Mittlerweile, bin ich mit meinen Forschungen ein Stückchen weiter gekommen....
Eins war schon klar:
OCR2A = 249;
Wird nicht übernommen, wenn direkt danach in den CTC Mode gewechselt wird.
Bisher offen ist, warum dann alles stehen bleibt, auch eine serielle Ausgabe.
Da bin ich jetzt näher dran!
ISR(TIMER2_COMPA_vect) // Timer 2 Interrupt
{
/*
static bool state = LOW;
state = !state;
digitalWrite(pin_T2, state);
*/
PINB = _BV(PINB4); // Arduino Pin 10 schnell toggeln
}
Mit dieser ISR schafft dein Programm wieder die Ausgaben.
Und es wird ein Signal an Pin 10 ausgegeben.
Der Grund für diese Verbesserung:
Da der Timer intern noch mit OCR2A == 0 läuft, da ja OCR2A = 249; nicht zur Wirkung gekommen ist, läuft der Timer mit zu hoher Frequenz.
So hoher Frequenz, dass es nicht für deine ISR reicht.
Meine ist wesentlich schneller, darum läuft der Rest wieder.
Aber wenn man den Vorteiler auf 1 stellt, dann ist meine ISR auch zu langsam.
Warum stoppt die Serielle?
Warum stoppt delay() und millis()?
Die Interrupt Priorität von Timer2 ist höher, als die von der UART und von Timer0
Darum wird der Timer2 Interrupt immer bevorzugt behandelt.
Wenn der nächste Timer2 Interrupt anliegt, bevor der letzte fertig ist, dann haben wir den Salat.
So kommt es dann, dass Serial und delay() versagen.
Und jetzt komme ich zum wunderlichsten Punkt:
Dass der Timer zu schnell läuft, kann man (mit meiner ISR) an Pin 10 messen.
Der Timer läuft mit OCR2A == 0 statt mit OCR2A == 249
Das wunderliche ist aber, dass man beim Auslesen von OCR2A genau die 249 erhält, die man meint auch da rein geschrieben zu haben, der Timer aber unbeirrt mit OCR2A == 0 läuft.
Grrr...
Ich fasse zusammen:
- Arduino Timer Initialisierung für PWM
- CTC Timer Initialisierungsreihenfolge (double buffering von OCR2A)
- ISR zu groß für diese Bedingungen
- Interrupt Priorität
- Falsche Werte beim auslesen von OCR2A
Ich schätze mal, dass ich damit den Zoo der Irritationen/Wunderlichkeiten vollständig beieinander habe.
Habe auch schon einen Namen dafür erfunden:
Ugly Timer Trap