mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Interrupts beim ATmega


Autor: andre (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Flintstone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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!

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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).

Autor: jonny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schädel...

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: johnny.m (Gast)
Datum:

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

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.