Hallo, so eine ISR springt stur dahin zurück, wo sie hergekommen ist (bei meinem Versuchsprogramm z.B. in eine Endlosschleife). Ich hätte es aber gern, wenn sie im Befehlszähler etwas weiter spränge. Dann habe ich alternativ in die ISR den Aufruf einer Funktion geschrieben, wurde aber vom Compiler belehrt, daß diese Funktion hier nicht definiert sei. Vielleicht löst eine Funktion das Problem gar nicht. Goto geht leider auch nicht. Kennt jemand einen Trick? Gruß Egon
> Ich hätte es aber gern, wenn sie im Befehlszähler etwas weiter spränge. Kaputtes Design. > Dann habe ich alternativ in die ISR den Aufruf einer Funktion > geschrieben, Ja, so kann man das Problem lösen, wenn denn die betreffende Funktion nicht sonderlich viel Zeit benötigt. > wurde aber vom Compiler belehrt, daß diese Funktion hier > nicht definiert sei. Tja, dann fehlte da halt der Funktionsprototyp bzw. die zugehörige Include-Datei war nicht eingebunden.
Wieso kommst du jetzt eigentlich wieder auf diesen Schrott mit Watchdog und "nach ISR woanders hin springen" zurück. Du hattest doch schon angefangen, den "normalen" Weg zu gehen. Woran hapert es jetzt? Hier die anderen Threads zum gleichen "Projekt": Beitrag "watchdog ohne Totalreset?" Beitrag "16-bit-Timer - wer kann helfen?" Beitrag "wie ATMega644- Watchdog ohne Headerdatei betreiben?"
wenn es unbedingt sein muss - die Vorposter haben ja schon geschrieben, dass das ein kaputtes Design ist - kannst Du per inline ASM den Stack manipulieren: Rücksprungadresse runterPOPen (nicht runterpoppen :-) und neue Zieladresse auf den Stack pushen plus den Rest wieder drauf schreiben. Die Zeit, die es dauert, um das zu realisieren solltest Du aber besser in ein anderes Programmdesign investieren.
>Dann habe ich alternativ in die ISR den Aufruf einer Funktion >geschrieben, wurde aber vom Compiler belehrt, daß diese Funktion hier >nicht definiert sei. Solange du solche elementaren Dinge nicht hinbekommst, macht es gar keinen Sinn, über Stackmanipulationen auch nur nachzudenken. >Goto geht leider auch nicht. Das geht bestimmt, ebenso ein break, aber beides braucht es vermutlich gar nicht. Formuliere doch nochmal den Kern der Aufgabenstellung. Das war doch irgenwas mit Impulsen und Sensorfehlererkennung durch timeout. Oliver
Solange Du kein Multitasking benutzt, geht unter C ein long Jump: http://www.java2s.com/Code/C/Memory/Memorylongjump.htm Aber ich muß auch sagen, es ist deutlich besser (wartbarer, weniger fehleranfällig), wenn man es durch einen besseren Programmablaufplan löst. Sobald die Programme größer werden, steigt die Gefahr, daß Du durch den Sprung andere wichtige Prozesse killst. Ein Eingenschaft von Interrupts ist nämlich, daß Du garnicht weißt, was er gerade unterbricht. Bzw. wenn Du wirklich weißt, daß er nur an einer bestimmten Stelle unterbricht, dann brauchst Du ja garkeinen Interrupt mehr. Dann kannst Du einfach an dieser Stelle warten, bis das Interrupt-Pending-Flag gesetzt ist. Peter
Peter Dannegger schrieb:
> Solange Du kein Multitasking benutzt, geht unter C ein long Jump:
Dann sollte man aber immer noch dran denken, die Interrupts noch
freizuschalten.
Ich hoffe aber, dass ich in meinem Leben niemals einem Gerät mit
derartiger verhunzter Firmware in Berührung kommen muss. schauder
>Ich hoffe aber, dass ich in meinem Leben niemals einem Gerät mit >derartiger verhunzter Firmware in Berührung kommen muss. Nach dem bisherigen Verlauf der Diskussion ist die Gefahr äusserst gering... Oliver
Jörg Wunsch schrieb: > Peter Dannegger schrieb: >> Solange Du kein Multitasking benutzt, geht unter C ein long Jump: > > Dann sollte man aber immer noch dran denken, die Interrupts noch > freizuschalten. > > Ich hoffe aber, dass ich in meinem Leben niemals einem Gerät mit > derartiger verhunzter Firmware in Berührung kommen muss. *schauder* Hallo Jörg Ich kann mir gut vorstellen, daß sich deutliche Unlustgefühle einstellen, wenn man als Experte zusehen muß, was die Dilettanten so alles verzapfen. Ich habe also volles Verständnis für Deinen Schauder. Du kannst Dir weiterhin unbesorgt jegliche Firmware zulegen, m e i n e ist garantiert auf gar keinen Fall dabei (es handelt sich um ein nicht kommerzielles Vorhaben zur Überwachung meines Gartenteiches). Im übrigen funktioniert es mit einem interruptauslösenden Watchdog bestens. Ob ich mich mal wieder hier mit Fragen einfinden darf? Vielen Dank auch für die anderen Beiträge! Viele Grüße Egon
Stefan Ernst schrieb: > Wieso kommst du jetzt eigentlich wieder auf diesen Schrott mit Watchdog > und "nach ISR woanders hin springen" zurück. Du hattest doch schon > angefangen, den "normalen" Weg zu gehen. Woran hapert es jetzt? > Im Manual, dessen Lektüre einem ja immer wieder empfohlen wird, wurde der Watchdog als sehr nützlich angepriesen. Deshalb habe ich nach besseren Beschreibungen gesucht, ihn mal ausprobiert und ich finde, daß er sehr brauchbar ist - wenn man seine Tücken vermeidet. Ich habe in den beiden Programmen jeweils vor der kritischen Abfrage den WD gestartet und ihn danach gleich wieder ausgeschaltet. In der von Atmel gebrauchfertig vorgegbenen ISR habe ich einfach ein Flag gesetzt, das sich überall leicht abfragen lies. Indem ich vor und nach WD-Gebrauch das Statusregister gesichert und wiederhergestellt habe, konnte ich die beiden Programme ohne Störungen in eine größeres Projekt mit allerhand Interrupts, wo man nicht einfach cli(); oder sei(); schreiben kann, integriert - und es funktioniert immer noch (Ulis Webserver ETH_M32....). Also, der Watchdog ist vielleicht nicht fein, aber manchmal sehr praktisch. Viele Grüße Egon
Lässt du dich früh auch von deinem Hund beißen, weil du keine Lust hast, dir anzusehen, wie man den normalen Wecker auf dem Nachttisch stellt? Ungefähr sowas machst du jedenfalls gerade in deiner Software...
Jörg Wunsch schrieb: > Lässt du dich früh auch von deinem Hund beißen, weil du keine Lust > hast, dir anzusehen, wie man den normalen Wecker auf dem Nachttisch > stellt? > > Ungefähr sowas machst du jedenfalls gerade in deiner Software... Dein Vergleich ist besser als man denkt, insofern nämlich mein liebes Hündchen mich nicht beißen, sondern freundlich an der Nase lecken würde - besser als das schrille Weckergeklingel! Nichts für ungut Egon
Egon Müller schrieb: > Dein Vergleich ist besser als man denkt, insofern nämlich mein liebes > Hündchen mich nicht beißen, sondern freundlich an der Nase lecken würde Dann agiert er aber nicht als Watchdog, sondern als regulärer Timer.
He, he, hab' mir diesen Thread gelinkt für den Fall daß wieder mal ein Basic / C Flamewar entsteht. Hier kann nun wirklich niemand mehr behaupten daß Ergebnisse in C besser sind oder der Programmierer durch Benutzung selbiger Sprache automatisch mehr Ahnung hätte :D
Jörg Wunsch schrieb: > Egon Müller schrieb: > >> Dein Vergleich ist besser als man denkt, insofern nämlich mein liebes >> Hündchen mich nicht beißen, sondern freundlich an der Nase lecken würde > > Dann agiert er aber nicht als Watchdog, sondern als regulärer Timer. Das stimmt; es wird bei dem Programm ein Port sechs mal abgefragt und zwei mal mittels Timer ausgezählt, wobei der Sensor in jeder Phase stehen bleiben kann. Da kam es mir bequemer vor, diese kritische Passage einmal mittels Watchdog zu überwachen als in jeder der sechs Schleifen einen Ausstieg mittels Zähler zu integrieren.
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.