Hi,
ich würde gern mal eure Meinung hören, welche Option des Datenbackups im
Fehlerfall die bessere ist.
Ich habe eine Uhr auf Basis eines Atmega 328p gebaut und programmiert.
Programmiert habe ich in C++. C++ einfach um das ganze objektorientiert
machen zu können. Da ich die Uhr auch als Wecker benutzen will und der
natürlich zuverlässig sein soll, habe ich also einen Watchdog
aufgesetzt. Alles tip top.
Es soll nun im Falle eines Watchdog-RESET die Uhrzeit, Alarm und eine
handvoll Einstellungen gesichert und anschließend wiederhergestellt
werden. Ich sehe hier prinzipiell 2 Möglichkeiten.
1. Ich richte einen Watchdog-Interrupt ein, der alles nötige in den
EEPROM schreibt. Beim Start wird festgestellt ob ein Watchdog-RESET
aufgetreten ist und wenn ja laden wir wieder alles aus dem EEPROM
2. Man definiert eine handvoll Backup-Variablen nach dem Schema
Sollte ein Watchdog-RESET auftreten, bleibt deren Wert erhalten und kann
anschließend wiederhergestellt werden.
Prinzipiell kommt mir Möglichkeit 2 einfacher vor, allerdings bin ich am
grübeln, ob es da Probleme bzgl fehlender Initialisierung o. Ä. geben
könnte. Die Menge der zu sichernden Daten beläuft sich auf ca. 10 Byte.
Meinungen?
Watchdog bei einer simplen Uhr? Wass nich all gibbt!
Bei meinem Wecker, assemblerprogrammiert, gibt es nur das Problem des
Netzausfalles (da eben netzgebunden), und da hilft nur Methode 1, aber
auch die nur bei entsprechender Berücksichtigung in der Hardware.
Hannes J. schrieb:> Sollte ein Watchdog-RESET auftreten, bleibt deren Wert erhalten und kann> anschließend wiederhergestellt werden.
Machbar!
Aber dann nicht diverse Sicherungsmaßnahmen vergessen...
Denn nach einem WDT Reset kannst du dich auf rein gar nichts mehr
verlassen.
Arduino Fanboy D. schrieb:> Denn nach einem WDT Reset kannst du dich auf rein gar nichts mehr> verlassen.
Insbesondere nicht, ob die Daten nicht genau im Moment des
Watchdog-Resets bearbeitet wurden und somit inkonsistent sind. Wenn der
Watchdog ein derartiges Problem darstellt, sollte man vielleicht lieber
den Code korrigieren sodass der Watchdog nicht auslöst.
Dr. Sommer schrieb:> Arduino Fanboy D. schrieb:>> Denn nach einem WDT Reset kannst du dich auf rein gar nichts mehr>> verlassen.>> Insbesondere nicht, ob die Daten nicht genau im Moment des> Watchdog-Resets bearbeitet wurden und somit inkonsistent sind. Wenn der> Watchdog ein derartiges Problem darstellt, sollte man vielleicht lieber> den Code korrigieren sodass der Watchdog nicht auslöst.
Ich gehe schon davon aus, dass der Watchdog nicht auslöst, keine Sorge.
Er ist ganz watchdog like dazu da um im besten Fall niemals gebraucht zu
werden, im Fall der Fälle aber da zu sein. Und da die Uhr schon einige
Features hat, begonnen bei der Helligkeitsregelung der
7-Segment-Anzeigen entsprechend der Umgebungs-Helligkeit bis hin zum
Zeitempfang über WLAN mittels I2C-Kommunikation mit einem ESP8266, sowie
Sommer- / Winterzeit-Management kann man eben nie ausschließen, dass es
nicht im Laufe der nächsten Jahre eben doch mal irgendwo hängt.
Okay das schreiben während eines RESET ist ein wichtiger Punkt. Also
sollte wenn überhaupt ein Backup in den .noinit-Bereich nur geschrieben
werden, wenn der Watchdog-Timer auch gerade zurückgesetzt wurde. Beim
Start werden die Daten natürlich nur angerührt wenn im MCUSR das WDR
Flag gesetzt ist. Außerdem würde ich ein Flag setzen um sicherzugehen,
dass überhaupt Daten gespeichert wurden. Sollte dann passen oder?
Hannes J. schrieb:> Also> sollte wenn überhaupt ein Backup in den .noinit-Bereich nur geschrieben> werden, wenn der Watchdog-Timer auch gerade zurückgesetzt wurde.
Du weißt nie, wann er zuschlägt.
Da irgend welche Annahmen zu treffen, ist unsinnig.
Hannes J. schrieb:> Sollte dann passen oder?
Hmmm ....
Stopfe alle Daten in eine Struktur
Berechne eine Prüfsumme(oder vergleichbares) und schreibe diese auch.
Vor dem nutzen der Daten, dann die Merkmale prüfen.
Das gilt übrigens auch fürs EEPROM.
Bei einer Weck-Uhr die aktuelle Uhrzeit zum Watchdog-Reset zu
speichern ist doch Quatsch.
Die Einstellungen, wie Weckzeit - und was auch immer - speichert
man vernünftigerweise sofort in's EEPROM. Das kannst du 100.000
mal machen, also über 27 Jahre 10 mal am Tag.
Die Zeit kannst du aber nur über DCF, GPS, oder Handeingabe wieder
auf den aktuellen Wert bringen.
Einen Wecker würde ich dann lieber (auch nachts) wild alarmieren
lassen, dass er nach einem Stromausfall-, oder Watchdog-Reset
keine aktuelle Zeit mehr hat.
Sonst verpasst du sicher den Start zu deiner sündhaft teuren
Traumreise...
Ein Watchdog Reset fuer eine Uhr bringt gar nicht. Denn der besagt, dass
der Reset kam. Was du willst ist ein Interrupr bevor der Power weggeht.
Und in diesem schreibst du dein Zeug ins EEPROM. Bei einem Powerup liest
du die Daten vom EEPROM. Ohne zu wissen, was dazwischen war.
Am Sinnvollsten nimmst du einen Uhrenbaustein mit einer kleinen
Batterie. Die hat auch vielleicht 64 byte Speicher. Der Vorteil .. sie
laeuft ab Batterie durch einen Powerunterbruch weiter.
Jacko schrieb:> Die Einstellungen, wie Weckzeit - und was auch immer - speichert> man vernünftigerweise sofort in's EEPROM. Das kannst du 100.000> mal machen, also über 27 Jahre 10 mal am Tag.
Full ACK.
In meinen Designs verwende ich dafür meist ein per SPI angeschlossenes
FRAM oder MRAM, dann muss man nicht auf Schreibvorgänge eines lahmen
EEPROMs warten und hat auch bei häufigerem Schreiben keine
Lebensdauer-Problematik.
> Die Zeit kannst du aber nur über DCF, GPS, oder Handeingabe wieder> auf den aktuellen Wert bringen.
Die naheliegendste und einfachste Möglichkeit hast du nicht erwähnt:
Ein RTC-Chip, gepuffert mit Batterie Akku SuperCap, je nach
Anforderungen an die überbrückbare Stromausfalldauer.
Manche RTCs haben sogar einen Alarmkomparator, der einen Ausgang
ansteuern kann. Wenn der μC den jeweils nächsten Alarm da reinlädt, kann
man über diesen Ausgang sogar einen Notfall-Alarm z.B.über einen
batteriegespeisten Piezoheuler auslösen, ohne dass der μC zur Alarmzeit
laufen muss...
Wenn der Watchdog den Controller resettet hat, ist irgendwas im Argen,
da würde ich auch eher einen Alarm auslösen, bzw. einen Zähler im FRAM,
EEPROM oder im CMOS-RAM der RTC inkrementieren und bei Überschreiten
eines Schwellwertes Alarm schlagen, der dem Benutzer den Fehler meldet.
Wenn man z.B. mit jedem Tag Uptime des Controllers den Zähler
dekrementiert (nur bis 0), kann man den Alarm auch nur bei mehr als
einem Watchdog-Event pro Tag auslösen...
Ich würde auch sagen, dass eine Erkennung von Stromausfall eher Sinn
macht. Der Watchdog triggert dann aber schon zu spät. Den Stromausfall
musst du erkennen, bevor die Pufferkondensatoren erschöpft sind und die
Spannungsversorgung absackt. Also vor dem Spannungsregler, besser noch
sogar vor dem Gleichrichter.
Wenn mein µC ohne Watchdog nicht dauerhaft funktioniert, ist entweder
das Programm oder die Hardware fehlerhaft. Als Entwickler möchte ich das
mitbekommen, der µC soll nicht klamm-heimlich einfach neu starten.
Normalerweise laufen Mikrocontroller ohne Ausfall durch - jahrelang.
Dass sie sich unerwartet zwischendurch aufhängen ist eher eine seltene
Ausnahme.
Arduino Fanboy D. schrieb:> Hannes J. schrieb:>> Also>> sollte wenn überhaupt ein Backup in den .noinit-Bereich nur geschrieben>> werden, wenn der Watchdog-Timer auch gerade zurückgesetzt wurde.>> Du weißt nie, wann er zuschlägt.> Da irgend welche Annahmen zu treffen, ist unsinnig.>>> Hannes J. schrieb:>> Sollte dann passen oder?>> Hmmm ....>> Stopfe alle Daten in eine Struktur> Berechne eine Prüfsumme(oder vergleichbares) und schreibe diese auch.>> Vor dem nutzen der Daten, dann die Merkmale prüfen.> Das gilt übrigens auch fürs EEPROM.
Perfekto, so mache ich das.
Zu allen Kommentaren die später noch kamen kann ich nur sagen, ihr habt
entweder nicht alles komplett gelesen was ich geschrieben habe, es nicht
verstanden oder ihr stellt irgendwelche Aussagen auf Grund von
Vermutungen über mein Design an, von dem ihr letztlich nicht die
geringste Ahnung habt. Aber das gehört wohl zu mikrocontroller.net, dass
jeder Thread iwann in sinnlosem Kluggescheiße endet.
> ihr habt entweder nicht alles komplett gelesen was ich geschrieben> habe, es nicht verstanden oder ihr stellt irgendwelche Aussagen auf> Grund von Vermutungen über mein Design an, von dem ihr letztlich nicht> die geringste Ahnung habt.
Wir helfen gerne. Punkt.
Wenn der Fragende (also du) zu wenig Infos über sein Projekt verrät,
erzählen Leute aus ihrem Erfahrungsschatz Sachen, die sie für eventuell
hilfreich halten. Ja, manchmal artet das dann zu einer regelrechten
Rate-Orgie aus, die am Ende nur Verwirrung stiftet.
Deswegen: Lerne, deine Fragen vernünftig zu stellen, dann bekommst du
auch vernünftige Antworten.
Im übrigens ist es in diesem Thread beinahe vorbildlich abgelaufen. Alle
Antworten waren zum Thema passend, sind auf deine Angaben eingegangen
und enthalten gut gemeinte Ratschläge.
Stefanus F. schrieb:>> ihr habt entweder nicht alles komplett gelesen was ich geschrieben>> habe, es nicht verstanden oder ihr stellt irgendwelche Aussagen auf>> Grund von Vermutungen über mein Design an, von dem ihr letztlich nicht>> die geringste Ahnung habt.>> Wir helfen gerne. Punkt.>> Wenn der Fragende (also du) zu wenig Infos über sein Projekt verrät,> erzählen Leute aus ihrem Erfahrungsschatz Sachen, die sie für eventuell> hilfreich halten. Ja, manchmal artet das dann zu einer regelrechten> Rate-Orgie aus, die am Ende nur Verwirrung stiftet.>> Deswegen: Lerne, deine Fragen vernünftig zu stellen, dann bekommst du> auch vernünftige Antworten.>> Im übrigens ist es in diesem Thread beinahe vorbildlich abgelaufen. Alle> Antworten waren zum Thema passend, sind auf deine Angaben eingegangen> und enthalten gut gemeinte Ratschläge.
Es sind doch alle notwendigen Infos da und die gestellte Frage wurde
zufriedenstellend beantwortet.
Dann fingen plötzlich ein paar an den watchdog ansich infrage zu stellen
und schrieben etwas von eeprom generell benutzen, was wiederum in
Anbetracht der wenigen Infos zum gesamten Design (wohl aber ausreichend
um die eigentliche Frage zu beantworten) ziemlich fragwürdig scheint.
Am besten ist der Kommentar von Chlorophor. Man versteht hauptsächlich
Bahnhof, weil kein einziger halbwegs fehlerfreier Satz zu finden ist,
aber iwas steht da von wegen man wüsste ja nicht was zwischen power off
und power on passiert sei. Er hat offensichtlich nicht im geringsten
verstanden worum es geht oder was ein watchdog ist.
Und als nächstes kam noch eine Fraktion die etwas von Stromausfall
faselte, was nun wirklich völlig am Thema vorbei geht. Was hat ein
watchdog mit fehlendem Strom zu tun? Nullum! Dann noch dein Hinweis ein
Programm sollte ohne watchdog laufen, sonst habe man etwas falsch
gemacht. Ja, genau das hat der TO in seinem ersten Kommentar ja selbst
geschrieben. Es geht um eine Absicherung gegen Programmierfehler. Also
genau das wofür das Konzept watchdog existiert.
Also so wie ich das sehe ist der TO zum Schluss etwas zickig geworden,
aber durchaus nachvollziehbar. Alles nach Arduino Fanboy war sinnloses
Geschwurble.