Hallo,
bei Microcontrollern gibt es ja den sogenannten Interrupt Vector Table
der das Mapping zwischen einem Interrupt und seiner Interrupt Service
Routine übernimmt.
Nun hat mein Lehrer gesagt, dass leere Vektoren in diesem Table zu einer
Endlosschleiße zeigen sollten (bzw. zu einer Adresse, in der dann die
Adresse einer Endlosschleife steht). So nach dem Motto "Dieser Interrupt
wird nicht gebraucht".
Ich verstehe aber den Sinn der Endlosschleife nicht. Wenn jetzt der
Interrupt auftritt, und der MC zu der Endlosschleife springt, kommt er
doch da nicht mehr raus? Warum eine Endlosschleife?
Ich hoffe ihr versteht, was ich meine! :)
Wime
Was passiert, wenn er dahin springt und kein definierter Code vorhanden
ist?
-> Chaos!
Eigentlich sollte ein nicht definierter Interrupt nicht angesprungen
werden. Aber man kann ja mit Fehlern (vom Programmierer) rechnen und
entsprechend reagieren.
-> Profi!
Es gibt zwei Ansätze:
- ignorieren: Also an der stelle einfach ein Rücksprung.
- signalisieren: Eine Fehlerlampe anschalten und in Endlosschleife
gehen.
Wenn "nix" (irgendwas steht auch da wenn es nicht explizit genannt wird)
dasteht ist das verhalten halt undefiniert und das will man ganz sicher
nicht!
Wim schrieb:> Ich verstehe aber den Sinn der Endlosschleife nicht. Wenn jetzt der> Interrupt auftritt, und der MC zu der Endlosschleife springt, kommt er> doch da nicht mehr raus? Warum eine Endlosschleife?
Das setzt voraus, daß der Watchdog eingeschaltet ist. Wenn der
Controller in der Endlosschleife landet, wird der Watchdogtimer nicht
mehr regelmässig zurückgesetzt und der Controller resetted. Dann macht
das auch einen Sinn.
Aber als allgemeingültig würde ich diese Mögichkeit nicht hinstellen.
Man kann das so machen, man muss aber nicht.
spess53 schrieb:> Sinnvoller ist es den Interruptvektor mit einem RETI oder einem Sprung> zu einem RETI zu belegen.
Das ist die einfachste Möglichkeit. Dann tut der Controller so, als
wäre(fast) nichts gewesen.
mfg.
Thomas Eckmann schrieb:> spess53 schrieb:>> Sinnvoller ist es den Interruptvektor mit einem RETI oder einem Sprung>> zu einem RETI zu belegen.> Das ist die einfachste Möglichkeit. Dann tut der Controller so, als> wäre(fast) nichts gewesen.
Davon halte ich garnichts.
Wenn eine Interruptroutine in eine separate Endlosschleife springt, kann
man die Ursache viel einfacher ergründen. Beispielsweise einen Bus- oder
Adressfehler entlarven - entsprechenden Controller vorausgesetzt :-)
Thomas Eckmann schrieb:>> Wenn jetzt der>> Interrupt auftritt, und der MC zu der Endlosschleife springt, kommt er>> doch da nicht mehr raus? Warum eine Endlosschleife?> Das setzt voraus, daß der Watchdog eingeschaltet ist.
Nö, soll er doch in der Endlosschleife bleiben. Dort macht er keinen
Blödsinn. Irgendeinen Grund muss es für den nicht vom Programmierer
geplanten Interrupt geben. Also passt etwas nicht und das Programm läuft
fehlerhaft oder unkontrolliert ab.
Es gibt verschiedene Aufgabenstellungen und verschiedene Lösungen.
Malso, mal anders, eine pauschale Antwort gibt es hier nicht.
Profi schrieb:> Dort macht er keinen Blödsinn.
Richtig. Er macht gar nichts mehr. Der Port, der den Ladestrom für den
Akku schaltet, bleibt eingeschaltet und der Akku verkocht irgendwann.
Falls nicht vorher was anderes kaputt geht.
Deswegen:
> eine pauschale Antwort gibt es hier nicht.
mfg.
Thomas Eckmann schrieb:> Der Port, der den Ladestrom für den> Akku schaltet, bleibt eingeschaltet und der Akku verkocht irgendwann.> Falls nicht vorher was anderes kaputt geht.
Siehst du auch kleine grüne Männchen? ;-)
Du musst schon alles lesen:
Profi schrieb:> Es gibt verschiedene Aufgabenstellungen und verschiedene Lösungen.> Malso, mal anders, eine pauschale Antwort gibt es hier nicht.
und ganz wichtig:
Wim schrieb:> Nun hat mein Lehrer gesagt, dass leere Vektoren in diesem Table zu einer> Endlosschleiße zeigen sollten (bzw. zu einer Adresse, in der dann die> Adresse einer Endlosschleife steht). So nach dem Motto "Dieser Interrupt> wird nicht gebraucht".
immer schön die Aufgabenstellung beachten.
Thomas Eckmann schrieb:> Profi schrieb:>> Dort macht er keinen Blödsinn.> Richtig. Er macht gar nichts mehr. Der Port, der den Ladestrom für den> Akku schaltet, bleibt eingeschaltet und der Akku verkocht irgendwann.> Falls nicht vorher was anderes kaputt geht.
Einen für die Anwendung definierter "sicheren Zustand" wäre besser.
Wenn es keine Rolle spielt, könnte man auch einfach wieder
zurückspringen.
Allerdings ist es definitiv ein Zustand der nie auftreten sollte und in
meinen Augen daher ein Fehler auf den man sinnvoll reagieren sollte.
Profi schrieb:> Du musst schon alles lesen:
Ich MUSS gar nichts.
Thomas Eckmann schrieb:> Deswegen:>> eine pauschale Antwort gibt es hier nicht.
Aber da ich dich sogar zitiert habe, hätte selbst dir auffallen können,
daß ich das wohl doch gelesen habe.
Aber das ist wohl ein bisschen viel verlangt.
mfg.
N. M. schrieb:> Allerdings ist es definitiv ein Zustand der nie auftreten sollte und in> meinen Augen daher ein Fehler auf den man sinnvoll reagieren sollte.
In Zustände, von denen der Programmierer mein, dass dort Fehler
auftreten können, sollte man genauso sinnvoll reagieren. Das macht also
keinen Unterschied.
In der Raumfahrt gehen Satelliten in Fällen unplausiblen Verhaltens oder
unerwarteter Zustandsdaten einfach in einen sicheren Zustand und warten
dort auf Anweisungen von der Kontrollstation.
M.A. schrieb:> In Zustände, von denen der Programmierer mein, dass dort Fehler> auftreten können, sollte man genauso sinnvoll reagieren. Das macht also> keinen Unterschied.
Was willst Du mir damit sagen? Ich schreibe doch dass es ein Fehler ist
wenn der uC in einen Vektor springt der nicht vergeben ist. Also
muss/sollte man auch sinnvoll auf diesen Fehler reagieren.
M.A. schrieb:> In der Raumfahrt gehen Satelliten in Fällen unplausiblen Verhaltens oder> unerwarteter Zustandsdaten einfach in einen sicheren Zustand und warten> dort auf Anweisungen von der Kontrollstation.
Nicht jede Anwendung wird allerdings nach SIL3/4 entwickelt.
Bei einer Eieruhr ist es wahrscheinlich egal dass er einmal in einen
falschen Vektor springt (vorausgesetzt er springt wieder zurück).
Deshalb hab ich ja geschrieben
N. M. schrieb:> Wenn es keine Rolle spielt, könnte man auch einfach wieder> zurückspringen.
M.A. schrieb:> In der Raumfahrt gehen Satelliten in Fällen unplausiblen Verhaltens oder> unerwarteter Zustandsdaten einfach in einen sicheren Zustand und warten> dort auf Anweisungen von der Kontrollstation.
Dass es bei der Fragestellung um Raumfahrt und Satelliten geht, hatte
ich noch garnicht mitbekommen.
Man lernt ja nie aus!
Aber wer ist denn jetzt die Kontrollstation? Wim oder der Lehrer?
Fit4Fun schrieb:> Wie ist das bei Vektorpositionen die "wirklich" leer sind wie beim XMega> ?
Kann man die nicht ummappen auf einen anderen Vektor den man dann von
mir aus "Illegaler_Vektor()" nennt?
Fit4Fun schrieb:> Wie ist das bei Vektorpositionen die "wirklich" leer sind wie beim XMega> ?
Gute Frage. "Leer" heißt noch lange nicht, das ein fehlerhaftes Programm
nicht dorthin springen kann.
Bei einem Piccolo von TI mache ich das bei der Initialisierung so, dass
ich zuerst alle Vektoren auf die Funktion "Illegaler_Vektor()" mappe und
anschließend die verwendete Vektoren auf die dementsprechenden
Funktionen.
Wenn dann ein nicht verwendeter bzw. falscher Vektor angesprungen wird,
dann landet er immer in der Funktion "Illegaler_Vektor()".
Fit4Fun schrieb:> Wie ist das bei Vektorpositionen die "wirklich" leer sind wie beim XMega
Die sind immer leer. Das ist ein Stück Flash und da steht 0xFF drin.
Springt der Controller da hin, führt er genau da aus. Was immer sich
dahinter verbergen mag.
N. M. schrieb:> Kann man die nicht ummappen auf einen anderen Vektor den man dann von> mir aus "Illegaler_Vektor()" nennt?
Der GCC setzt auf unbenutzte Vektoren einen Sprung auf den Resetvektor.
Man kann das aber auch mit einer "ISR(BADISR_vect)" abfangen.
mfg.
Thomas Eckmann schrieb:> N. M. schrieb:>> Kann man die nicht ummappen auf einen anderen Vektor den man dann von>> mir aus "Illegaler_Vektor()" nennt?> Der GCC setzt auf unbenutzte Vektoren einen Sprung auf den Resetvektor.> Man kann das aber auch mit einer "ISR(BADISR_vect)" abfangen.
Schon wieder was dazu gelernt, danke.
Thomas Eckmann schrieb:> Der GCC setzt auf unbenutzte Vektoren einen Sprung auf den Resetvektor.> Man kann das aber auch mit einer "ISR(BADISR_vect)" abfangen.
So isses!
Wenn es Sicherheitsanforderungen gibt, kann man da in einem sicheren
Zustand gehen und den Fehler irgendwie signalisieren. Ein Fehler ist es
ja eindeutig.
Was auf alle Fälle das Falscheste ist, solche Softwarefehler mit einem
RETI zu verstecken!
Einen Programmierer, der versucht, Fehler zu vertuschen, würde ich
fristlos kündigen.
Peter
Peter Dannegger schrieb:> Was auf alle Fälle das Falscheste ist, solche Softwarefehler mit einem> RETI zu verstecken!>> Einen Programmierer, der versucht, Fehler zu vertuschen, würde ich> fristlos kündigen.
Es gibt keine fehlerfreie SW! Was nun?
Selbstkritisch schrieb:> Es gibt keine fehlerfreie SW! Was nun?
Genau deshalb ist es umso wichtiger, Fehler nicht zu vertuschen.
Ansonsten sollten wir besser z.B. Feuermeldeanlagen wieder mit Relais
aufbauen.
Peter
Peter Dannegger schrieb:> Genau deshalb ist es umso wichtiger, Fehler nicht zu vertuschen.
???
Peter Dannegger schrieb:> Was auf alle Fälle das Falscheste ist, solche Softwarefehler mit einem> RETI zu verstecken!
Bei einem Fahrrad-Computer für 2,99€ wäre der RETI gar nicht schlecht.
Oder soll der Nutzer sofort anhalten und die Werkstatt aufsuchen?
Es gilt:
Profi schrieb:> Es gibt verschiedene Aufgabenstellungen und verschiedene Lösungen.> Malso, mal anders, eine pauschale Antwort gibt es hier nicht.
Selbstkritisch schrieb:> Peter Dannegger schrieb:>> Genau deshalb ist es umso wichtiger, Fehler nicht zu vertuschen.> ???
Er redet von dem Vorsatz, daß dem Programmierer ein Fehler aufgefallen
ist und durch z.B. ein RETI vertuscht wurde.
> Peter Dannegger schrieb:>> Was auf alle Fälle das Falscheste ist, solche Softwarefehler mit einem>> RETI zu verstecken!> Bei einem Fahrrad-Computer für 2,99€ wäre der RETI gar nicht schlecht.> Oder soll der Nutzer sofort anhalten und die Werkstatt aufsuchen?
Nur, wenn der Fahrradfaher der Programmierer ist.
Du bringst hier einige Dinge durcheinander oder versuchst Aussagen zu
verbiegen.
Eine Endlosschleife ist nur für die Fehlersuche zu gebrauchen.
Ein RETI kann man nach abgeschlossener Fehlersuche einbauen, um einen
evtl. doch auftretenden Fehler vor dem Anwender zu verbergen.
Gruß
Jobst
Jobst M. schrieb:> um einen> evtl. doch auftretenden Fehler vor dem Anwender zu verbergen.
Das kann es doch wohl nicht sein!
Selbst ein unbedarfter Anwender findet nach einiger Zeit die Fehler
eines Programmes.
Wenn, dann doch die Endlosschleife + watchdog-reset. Damit wird wieder
ein definierter Zustand hergestellt.
M.A. schrieb:> In der Raumfahrt gehen Satelliten in Fällen unplausiblen Verhaltens oder> unerwarteter Zustandsdaten einfach in einen sicheren Zustand und warten> dort auf Anweisungen von der Kontrollstation.
So wie bei Ariane 5.
Dort war der "sichere Zustand" die Selbstzerstörung :-)
Ein recht langer Thread... ich wusste gar nicht, dass wir hier so viele
ASM Programmierer haben. Dier meisten davon wussten wahrscheinlich auch
nicht dass man Interupt Tabellen nur bei ASM antrifft.
Prachz Kerl schrieb:> Dier meisten davon wussten wahrscheinlich auch> nicht dass man Interupt Tabellen nur bei ASM antrifft.
1. WIR sind Profis! WIR können auch Papst!
2. Zeige mir bei der angehängten Tabelle eine ASM-Anweisung!
Willi schrieb:> Das kann es doch wohl nicht sein!> Selbst ein unbedarfter Anwender findet nach einiger Zeit die Fehler> eines Programmes.
Lesen die Leute eigentlich richtig mit? Immer werden nur Fetzen, die
einem nicht gefallen, aus dem Zusammenhang gerissen und kommentiert.
Es geht darum, dies als Vorsichtsmaßnahme einzubauen, nachdem Deine
Fehlersuche ABGESCHLOSSEN ist und keine Fehler mehr gefunden werden
konnten.
Es geht NICHT darum, hiermit Fehler im Code zu billigen!
> Wenn, dann doch die Endlosschleife + watchdog-reset. Damit wird wieder> ein definierter Zustand hergestellt.
Wenn einfach zurück an die Stelle gesprungen wird, an der das Programm
unterbrochen wurde, auch. Der Interupt wird dann einfach nicht
behandelt.
Gruß
Jobst
Jobst M. schrieb:> Wenn einfach zurück an die Stelle gesprungen wird, an der das Programm> unterbrochen wurde, auch. Der Interupt wird dann einfach nicht> behandelt.
Wobei das nur bei AVRs Sinn ergibt, bzw. generell bei Controllern, bei
denen mit Einsprung in die ISR das Interrupt-Flag meistens automatisch
gelöscht wird.
Wenn man ein Interrupt-Flag stets explizit zurück setzen muss, dann ist
ein Return-from-Interrupt sinnlos. Denn der läuft dann auch auf eine
Totschleife hinaus, aber die explizite Schleife erkennt man bei der
Suche wenigstens als solche.
