www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Atmega 64 Interrupt Reaktionszeit?


Autor: Kuki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
kann mir vieleicht einer sagen, wie lange die Reaktion auf einen 
Interrupt ist? ich hab´s im Datenblatt nicht gefunden.
(Atmega 64 @ 16MHz)
ich hab mim Oszi mal gemessen, des waren so um die 500ns des erscheint 
mir etwas viel kann das sein?

Danke im Vorraus

Autor: Kuki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
habs soeben gefunden es sind 437,5ns(+evtl. zeit in der ein multi-cycle 
instruktion zuende ausgeführt wir).
oder 4clk für bis in die Interruptroutine, 3 clk für den sprung, und der 
zuvorausgeführte befehl wird zuende ausgeführt.

Autor: Roadrunner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin!
Mir fällt da nur zum ATM8 bzw. 16 (dürfte beim 64 auch so sein) ein, 
dass es 4 Taktzyklen dauert, bis der erste Befehl der Interruptroutine 
ausgeführt wird. In dieser Zeit muss die MCU den PC mit der richtigen 
Sprungadresse des betreffenden Interrupts laden.
Soweit ich mich erinnern kann, stand das im Kapitel zum 
Interrupthandling (liegt ja auch irgendwie auf der Hand).

Gruß Roadrunner

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interrupt Response Time The interrupt execution response for all the 
enabled 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 four 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 completed 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 addition to the 
start-up time from
the selected sleep mode.
A return from an interrupt handling routine takes four clock cycles. 
During these four
clock cycles, the Program Counter (two bytes) is popped back from the 
Stack, the Stack
Pointer is incremented by two, and the I-bit in SREG is set.

Die Reaktionszeit liegt also bei 250ns + Sprung zur Routine, was nochmal 
187ns dauert. Die 500ns kommen also hin.

Der Text steht übrigends etwas versteckt unter AVR CPU Core und nicht 
unter  Interrupts.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu diesen Reaktionszeiten dazu kommen natürlich noch so Sachen wie 
Register retten. Vor allem das Sichern des SREG braucht schon mindestens 
5 Taktzyklen (push r16, in r16, SREG, push r16). Der Unsicherheitsfaktor 
mit dem Multicycle-Befehl, der noch zuende ausgeführt wird, liegt wohl 
je nach Prozessor bei 3 oder 4 Taktzyklen (die längsten Befehle, wie 
z.B. call brauchen 4 oder 5, wenn also nach dem ersten Takt davon der 
Interrupt kommt, wird noch 3 bzw. 4 gewartet).
Falls der Prozessor beim Auftreten des Interrupt im Idle- oder 
Sleepmodus war, kommt noch die Aufwachzeit und eine zusätzliche 
Verlängerung der Antwortzeit dazu. Ich weiß grad nicht auswendig, 
wieviel das ist.

Autor: Kuki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke nochmals
kann mir einer von euch einen controller empfehlen den ich statt dem 
Atmega 64 nehmen könnte? wäre schön wenn die software nicht groß 
umgeändert werden müsste...
und ich sag mal so von der Verarbeitunggeschwindigkeit wäre faktor 10 x 
so schnell wünschenswert.

hab den SX52BD von Parallax im Netz gesehen, habt ihr erfahrungen mit 
diesen?

Autor: Michael (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Google mal nach Atmega64-HS. Der soll angeblich mit 200MHz laufen. Ist 
pin- und funktionskompatibel.

Autor: Hansi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Muahahahaha....

Autor: Kuki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
von einem Atmega 64 mit 200 MIPS...

Autor: Kuki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...träum ich auch :-)

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interrupt-Antwortzeiten sind immer recht lang. Darf man fragen, warum 
die Reaktionszeit so kurz sein muss?

Autor: Kuki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wollte auf mit den Interrupts den I2C-Bus mit 400 kHz tracen... da aber 
bei steigender Flanke der CLK innerhalb von 600ns auslesen muß sind die 
500ns an Interrupt-Antwortzeit ziemlich lang...

ich habe mir mal wie oben beschrieben den SX52BD-100 angeschaut, der 
hätte nur 30ns Interruptreaktionszeit... leider habe ich die Hardware 
scho fertig...
werde wohl aber bald auf was schnelleres wie den Atmega64 umsteigen 
müssen, den der ist "etwas" überfordert...

Autor: Der Techniker (_techniker_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alternative Polling?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder das Hadware I2C Interface verwenden ?

Autor: Kuki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja mit polling habs auch scho probiert und hab eine Max. Abtastrate von 
800 kHz aber laut spec ist die "high" zustand vom Clk für min 600 ns 
d.h. ich müßte mit 1600 MHz abtasten... ist glaub ich nicht möglich 
nochmal soviel ausm controller rauszuholen... man bedenke d.h. alle 10 
Clk bei 16MHz den Bus abtasten... in dieser zeit sollten die daten ja 
auch weggeschickt werden...

Nochmals zu Interrupts... wenn ein interrupt ausgelöst wird push der MCT 
den Program Counter... geschieht des im Hintergrund oder ist da der MCT 
dann für meine Befehle blockiert?

Autor: Kuki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hardware I2C interface... funktioniert auch nicht, da ich das Interface 
nur als Slave verwenden könnte. Weil der Trace möglichst passiv ablaufen 
sollte!

und der Slave reagiert dann nur auf die Eingespeicherte Adresse...

oder gibt es ein möglichkeit auf das Bus Interface Unit zuzugreifen?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt, das I2C Interface ist zu gut. Bei einfachen AVRs wie dem 
tiny2313 mit USI funktioniert das aber wunderbar. Damit habe ich einen 
einfachen I2C Sniffer realisiert der mir alle Aktivitäten auf dem Bus am 
PC anzeigt.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<<Nochmals zu Interrupts... wenn ein interrupt ausgelöst wird push der 
MCT
den Program Counter... geschieht des im Hintergrund oder ist da der MCT
dann für meine Befehle blockiert?>>

Wie vermutet, war Deine Forderung nach einem schnellem µP nur der 
Ausdruck dafür, daß Du keine Ahnung hast. Wenn Du obige Frage nicht 
selbst beantworten kannst, bringe erst einmal eine LED zum Blinken.

Autor: Kuki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ich nicht so viel Ahnung habe, wie andere hier stimmt !!!
aber seit 2 Jahren verschiedene Controller in ASM zu programieren nenne 
ich nicht unbedingt "keine Ahnung"
das problem ist das jeder MCT anders ist... habe bisher vorallem mit 
welchen mit nem C166 Core zu tun gehabt...
und da ich versuche so wenig wie möglich anzunehmen, wenn nix im 
Datenblatt steht, oder ich es nicht finde, frage ich lieber nach...
so wie ich des sehe, blockiert der Interrupt den MCT für min 435ns das 
ist ziehmlcih lang, aber es könnte auch sein, das des Pushen im 
Hintergrund abläuft..

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.