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 <.....speffKILLspam
.....INTERLOG.COM>
Para: <EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU>
Enviado: jueves, 08 de marzo de 2001 18:57
Asunto: Re: [PIC]: PWM glitch-free updates
{Quote hidden}> 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"
> speffspam_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
