www.mikrocontroller.net

Forum: Compiler & IDEs was passiert bei Interrupt ohne Routine


Autor: gast (Gast)
Datum:

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

Autor: Johannes M. (johnny-m)
Datum:

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

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beitrag "AVR Stürzt ab --> interner Reset Hilfe"

Könnte das hier die Ursache sein ?

Autor: Sven P. (haku) Benutzerseite
Datum:

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

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha dir Otimierungslevel ist 0! aber bei höheren levels geht das 
Programm nicht mehr

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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__...
#include <avr/interrupt.h>

ISR(BADISR_vect)
{
}

so würde der Prozessor unimplementierte Interrupts einfach ignorieren.

Autor: Simon K. (simon) Benutzerseite
Datum:

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

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank  Simon K.

Ich glaube jetzt gehts.

Habe denn Code in die ISR gepackt.

Autor: Florian Pfanner (db1pf)
Datum:

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

Autor: Simon K. (simon) Benutzerseite
Datum:

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

Autor: Uwe ... (uwegw)
Datum:

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

Autor: Simon K. (simon) Benutzerseite
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Simon K. (simon) Benutzerseite
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

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.