Interrupt Response Time: Wie lange genau?

Die Response-Time kann um die Taktzyklen länger werden,
die ein gerade ausgeführter Befehl länger ist, als einen
Taktzyklus.

Wenn du schnelle Reaktionen brauchst, verbietet sich natürlich
ein Sleep-Modus.

Ansonsten können nur noch andere Interrupt-Routinen, die
dem zeitkritischen Interrupt zufällig zuvorkommen die
Reaktionszeit verlängern.

... Oder andere Programmabschnitte, in denen Interrupts
zeitweise mit di ... sei global gesperrt werden.

Okey also alles vermeidbare Verzögerungen.
Angenommen ich habe nur INT0 aktiviert und der Controller befindet sich 
gerade in einer Endlosschleife und schläft nicht, dann müsste er immer 4 
bzw. 5 Takte brauchen, bis er im Interrupt-Handler ist (oder auch 
länger, im Datenblatt steht ja "four clock cycles
minimum "?) .. ?

Jonathan K. schrieb:
> Im Datenblatt vom mega8 steht: "The interrupt execution response for all
> the enabled Atmel ® AVR ® interrupts is four clock cycles
> minimum. After four clock cycles, the Program Vector address for the
> actual interrupt handling
> routine is executed. During this 4-clock cycle period, the Program
> Counter is pushed onto the
> Stack. The Vector is normally a jump to the interrupt routine, and this
> jump takes three clock
> cycles. If an interrupt occurs during execution of a multi-cycle
> instruction, this instruction is com-
> pleted before the interrupt is served. If an interrupt occurs when the
> MCU is in sleep mode, the
> interrupt execution response time is increased by four clock cycles.
> This increase comes in addi-
> tion to the start-up time from the selected sleep mode."
>
> Hier steht, dass der AVR mind. 4 Takte braucht, bis er beim Ausführen
> der Interrupt Routine ist. Wann braucht der AVR aber länger? Einmal wenn

Nein, steht da nicht. ;-)

> er im Schlafmodus ist und wenn ein Befehl, der mehrere Takte braucht,
> ausgeführt wird .. war das alles? Oder kann der AVR auch "zufällig" mal
> 4 und wann anders unter gleichen Bedingungen 6 Takte brauchen?

Unter gleichen Bedingungen braucht er immer gleich lange. Tatsächlich 
immer gleiche Bedingungen zu haben ist für nicht-triviale Programme, 
ähh, nicht-trivial.

Also in der Doku steht u.a.:

- 4 Takte bis es überhaupt losgeht (in der Zeit Push vom PC), immer 
gleich lang
- dann Ausführung Interrupt Vector, der normalerweise ein Jump ist - 
braucht nochmal 3 Takte, immer gleich lang
- wenn der Interrupt auf eine multi-cycle Instruction traf wird die erst 
fertig gemacht, weitere 1 - n Takte, nicht immer gleich lang
- Sleep-Geraffel (hab ich nicht nachgesehen)

Dazu kommt noch:

- benutzt das Programm mehrere Interrupts (Prioritäten!) oder disabled 
Interrupts für einige Zeit, weitere n (können richtig viele sein, hängt 
vom konkreten Code ab) Takte, nicht immer gleich lang
- die Interrupt Routine hat am Anfang Standard-Code zum Retten der 
Register auf den Stack, wenn man die in C schreibt ist das sogar 
ziemlich viel, weitere ein, zwei Dutzend Takte bis wirklich etwas 
interessantes passiert, immer gleich lang

D.h. einerseits ist da nix mit 4 oder 6 Takten, das dauert immer etwas 
länger, andererseits, je nach konkretem Programm, das kann noch viel 
länger dauern und ist dann auch nur als Worst-Case vorhersagbar.

Dieses Zeug ist halt kompliziert.

OK. Meiner Ansicht nach, bezieht sich das "minimal" hier darauf, dass 
vier Zyklen gebraucht werden, um den momentanen PC auf den Stack zu 
bringen.

Im fünften Zyklus, wird der Code an der Adresse ausgeführt, die dem 
Interrupt zugeordnet ist - was in der Regel ("normally") ein JMP ist - 
aber nicht zwingend. D.h. dieser Maschinencode ist streng genommen schon 
ein Teil des Interrupt-Handlers.

Es ist aber nicht festgeschrieben, was da für ein Befehl steht. Könnte 
auch ein JSR sein oder was anderes. Dessen Ausführungszeit muss nun 
entweder zu der Latenz dazu gezählt werden oder zu der Ausführungszeit 
der ISR.

Deswegen also dieses "minimal". Ein wenig bürokratisch - aber doch 
eigentlich korrekt.

Er wird jedenfalls nicht irgendwie unbestimmbar länger als 4 Zyklen 
brauchen. Jede mögliche Verzögerung ist definiert.

Was die anderen Antworter hier schrieben ist jedenfalls richtig. Es 
kommt halt darauf an, welche Nebenumstände Du einbeziehst.

Jasch schrieb:
> dann Ausführung Interrupt Vector, der normalerweise ein Jump ist -
> braucht nochmal 3 Takte, immer gleich lang

Hab ich oben nur net reingerechnet, da ja diesen Befehl ja selbst im 
Code stehen hab.


Jasch schrieb:
> Dieses Zeug ist halt kompliziert.

Naja wenn mans einmal verstanden hat ists total easy^^


Ich war nur unsicher, was denn genau mit "minimum" gemeint ist. Also 
bedeutet es nur, dass der AVR im Idealfall immer 4 Takte braucht, und 
wenn was dazwischen kommt (z.B. anderer Interrupt) braucht er 
dementsprechend länger, richtig so?

EDIT:
Klaus schrieb:
> Er wird jedenfalls nicht irgendwie unbestimmbar länger als 4 Zyklen
> brauchen.

Das ist, was ich wissen wollte, dann hat sich das ja geklärt, wenn dem 
keiner widerspricht :)

Jonathan K. schrieb:

> Also
> bedeutet es nur, dass der AVR im Idealfall immer 4 Takte braucht,

"Im Idealfall immer" ist potentiell ein Widerspruch in sich.

Das ist einfach das Minimum - für den Fall, dass der Interrupt genau 
dann gültig wird, wenn gerade ein Befehl fertig ist. Mehr ist damit 
nicht gesagt.

Klaus schrieb:
> Jonathan K. schrieb:
>
>> Also
>> bedeutet es nur, dass der AVR im Idealfall immer 4 Takte braucht,
>
> "Im Idealfall immer" ist potentiell ein Widerspruch in sich.

War vielleicht blöd ausgedrückt, ich meinte mit "immer", dass der AVR im 
Idealfall (=kein anderer Interrupt höherer Priorität, usw.) jedes mal 
seine 4 Takte braucht (statt einer variablen Zahl an Takten).

Genau: 4, oder 5 Takte - so ist meine Erfahrung.

Man müsste mal ins Datenblatt schauen, aber vom Pegelwechsel
am INT0-Eingang bis zum Setzen des Interrupts dürfte es auch
noch ein paar (konstante) Takte dauern.

Meist stört das aber nicht, solange es reproduzierbar ist.

Wenn du ein Experimentier-Bord und ein Skop hast, kannst du
dir das schön ansehen.
Bei wirklich zeitkritischen Anwendungen sollte man das auf
jeden Fall machen.

Jonathan K. schrieb:
> Klaus schrieb:
>> Jonathan K. schrieb:
>>
>>> Also
>>> bedeutet es nur, dass der AVR im Idealfall immer 4 Takte braucht,
>>
>> "Im Idealfall immer" ist potentiell ein Widerspruch in sich.
>
> War vielleicht blöd ausgedrückt, ich meinte mit "immer", dass der AVR im
> Idealfall (=kein anderer Interrupt höherer Priorität, usw.) jedes mal
> seine 4 Takte braucht (statt einer variablen Zahl an Takten).

Naja. Das ist halt immer so ein Problem mit der Sprache. :-)

Wenn Du nun "im Idealfall immer" durch "im Idealfall jedesmal" ersetzt 
entschärft das Problem nicht. Das ist eigentlich das selbe.

Es geht darum, dass Du bei n über die Zeit gleichverteilten Interrupts 
mit einer Chance von ca. 1/n den Zeitpunkt triffst, bei dem genau der 
Fall eintritt. Dabei ist noch nicht eingerechnet, dass unterschiedliche 
Befehlslaufzeiten auftreten.

Wenn Du aber partout eine Antwort will, würde ich mal so übern Daumen, 
die Latenz auf etwa 4,4 Zyklen schätzen.

Wenn Du erstmal nur grundsätzliche Informationen willst, dann muss das 
so hinreichen.

Ein recht lehrreiches konkretes Problem ist die Video-Erzeugung mit dem 
AVR. Habe ich nie versucht, weil ich nie soviel Kaffee bevorraten 
konnte, wie ich für nötig hielt. :-) Lies Dir das mal durch (Findest Du 
hier über FBAS oder BAS).

Ich will es nochmal anders versuchen:

Die Aussage "minimal" ist nicht gleichbedeutend mit "im Durchschnitt" 
oder "in der Regel" oder "meistens".

Es heisst nur, dass da eine absolute untere Grenze existiert.

Hallo,

eigentlich interessiert ja sowieso nicht, wann der Interrupt Vector 
ausgeführt wird (meistens ein JMP-Befehl), sondern wann eine Reaktion 
auf das Interrupt-Ereignis erfolgt, z.B. das Einlesen eines Bytes vom 
UART. Da kommen dann zur Minimalverzögerung von 4 Takten noch die 
Taktzahl des längsten Befehls, der vorkommen kann, plus JMP-Befehl oder 
was da sonst steht, plus die Push-Befehle zum Sichern der benutzten 
Register und was noch benötigt wird bis zum Input-Befehl. Da kann man 
i.d.R. nur eine Worst Case Berechnung machen. Eine Best Case Rechnung 
auch, aber die ist selten von Interesse ausser um die mögliche Variaton 
abzuschätzen.

Georg

Die mehrfache Wiederholung von jmp hier finde ich seltsam, es wird 
auch nicht dadurch besser, dass es so im Datenblatt steht. Der ATmega8 
kann gar kein jmp (3 Takte), sondern nur ein rjmp mit 2 Takten, und 
der reicht ihm für den gesamten Programmspeicherbereich.
Und auch größere Controller werden für die ISR in der Regel mit einem 
rjmp auskommen.

S. Landolt schrieb:
> Die mehrfache Wiederholung von jmp hier finde ich seltsam

Ein jmp ist ein jmp ist ein jmp, egal wie der im speziellen Assembler 
gerade heisst. Und so einen Befehl gibt es bei jedem Prozessor, mir ist 
jedenfalls keine Ausnahme bekannt.

S. Landolt schrieb:
> Der ATmega8
> kann gar kein jmp (3 Takte)

Das ist jetzt allerdings hochgradig seltsam - woher weisst du, dass der 
Befehl 3 Takte braucht, wenn ihn der Prozessor garnicht kennt?

Georg

Die Ausgangsfrage bezog sich auf einen ATmega8, dieser gehört zur 
8-bit-AVR-Familie. Die Informationsquelle hierfür ist das 'Atmel AVR 
8-bit Instruction Set Manual'.

Der Einwand von S. Landolt ist zwar sachlich zutreffend,
für die Frage des TO aber, dem tieferen Sinne nach, unwichtig.

Es wird da nur ein Detail quantitativ präzisiert;
auf den qualitativen Aspekt hat das keine Auswirkung.

Das Wesentliche war die Frage nach der Determiniertheit der minimalen 
Latenz.

Wenn man nur einen Interrupt nutz kann man auch ohne den Sprung in der 
Interrupttabelle auskommen. Auch sonst reicht da i.A. die 2 Zyklen 
variante rjmp. Ob das auch so mit einem C Compiler geht ist aber was 
anderes.

Zu den oben genannten Zeiten kommt ggf. noch 1 Zyklus oder so dazu, bis 
das Interrupt flag überhaupt auslöst. Das hängt von der Quelle ab.

Wenn es auf eine reproduzierbare Reaktionszeit ankommt, ist es sogar ein 
vorteil, wenn der µC davor im Idel mode ist, dann hat man zwar ein paar 
Zyklen mehr, aber dafür keinen Befehl der erst noch zu Ende ausgeführt 
werden muss. Damit ist die Reaktionszeit dann reproduzierbar, im Rahmen 
des Taktes.

Die isr braucht ggf. auch noch am Anfang das Retten des Status registers 
- vorher kann man nur eingeschränkte Aktionen machen.