AVR ASM Interrupt Priorität

hi,
der "normale" weg ist es, zu beginn einer (längeren, kritischen)
interrupt-routine das ie-register zu sichern, interrupts auszuschalten,
befehle ausführen, ie zurückschreiben, interrupts an und feddich.
prioritäten bei irq's gibts afaik nicht, würde bei RISC auch wenig
sinn machen...

Hallo,

ok danke für die schnelle Antwort. Heißt "sichern" auf den Stack
legen und zurückholen(push/pop) oder ist das unsicher?

Hallo,

immer wieder heißt es, der AVR hätte keine Interrupt-Prioritäten. Im
Manual, z.B. zum 2313, liest man jedoch:

"The complete list of vectors is shown in Table 2. The list also
determines the priority levels of the diferent interrupts. The lower
the adress, the higher the priority level. Reset has the highest
priority,...."

Widersprechen sich die beiden Aussagen nicht? Klar ist, daß man als
Anwender an diese Tabelle gebunden ist, außer man bemüht sich in der
Software, das zu ändern. Wie lassen sich denn beide Aussagen in
Einklang bringen?

Gruß

Genau so ist es. Denn der AVR löscht ja bei jedem Eintritt in eine ISR
das Interrupt-Enable-Bit. Nach der ISR wird es wieder gesetzt. Also
gibt es eigentlich eine Unterbrechung der ISR durch eine andere.

Ich habe das aber in einer Anwendung schon benötigt. Also hab ich in
meiner, um einiges längere, Routine das dazugehörige
Interrupt-Enable-Bit gelöscht und dann die Interrupts Global wieder
freigegeben. Am Ende der Routine hab ich das Bit dann wieder gesetzt.
So konnte diese ISR durch eine andere (in diesem Fall höhere ISR)
unterbrochen werden, aber Sie konnte sich nicht selbst aufrufen.

Gruß, Florian

Dann grabe ich mal dieses schöne Thema wieder aus! :-)

Wie sieht es denn bei folgenden Beispiel aus!

Ich habe zum Beispiel einen Overflow Timer Interrupt und ein INT0 
Interrupt, wo ein Taster dran ist. Beim Timer Interrupt wird eine 
Variable hochgezählt. Btw. muss die volatile sein?

So jetzt halte ich den Taster gedrückt. Kommt der Timerinterrupt 
trotzdem noch zum Zuge?

Variable volatile? Ja wenn sie nicht nur im Timer Interrupt sondern auch 
in einem anderen Interrupt oder Hautprogramm benutzt wird.

Sobald ein Interrupt aktiv ist sind alle weiteren Interrupt 
Abforderungen gesperrt. Man muss in der Interrupt Routine ein EI machen 
damit die anderen Interrup Anforderungen den aktuellen Interrupt 
unterbrechen können.

Die Interrupt Priorität hat damit nichts zu tun. Sie regelt die 
Reihenfolge bei gleichzeitigem Auftreten von mehreren Interrupt 
Anforderungen.

> Die Interrupt Priorität hat damit nichts zu tun.

Doch , eigentlich ist sie genau das. Höherpriore Interrupts können 
niederpriore unterbrechen, umgekehrt aber nicht. Das unterstützt der AVR 
nicht, sondern nur:

> Sie regelt die Reihenfolge bei gleichzeitigem Auftreten von mehreren
> Interrupt Anforderungen.

Siehe Posting in diesem Thread etwas weiter oben:
Beitrag "Re: AVR ASM Interrupt Priorität"

>So jetzt halte ich den Taster gedrückt. Kommt der Timerinterrupt
>trotzdem noch zum Zuge?

Schreib doch ein Mini-Testprogramm im AVRStudio und lass es im Simulator 
laufen.

Ich tippe übrigens auf "nein", d. h. der Timerinterrupt wird nicht mehr 
aufgerufen, wenn der INT0-Interrupt auf "pegelgetriggert" konfiguriert 
ist und deshalb bei gedrücktem Taster ständig ansteht. Dieser 
Betriebszustand gibt aber in keinem normalen Programm einen Sinn. Man 
benötigt den pegelgetriggerten INT0 zum Aufwachen aus dem Power Down und 
zur Realisierung eines Single-Step-Modus für Debuggingzwecke, aber ich 
glaube nicht, dass er für sonst noch was gut ist (heißt: etwas, das man 
nicht auch mit einem flankengetriggerten INT0 erledigen kann).

> (heißt: etwas, das man
> nicht auch mit einem flankengetriggerten INT0 erledigen kann).

Wobei Taster am flankengetriggerten Int0 kontraproduktiv sind, es sei 
denn, man will einen Zufallsgenerator bauen. ;-)

~

Da ist der pegelgetriggerte Interrupt aber auch nicht besser.

Ahh so... und was würde man dann für ein Interrupt verfahren nehmen, 
wenn man per Tastendruck eine Aktion machen will. Polling würde ja bei 
kritischen Anwendungen nicht die optimale Lösung sein.

Worauf ich hinaus will ist, der Timer Interrupt ist wichtig aber der 
Tastendruck Interrupt auch. Aber wie könnte man das jetzt lösen, wenn 
zum Beispiel aus mechanischen Gründen der Schalter hängt. Dann würde ja 
die kritische Timer Routine nicht mehr zum zugekommen, wenn ich das 
jetzt richtig verstanden habe!?

Was ist denn für dich "kritisch"?

>Wobei Taster am flankengetriggerten Int0 kontraproduktiv sind, es sei
>denn, man will einen Zufallsgenerator bauen. ;-)

OK, das steht dann auf einem anderen Blatt. Ein denkbarer 
Anwendungsfall: Jemand will herausfinden, wie oft ein Taster prellt. 
Dann könnte er ihn an einen flankengetriggerten INT0 hängen und in der 
ISR nur eine Variable inkrementieren, die sofort auf einen Port 
geschrieben wird.

>Polling würde ja bei
>kritischen Anwendungen nicht die optimale Lösung sein.

Nein, umgekehrt: Über Interrupt ist nicht die optimale Lösung.

Jeder Taster prellt. Wenn er beim Niederdrücken z. B. fünf mal prellt, 
dann gibts zwei Möglichkeiten: 1. Der INT0-Handler wird auch fünfmal 
aufgerufen, weil er so reaktionsschnell ist (das ist ja gerade seine 
Besonderheit). Dies dürfte kaum jemals erwünscht sein. Also muss man 2. 
irgendwie eine künstliche Verzögerung realisieren, die verhindert, dass 
der Interrupt sofort nach dem ersten Pegelwechsel erneut stattfinden 
kann. Eine Delayschleife ist dafür tabu, weil der µC in einer 
zeitkritischen Anwendung nicht ein paar Millisekunden lang blockiert 
sein darf, also muss man es mit einem Timer machen. Toll: Dann sind zwei 
wertvolle Controllerresourcen (ext. Int. + Timer) mit der Abfrage 
eines dämlichen Tasters belegt. Manche hält das nicht davon ab, es 
tatsächlich so zu machen; der Rest erkennt die Vorteile der 
Pollingmethode: Kein externer Interrupt nötig; die Resource Timer kann 
gleichzeitig noch vielen anderen Zwecken dienen; CPU-Last 
vernachlässigbar (wen nicht: Taktfrequenz des µC raufsetzen); so viele 
Taster handelbar, wie man will. Die durch die Tastenabfrage erzeugte 
CPU-Last kann man leicht rechnerisch abschätzen und kommt unter 
realistischen Bedingungen (z. B. FOSC = 8 MHz, Abfrageintervall = 10 ms, 
20 Takte für Tastenhandler) auf Werte weit unter 1 %.

Ah stimmt dran habe ich noch nicht gedacht. Auch wenn ich jetzt nicht 
Timer und INT0 für einen "dämlichen" Taster verschwenden würde!

Da hätte ich noch eine Offtopic Frage! ;-) Nehmen wir an zwei Leute 
arbeiten an einem Projekt. Jeder schreibt seinen Teil. Beide nutzen den 
Timer Overflow Interrupt. Gibt es in einem Programm immer nur einen ISR 
zu dem jeweiligen Interrupt?! Ich würde denke ja, aber wie organisiert 
man dann so ein etwas größeres Programm?! Legt man sowas dann vorher 
durch die Vorplanung fest?

Ist es dann auch sinnvoll alle ISR in eine seperate Datei zu legen?

Ah ich finde das Forum super! ;-) Nicht so ein Kompetenzverlust wie in 
anderen Foren! :-)