[PWM] Nadel verschwindet nicht

[Joachim .. (joachim_01)]

Hab hier nen 1284P und erzeuge mit Timer 0 PWM-Werte.
Eigentlich sollte es wohl so sein, daß der Ausgang bei OCR0A = 0 auf Low 
geht. Stattdessen kommt eine regelmäßige Nadel.
Wenn ich mit dem Oszi nachmesse so sieht es aus als ob es nicht 1/256 
sondern ca 3/256 Periodendauer sind - was mich zu dem Gedanken bringt, 
daß dies vielleicht gar kein Spike ist sondern das Vergleichen nicht 
funktioniert/unterdrückt wird/ bzw zum Zeitpunkt x gar nicht 
stattfindet.
Wenn Atmel "Glitch Free, Phase Correct Pulse Width Modulator (PWM)" 
schreibt, dann sollte das doch auch eigentlich so sein, oder? Ich könnte 
natürlich auch für einen kurze Zeit den Port abschalten... aber das ist 
ja nicht der Sinn. Wo liegt der Denkfehler?

   //PWM test

       OCR0A = 0;
    
       // set up WGM, clock, and mode for timer 0
       TCCR0A = 1 << COM0A1 |    // Clear OC0A on Compare Match, set OC0A at BOTTOM (in Fast PWM Mode)
                0 << COM0A0 |
                1 << WGM01  |    /* fast pwm */
                1 << WGM00  ;    /* fast pwm */

       TCCR0B = 0 << FOC0A |
                0 << FOC0B |
                0 << WGM02 |     /* fast pwm */
                1 << CS02  |     /* div 256 prescale */
                0 << CS01  |
                0 << CS00  ;
 
  
        while (1) {
            OCR0A = 0x40;    // ok
            showPWMVal();    // show register contents
            _delay_ms(500);
        //while (1);
            OCR0A = 0x00;    //Nadel bleibt stehen
            showPWMVal();    // show register contents
            _delay_ms(500);

        }

[Falk B. (falk)]

@  Joachim ... (joachim_01)

>Eigentlich sollte es wohl so sein, daß der Ausgang bei OCR0A = 0 auf Low
>geht.

Nein.

> Stattdessen kommt eine regelmäßige Nadel.

Ja, siehe Datenblatt.

>Wenn ich mit dem Oszi nachmesse so sieht es aus als ob es nicht 1/256
>sondern ca 3/256 Periodendauer sind

Dann misst du wahrscheinlich falsch.

>Wenn Atmel "Glitch Free, Phase Correct Pulse Width Modulator (PWM)"
>schreibt, dann sollte das doch auch eigentlich so sein, oder?

Das ist kein Glitch, das ist die minimale Pulsbreite. Wenn du den Pin 
dauerhaft auf Null schalten willst, musst du die PWM abkoppeln und den 
Pin manuell auf LOW setzen. Ist halt ein Sonderfall.

[Karl H. (kbuchegg)]

Joachim ... schrieb:
> Hab hier nen 1284P und erzeuge mit Timer 0 PWM-Werte.
> Eigentlich sollte es wohl so sein, daß der Ausgang bei OCR0A = 0 auf Low
> geht.

Nein.
Durch die Reihenfolge der Operationen geschieht das nicht.

Der Ausgangspin wird auf 1 gesetzt, wenn der Timer auf 0 geht.
Erst dann erfolgt der Vergleich mit dem OCR Wert und wenn die 
übereinstimmen, wird der Pin wieder auf 0 gesetzt.

Es gibt da für einen OCR Wert von 0 keine Ausnahme.

Wenn dich das stört, dann musst du selbst die 0 als Sonderfall behandeln 
und selbst wieder die Kontrolle über den Pin übernehmen und ihn auf 0 
setzen.

Oder du drehst die PWM um. Dann kannst du zwar ein DauerLow erzeugen 
aber kein Dauer-High mehr. Irgendeinen Tod musst du sterben.

[Karl H. (kbuchegg)]

> Wenn Atmel "Glitch Free, Phase Correct Pulse Width Modulator
> (PWM)" schreibt, dann sollte das doch auch eigentlich so sein, oder?

Da ist aber von etwas völlig anderem die Rede.

[spess53 (Gast)]

Hi

>Oder du drehst die PWM um. Dann kannst du zwar ein DauerLow erzeugen
>aber kein Dauer-High mehr. Irgendeinen Tod musst du sterben.

Phase Correct und Phase and Frequency Correct lässt sich auf Null 
stellen. Allerdings ist die Frequenz halbiert.

MfG Spess

[Joachim .. (joachim_01)]

Vielen Dank für die schnelle Hilfe. Yep, dann mach ichs wohl mit ner 
zusätzlichen Zeile. Aber wundern tut mich das schon. Ist das denn bei 
allen uC-Familien so?

>> Wenn Atmel "Glitch Free, Phase Correct Pulse Width Modulator
>> (PWM)" schreibt, dann sollte das doch auch eigentlich so sein, oder?

>Da ist aber von etwas völlig anderem die Rede.
Ich hatte es mir schon fast gedacht, damit ist wohl das hardwaremäßig 
fehlerfreie interne kopieren/updaten der (Schatten-)Register gemeint.

[Alex S. (thor368)]

Tach Joachim,

du hast schon recht. Mit diesen Einstellungen kannst du keine "0" am 
Port ausgeben. Du hast nur 256 Schritte zur Verfügung. Entweder bedeutet 
0 dann 0% oder 256 100%. Im nicht invertierenden Modus ist das OC bit 
für ein timerclock gesetzt. Das liegt daran, dass der OC beim Sprung von 
256 auf 0 gesetzt wird aber erst im Sprung von 0 auf 1 gelöscht. Wenn du 
das umgehen möchtest kannst du entweder das OCR bit invertieren. Dann 
dreht sich das Problem um und du kannst keine 100% duty cycle ausgeben. 
Oder du deaktivierst das COM wenn OCRx = 0.

Thor

[Karl H. (kbuchegg)]

Joachim ... schrieb:
> Vielen Dank für die schnelle Hilfe. Yep, dann mach ichs wohl mit ner
> zusätzlichen Zeile. Aber wundern tut mich das schon. Ist das denn bei
> allen uC-Familien so?
>
>>> Wenn Atmel "Glitch Free, Phase Correct Pulse Width Modulator
>>> (PWM)" schreibt, dann sollte das doch auch eigentlich so sein, oder?
>
>>Da ist aber von etwas völlig anderem die Rede.
> Ich hatte es mir schon fast gedacht, damit ist wohl das hardwaremäßig
> fehlerfreie interne kopieren/updaten der (Schatten-)Register gemeint.

So kann man das ausdrücken.

Es geht zb um die Fragestellung, was die PWM macht, wenn du den OCR Wert 
von sagen wir mal 200 auf 100 verringerst und der Timer in seiner 
Zähglerei gerade bei 150 ist. Normalerweise würde er ja weiterzählen und 
bei 200 den Pin wieder abschalten. Da aber die Grenze auf 100 abgesenkt 
wurde, würde er in diesem PWM-Zyklus den Abschaltpunkt verpassen (Der 
Wert wird ja nur auf Gleichheit geprüft und nicht auf Größer) und die 
PWM würde für einen Zyklus gar nicht den Pin abschalten. Jetzt hast du 
einen Glitch, einen Puls der nicht dazugehört.
Die Lösung: Eine Änderung des OCR Wertes geht nicht direkt ins OCR 
Register, sonder erst mal in einen Zwischenpuffer. Erst dann, wenn der 
Timer den Reset macht, wird das eigentliche OCR Register von diesem 
Zwischenpuffer upgedatet (oder auch nicht, je nach Modus. Da gibts im 
Datenblatt eine Tabelle über alle MOdi und da steht auch drinn, wann der 
Update gemacht wird). Dadurch ist gewährleistet, dass das OCR Register 
seinen Wert erhält, wenn keine Gefahr besteht, dass obiges Szenario 
passiert.


Und Phase-Correct-PWM ist sowieso ein anderer Modus als Fast-PWM.

[Hauspapa (Gast)]

Diese PWM Einheit ist eine der Übersichtlichsten die ich kenne. Also bei 
TI DSPs ist die PWM Einheit noch wesentlich mächtiger, die Dokumentation 
erheblich dicker und solche Fallstricke noch einige mehr.

Spätestens wenn man Timer synchronisiert, einzelne Ausgänge 
gegeneinander verriegelt sein mmüssen, Totzeiten zu beachten sind, 
Startupreihenfolgen zu beachten sind usw. werden so Randwertprobleme 
schnell nicht mehr nur ein bischen unhübsch sondern ausgewachsene Orgien 
in den Tiefen der Registerdokumentation.

viel Erfolg
Hauspapa

[Bronco (Gast)]

Karl Heinz Buchegger schrieb:
> Es geht zb um die Fragestellung, was die PWM macht, wenn du den OCR Wert
> von sagen wir mal 200 auf 100 verringerst und der Timer in seiner
> Zähglerei gerade bei 150 ist. Normalerweise würde er ja weiterzählen und
> bei 200 den Pin wieder abschalten. Da aber die Grenze auf 100 abgesenkt
> wurde, würde er in diesem PWM-Zyklus den Abschaltpunkt verpassen (Der
> Wert wird ja nur auf Gleichheit geprüft und nicht auf Größer) und die
> PWM würde für einen Zyklus gar nicht den Pin abschalten. Jetzt hast du
> einen Glitch, einen Puls der nicht dazugehört.
> Die Lösung: Eine Änderung des OCR Wertes geht nicht direkt ins OCR
> Register, sonder erst mal in einen Zwischenpuffer. Erst dann, wenn der
> Timer den Reset macht, wird das eigentliche OCR Register von diesem
> Zwischenpuffer upgedatet (oder auch nicht, je nach Modus. Da gibts im
> Datenblatt eine Tabelle über alle MOdi und da steht auch drinn, wann der
> Update gemacht wird). Dadurch ist gewährleistet, dass das OCR Register
> seinen Wert erhält, wenn keine Gefahr besteht, dass obiges Szenario
> passiert.

Auf 8051, C167 & Co. gab es die Empfehlung, die beteiligten Register nur 
in der Timer-Overflow-ISR zu überschreiben. Dadurch wurden eben diese 
Glitches vermieden.
Ich ja schön zu hören, daß der AVR das in Hardware kann.