Interrupts beim ATmega

[andre (Gast)]

Hi!

Ich hab mal eine Frage zu den Interrupts und zwar können im ATmega
mehrere unterschiedliche Interrupts gleichzeitig (während der eine
bearbeitet wird) auftreten? Und bis zu welcher Aufruftiefe ist das
möglich? Können gleiche Interrupt-Routinen mehrmals aufgerufen werden,
oder gibt es Prioritäten wie beim 8051?

[Jan M. (mueschel)]

Interrupts haben keine Prioritäten.
hardwaremäßig werden die Interrupts global abgeschaltet, wenn eine
IR-Routine aufgerufen wird und wieder angeschaltet, wenn sie beendet
wird. Das kannst du aber von Hand umgehen. Theoretisch kann auch der
gleiche IR mehrmals gleichzeitig abgarbeitet werden, allerdings wirst
du dann höchstwahrscheinlich Probleme mit dem Stack bekommen, wenn du
da keine Vorkehrungen triffst. Die Aufruftiefe ist im Prinzip nur durch
die maximal mögliche Stackgröße vorgegeben.

[Flintstone (Gast)]

Hallo!

Wie bei allen Prozessoren, die ich kenne, können auch beim ATmega die
Interrupts nur nacheinander abgearbeitet werden. Dass ist auch logisch,
da nur ein Prozessorkern vorhanden ist und zur gleichen Zeit nun mal nur
ein Maschinenbefehl abgearbeitet werden kann.
Ein Interrupt sperrt sich immer selbst. D.h. wird der Intrrupt
ausgelöst, kann er nicht ein weiteres Mal aufgerufen werden, bevor der
Interrupt nicht wieder freigegeben wird. Üblicherweise wird dies durch
ein RETI realisiert. Ein Interrupt kann aber durch einen anderen
Interrupt unterbrochen werden, wenn dieser eine höhere Priorität hat.
Auch beim ATmega gibt es Prioritäten bei den Interrupts. Für den
ATmega8 habe ich mal in der Doku nachgelesen. Im Dokument
"doc2486.pdf" von ATMEL steht auf Seite 10, dass die Interrupts in
Abhängigkeit ihrer Position in der Vektortabelle auch eine Priorität
haben. Je niedriger die Unterbrechungsvektoradresse, desto höher die
Priorität.

@ Jan M.
Interrupts werden nicht automatisch global gesperrt. Es wird nur der
Interrupt gesperrt, desser ISR gerade abgearbeitet wird, bis ein RETI
die ISR beendet.

Gruß
Guido

[johnny.m (Gast)]

@Flintstone:
Das stimmt nicht! Was Jan gesagt hat ist völlig korrekt. Bei Einsprung
in den Interrupt-Vektor löscht die µC-Hardware automatisch das I-Bit im
SREG, so dass ohne manuelles Setzen dieses Steuerbits keine weiteren
Interrupts bearbeitet werden können. Sie können aber nach wie vor
auftreten. Auch das andere was Du schreibst ist Unsinn: Beim Einsprung
in den Vektor wird nämlich (bis auf wenige Ausnahmen, z.B. UART RXC)
auch das auslösende Flag gelöscht und kann durch ein entsprechendes
Hardware-Ereignis sofort wieder gesetzt werden. Wenn man nach
Einsprung in die ISR das I-Bit wieder setzt (durch sei), dann kann ein
Interrupt auch den eigenen Handler unterbrechen! Deshalb sollte man mit
sowas sehr vorsichtig sein. Prioritäten gibt es bei den AVRs nur, was
die Reihenfolge der Abarbeitung gleichzeitig auftretender Interrupts
angeht! Informiere Dich bitte demnächst genauer, bevor Du hier Leute
mit Halbwissen verunsicherst. Es hat zu dem Thema schon eine ganze
Reihe anderer Threads gegeben. Schau mal nach!

[Rahul (Gast)]

@Johnny: Das hast du nett ausgedrückt. Ich wäre nicht so freundlich in
meiner Wortwahl gewesen...

Beim 8051 ergibt die Verteilung von Prioritäten die Möglichkeit, dass
ein Interrupt mit höherer Priorität die Abarbeitung eines Interrupts
mit niedrigerer Priorität unterbricht.
Das kann der AVR nicht. Da haben alle Interrupts die gleiche Priorität.

[johnny.m (Gast)]

Ergänzung zur Frage von andre:
Das Sperren der Interrupts (global durch Löschen des I-Bit im
Statusregister SREG oder lokal durch das entsprechende Interrupt Enable
Bit) bedeutet nur, dass die Bearbeitung der betreffenden Interrupts
gesperrt wird, nicht aber der Interrupt an sich! Die dazugehörigen
Flags werden trotzdem durch die entsprechenden Hardware-Ereignisse
gesetzt. Gibt man dann die Interrupts wieder frei (ohne die Flags
vorher zu löschen) und es sind mehrere Flags gesetzt, dann greifen die
'Prioritäten', was die Reihenfolge der Abarbeitung angeht (Tabelle im
Datenblatt). Und genau das passiert auch, wenn während der Ausführung
eines Interrupt Handlers Interrupt-Flags gesetzt werden. Sobald (beim
reti) die Interrupts wieder global freigegeben werden, können die
inzwischen aufgelaufenen Interrupts abgearbeitet werden, und zwar in
der Reihenfolge entsprechend der Vektortabelle im Datenblatt.

[Karl (Gast)]

SIGNAL ( xyz ) {                    //xyz entspricht einem
Interruptvektor, z.B.  SIG_INTERRUPT0
        Anweisung ( );              //beliebige Anweisung
}

oder alternativ:

INTERRUPT ( xyz ) {
        Anweisung ( );
}

SIGNAL sind nicht unterbrechbar
INTERRUPT hingegen schon

[johnny.m (Gast)]

@Karl:
SIGNAL und INTERRUPT sind veraltet! Besorge Dir mal ne neue AVR-libc!
Abgesehen davon hat bisher niemand was über eine Programmiersprache,
geschweige denn über einen speziellen Compiler gesagt. Es ging ums
generelle Prinzip was die Hardware angeht, und das lässt sich auf
Hochsprachen-Ebene erst recht nicht erläutern! Und der Compiler
macht(e) beim Aufruf mit INTERRUPT auch nix anderes, als direkt am
Anfang der ISR das I-Bit zu setzen (sei).

[jonny (Gast)]

Schädel...

[Bernhard S. (bernhard)]

Interessant ist auch die Verschachtelung von Interrupts, d.h. wenn

ein Interrupt auftritt, sofort durch "SEI" alle Interrupts wieder

zulassen, ist aber mit Vorsicht zu genießen.

Bernhard

[Peter D. (peda)]

Das Ausführen von SEI innerhalb eines Interrupts ist nur eine Krücke und
daher eine sehr gefährliche und kaum beherschbare Krücke.

Sämtliche freigegebenen Interrupts können danach wieder unbegrenzt
zuschlagen bis der Stack überläuft.


Im Gegensatz dazu merken sich Architekturen mit Interruptprioritäten
die Eintrittspriorität und sperren unbedingt alle Interrupts gleicher
oder niederer Priorität.

Dieser Schutz läßt sich softwaremäßig nur durch schmutzige Tricks
aushebeln (indem man durch ein RETI an falscher Stelle das Beenden des
Interrupts vorgaukelt).


Peter

[Peter D. (peda)]

@johnny.m

"Die dazugehörigen Flags werden trotzdem durch die entsprechenden
Hardware-Ereignisse gesetzt."


Stimmt nur fast. Die Pin-Change-Interrupts setzen bei einigen AVRs das
Flag nur, wenn sie freigegeben sind. Man kann also nicht auf Pin-Change
pollen.


Peter

[johnny.m (Gast)]

Jau, danke für die Ergänzung. Hatte ich jetzt nicht bedacht. Ist aber
glaub ich die einzige Ausnahme.