Moin, moin, ich experimentiere gerade mit AVR ATmegas und stehe vor folgender Frage. Gibt es eine bestimmte Methode/Befehl o.ä. um den Status sämtlicher Ausgänge nach einem Reset wiederherzustellen? Hintergrund ist, dass der (Haupt-)µC gewisse Funktionen schaltet und extern durch einen weiteren µC (Watchdog) überwacht wird. Bei Problemen wird der Haupt-µC resetet und fährt dannach wieder hoch. Je nachdem, welche Art Fehlerflag der Watchdog dann enthält, sollen die Ausgangszustände das Haupt-µCs wieder hergestellt werden. Ist es tatsächlich so banal, dass ich die Zustände durch den Watchdog speichere und dann dem µC wieder anbiete, oder gibt es eine schönere Methode, beispielsweise irgend ein Flashregister ö.ä., welches den letzten Status bereits enthält?
Ich verstehe das Prinzip nicht ganz: Wenn Dein Haupt-uC Probleme hat und extern resettet werden soll, kannst Du ja auch nicht davon ausgehen, daß die Ausgänge richtig geschaltet sind..? Ansonsten, wenn Du nicht so oft schaltest, schreibst Du Dir die Daten halt nach dem Ändern immer ins Eprom und liest sie nach dem Reset wieder..
Automatisch behält der AVR seine Zustände nicht, aber der RAM-Inhalt überlebt einen Reset. Was Du brauchst ist ein Satz Variablen, die Du nur beim Einschalt-Reset initialisierst, aber nicht wenn der Watchdog zuschlägt. In denen hältst Du jede I/O-Zustandsänderung fest und kannst sie dann nach dem Watchdog-Reset wieder herstellen.
Die Überwachungssoftware ist schon umfangreicher, ich wollte die Frage aber so kompakt wie möglich halten. Je nach Art des erkannten Fehlers im µC setzt der Watchdog Flags, die der µC nach dem Reset ausliest. Und abhängig von diesen Flags gibt es verschiedene Reaktionen, z.B. in einem Fail-Zustand bleiben, das Programm "sauber" neustarten oder eben die Ausgänge wiederherstellen.
Noch eine Anmerkung bzgl. der Antwort von R. Max. Der Watchdog soll bei der Initialisierung auf jedem Fall einbezogen werden. Der µC weiß ja von sich aus erstmal nicht, ob der Reset manuell auf Grund einer Neuprogrammierung oder auf Grund eines Fehlers ausgelöst wurde. Dies erfährt er nur, wenn der die Fehlerflags des Watchdogs bei der Initialisierung ausliest. Pauschal sind alle Ausgänge beim Einschalten offen (bzw. werden mit Standardwerten initialisiert), die vor dem Reset anliegenden Zustände sollen wirklich nur dann wiederhergestellt werden (und damit die Standardwerte vor Programmstart überschreiben), wenn das entsprechende Flag des Watchdogs gesetzt ist.
Speedy schrieb: > Noch eine Anmerkung bzgl. der Antwort von R. Max. Der Watchdog soll bei > der Initialisierung auf jedem Fall einbezogen werden. Der µC weiß ja von > sich aus erstmal nicht, ob der Reset manuell auf Grund einer > Neuprogrammierung oder auf Grund eines Fehlers ausgelöst wurde. Ja, das hatte ich so schon verstanden, das steht aber meinem Vorschlag mit den persistenten Variablen nicht entgegen. Deine Initialisierung muß halt anhand der Informationen vom Watchdog entscheiden, ob es den alten Zustand wieder herstellt oder neu aufsetzt.
Ok, dass if und Schleife nicht passen, haben wir jetzt glücklicherweise schon festgestellt ;-). Wie genau meinst Du das? Mit if erschließt sich mir keine Methode - oder spielst Du auf eine Abfrage des RAMs an? Schleifen an sich wollte ich ja nach Möglichkeit vermeiden. Die Zustände vor dem Reset zu speichern ist natürlich probat, aber lieber wäre mir eine andere Möglichkeit, bei der ich mich vor dem Reset nicht aktiv um die Zustände kümmern muss. Die Tatsache, dass das RAM den Reset überlebt, ist vermutlich die sinnvollste Option, danke R. Max.
>Hintergrund ist, dass der (Haupt-)µC gewisse Funktionen schaltet und extern >durch einen weiteren µC (Watchdog) überwacht wird. Dann muss das auf dem Überwachungs-µC laufende Programm deutlich sicherer sein als das des Haupt-µCs (sonst macht das Konzept keinen Sinn). Wenn Du aber in der Lage bist, zwei Programme zu schreiben, von denen das zweite viel sicherer ist als das erste, warum machst Du dann nicht gleich das erste sicher?
Speedy schrieb: > Die Tatsache, dass das RAM den Reset > überlebt, ist vermutlich die sinnvollste Option Aber auch da muß Dein Programm die Werte aktiv in die entsprechenden Variablen sichern oder Du mußt es so schreiben, daß Du Variablen verwenden kannst, mit denen Du ohnehin schon arbeitest. Jedenfalls darf so eine Variable nie einen Wert haben, der nicht unmittelbar vorher oder nachher auch ausgegeben wird, denn es könnte ja jederzeit ein Reset auftreten.
Und nicht vergessen. Je nach deinem Programm reicht es nicht aus, sich einfach nur die aktuelle Porteinstellung zu merken. Dein Programm kann beim Reset in einem bestimmten Zustand sein, den man unter Umständen wieder genau so restaurieren muss. Bsp: Der Prozessor steuert einen Schlitten, der links/rechts verfährt. Immer von einer Endlage in die andere (zb Drucker). Kommt der Watchdog, reicht es nicht, die I/O Pins wieder exakt zu restaurieren, du musst auch noch wissen in welche Richtung du zuletzt gefahren bist. Das ist jetzt nur ein simples Beispiel, das ich mir auf die schnelle ausgedacht habe. Bei deinem Programm mag das überhaupt keine Rolle spielen oder aber es kann auch ziemlich kompliziert sein nach einem Reset die Dinge wieder ins Rollen zu bringen und dort weiterzumachen, wo man zuletzt gehangen ist.
Gastofatz schrieb: > Dann muss das auf dem Überwachungs-µC laufende Programm deutlich > sicherer sein als das des Haupt-µCs (sonst macht das Konzept keinen > Sinn). Wenn Du aber in der Lage bist, zwei Programme zu schreiben, von > denen das zweite viel sicherer ist als das erste, warum machst Du dann > nicht gleich das erste sicher? Das eine hat mit dem anderen nichts zu tun, der Watchdog muss keinesfalls sicherer sein als der Haupt-µC. Abgesehen davon ist die Überwachung selbstredent bidirektional, ansonsten würde der Watchdog schließlich nicht wirklich für mehr Sicherheit sorgen.
> as eine hat mit dem anderen nichts zu tun, der Watchdog muss > keinesfalls sicherer sein als der Haupt-µC. und was ist wenn durch ein Fehler im Watchdog der anderen µC immer ein reset macht? Ich würde auch sagen damit erhöhst du die komplexität und baust mehr Fehlerquellen rein als man mit einem µC hätte.
>Ich würde auch sagen damit erhöhst du die komplexität und baust mehr >Fehlerquellen rein als man mit einem µC hätte. Das ist der Punkt.
Ich glaube hier liegt ein Missverständnis vor. Der Watchdog prüft natürlich nicht, ob die SW auf dem Haupt-µC korrekt programmiert wurde, das wäre tatsächlich nicht sinnvoll (Ausnahmen bestätigen die Regel). Hier geht es um Fehlerursachen auf Grund externer Einwirkungen, sprich Defekte des µC.
Speedy schrieb: > Hier geht es um Fehlerursachen auf Grund externer Einwirkungen, sprich > Defekte des µC. Ich wußte gar nicht, daß man einen defekten µC einfach dadurch reparieren kann, daß man einen Reset auslöst. ;) SCNR
@Speedy (Gast)
>Ich glaube hier liegt ein Missverständnis vor.
nein, denke ich nicht.
Was ist wenn etwas bei der überwachung von µC schief geht? Wenn also der
Watchdog kein Signal vom Haupt µC bekommt? Ist der µC Tot, ist die
Leitung gestört, ist es ein Software fehler im Watchdog? Das alles kann
die Ursache sein und damit müsste man den Haupt µC resetten. Wenn es
jetzt aber ein Software fehler im Watchdog war dann war der reset
umsonst und du hast damit einen neuen Fehler erzeugt.
Ich würde lieber mehr zeit in die Software stecken, das dort möglichst
wenig Fehler drin sind und nicht so sehr veruchen das Problem mit einem
externen Watchdog zu umgehen.
Peter schrieb: > @Speedy (Gast) >>Ich glaube hier liegt ein Missverständnis vor. > nein, denke ich nicht. Doch, doch ;-). Ich zitiere Dich selbst nochmal: Peter schrieb: > Ich würde lieber mehr zeit in die Software stecken, das dort möglichst > wenig Fehler drin sind und nicht so sehr veruchen das Problem mit einem > externen Watchdog zu umgehen. Wie ich oben schrieb, geht es hier nicht um die Entdeckung von SW-Fehlern. Das die Programmierung eines Watchdogs und einer 2-Ebenen oder vielleicht sogar 3-Ebenen-Überwachung nicht trivial ist, ist mir schon klar. Ich erarbeite beruflich entsprechende Sicherheitkonzepte, ich gestehe mir zu, diesbezüglich einen gewissen Überblick zu haben :). Wenn der Sinn des Watchdogs dennoch unklar sein sollte, kann ich gerne mal das Konzept etwas ausführlicher erläutern, das werden dann aber ein paar mehr Sätze. R. Max schrieb: > Ich wußte gar nicht, daß man einen defekten µC einfach dadurch > reparieren kann, daß man einen Reset auslöst. ;) > > SCNR Sehr lustig ;). Aber der Vollständigkeit halber siehe: Beitrag "Re: Zustand I/Os nach Reset bei ATmega" :-P
>Wenn der Sinn des Watchdogs dennoch unklar sein sollte, kann ich gerne >mal das Konzept etwas ausführlicher erläutern Wär vielleicht gar nicht so schlecht, wenn dieses Forum genau dazu mal mit ein paar kompetenten Sätzen beschenkt würde. Du bist Profi - leg los! :-)
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.