|
Anzeige
|
Verständnisproblem PWM
Gast
#2015183
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--;
}
Gast
#2015337
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.
Gast
#2015359
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.
Gast
#2015360
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?
Gast
#2015371
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. 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 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.
Gast
#2015430
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?
Gast
#2015439
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!
Gast
#2015441
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. 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. Antwort schreiben |
Anzeige
|
