was passiert bei Interrupt ohne Routine? Kann ein AVR abstürzen, wenn ein Timer in den Overflow läuft, und kein entsprechendes Signal definiert ist ?
gast wrote: > was passiert bei Interrupt ohne Routine? Es wird intern ein bad-interrupt-Handler aufgerufen, der defaultmäßig zu einem Neustart des Programms führt (Sprung an die Programmadresse 0). Man kann den bad-interrupt-handler aber auch dazu bringen, etwas anderes zu machen. Wie es geht steht in der libc-Dokumentation. > Kann ein AVR abstürzen, wenn ein Timer in den Overflow läuft, und kein > entsprechendes Signal definiert ist ? Wenn Du mit "abstürzen" meinst, dass das Programm von vorne neu anfängt: Ja. Und er kann das nicht nur, sondern er tut das auch!
Kommt drauf an, was in der Interrupttabelle steht. Wenn die schön sauber mit reti aufgefüllt ist, passiert garnix. GCC füllt die mit unsauberen Neustarts auf.
Aha dir Otimierungslevel ist 0! aber bei höheren levels geht das Programm nicht mehr
Sven Pauli wrote: > Kommt drauf an, was in der Interrupttabelle steht. Wenn die schön sauber > mit reti aufgefüllt ist, passiert garnix. GCC füllt die mit unsauberen > Neustarts auf. Nicht zwangsläufig: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html
1 | #include <avr/interrupt.h> |
2 | |
3 | ISR(BADISR_vect) |
4 | {
|
5 | }
|
so würde der Prozessor unimplementierte Interrupts einfach ignorieren.
gast wrote: > Aha dir Otimierungslevel ist 0! aber bei höheren levels geht das > Programm nicht mehr Na das sind ja viele Informationen. Sollten wir daraus was entnehmen sollen?
Vielen Dank Simon K. Ich glaube jetzt gehts. Habe denn Code in die ISR gepackt.
Hallo, ich weiß nicht, ob das Problem dadurch gelöst wird, wenn der BADISR_vect angegeben wird. Es wird zwar die ISR ausgeführt, aber wenn in dieser die Ursache z.B. Timer-Flag nicht gelöscht wird, so wird die ISR gleich nach dem verlassen wieder ausgeführt. Der Controller ist dann in einer Endlosschleife. (Es sei denn es kommt ein Interrupt mit einer höheren Priorität) Ich würde mich daher auf den BADISR_vect nicht verlassen. Grüße, Florian
Florian Pfanner wrote: > Hallo, > > ich weiß nicht, ob das Problem dadurch gelöst wird, wenn der BADISR_vect > angegeben wird. Es wird zwar die ISR ausgeführt, aber wenn in dieser die > Ursache z.B. Timer-Flag nicht gelöscht wird, so wird die ISR gleich nach > dem verlassen wieder ausgeführt. Der Controller ist dann in einer > Endlosschleife. (Es sei denn es kommt ein Interrupt mit einer höheren > Priorität) Die meisten Flags löschen sich selber dadurch, dass der Interrupthandler ausgeführt bzw. beendet wird.
Der BADISR_vect sollte eigentlich nur dazu dienen, solche Fehler zu finden und richtig zuzuordnen! Er sollte eigentlich nicht die dauerhafte Lösung sein. Besser: den Interrupt finden, den man aktiviert, aber nicht abfängt. Und hat man den gefunden, ist der BADISR_vect auch wieder überflüssig.
Uwe ... wrote: > Der BADISR_vect sollte eigentlich nur dazu dienen, solche Fehler zu > finden und richtig zuzuordnen! Er sollte eigentlich nicht die dauerhafte > Lösung sein. Besser: den Interrupt finden, den man aktiviert, aber nicht > abfängt. Und hat man den gefunden, ist der BADISR_vect auch wieder > überflüssig. Ah genau, das vergaß ich noch zu sagen. Sprich: Den BADISR_vect bezieht man am besten auf das obligatorische #define DEBUG Makro ;)
Uwe ... wrote: > Der BADISR_vect sollte eigentlich nur dazu dienen, solche Fehler zu > finden und richtig zuzuordnen! Genau! Ein Programmierer sollte sich doch nicht wie ein Politiker benehmen :-( Also nicht die eigenen Fehler verschleiern, sondern die Ursache finden und beseitigen. Peter P.S.: Ich hab in der BADISR ne Endlosschleife mit Blink-LED, damit ich sofort sehe, daß ich was falsch gemacht habe.
>Kann ein AVR abstürzen, wenn ein Timer in den Overflow läuft, >und kein entsprechendes Signal definiert ist ? Wenn nur der Timer in den Overflow läuft und Interrupts gar nicht eingeschaltet sind (also z.B. nur TRx = 1;), passiert schon gleich gar nichts. Es wird nur das Overflow-Flag gesetzt wird, und der Zähler beginnt wieder von vorn... Abstürzen wird der uC sicher nicht. Der wird evtl. nur nicht mehr das tun, was du von ihm willst, sondern eben etwas anderes. Das wäre dann eher Amok-Laufen. Was du meinst, ist ob ein fehlerhaftes Programm abstürzen kann. Ja, aber das liegt am Programmierer...
Lothar Miller wrote: > Abstürzen wird der uC sicher nicht. Der wird evtl. nur nicht mehr das > tun, was du von ihm willst, sondern eben etwas anderes. ... Wobei dies beispielsweise im Falle eines UART-Interrupts nicht mehr von einem ,,Absturz'' unterscheidbar wäre. Der Controller würde endlos immer wieder die ISR ausführen und dazwischen jeweils einen anderen Befehl. Warum das Füllen der Vektortabelle mit RETI in diesem Lichte eine ,,saubere'' Lösung sein sollte, muss mir dann auch erstmal jemand verraten. Das Thema ist auf der avr-libc-Mailingliste mehr als einmal diskutiert worden, und nach Austausch der Argumente war jedes Mal klar, dass eine Lösung, die den Programmierer mit der Nase auf seinen Fehler stößt (also nicht stillschweigend einfach ein RETI ausführt) auf jeden Fall die zu bevorzugende Variante ist. Dass die jetzige Lösung durchaus auch Verbesserungspotenzial bietet, ist eine andere Frage. Peter Dannegger hatte mal einen Vorschlag, bei dem man wohl die Adresse des Interruptvektors mit einem Debugger nachträglich (mittels eines passenden Breakpoints oder so) analysieren könnte. Leider äußert Peter zwar immer mal schöne Ideen, aber handfeste (also mit wenig Aufwand zu integrierende, sauber dokumentierte und sinnvoll mit existierenden Lösungen kompatible) Patches habe ich von ihm bislang noch nie in einem der Projekte gesehen.
Jörg Wunsch wrote: > Peter Dannegger hatte mal einen Vorschlag, bei dem man wohl die Adresse > des Interruptvektors mit einem Debugger nachträglich (mittels eines > passenden Breakpoints oder so) analysieren könnte. Das geht in Assembler ganz einfach. Man muß nur im Unterschied zu anderen ISR-Handlern den Handler nicht anspringen, sonder callen. Dann kann der BADISR-Handler im Stack nachschauen, von wo er aufgerufen wurde. Er muß aber vor dem RETI die Return-Adresse entfernen (SP+=2), sonst wird ja der nächste Interruptvektor aufgerufen. Wie man sowas einem Compiler beibringt, weiß ich allerdings nicht. > Leider äußert Peter > zwar immer mal schöne Ideen, aber handfeste (also mit wenig Aufwand > zu integrierende, sauber dokumentierte und sinnvoll mit existierenden > Lösungen kompatible) Patches habe ich von ihm bislang noch nie in > einem der Projekte gesehen. Der Grund ist einfach, daß ich vom Compilerbau null Ahnung habe. Ich kann daher nicht einschätzen, ob ein Patch leicht zu integrieren oder zu irgendwas kompatibel ist. Für mich ist ein Compiler eine Black-Box wie z.B. Excel oder Word, ich kann es benutzen, aber nichts daran ändern. Wenn ich wüßte, wie man einen Patch programmiert, hätte ich z.B. schon längst meine kleine 64Bit Assembler-Arithmetik eingebaut. Peter P.S.: Beruflich bin ich Hardwareentwickler, das MC-Proggen ist also mehr ein Hobby. Bei 128 Byte SRAM macht das Proggen noch Spaß. 117MB der WINAVR-Installation sind aber ein völlig anderes Kaliber.
Jörg Wunsch wrote: > Peter Dannegger hatte mal einen Vorschlag, bei dem man wohl die Adresse > des Interruptvektors mit einem Debugger nachträglich (mittels eines > passenden Breakpoints oder so) analysieren könnte. Leider äußert Peter > zwar immer mal schöne Ideen, aber handfeste (also mit wenig Aufwand > zu integrierende, sauber dokumentierte und sinnvoll mit existierenden > Lösungen kompatible) Patches habe ich von ihm bislang noch nie in > einem der Projekte gesehen. Das hört sich leider sehr vorwurfsvoll an. Ich kann Peter verstehen, wenn er keine Ahnung von Compilern von innen hat und sich dies auch nicht antun möchte. Genauso wenig tue und möchte ich es, um ehrlich zu sein. Für mich bleibt das Dingen immer irgendwie eine Wundermaschine der Technik. Bis man erst ein mal hintergekommen ist, an welchem Punkt man den Patch ansetzen müsste um das gewünschte Resultat zu erhalten hat man unter Umständen schon so viel Kaffe getrunken, Zigaretten geraucht und Frusterlebnisse gehabt, dass man es lieber sein lässt oder schon gestorben ist.
Nun, sorry, ein Vorwurf sollte es nicht sein. Wohl eher ein wenig Jammern: es gibt schöne Ideen, aber zu wenig Leute, die sie dann auch mal umsetzen würden. Dabei bieten sich gerade Ideen wie diese an, weil sie eben gar nicht in den Compiler eingreifen (der mir zu großen Teilen [leider] auch eine ziemliche Blackbox ist), sondern auf Ebene der Bibliothek implementiert werden können (Startup-Code und ggf. Headerdateien). Damit sind sie von der normalen Applikation gar nicht mehr so weit weg, wie es auf den ersten Blick scheinen mag.
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.