www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Zustand I/Os nach Reset bei ATmega


Autor: Speedy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Klemm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Speedy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Speedy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: GenKlon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich würde mit einer if-Schleigfe die I/Os abfragen

Autor: Thomas K. (muetze1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
www.if-schleife.de grml wie ich es hasse...

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Speedy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gastofatz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Speedy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Gastofatz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Speedy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Speedy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gastofatz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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! :-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.