eeprom vs ram vs flash

#4009695
Lesenswert?

Hallo,

ich habe ein Programm was regelmäßig Daten sichert. Diese Daten müssen 
jedoch nach trennen und wieder verbinden der Versorgungsspannung 
erhalten bleiben.

Nach hochrechnung würde ich, je nach laufzeit, nach, je nach Datenmenge, 
die nur geschätzt werden kann, nach ca 2 Wochen schon die 100.000 
schreibzyklen überschreiten.

Was ist nun sinnvoller?

1. Die Daten extern in einem Ram puffern und bei unterschreiten der 
Versorgungsspannung durch die restversorgung und "schutzschaltung" durch 
den Elko die Daten erst dann in den eeprom schreiben?

2. Die Daten mittels progmem im Flash sichern und bei unterschreiten der 
Versorgungsspannung in den eeprom sichern?


Was passiert mit dem eeprom nach überschreiten? Klar kann er ggf mehr 
aber was ist wenn "ende" ist? Gibt es externen eeprom? Läuft der uC 
trotz "toten" eeprom trotzdem weiter, kann jedoch nichts mehr speichern?

Bei der möglichkeit mit dem externen Ram muss ich den Elko vermutlich 
erhöhen da dieser ja dann den Ram ebenfalls versorgen muss, richtig?

Wie schnell geht das auslesen des Rams und schreiben in den eeprom um 
die Entladezeit des Elkos zu berechnen?

Es handelt sich um drn ATMega128A mit 16Mhz Quarz. Zurzeit befindet sich 
an den Versorgungspins ein 1000uF 16V gepolter Elko.

Danke.
#4009704
Lesenswert?

@ Rene H. (ballibou)

>die nur geschätzt werden kann, nach ca 2 Wochen schon die 100.000
>schreibzyklen überschreiten.

>1. Die Daten extern in einem Ram puffern

Warum extern? Hast du keinen internen RAM?

> und bei unterschreiten der
>Versorgungsspannung durch die restversorgung und "schutzschaltung" durch
>den Elko die Daten erst dann in den eeprom schreiben?

Ja.

>2. Die Daten mittels progmem im Flash sichern und bei unterschreiten der
>Versorgungsspannung in den eeprom sichern?

Nein.

>Was passiert mit dem eeprom nach überschreiten?

Der Schreibvorgang wird unzuverlässig. Es werden irgendwann Bitfehler 
auftreten.

> Klar kann er ggf mehr
>aber was ist wenn "ende" ist? Gibt es externen eeprom?

Sicher, die 24er.
Oder FRAM, der hat Milliarden von Schreibzyklen.
Oder man verteilt die Schreibzyklen intelligent über mehrere Zellen.

>Läuft der uC
>trotz "toten" eeprom trotzdem weiter, kann jedoch nichts mehr speichern?

Ja.

>Bei der möglichkeit mit dem externen Ram muss ich den Elko vermutlich
>erhöhen da dieser ja dann den Ram ebenfalls versorgen muss, richtig?

Du brauchst keinen externen RAM.

https://www.mikrocontroller.net/articles/Speicher#EEPROM_Schreibzugriffe_minimieren

>Es handelt sich um drn ATMega128A mit 16Mhz Quarz. Zurzeit befindet sich
>an den Versorgungspins ein 1000uF 16V gepolter Elko.

Siehe oben.
#4009740
Lesenswert?

Rene H. schrieb:
> Nach hochrechnung würde ich, je nach laufzeit, nach, je nach Datenmenge,
> die nur geschätzt werden kann, nach ca 2 Wochen schon die 100.000
> schreibzyklen überschreiten.

Die Hochrechnung würden wir gerne sehen. Das wäre eine gute 
Informationsquelle. Und beschreibe und bitte die Anforderungen und was 
es werden soll.

Oft steht man zu nahe an der eigenen Lösung des Problems und sieht nur 
diese. Dann sehen frische Augen oft noch andere Wege die teilweise auch 
sehr viel einfacher sind.
#4010742
Lesenswert?

Naja, irgendwie habt ihr schon recht. Aber irgendwie wird sich Rene 
schon was dabei gedacht haben, auch wenn die Ansätze z.T. etwas krude 
sind.
FRAM ist ne geniale Möglichkeit, sich derartige Probleme vom Hals zu 
schaffen. Vor allem ist es schnell und für kleines Geld erledigt.
Vorausgesetzt, das Problem existiert tatsächlich:
-Flash schreiben ist Quatsch
-im RAM halten und bei Bedarf ins EEPROM schreiben ist natürlich 
möglich, erfordert aber eine ausreichend frühe Erkennung des drohenden 
Versorgungsausfalls und ausreichend schnelle Bearbeitung für alle 
relevanten Daten
-externes RAM mit Batterie? Naja, ich versuch Batterien zu vermeiden, 
solange ich keine RTC im System habe
-verteiltes Schreiben im EEPROM - klar, geht. Hat aber auch Grenzen. Und 
man muss schon ein wenig aufpassen dabei.

Mit nem FRAM ist das alles kein Thema. Ist auch ne Frage der Stückzahl. 
Sind es wirklich viele, kannn man sich Gedanken machen, wie das 
MC-intern erledigt werden kann.
#4010932
Lesenswert?

Carsten R. schrieb:
> Die Hochrechnung würden wir gerne sehen. Das wäre eine gute
> Informationsquelle. Und beschreibe und bitte die Anforderungen und was
> es werden soll.

Genau!
Bisher stochern wir alle nur im Nebel.

Trotzdem mal ein Beispiel:
Ich hab ein Gerät, was sich Benutzereinstellungen merken soll.
Die Strategie ist ganz einfach. Ändern sich Werte und bleiben für 1s 
konstant (konstante CRC), wird gespeichert. Danach wird eine 
Schreibpause von 10s eingelegt. Damit hat man so selten Schreibzugriffe, 
daß es mindestens ein Leben lang reicht. Bzw. eher sind die 
Tasten/Drehgeber hinüber.

Nur in seltensten Fällen lohnt sich ein zusätzlicher FRAM/MRAM.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren