Searching \ for '[PIC]: PWM glitch-free updates' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=pwm
Search entire site for: 'PWM glitch-free updates'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: PWM glitch-free updates'
2001\03\08@092457 by Spehro Pefhany

picon face
Hi,

Midrange PIC CCP module question:-

What's the best strategy for dealing with updating
a 10-bit PWM value asynchronously with TMR2?

It looks like you could get a glitch if the update
happens to occur just as TMR2 is overflowing.

Is it better to read TMR2 to make sure it isn't
about to roll over (and wait around for a bit if
it is), or is it better to do something else like
use the TMR2 interrupt to triple-buffer the data
(and disable interrupts during the update to the
shadow registers to make it atomic). Or something
else?

Thanks for any suggestions.

Best regard.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\08@093955 by Olin Lathrop

face picon face
> What's the best strategy for dealing with updating
> a 10-bit PWM value asynchronously with TMR2?
>
> It looks like you could get a glitch if the update
> happens to occur just as TMR2 is overflowing.

I've thought about this too.  In the end I just updated the high 8 bits,
then the low two bits as quickly as possible thereafter.  Since PWM is
usually used to achieve an average duty cycle over a longer time interval
than the PWM frequency, I think you can just ignore the glitch because the
average will still be correct.  Yeah, I know, I'd feel better too if all 10
bits were properly double buffered in the hardware.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, .....olinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\08@095231 by Roman Black

flavicon
face
Olin Lathrop wrote:
>
> > What's the best strategy for dealing with updating
> > a 10-bit PWM value asynchronously with TMR2?
> >
> > It looks like you could get a glitch if the update
> > happens to occur just as TMR2 is overflowing.
>
> I've thought about this too.  In the end I just updated the high 8 bits,
> then the low two bits as quickly as possible thereafter.  Since PWM is
> usually used to achieve an average duty cycle over a longer time interval
> than the PWM frequency, I think you can just ignore the glitch because the
> average will still be correct.  Yeah, I know, I'd feel better too if all 10
> bits were properly double buffered in the hardware.


I poll timer2 and only change the registers in a
time when the change will not affect the PWM
output. Most of my apps use some type of polling
to get the best hardware performance, and I also
like to synchronise timer1 or timer2 a few insts
after timer0 which I use for the main int, as I can
then handle timer1/timer2 overflow issues at the
end of the timer0 int, before any code processing
gets to take place. Hope that makes sense. :o)
-Roman

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\08@104237 by Mike Mansheim

flavicon
face
> What's the best strategy for dealing with updating
> a 10-bit PWM value asynchronously with TMR2?

> It looks like you could get a glitch if the update
> happens to occur just as TMR2 is overflowing.

quote from the F87x data sheet:
"The CCPR1H register and a 2-bit internal latch are used to double buffer
the PWM duty cycle.  This double buffering is essential for glitchless
PWM operation".
and (earlier in the discussion):
"...but the duty cycle value is not latched into CCPR1H until after a
match between PR2 and TMR2 occurs..."

From the comments by Spehro & Olin, is this all hooey??

(by the way, my applications of pwm typically wouldn't care about an
occasional glitch, but now I'm curious)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\08@125823 by Spehro Pefhany
picon face
At 09:39 AM 3/8/01 -0600, you wrote:

>>From the comments by Spehro & Olin, is this all hooey??

Not hooey, there are two distinct problems. The first is that the
value for comparison should be double-buffered. If this was not true, it
would be possible to "short cycle" the PWM by writing a value into
there during the PWM cycle. If the (double-buffering) hardware was
not in the PIC, it would be very difficult to make a glitchless
(even) 8-bit PWM.

The second only rears its head when you go beyond 8 bits on the
PWM. The problem is that you have *two* registers being written
at an unknown time relative to TMR2 rollover, if it happens to hit
exactly after the update of the MS 8 bits, but before the update
of the LS 2 bits (or the opposite), you get a glitch. You could imagine a
pathological situation where the program was running isochronously
and *always* hitting at just the right time, and the required PWM
value was bobbling between 00000001 00 and 00000000 11 on alternate
updates. In this unlikely scenario, the output could be steady at
0000001 11 (almost double what it should be) or 00000000 00 (zero).
This happens because the update of the two bytes is not an atomic
operation, this being an 8-bit processor. Some Motorola micros
deal with similar issues by interlocking it so the update of the
comparison register won't take place until the 2nd register is
written if they are written in one order, and allowing the glitch
if they are written in the reverse order. That takes a FF and
a bit of logic on chip.

Thanks for the comments, guys!

Best regards,



=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffspamKILLspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\08@152444 by Alvaro Deibe Diaz

flavicon
face
I don't get a single glitch on my PWM arrangement:

I use CCP2 to generate 6 PWM for 6 RC servos. The 6 PWM signals get out of
the pic through CCP2 pin, multiplexed in time. Then, controlling the TRIS
state of pins RB5:RB0, tied to CCP2 with a 4k7 resistor each one, the PWM
pulses reach the six servos... (this sound a little complicated, but it is
not so)

Then I need to update the duty cycle of the PWM module for EACH PWM cycle.
To do this I wrote a int service routine that runs at the end of each cycle.
Here a "dummy" PWM cycle begins. The PWM value of the duty cycle, previously
programed in CCPR2L and CCP2CON5:4 is latched in the PWM hardware. This
value is 0, so no change in CCP2 pin is made. I, now, have time enough to
program the "real" value of the next duty cycle. TMR2 will not roll at this
point (is barely growing from 0). The next thing to do is program the next
TRIS states, to select the correct servo output, and, finally, force the
final of the "dummy" cycle writing TMR2 in PR2.

The 10 correct bits are then latched together to the PWM hardware, and the
"real" PWM cycle begins.

The last thing to do is reprogram PR2, CCPR2L and CCP2CON5:4 to generate the
next "dummy" cycle at the correct time...

The C code of this routine (in a monospaced font) is:
(sorry for the spanish comments, but I feel I wrote enough "english" today.
Sorry for this, too)

// Interrupción del TIMER2
 if (TMR2IF) {                                     // Interrupción del PWM
   // Ha comenzado un ciclo "falso" utilizado para generar la interrupción
   TRISB&=0b11000000;                       // Fuerza a 0 todos los servos
         //   ++++++-> Salidas a los 6 servos

   // Carga el valor del ciclo del siguiente canal
   if (i<NMAXCH) {
     CCP2CON&=0b11001111;                      // Borra los bits bajos del
     CCP2CON|=(lo(ch[i])<<4)&0b00110000;       // PWM y los escribe.
     CCPR2L=(ch[i])>>2;                        // Escribe los bits altos
     TRISB|=1<<i;               // Selecciona el servo del siguiente canal
   } else {
     CCP2X=0; CCP2Y=0;                               // Bits bajos del PWM
     CCPR2L=0;                                       // Bits altos del PWM
   }
   if (i++>=10) i=0;

   // Fuerza final del ciclo actual, para la recarga del nuevo ciclo
   while (TMR2!=0) PR2=TMR2;          // Espera que se produzca la recarga

   // Recarga el valor del período, y el siguiente ciclo "falso"
   PR2=PWMPER;                                      // Refresca el período
   CCP2X=0; CCP2Y=0;
   CCPR2L=0;

   TMR2IF=0;                              // Borra el flag de interrupción
 } // Fin del if (TMR2IF)



----- Mensaje original -----
De: Spehro Pefhany <.....speffKILLspamspam.....INTERLOG.COM>
Para: <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU>
Enviado: jueves, 08 de marzo de 2001 18:57
Asunto: Re: [PIC]: PWM glitch-free updates


{Quote hidden}

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=
> Spehro Pefhany --"it's the network..."            "The Journey is the
reward"
> speffspamspam_OUTinterlog.com             Info for manufacturers:
http://www.trexon.com
> Embedded software/hardware/analog  Info for designers:
http://www.speff.com
> Contributions invited->The AVR-gcc FAQ is at:
http://www.bluecollarlinux.com
>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=
>
> --
> http://www.piclist.com hint: PICList Posts must start with ONE topic:
> [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>
>
>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\08@214338 by Bob Ammerman

picon face
> > What's the best strategy for dealing with updating
> > a 10-bit PWM value asynchronously with TMR2?
>
> > It looks like you could get a glitch if the update
> > happens to occur just as TMR2 is overflowing.
>
> quote from the F87x data sheet:
> "The CCPR1H register and a 2-bit internal latch are used to double buffer
> the PWM duty cycle.  This double buffering is essential for glitchless
> PWM operation".
> and (earlier in the discussion):
> "...but the duty cycle value is not latched into CCPR1H until after a
> match between PR2 and TMR2 occurs..."
>
> From the comments by Spehro & Olin, is this all hooey??
>
> (by the way, my applications of pwm typically wouldn't care about an
>  occasional glitch, but now I'm curious)

No, this isn't all hooey.

What the data sheet is saying is that CCPR1L and the two PWM bits in CCP1CON
are copied to CCPR1H and an invisible two bit latch at the match time.

However, if the application has updated CCPR1L but ont CCP1CON or vice-versa
when the TMR2 to PR2 match occurs then you will get a partially updated
value loaded into the hardware.

This may seem like a non-issue, and that any error encountered this way will
eventually 'even out' over time.

There are two reasons this may not be so:

1: You may have a 'beat' between the execution loop of the program and the
period of TMR2 such that you more or less consistently have the wrong value.

2: If PR2 is set to a relatively small value (for a higher PWM rate at the
cost of resolution) then what would normally be the LSBits of a 10-bit value
can have quite a bit more significance.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...