Timer1, Interrupt wird nur einmal ausgeführt

[Searcher]

...

Super Rückmeldung. Auch vielen Dank.

Gruß
Searcher

[Helmut1234]

Aber ist nicht ein Timertick gleich einen Clocktick? Also Zählt der timer nicht durch den Clock?

Gruß
Helmut

[oberallgeier]

Aber ist nicht ein Timertick gleich einen Clocktick? Also Zählt der timer nicht durch den Clock? ..

Das Verhältnis Timerticks zu Clockticks wird durch den entsprechenden Prescaler bestimmt.

..The Timer/Counter can be clocked internally, via the prescaler, or by an external clock source on
the T1 pin. The Clock Select logic block controls which clock source and edge the Timer/Counter
uses to increment (or decrement) its value. The Timer/Counter is inactive when no clock source
is selected. The output from the clock select logic is referred to as the timer clock (clkT1)..

Siehe auch Figure 40. 16-bit Timer/Counter Block Diagram a.a.O.

[Ceos]

Was ich nicht verstehe, warum der Timer Takt dadurch verzögert wird ... eigentlich sollte doch bei einem PreScale > 1 die Nullung des Registers fertig sein, bevor der Timer inkrementiert wird, aber scheinbr glitcht auch der prescaler dabei um einen Takt mit, aber das scheint wohl ein Atmel Problem zu sein

[Helmut1234]

Das Verhältnis Timerticks zu Clockticks wird durch den entsprechenden Prescaler bestimmt.



Siehe auch Figure 40. 16-bit Timer/Counter Block Diagram a.a.O.

Super, danke!

Gruß
Helmut

[Searcher]

Was ich nicht verstehe, warum der Timer Takt dadurch verzögert wird ... eigentlich sollte doch bei einem PreScale > 1 die Nullung des Registers fertig sein, bevor der Timer inkrementiert wird, aber scheinbr glitcht auch der prescaler dabei um einen Takt mit, aber das scheint wohl ein Atmel Problem zu sein

Hallo Ceos,
ich habe etwas an einem ATmega88 herum gemessen.
Prozessortakt 1MHz
TIMER0 im CTC (kein PWM) mit OCR0A als TOP
kein Presacaler (Timertakt = 1MHz) und OCR0A=0
HW-Timerausgang OC0A an PD6 mit COM0A0 toggeln lassen

Zweikanal Oszi mit einem Kanal auf CLKO um Systemtakt zu sehen, den anderen Kanal auf OC0A

Bei jeder steigenden Systemtaktflanke wurde OC0A getoggelt. Es gab dort keine Verzögerungen des Timertaktes. Auch bei OCR0A mit 1 oder höher sah es nicht so aus, als wenn irgendwo Takte beim Timing verloren gingen.

Allerdings wenn man die Portpins im Interrupt toggeln läßt, gehen Systemtakte "verloren". Messungen versuche ich noch "auf die Reihe" zu kriegen, da sie von der Abarbeitungsgeschwindigkeit der ISR abhängen und ich noch keine Regel erkennen kann.

Ich denke, daß der Timer keine irgenwie geartete Verzögerungen beim Rücksetzten zeigt, sondern es bei der Erkennung der ISR-Anforderung zu Verzögerungen kommt.

Oder hab ich das Problem falsch verstanden?

Gruß
Searcher

[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