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 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! :-)
