Verständnisproblem PWM

[Attila (Gast)]

Hallo!

Anfängerfrage:

Meines Erachtens müsste der Wert fade nach 255 "Vorgängen" bei 0x00 
verweilen. Dem ist aber nicht so. Warum?

#ifdef TIMER2_OVF_vect
#endif

  int  fade=0xFF;

  ISR (TIMER2_OVF_vect)
    {
    OCR2=fade;
    fade--;
    }

[fade (Gast)]

Dem ist nicht so, weil du bei int fade problemlos 1 von 0 abziehen 
kannst und dann -1 in fade steht...

Bei

  ISR (TIMER2_OVF_vect)
    {
    OCR2=fade;
    if (fade > 0) fade--;
    }

sähe das anders aus.

[joerg66 (Gast)]

Hallo,

globale Variablen, die innerhalb einer ISR verwendet werden, müssen 
grundsätzlich als volatile definiert werden:

volatile int fade=0xFF;

Anderfalls ändert sich der Wert bei der Ausführung innerhalb der ISR 
nicht.

[Attila (Gast)]

Wenn ich bitte weiter etwas dilletantisch fragen darf: Wieso versteht 
OCR2 denn -1? Was passiert denn da genau?
Der Timer zählt von 0 bis 255. Also kann OCR2 Werte zwischen 0 und 255 
annehmen.
Ich gebe fade ja den Wert 255 "mit". Dann wird fade bei jedem Intterrupt 
, also wenn Timer 2 bei 255 angekommen ist, eins kleiner. Nach 255 
Durchläufen müsste fade den Wert 0 haben. Was passiert denn dannach?

[Attila (Gast)]

Aus der blinkenden LED auf meinem Schreibtisch schliesse ich dass fade 
seinen Wert wohl ändert. Bei fade++ wird die LED immer heller bis sie 
von dunkel wieder anfängt und bei fade-- wird sie immer dunkler um bei 
ganz Hell wieder anzufangen.

[Stefan B. (stefan)]

http://de.wikipedia.org/wiki/Integer_(Datentyp)
oder C-Buch in den ersten 30 Seiten bei den Datentypen

fade = 1;    // Inhalt von fade: 1 = 0x0001 (bei 16-Bit Integern)
OCR2 = fade; // Inhalt von OCR2: 1 = 0x01
fade--;      // Inhalt von fade: 0 = 0x0000
OCR2 = fade; // Inhalt von OCR2: 0 = 0x00
fade--;      // Inhalt von fade: -1 = 0xFFFF im Zweierkomplement
OCR2 = fade; // Inhalt von OCR2: 255 = 0xFF
             // = niederwertigstes Byte des Zweierkomplements

[Rolf M. (rmagnus)]

Attila schrieb:
> Wenn ich bitte weiter etwas dilletantisch fragen darf: Wieso versteht
> OCR2 denn -1?

Was erwartest du denn? Daß OCR2 sich denkt "Hä, was soll ich denn mit -1 
machen? Das ignoriere ich mal."?

> Was passiert denn da genau?

Nun

> Der Timer zählt von 0 bis 255. Also kann OCR2 Werte zwischen 0 und 255
> annehmen.

Ja.

> Ich gebe fade ja den Wert 255 "mit".

Also in Bits: 0000000011111111

An dein OCR2 werden die unteren 8 Bit davon übergeben,
das ergibt 11111111

> Dann wird fade bei jedem Intterrupt , also wenn Timer 2 bei 255
> angekommen ist, eins kleiner. Nach 255 Durchläufen müsste fade den Wert 0
> haben.

Also 0000000000000000, in OCR2 kommt 00000000.

> Was passiert denn dannach?

fade bekommt den Wert -1, also 1111111111111111. OCR2 bekommt wieder die 
unteren 8 Bit, also in diesem Fall 11111111.

[joerg66 (Gast)]

Welche Rolle spielt eigentlich OCR2 in dem Programm? Für den 
Overflow-Interrupt ist das Register vollkommen irrelevant. Vermute, dass 
der Timer-Compare-Interrupt ebenfalls läuft.

In welchem Modus läuft der Counter? Fast Mode PWM?

[Attila (Gast)]

Oooooooooook!!! Aha! Verstanden! Vielen Dank!

Ich hatte schlichtweg erwartet dass das was ich da geschrieben habe erst 
garnicht funktioniert. Das nach dem Abzählen von 255 meine Led einfach 
nicht mehr leuchtet weil OCR2 bei 0x00 "hängen bleibt". Nicht das der 
OCR denkt" Hä -1? Das ignoriere ich mal!" sondern: " Hä 0-1? Kann ich 
nicht und daher gilt 0-1=0!" Ist der Programierer schliesslich selber 
schuld wenn er den Wertebereich von integer zahlen überschreitet.

Aber jetzt ist alles vorerst klar! Vielen Dank!

[Hc Zimmerer(mizch) (Gast)]

Es passiert dasselbe wie wenn Du hochzählst:  bei 9 geht es mit 0 weiter 
und es gibt einen Übertrag.  So macht es der Timer auch.  Selbst für den 
Übertrag ist gesorgt.  Beim Runterzählen passiert dasselbe:  Nach 0 
kommt 9 und es gibt einen Unterlauf in die nächsthöhere Stelle.

Ob es unter 0 mit -1 oder mit 255 (8 Bit) weitergeht, ist reine 
Betrachtungssache.  Genauer gesagt, ist es durch den Zahlentyp 
vorgegeben.  Ist er unsigned, folgt (bei 8 Bit Breite 255), ist er 
signed, folgt -1.  Das Bitmuster im Zähler ist beide Male dasselbe.  Du 
entscheidest, welche Bedeutung das Bitmuster 0xff hat.

[Jörg T. (joerg66)]

Sorry,

muss mich korrigieren. OCR2 spielt je nach ATmega-Typ doch eine Rolle 
beim Overflow Interrupt. Hatte letztens mit einem ATmega32A zu tun. Hier 
ist TOP immer 0xFF. Beim 324/644 kann TOP verändert werden.