EEPROM Fehler verwalten

Ich denke der Ansatz ist falsch. Ich wuerde solche Speicher einsetzen 
die das Gewuenschte koennen. Wieviel Byte fallen pro Zeiteinheit an und 
wie oft wird das Ganze wieder ueberschrieben? Dh die gewuenschte 
Lebendauer.

Weder die IDE (welche denn?) noch der Atmel selbst behandeln 
EEPROM-Fehler. Andernfalls müsste das im Datenblatt bzw. dem Manual der 
IDE stehen. Eine "Intransparenz" ist nicht vorhanden.

Die open-source IDE, welche direkt von Arduino kommt. Schade, dann muss 
ich mich selbst drum kümmern. Ich habe bloss den EEPROM schon oft 
beschrieben, bei der Messung selbst sind ca. alle 2-3 Sekunden 3 Byte an 
Daten zu erwarten.

> Jetzt gibt es das Problem, dass ich nicht weiß, wie die IDE das intern
> verwaltet und kompiliert, ...
Verwaltet wird's durch den Compiler bzw. eher den Linker.

> ... es könnte ja auch sein, dass schon in der Software defekte Zellen
> erkannt und dementsprechen "behandelt" werden.
Sowohl dem Compiler als auch dem Linker ist das völlig wurscht, deren 
Daseinszweck ist nur, dass dein C/Assembler-Programm in eine 
Controller-verständliche Sprache bzw. Instruktionen umgesetzt werden.

> Auch könnte es ja sein, ich weiß es aber nicht genau, dass der
> AtMega2560 hardwareintern solche Zellen erkennt oder sogar eine Tabelle
> mit Bad Blocks, ähnlich wie Flash enthält, kann das sein?
Ich wüsste keinen einzigen Controller, der sowas eingebaut hat - das 
würde die Kosten wahrscheinlich extrem hochjagen.
SSD-Controller machen sowas, aber auch nur in Firmware, sprich da steckt 
eben Hirnschmalz vom Softwerker dahinter.
Soweit ich weiss, ist die Hardware-Erkennung solcher Fehler auch "nur" 
eine Checksumme über ein bzw. mehrere Bytes (grob gesagt) bzw. ein paar 
Prüfbits, wenn die einen Fehler erkennen lassen, wird's 
wahrscheinlich(?) auch nur wieder per Software versucht ausgebügelt zu 
werden.

> Wegen dieser Intransparenz kann ich den Zustand des EEPROMs jetzt leider
> nicht verfolgen, es wäre aber für das Loggen ziemlich wichtig, gibt es da
> eine Möglichkeit?
Ja, die gibt's, du zählst einfach mit, wie oft du einen bestimmten 
Bereich geschrieben hast.
Beispiel:
1024 Byte EEPROM insgesamt, benötigte Speichergröße für's Projekt 64 
Bytes, Zählervariable 4 Byte = 68 Byte.
Wenn du ans maximal garantierte Schreiblimit kommst, markierst du mit 
dem Zähler den "Datenblock" als untauglich, und verwendest den nächsten 
Block.
Macht bei 1024/68 -> 15 x Schreiblimit. Das wäre jetzt ein simpler 
Ansatz(!) und dürfte relativ leicht in Software umzusetzen sein.
Kommt natürlich drauf an, wie schnell und wieviel du loggst, denn da 
kann sich ein externer Speicher evtl. eher lohnen.

Ralf

Danke Ralf für deine sehr ausführliche und hilfreiche Antwort! Ich werde 
den Ansatz umsetzten, danke!

Ralf schrieb:
> Ja, die gibt's, du zählst einfach mit, wie oft du einen bestimmten
> Bereich geschrieben hast.

Damit nützt er aber das EEPROM bei weitem nicht aus - das ist nur eine 
worst case Angabe, i.A. vertragen die Zellen sehr viel mehr 
Schreibvorgänge.

Man muss nur aufpassen, dass man nicht nur in einen Bruchteil des 
EEPROMs schreibt, sondern dass die Daten gleichmässig verteilt werden 
(siehe Wearing bei SSDs).

Gruss Reinhard

Du könntest die Messwerte immer in die nächste freie Speicherzelle 
schreiben. Beim lesen suchst Du die letzte nicht leere Zelle, die 
enthält den aktuellsten Wert. Wenn der ganze Speicher voll ist, löschst 
Du ihn
wieder und fängst von vorne an.

Damit kannst Du dann zwar nicht einzelne defekte Zellen ausschließen, 
aber immerhin den ganzen Speicher so lange nutzen, bis der erste Defekt 
auftritt. Durch die Verteilung auf alle Speicherzellen dürfte es bis 
dahin schon recht lange dauern.

Ansonsten bieten sich SRAM Chips mit serieller Schnittstelle an. Die 
halten theoretisch ewig. Du brauchst dann halt eventuell noch eine 
Batterie (oder supercap) zur Not-Stromversorgung.

Hi

Es gibt doch etwas passendes von ATMEL:

http://www.atmel.com/Images/doc2526.pdf
http://www.atmel.com/Images/AVR101.zip

MfG Spess