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!
Hi Sinnvoller ist es den Interruptvektor mit einem RETI oder einem Sprung zu einem RETI zu belegen. MfG Spess
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?
Wie ist das bei Vektorpositionen die "wirklich" leer sind wie beim XMega ?
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.
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.