>Hi all. I seem to be in a creative mood lately. I came up with an odd
>idea for a festive holiday light type item. Problem is I want 15-30
>channels of PWM. I really like the PIC's PWM module for its simplicity.
>However, 15 16f628s or 8 16f870s seems a bit much. I have seen Scott
>Dattalo's code for 8 concurrent streams. However it's all software, and
>I'm worried that running a routine for dealing with serial comms will
>throw off the timing. Is there a commercially available chip that does
>multiple PWMs in one package? Or, has anyone else dealt with this?
>
>Thanks,
>Josh
>
>--
>A common mistake that people make when trying to design something
>completely foolproof is to underestimate the ingenuity of complete
>fools.
>        -Douglas Adams
>
>--
>http://www.piclist.com hint: The list server can filter out subtopics
>(like ads or off topics) for you. See http://www.piclist.com/#topics
>
>

>Have a look at http://www.al-williams.com/pak5.htm -- a lot of these are
>used in commercial lighting displays.
>
>Other than that, you might consider writing your own PWM in an interrupt
>timer routine. However, 30 might be a bit much depending on the
>frequency you want.
>
>Regards,
>
>Al Williams
>AWC
>* Easy RS-232 Prototyping
>http://www.al-williams.com/awce/rs1.htm
>

>         CLRW                    ;Build the bit mask for turning
>                                 ;off the PWM outputs. Assume that
>                                 ;all of the outputs will be turned
>                                 ;off.
>                                 ;
>         DECFSZ  pwm0,F          ;If the first counter has not reached 0
>          IORLW  00000001b       ;then we don't want to turn it off.
>                                 ;
>         DECFSZ  pwm1,F          ;Same for the second one
>          IORLW  00000010b       ;

> Well, as Olin suggested, the PWM routine can be placed in a Timer
> interrupt routine. You could run
>
> http://www.dattalo.com/technical/software/pic/pwm8.asm
>
> For 23 cycles / 8 PWM's. Or 46 cycles for 16 PWMs. For the last two PWMs
> you could shrink the routine to just this:
>
>         CLRW                    ;Build the bit mask for turning
>                                 ;off the PWM outputs. Assume that
>                                 ;all of the outputs will be turned
>                                 ;off.
>                                 ;
>         DECFSZ  pwm0,F          ;If the first counter has not reached 0
>          IORLW  00000001b       ;then we don't want to turn it off.
>                                 ;
>         DECFSZ  pwm1,F          ;Same for the second one
>          IORLW  00000010b       ;
>
>         ANDWF   pwm_state,W     ; Clear all of those pwm outputs
>                                 ;that have reached zero.
>                                 ;
>         XORLW   00000011b       ;Toggle the current state.
>         INCFSZ  rising_edge,F   ;If the rising edge counter has not
>          XORLW  00000011b       ;rolled over then toggle them again.
>                                 ;Double toggle == no effect. However,
>                                 ;if the rising edge counter does roll
>                                 ;over then a single toggle will turn
>                                 ;the pwm bits on, unless of course the
>                                 ;pwm counter has just rolled over too.
>                                 ;
>         MOVWF   pwm_state       ;Save the state
>         MOVWF   PWM_PORT        ;update the outputs
>
> That'd be 58 cycles for 18 outputs. If TMR0 is the interrupt source and
> you don't select the prescaler, then you'd have ~75% of the CPU time
> available for other things. Those "other things" would be updating all
> those PWMs! (BTW, there's a way to save a few cycles by combining the
> checks for "rising_edge").

>
> Hi Josh,
> You can put the counterupdates in the interrupt routine if u want
> to control the PWM freq. independently from your mainloop.
>
> First of all I'd like to present a way to think about how it works:
> Think of it as 2 cam-wheels (like in a washing machine)
> One wheel sets the PWM output to 0 once each turn.
> The other one sets the PWM output to 1 once each turn.
>
> Now if these two wheels were on the same axle, and u start
> turning the axle around... the axle rpm decides the PWM-freq.
> And the phase-difference between the wheels decides the
> pulsefactor 0-100%. So it is perfectly okay that the counters
> roll over, they are supposed to !
>
> You do not need to reload the counters unless u want to change
> the pulsefactor. And then all you do is add say 1 to the PWM-
> counter and the phase will shift slightly.
>
> Above method is dead simple and works like a charm, the routine
> below is more complicated and doesnt offer anything extra (i think)
> *ducks*
>
> I prolly could dig up some code I wrote using above techinqe
> for a recent project if ure interested... for the 877 tho.
> I figured id put it on piclist.com but no time to mess w that now :-)

> Ok, sorry to dig up this old thread, but now that I actually go to
> integrate it into a project, I seem to have forgotten that perfect view
> of the solution I had a month ago :)
>
> I am looking to use the code at
> www.dattalo.com/technical/software/pic/pwm8.asm
> to do multiple PWMs on one chip. My basic question is...where and when
> do I update the PWM counters? I plan on putting the timer checking and
> updating in an ISR, and triggering it with a TMR0 interrupt. This will
> work on the first iteration, but once a counter has hit zero, doesn't it
> just start again at 255? Therefore, I would need to reload the value I
> want in the counter so that it will start to count down again. What if
> after:
>          DECFSZ  pwm0,F          ;If the first counter has not reached 0
>          IORLW  00000001b       ;then we don't want to turn it off.
> I add something to the effect of:
>         check pwm0 for zero
>         if zero, reload pwm0 with proper value
> This would still be in the ISR. How does this sound? Plausible? Am I on
> the right track? I'm using an 18f252 chip, so I was thinking about using
> the BZ (Branch if Zero) operand. I guess I would have to do a movf
> pwm0,f in order to trigger the zero bit. If only there was an
> instruction similar to TSTFSZ (Test f, skip if 0), but skip if not zero.
> Can having the branch operand in an ISR cause a stack overflow if I run
> too many of them?

> If you're using the 18F series then  you can save an instruction:
>
> Instead of doing this (at the end of the routine)
>
>         XORLW   11111111b       ;Toggle the current state.
>         INCFSZ  rising_edge,F   ;If the rising edge counter has not
>          XORLW  11111111b       ;rolled over then toggle them again.
>                                 ;Double toggle == no effect. However,
>                                 ;if the rising edge counter does roll
>                                 ;over then a single toggle will turn
>                                 ;the pwm bits on, unless of course the
>                                 ;pwm counter has just rolled over too.
>
> You save the instruction by:
>
>        INFSNZ   rising_edge,F
>         BRA     UpdatePWMs      ;When the rising edge counter rolls over
>                                 ; then update everything.
>
>        MOVWF   pwm_state       ;Save the state
>        MOVWF   PWM_PORT        ;update the outputs
>
>        RETURN
>
> Then:
>
> UpdatePWMs:
>
>   ; (note the reversed order from above - this ensures the
>   ; pwm_port is written isochronously).
>
>        MOVWF   PWM_PORT        ;update the outputs
>        MOVWF   pwm_state       ;Save the state
>
>   ; copy the current duty cycles into counters
>
>        MOVFF    pwm0DC,pmw0
>        ...
>
>        RETURN
>
> Everytime the "rising_edge" counter rolls over, 17 extra cycles are spent
> updating the PWM counters. However, the counters don't need to be updated
> if nothing has changed (they just roll over). So you could save 15
> instructions by adding a flag:
>
> UpdatePWMs:
>
>   ; (note the reversed order from above - this ensures the
>   ; pwm_port is written isochronously).
>
>        MOVWF   PWM_PORT        ;update the outputs
>        MOVWF   pwm_state       ;Save the state
>
>        BTFSS   ShouldUpdate,bitn
>         return
>
>        BCF     ShouldUpdate,bitn
>
>  ; copy the current duty cycles into counters
>
>        MOVFF    pwm0DC,pmw0
>        ...
>
> ----
>
> You can also dynamically adjust the PWM. However, this runs the risk of
> creating an abrupt discontinuity. See the comments in the code (on my web
> page) on how this can be done.
>
> ----
>
> BTW, If you're using the 18F there's a way to save many instructions:
>
>        DCFSNZ    pwm0,F           ;When the pwm counter reaches 0
>         BTG      PWM_LATCH,0      ;toggle it's output
>
>       ....
>
>        DCFSNZ    pwm7,F
>         BTG      PWM_LATCH,7
>
>        DCFSNZ    rising_edge,F
>         NEGF     PWM_LATCH,F      ; tricky - drive all ouput highs.
>
> 18 cycles versus 23.
>
> The NEGF works because all of the outputs are cleared by executing a
> single BTG (bit toggle) instruction every 256 iterations. At the end of
> 256 cycles, all 8 outputs are cleared and the NEGF will turn them all back
> on. Of course, this assumes that when the PWM engine was started that the
> output latch was initialized to all ones.
>
> A slightly better ending:
>
>        DECFSZ    rising_edge,F
>         RETURN
>
>        NEGF      PWM_LATCH,F
>
>        ; update the PWM's:
>
>        BTFSS    ShouldUpdate,bitn
>         return
>
>        BCF      ShouldUpdate,bitn
>
>        MOVFF    pwm0DC, pwm0
>        ...
>
>        RETURN

>
> On Sun, 15 Dec 2002, Josh Koffman wrote:
>
> > Ok, sorry to dig up this old thread, but now that I actually go to
> > integrate it into a project, I seem to have forgotten that perfect view
> > of the solution I had a month ago :)
> >
> > I am looking to use the code at
> > www.dattalo.com/technical/software/pic/pwm8.asm
> > to do multiple PWMs on one chip. My basic question is...where and when
> > do I update the PWM counters? I plan on putting the timer checking and
> > updating in an ISR, and triggering it with a TMR0 interrupt. This will
> > work on the first iteration, but once a counter has hit zero, doesn't it
> > just start again at 255? Therefore, I would need to reload the value I
> > want in the counter so that it will start to count down again. What if
> > after:
> >          DECFSZ  pwm0,F          ;If the first counter has not reached 0
> >          IORLW  00000001b       ;then we don't want to turn it off.
> > I add something to the effect of:
> >         check pwm0 for zero
> >         if zero, reload pwm0 with proper value
> > This would still be in the ISR. How does this sound? Plausible? Am I on
> > the right track? I'm using an 18f252 chip, so I was thinking about using
> > the BZ (Branch if Zero) operand. I guess I would have to do a movf
> > pwm0,f in order to trigger the zero bit. If only there was an
> > instruction similar to TSTFSZ (Test f, skip if 0), but skip if not zero.
> > Can having the branch operand in an ISR cause a stack overflow if I run
> > too many of them?
>
> If you're using the 18F series then  you can save an instruction:
>
> Instead of doing this (at the end of the routine)
>
>         XORLW   11111111b       ;Toggle the current state.
>         INCFSZ  rising_edge,F   ;If the rising edge counter has not
>          XORLW  11111111b       ;rolled over then toggle them again.
>                                 ;Double toggle == no effect. However,
>                                 ;if the rising edge counter does roll
>                                 ;over then a single toggle will turn
>                                 ;the pwm bits on, unless of course the
>                                 ;pwm counter has just rolled over too.
>
> You save the instruction by:
>
>        INFSNZ   rising_edge,F
>         BRA     UpdatePWMs      ;When the rising edge counter rolls over
>                                 ; then update everything.
>
>        MOVWF   pwm_state       ;Save the state
>        MOVWF   PWM_PORT        ;update the outputs
>
>        RETURN
>
> Then:
>
> UpdatePWMs:
>
>   ; (note the reversed order from above - this ensures the
>   ; pwm_port is written isochronously).
>
>        MOVWF   PWM_PORT        ;update the outputs
>        MOVWF   pwm_state       ;Save the state
>
>   ; copy the current duty cycles into counters
>
>        MOVFF    pwm0DC,pmw0
>        ...
>
>        RETURN
>
> Everytime the "rising_edge" counter rolls over, 17 extra cycles are spent
> updating the PWM counters. However, the counters don't need to be updated
> if nothing has changed (they just roll over). So you could save 15
> instructions by adding a flag:
>
> UpdatePWMs:
>
>   ; (note the reversed order from above - this ensures the
>   ; pwm_port is written isochronously).
>
>        MOVWF   PWM_PORT        ;update the outputs
>        MOVWF   pwm_state       ;Save the state
>
>        BTFSS   ShouldUpdate,bitn
>         return
>
>        BCF     ShouldUpdate,bitn
>
>  ; copy the current duty cycles into counters
>
>        MOVFF    pwm0DC,pmw0
>        ...
>
> ----
>
> You can also dynamically adjust the PWM. However, this runs the risk of
> creating an abrupt discontinuity. See the comments in the code (on my web
> page) on how this can be done.
>
> ----
>
> BTW, If you're using the 18F there's a way to save many instructions:
>
>        DCFSNZ    pwm0,F           ;When the pwm counter reaches 0
>         BTG      PWM_LATCH,0      ;toggle it's output
>
>       ....
>
>        DCFSNZ    pwm7,F
>         BTG      PWM_LATCH,7
>
>        DCFSNZ    rising_edge,F
>         NEGF     PWM_LATCH,F      ; tricky - drive all ouput highs.
>
> 18 cycles versus 23.
>
> The NEGF works because all of the outputs are cleared by executing a
> single BTG (bit toggle) instruction every 256 iterations. At the end of
> 256 cycles, all 8 outputs are cleared and the NEGF will turn them all back
> on. Of course, this assumes that when the PWM engine was started that the
> output latch was initialized to all ones.
>
> A slightly better ending:
>
>        DECFSZ    rising_edge,F
>         RETURN
>
>        NEGF      PWM_LATCH,F
>
>        ; update the PWM's:
>
>        BTFSS    ShouldUpdate,bitn
>         return
>
>        BCF      ShouldUpdate,bitn
>
>        MOVFF    pwm0DC, pwm0
>        ...
>
>        RETURN

>
> So...the question is, what do I do now? I was thinking of perhaps
> splitting the channels up. Instead of having them all on 1 main counter,
> I could have 4 counters. They'd all increment in the ISR, but I'd
> preload them at the start with different values, and offset them. This
> would make my ISR much longer, but it would be a uniform longness, not
> based (as much) on concurrent roll overs. I guess another option would
> be to try Scott's updated 18F code below, but I think I'll run into
> similar problems as long as there are 8 roll overs occuring at once.
>
> I can't quite figure out exactly why this is all happening, my ideas
> above are educated guesses at best. The problem doesn't seem to occur as
> much with lower PWM values, but once I get significantly above 0x80
> (halfway) things start to go odd. Below that, I'm getting the right
> pulse widths on most channels, but have some values that cause wierd
> things to happen with some channels and not others. That's why I leaning
> towards the seperate, offset main counters.
>
> Any comments? Am I even on the right track? Or am I so horribly wrong
> that it doesn't even make sense?

>
> On Fri, 20 Dec 2002, Josh Koffman wrote:
>
> > Well, I've hit yet another problem. Everything was going great...until I
> > tried to run all PWM channels at the same value. Apparently, that wasn't
> > such a great idea :)
>
> It should work just fine!
>
> > I'm running the older version of the code, what's posted on the web, not
> > the new suggestions Scott has made below. I'm sorry the post is so long,
> > but I felt it was somewhat important to leave Scott's comments attached.
>
> There are a couple of enhancements to that code. Probably the biggest one
> is that I suggested a "NEGF" instruction when I meant a "COMF"
> instruction. I bet that is what's causing you the problems. Sorry about
> that.
>
> >
> > Basically what I think is happening is that when all the counters roll
> > over at the same time, each bit in the mask needs to be set, and it adds
> > too many cycles to the ISR. So when I set all PWMs to 0xFF, instead of
> > looking like almost a perfect 100% duty cycle, instead I see about a 50%
> > duty cycle. And yes, it happens with 0xFE too, so it's not just a wacky
> > end of range thing.
>
> It sounds like these roll-over counters are throwing you through a
> while(1) loop. You may wish to read a brief description of the pwm
> algorithm here:
>
> http://www.dattalo.com/technical/theory/pwm.html
>
> >
> > So...the question is, what do I do now? I was thinking of perhaps
> > splitting the channels up. Instead of having them all on 1 main counter,
> > I could have 4 counters. They'd all increment in the ISR, but I'd
> > preload them at the start with different values, and offset them. This
> > would make my ISR much longer, but it would be a uniform longness, not
> > based (as much) on concurrent roll overs. I guess another option would
> > be to try Scott's updated 18F code below, but I think I'll run into
> > similar problems as long as there are 8 roll overs occuring at once.
> >
> > I can't quite figure out exactly why this is all happening, my ideas
> > above are educated guesses at best. The problem doesn't seem to occur as
> > much with lower PWM values, but once I get significantly above 0x80
> > (halfway) things start to go odd. Below that, I'm getting the right
> > pulse widths on most channels, but have some values that cause wierd
> > things to happen with some channels and not others. That's why I leaning
> > towards the seperate, offset main counters.
> >
> > Any comments? Am I even on the right track? Or am I so horribly wrong
> > that it doesn't even make sense?
>
> In the original routine there are 8 counters for the 8 pwms, 1 counter for
> the rising edge and there's one variable for the current state of the pwm
> outputs. None of these should be changed while the program is running! The
> other day we discussed a method by which the 8 pwm counters could be
> dynamically changed. Recall that this require 8 new variables that get
> copied to the 8 pwm counters when the rising edge counter rolls over.
>
> Let's look at the roll over issue in a little more detail. From my web
> page I write:
>
> RE  |---------|---------|---------|---------|---------
>     01234567890123456789012345678901234567890123456789
>
> FE  ----|---------|---------|---------|---------|-----
>     67890123456789012345678901234567890123456789012345
>
> PWM ----______----______----______----______----______
>
> RE = Rising Edge counter
>
> FE = Falling Edge counter
>
> PWM = PWM output
>
> In this example, the counters roll over after 10 counts. In the beginning,
> the rising edge counter is cleared and the output is driven high. Also,
> the duty cycle is 4 so the falling edge counter is initialized to (10 - 4)
> = 6. When the rising edge counter counts from 9 to 10, it is "rolled over"
> back to zero and the output is driven high. Similarly, the falling edge
> counter drives the output low when it rolls over.
>
> Perhaps one thing to notice is that the difference (modulo 10) between the
> two counters is always equal to the duty cycle. That's no coincidence. In
> fact that's why this technique is called the "Phase Shifted Counters".
>
> --------------
>
> You describe the boundary condition of the pwm counters = 0xff. Let's look
> at that for one pwm. This table illustrates what happens:
>
> rising   pwm
> edge     counter   output
> -------------------------
>   0       ff        1
>   1       fe        1
>   2       fd        1
>   ...
>   fe      1         1
>   ff      0         0
>   0       ff        1
>
> Can you try this in a simulator to verify that it's true?
>
> Now for code. You've got the routine on my web page. Here's a version that
> saves an instruction (and still works for the 14-bit core devices):
>
>         MOVF    pwm_state,W     ;Get the current state of the pwms.
>                                 ;We assume that the PWMs are not changed
>                                 ;on this cycle
>                                 ;
>                                 ;
>         DECFSZ  pwm0,F          ;If the first counter has not reached 0
>          ANDLW  11111110b       ;then we don't want to turn it off.
>                                 ;
>         DECFSZ  pwm1,F          ;Same for the second one
>          ANDLW  11111101b       ;
>                                 ;
>         DECFSZ  pwm2,F          ;and so on...
>          ANDLW  11111011b       ;
>                                 ;
>         DECFSZ  pwm3,F          ;
>          ANDLW  11110111b       ;
>                                 ;
>         DECFSZ  pwm4,F          ;
>          ANDLW  11101111b       ;
>                                 ;
>         DECFSZ  pwm5,F          ;
>          ANDLW  11011111b       ;
>                                 ;
>         DECFSZ  pwm6,F          ;
>          ANDLW  10111111b       ;
>                                 ;
>         DECFSZ  pwm7,F          ;
>          ANDLW  01111111b       ;
>                                 ;At this point, W contains a bit
>                                 ;mask of all PWMs that need to be
>                                 ;cleared
>                                 ;
>                                 ;
>         INCFSZ  rising_edge,F   ;If the rising edge counter has not
>          GOTO   drive_pwms      ;reached zero then drive the next state
>                                 ;
>         MOVLW   11111111b       ;Drive all pwms high
>         MOVWF   pwm_state       ;Save the state
>         MOVWF   PWM_PORT        ;update the outputs
>
>         ; update the pwm counters here.
>
>         RETURN
>                                 ;
> drive_pwms:                     ;
>         XORWF   pwm_state,W     ;Clear the outputs that have changed
>         MOVWF   pwm_state       ;Save the state
>         MOVWF   PWM_PORT        ;update the outputs
>
>         RETURN
>
> ----------
>
> The code I posted for the 18f instruction set last time directly modifies
> the output latch. This is bad because it means that there's a skew in the
> pulse widths of the PWMs. So here is a correction:
>
> PWM_LATCH  EQU  LATB   ; assume port b is the output port.
>
>         COMF    PWM_LATCH,W     ;Get the complement of the current state
>                                 ;of the pwms. We assume the pwms will
>                                 ;change this iteration.
>                                 ;
>                                 ;
>         DECFSZ  pwm0,F          ;If the first counter has not reached 0
>          ANDLW  11111110b       ;then don't turn it off.
>                                 ;
>         DECFSZ  pwm1,F          ;Same for the second one
>          ANDLW  11111101b       ;
>                                 ;
>         DECFSZ  pwm2,F          ;and so on...
>          ANDLW  11111011b       ;
>                                 ;
>         DECFSZ  pwm3,F          ;
>          ANDLW  11110111b       ;
>                                 ;
>         DECFSZ  pwm4,F          ;
>          ANDLW  11101111b       ;
>                                 ;
>         DECFSZ  pwm5,F          ;
>          ANDLW  11011111b       ;
>                                 ;
>         DECFSZ  pwm6,F          ;
>          ANDLW  10111111b       ;
>                                 ;
>         DECFSZ  pwm7,F          ;
>          ANDLW  01111111b       ;
>                                 ;At this point, W contains a bit
>                                 ;mask of all PWMs that need to be
>                                 ;cleared
>                                 ;
>                                 ;
>         INFSNZ  rising_edge,F   ;If the rising edge counter has rolled
>          COMF   PWM_LATCH,W     ;over, grab a complement of the current
>                                 ;state of the outputs
>                                 ;
>         XORWF   PWM_LATCH       ;update the outputs
>
>         TSTFSZ  rising_edge
>          RETURN
>                                 ;
>
>         ; update PWM counters here.
>
>         RETURN
>