Hallo,
ich möchte bei einem neuen Projekt das interne EEPROM des ATtiny25
verwenden, um einen Zählerstand abzuspeichern.
Die Ersae/Write Zyklen sind ja auf 100.000 im Datenblatt spezifiziert.
Ist für eine Art Wear leveling folgendes möglich:
1. Byte x1....X100 im EEPROM löschen (0xff)
2. Die Bit Folge 11111110 schreiben ohne Löschvorgang
3. Die Bit Folge 11111100 schreiben ohne Löschvorgang
3. Die Bit Folge 11111000 schreiben ohne Löschvorgang
.
.
9. Die Bit Folge 00000000 schreiben ohne Löschvorgang
10. Byte X2 auf die gleiche Weise füllen.
Nach 100 benutzen Bytes werden alle 100 Bytes gelöscht und ein Zähler
an anderer Stelle hochgezählt.
Also eine Art Vorteiler (:800) für den Zählerstand.
Hinweis: Nach jedem Schreibvorgang erfolgt in der Regel eine
Abschaltung. (Also Power off)
Im Datenblatt steht:
"If the location to be written has not been erased before write, the
data that is stored must be considered as lost."
Gruß Dirk
Ja dann frag ich mal anders:
Wie würdet ihr an einer Maschine, die in ihrem Leben 10 Mio mal ein und
ausgeschaltet wird, die Anzahl der Schaltungen zählen ?
Dirk schrieb:> Wie würdet ihr an einer Maschine, die in ihrem Leben 10 Mio mal ein und> ausgeschaltet wird, die Anzahl der Schaltungen zählen ?
Mit seriellem FRAM.
Dirk schrieb:> Ja dann frag ich mal anders:> Wie würdet ihr an einer Maschine, die in ihrem Leben 10 Mio mal ein und> ausgeschaltet wird, die Anzahl der Schaltungen zählen ?
Ohne mehr über Deine Anwendung zu wissen:
Der ATtiny25 hat 128 Byte EEPROM...
> Wie würdet ihr ...
Ich würde dem ATtiny einen großen Kondensator parallel schalten, um z.B.
die eine Minute zu überbrücken. Denn 10000000 Minuten sind rund 19
Jahre, ob diese Maschine so lange hält?
Dirk schrieb:> Marcus H. schrieb:>> Der ATtiny25 hat 128 Byte EEPROM...>> Ja, wieso ?
Er meint, speicher einen Zeiger (Pointer) auf der Adresse 0 im EEprom
ab.
Über diese liest und schreibst Du deine Zählerstände.
Z.B. eine 3 Byte = 24 Bit-Zahl wird für deine Anwendung reichen.
(128-2) Byte / 3 = 42 Speicherbänke.
mit 100.000 Schreibzyklen erhältst Du für diese 42 Speicherbänke
100.000 * 42 = 4.200.000, reicht also nicht ganz.
Somit musst du dein Design abändern.
Dirk schrieb:> ich möchte bei einem neuen Projekt das interne EEPROM des ATtiny25> verwenden, um einen Zählerstand abzuspeichern.
Ich wuerde das einfach mit einer Adresse ausprobieren. Das hast du mit
100 x Schreiben/Sekunde schneller durch als hier zu posten. Ein ATtiny25
kostet nicht die Welt.
lep
Warum nicht den Zähler auf alle verfügbaren Bytes ausweiten? Bei 100
Einträge gibt es immer einen Versatz zu den maximal 128 Bytes.
Beispiel:
Im ersten Durchlauf werden die ersten hundert Bytes mit 0 bis 99
geschrieben. Byte 100 beginnt wieder bei 0, Byte 128 wäre dann 27. Im
nächsten Durchlauf beginnt Byte 0 mit 28, Byte 1 wird zu 29. Möchtest du
jetzt den nächsten Zählerstand wissen, so gehst du durch alle Bytes und
suchst eine Differenz von 28 (Wert ist also kleiner als der vorherige)
oder 100.
1. Durchlauf: 0 1 2 3 4 ... 100 0 1 2 ... 27
2. Durchlauf 28 29 30 ... 100 0 1 2 ... 55
Ich hoffe, ich habe keinen Denkfehler bei der Zahlenreihenfolge, aber
hoffe das Prinzip sollte klar sein.
ääääähhmmmm .... wie lautete doch das Thema des Threads?
"Wie trickse ich mit der Methode "von hinten durch die Brust
ins Auge" dass mein Tiny EEPROM doch noch ein bisschen länger
hält?"
oder
"ATtiny25 - EEPROM - Write ohne Verschleiß"
100.000 Mal möglich und 10 Mio. Gefordert: Faktor 100.
Also einfach 100 Bytes für das LSByte Opfern und je 100.000 Mal
beschreiben. Oder bis sie defekt sind.
Ein Byte Index, wo das LSByte steht, 4 Byte MSBytes, in Summe 105 Byte.
Viel schlimmer ist die Gefahr korrupter Daten bei Stromausfall während
des Schreibens.
A. S. schrieb:> Oder bis sie defekt sind.
Ich frage mich schon was ich davon habe ein EEPROM solange zu
beschreiben bis es defekt ist.
Wenn es dann defekt ist:
Wie möchte man denn dann die Information zurück gewinnen auf
die man so lange hinprogrammiert hat?
Oder ist die Zyklenzahl daraus zu gewinnen dass das EEPROM
ab Schreibzyklus 100.001 defekt ist?
Ich versteh's nicht. So genial die Ansätze sind, das letzte
Quentchen aus Hardware herauszuquetschen, sie sind nutzlos ....
Der einzige Sinn besteht für mich in der geistigen Ertüchtigung,
die aber leider nicht zur Lösung des Problems führt.
Beo Bachta schrieb:> ääääähhmmmm .... wie lautete doch das Thema des Threads?
...
Danke für Deinen wertvollen Hinweis.
> "ATtiny25 - EEPROM - Write ohne Verschleiß"
Wenn man sich ein wenig in das Thema EEPROM eingearbeitet hat, weiß man,
dass die Antwort auf die Frage nur mit: "geht net, gibt's net"
beantwortet werden kann.
Also kommen wir zum Punkt:
> "Wie trickse ich mit der Methode "von hinten durch die Brust> ins Auge" dass mein Tiny EEPROM doch noch ein bisschen länger> hält?"
Ganz grob zusammengefasst:
EEPROM und FLASH speichern Daten in Form von Ladungen in den isoloierten
Gatekondensatoren von Feldeffektransitoren. Die Änderung dieser Ladung
erfordert das Durchbrechen der Isolationschicht und hinterlässt
akkumulative Schäden.
Durch diese Schäden wird die Isolationsfähigkeit dieser Schicht
herabgesetzt, damit führt jeder Schreibvorgang zu einer Reduktion der
Speicherremanenz.
Diese Speicherzellen sterben also üblicherweise nicht sofort, sondern
zeichnen sich durch eine steigende Vergesslichkeit aus.
Der Hersteller gibt im Datenblatt für eine bestimmte Anzahl
Schreibzyklen und unter weiteren Randbedingungen eine zu erwartende
Datenhaltezeit an.
Beo Bachta schrieb:
...
>> Ich versteh's nicht. So genial die Ansätze sind, das letzte> Quentchen aus Hardware herauszuquetschen, sie sind nutzlos ....>> Der einzige Sinn besteht für mich in der geistigen Ertüchtigung,> die aber leider nicht zur Lösung des Problems führt.
Dieselben Probleme die wir hier besprechen gelten u.a. auch für SSDs.
Unter dem Begriff Wear-Leveling kämpft eine ganze Industrie darum die
limitierte Lebensdauer von FLASH-Zellen optimal auszunutzen.
Beo Bachta schrieb:> Marcus H. schrieb:>> Ganz grob zusammengefasst:>> Ach neee?>> Du meinst also du erzählst hier was Neues?
Für manche hier im Kreis wohl schon. Oben schrieb einer:
> Ich versteh's nicht. So genial die Ansätze sind, das letzte> Quentchen aus Hardware herauszuquetschen, sie sind nutzlos ....>> Der einzige Sinn besteht für mich in der geistigen Ertüchtigung,> die aber leider nicht zur Lösung des Problems führt.
Dirk schrieb:> Ja dann frag ich mal anders:> Wie würdet ihr an einer Maschine, die in ihrem Leben 10 Mio mal ein und> ausgeschaltet wird, die Anzahl der Schaltungen zählen ?
...ist mir gerade eingefallen: ein 16-Bit Zähler besteht aus low und
high byte. Was wäre damit nicht immer stupide den Wert reinschreiben,
sondern das High Byte nur dann beschreiben, wenn Low Byte einen Überlauf
hat? D.h. bei Zählerstand von 65536 wurde das High Byte nur 256 mal
beschrieben. Dann den Zählerspeicher so ändern, dass das high Byte low
Byte wird und den nächsten Speicherplatz als high Byte definieren, immer
nur eine Stelle weiter.
... ich spende euch labertypen, die sicher auch mit dem begriff
selbstwirksamkeit wohl eher nichts anfangen können, meine eeprom
endurance lib und hoffe damit (wohlweislich vergeblich) nicht weiteren
mist von euch lesen zu müssen!
mt
Apollo M. schrieb:> ... ich spende euch labertypen, die sicher auch mit dem begriff> selbstwirksamkeit wohl eher nichts anfangen können, meine eeprom> endurance lib und hoffe damit (wohlweislich vergeblich) nicht weiteren> mist von euch lesen zu müssen!>>> mt
Kann mir nicht vorstellen, dass sich jemand diese halbfertige
Hobby-"Software" auf den Chip holt.
Anmerkung: Schlechter als dein Englisch - ist nur noch dein Deutsch.
Kabb schrieb:> Anmerkung: Schlechter als dein Englisch - ist nur noch dein Deutsch.
Das verstehst du nicht .... das ist NeuEnglisch.
Edurance - das ist die (knall)harte Version von Education.
Kabb schrieb:> Schlechter als dein Englisch
echt?
egal, hat immerhin gereicht für zwei uni-abschlüsse in uk und zwei in
deutschland! davon seid ihr mittelmässigen wohl sicherlich lebenslang
befreit!
mt
O S S Hans schrieb:> In der Funktion eeReadData()
kann man besser machen ... aber dann wird die #if/elif kette komplexer
if(0)? wenn der eedata_byte type nicht benutzt wird muss trotzdem am
anfang ein if() für den compiler zu sehen sein.
werde das anpassen, weil das problem auch existiert, wenn eedata_word
nicht benutzt wird.
update folgt!
mt
Dirk schrieb:> Maschine, die in ihrem Leben 10 Mio mal ein und> ausgeschaltet wird
Soso, du hast also eine Maschine gebaut, die 10 Millionen Mal ein- und
ausgeschaltet wird. Und in welchen Zeitabständen soll das passieren?
Beo Bachta schrieb:> Dirk schrieb:>> Wie würdet ihr an einer Maschine, die in ihrem Leben 10 Mio mal ein und>> ausgeschaltet wird, die Anzahl der Schaltungen zählen ?>> Mit seriellem FRAM.
Oder einfach einen MSP430 nehmen, der hats bereits drin.
Dirk schrieb:> Wie würdet ihr an einer Maschine, die in ihrem Leben 10 Mio mal ein und> ausgeschaltet wird,
10m-counter passt für attiny25 mit 128bytes im eeprom gerade zum
abspeichern!
BUF_TYPE_DATA = DWORD_FLOAT_TYPE
BUF_SIZE_DATA = 20
BUF_TYPE_STATUS = BYTE_TYPE
BUF_SIZE_STATUS = 20
needed eeprom size for uint32_t counter: 4*20+1*20=100bytes
mt
Hi,
auf die Ursprungsfrage, "ATtiny25 - EEPROM - Write ohne Verschleiß", ist
soweit ich sehe noch niemand eingegangen -- also speziell das ohne
Verschleiss...:
Marcus H. schrieb:> Wenn man sich ein wenig in das Thema EEPROM eingearbeitet hat, weiß man,> dass die Antwort auf die Frage nur mit: "geht net, gibt's net"> beantwortet werden kann.>> Also kommen wir zum Punkt:>> "Wie trickse ich mit der Methode "von hinten durch die Brust>> ins Auge" dass mein Tiny EEPROM doch noch ein bisschen länger>> hält?">> Ganz grob zusammengefasst:> EEPROM und FLASH speichern Daten in Form von Ladungen in den isoloierten> Gatekondensatoren von Feldeffektransitoren. Die Änderung dieser Ladung> erfordert das Durchbrechen der Isolationschicht und hinterlässt> akkumulative Schäden.> Durch diese Schäden wird die Isolationsfähigkeit dieser Schicht> herabgesetzt, damit führt jeder Schreibvorgang zu einer Reduktion der> Speicherremanenz.
Das stimmt. Allerdings kann ein Schreibvorgang beim EEPROM einzelne Bits
meines Wissens nur löschen -- Setzen kann man sie nur byteweise
gemeinsam, durch Erase.
Die Frage wäre demnach: führt ein Schreibvorgang auch dann zu
Verschleiss, wenn der aktuelle Zustand der Zelle sich dabei nicht
ändert?
Meine Vermutung wäre nein, aber wissen tu ich's nicht...
> Diese Speicherzellen sterben also üblicherweise nicht sofort, sondern> zeichnen sich durch eine steigende Vergesslichkeit aus.>> Der Hersteller gibt im Datenblatt für eine bestimmte Anzahl> Schreibzyklen und unter weiteren Randbedingungen eine zu erwartende> Datenhaltezeit an.
Stimmt ebenfalls. Dadurch ist es nicht zuverlässig möglich, z.B. durch
Rücklesen unmittelbar nach dem Schreiben festzustellen ob eine Zelle
verschlissen ist. Es soll z.B. Effekte geben, wonach verschlissene
Zellen abhängig von der Betriebsspannung und/oder -temperatur hin- und
herkippen...
Dirk schrieb:> Im Datenblatt steht:> "If the location to be written has not been erased before write, the> data that is stored must be considered as lost."
Kann sein dass das nur vorsichtig formuliert ist, und man einfach nur
nicht garantieren will, dass bei mehreren aufeinanderfolgenden Writes
ohne Erase dazwischen, alle jeweils auf 0 zu setzenden Bits gelöscht
werden und alle anderen unverändert bleiben.
Hast Du es schon mal ausprobiert?
Allerdings ist es halt leider nicht garantiert...je nach dem wie sicher
Du es brauchst fällt es dadurch doch weg, selbst wenn es im Test
funktionieren sollte...allenfalls könnte dann vielleicht noch eine
Anfrage beim Hersteller weiterhelfen.
Apollo M. schrieb:> needed eeprom size for uint32_t counter: 4*20+1*20=100bytes
da für einen 10m-counter auch 3bytes reichen würden, werde ich im
nächsten update noch uint24_t unterstützen.
dann braucht dein counter "nur" noch 80bytes.
mt
Klingt komisch, aber: Indem Du Dir genau "überlegst" was Du machst.
1. Du speicherst den aktuellen Wert im RAM.
2. Verpasst dem Teil einen "großen" Stützkondensator.
3. Du überwachst die Versorgungsspannung.
zu 1. Der aktuelle Wert wird ständig (sooft wie er anfällt) im RAM
abgelegt.
zu 2. Du entkoppelst den µP von der Peripherie, so dass nur der µP
am Stützkondensator hängt. Notfalls mit getrennten Reglern oder
Dioden nachhelfen.
zu 3. Signalisiert die Spannungsüberwachung: "Keiner da", so wird der
aktuelle Wert in das EEPROM übernommen. Der µP wird so lange
von dem Stützkondensator versorgt.
Egal ob Du das Teil abschaltest oder der Strom ausfällt, der aktuelle
Wert wird dann gespeichert. Da das Abschalten oder ein Stromausfall
nicht 100000 Mal stattfindet, sollte das ausreichend sein.
Übrigens: Auch ein FRAM befreit Dich nicht von der Pflicht die
Versorgung zu überwachen, da ja VORHER gespeichert werden muss.
Andernfalls speicherst Du irgendeinen Wert, der stimmen kann, aber –
während des Stromausfalls - nicht muss.
Oliver S. schrieb:> Mathias A. schrieb:>> auf die Ursprungsfrage, "ATtiny25 - EEPROM - Write ohne Verschleiß", ist>> soweit ich sehe noch niemand eingegangen -- also speziell das ohne>> Verschleiss...:>> Das Thema ist nicht ganz neu,>> Beitrag "Atmega 328p Eeprom schreibzugriff auf einzelne Bits">> Oliver
OK, der Thread war an mir vorbeigegangen...aber wirklich neu ist das
Thema in der Tat nicht, deswegen hatte mich schon gewundert dass es noch
nicht angesprochen war hier im Thread :)
Hallo, erst mal Danke für die Rückmeldungen.
DEr Hinweis mit dem FRAM gefällt mir sehr gut.
Sebastian S. schrieb:> Da das Abschalten oder ein Stromausfall> nicht 100000 Mal stattfindet
Doch. 10 Mio mal.
Sebastian S. schrieb:> Auch ein FRAM befreit Dich nicht von der Pflicht die> Versorgung zu überwachen, da ja VORHER gespeichert werden muss.> Andernfalls speicherst Du irgendeinen Wert, der stimmen kann, aber –> während des Stromausfalls - nicht muss.
Ich könnte aber einfach den Zählwert an 3 verschiedenen Stellen
speichern und dann nach dem Einschalten prüfen, welche zwei Werte gleich
sind....
Thomas E. schrieb:> Soso, du hast also eine Maschine gebaut, die 10 Millionen Mal ein- und> ausgeschaltet wird. Und in welchen Zeitabständen soll das passieren?
Stell Dir einfach einen Elektromotor vor.
Es soll gezählt werden, wie of der ein und ausgeschaltet wird.
Im Motor, nicht woanders aus Gründen der Gewährleistung.
Thomas E. schrieb:> Soso, du hast also eine Maschine gebaut, die 10 Millionen Mal ein- und> ausgeschaltet wird. Und in welchen Zeitabständen soll das passieren?
Überschlage einfach mal:
Angenommen, das Gerät soll 20 Jahre betrieben werden, dann ist das im
Mittel rund ein Schaltzyklus (ein/aus) pro Minute. 20a ≈ 10.5*10^6
Minuten.
Das lässt sich jetzt leicht skalieren auf kürzere oder längere
Betriebsdauer ...
Aber wie so oft: darum ging es nicht.
Apollo M. schrieb:> werde ich im> nächsten update noch uint24_t unterstützen.
new version, tested with as7 simulator!
supports now five data types:
eedata_u8_t/eedata_u16_t/eedata_u24_t/eedata_u32_t/eedata_float_t
mt
S. Landolt schrieb:> Wenn das wieder ein Rohrkrempierer sein sollte, erfolgt die Degradierung> zum Sergeant.
passt, ich beobachte auch viel lieber das treiben der ferngesteuerten
:-)
duck und weg!
HildeK schrieb:> Angenommen, das Gerät soll 20 Jahre betrieben werden
Das hast du toll gerechnet. Das ist einmal pro Minute, 24/7, 365
Tage/Jahr. Dieses Jahr sogar 366 Tage. Da es dem TO aber angeblich um
Gewährleistung geht, geht es nicht um einen Zeitraum von 20 Jahren,
sondern von höchsten 3 Jahren. Und in dem Zeitraum soll das Ding 10 Mio.
Mal geschaltet werden. Alle 10s. So ungefähr. Das ist, wie so oft hier,
eine Anfrage auf dem Niveau von 24-Bit-Adc für die Messung von
Kühlschrank- oder Backofentemperaturen.
Thomas E. schrieb:> Das ist, wie so oft hier,> eine Anfrage auf dem Niveau von 24-Bit-Adc für die Messung von> Kühlschrank- oder Backofentemperaturen.
... und dann mit zweipunktregler oder fuzzy-logic, ach neh jetzt ja AI!
oder gewaltig adc over-sampling aber bitte mit nix-kosten uref.
Apollo M. schrieb:> minor update!> pre-compiler bugs fixed and related conditions simplified>>> mt
Warum muss da krampfhaft ein "else" hin? Macht den Code nur
unleserlicher....
Bernhard M. schrieb:> Warum muss da krampfhaft ein "else" hin? Macht den Code nur> unleserlicher....Apollo M. schrieb:> drei if() ohne pre-compiler bedingung ginge auch> anstatt if()/else if() aber dann je nach type weitere if-abfragen bzw.> minimal längere laufzeiten
unleserlich? neee!
weil, keine inhaltslosen comments, dafür aber sinnige bezeichner und
daraus folgt für mich erst lesbarkeit.
mt
Apollo M. schrieb:> Bernhard M. schrieb:>> Warum muss da krampfhaft ein "else" hin? Macht den Code nur>> unleserlicher....>> Apollo M. schrieb:>> drei if() ohne pre-compiler bedingung ginge auch>> anstatt if()/else if() aber dann je nach type weitere if-abfragen bzw.>> minimal längere laufzeiten>> unleserlich? nee!> weil, keine inhaltslosen comments, dafür aber sinnige bezeichner und> daraus folgt für mich erst lesbarkeit.>>> mt
Aber unnötige #ifs, die das lesen schwer machen....im obigen Beispiel
bringt das "else if" gar nichts, wie sollte es denn die Laufzeit erhöhen
können???
Bernhard M. schrieb:> #ifs, die das lesen schwer machen
ok, dann feel free und mach deine eigene version daraus!
> bringt das "else if" gar nichts, wie sollte es denn die Laufzeit erhöhen> können???
so, so ... die laufzeit verringern soll es! je nach data type, weil dann
weitere abfragen entfallen.
mt
Apollo M. schrieb:> Bernhard M. schrieb:>> #ifs, die das lesen schwer machen>> ok, dann feel free und mach deine eigene version daraus!>>>> bringt das "else if" gar nichts, wie sollte es denn die Laufzeit erhöhen>> können???>> so, so ... die laufzeit verringern soll es! je nach data type, weil dann> weitere abfragen entfallen.>>> mt
Ich mein ja nur...
ist das gleiche, denn wenn der erste "if" passt, wird mit return
beendet...
Das "else if" könnte nur dann die Laufzeit verringern, wenn er bei der
Ausführung da überhaupt hinkommen könnte...
Ich habe langsam den Eindruck, Du hast durch die vielen Präprozessor ifs
schon selbst den Überblick verloren....
Ich finds so übersichtlicher, und evtl. noch schneller, wenn viele /
alle Typen definiert sind...
Bernhard M. schrieb:> Ich habe langsam den Eindruck, Du hast durch die vielen Präprozessor ifs> schon selbst den Überblick verloren....
viel? träumst du, das ist hier alles simple and short, sprich mal eher
von deinen problem und nicht was andere nach deiner einsicht haben
sollen!
aber ein copy/past problem hatte ich hier wohl schon.
Bernhard M. schrieb:> Ich mein ja nur...
read() return... ja stimmt! ändere ich und rufe nach mehr schlaf.
Bernhard M. schrieb:> switch (p->type)
erzeugt in der regel relative mehr code mit gcc, daher bevorzuge ich
if().
btw. auch while() erzeugt regelmäßig mehr code als for()!
Bernhard M. schrieb:> und evtl. noch schneller, wenn viele /> alle Typen definiert sind...
kann man so pauschal nicht sagen, aber recht einfach im simulator
anschauen, sicher ist nur, das die zeitbedingung für alle typen mit
switch eher gleich aussieht.
die if()/else chain könnte auch nach den bevorzugten typen geordnet
werden!?
bezogen auf die grundfunktionalität ist das aber eher zweitrangig.
du kannst aber gerne richtig beitragen und z.b. ergänzen bzgl. @todo,
z.b. den support für struct block oder switch()/if() inst. cycl. im
simulator genauer untersuchen.
mt
Beim Tiny25 hast du 128 Byte EEPROM, die du 100.000 mal mit
ändern darfst, bis das MHD vielleicht zuschlägt.
Deine Änderungen von je 100 Byte führen im besten (!) Falle dazu,
dass du 128.000 mal 100 Bytes ändern darfst, wenn du das ganze
schön zyklisch, also gleichmäßig auf die vorhandenen Speicher-
stellen verteilst.
Das 100-Byte-Abakadabra ist aber wohl nur ein eher ungeeigneter
Ansatz, um den letztn Eintrag zu finden. - Also um Kontinuität
zu erreichen.
Stetiges +1 bei jedem neuen Eintrag ist einfacher (und nicht
fehlerträchtiger), als die 100-Byte-Variante, um den letzten
Eintrag zu erkennen.
Man kann über 1 Jahr:
24 Byte jede Minute ändern
Man kann über 12 Jahre:
2 Byte jede Minute ändern
Man kann über 48 Jahre:
30 Byte jede Stunde ändern
Welche Auflösung über welche Betriebszeit willst du denn nun
eigentlich haben?
Sag doch einfach, was du willst!
Schon kann dir geholfen werden. ;-)
Knorke schrieb:> Sag doch einfach, was du willst! Schon kann dir geholfen werden. ;-)
Das hat er doch schon geschrieben...siehe zweiten Beitrag im Thread:
Dirk schrieb:> Ja dann frag ich mal anders:> Wie würdet ihr an einer Maschine, die in ihrem Leben 10 Mio mal ein und> ausgeschaltet wird, die Anzahl der Schaltungen zählen ?
Ist bei den mittlerweile vielen Antworten aber in der Tat leicht zu
übersehen ;)
Aber meine eigentliche Frage wurde noch nicht beantwortet.
Beim ATtiny25 kann man beim Schreiben ins EEPROM 2 Arten wählen:
Byte löschen und schreiben in einer Schritt oder beide Sachen getrennt
ausführen.
Frage:
Hat eine dieser Sequenzen weniger Verschleiß
1. Byte x1 im EEPROM löschen (0xff)
2. Die Bit Folge 11111110 schreiben ohne Löschvorgang
3. Die Bit Folge 11111100 schreiben ohne Löschvorgang
4. Die Bit Folge 11111000 schreiben ohne Löschvorgang
5. Die Bit Folge 11110000 schreiben ohne Löschvorgang
6. Die Bit Folge 11100000 schreiben ohne Löschvorgang
7. Die Bit Folge 11000000 schreiben ohne Löschvorgang
8. Die Bit Folge 10000000 schreiben ohne Löschvorgang
9. Die Bit Folge 00000000 schreiben ohne Löschvorgang
als diese:
1. Byte x1 löschen und irgendeine Zahl reinschreiben
Falls wieder die Frage kommt was das für einen Sinn hat:
Nach jedem Schreibvorgang kommt Power off !!!
Ist das eigentlich ein echtes EEPROM oder ein HEF ?
Dirk schrieb:> Frage:> Hat eine dieser Sequenzen weniger Verschleiß
Aus der Diskussion im anderen Thread und anderswo lässt sich ableiten,
daß der (stärker?) schädigenden Vorgang das löschen ist (0->1). Das
mehrfache setzen (1->0) eines Bits in einem Byte sollte daher (kaum)
schaden.
Wie alles, was man ausserhalb der Spezifikation des Datenblatts
betreibt, liegt das Risiko aber bei dir. Ein "paar" Tests solltest du
daher schon durchführen.
Oliver
Oliver S. schrieb:> Dirk schrieb:>> Frage:>> Hat eine dieser Sequenzen weniger Verschleiß
...
> Aus der Diskussion im anderen Thread und anderswo lässt sich ableiten,> daß der (stärker?) schädigenden Vorgang das löschen ist (0->1). Das> mehrfache setzen (1->0) eines Bits in einem Byte sollte daher (kaum)> schaden.
Diese Vermutung liegt nahe, wenn man die zugrundeliegende Theorie kennt.
Jedoch schreibst Du hier so treffend:
> Wie alles, was man ausserhalb der Spezifikation des Datenblatts> betreibt, liegt das Risiko aber bei dir. Ein "paar" Tests solltest du> daher schon durchführen.
Der TO lässt anklingen, dass diese Anwendung für ein kommerzielles,
professionelles Umfeld gedacht ist. Daher hat er zwei Möglichkeiten:
- die vorhandenen Ressourcen innerhalb der Datenblattspezifikation zu
nutzen
- den Hersteller zu fragen, ob ein von ihm geplanter Spezialalgorithmus
für die vorliegende Anwendung akzeptabel ist
Alles andere ist Bastelei und Pfusch. Das Schlimme daran ist:
Bei den zu erwartenden häufigen Schreibzyklen würde die irgendwann
verbleibende Retentionszeit vielleicht sogar ausreichen um einen 24bit
Zähler in 8 Bytes unterzubringen. Daraus zu folgern, dass das eine
unproblematische Betriebsart für EEPROMs ist, ist aber weiterhin falsch.
Ein ähnliches Thema sind übrigens Löschzyklen für MCU-Programmspeicher.
Wenn per JTAG 10000 Mal in den Programmspeicher eines Eval-Boards
geschrieben wurde, wird das Ding trotzdem keine Probleme während der
Entwicklung machen. Nur die Retentionszeit wird sinken. Habe zufällig
ein STM32F051-Datenblatt offen:
Table 42. Flash memory endurance and data Retention
1 kcycle (2) at T A = 85 °C -> 30a
1 kcycle (2) at T A = 105 °C -> 10a
10 kcycle (2) at T A = 55 °C -> 20a
Endurance: T A = –40 to +105 °C 10kcycle
Dirk schrieb:> Frage:> Hat eine dieser Sequenzen weniger Verschleiß>> 1. Byte x1 im EEPROM löschen (0xff)> 2. Die Bit Folge 11111110 schreiben ohne Löschvorgang> 3. Die Bit Folge 11111100 schreiben ohne Löschvorgang> 4. Die Bit Folge 11111000 schreiben ohne Löschvorgang> 5. Die Bit Folge 11110000 schreiben ohne Löschvorgang> 6. Die Bit Folge 11100000 schreiben ohne Löschvorgang> 7. Die Bit Folge 11000000 schreiben ohne Löschvorgang> 8. Die Bit Folge 10000000 schreiben ohne Löschvorgang> 9. Die Bit Folge 00000000 schreiben ohne Löschvorgang
Verschleissmässig ist das vermutlich identisch zu:
1. Byte x1 im EEPROM löschen (0xff)
2. Die Bit Folge 11111110 schreiben
Byte x1 im EEPROM löschen (0xff)
3. Die Bit Folge 11111101 schreiben
Byte x1 im EEPROM löschen (0xff)
4. Die Bit Folge 11111011 schreiben
Byte x1 im EEPROM löschen (0xff)
5. Die Bit Folge 11110111 schreiben
Byte x1 im EEPROM löschen (0xff)
6. Die Bit Folge 11101111 schreiben
Byte x1 im EEPROM löschen (0xff)
7. Die Bit Folge 11011111 schreiben
Byte x1 im EEPROM löschen (0xff)
8. Die Bit Folge 10111111 schreiben
Byte x1 im EEPROM löschen (0xff)
9. Die Bit Folge 01111111 schreiben
genau weis ich es aber auch nicht.
viel Erfolg
hauspapa
Dirk schrieb:> Aber meine eigentliche Frage wurde noch nicht beantwortet.
Wer soll dir denn diese Frage hier im Forum definitiv beantworten
können, wenn nichts darüber im Datenblatt steht. Glaubst du der
Chipdesigner treibt sich in diesem Forum herum?
> Beim ATtiny25 kann man beim Schreiben ins EEPROM 2 Arten wählen:> Byte löschen und schreiben in einer Schritt oder beide Sachen getrennt> ausführen.>> Frage:> Hat eine dieser Sequenzen weniger Verschleiß>> 1. Byte x1 im EEPROM löschen (0xff)> 2. Die Bit Folge 11111110 schreiben ohne Löschvorgang> 3. Die Bit Folge 11111100 schreiben ohne Löschvorgang> 4. Die Bit Folge 11111000 schreiben ohne Löschvorgang> 5. Die Bit Folge 11110000 schreiben ohne Löschvorgang> 6. Die Bit Folge 11100000 schreiben ohne Löschvorgang> 7. Die Bit Folge 11000000 schreiben ohne Löschvorgang> 8. Die Bit Folge 10000000 schreiben ohne Löschvorgang> 9. Die Bit Folge 00000000 schreiben ohne Löschvorgang>> als diese:> 1. Byte x1 löschen und irgendeine Zahl reinschreiben
Im Datenblatt steht "The EEPROM has an endurance of at least 100,000
write/erase cycles". Diese Zahl wird durch Statistik und nicht durch
Tests garantiert, d.h. du kannst sicherlich auch auf Chips treffen, die
darunter liegen, und andere, die deutlich darüber liegen.
Das Problem bei deinem Vorhaben ist, du hast keine Redundanz, kannst
also nicht erkennen wenn etwas schiefgelaufen ist. Du musst ja vor jedem
Schreiben ermitteln, an welche Stelle das nächste Bit geschrieben werden
soll, indem du die Bytes des EEPROM durchsuchst. Wenn nun der letzte
Schreibvorgang nicht geklappt hat, versuchst du vermutlich wieder das
gleiche (gekippte) Bit zu schreiben, und bleibst für immer hängen. Eine
Verifikation direkt nach dem Schreiben kann nicht schaden, wird dir aber
bei Zellen am Ende ihrer Lebensdauer nichts helfen, da diese direkt nach
dem Schreiben vermutlich noch den korrekten Inhalt haben, aber eventuell
kurze Zeit später kippen.
> Falls wieder die Frage kommt was das für einen Sinn hat:> Nach jedem Schreibvorgang kommt Power off !!!
Das halte ich für Unsinn. Direkt vor Power Off auf das EEPROM zu
schreiben ist sehr kritisch und kann das EEPROM leicht korrumpieren wenn
die Spannung zu früh weggeht. Da du bei deinem geplanten Zähler ja keine
zeitliche Zuordnung mehr hast, kannst du genausogut (besser) den Zähler
nach jedem Power On erhöhen, und hast damit die gleiche Information.
Allerdings auch hier die zeitlichen Randbedingungen (stabile Spannung)
beachten.
Manne schrieb:>> Falls wieder die Frage kommt was das für einen Sinn hat:>> Nach jedem Schreibvorgang kommt Power off !!!>> Das halte ich für Unsinn.
Ob du das für Unsinn hälst oder nicht, wenn die Applikation
Ausschaltvorgänge zählen will, dann kommt definitiv nach jedem
Schreibvorgang ein power off.
Der wesentliche Hinweis darin ist der, daß sich die maximale Zahl der im
Datenblatt agegeben Schreibvorgänge (vermutlich) auf diese Betriebsart
bezieht. Irgendwo in den Tiefen des Forums finden sich Beiträge von
Leuten, die das (an anderen EEPROMS) schon nachvollzogen haben. Ohne den
Power off/on-Cycle vertragen EEPROMS sehr viel mehr Zyklen, als im
Datenblatt steht.
Was genau davon jetzt auf das im ausgewählten AVR verbauten EPROM
zutrifft, ist unbekannt.
Oliver
Bis jetzt hat wohl keiner der Algorithmus-Spezialisten die
Frage beantwortet wie man denn eine Zyklen-Inforation gewinnt
wenn das EEPROM schliesslich ausgeleiert ist.
Beo Bachta schrieb:> Wenn es dann defekt ist:> Wie möchte man denn dann die Information zurück gewinnen auf> die man so lange hinprogrammiert hat?
Was hilft's wenn am Ende doch alles für die Katz ist?
Oliver S. schrieb:> Manne schrieb:>>> Falls wieder die Frage kommt was das für einen Sinn hat:>>> Nach jedem Schreibvorgang kommt Power off !!!>>>> Das halte ich für Unsinn.>> Ob du das für Unsinn hälst oder nicht, wenn die Applikation> Ausschaltvorgänge zählen will, dann kommt definitiv nach jedem> Schreibvorgang ein power off.
Und du meinst also es gibt mehr Ausschaltvorgänge als Einschaltvorgänge?
Wenn die Applikation Ausschaltvorgänge zählen will, kann sie genausogut
die Einschaltvorgänge zählen!
... echt ein esoteriker stammtisch wird das jetzt hier!
kleine zusammenfassung, es gibt:
- keine herstellerweite definition für eeprom endurance
- kein eeprom endurance model herstellerweit
- kein etabliertes endurance testverfahren
- eeprom endurance ist abhängig von:
- der verwendeten technology
- temperatur
- betriebsspannung, der spannung der ladungspumpe
- anzahl der löschvorgänge
- ...
- die 100k writes sind definiert über den gesamten vcc und tp bereichen
- bei vcc_min und tp@25°C folglich wesentlich gößer als 100k
- um unter beachtung der vielen parameter/+streuung die 100k zu
garantieren, ist der wert sicher sehr konservative gesetzt worden.
ich denke, kein hersteller wird weitere frage hierzu beantworten, ausser
das was er untersucht und bereit war zu garantieren.
also, was wollt ihr spinner jetzt noch weiter diskutieren?
ausser praktische konzequenzen für eine reale anwendung?!
z.b.
- das teil bekommt einen kühlen schattenplatz
- wird mit nur vcc 1.8V betrieben
- verteilung der write cycles über mehrere addressen
- andere technology
- anderes konzept
- ...
engineering ist für mich zuerst praktisch ...!
mt
Frank M. schrieb:> Wo steht im Datenblatt, dass dieser Wert pro Zelle gilt?
Das steht nicht explizit drin, es steht aber auch nicht drin, daß das
nicht so ist.
Oliver
Frank M. schrieb:> Dirk schrieb:>> Die Ersae/Write Zyklen sind ja auf 100.000 im Datenblatt spezifiziert.>> Wo steht im Datenblatt, dass dieser Wert pro Zelle gilt?
Der Wert ist pro Zelle. Da ein Chip nicht teuer ist kannst du es leicht
ausprobieren. Pro Byte: 100.000 x ca. 5 ms = 500 s.
Malefiz schrieb:> Frank M. schrieb:>> Dirk schrieb:>>> Die Ersae/Write Zyklen sind ja auf 100.000 im Datenblatt spezifiziert.>>>> Wo steht im Datenblatt, dass dieser Wert pro Zelle gilt?>> Der Wert ist pro Zelle. Da ein Chip nicht teuer ist kannst du es leicht> ausprobieren. Pro Byte: 100.000 x ca. 5 ms = 500 s.
Nein, so leicht ist es nicht. Wurde schon mehrfach geschrieben im
Thread.
Moin! Ich habe ja keine Ahnung ob ich das verstanden habe was der Autor
da versucht, aber den Ansatz finde ich interessant.
10 Millionen passen in 3 Bytes.
Du darfst aber nur 100000 mal löschen. Irgendwie muss da also der Faktor
100 her. Und da ist die Idee, wenn ich sie richtig verstanden habe, die
LSBs wie mit einer Strichliste zu zählen.
Für eine Strichliste mit 100 Strichen benötigst du 13 Bytes. Zusammen
mit der ganzen Zahl dann also 13+3 Bytes.
Das stelle ich mir so vor:
Die 3 Bytes der Zahl sind 0
Die 13 Bytes der Strichliste sind
11111111 ... 11111111
Jetzt wird hochgezählt, also Bits werden von 1 auf 0 gekippt. Das könnte
man eigentlich beliebig machen, aber praktischer ist es wohl an einer
Seite anzufangen, also
11111111 ... 11111110
11111111 ... 11111100
11111111 ... 11111000
...
11000000 ... 00000000
10000000 ... 00000000
00000000 ... 00000000
Und genau dann wenn alle Bits 0 sind, dann wird die Zahl, also die 3
Bytes, um die Länge der Strichliste erhöht. Bei einer Strichlistenlänge
von 13 Bytes sind das also 13*8=104
Und dann werden die 13 Bytes der Strichliste wieder auf 1111111 gesetzt.
Damit musst du die Bytes der Strichliste nur dann löschen wenn die
Strichliste voll ist und die Zahl ebenfalls mur dann neu abspeichern.
Wenn du jetzt irgendwann die genaue Zahl der Einschaltungen wissen
willst, dann musst du die Zahl in den 3 Bytes nehmen und die Anzahl der
Nullen in der Strichliste dazuaddieren.
Macht das Sinn oder war das etwas zu wirr?
Gustl B. schrieb:> Macht das Sinn oder
... die 100-vorteiler variante - jein!
weil, du kannst zwar so bis 10m zählen, aber dann wäre theoretisch
schluss, da die 100k verschossen sind.
und du kannst auch nur einen linearen increment zähler realisieren.
im sinne des to-target/constrains - ja,
wenn beliebige daten kodierung/struktur eher nein
mt
Na ich kann damit auch deutlich weiter wie 10 M zählen. Dann verwende
ich eben statt 13 Byte Vorteiler 125 Byte. Dann müssen die Bytes nur
alle 1000 Einschaltungen gelöscht werden.
Aber ja, eine Milliarde wird schwer, stimmt. Hier für dieses Problem ist
das mit der Strichliste aber extrem leicht machbar.
Gustl B. schrieb:> Aber ja, eine Milliarde wird schwer, stimmt.
warum?
Gustl B. schrieb:> Hier für dieses Problem ist> das mit der Strichliste aber extrem leicht machbar.
ich finde, es ist eine interessante variante, wenn ich "nur" einen
zähler brauche und wenig platz dafür im eeprom habe.
die variante taugt auch gut für eeprom's mit page-write e.g. bei pic's
mit HEF.
mt
Apollo M. schrieb:> warum?
Nun, dann rechnen wir uns mal aus wie viele Bytes Strickliste du
bräuchtest wenn jedes Byte nur 100k mal geschrieben/gelöscht werden
darf.
1 Milliarde / 100k = 10000 und dafür braucht man dann 1250 Bytes + 4
Bytes für die ganze Zahl.
(Ja, du kannst grob 1 Byte sparen wenn du nicht die ganze Zahl des
Zählers abspeicherst, sondern nur die Anzahl der Strichlistenüberläufe,
aber 1 Byte ist bei über 1 kByte recht egal.)
Jedenfalls, das passt nicht in die hier genannten 128 Byte EEPROM des
uCs.
Gustl B. schrieb:> 1 Milliarde / 100k = 10000 und dafür braucht man dann 1250 Bytes + 4> Bytes für die ganze Zahl.
sehe ich nicht ein, weil
1mia = 100x100x100k und dann mit zwei "separaten" 100-vorteiler
realisiert sind 2x13+5/6bytes.
also warum soll das nicht bei passen?
mt
Apollo M. schrieb:> also warum soll das nicht bei passen?
Weil der erste Vorteiler dann 100 mal öfter beschrieben wird als der
zweite Vorteiler. Also mehr als 100K.
Apollo M. schrieb:> dann mit zwei "separaten" 100-vorteiler
Sehr witzig. Und wie oft wird ein 100 Bits langer Vorteiler bei einer
Milliarde zurückgesetzt/gelöscht? Ist das mehr als die maximal möglichen
100000? Rechne das doch mal.
Vermutlich hast du nicht verstanden wie eine Strichliste funktioniert.
Der für eine Milliarde nötige Vorteiler ist 10000. So lang muss also die
Strichliste sein. 10000 ist zwar 100*100, aber trotzdem kannst du eine
Strichliste die 10000 Striche fassen soll nicht durch nur zwei
Strichlisten ersetzen die 100 Striche fassen.
Du könntest sie ersetzen durch 100 Strichlisten die jeweils 100
Striche fassen. Aber dann hast du genau Null Bits gespart.
Oder noch mal anders:
Um die Bits möglichst selten löschen zu müssen sollte man gerade kein
Stellenwertsystem verwenden. Oder wenn, dann eines mit einer möglichst
großen Basis. So wird das glaube in dem Klassiker Математика и
правдоподоБные рассуждения erklärt/begründet.
Bei einer einzelnen Strichliste mit 10000 Bits hast du eben eine Basis
von 10000. Was du vorgeschlagen hattest waren zwei Strichlisten mit
jeweils 100 Strichen. Die 2. Strichliste zählt also wie oft die erste
zurückgesetzt werden muss. Damit hast du ein Stellenwertsystem zur Basis
100 gebaut. Und musst eben die niederwertigste Stelle 100 mal öfter
zurücksetzen/löschen.
Karl M. schrieb:> Er meint, speicher einen Zeiger (Pointer) auf der Adresse 0 im EEprom> ab.> Über diese liest und schreibst Du deine Zählerstände.> Z.B. eine 3 Byte = 24 Bit-Zahl wird für deine Anwendung reichen.>> (128-2) Byte / 3 = 42 Speicherbänke.>> mit 100.000 Schreibzyklen erhältst Du für diese 42 Speicherbänke>> 100.000 * 42 = 4.200.000, reicht also nicht ganz.>> Somit musst du dein Design abändern.
der Ansatz klingt mir doch super schonmal
AAaber man braucht doch garnicht alle bytes zu ändern
immer nur das lowbyte und dann den überlauf..
höchstes byte wird nur 152 mal beschrieben zB
Mittleres byte hat damit 38.760 Schreibzyklen (oder verrechnete ich
mich?)
damit blieben 126 byte für das Low byte
126* 100.000 = 12,6 mio
reicht also locker meiner Meinung nach.
festgelegte Adresse 0 für höchstes byte, und 1 für's mittlere,
dann kann man sich die Speicherposition des niedrigsten bytes errechnen
und
da man in multiplen von 100000 rechnet hat man alle Informationen die
man braucht um ggf zur nächsten lowbyte adresse zu hüpfen
'sid
Kann man machen, ist aber eben irre verschwenderisch wenn es auch mit 16
Bytes gehen würde (es geht sogar mit nur 15 Bytes, aber leicht
unbequem).
Ist aber wohl derzeit der Trend verschwenderisch mit dem umzugehen was
man hat. Folge sind dicke Handyapps die fast nix machen und Webseiten
mit mehrenen 10 MBytes. Komplexität ist der Feind!
sid schrieb:> Mittleres byte hat damit 38.760 Schreibzyklen (oder verrechnete ich> mich?)
japp verrechnet ... 39215 schreibzyklen.. immernoch weit weniger als
100000 zum Glück.
man braucht also in der tat nur 102 byte Platz im eeprom um die 10 mio
schaltungen zu speichern.
man könnte also spielend einen byte opfern um die Speicheradresse des
low bytes zu hinterlegen (wird ja nur 100 mal beschrieben ;))
'sid
Gustl B. schrieb:> Kann man machen, ist aber eben irre verschwenderisch wenn es auch mit 16> Bytes gehen würde (es geht sogar mit nur 15 Bytes, aber leicht> unbequem).>> Ist aber wohl derzeit der Trend verschwenderisch mit dem umzugehen was> man hat. Folge sind dicke Handyapps die fast nix machen und Webseiten> mit mehrenen 10 MBytes. Komplexität ist der Feind!
irre verschwenderisch weiss ich nicht, aber viellicht kann ich auch nur
dem StrichlistenDing nicht folgen..
wenn ich nen bit setze/lösche ist das doch ein schreibzyklus..
und wenn ich das achtmal pro byte mache sind das eben Acht, nicht
einer..
da die Strichliste aber 100000 mal gelöscht wird,
und jedes der dreizehn bytes darin achtmal pro Löschen neu gesetzt
wird..
macht das bei mir 800.000 schreibzyklen, oder nicht?
'sid
sid schrieb:> wenn ich nen bit setze/lösche ist das doch ein schreibzyklus..
Nein.
Als Schreibzyklus zählt nur wenn die Bits von 0 auf 1 gesetzt werden.
Wenn sie von 1 auf 0 gesetzt werden zählt das nicht.
Du kannst also in einer Strichliste aus 8 Bits einmal dieses Byte auf FF
setzen und dann zählen von
11111110
11111100
bis
00000000.
Das kostet keine der 100000 möglichen Löschzyklen. Erst wenn du das Byte
wieder auf FF zurücksetzt kostet das wieder einen Löschzyklus.
Wenn du jetzt eine Strichliste auf 13 Bytes hast, dann setzt du die
einmal alle 13 Bytes auf FF. Das kostet also für jedes Byte einen der
100000 erlaubten Löschzyklen. Und dann kannst du aber 13*8=104 mal
hochzählen ohne dass es was kostet.
Das ist eben eine quasi invertiere Strichliste. Statt für 1er
hinzschreiben wo vorher 0er standen schreibt man 0er wo 1er standen. Ist
aber eben egal. Am Ende muss man bei einer 13 Byte langen Strichliste
nur alle 104 Zählvorgänge einen Löschzyklus für alle 13 Byte machen.
Weil die 13 Bytes leider keine 10 Millionen fassen, braucht man noch
zusätzliche 3 Bytes für den tatsächlichen Wert des Zählers. In den
zusätzlichen 3 Bytes speichert man also eine ganze Zahl und zwar nicht
als Strichliste sondern im Binärsystem. Und diese Zahl erhöht man immer
dann wenn die Strichliste aus den 13 Bytes voll ist um die Anzahl der
Striche in der Strichliste. Hier also um 13*8=104.
Bonus:
Ja nach länge der Srichliste kann man noch weitere Bytes einsparen wenn
man statt einer ganzen Zahl in n zusätzlichen Bytes nurnoch abspeichert
wie oft die Strichliste voll war.
Beispiel:
Wenn du eine Strichliste als 256 Bits (32 Bytes) anlegst, und nornoch
speicherst wie oft sie voll war, dann sparst du ein ganzes Byte im
Vergleich dazu wenn du den kompletten Zählerstand binär ablegen würdest.
Gustl B. schrieb:> Nein.>> Als Schreibzyklus zählt nur wenn die Bits von 0 auf 1 gesetzt werden.> Wenn sie von 1 auf 0 gesetzt werden zählt das nicht.
Ahaaa.. das hatte ich nicht auf'm Schirm
ehrlich gesagt hat ich noch nie irgendwas auch nur in der Nähe von 100k
schreibzyklen gebraucht.. eher mal so hundert, höchstens 200...
dachte wenn ich einen byte von FF auf FE setze werden alle Acht bit neu
beschickt (egal ob geändert oder nicht).
der Rest war schon zuvor ausreichend erklärt mMn..
Dann in der tat geb ich Dir recht, ist eine 'Strichliste' in der Tat die
EEprom schonendere Alternative für die "kleinstelligen" Werte.
'sid
Gustl B. schrieb:> Als Schreibzyklus zählt nur wenn die Bits von 0 auf 1 gesetzt werden.> Wenn sie von 1 auf 0 gesetzt werden zählt das nicht.
Könntest du diese Vermutung bitte mit einer Aussage des Herstellers
untermauern (Datenblatt, Application Note, ...) oder mit einer
aussagekräftigen Testreihe?
/edit:
Von Mikrochip gibt es tatsächlich die AN537 aus welcher man das
rausinterpretieren kann:
http://ww1.microchip.com/downloads/en/appnotes/00537.pdf
"Worst casetesting would be to erase and write each bit, which is what a
write all “0”s pattern with an auto-erase of “1”routine will perform.
Indeed, this write all “0”s testpattern will produce very different
results than a check-erboard test pattern of alternating “1”s and “0”s
within abyte, since cells are changed more often writing all “0”sthan in
an alternating “1” and “0” write pattern."
Michael
Apollo M. schrieb:> ... ich spende euch labertypen, die sicher auch mit dem begriff> selbstwirksamkeit wohl eher nichts anfangen können, meine eeprom> endurance lib und hoffe damit (wohlweislich vergeblich) nicht weiteren> mist von euch lesen zu müssen!Apollo M. schrieb:> davon seid ihr mittelmässigen wohl sicherlich lebenslang> befreit!
Uwe, ist dir das gar nicht peinlich solche überheblichen Entgleisungen
unter deinem Realnamen zu posten?
sid schrieb:> dachte wenn ich einen byte von FF auf FE setze werden alle Acht bit neu> beschickt (egal ob geändert oder nicht).
Bei
EECR = (1<<EEPM1)|(0<<EEPM0);
wird nur geschrieben. Also nur Änderung von 1 auf 0 möglich
Und bei
EECR = (0<<EEPM1)|(0<<EEPM0);
wird erst gelöscht (alles auf 0xff setzen) dann geschrieben
Bitweises Ändern von 1->0 ohne vorheriges löschen kann in die Hose
gehen. Wir haben einen ähnlichen Ansatz mit einem externen SPI Flash
verfolgt und haben dabei unerwartet Bitkipper in vollkommen anderen
Sektoren beobachtet.
Während der Entwicklung waren diese Fehler nicht aufgetreten. Der
Hersteller hat nichts spezielles zu dem Thema bitweises Schreiben in dem
DB geschrieben. Es hat sich dann herausgestellt, das die Bitkipper erst
mit einer neuen Generation des (selben!) Flash-Chips aufgetreten sind,
vermutlich eine andere Strukturgröße. Das Problem bei Flash Chips ist,
dass das Schreiben einer Flash-Zelle Auswirkungen auf benachbarte Flash
Zellen haben kann, wenn nicht der ganze Sektor vorher gelöscht wird.
(Irgendwelche Feldeffekte)
Jetzt steht es auch in dem betreffenden Datenblatt, dass es nicht geht.
:-)
Andreas M. schrieb:> Jetzt steht es auch in dem betreffenden Datenblatt, dass es nicht geht.
Ja, aber beim Tiny25 stehen im Datenblatt explizit drei Modi:
- Erase and Write in one operation
- Erase only
- Write only
Die angedachten Methoden dürften daher keine Probleme machen.
Was nicht drin steht: ist 'Erase and Write' ein Vorgang, der von den
100000 Zyklen einen oder möglicherweise zwei wegnimmt?
Ich habe zumindest beim kurzen Durchschauen keine Aussage dazu gefunden.
Michael D. schrieb:> Könntest du diese Vermutung bitte mit einer Aussage des Herstellers> untermauern (Datenblatt, Application Note, ...) oder mit einer> aussagekräftigen Testreihe?
Wie das bei einem EEPROM ist weiß ich nicht. Aber bei NAND Flash müsste
es bedingt durch den Aufbau genau so sein.
Wie ihr das auf Hardware umsetzt ist mir aber auch echt egal, ich habe
mit uCs nichts am Hut und verwende FRAM am FPGA.
Hier hatte ich nur beschrieben was eine Strichliste ist und wie man
diese als Vorteiler verwenden kann.
HildeK schrieb:> Was nicht drin steht: ist 'Erase and Write' ein Vorgang, der von den> 100000 Zyklen einen oder möglicherweise zwei wegnimmt?> Ich habe zumindest beim kurzen Durchschauen keine Aussage dazu gefunden.
Bei EEPROM und FlashROM-Technologie zählt die Anzahl der Löschzyklen,
also wo man den Initialzustand wieder herstellt. Also zählen Erase sowie
Erase+Write einfach, Write jedoch nicht.
Ja genau, danke. Das weiß ich auch, aber ich habe keine Quelle. Zum NAND
finde ich was aber zu EEPROM nicht.
Vor allem wäre interessant ob vor jedem Schreibvorgang ein Löschvorgang
erfolgen muss, oder ob das auch ohne Löschvorgang ein valider
Schreibvorgang ist.
Ich meine ob es erlaubt ist ein bestimmtes Byte/Adresse von initial nach
einem Löschvorgang
11111111
ohne zwischen drinnen erneut zu löschen mehrmals nacheinander mit
11111110
11111100
11111000
...
bis
00000000
zu beschreiben ohne dass dabei Fehler passieren. Ich sehe keinen Grund
wieso das nicht funktionieren sollte, kann aber auch gut sein, dass es
nur meistens funktioniert und schlicht ein Schreibvorgang ohne löschen
vorher/oder auf ein Bytes mit einem anderen Inhalt als 11111111 nicht
garantiert wird.
Gustl B. schrieb:> Vor allem wäre interessant ob vor jedem Schreibvorgang ein Löschvorgang> erfolgen muss, oder ob das auch ohne Löschvorgang ein valider> Schreibvorgang ist.
Im Falle des AVR-EEproms, bei dem es einzelne Befehle zum Schreiben und
Löschen gibt, gehe ich davon aus, daß das Datenblatt explizit darauf
hinweisen müsste, wenn Schreiben ohne vorheriges Löschen nicht zulässig
wäre. Davon steht da aber nichts drin.
Oliver
HildeK schrieb:> Andreas M. schrieb:>> Jetzt steht es auch in dem betreffenden Datenblatt, dass es nicht geht.>> Ja, aber beim Tiny25 stehen im Datenblatt explizit drei Modi:> - Erase and Write in one operation> - Erase only> - Write only> Die angedachten Methoden dürften daher keine Probleme machen.
Richtig -- bis auf das was im Ursprungsposting noch zititert ist:
Dirk schrieb:> Im Datenblatt steht:> "If the location to be written has not been erased before write, the> data that is stored must be considered as lost."
Location bezieht sich hier sicherlich auf ein Byte, da das die kleinste
Einheit ist die hier beim EEPROM gelöscht werden kann.
Wobei mir gerade auffällt beim erneuten lesen: es steht da ja garnicht
explizit, dass zwischen zweimal Write einmal gelöscht werden
muss...bisher hatte ich es dagegen so verstanden, und vermute auch dass
es so gemeint ist ;-)
@Dirk: hast Du mal probiert ob man bei dem Chip die Bits durch
mehrfaches Write ohne Erase einzeln auf 0 setzen kann?
Vermutlich ist das obige Datenblatt-Zitat so zu verstehen dass es nur
nicht garantiert wird, und nicht dass die Daten auf jeden Fall defekt
sind wenn zwischendurch kein Erase stattfindet.
Wenn ja, würde ich es denke ich ebenfalls mit der Strichliste lösen --
und wenn im EEPROM Platz ist, das ganze am besten mehrfach darin
ablegen, um Redundanz zu haben falls doch einmal einzelne Bits kippen...
Sehr interessantes Problem, dafür gibt es bestimmt eine Standardlösung,
weil das Problem jeder hat der dauerhaft was im EEPROM speichern will.
Die Standardlösung hab ich aber nicht gegoogelt.
Meine drei Cent dazu:
Erster Cent: Nur das Setzen eines Bit innerhalb eines Byte auf '1'
kostet Schreibcyclen, nicht das Setzen auf '0'. Oder umgekeht, das hängt
vom EEPROM Typ ab.
Zweiter Cent: Unter obiger Voraussetzung scheint mir die Strategie des
TO optimal zu sein: Ein Byte kann 9 Zustände haben,
'11111111','11111110','11111100' usw bis '00000000'. Wir rechnen also im
9-er System. Um im 9-er System bis 1E7 zu zählen benötige ich 8 Stellen,
dazu nehme ich 8 Byte. Die unteren drei Stellen des Zählers wrappen mehr
als 100000 Mal um. Wenn eine Stelle 100000 Schreibzyklen 'durch' hat
nehme ich für die ein neues, 'unverbrauchtes' Byte. Die unterste Stelle
muss ich 100mal erneuern, die nächstuntere 11 Mal, die darüber 1 oder 2
Mal, insgesamt passt das also knirsch in die 128 Byte rein. Paßt und
verletzt keine Spec.
Dritter Cent: Zähler wie oben mit 8 Stellen im 9-er System, davon aber
drei Stück. Wenn einer der Zähler kaputt ist nehme ich für den ein neues
Byte an der Stelle an der er kaputt gegangen ist. Da vertraue ich drauf,
dass man mehr als 100000 mal schreiben kann und dass nicht zwei Bytes
gleichzeitig kaputtgehen, was aber m.E. kein Risko ist.
So macht man das, glaube ich.
math rulez!
Cheers
Detlef
Arduino Fanboy D. schrieb:> Das wurde doch hier gerade noch erklärt, dass das geht:> Beitrag "Re: ATtiny25 - EEPROM - Write ohne Verschleiß">> Überlesen?> Vielleicht hilft es ja, selber die Stelle im Datenblatt zu suchen, und> 100 mal laut vorzulesen.
Da steht doch nur, dass man einzeln ein Erase und einzeln ein Write
auslösen kann -- aber im Datenblatt steht auch, dass man vor einem Write
ein Erase aufrufen muss, siehe Ursprungsposting.
Mathias A. schrieb:> aber im Datenblatt steht auch, dass man vor einem Write> ein Erase aufrufen muss, siehe Ursprungsposting.
Das Atmel English ist manchmal ein wenig speziell.
Hier dürfte gemeint sein, dass ohne vorherigem löschen (alles auf 1
setzen) beim schreiben nicht das Byte in der Zelle landetet, wie man das
evtl beabsichtigt hat. Denn die vorherigen 0en bleiben erhalten.
Im naiven Normalfall (will Byte schreiben) ist das ein Fehlverhalten,
denn dann steht Müll in der Zelle.
Aber der TE beabsichtigt genau diesen Effekt zu nutzen.
Arduino Fanboy D. schrieb:> Das Atmel English ist manchmal ein wenig speziell.
Im Falle des Tiny25 nicht.
1
In order to take advantage
2
of this method, it is required that the locations to be written have been erased before the write operation.
"it is required" ist schon ziemlich eindeutig.
Im Datenblatt vom ATmega2561 und anderen, die die getrennten Operationen
auch haben, steht dieser Abschnitt allerdings nicht.
Oliver
Hi,
Arduino Fanboy D. schrieb:> Denn die vorherigen 0en bleiben erhalten.
wie gesagt, ich vermute das ja auch, weil es üblicherweise bei EEPROMs
eben so ist -- aber der Satz im DB würde mich zumindest veranlassen, das
einmal auszuprobieren (wobei selbst das natürlich keine Garantie gibt
dass es dann immer funktioniert). Es könnte ja sein dass bei diesem Chip
da tatsächlich irgendein Effekt dafür sorgt dass dann die Daten in der
beschriebenen Location nicht mehr definiert sind.
Daher meine Frage an Dirk...
Funktionieren tut es, siehe Beispiel in der Artikelsammlung. Ob
dauerhaft, und ob man das in einem komerziellen Produkt verwenden
sollte, ist offen.
Oliver
Meiner Meinung nach wird es höchstwahrscheinlich nach dem Vorhaben vom
TO funktionieren (Striche zählen). Als professionelle Lösung würde ich
es aber nicht verwenden, siehe das Zitat unten:
Andreas M. schrieb:> ...das die Bitkipper erst> mit einer neuen Generation des (selben!) Flash-Chips aufgetreten sind,> vermutlich eine andere Strukturgröße. Das Problem bei Flash Chips ist,> dass das Schreiben einer Flash-Zelle Auswirkungen auf benachbarte Flash> Zellen haben kann, wenn nicht der ganze Sektor vorher gelöscht wird.
Irgendwas änderst sich mit der Zeit vorauf man keinen Einfluss hat, und
dann funktioniert nicht mehr so wie ursprünglich vorgestellt.
10.000.000 Zyklen kann man mit 128 Bytes trotzdem erreichen ohne die
Spezifikationen zu verletzen mit 126 x low Byte + 1 x high Byte + 1 x
Bit 17 (65536-100000) + pointer auf low bytes.
Detlef _. schrieb:> jeder hat der dauerhaft was im EEPROM speichern will.
Nee, nur jeder der was Millionenmal im Eeprom speichern will. Normale
Entwickler benutzen Eeprom einfach innerhalb der Herstellerspecs und
müssen sich nicht solchen Unsinn ausdenken.
Hint: Goldcap-gepufferte RTC mit paar Bytes Ram kann den Zähler ganz
ohne Kopfschmerzen halten.
Karl K. schrieb:> Detlef _. schrieb:>> jeder hat der dauerhaft was im EEPROM speichern will.>> Nee, nur jeder der was Millionenmal im Eeprom speichern will. Normale> Entwickler benutzen Eeprom einfach innerhalb der Herstellerspecs und> müssen sich nicht solchen Unsinn ausdenken.
Normale Entwickler gibts nur in Bielefeld.
Cheers
Detlef
Ja, nennt sich EEprom refresh cycle.
Also wenn man 10mio zählen will und dies das Einzige was man zählen
will, muss man wenn der Zähler 1626 mal incrementiert wurde ein
EEprom Refresh cycle machen. Will man jedoch auch noch die Minuten
zählen was
das Gerät eingeschalten ist, sowie das EEprom doppelt speichern, also
abwechselnd in page0 und in page1 , dann sieht die Sache etwas anders
aus.
Also 4 identische Zähler im EEprom, welche man aufsummiert,
<code>
if(((ee_cnt_15(EE_PWR)+ee_cnt_15(EE_TIME))>(ee_get(EE_REFRESH)*/*1626*-/
paging=>*/813))
{ ee_refresh(); ee_put(EE_REFRESH,ee_get(EE_REFRESH); }
</code>
Das obige gilt nur für echte byteaddressierte EEproms.
Weiters wird angenommend dass 9 EEprom bytes verwendet werden um 10 mio
zu zählen, mit einem 18bit Zähler (max 196608) und 53 bits als
prescaler.
Refresh cycle ist einfach das ganze EEprom durchgehen und für jedes Byte
dieses lesen und neu schreiben.
Ich verwende einen Zähler 18bit,= welcher als 15bit sowie extern 3bit
ausgelagert ist. Code für 15bit part lesen:
<code>
l=ee_get(addr),h=ee_get(addr^1); // flag
is bit7 of each byte, one flag is counter expired, the other flag is
word msb/lsb* at first addr
if((l&h)&0x80) return 0; //
expired -- error
if((l^h)&0x80) addr++; //
adjust endianess
l=ee_get(addr),h=ee_get(addr^1); // read
counter
h&=0x7f; // mask
out expired flag
</code>
Ozvald K. schrieb:> 10.000.000 Zyklen kann man mit 128 Bytes trotzdem erreichen ohne die> Spezifikationen zu verletzen mit 126 x low Byte + 1 x high Byte + 1 x> Bit 17 (65536-100000) + pointer auf low bytes.
Warum kann man nicht die gezeigten Endurance Funktionen von Apollo
nehmen, da reichen 80 Byte aus und es verstößt gegen keine
Spezifikation/DB. Sieht auch echt nachvollziehbar aus, oder?
HutaufHutab
chris schrieb:> Ich verwende einen Zähler 18bit,= welcher als 15bit sowie extern 3bit> ausgelagert ist. Code für 15bit part lesen:
Echt bizarr/wirr, ich verstehe nur Bahnhof!
Welche Sprache sprichst du?
HutaufHutab
Detlef _. schrieb:> Wenn einer der Zähler kaputt ist nehme ich für den ein neues> Byte an der Stelle an der er kaputt gegangen ist.
Wie stellst du denn fest, dass ein EEPROM Byte kaputt ist? Weil das ja
nicht direkt nach dem Schreiben kippen muss, sondern erst später -
irgendwann zufällig?
Dann ist nicht nur das letzt Increment weg, sondern wir haben dann eine
Unsicherheit von max +-8 oder so?
HutaufHutab
Andreas M. schrieb:> Bitweises Ändern von 1->0 ohne vorheriges löschen kann in die Hose> gehen. Wir haben einen ähnlichen Ansatz mit einem externen SPI Flash> verfolgt und haben dabei unerwartet Bitkipper in vollkommen anderen> Sektoren beobachtet.
Bei komplexeren Chips kann es sein, dass diese ECC Algorithmen eingebaut
haben. Die werden erstens durcheinandergebracht, wenn nur Teile von
Bytes geschrieben werden und außerdem muss auch beim Schreiben eines
einzelnen Bits immer die Checksumme nachgezogen und geschrieben werden,
d.h. die Checksum Bits würden dann früher altern als die Strichliste.
Die ECC kann natürlich auf größere Blöcke als "Byte" angewendet werden,
dann kann es wie du beschreibst Auswirkungen auf "benachbarte" Bytes
haben.
Michael
HutaufHutab schrieb:> Warum kann man nicht die gezeigten Endurance Funktionen von Apollo> nehmen, da reichen 80 Byte aus und es verstößt gegen keine> Spezifikation/DB. Sieht auch echt nachvollziehbar aus, oder?
Ich kann anhand von Beispiel mit 2 Ringpuffern den 80 Byte
Speicherbedarf nicht nachvollziehen
http://ww1.microchip.com/downloads/en/appnotes/doc2526.pdf.
Weil egal ob Ringpuffer oder was anderes, die Grenze von 100.000 Zyklen
pro Byte bleibt. Übersehe ich da was?
HutaufHutab schrieb:> Ozvald K. schrieb:>> 10.000.000 Zyklen kann man mit 128 Bytes trotzdem erreichen ohne die>> Spezifikationen zu verletzen mit 126 x low Byte + 1 x high Byte + 1 x>> Bit 17 (65536-100000) + pointer auf low bytes.>> Warum kann man nicht die gezeigten Endurance Funktionen von Apollo> nehmen, da reichen 80 Byte aus und es verstößt gegen keine> Spezifikation/DB. Sieht auch echt nachvollziehbar aus, oder?
1
Gew.ZyklenVorh.ZyklenSich.Faktor
2
10.000.000/100.000=100*2=200
Jedes bit darf demnach erst nach 200 Zyklen gelöscht und neu
beschrieben werden (berechnet mit einem Sicherheitsfaktor von 2,
also 50.000 anstatt 100.000 Löschzyklen).
1
Zyklenbit/Byteben.Bytes
2
200/8=25
Bleiben mehr als 100 Byt für andere Sachen wie High/Low Wert,
Pointer, CRC, Shadow EEP, etc.
Oder, man nimmt auch die oberen 25 Byt für Kontrolle und schreibt
gleich doppelt um ev. bitkippen zu erkennen.
P.S.
ATTINY85 kostet nur unwesentlich mehr, hat aber 512 Bytes EEPROM.
Marc V. schrieb:> Jedes bit darf demnach erst nach 200 Zyklen gelöscht und neu> beschrieben werden
Mit dieser Methode sind wir aber wieder bei "Striche zählen". Zu 25
Bytes fehlt noch ein 16-bit Zähler, der die Löschzyklen von Strichen
zählt. (50.000)
Ozvald K. schrieb:> Mit dieser Methode sind wir aber wieder bei "Striche zählen". Zu 25> Bytes fehlt noch ein 16-bit Zähler, der die Löschzyklen von Strichen> zählt. (50.000)
Selbst mit nur 2 Bytes und nur 50.000 Lösch/Schreibzyklen sind das
200 * 50.000 = 10.000.000, also halten auch diese 2 Bytes bis
10.000.000 Lösch/Schreibzyklen.
Mit 2 Mal so viel Bytes (2*25) + 2*2 = 54 Bytes, bleiben noch
74 Bytes für verschiedenes.
P.S.
Und wieder hat der schwachsinnige Idiot seine Bewertung abgegeben...
Ozvald K. schrieb:> Weil egal ob Ringpuffer oder was anderes, die Grenze von 100.000 Zyklen> pro Byte bleibt. Übersehe ich da was?
Ich meine ja, nachdem was ich hier so lese!
- 100K Write gilt nur sicher nach DB für Byte, daher die
Strichliste/Vorteiler Variante ist eigentlich ungeeignet.
- die Ringbuffervariante bildet die 100k Writes x-mal ab, um die
gewünschte Writeanzahl hinzubekommen und das auch sicher für den Status
bzw. die letzte Schreibposition.
Ausserdem erscheinen mir alle Ideen die mit "Redundanz" zu arbeiten als
sinnlos, weil das nur geht, wenn direkt beim Schreibzugriff der Fehler
erkennbar ist.
Das aber gilt nicht sicher, weil nach dem Schreibzugriff eine Bytezelle
am Lebensende irgendwann zufällig auch erst undefiniert wackeln kann.
Die verlinkten Dokumente von Microchip bringen das doch genau so auch
auf den Punkt.
Oder doch nicht?
HutaufHutab
HutaufHutab schrieb:> - 100K Write gilt nur sicher nach DB für Byte, daher die> Strichliste/Vorteiler Variante ist eigentlich ungeeignet.
Nein, warum?
Sowohl Atmel als auch Microchip reden über E/W Cyclen, also erst
Löschen und danach Schreiben.
Falls setzen eines einzelnen bits von 0 auf 1 möglich wäre, würde
Erase nicht nötig sein.
Deswegen gelten E/W Cyclen auch nur Byteweise, nicht bitweise.
Da aber das setzen eines bits auf 0 kein Erase erfordert, zählt
dies nicht zu EEPROM wearing bei.
P.S.
Und wieder hat der schwachsinnige Idiot zugeschlagen...
HutaufHutab schrieb:> - die Ringbuffervariante bildet die 100k Writes x-mal ab, um die> gewünschte Writeanzahl hinzubekommen und das auch sicher für den Status> bzw. die letzte Schreibposition.
Genau. Im Dokument doc2526.pdf ist das auch so beschrieben. Spielen wir
jetzt das durch: Wir wollen einen Zähler speichern der bis 10.000.000
zählt. 10.000.000 dez = 98 96 80 hex d.h wir brauchen 3 Bytes um zu
speichern. Dieser Wert wird in Ringpuffer jedes mal auf die nächste
Stelle gespeichert. Um jede Speicherstelle nicht mehr als 100k mal zu
beanspruchen wie groß muss der Ringpuffer sein? 10.000.000 / 100.000 * 3
= 300 Bytes, für Parameter Puffer, und noch einmal soviel für Status
Puffer.
Das ist meine Interpretation von dort beschriebener Methode. Bitte
korrigieren falls ich falsch lege.
HutaufHutab schrieb:> - 100K Write gilt nur sicher nach DB für Byte, daher die> Strichliste/Vorteiler Variante ist eigentlich ungeeignet.> Das aber gilt nicht sicher, weil nach dem Schreibzugriff eine Bytezelle> am Lebensende irgendwann zufällig auch erst undefiniert wackeln kann.>> Die verlinkten Dokumente von Microchip bringen das doch genau so auch> auf den Punkt.>> Oder doch nicht?
Eigentlich nicht :-)
Es steht drin, dass bestimmte Bit-Patterns 0->1->0->1 die Zellen
besonders abnutzen. Im Umkehrschluss kann man die Abnutzung reduzieren,
wenn man dies vermeidet und den Strichlistenalgorithmus verwendet:
"Worst casetesting would be to erase and write each bit, which is what a
write all “0”s pattern with an auto-erase of “1”routine will perform."
Für welche Hardware dies genau gilt müsste man noch klären, die AN ist
uralt.
> Ausserdem erscheinen mir alle Ideen die mit "Redundanz" zu arbeiten als> sinnlos, weil das nur geht, wenn direkt beim Schreibzugriff der Fehler> erkennbar ist.
Es reicht, den Fehler beim nächsten Auslesen festzustellen, der Fehler
wird sich wahrscheinlich sowieso erst viel später zeigen. Um den
korrekten Wert zu restaurieren benötigst du einen fehlerkorrigierenden
ECC Algorithmus, mit einfachem Duplizieren kannst du den Fehler nur
erkennen aber nicht korrigieren. Mehr dazu findet sich sicher in der
Google Patent Datenbank.
Michael
Marc V. schrieb:> Nein, warum?
DB, page 17, chapter 5.3.5 Write
... "If the location to be written has not been erased before write, the
data that is stored must be considered as lost."
Nach meinen Verständnis, schließt das auch Bit-Writes ein.
Und das auch unabhängig, ob nach Bitmusterlage ein Erase nötig wäre. Da
jedes Write die gesamte Zelle verändert, sprich diese Zelle verliert
Ladungsträger/degeneriert ihre Isolationsschichten auf allen
Bitpositionen.
Das wäre auch irgendwie logisch. Weil die Annahme, dass nur Erase die
Alterung bewirkt steht nirgends, dann hätte im DB stehen können 100k
Erase.
Nur da steht Erase/Write und diese Aussage jetzt zu zerlegen,
dahingegend, dass nur Erase das Altern bewirkt erscheint mir
unberechtigt.
HutaufHutab schrieb:> ... "If the location to be written has not been erased before write, the> data that is stored must be considered as lost.">> Nach meinen Verständnis, schließt das auch Bit-Writes ein.
Probiere mal eine EEPROM-location von 0x00 auf 0xFF ohne Löschen
zu ändern - von 0xFF auf 0x00 geht dies ohne Löschen und ohne
irgendwelche Probleme zu verursachen.
HutaufHutab schrieb:> Nur da steht Erase/Write und diese Aussage jetzt zu zerlegen,> dahingegend, dass nur Erase das Altern bewirkt erscheint mir> unberechtigt.
Und mir erscheint eine Aussage von 100K Erase ohne irgendetwas
in diese Zellen zu schreiben ein bisschen unsinnig, oder?
HutaufHutab schrieb:> Da> jedes Write die gesamte Zelle verändert, sprich diese Zelle verliert> Ladungsträger/degeneriert ihre Isolationsschichten auf allen> Bitpositionen.
Hier könnte man eventuell dagegen argumentieren, dass beim bitweise
Schreiben wenn der floating Gate schon aufgeladen ist, dann fließt kein
Strom mehr zum Gate und dadurch wird die Isolationsschicht weniger
beansprucht. Das ist nur meine persönliche Meinung, keine
wissenschaftliche Begründung.
Ozvald K. schrieb:> wie groß muss der Ringpuffer sein? 10.000.000 / 100.000 * 3> = 300 Bytes, für Parameter Puffer, und noch einmal soviel für Status> Puffer.
Ja stimmt, die 80Bytes von Apollo sind für 10Mio/Writes falsch und
gelten für 2Mio/Writes, weil 1Mio/40Bytes ...
Marc V. schrieb:> Und mir erscheint eine Aussage von 100K Erase ohne irgendetwas> in diese Zellen zu schreiben ein bisschen unsinnig, oder?
Das hängt von der Perspektive ab, als Programmierer vielleicht eher
unsinnig, als Halbleiterphysiker, den nur die Zellalterung interessiert,
eher egal und daher auch nur Erase.
Ich kann mir nicht vorstellen, dass wir das hier sicher aufklären
können.
HutaufHutab schrieb:> HutaufHutab schrieb:>> eher egal und daher auch nur Erase.>> ... ich meinte, auch nur Erase oder Writes.
Ja, aber sowohl ATMEL als auch Microchip reden immer von Erase/Write
Cycles, also Erase AND Write, nicht Erase OR Write, zumindest verstehe
ich das so...
HutaufHutab schrieb:> Ausserdem erscheinen mir alle Ideen die mit "Redundanz" zu arbeiten als> sinnlos, weil das nur geht, wenn direkt beim Schreibzugriff der Fehler> erkennbar ist.
Man kann aber den Zählerstand 3-fach abspeichern.
Nach dem Einschalten wird dann geprüft, ob Zähler 1 und Zähler 2
identisch sind, dann wir dieser verwendet.
Wenn beim letzten Abspeichern ein Stromausfall da war, dann sind die
beiden Zähler 1 und 2 u.U. nicht gleich, dann verwendet man den dritten,
zählt ihn um eins hoch und speichert disesn neuen Zählerstand wieder 3
mal ab.
Dirk schrieb:> dann verwendet man den dritten,> zählt ihn um eins hoch und speichert disesn neuen Zählerstand wieder 3> mal ab.
und das sind pro Stromausfall also hartes Abschalten 10 Mio writes auf 3
Byte?
Soweit waren wir doch schon!
Dirk schrieb:> Wie würdet ihr an einer Maschine, die in ihrem Leben 10 Mio mal ein und> ausgeschaltet wird, die Anzahl der Schaltungen zählen ?Dirk schrieb:> Man kann aber den Zählerstand 3-fach abspeichern.
bist du der TO?
du willst also 10 Mio. x 3 Byte schreiben auf 128 Byte mit 100k mögliche
sichere Schreibvorgänge?
Dirk schrieb:> Nach dem Einschalten wird dann geprüft, ob Zähler 1 und Zähler 2> identisch sind, dann wir dieser verwendet.>> Wenn beim letzten Abspeichern ein Stromausfall da war, dann sind die> beiden Zähler 1 und 2 u.U. nicht gleich,
... hier werden immer wieder zwei verschiedene Themen vermischt, die
nicht zusammengehören!
Die da wären, EEPROM Daten korrupt wegen
1. Stromausfall
2. Alterung
Zu Pkt. 2 lässt sich nicht sicher feststellen, ob die Daten (un)-gültig
sind, da beide Zähler gleich kippen können.
Marc V. schrieb:> Ja, aber sowohl ATMEL als auch Microchip reden immer von Erase/Write> Cycles, also Erase AND Write, nicht Erase OR Write, zumindest verstehe> ich das so...
ja ABER, die Hersteller sprechen davon, dass 100k Erase+Write garantiert
sind und ich/SC-Physiker spreche davon, dass sowohl Erase ODER/als auch
Write die EEPROM Zellen degeneriert/altert.
HutaufHutab schrieb:> ja ABER, die Hersteller sprechen davon, dass 100k Erase+Write garantiert> sind und ich/SC-Physiker spreche davon, dass sowohl Erase ODER/als auch> Write die EEPROM Zellen degeneriert/altert.
Da Erase (auf 1 setzen) und Write (auf 0 setzen) sich immer abwechseln
ist es egal was Du zählst. Hauptsache Du zählst nicht doppelt.
Nullen nochmal schreiben ist i.A. nicht erlaubt. Einsen nochmal löschen
schon, und das trägt auch nicht zur Alterung bei.
Nach den spezifizierten 100k Zyklen ist die Speicherzelle auch nicht
"kaputt" im Sinne von "es kommen falsche Daten raus". Es wird lediglich
die spezifizierte Data Retention Time nicht mehr eingehalten. Die Daten
bleiben dann nicht mehr 20 Jahre bei <55°C erhalten, sondern
entsprechend weniger.
Umgekehrt gilt: wenn Du gar keine 20 Jahre Datenerhalt benötigst, kannst
Du die Zellen deutlich öfter beschreiben. Viele Hersteller spezifizieren
im Datenblatt auch mehrere Stützstellen. Z.B "10k Zyklen für 20 Jahre,
100k Zyklen für 5 Jahre".
HutaufHutab schrieb:> Ja stimmt, die 80Bytes von Apollo sind für 10Mio/Writes falsch und> gelten für 2Mio/Writes, weil 1Mio/40Bytes ...
... das bedeutet mit Ringbuffer/Apollo-Lib sind
beim Attiny25 max 3Mio EEPROM Writes für einen 3-Byte Counter sicher
möglich und mit Attiny85 sind es max 12Mio.
Somit muss der TO auf Attiny85 umsteigen, wenn das mit dem Zähler was
sicheres werden soll.
Oder, wie/was denkt ihr dazu, sollen wir voten
im Sinne von Strichliste vs. Ringbuffer?
soul e. schrieb:> spezifizierte Data Retention Time
... das wäre jetzt sicher eine weiter neue und interessante
Perspektive/Abhängigkeit zu dem Thema, aber nur allgemein.
Weil, wenn es darum geht was du/Entwickler garantieren willst/musst
hilft das nicht weiter, da du nur weitere Annahmen treffen kannst - im
Sinne von aus 20Jahre Data Retention werden dann 10/5/...? oder denkbar
auch gleich 0/defekt.
Wenn also ein "juristisch sicherer" Counter das Ziel ist, dann brauchst
du am Ende Belege/Beweise ... sonst machen die Juristen dich nackig.
HutaufHutab schrieb:> Detlef _. schrieb:>> Wenn einer der Zähler kaputt ist nehme ich für den ein neues>> Byte an der Stelle an der er kaputt gegangen ist.>> Wie stellst du denn fest, dass ein EEPROM Byte kaputt ist? Weil das ja> nicht direkt nach dem Schreiben kippen muss, sondern erst später -> irgendwann zufällig?> Dann ist nicht nur das letzt Increment weg, sondern wir haben dann eine> Unsicherheit von max +-8 oder so?>>> HutaufHutab
Ich hab drei Zähler. Da weiß ich, dass einer und welcher kaputt ist.
Cheers
Detlef
Detlef _. schrieb:> Da weiß ich, dass einer und welcher kaputt ist.
In der Hoffnung, dass ein Doppelfehler seltener ist.
Da möchte ich an Murphy erinnern ....
... ich wage mal die Aussage, dass das Meiste was hier geschrieben wurde
gutes und weniger gutes Bastel-Level entspricht oder einfach nur Rate-
und Glaskugelspiele, aber auch mehr nicht.
Ich hoffe mal, dass die Wortmelder hier mehrheitlich keine
HW/SW-Entwickler, sind, sonst stellt sich die Frage, ob man noch mit
ruhigen Gewissen in ein Flugzeug/Auto einsteigen kann.
Weil technische Zuverlässigkeitsbetrachtungen, wissentlich solider
gedacht werden - hoffentlich bleibt das auch so!
Und Tschüss!
HutaufHutab schrieb:> Wenn also ein "juristisch sicherer" Counter das Ziel ist, dann brauchst> du am Ende Belege/Beweise ... sonst machen die Juristen dich nackig.
Dazu brauchst Du eine Spezifikation des Herstellers, vollkommen richtig.
Der hat die Daten vorliegen, schließlich hat er die Lebensdauer mal
ermittelt (und dafür nicht 100.000x zwanzig Jahre gewartet). Leider
unterliegen solche Daten üblicherweise einem NDA und stehen nicht im
allgemein zugänglichen Internet-Datenblatt.
Für den TO: den FAE des Herstellers fragen kostet nichts. Mit
entsprechendem Auftragsvolumen bekommt man auch Daten garantiert, die
nicht im öffentlichen Datenblatt stehen.
HutaufHutab schrieb:> Ich hoffe mal, dass die Wortmelder hier mehrheitlich keine> HW/SW-Entwickler, sind, sonst stellt sich die Frage, ob man noch mit> ruhigen Gewissen in ein Flugzeug/Auto einsteigen kann.
Wie ich schon in einem anderen Beitrag sagte:
Ein 24LC256 kostet als EinzelStück kaum mehr als 70 Ct., verträgt
über 1 Mio. Write/Erase Cycles und hat 32768 Bytes zum schreiben.
Glaubst du im Ernst, dass irgendein kommerzielles Gerät 10 Mio. Mal
in internes EEPROM von ATTINY25 schreiben würde?
Dirk schrieb:> Ja dann frag ich mal anders:> Wie würdet ihr an einer Maschine, die in ihrem Leben 10 Mio mal ein und> ausgeschaltet wird, die Anzahl der Schaltungen zählen ?
Bestimmt nicht mit internem EEPROM von ATTINY25.
Marc V. schrieb:> Ein 24LC256 kostet als EinzelStück kaum mehr als 70 Ct., verträgt> über 1 Mio. Write/Erase Cycles und hat 32768 Bytes zum schreibe
Wo du schon über kleine Ewigkeiten sprichst.....
Die Verwendung eines 23LCV1024 würde die Lebensdauer gegen Unendlich
treiben.
Und ganz soviel teurer ist das auch nicht.
Arduino Fanboy D. schrieb:> Die Verwendung eines 23LCV1024 würde die Lebensdauer gegen Unendlich> treiben.
Wohl kaum, weil du verheimlichst die weit von Unendlich begrenzte
Lebensdauer der notwendigen Batterie.
Das ist ziemlich unseriös! Hast du das vielleicht bei der Autoindustrie
gelernt?
BTW, das wird auch bald der Normalverbraucher dazu lernen, wie oft und
teuer so ein Batterietausch sein kann für das Bike/Auto.
