Uhrzeit sinnvoll im EEprom speichern

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • ich nehme an, @Michael meint die 'modernen' Funkuhren. Die älteren Nebenuhren haben nix dergleichen drin. Die sind ja auch in der Regel alle parallel geschaltet und mit der Mutteruhr verbunden.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Taugt ein IButton der Dallas DS1994, oder 1995, oder 1996 Serie mit dem Dallas 1 Wire Protokol dafür etwas?
      Okay man müsste den Halter für den Button mit organisieren, oder recherchieren ob solche Buttons in diverse Batteriehalter passen.
      Ich verwende für ähnliche Dinge den RTC Baustein DS1307. Dieser hat in seiner internen Uhr auch 56 Ram Bytes. Wenn die Dir reichen, genügt ein DS1307. ;)
    • Tachchen,

      ich habe schon einige Jahre etliche alte riesige Bahnhofsuhren mit DCF selbststellend in Betrieb.
      Die Uhren mussten noch nie nachgestellt werden.
      Das erste Stellen erfolgt einfach aus der Eingabe des tatsächlichen momentanen Zifferblattstandes über das Display.
      Die Differenz zur echten Zeit wird dann im Programm verrechnet.
      Nach der DCF-Synchronisation tackern die Zeiger zur aktuellen Zeit.
      Der Netzausfall wird mit einem Analogeingang am Ladeelko erfasst (wichtig dabei !!! Schutzbeschaltung mit Teiler 2:1 + Klammerdiode) .
      Nur bei Spannungsausfall wird damit der aktuelle Ziffernblatt-Stand ins EEprom geschrieben und beim Neustart zurückgelesen.
      Man muss auch das Richtungs-Bit der Uhr mit abspeichern.
      Mein Beispiel ist für eine Arduino Uno mit LCD-Shield geschrieben.
      Bei der Programmieriung muss am Analogeingags-Teiler mehr als 8V anliegen, sonst wird sofort die Speicherungs-Routine ausgelöst.
      Oder das Service-Bit auf 1 setzen..
      Viel Spaß damit
      Dateien
    • Michael schrieb:

      Nach dem Wiedereinschalten (Taster ist diesmal nicht gedrückt) und der Synchronisation mit DCF77 taktet die Uhr minütlich weiter.
      Es gibt eine Differenz, die der Stromausfallzeit entspricht.

      Die Idee ist nun, den internen EEprom jede Minute mit der aktuellen Uhrzeit zu beschreiben. Die kann er sich nach dem Stromausfall holen und feststellen, welche Differenz seitdem besteht und entsprechend nachtakten.
      Soweit klar Michael.
      Aber was spricht dagegen, die Idee von @Eber58 zu verwenden?
      Er speichert nicht die letzte aktuelle Realtime und dies ständig, sondern er speichert nur bei Netzausfall den letzten Stand des Ziffernblattes (Uhrzeit)
      Nach dem Wiedereinschalten kann man die letzte Uhrzeit lesen, mit DCF vergleichen und die Differenz zum Vorrücken bilden.

      Finde das einen guten Ansatz...
      Code first, think later - Natural programmer :D
    • Das verstehe ich jetzt nicht. Du benötigst keine Hardware Änderung.
      Nach einem einmaligen Einstellen der Uhr, musst du nie mehr dran und benötigst keinerlei Rückmeldungen von Deiner Uhr.

      Edit:
      Achso, du kannst den Netzausfall nicht mitbekommen....
      Naja, dann bleibt, die aktuelle Stunde und Minute zu speichern...


      ...und na klar, die Antwort ist 42


      Ich würde die Stunden in ein eigenes Byte ins EEram schreiben. Ein Byte sollte ~11 Jahre für die Stunden halten. Mit Pointer auf weitere mögliche 5 Bytes, bist du höchstwahrscheinlich aus der Garantie raus :D
      Die Minuten dann mit Pointer und Schreib-Lese Routine auf die restlichen verbleibenden Bytes.
      Code first, think later - Natural programmer :D
    • six1 schrieb:

      Ich würde die Stunden in ein eigenes Byte ins EEram schreiben.
      Das macht es langlebiger : Das Stundenbyte bis 252 hochzählen lassen sind 10,5 Tage bis zum "Überlauf"
      macht weit über 2000 Jahre. Dann das Minuten byte bis 240 Zählen lassen = 1/6Tag macht knapp 70 Tage bis zum Wechseln mal 198 nutzbare Byte wären über 35 Jahre. Dazu noch ein Zeigerbyte was die Überläufe zählt um das nächste auszuwählen. Evt noch eins das auf das aktuell genutzte Minutenbyte zeigt. Das kann entfallen wenn die verbrauchten mit z.B. 245 beschreibt, oder eine Routine das erste sucht in dem nicht 255 steht.
    • Hmm so ein EEPROM Fehler entsteht ja auf der Bitebene, wenn die Oxidschicht vom FET durch Umladung soweit zerstört wurde, dass keine Bitänderung mehr messbar ist. Wäre interessant, ob man für solche Counter die Lebensdauer einer EEPROM Zelle erhöhen kann, wenn man statt der normalen Zahlendarstellung einen Gray-Code verwendet, bei dem sich von einem Schritt zum nächsten nur jeweils ein Bit ändert.
      Hat das mal jemand versucht bzw weiß genaueres?

      edit: das müsste von der HW-Implementierung des EEPROMs abhängen, Gray-Code in einem Byte würde bitgenaues Erase&Write vorraussetzen. Wenn der Erase&Write Zyklus auf Byte-Ebene organisiert ist, könnte man den ursprünglichen 8-Bit Gray-Code eben auf 8 Speicherzellen verteilen, wobei man jedes Byte nur als Bit behandelt. Wenn das EEPROM zb. in 64-Byte Blöcken organisiert ist, dann nimmt man nur jedes 64. Byte, gilt auch für 10- oder 16-Bit Gray-Code usw.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von zaubara ()

    • Ich habe jetzt eine zufriedenstellende Lösung gefunden, bei der die anfangs leeren EEprom-Words so lange dekrementiert werden, bis der Wert 15 drin steht.
      Eine Schleife am Programmanfang sucht sich aus einem Array die erste Speicherstelle mit einem Wert > 15 und hat damit auch den Index.
      Der Wert 15, weil das übrig bleibt, wenn 91x720(Minuten pro Halbtag) vorbei sind.
      91 Halbtage sind 45,5 Tage, bei 200 Zellen ist der Speicher in 24,9 Jahren voll und dann fängt alles von vorne an. Die Zellen werden dann in 50 Jahren 131000 mal beschrieben, das sollten sie aushalten und ich bin dann schon knapp 10 Jahre tot ;)
      Die Lösung kommt ohne abzuspeichernde Zählervariablen aus, da könnten eigentlich auch alle 255 Zellen beschrieben werden und dann wäre der Überlauf nach knapp 32 Jahren. (1 Zelle hebe ich auf für den Zähler für die Überläufe. Den würde ich dann bei Defekt auslesen wollen ;) )

      Wearlevelling.png
    • :thumbsup:
      so wird jede Zelle 193 mal benützt und dann zur nächsten gesprungen. Was durch den Neubeginn kein Problem darstellt. Dann wird den oberen nicht so langweilig als würden sie zig Jahre auf ihre Benutzung warten

      Michael schrieb:

      Den würde ich dann bei Defekt auslesen wollen
      Damit müßte er ein wenig mehr Schreibzyklen überleben als seine Kollegen. (Das 200/193 fache)

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Pluto25 ()

    • Pluto25 schrieb:

      o wird jede Zelle 193 mal benützt
      Verstehe nicht.
      Ich schreibe in eine Zelle (Word) 65520 mal rein

      Pluto25 schrieb:

      Damit müßte er ein wenig mehr Schreibzyklen überleben als seine Kollegen
      Der Überlauf zählt die kompletten Überläufe (25 Jahres-Zyklus), der geht sicher nicht kaputt ;)

      six1 schrieb:

      Würdest du jede Zelle kaputt schreiben nach meinem Vorschlag,
      Dann hätte ich das Problem wie bereits beschrieben. Ich würde nur richtig kaputte Zellen erkennen. Fällt der Strom mal länger aus, dann ist die Ladung weg und die vorher noch als gut befundene ist plötzlich tot.
    • Michael schrieb:

      Verstehe nicht.
      Ich schreibe in eine Zelle (Word) 65520 mal rein
      Dein Word beginnt mit FF FF nach 193 Änderungen sorry 240 Änderungen ist es FF 0F .
      Im EEprom mit 0F(15) FF abgelegt. Somit wird die erste Zelle verworfen.
      Und der Zähler überlebt (200/240) :D
      Noch immer verkehrt a_45_132ca9f5
      die ersten Zwei Zellen werden wirklich 65520 mal beschrieben die zweite wird jedoch übersprungen nachdem sie bei FF00 (00FF im EEprom) angekommen ist also nach 255 mal. Dann steht im EEprom 15 00 FF. Und es geht von Vorn los.
      Immer noch falsch. Ich glab der Glühwein wirkt nach a_71_f9c57bbe
      Aber ein Problem besteht wirklich. Ist lange Zeit der Strom nicht ausgefallen steht 0F 0F 0F... Im EEprom was als 3855 interpretiert wird wodurch er nach einem Stromausfall wieder vorn beginnen würde.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Pluto25 ()

    • Eine Zelle = Speicherzelle = Word = 2Bytes
      Ich hab 512 Bytes und nehme davon bis zu 255 Words für 255 Speicherzellen.
      Weil die letzten beiden Bytes, davon brauch ich ein Byte zum zählen, wie oft alles schon übergelaufen ist. Da diese letzte Zelle zu meinen Lebzeiten maximal 2 mal beschrieben wird, ist es unwahrscheinlich, dass sie überlastet wird ;)