Verständnisfrage Interrupts

S. Landolt schrieb:
>> Kann eine ISR generell "unterbrochen" werden durch andere Interrupts?
> Prinzipiell ja, indem man in der ISR durch ein sei die Interrupts
> global wieder freigibt - man sollte aber sehr genau wissen, was man da
> tut.

Nach meiner Erfahrung funktionieren "nested Interrupts" genauso wie 
einfache Interrupts, man braucht nur mehr Platz auf dem Stack. Wüßte 
nicht, was da anders wäre.

Gruß Klaus (der soundsovielte)

HildeK schrieb:
> Max Wo schrieb:
>> Kann eine ISR generell "unterbrochen" werden durch andere Interrupts?
>
> Kann, wie aus den Antworten hervorgeht, wenn man das gezielt will. Ohne
> weitere Maßnahmen wird meines Wissens nur ein weiterer IRQ gespeichert
> und nach Beenden der ersten ISR ausgeführt.

Das ist nicht richtig. Bzw. nur halb. Von jeder Interrupt-Quelle wird 
nur ein Interrupt gespeichert.

Jeder Interrupt hat ein Pending-Bit (abfragbar als Interrupt-Flag). Wenn 
das globale Interrupt-Enable Flag gesetzt ist (per SEI) wird die 
zugehörige ISR ausgeführt. Wenn mehrere Falgs gleichzeitig gesetzt 
werden, das mit der höchsten Priorität (niedrigste Vektor-Adresse) 
zuerst.

Immer wenn das globale Interrupt-Enable Flag gesetzt wird, wird noch 
genau ein weiterer Befehl ausgeführt bevor die Pending Flags honoriert 
werden. Normalerweise wird beim Einsprung in eine ISR das Bit 
automatisch gelöscht und beim Verlassen automatisch wieder gesetzt. 
Daraus resultiert das beschriebene Verhalten.

So lange noch Interrupts Pending sind, wird das System also die 
zugehörigen ISRs ausführen (immer mit einen Befehl dazwischen). Wenn ein 
Interrupt erneut ausgelöst wird, während er noch Pending ist, dann geht 
das Event verloren. Es gibt ja nur ein Bit pro Interrupt.

HildeK schrieb:
> Kann, wie aus den Antworten hervorgeht, wenn man das gezielt will. Ohne
> weitere Maßnahmen wird meines Wissens nur ein weiterer IRQ gespeichert
> und nach Beenden der ersten ISR ausgeführt

Das ist richtig für den Fall, daß während der ISR derselbe Interrupt 
noch einmal auftritt und das Interruptflag bereits gelöscht ist, 
ansonsten landet auch schon der zweite Interrupt im Nirvana. Dann ist 
aber der Programmierer dringend reif für eine Fortbildung!

Gruß Klaus (der soundsovielte)

c-hater schrieb:
> Es besteht die Gefahr, sich selbst zu "nesten". Dann wächst der Stack
> bis BUMM.

Kennst Du einen Prozessor, dessen Interruptcontroller das ermöglicht? 
Das täte mich gewaltig interessieren. Kann mir nur schlecht vorstellen, 
daß ein Hersteller das Vorstellen einer solchen Mißgeburt finanziell 
üerlebt.

Der einzige Trick dazu wäre m.E., in der ISR die eigene 
Interruptpriority herunterzusetzen. Das ist dann aber Vorsatz!

Gruß Klaus (der soundsovielte)

Klaus S. schrieb:
> c-hater schrieb:
>> Es besteht die Gefahr, sich selbst zu "nesten". Dann wächst der Stack
>> bis BUMM.
>
> Kennst Du einen Prozessor, dessen Interruptcontroller das ermöglicht?
> Das täte mich gewaltig interessieren. Kann mir nur schlecht vorstellen,
> daß ein Hersteller das Vorstellen einer solchen Mißgeburt finanziell
> üerlebt.

Meines wissen alle Pics.
Da muss, wie wahrscheinlich auch bei vielen anderen, das zugehörige 
IR-Flag explizit gelöscht werden. Da is es dann dir überlassen, ob Du 
das am Anfang o. am Ende der Routine machst.
Und wenn Du es mal wirklich krachen lassen willst, löscht Du es einfach 
gar nicht. ;)

Teo D. schrieb:
> Meines wissen alle Pics.
> Da muss, wie wahrscheinlich auch bei vielen anderen, das zugehörige
> IR-Flag explizit gelöscht werden. Da is es dann dir überlassen, ob Du
> das am Anfang o. am Ende der Routine machst.
> Und wenn Du es mal wirklich krachen lassen willst, löscht Du es einfach
> gar nicht. ;)

Ich kenne die PICs nur von den paar Malen, wo ich ihr Datenblatt gelesen 
habe und sie als zu klein aussortiert habe. Aber ein beliebig 
herausgegriffenes sagt:
--------------------
The PIC18(L)F2X/4XK22 devices have multiple
interrupt sources and an interrupt priority feature that
allows most interrupt sources to be assigned a high or
low priority level (INT0 does not have a priority bit, it is
always a high priority). The high priority interrupt vector
is at 0008h and the low priority interrupt vector is at
0018h. A high priority interrupt event will interrupt a low
priority interrupt that may be in progress.
----------------------
Der hat also sowieso nur zwei Interruptvektoren und sowas wie Rekursion 
geht damit nicht, wie nach meinem Veständnis das Datenblatt klar und 
deutlich aussagt. Und lösche ich das IR-Flag nicht, wird die ISR einfach 
wieder und wieder aufgerufen. Das ist der normale vorhersehbare und 
einplanbare Programmverlauf, da "kracht" gar nix.
Legt man sein Programm passend an, kann man in der Low-Prio-ISR sein 
Hauptprogramm unterbringen (loop() im Arduino-Sprech) und spart eine 
Rücksprunganweisung.

@Klaus S
Achne, dämlich Haarspalterei und Themen schön verwoben, das mach mal 
alleine bitte.

c-hater schrieb:
>> Kennst Du einen Prozessor, dessen Interruptcontroller das ermöglicht?
>
> AVR8 (klassisch)

Das muß ich nachprüfen. So einen Schwachpunkt hatte ich nicht erwartet. 
Ausprobiert habe ich selbst, ob das Verschachteln funktioniert, da das 
Datenblatt wenig darüber aussagt. Da das einwandfrei ablief, habe ich 
nicht weiter getestet. Auch in dem auf mc.net vorrätigen Artikel steht 
nur Wachsweiches. Wenn das aber so ist, muß ich wohl schnell wieder zum 
8051 zurückkehren, wenn ich etwas kleineres als den XMC1000 oder STM32 
brauche.

MaWin schrieb:
> EAF schrieb:
>> Vor Jahrzehnten wurde schon festgestellt, dass Rekursionen in allen
>> Fällen auf Iterationen zurückgeführt werden können.
>
> Was das Ressourcenproblem nicht löst.

Doch.

Zumindest in den Fällen, wo pro Schritt keine weiteren Resourcen 
benötigt werden.
Wenn man dann Rekursion verwendet, wird pro Stufe ein Funktionsaufruf 
ausgeführt, der Rücksprungadresse, Stackpointer, Framepointer etc. auf 
den Stack legen muß.
Wenn man die Rekursion durch Iteration ersetzt, ist das nicht nötig.

Wolfgang schrieb:
> Klaus S. schrieb:
>> Kennst Du einen Prozessor, dessen Interruptcontroller das ermöglicht?
>
> Die Möglichkeit besteht bei jedem Controller, wenn der Interrupt durch
> einen Pegel ausgelöst wird und man in der Interruptroutine den Interrupt
> direkt wieder freigibt.

Alle Controller (mit Ausnahme des AVR), mit denen ich verschachtelte 
Interrupts  programmiert habe, hatten im Datenblatt eindeutig stehen, 
daß nur Interrupts höherer Prio eine ISR unterbrechen können. Auch die 
PICs machen es so. Man kann sich also maximal sein Hauptprogramm auf 
Geschwindigkeit 0 herunterregeln, ansonsten laufen die Interrupts brav 
weiter wie sie programmiert wurden. Und der Stack bleibt sauber bis der 
Stom ausfällt.

MaWin schrieb:
> Klaus W. schrieb:
>> Doch.
>>
>> Zumindest in den Fällen, wo pro Schritt keine weiteren Resourcen
>> benötigt werden.
>
> Was natürlich praktisch niemals vorkommt.
>
> Ein Algorithmus, der und begrenzt lange läuft und trotzdem begrenzt
> Speicher braucht und sinnvolle Arbeit leisten kann. Also auch keinen
> ungewünschten Int-Überlauf produzieren kann, weil das ja äquivalent zu
> einer fehlgeschlagenen Alloziierung eines größeren Int ist.
> Was wäre das zum Beispiel?

Soll das "unbegrenzte" statt "und begrenzte" heißen? Bedeutet das, dass 
ihr noch über die
EAF schrieb:
> infinite Rekursion
redet?

Klaus S. schrieb:
> Nach meiner Erfahrung funktionieren "nested Interrupts" genauso wie
> einfache Interrupts, man braucht nur mehr Platz auf dem Stack. Wüßte
> nicht, was da anders wäre.

Der große Unterschied ist, daß der AVR Interruptprioritäten nicht in 
Hardware unterstützt. Daher kann sich ein Interrupt unbegrenzt selber 
unterbrechen nach einem SEI. Z.B. beim Levelinterrupt, EEPROM, UART, I2C 
geht das voll in die Hose. Die müssen sich vor dem SEI immer erst selber 
disablen. Die Interruptproblematik habe ich schon 1997 bei einem 
AVR-Seminar bemängelt, stieß aber auf taube Ohren.

Ganz anders die 8051. Z.B. der AT89LP51 hat 2 Prioritätsbits je 
Interruptquelle, d.h. ein Interrupt kann sich default nicht selber 
unterbrechen. Um sich selber zu unterbrechen, muß ein Interrupt seine 
eigene Priorität erhöhen. Das kann er 3-mal, dann ist Schluß. Also max 4 
Instanzen sind möglich. Insbesondere für jitterarme Timerinterrupts 
machen sich die Prioritätsbits hervorragend (Audio-PWM, Steppermotoren 
usw.).

Die AVRs wurden bestimmt nicht wegen ihrer rückständigen Interruptlogik 
populär, sondern wegen ihrer einfachen Anwendung (interner Takt, Reset, 
ISP, weiter Spannungsbereich, freier und gut benutzbarer GCC (WINAVR).
Ich denke mal, der WINAVR war sogar der Hauptpunkt, den AVR populär zu 
machen. Ich hab den auch noch lange nach 2010 benutzt.

MCUA schrieb:
> Höchste Zeit, dass MCH das mal ändert.

Es gibt zaghafte Ansätze. Bei den neueren AVRs kann man eine 
Interruptquelle hochsetzen. Auch kann man die low-level Interrupts als 
Round-Robin konfigurieren, d.h. jeder kommt mal dran.

c-hater schrieb:
> AVR8 (klassisch)
> Wobei die eben gerade keinen Interruptcontroller im üblichen Sinne
> besitzen.

Peter D. schrieb:
> Der große Unterschied ist, daß der AVR Interruptprioritäten nicht in
> Hardware unterstützt. Daher kann sich ein Interrupt unbegrenzt selber
> unterbrechen nach einem SEI. Z.B. beim Levelinterrupt, EEPROM, UART, I2C
> geht das voll in die Hose. Die müssen sich vor dem SEI immer erst selber
> disablen. Die Interruptproblematik habe ich schon 1997 bei einem
> AVR-Seminar bemängelt, stieß aber auf taube Ohren.

Ich würde gern an dem Thema dranbleiben, da es mir doch einen (weit 
verbreiteten) Sonderfall darzustellen scheint und weil ich etwas 
dazulernen möchte.

Im Interrupttutorial steht der intelligente Satz, daß verschachtelte 
Interrupts unwichtig sind, da 99,9% es nicht brauchen. Danach wäre das 
ganze mc.net überflüssig, da bei 3000 eingetragenen Benutzern und der 
10fachen Menge Gästen die 0,1% der deutschsprachigen Bevölkerung nicht 
erreicht sind.
Im speziellen AVR-Interrupttutorial steht vorsichtshalber gar nichts 
dazu.

Für mich sind verschachtelte Interrupts die einfachste Methode, 
prioritätsgesteuertes "preemptive multitasking" hinzubekommen. Scheduler 
und Dispatcher sind in Hardware vorhanden. Programmiert man nicht wie in 
DOS-Zeiten (resp. nach SPS-Muster), sondern ereignisgesteuert wie in 
Windows, gibt es m.E. nichts Einfacheres.
(Siehe auch "Super Simple Tasker" von Rob Ward und Miro Samir.)

Für den AVR hieße das, das man seine eigenen Prioritäten dadurch 
vergeben kann, daß man vor dem GlobalInterruptEnable alle Interrupts 
niedriger Prio ausmaskiert. Da wäre meine Frage, ob da, abgesehen von 
der Fummelei mit verteilten Bits, auch noch Timingprobleme durch 
verzögerte Weitergabe der Flaginformation entstehen. Die Verzögerungen 
durch das Löschen der Enablebits möge mir bitte,bitte,bitte keiner 
erklären. Macht man prioritätsgesteuertes Multitasking, muß nicht jede 
ISR so kurz wie möglich sein.

Weiß da jemand etwas Näheres?

Gruß Klaus (der soundsovielte)

Klaus S. schrieb:
> Für den AVR hieße das, das man seine eigenen Prioritäten dadurch
> vergeben kann, daß man vor dem GlobalInterruptEnable alle Interrupts
> niedriger Prio ausmaskiert.

Für die ganz Genauen sollte das heißen:
Für den AVR hieße das, das man seine eigenen Prioritäten dadurch 
vergeben kann, daß man vor dem GlobalInterruptEnable alle Interrupts 
niedrigerer_ und _gleicher Prio ausmaskiert.

Klaus S. schrieb:
> Für mich sind verschachtelte Interrupts die einfachste Methode,
> prioritätsgesteuertes "preemptive multitasking" hinzubekommen. Scheduler
> und Dispatcher sind in Hardware vorhanden. Programmiert man nicht wie in
> DOS-Zeiten (resp. nach SPS-Muster), sondern ereignisgesteuert wie in
> Windows, gibt es m.E. nichts Einfacheres.
> (Siehe auch "Super Simple Tasker" von Rob Ward und Miro Samir.)

Ja.

Und jetzt diskutierst du bitte den Sinn von preemptive Multitasking auf 
AVRs.

Oliver

c-hater schrieb:
> Das Gesamtwerk agiert dann im Endeffekt genauso, wie mit "präemptiven
> Multitasking", bloß viel, viel effizienter...

Ich meinte, ausreichend darauf hingewiesen zu haben (15:38 heutigen 
Datums):
"Für mich sind verschachtelte Interrupts die einfachste Methode, 
prioritätsgesteuertes "preemptive multitasking" hinzubekommen."

Ein FlameWar über Worte ist nicht meine Baustelle. Im Übrigen fand Linus 
Pauling schon vor Jahren Leute "crazy", die einen Laser mit einem PC 
steuern wollen. Ich gehöre demnach ohnehin schon zur Gruppe der "crazy 
people", wie andere Firmen auch. Jeder hat das Recht, sich zum Narren zu 
machen, wie er möchte und Menschen mit begrenztem Horizont stehen an 
jeder Straßenecke. Ich will mich da auch gar nicht ausnehmen. Deswegen 
interessieren mich ja die Fakten, aber nicht die alternativen nach 
Trump-Manier.


Oliver S. schrieb:
> Und jetzt diskutierst du bitte den Sinn von preemptive Multitasking auf
> AVRs.
Hier ein kleines Beispiel aus den Tiefen des Internets, sogar ganz 
feudal mit EDF-Scheduling:
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.489.2370&rep=rep1&type=pdf
Den Sinn darfst Du Dir dazuerfinden. Die ganze uns bekannte Welt hat 
keinen eingebauten Sinn, außer für Theologen. Ich bin keiner. Noch 
Fragen?

Mit einem amüsierten Lächeln
Klaus (der soundsovielte)
P.S.Ist das jetzt eher drollig oder trollig? Sorry, couldn't resist.

Klaus S. schrieb:
> P.S.Ist das jetzt eher drollig oder trollig? Sorry, couldn't resist.

Nö, nur Posing, du ><(()°> .... Nein kein Troll, das ist ein Hecht.


rofel
Teo

Klaus S. schrieb:
> Im Übrigen fand Linus Pauling ...

So ein Quatsch, natürlich Linus Torvalds !!!!!

Peter D. schrieb:
> habe ich schon 1997 bei einem AVR-Seminar bemängelt

Eins der fast schon legendären MSC-Seminare mit dem coolen Norweger und 
dem Elchbraten am Abend? Vom AVR ist nicht viel übrig geblieben, aber 
Elchbraten ist immer noch ein highlight für mich.

Hier ist es recht gut beschrieben:

https://kner.at/home/40.avr/Tutorials/Interrupts/index.html

Ansonsten - Datenblatt

https://ww1.microchip.com/downloads/en/DeviceDoc/ATmega164P-324P-644P-Data-Sheet-40002071A.pdf

Kap. 4.7 etc.