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 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? Danke schon mal^^ MfG Jonathan
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.
Georg schrieb: > 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. Nein. Es gibt bei der AVR-Archtektur den JMP und den RJMP. Der JMP macht einen absoluten Sprung, braucht 3 Takzyklen und ist zwei Flash-Worte lang, der RJMP springt relativ, braucht nur 2 Taktzyklen und ein Wort. Aber die AVRs mit 8k Flash oder weniger haben keinen JMP, da man mit einem RJMP den kompletten Flash erreichen kann. Das ist in der Interrupt-Tabelle berücksichtigt, indem ein Eintrag auf den Prozessoren bis 8k ein Wort groß ist, bei den größeren Prozessoren zwei Worte, um Platz für den JMP zu haben. > Und so einen Befehl gibt es bei jedem Prozessor, mir ist jedenfalls keine > Ausnahme bekannt. Es geht hier aber konkret um einen AVR und darum, wieviel Taktzyklen der Sprung dort genau braucht. Daß andere Prozessoren was ähnliches haben, spielt dafür keine Rolle und hilft bei der Beantwortung der Frage kein bischen. > 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? Sieh dir einfach mal das AVR Assembler Instruction Set an.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.