Hallo! Eine Frage bzgl. Interrupts auf einem ATmega324. Wenn bei der Ausführung einer ISR (z.B. durch einen PCINT) währenddessen ein weiterer Interrupt (z.B. durch einen weiteren PCINT oder TOVF) kommt, was passiert? Werden die anderen ISRs direkt danach ausgeführt? Werden sie übersprungen? Kann eine ISR generell "unterbrochen" werden durch andere Interrupts?
> Werden die anderen ISRs direkt danach ausgeführt? Ja, nachdem im Hauptprogramm der nächste Befehl ausgeführt wurde. Reihenfolge ergibt sich aus der Reihenfolge in der Vektortabelle. > 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.
PS:
> Werden sie übersprungen?
Nein, natürlich nicht; die betreffenden Interrupt-Flags bleiben ja
gesetzt, bis sie (im Regelfall) hardwaremäßig beim Einsprung in die ISR
gelöscht werden.
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)
S. Landolt schrieb: >> Werden die anderen ISRs direkt danach ausgeführt? > Ja, nachdem im Hauptprogramm der nächste Befehl ausgeführt wurde. Oder schon vorher, nachdem in der laufenden Interruptroutine Interrupts über das global interrupt Flag wieder freigegeben wurden.
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. Liegen weitere an, würden die verloren gehen - ich lasse mich aber gerne eines Besseren belehren :-)
Klaus S. schrieb: > Nach meiner Erfahrung funktionieren "nested Interrupts" genauso wie > einfache Interrupts, man braucht nur mehr Platz auf dem Stack. Das ist erstmal grundsätzlich so. > Wüßte > nicht, was da anders wäre. Es besteht die Gefahr, sich selbst zu "nesten". Dann wächst der Stack bis BUMM. Diese Gefahr besteht prinzipiell für alle ISRs, sobald es auch nur einen einzigen Interrupt im System gibt, bei dem die maximale Interruptfolgefrequenz nicht vorhersagbar ist, sprich: letztlich aus einer äußeren Quelle stammt. Und das ist bei ziemlich vielen Interrupts der Fall (entweder generell oder zumindest als Möglichkeit in bestimmten Betriebsarten). Wohlgemerkt: die unterbrechbar gemachte ISR kann für sich selber sicher sein (z.B. OVF eines Timers alle 100µs, gesamte ISR-Laufzeit 80µs), aber durch einen anderen Interrupt so sehr heruntergebremst werden, dass das Nesting für die Timer-ISR eintritt, obwohl die selber eigentlich garnicht Schuld daran ist.
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: > Kennst Du einen Prozessor, dessen Interruptcontroller das ermöglicht? AVR8 (klassisch) Wobei die eben gerade keinen Interruptcontroller im üblichen Sinne besitzen.
> AVR8 (klassisch)
Eben. 'Max Wo' fragte nach dem ATmega324 - und ist mit der Diskussion
hier mittlerweile wahrscheinlich überfordert, wenn ich seine Fragen
richtig einordne.
c-hater schrieb: > Diese Gefahr besteht prinzipiell für alle ISRs, sobald es auch nur > einen einzigen Interrupt im System gibt, bei dem die maximale > Interruptfolgefrequenz nicht vorhersagbar ist, sprich: letztlich aus > einer äußeren Quelle stammt. Das ist kein spezielles Problem von Interrupts. Bei rekursivem Aufruf von Funktionen/Unterprogrammen kann der Stack genauso explodieren.
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. ;)
Klaus S. schrieb: > Kennst Du einen Prozessor, dessen Interruptcontroller das ermöglicht? Der ATmega324 hat da nicht viel zu bieten. 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.
Wolfgang schrieb: > Das ist kein spezielles Problem von Interrupts. Bei rekursivem Aufruf > von Funktionen/Unterprogrammen kann der Stack genauso explodieren. Natürlich. Deswegen vermeidet man Rekursionen, wann immer es geht. Auch wenn das weniger "elegant" aussieht...
Wolfgang schrieb: > Das ist kein spezielles Problem von Interrupts. Bei rekursivem Aufruf > von Funktionen/Unterprogrammen kann der Stack genauso explodieren. Das Besondere bei Interrupts ist aber, dass das Verhalten oft von außerhalb des Controllers ausgelöst werden kann. z.B. durch Glitches an Pins. Und deshalb sehr schwer zu debuggen ist.
c-hater schrieb: > Deswegen vermeidet man Rekursionen, wann immer es geht. Rekursionen verwendet man genau dann, wenn sie eine besonders effektive Abbildung des Problems erlauben. Soll man sich da künstlich verbiegen und einen fehlerträchtigen Murks drumrum stricken?
Wolfgang schrieb: > Soll man sich da künstlich verbiegen und einen fehlerträchtigen Murks > drumrum stricken? Was soll man von C-Hatern auch schon erwarten.
Wolfgang schrieb: > c-hater schrieb: >> Deswegen vermeidet man Rekursionen, wann immer es geht. > > Rekursionen verwendet man genau dann, wenn sie eine besonders effektive > Abbildung des Problems erlauben. Nein. Das verkneift man sich. Das tuen nur praxisferne Akademiker, die das Problem der endlichen Ressourcen erstmal "ausklammern" (und dann instantan vergessen). Erst, wenn sie auf ihre dumme Schnauze gefallen sind, bauen sie dann typisch wenigstens eine Beschränkung der Rekursionstiefe ein. Das sieht dann allerdings auch schon wesentlich weniger elegant aus ;o)
c-hater schrieb: > Das tuen nur praxisferne Akademiker, die > das Problem der endlichen Ressourcen erstmal "ausklammern" (und dann > instantan vergessen). Man kann und sollte Rekursionen natürlich begrenzen, damit eben keine unendlich große Ressourcenalloziierung passieren kann. Versteht sich von selbst.
Ausnahmsweise möchte ich hier dem C Hasser minimal zustimmen! Rekursion ist ein Pattern, welches jeder Programmierer kennen und beherrschen können sollte. Festhalten kann man: Eine infinite Rekursion ist tödlich, egal auf welchem System Vor Jahrzehnten wurde schon festgestellt, dass Rekursionen in allen Fällen auf Iterationen zurückgeführt werden können. Das ist das Mittel, um solche Geschichten auf kleinen µC verwertbar zu bekommen. Ein System mit MMU, oder anderen Schutzeinrichtungen, kann ein Überlaufen des Stacks verhindern/unterbinden. Aber auf den kleinen AVR kann der Stack in den Heap oder andere Datenspeicherbereiche rein rasseln. Drum verstehe ich die Abneigung gegen Rekursion. Kann sie aber nicht assimilieren.
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.
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.
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?
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: > ansonsten laufen die Interrupts brav > weiter wie sie programmiert wurden Wenn sie denn genügend Speicher haben. Das Problem ist, dass die Stackauslastung nichtdeterministisch ist und die maximale Auslastung sehr schwer zu ermitteln ist, weil sie vom IRQ-Timing abhängt. Und das theoretische Maximum - alle IRQs laufen zugleich mit maximaler Schachteltiefe - überschreitet sehr schnell kleine Speicher von kleinen Controllern.
Klaus S. schrieb: > 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. loop() ist auch bei Arduino kein Hauptprogramm, sondern eine Funktion, die vom Hauptprogramm aufgerufen wird.
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.
>Die AVRs wurden bestimmt nicht wegen ihrer rückständigen Interruptlogik >populär,.. Stimmt. Höchste Zeit, dass MCH das mal ändert.
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: > Weiß da jemand etwas Näheres? Nun, ich weiß, dass es ziemlicher Schwachsinn ist, den AVR8 als Basis zu wählen, wenn das Ziel "präemptives Multitasking" ist. Und ich weiß außerdem, dass es durchaus möglich ist, eine Anwendung auf dem AVR8 hinzubekommen, die nur aus ISRs besteht (die teilweise auch unterbrechbar sind, also Prioritäten implementieren). Das Gesamtwerk agiert dann im Endeffekt genauso, wie mit "präemptiven Multitasking", bloß viel, viel effizienter...
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.
Wenn es denn den Max Wo (Gast) interessieren würde: Bei ATmega und ATtiny gilt: Ausgelöste Interruptanforderungen (Interruptflags) bleiben gesetzt, bis sie in einer Interruptroutine behandelt, oder bewusst gelöscht wurden. Das geschilderte Problem ist also keines. Andersherum wird es kritisch: Wird eine Interruptanforderung nicht vor dem erneuten Auftreten der gleichen Interruptanforderung bearbeitet, hat das Programm zwischenzeitliche Zustände nicht erfasst. Da muss Programmierer/in GENAU wissen, ob das nachteilige Auswirkungen haben könnte und ggfs. was dagegen tun.
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.
:
Bearbeitet durch User
Hallo und vielen Dank für eure Antworten und die lebhafte Diskussion ;-) Blicke jetzt deutlich klarer durch. Grüße
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.