Timer1, Interrupt wird nur einmal ausgeführt

[Ceos]

valider Punkt, das habe ich so noch garnicht betrachtet

in dem konkreten Fall reizen wir den Controller aber auch bis ans limit aus, weil er bis auf diesen glitch absolut zuverlässig (vorhersagbar) arbeitet und genau den Zweck bedienen kann.

[Searcher]

Hallo,

Eine Messung weiter:

Aus dem ATmega32 Datenblatt zum TIFR1 Register:

• Bit 4 – OCF1A: Timer/Counter1, Output Compare A Match Flag
This flag is set in the timer clock cycle after the counter (TCNT1) value matches the Output
Compare Register A (OCR1A).

Für mich ist die Formulierung "in the timer clock cycle" nicht genau.
ATmega88:
Ich habe wieder den CTC modus mit OCR1A als TOP und lasse OC1A bei TOP toggeln.
Systemtakt und Timertakt gleich mit einem MHz.
Außerdem wird über den Compare1A Interrupt der PC0 Pin über eine ISR softwaremäßig getoggelt; OCR1A Comparewert auf 12.
Im Simulator ist nach Auftreten des Interrupts der PC0 mit dem siebten Takt getoggelt (sbi asm Befehl ins PINC ausgeführt)

Ich gehe davon aus, daß OC1A ohne Verzögerung bei Compare Match getoggelt wird.
Vergleich mit Oszi zeigt, daß der PC0 bei Prescaler=1 acht Takte nach OC1A getoggelt wird.

Bei Prescaler 8, 64, 256, 1024 wird PC0 neun Takte nach OC1A getoggelt.

Das Compare Match Flag OCF1A scheint also wirklich obigem Zitat folgend nicht mit, sondern nach dem Compare Match gesetzt. Allerdings wird es nicht, wie man vermuten könnte, einen Timertakt danach, sondern in diesem Fall nur ein oder zwei Systemtakte nach dem Comparematch gesetzt und auch sofort das Interrupthandling gestartet.

Keine Ahnung, wie das nun einzuordnen ist. Wird der ISR-Start nicht gestört, dürfte das erzeugte Timing über die Compare Match Interrupts immer gleichmäßig sein.

Gruß
Searcher

[Ceos]

Wir hatten auch den Timer zur Erzeugung definierter Pulse verwendet und dabei diesen glitch erlebt, wir brauchten halt einen timer mit variabler Pulsbreite und Frequenz