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.
Marcus H. schrieb: > Ganz grob zusammengefasst: Ach neee? Du meinst also du erzählst hier was Neues?
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
Apollo M. schrieb: > ahnungslosen labertypen Lexikon hat Bild von mir. In der Funktion eeReadData() hab ich das folgende entdeckt.
1 | # else
|
2 | if (0); |
3 | # endif
|
Why? Ansonsten vielen Dank für den Code.
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.
Apollo M. schrieb: > update folgt! update attached 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 some references: http://ww1.microchip.com/downloads/en/appnotes/doc2526.pdf http://ww1.microchip.com/downloads/en/appnotes/01019a.pdf http://www.t-es-t.hu/download/microchip/an602a.pdf mt
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
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
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 :)
:
Bearbeitet durch User
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.
Um define Frage zu beantworten, ja es word so gemacht und auch doppelt abgespeichert. Für 10mio braucht es 15 eeprom bytes.
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
Beitrag #6167411 wurde vom Autor gelöscht.
Beitrag #6167426 wurde vom Autor gelöscht.
Beitrag #6167456 wurde vom Autor gelöscht.
minor update! pre-compiler bugs fixed and related conditions simplified mt
Wenn das wieder ein Rohrkrempierer sein sollte, erfolgt die Degradierung zum Sergeant.
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!
Autsch, seh' ich jetzt erst: da hat mir doch der alte Freud über die Schulter geschaut - na, kann passieren.
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....
1 | # ifdef EEDATA_U8
|
2 | if (p->type == EEDATA_U8) |
3 | return (eedata_t)eeprom_read_byte((uint8_t*) (p->bufStartAddr+p->dataIdxAddr)); |
4 | # endif
|
5 | |
6 | # ifdef EEDATA_U16
|
7 | # ifdef EEDATA_U8
|
8 | else
|
9 | # endif
|
10 | if (p->type == EEDATA_U16) |
11 | return (eedata_t)eeprom_read_word((uint16_t*) (p->bufStartAddr+p->dataIdxAddr)); |
12 | # endif
|
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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...
1 | # ifdef EEDATA_U8
|
2 | if (p->type == EEDATA_U8) |
3 | return (eedata_t)eeprom_read_byte((uint8_t*) (p->bufStartAddr+p->dataIdxAddr)); |
4 | # endif
|
5 | |
6 | # ifdef EEDATA_U16
|
7 | if (p->type == EEDATA_U16) |
8 | return (eedata_t)eeprom_read_word((uint16_t*) (p->bufStartAddr+p->dataIdxAddr)); |
9 | # endif
|
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...
1 | switch (p->type) |
2 | {
|
3 | # ifdef EEDATA_U8
|
4 | case EEDATA_U8: |
5 | return (eedata_t)eeprom_read_byte((uint8_t*) (p->bufStartAddr+p->dataIdxAddr)); |
6 | # endif
|
7 | |
8 | # ifdef EEDATA_U16
|
9 | case EEDATA_U16: |
10 | return (eedata_t)eeprom_read_word((uint16_t*) (p->bufStartAddr+p->dataIdxAddr)); |
11 | # endif
|
12 | |
13 | # ifdef EEDATA_U24
|
14 | case EEDATA_U24: |
15 | union {uint32_t u32; uint8_t u8[3];} d = {.u32=0}; |
16 | for(uint8_t i=0; i!=3; i++) |
17 | d.u8[i] = eeprom_read_byte((uint8_t*) (p->bufStartAddr+p->dataIdxAddr+i)); |
18 | return (eedata_t)(d.u32); |
19 | # endif
|
20 | # if defined EEDATA_U32 || defined EEDATA_FLOAT
|
21 | case EEDATA_U32: |
22 | return (eedata_t)eeprom_read_dword((uint32_t*) (p->bufStartAddr+p->dataIdxAddr)); |
23 | # endif
|
24 | }
|
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
Ich verwende diese routinen,
uint bits(uint32_t val) { uchar i=0; for(;val;val>>=1) if(val&1) i++;
return i; }
uint32_t ee_cnt(uint16_t addr, uint8_t cnt) { // 3bytes = 1.572.863 --
4bytes = 3.670.015
uint8_t cnt_flag(uint16_t addr, uint8_t mask) { ... }
void ee_inc(uint16_t addr, uint8_t cnt) { }
ee(addr) liefert ~eeprom_get_byte(ee_+addr) zurueck
ee_(addr,val) ist eeprom_update_byte(ee_+addr,val)
aber was sollen diese Routinen bei so einer Frage ?
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
Dirk schrieb: > Die Ersae/Write Zyklen sind ja auf 100.000 im Datenblatt spezifiziert. Wo steht im Datenblatt, dass dieser Wert pro Zelle gilt?
Hoffentlich leben nach 10 Millionen Betätigungen Dein Schalter und der Finger noch!
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?
:
Bearbeitet durch User
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
:
Bearbeitet durch User
Gustl B. schrieb: > Moin! Ich habe ja keine Ahnung ob ich das verstanden Du hast es exakt verstanden !!!!
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
Hier mein Code der beim Einschalten einen "Strich" (Bit im EEPROM löschen) hinzufügt:
1 | unsigned int zeiger; |
2 | unsigned char flag; |
3 | |
4 | while(EECR & (1<<EEPE));// Warten bis EEPROM Schreiben fertig |
5 | while (!flag) // EEPROM durchsuchen, |
6 | |
7 | { // bis Stelle mit !=0 gefunden wird |
8 | EEAR = zeiger/8; // Zeiger auf EEPROM Daten |
9 | EECR |= (1<<EERE); // Start eeprom read by writing EERE |
10 | // Wenn Byte komplett gelöscht 0x00, dann nächstes testen
|
11 | |
12 | if ( EEDR == 0 ) zeiger=zeiger+8; |
13 | else // Sonst gelöschte bits im Byte zählen |
14 | {
|
15 | flag = 1; |
16 | for(i=0; i < 8; ++i) |
17 | if (~EEDR & (1 << i)) |
18 | zeiger++; |
19 | }
|
20 | }
|
21 | |
22 | EECR = (1<<EEPM1)|(0<<EEPM0); /* Mode 10=Write only*/ |
23 | EEAR = zeiger/8; /* Set up address */ |
24 | EEDR = 0xfe<<zeiger%8; /* Set up data */ |
25 | EECR |= (1<<EEMPE); /* Write logical one*/ |
26 | EECR |= (1<<EEPE); /* Start eeprom write*/ |
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
:
Bearbeitet durch User
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: > Das Problem bei Flash Chips ist, Danke für den Hinweis. Aber der ATtiny25 hat doch ein echtes EEPROM drin, oder ?
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...
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.
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
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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. Zyklen Vorh. Zyklen Sich. 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 | Zyklen bit/Byte ben. 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.
:
Bearbeitet durch User
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)
Angehängte Dateien:
-
2020-03-09_210323.png
15 KB
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...
:
Bearbeitet durch User
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
Angehängte Dateien:
-
2020-03-09_214946.png
31 KB
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...
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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: > eher egal und daher auch nur Erase. ... ich meinte, auch nur Erase oder Writes.
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...
:
Bearbeitet durch User
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.
Beitrag #6174259 wurde vom Autor gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.