Hallo an die EEPROM-Spezialisten, ich hab einige, vielleicht nicht alltägliche, Fragen zum controllerinternen EEPROM angehäuft die mich schon länger beschäftigen. Mir ist klar, dass bei jeder Anwendung im Vorfeld geprüft werden soll, ob das in den Datenblättern angegebene EEPROM-Schreibzyklen-Limit für die vorgesehene Produktlebensdauer auch eingehalten wird. Thema: „(Un)geplante Obsoleszenz“, aber darauf will ich hier nicht hinaus – im Gegenteil. Für die neueren AVR Controller wird in den Datenblättern eine Lebenserwartung von 100.000 Schreibzyklen für das EEPROM angegeben. Wobei sich mir hier schon meine erste Frage aufdrängt, denn genaugenommen steht in den Datenblättern immer folgender Wortlaut: „EEPROM Standhaftigkeit: 100.000 Schreib- / Lesezyklen“. Ich kann mir aber nicht vorstellen dass auch Lesezugriffe die Lebensdauer des EEPROM marginal beeinträchtigen? Interessant zu wissen wäre auch, ob sich das Schreibzyklen-Limit nur auf das Schreiben der immer selben Speicheradresse bezieht, oder ist das zweitrangig und auch wenn ich ein Byte gleichmäßig über den gesamten EEPROM-Speicher verteile, ist (schon) nach 100.000 Schreibzyklen Schluss? Was ich bisher in Erfahrung bringen konnte ist, dass jeder EEPROM-Speichervorgang die Speicherzellen-Oxidschicht immer weiter degeneriert lässt bis diese dann keine Isolationswirkung mehr hat und die Speicherzelle somit ihre Information verliert. Unklar ist mir, ob sich die Degeneration beim Schreiben nur auf die betroffene Speicherzelle, oder aber auf alle Speicherzellen gleichzeitig auswirkt? Vom logischen Standpunkt aus würde ich jetzt zu ersterem tendieren, da ja in den unbeschriebenen Speicherzellen kein physikalischer Vorgang einsetzen muss? Wenn ich richtig liege könnte man mit einem Adresszeiger und einem Schreibzyklen-Zähler, die im EEPROM selbst verankert sind, die EEPROM-Lebensdauer sooft vervielfachen solange das Datenvolumen aneinandergereiht den EEPROM-Speicher nicht überschreitet. Der Zyklen-Zähler selbst muss dann natürlich auch mit dem Adresszeiger aufs nächste EEPROM-Segment verschoben werden, sonst wird der selbst ans Schreibzyklen-Limit geraten. Wenn ich das Ganze nun weiter spinne, wäre meine nächste Frage: Nach welcher Anzahl an Schreibzyklen, im prozentualem Verhältnis zum angegebenen Schreibzyklen-Limit, würdet Ihr die Adresse auf das nächste Datensegment weiterschalten, damit sichergestellt ist, das das EEPROM nicht durch übermäßige Schreibzugriffe auf ein und das selbe Datensegment ausfällt? Sind 50% angemessen, also hier 50.000 Zyklen, wenn man annimmt dass das in den Datenblättern angegebenen Schreibzyklen-Limit nur ein Durchschnittswert ist? Was aber geschieht denn nun genau, wenn es mal soweit ist und der letzte EEPROM-Schreibversuch „daneben“ geht – der letzte Drops gelutscht ist? Ich hab mir dazu drei mögliche Szenarien ausgemalt: 1. Das EEPE-Bit (bei älteren Controllern das EEWE-Bit) wird vom Controller nicht mehr gelöscht und der nachfolgende EEPROM-Zugriff hängt sich in einer Endlosschleife auf, falls das nicht durch ein Timeout abgefangen wird - so wie es auch in vielen Beispielen angegeben ist? EEPROM_read: sbic EECR,EEPE ; prüfe ob der vorherige Schreibzugriff beendet ist rjmp EEPROM_read ; nein, nochmal prüfen … 2. Das Byte wird richtig ans EEPROM übergeben, aber dort nicht richtig eingebrannt, weil sich die Oxidschicht der Speicherzelle bereits aufgelöst hat und schon der nächstfolgende Lesezugriff darauf bringt den falschen Fünfziger in Umlauf? 3. Das Byte wird zwar richtig im EEPROM gespeichert, verändert sich aber ohne Zutun nach einer undefinierbaren Zeit oder einem Ereignis wie zum Beispiel dem Aus- oder Einschalten der Versorgungsspannung? Ich frage deshalb, weil sich im Grunde genommen diese Fälle unabhängig von der EEPROM-Lebenserwartung über geeignete Fehlerroutinen abfangen und dann vorteilhafter Weise auch ausgeben ließen. Sei es denn über eine Timeout-Überwachung des EEPE-Bits, einer EEPROM Prüfsumme, einem EEPROM Schreibzyklen-Zähler und einem sofortigen Lesevergleich mit dem geschriebenen Byte. Die Frage ist nur welcher der Fälle kann real auftreten oder ist mir nicht eingefallen und welchen Aufwand betreibt man, oder kann man betreiben, in Abhängigkeit davon wie wichtig einem die EEPROM-Daten sind und wieviel Controller-Zeit zur Verfügung steht? Was meiner Meinung nach ein kleines bisschen zur Schonung des EEPROM beiträgt ist vor dem Schreiben zu prüfen ob die Speicherzelle nicht bereits den gewünschten Wert enthält. Denn jeder Schreibzugriff löscht ja die EEPROM-Zelle zunächst und beschreibt sie dann neu - ist also ein unnötiger Zyklus und kann, im zugegeben seltenen, aber günstigsten Fall, 3,4 ms Verarbeitungszeit fürs Schreiben einsparen wenn mehrere Daten hintereinander geschrieben werden müssen. Das ist zwar nicht viel, gibt einem aber ein gutes Gefühl bei Anwendungen die in einer Power-fail Routine noch schnell ein paar Daten ins EEPROM retten müssen bevor die Versorgungsspannung zusammenbricht. Da setzen nun auch meine letzten beiden Fragen an, die aber diesmal nichts dem Schreibzyklen-Limit zu tun haben. Angenommen ein Controller hat keine Power-fail Überwachung und der Brown-out Reset ist deaktiviert. Was geschieht nun wenn ein EEPROM-Schreibzyklus ausgelöst wird aber noch bevor dieser beendet ist, bricht die Versorgungsspannung soweit ein dass ein Power-on Reset ausgelöst wird. Ist es dann Zufall wenn das Byte richtig geschrieben wurde? Und ist es auch Zufall wenn das Byte richtig geschrieben wird, wenn während des Schreibvorgangs, bei intakter Versorgungsspannung, ein Reset beliebigen Ursprungs ausgelöst wird, oder ist zumindest dieser Vorgang failsafe gestaltet? Das soll es jetzt aber auch gewesen sein. Ich hoffe ich hab es nicht übertrieben mit der Fragerei und habe niemanden zu Tode gelangweilt?! Schönes Wochenende Chris
Hallo ich bin zwar kein EEPROM Spezialist, aber die ersten zwei Fragen kann ich dir beantworten :-) Chris D. schrieb: > Für die neueren AVR Controller wird in den Datenblättern eine > Lebenserwartung von 100.000 Schreibzyklen für das EEPROM angegeben. > Wobei sich mir hier schon meine erste Frage aufdrängt, denn > genaugenommen steht in den Datenblättern immer folgender Wortlaut: > „EEPROM Standhaftigkeit: 100.000 Schreib- / Lesezyklen“. > Ich kann mir aber nicht vorstellen dass auch Lesezugriffe die > Lebensdauer des EEPROM marginal beeinträchtigen? Das tun sie auch nicht! Lesen kann man einen EEPROM immer unbegrenzt. Chris D. schrieb: > Interessant zu wissen wäre auch, ob sich das Schreibzyklen-Limit nur auf > das Schreiben der immer selben Speicheradresse bezieht, oder ist das > zweitrangig und auch wenn ich ein Byte gleichmäßig über den gesamten > EEPROM-Speicher verteile, ist (schon) nach 100.000 Schreibzyklen > Schluss? Nein! Wenn du ein Byte 100.000 mal auf die selbe Adresse schreibst dann wird ab dem 100.001 'ten mal kein richtiger Speichervorgang mehr garantiert. Wenn du aber dieses Byte über einen Adresscounter verteilt schreibst kannst du diesen Wert mal die Speichergröße in Bytes nehmen BSP: 32 Byte Speicher mit 100.000 Schreibzyklen -> 32 X 100.000 Schreibzyklen
Hier findest du noch hilfreiche Infos... https://www.mikrocontroller.net/articles/AVR-Tutorial:_Speicher
Chris D. schrieb: > Interessant zu wissen wäre auch, ob sich das Schreibzyklen-Limit nur auf > das Schreiben der immer selben Speicheradresse bezieht, oder ist das > zweitrangig und auch wenn ich ein Byte gleichmäßig über den gesamten > EEPROM-Speicher verteile, ist (schon) nach 100.000 Schreibzyklen > Schluss? Nein. Aber sehr wichtig in diesem Zusammenhang ist Pagesize. Wenn Pagesize z.B. 4 Byt ist, dann ist es egal ob du in diese Page ein Byte oder ein Long schreibst - es werden immer Pagesize Byte geschrieben, auch wenn ATMEL das nicht explizit sagt. Es ist also nur meine Vermutung, anders ginge es meiner Meinung nach auch nicht. Jede Page sollte mindestens 100000 Schreibzyklen aushalten - aber nicht 4*100000 fur jedes Byte in diese Page. EEP_SIZE / PAGE_SIZE = Nutzbare Adressen zum 100000 Schreiben.
Chris D. schrieb: > Für die neueren AVR Controller wird in den Datenblättern eine > Lebenserwartung von 100.000 Schreibzyklen für das EEPROM angegeben. > Wobei sich mir hier schon meine erste Frage aufdrängt, denn > genaugenommen steht in den Datenblättern immer folgender Wortlaut: > „EEPROM Standhaftigkeit: 100.000 Schreib- / Lesezyklen“. > Ich kann mir aber nicht vorstellen dass auch Lesezugriffe die > Lebensdauer des EEPROM marginal beeinträchtigen? Du musst an deinem Englisch arbeiten. In den Datenblättern steht: > The EEPROM has an endurance of at least 100,000 write/erase cycles. Das heißt: Das EEPROM hat einen Haltbarkeit von mindestens 100.000 Schreib-/Löschzyklen. Vom Lesen seh ich da nix. Wo hast du da gelese, dass da sowas steht wie: > The EEPROM has an endurance of at least 100,000 write/read cycles. ?? Chris D. schrieb: > Was meiner Meinung nach ein kleines bisschen zur Schonung des EEPROM > beiträgt ist vor dem Schreiben zu prüfen ob die Speicherzelle nicht > bereits den gewünschten Wert enthält. Die avr/eeprom.h kennst du? Da gibt es so Funktionen wie eeprom_write_word(&value, value) die schreibt den Wert value einfach an die Adresse &value. Es gibt aber auch eeprom_update_word(&value, value) und die Funktion prüft vorher was an der Adresse &value steht und wenn das der gleiche Wert wie value ist wird nix geschrieben. Nachteil ist halt, dass es länger dauert da ja zunächst ein Lesezyklus erfolgt. Ist die Frage wie schnell man die Daten wegspeichern will/muss.
:
Bearbeitet durch User
Ich meine, dass man nicht zwangsläufig ganze Pagesizes beschreiben muss. Der Löschvorgang bezieht sich immer auf eine Page. Beschreiben kann man die Zellen einzeln. Und die Library unterstützt das auch. Wenn du eine Page (also 4 Bytes) löscht und dann die vier Bytes nacheinander beschreibst, hast du pro Zelle nicht mehr als 2 Zyklen. Denn jedes Byte wird nur einmal gelöscht und einmal verändert. ?? ?? ?? ?? Unbekannter Anfangszustand FF FF FF FF Nach dem Löschen 11 FF FF FF Erster Schreibzugriff 11 22 FF FF Zweiter Schreibzugriff 11 22 33 FF Dritter Schreibzugriff 11 22 33 44 Vierter Schreibzugriff Genau genommen gilt das IMHO für jedes einzelne Bit. Bei den vier Bytes könnte man 32 Schreibzugriffe machen, die jeweils nur ein Bit ändern. Dann altert jedes Bit um maximal 2 Zyklen.
Stefan U. schrieb: > Genau genommen gilt das IMHO für jedes einzelne Bit. Wie schreibst du denn ein einzelnes Bit ins EEPROM?
Wo steht denn eigentlich, dass das EEPROM seitenweise gelöscht werden muss...? Das war doch eigentlich immer das Unterscheidungskriterium zum Flash-Speicher.
Chris D. schrieb: > 3. Das Byte wird zwar richtig im EEPROM gespeichert, verändert sich > aber ohne Zutun nach einer undefinierbaren Zeit das. aber auch nicht ab dem 100001 schreibzugriff. vielleicht kannst du auch 500000 schreibzugriffe machen ohne probleme zu kriegen, dafür arantiert dir aber keiner!
@ Stefan Us (stefanus) >Ich meine, dass man nicht zwangsläufig ganze Pagesizes beschreiben muss. Beim AVR gibt es aus CPU-Sicht keine Pages. Nur per ISP kann man Pages löschen und beschreiben. Und bei EEROM KANN man Pages löschen, MUSS es aber nicht! Das ist KEIN Flash! Bei EEPROM sind einzelne Bytes lösch- und schreibbar! Daß die seriellen EEPROMS das meist nur seitenweise anbieten, ist ein anderes Thema! >Der Löschvorgang bezieht sich immer auf eine Page. Beschreiben kann man >die Zellen einzeln. Und die Library unterstützt das auch. Die Funktionen in der libc vom avr gcc arbeiten komplett bytebasierend, siehe oben!
@Chris D. (m8nix) >Interessant zu wissen wäre auch, ob sich das Schreibzyklen-Limit nur auf >das Schreiben der immer selben Speicheradresse bezieht, Ja. > oder ist das >zweitrangig und auch wenn ich ein Byte gleichmäßig über den gesamten >EEPROM-Speicher verteile, ist (schon) nach 100.000 Schreibzyklen >Schluss? Nein! >Was ich bisher in Erfahrung bringen konnte ist, dass jeder >EEPROM-Speichervorgang die Speicherzellen-Oxidschicht immer weiter >degeneriert lässt bis diese dann keine Isolationswirkung mehr hat und >die Speicherzelle somit ihre Information verliert. Jain. >Unklar ist mir, ob sich die Degeneration beim Schreiben nur auf die >betroffene Speicherzelle, Ja. > oder aber auf alle Speicherzellen >gleichzeitig auswirkt? Nein. >Wenn ich richtig liege könnte man mit einem Adresszeiger und einem >Schreibzyklen-Zähler, die im EEPROM selbst verankert sind, Jain. Im einfachen Ansatz würden die ja auf einer konstanten Adresse liegen und bei jedem Update einen Schreibvorgang erfahren. Damit ist nich 100k Schreibvorgängen offiziell Schluß. Geht also nicht wirklich, denn dann könnte man auch gleich 100k mal die Daten direkt schreiben. Also muss man den Adresszeiger ebenfalls verteilt schreiben. Ein einfacher Ansatz ist eine Serielnnummer mit 32 Bit. Das hab ich vor einiger Zeit in einem Projekt gemacht. Ein Datensatz mit ca. 200 Byte wird um eine 32 Bit Seriennummer erweitert. Die Datenstz werden im (seriellen) EEPROM in einem logischen Ringpuffer geschrieben, d.h. jeder schreibvorgang geht auf die nächste Adresse bzw. hier Page. Am Ende des EEPROM-Adressraums gehts bei 0 wieder los (Adressüberlauf, wrap around). Beim Programmstart wird der EEPROM nach der höchsten Seriennummer durchsucht. Dann hat man wieder seinen letzten, aktuellen Datensatz. Damit kann man problemlos ein Datenvolumen von 100k * EEPROM Größe schreiben. >Zyklen-Zähler selbst muss dann natürlich auch mit dem Adresszeiger aufs >nächste EEPROM-Segment verschoben werden, sonst wird der selbst ans >Schreibzyklen-Limit geraten. Eben. Und dann hat man die oben genannte Seriennummer ;-) >Wenn ich das Ganze nun weiter spinne, wäre meine nächste Frage: Nach >welcher Anzahl an Schreibzyklen, im prozentualem Verhältnis zum >angegebenen Schreibzyklen-Limit, würdet Ihr die Adresse auf das nächste >Datensegment weiterschalten, damit sichergestellt ist, das das EEPROM >nicht durch übermäßige Schreibzugriffe auf ein und das selbe >Datensegment ausfällt? Sind 50% angemessen, also hier 50.000 Zyklen, >wenn man annimmt dass das in den Datenblättern angegebenen >Schreibzyklen-Limit nur ein Durchschnittswert ist? Ich würde es bei JEDEM Zugriff eins weiter schalten, denn dadurch werden ALLÖE Zellen gleichmäßig belastet und die, wenn gleich auch sehr kleine Wahrscheinlichkeit von vereinzelten Frühausfällen wird deutlich gesenkt. >1. Das EEPE-Bit (bei älteren Controllern das EEWE-Bit) wird vom >Controller nicht mehr gelöscht und der nachfolgende EEPROM-Zugriff hängt >sich in einer Endlosschleife auf, Das passiert nicht. Der Schrteibzugriff wird IMMER beendet, auch wenn vielleicht die falschen Daten im EEPROM landen. >2. Das Byte wird richtig ans EEPROM übergeben, aber dort nicht richtig >eingebrannt, weil sich die Oxidschicht der Speicherzelle bereits >aufgelöst hat und schon der nächstfolgende Lesezugriff darauf bringt den >falschen Fünfziger in Umlauf? Genau so. >3. Das Byte wird zwar richtig im EEPROM gespeichert, verändert sich >aber ohne Zutun nach einer undefinierbaren Zeit oder einem Ereignis wie >zum Beispiel dem Aus- oder Einschalten der Versorgungsspannung? Auch das wird passieren. >Angenommen ein Controller hat keine Power-fail Überwachung und der >Brown-out Reset ist deaktiviert. Was geschieht nun wenn ein >EEPROM-Schreibzyklus ausgelöst wird aber noch bevor dieser beendet ist, >bricht die Versorgungsspannung soweit ein dass ein Power-on Reset >ausgelöst wird. Ist es dann Zufall wenn das Byte richtig geschrieben >wurde? Ja. Im Extremfall werden dadurch aber auch andere EEPROM-Zellen teilweise gelöscht, weil die Steuerung Unsinn macht. Das muss man auf jeden Fall vermeiden! >Und ist es auch Zufall wenn das Byte richtig geschrieben wird, wenn >während des Schreibvorgangs, bei intakter Versorgungsspannung, ein Reset >beliebigen Ursprungs ausgelöst wird, oder ist zumindest dieser Vorgang >failsafe gestaltet? Ja.
Falk B. schrieb: > Beim AVR gibt es aus CPU-Sicht keine Pages. Nein, aus deiner Sicht gibt es keine Pages (als user, meine ich). Falk B. schrieb: > Nur per ISP kann man Pages löschen und beschreiben. Mit ISP sendet man Befehle, da wird man nicht direkt an interne Adress- und Datenleitungen angeschlossen. Also, wird es von der CPU ausgeführt. Warum glaubst du, dass das anders funktioniert als bei einem Programm der aus FLASH ausgeführt wird ? AVR besitzt page buffer sowohl für FLASH als auch für EEPROM und da es kostengünstiger ist, mit Pages zu arbeiten, als mit einzelnen Bytes, haben sich die AVR-Leute wahrscheinlich gedacht... Falk B. schrieb: > aber nicht! Das ist KEIN Flash! Bei EEPROM sind einzelne Bytes lösch- > und schreibbar! Daß die seriellen EEPROMS das meist nur seitenweise > anbieten, ist ein anderes Thema! Wozu schreien ? Wie war das noch: Wer schreit, hat meistens... EDIT: Bei parallelen EEPROMS (vor 20-30 Jahren aktuell) war das noch möglich, aber die hatten auch sooo viele Pins, waren so teuer in der Produktion, da hat man sich entschlossen, anders vorzugehen.
:
Bearbeitet durch User
Hallo, zunächst vielen Dank für Eure Antworten. @ Falk, ich hab mir selber ein Ei gelegt mit meiner Fragestellung hier: >>Und ist es auch Zufall wenn das Byte richtig geschrieben wird, wenn >>während des Schreibvorgangs, bei intakter Versorgungsspannung, ein Reset >>beliebigen Ursprungs ausgelöst wird, oder ist zumindest dieser Vorgang >>failsafe gestaltet? >Ja. Ich nehme an das Du damit „Ja im Sinne von failsafe“ gemeint hast? Ansonsten wäre ich jetzt schon etwas verwundert, denn diesen zwar unwahrscheinlichen, aber möglichen Fall, kann man nun mal nicht verhindern. Darum hab ich jetzt noch mal etwas recherchiert und folgendes gefunden: >"If a reset occurs while a write operation is in progress, the write operation will be completed provided that the power supply voltage is sufficient."< Aber, es ist es wohl so, das bei den älteren AVR-Generationen trotzdem etwas schief kann wenn ein Reset zum Zeitpunkt eines Schreibzyklus auftritt, selbst wenn die Versorgungsspannung in Ordnung ist. Wobei ich nicht weiß welche Generation da genau gemeint ist. Bei diesen Controllern wird bei einem Reset nach Beginn eines Schreibzyklus das EEPROM Address Register (EEAR) auf den Initialwert 0x00 zurückgesetzt. So das das zu schreibende Byte ungewollt an der EEPROM Adresse 0x0000 landen kann, wenn der Reset zu einem frühen Zeitpunkt nach dem initiieren des Schreibvorgangs stattfindet. Also reine Glückssache. >>Zyklen-Zähler selbst muss dann natürlich auch mit dem Adresszeiger aufs >>nächste EEPROM-Segment verschoben werden, sonst wird der selbst ans >>Schreibzyklen-Limit geraten. >Eben. Und dann hat man die oben genannte Seriennummer ;-) Deine Idee mit der Seriennummer finde ich super. Mir gefällt der Ansatz dass der EEPROM-Speicher „gleichmäßig abgenutzt“ wird und nicht so wie in meinem Konzept Blockweise, welches die Wahrscheinlichkeit zum vorzeitigen Ableben des EEPROM erhöht. Mein Konzept war folgendes: [EEPROM-Start] 0x0000 Adresszeiger auf den Anfang der Datenblöcke - Init: 0x0002, nächster Wert 0x000C, …, letzter Wert 0x0FF6 Datenblock 1 0x0002 Schreibzyklenzähler 1-> Schaltet den Adresszeiger beim erreichen Limits weiter. 0x0004 Nutzdaten 1 0x0006 Nutzdaten 2 0x0008 Nutzdaten 3 0x000A Prüfsummme 1 (inklusiv Schreibzyklenzähler 1) Datenblock 2 0x000C Schreibzyklenzähler 2-> Schaltet den Adresszeiger beim erreichen Limits weiter. 0x000E Nutzdaten 1 0x0010 Nutzdaten 2 0x0012 Nutzdaten 3 0x0014 Prüfsummme 2 (inklusiv Schreibzyklenzähler 2) . . . Datenblock x 0x0FF6 Schreibzyklenzähler x-> Beim erreichen Limits ist der EEPROM-Speicher am erwarteten Lebensende. 0x0FF8 Nutzdaten 1 0x0FFA Nutzdaten 2 0x0FFC Nutzdaten 3 0x0FFE Prüfsummme x (inklusiv Schreibzyklenzähler x) [EEPROM-End] … und hier der das Konzept von Falk, sofern ich es richtig verstanden habe: [EEPROM-Start] Datenblock A 0x0000 Nutzdaten 1 0x0002 Nutzdaten 2 0x0004 Nutzdaten 3 0x0006 Seriennummer A (Init: 0x00000000), -> = Seriennummer x + 1 0x000A Prüfsumme A (inklusiv Seriennummer A) Datenblock B 0x000C Nutzdaten 1 0x000E Nutzdaten 2 0x0010 Nutzdaten 3 0x0012 Seriennummer B = Seriennummer A + 1 0x0016 Prüfsumme B (inklusiv Seriennummer B) . . . Datenblock x 0x0FF4 Nutzdaten 1 0x0FF6 Nutzdaten 2 0x0FF8 Nutzdaten 3 0x0FFA Seriennummer x = Seriennummer (x-1) + 1 -> Wrap around to A 0x0FFE Prüfsumme x (inklusiv Seriennummer x) [EEPROM-End] Damit sind eigentlich alle meine Fragen beantwortet. Wobei ich das Ganze noch einmal zusammenfassen möchte, damit der Tenor einheitlich ausfällt und alle damit leben können?! 1. Das im Datenblatt angegebene EEPROM Schreibzyklen-Limit ist eine Angabe über die minimale Anzahl an Schreib-/Löschzyklen die durchgeführt werden können, bevor das EEPROM ableben kann. (Danke an M. Köhler) Eine Garantie dafür, dass das EEPROM aber nicht schon vorher seinen Dienst versagt, gibt es allerdings nicht. 2. Das Schreibzyklen-Limit bezieht sich nur auf EEPROM Schreib-/Löschzyklen. Lesen beeinträchtigt die EEPROM-Lebensdauer nicht. 3. Das Schreibzyklen-Limit gilt für jede einzelne Speicherzelle individuell. Die Anzahl an insgesamt durchgeführten Schreibzyklen auf unterschiedliche Speicherzellen ist dabei unerheblich. Basierend darauf kann eine gleichmäßige Datenverteilung über den gesamten EEPROM-Speicher die EEPROM-Lebensdauer positiv beeinflussen. 4. Beim Schreiben auf eine degenerierte Speicherzelle können Daten sofort falsch im EEPROM abgelegt werden, oder verzögert ihre Information verlieren. 5. Das EEPE-Bit (EEWE-Bit) wird nach einem Schreibvorgang auch dann vom Controller zurückgesetzt wenn Daten falsch ins EEPROM eingebrannt wurden. 6. Tritt ein Reset während eines EEPROM-Schreibvorgangs ein, wird der Schreibvorgang korrekt abgeschlossen - Vorausgesetzt die Controller Versorgungsspannung ist während des Schreibvorgangs innerhalb der spezifizierten Grenzen! Ausnahme: Ältere ARV Controller Generationen. Dort können Daten auch bei intakter Versorgungsspannung ungewollt an Adresse 0x0000 landen. Was meint Ihr, kann man das so stehen lassen?
Falk B. schrieb: > Die Funktionen in der libc vom avr gcc arbeiten komplett bytebasierend, > siehe oben! Genau. Marc V. schrieb: > Nein, aus deiner Sicht gibt es keine Pages (als user, meine ich). Und du hast keine Ahnung.
Chris D. schrieb: > Ausnahme: Ältere ARV Controller Generationen. Dort können Daten auch bei > intakter Versorgungsspannung ungewollt an Adresse 0x0000 landen. Das war ein Problem des ATmega103L in der Revision F/G und ist im Errata Sheet beschrieben. Dieser Prozessor in dieser Revision stammt aus den 90 Jahren des letzen Jahrtausend und ist längst durch eine Version ohne diesen Fehler ersetzt worden. Es macht IMHO keinen Sinn, in einer allgemeinen Beschreibung beseitigte Fehler in einzelnen Chips aufzulisten. Die Liste könnte sonst lang werden. MfG Klaus
Danke für den Hinweis, ich hatte nicht angenommen das der Hut so alt ist. Das ging leider nicht aus dem Schrieb hervor.
Mein grosses V. schrieb: > Falk B. schrieb: >> Die Funktionen in der libc vom avr gcc arbeiten komplett bytebasierend, >> siehe oben! > > Genau. Die Funktionen können arbeiten wie die wollen, was die CPU macht, ist eine ganz andere Sache. > Marc V. schrieb: >> Nein, aus deiner Sicht gibt es keine Pages (als user, meine ich). > > Und du hast keine Ahnung. Und wenn ich sagen würde, dass du dumm bist, wäre das ein Kompliment für dich (ich sage es natürlich nicht). Bitte, nicht über etwas reden, wovon du keine Ahnung hast und nicht verstehen kannst.
:
Bearbeitet durch User
Atmel: The ATmega48PA/88PA/168PA/328P contains 256/512/512/1K bytes of data EEPROM memory. It is organized as a separate data space, in which single bytes can be read and written. Die sollten es wissen!
@Chris D. (m8nix) >>Und ist es auch Zufall wenn das Byte richtig geschrieben wird, wenn >>während des Schreibvorgangs, bei intakter Versorgungsspannung, ein Reset >>beliebigen Ursprungs ausgelöst wird, Ja. >>oder ist zumindest dieser Vorgang >>failsafe gestaltet? NEIN! >Ich nehme an das Du damit „Ja im Sinne von failsafe“ gemeint hast? Nein ;-) >Darum hab ich jetzt noch mal etwas recherchiert und folgendes gefunden: > >"If a reset occurs while a write operation is in progress, the write >operation will be completed provided that the power supply voltage is >sufficient."< Ok, aber der Nebensatz ist entscheidend! >1. Das im Datenblatt angegebene EEPROM Schreibzyklen-Limit ist eine >Angabe über die minimale Anzahl an Schreib-/Löschzyklen die >durchgeführt werden können, bevor das EEPROM ableben kann. Ja. > (Danke an M. >Köhler) Eine Garantie dafür, dass das EEPROM aber nicht schon vorher >seinen Dienst versagt, gibt es allerdings nicht. Nein. Nur die Wahrscheinlichkeit ist SEHR gering. >2. Das Schreibzyklen-Limit bezieht sich nur auf EEPROM >Schreib-/Löschzyklen. Lesen beeinträchtigt die EEPROM-Lebensdauer nicht. Ja. >3. Das Schreibzyklen-Limit gilt für jede einzelne Speicherzelle >individuell. Die Anzahl an insgesamt durchgeführten Schreibzyklen auf >unterschiedliche Speicherzellen ist dabei unerheblich. Basierend darauf >kann eine gleichmäßige Datenverteilung über den gesamten EEPROM-Speicher >die EEPROM-Lebensdauer positiv beeinflussen. Ja. >4. Beim Schreiben auf eine degenerierte Speicherzelle können Daten >sofort falsch im EEPROM abgelegt werden, oder verzögert ihre Information >verlieren. Ja. >5. Das EEPE-Bit (EEWE-Bit) wird nach einem Schreibvorgang auch dann vom >Controller zurückgesetzt wenn Daten falsch ins EEPROM eingebrannt >wurden. Ja. >6. Tritt ein Reset während eines EEPROM-Schreibvorgangs ein, wird der >Schreibvorgang korrekt abgeschlossen - Vorausgesetzt die Controller >Versorgungsspannung ist während des Schreibvorgangs innerhalb der >spezifizierten Grenzen! Ja. >Ausnahme: Ältere ARV Controller Generationen. Dort können Daten auch bei >intakter Versorgungsspannung ungewollt an Adresse 0x0000 landen. Ja. >Was meint Ihr, kann man das so stehen lassen? JAAAAAA! Heurekaaaaaaa!! ;-)
Marc V. schrieb: > Und wenn ich sagen würde, dass du dumm bist, wäre das ein Kompliment > für dich (ich sage es natürlich nicht). > Bitte, nicht über etwas reden, wovon du keine Ahnung hast und nicht > verstehen kannst. Carl D. schrieb: > Atmel: > The ATmega48PA/88PA/168PA/328P contains 256/512/512/1K bytes of data > EEPROM memory. It is organized as a separate data space, in which single > bytes can be read and written. Na, wer ist jetzt der Doofe?
Mein grosses V. schrieb: > Carl D. schrieb: >> Atmel: >> The ATmega48PA/88PA/168PA/328P contains 256/512/512/1K bytes of data >> EEPROM memory. It is organized as a separate data space, in which single >> bytes can be read and written. > > Na, wer ist jetzt der Doofe? Du. Es sagt nichts über die Art, wie dieses Byte tatsächlich ins EEPROM geschrieben wird. Ich schreibe jetzt auch ganz langsam, damit du mitkommst, OK ? Es gibt bei AVRs so etwas wie page buffer, das ist sehr nützlich beim schreiben bzw. lesen der Daten. Sowohl beim Lesen als auch beim Schreiben wird zuerst eine ganze Page ins page buffer eingelesen, ein oder mehrere Bytes werden verändert, die Page wird zurückgeschrieben. Für dich (eigentlich nicht für dich, das ist für dich zu kompliziert, aber für normale Benutzer) sieht es so aus, als ob nur ein einziges Byte geschrieben wurde. Wenn es nicht Pageweise wäre, würde sich Atmel page buffer bestimmt sparen. Oder andersrum, bei solch einer Schreibweise spart Atmel an Adressleitungen, 4 Zellen werden auf einmal gelöscht bzw. beschrieben. Atmel sagt nur, dass man einzelne Bytes lesen bzw. schreiben kann - über die Art und Weise wie das geschieht, schweigt er sich aus. Ich hoffe ich könnte etwas Licht ins Dunkel bringen, obwohl ich befürchte, dass es bei dir schon totale Finsternis ist.
Marc V. schrieb: > Und wenn ich sagen würde, dass du dumm bist, wäre das ein Kompliment > für dich (ich sage es natürlich nicht). Marc V. schrieb: > Ich schreibe jetzt auch ganz langsam, damit du mitkommst, OK ? Du kannst mich mal kreuzweise. Marc V. schrieb: > Es gibt bei AVRs so etwas wie page buffer So so "etwas wie..."
Marc V. schrieb: > eigentlich nicht für dich, das ist für dich zu kompliziert, > aber für normale Benutzer Marc V. schrieb: > Ich hoffe ich könnte etwas Licht ins Dunkel bringen, obwohl ich > befürchte, dass es bei dir schon totale Finsternis ist. Muss sowas denn sein? Marc V. schrieb: > Es gibt bei AVRs so etwas wie page buffer, das ist sehr nützlich beim > schreiben bzw. lesen der Daten. > Sowohl beim Lesen als auch beim Schreiben wird zuerst eine ganze Page > ins page buffer eingelesen, ein oder mehrere Bytes werden verändert, > die Page wird zurückgeschrieben. Hast du eine Appnote oder ähnliches wo das beschrieben ist oder wo hast du diese Information her? Würde mich mal interessieren wie das im AVR genau abläuft.
M. K. schrieb: > Hast du eine Appnote oder ähnliches wo das beschrieben ist oder wo hast > du diese Information her? Würde mich mal interessieren wie das im AVR > genau abläuft. Die gibt es nicht. Das mag aber auch daran liegen, dass er nicht kapiert, dass der Pagebuffer für ISP ist, also wenn man das EEPROM mit dem Programmiergerät beschreibt. Darum steht die Pagesize auch nicht unter "EEPROM", sondern unter "Memory programming". Man kann das übrigens recht leicht austesten, was auch einige Leute schon gemacht haben: Einfach eine Zelle immer wieder beschreiben. Irgendwann wird die Zelle ("das Byte") kaputt sein und den Wert nicht mehr behalten. Und dann guckt man halt mal, ob ansonsten noch andere Zellen (die ja angeblich in der Page sind) defekt sind.
> Wie schreibst du denn ein einzelnes Bit ins EEPROM? Wenn die Speicherzelle den Wert FF hat und ich danach ein FE rein Schreibe, habe ich nur ein Bit verändert. Wenn ich danach FC schreibe, habe ich wieder nur ein Bit verändert. Und so weiter. Nach diesem Muster kann ich acht Schreibzugriffe machen, die Verschleißtechnisch aber nur als 1 Zyklus zählen. Denn jedes Bit wurde nur einmal verändert. andere Thema: Wer hier meint, dass EPEPROMS grundsätzliche Byteweise beschrieben werden, der irrt. > Das war doch eigentlich immer das Unterscheidungskriterium zum Flash-Speicher. Nein. IMHO gibt es gar kein eindeutiges Unterscheidungskriterium. Wikipedia nutzt sogar bei der Erklärung des Wortes Flash-Speicher den Begriff "Flash-EEPROM" im ersten Satz! Soweit ich es erlebt habe, werden die Daten bei Flash Speichern in größeren Blöcken gelöscht und beschrieben. Oft mehrere hundert Bytes am Stück. Bei EEPROMS sind die Einheiten kleiner, aber nicht zwangsläufig Bytes. Es gibt auch Eproms, die 2 oder 4 Bytes zusammen fassen. Ich könnte mir auch andere Blockgrößen vorstellen. Größere und kleinere Blöcke sind jedoch keine eindeutigen Begriffe, sie könnten sich überlappen.
> Und dann guckt man halt mal, ob ansonsten noch andere > Zellen (die ja angeblich in der Page sind) defekt sind. Diese Methode wird nicht klappen. Denn Zellen, deren Wert du nicht veränderst, verschleißen auch nicht. Du kannst so oft den selben Wert rein Schreiben, wie du Lust hast. Aktuelle USB Speichersticks speichern mehrere Bits in einer Zelle. Aber beim AVR ist das sicher nicht der Fall.
> Hast du eine Appnote oder ähnliches wo das beschrieben ist oder > wo hast du diese Information her? http://www.gaw.ru/pdf/Atmel/app/avr/AVR105.pdf Laut Appnote AVR105 ist dass EEPROM der AVR Mikrocontroller in einzelnen Bytes organisiert. Das steht da mehrfach im Text. Aber bitte missinterpretiert meine Aussage bitte nicht als generelle Regel. Das gilt nicht grundsätzlich für jedes EEPROM. Da steht übrigens auch, dass das EEPROM und der FLASH Speicher über eine gemeinsamgenutzte Logik beschrieben werden. Das erklärt, warum der Write-Buffer auch beim EEPROM verwendet wird. Sagt aber nichts über dessen Page-Size aus.
Stefan U. schrieb: >> Das war doch eigentlich immer das Unterscheidungskriterium zum > Flash-Speicher. > > Nein. Behaupte doch nicht einfach so etwas. Ich kann mich sehr wohl an die Zeit erinnern, als Flash-Speicher gerade in Mode kamen. Und da war das Unterscheidungskriterium schlechthin die Blockgröße, die am Stück gelöscht/neubeschrieben werden musste. Das lag daran, dass der Schritt zu der gigantischen Integrationsdichte beim Flash-Speicher im Prinzip das Weglassen der Lösch-/Schreibtransistoren für jede Speicherzelle. Hättest du den von dir zitierten Wikipedia-Artikel einfach mal weitergelesen, also nicht so wahnsinnig weit, aber vielleicht nur /einen einzigen/ Satz weiter, dann hättest du das auch dort gefunden: > es lassen sich jedoch im Gegensatz zu gewöhnlichem EEPROM-Speicher bei > neuen Flash-EEPROM Bytes, die kleinsten adressierbaren Speichereinheiten, > nicht einzeln löschen bzw. überschreiben Auch weiter unten wird das nochmal erklärt. Auch, woher der Name "Flash" kommt: Nämlich genau daher, dass die Dinger Blockweise beschrieben werden und nicht Zellenweise, wie konventionelle EEPROMs.
Stefan U. schrieb: > Diese Methode wird nicht klappen. Denn Zellen, deren Wert du nicht > veränderst, verschleißen auch nicht. Du kannst so oft den selben Wert > rein Schreiben, wie du Lust hast. Doch, sie müssen verschleißen, wenn sie, wie behauptet, blockweise beschrieben werden. Selbst wenn ich die Testzelle mit einem laufenden Zähler beschreibe und alle anderen immer mit "0", dann müssten die zum Block der Testzelle gehörenden anderen Zellen jedes Mal mitgelöscht auf "1" und wieder mit "0" neubeschrieben werden. Das war ja genau das Ausgangsproblem.
Ach, jetzt kann man schon einzelne Bits brennen. Wie wärs mal mit Belegen für irgendwas.
batman schrieb: > Ach, jetzt kann man schon einzelne Bits brennen. Wie wärs mal mit > Belegen für irgendwas. Das ist der typische µCNet Meinungsthread - da wird nichts belegt.
Stefan U. schrieb: > Wenn die Speicherzelle den Wert FF hat und ich danach ein FE rein > Schreibe, habe ich nur ein Bit verändert. Wenn ich danach FC schreibe, > habe ich wieder nur ein Bit verändert. Und so weiter. Nach diesem Muster > kann ich acht Schreibzugriffe machen, die Verschleißtechnisch aber nur > als 1 Zyklus zählen. Denn jedes Bit wurde nur einmal verändert. Ja, so kannst du ein Bit ändern aber deine Annahme ist falsch. Das verbraucht auch einen gesamten Schreibzyklus bei Atmega. Bei den Atmegas wird immer Byte-Weise das EEPROM beschrieben. Also selbst wenn im EEPROM 0xFF drin steht und du machst ein write(0xff) verbraucht das einen Zyklus. Genau deshalb gibt es in der avr/eeprom.h auch die Funktion eeprom_update_x(adrr, value) (x = float, byte oder word). Damit wird nämlich zunächst geprüft ob der Wert value, den man ins EEPROM schreiben will, nicht schon im EEPROM steht an der Adresse adrr um eben keinen Schreibzyklus sinnlos zu vergeuden. Stefan U. schrieb: > Wer hier meint, dass EPEPROMS grundsätzliche Byteweise beschrieben > werden, der irrt. Grundsätzlich nicht, beim Atmega aber immer. Beim Atmega wird beim Schreibsignal immer das komplette EEDR ins EEPROM geschrieben. ;) Stefan U. schrieb: > Diese Methode wird nicht klappen. Denn Zellen, deren Wert du nicht > veränderst, verschleißen auch nicht. Du kannst so oft den selben Wert > rein Schreiben, wie du Lust hast. Wie schon gesagt, das ist falsch. Auch wenn du den selben Wert in die Zelle schreibst verbraucht das einen Schreibzyklus. Das sind jetzt aber eigentlich auch Grundlagen EEPROMs. Der Schreibvorgang ist ein teilweise zerstörerischer Vorgang der unabhängig vom Inhalt der Speicherzelle ist. EDIT: Übrigens, auch ein Löschvorgang verbraucht einen Zyklus und das ist beim Atmega etwas spannend: Standardmäßig sind die Programmer/IDEs/Makefiles so eingestellt, dass das Device beim Beschreiben des µCs gelöscht werden sollen…inclusive EEPROM. In der Regel also verbaucht man schon mit dem ersten Programmieren des µCs beim Atmega den ersten Schreibzyklus des EEPROMs ;)
:
Bearbeitet durch User
..was uns nun zur Fuse EESAVE führt, mit welcher man die Jungfräulichkeit des EEPROM bewahren kann.. also quasi ein Keuschheitsgürtel :-)
batman schrieb: > ..was uns nun zur Fuse EESAVE führt, mit welcher man die > Jungfräulichkeit des EEPROM bewahren kann.. also quasi ein > Keuschheitsgürtel :-) Richtig, muss man aber vor der ersten Programmübertragung einschalten, default ist das nämlich aus. Deswegen benutzte ich ja das Wort "Standardmäßig" ;)
>> Diese Methode wird nicht klappen. Denn Zellen, deren Wert du nicht >> veränderst, verschleißen auch nicht. Du kannst so oft den selben Wert >> rein Schreiben, wie du Lust hast. > Doch, sie müssen verschleißen, wenn sie, wie behauptet, > blockweise beschrieben werden. Aber sie werden doch eben nicht Blockweise beschrieben. Jedenfalls nicht beim AVR. > Ach, jetzt kann man schon einzelne Bits brennen. Wie wärs mal > mit Belegen für irgendwas. Hab ich bereits erklärt. Erst in Worten und dann nochmal mit konkreten Beispiel-Werten (Bytes, die nur ein Bit ändern). Ich vertraue meiner ehemaligen Berufschule und deren Lehrbücher. Ich brauche keinen Beweis. Abgesehen davon ist dieses Detail ungefähr so wichtig, als ob in China ein Sack Reis umfallen würde. Aber über solche Nichtigkeiten diskutieren wir hier ja alle bevorzugt, bis zur Ermüdung. Das Gleiche passiert bei diesen Worten: "LED parallel", "Akku auffrischen", "Welcher Mikrocontroller ist besser", "Arduino", "8 versus 32bit", "KFZ umbauen", und so weiter. Ich habe gestern in einem Anfall geistiger Umnachtung dieses LED Thema (anderer Thread) angefangen. Immerhin sind diese Diskussionen viel interessanter, als das TV Programm. Ich liebe es :-) > Auch wenn du den selben Wert in die > Zelle schreibst verbraucht das einen Schreibzyklus. > Der Schreibvorgang ist ein teilweise zerstörerischer > Vorgang der unabhängig vom Inhalt der Speicherzelle ist. Warum? Kann man das irgendwo nachlesen? Oder hast du das jetzt einfach so aus dem Bauch heraus behauptet?
Stefan U. schrieb: > Aber sie werden doch eben nicht Blockweise beschrieben. Jedenfalls nicht > beim AVR. Ich habe das ja auch nicht behauptet. Das mit dem "bitweise Brennen" konnte man doch bei alten EPROMs schon ausprobieren. Mit dem UV-Löschgerät hat man das EPROM mit "1" gefüllt. Mit dem Prommer konnte man dann z.B. aus einem "FF" ein "FE" machen, indem man eine "1" abgebrannt hat. Daraus konnte man ein "FC" machen, indem man noch eine 1 abgegrannt hat und so weiter. Nur zurück ging es nur am Stück mit dem Löschgerät.
So läuft das auch mit dem Flash des AVR. Der Chip-Erase setzt die ganze Bank auf 1, danach kann und muß man nur Nullen schreiben. Beim EEPROM gilt das aber nicht, wie o.g. Atmel-Doku sagt.
Stefan U. schrieb: > Warum? Kann man das irgendwo nachlesen? Oder hast du das jetzt einfach > so aus dem Bauch heraus behauptet? Was, so denkst du, verschleißt denn? Ich hab den Eindruck, dass du gar nicht weißt wie ein EEPROM auf Hardwareebene funktioniert. Kurze Erklärung: Eine Speicherzelle besteht aus einem MOSFET der zum "normalen Gate" (das heißt hier üblicherweise Control-Gate) noch ein vergrabenes Gate, das sogenannte Floating Gate, hat. Das sitzt zwischen Control-Gate und dem Kanal. Ob jetzt eine 1 oder 0 in der Speicherzelle steht ist abhängig davon wieviel Ladungsträger auf dem Floating Gate sind. Für eine logische 1 muss das Floating Gate leer sein, für eine logische 0 muss das Floating Gate geladen sein. Egal, das Beschreiben erfolgt mit einer vergleichsweisen sehr hohen Spannung da man ja Ladungsträger durch die Isolationsschicht vom Kanal auf das Floating Gate bringen muss oder vom Floating Gate holen muss. Source ist typischer Weise dabei auf GND, Drain auf der Schreibspannung und das Control-Gate ist entweder auf der Schreibspannung oder auf GND (je nachdem welchen Wert das Floating Gate annehmen soll). Bei dieser Aktion wird zum einem die Isolationsschicht gestresst aber, vor allem, der Kanal des Speicher-Mosfets. Und der ist das, was verschleißt. Hierbei ist es völlig egal ob ich jetzt Ladungsträger auf das Floating Gate schaufel oder davon runter hole oder gar nix am Floating gate ändere, der Stress für den Kanal ist immer der Gleiche.
Falk B. schrieb: > 3. Das Schreibzyklen-Limit gilt für jede einzelne Speicherzelle >>individuell. Die Anzahl an insgesamt durchgeführten Schreibzyklen auf >>unterschiedliche Speicherzellen ist dabei unerheblich. Basierend darauf >>kann eine gleichmäßige Datenverteilung über den gesamten EEPROM-Speicher >>die EEPROM-Lebensdauer positiv beeinflussen. > > Ja. Nase schrieb: >> Hast du eine Appnote oder ähnliches wo das beschrieben ist oder wo hast >> du diese Information her? Würde mich mal interessieren wie das im AVR >> genau abläuft. > Die gibt es nicht. > Das mag aber auch daran liegen, dass er nicht kapiert, dass der > Pagebuffer für ISP ist, also wenn man das EEPROM mit dem > Programmiergerät beschreibt. Darum steht die Pagesize auch nicht unter > "EEPROM", sondern unter "Memory programming". Wie gesagt, ISP sendet Befehle und diese werden von der CPU ausgeführt. Warum das bei ISP anders ausgeführt werden soll als bei direkten CPU Befehlen aus dem Flash, ist mir unklar. Auch ATMEL hat das bestätigt:
1 | Details:
|
2 | |
3 | I would like to request the addition of the EEPROM Page Size |
4 | value to the header files, for the parts that have EEPROM. |
5 | .
|
6 | .
|
7 | .
|
8 | The reason for such a request is that if you need to save data in |
9 | the internal EEPROM, beyond the stated endurance for a byte, |
10 | listed in the data sheet as |
11 | 'EEPROM (Endurance: 100,000 Write/Erase Cycles)', you need to |
12 | know how far to spread the bytes so that you can archive higher |
13 | endurance figures. For example if you need a byte, but for |
14 | 200,000 cycles you need to use two pages, or 16 bytes in the |
15 | CAN64 part. |
16 | |
17 | "The factory has confirmed, via my FAE, that the listed Endurance
|
18 | "figures are on a page bases, and not a byte bases." |
Somit ist für mich die Diskussion wer was kapiert beendet.
Naja sorry, Schnipsel von unbekannten Quellen zusammenkopiert, können sich teilweise auf den Flash oder anderes beziehen oder schlicht ein Gerücht sein. Oder existiert irgendwo eine Pagesize-Angabe von Atmel (abweichend von 1 Byte)?
Marc V. schrieb: > Wie gesagt, ISP sendet Befehle und diese werden von der CPU ausgeführt. > Warum das bei ISP anders ausgeführt werden soll als bei direkten CPU > Befehlen aus dem Flash, ist mir unklar. Ich schätze mal weil man bei Befehlen aus dem Flash das EEPROM mit Daten aus dem RAM der CPU füttert während man bei Programmieren das EEPROM mit Daten aus dem ISP füttert. Auch wird in den Datenblättern nur bei der Programmierung des µCs von einer Page-weisen Programmierung gesprochen wird, beim Zugriff des µC-Programms auf das EEPROM wird von einer Page-weisen Vorgehensweise nicht gesprochen. Da heißt es nur dass, bei setzen der entsprechenden Bits, die Daten aus dem EEDR ins EEPROM geschrieben werden an die Adresse EEAR.
M. K. schrieb: > Ich schätze mal weil man bei Befehlen aus dem Flash das EEPROM mit Daten > aus dem RAM der CPU füttert während man bei Programmieren das EEPROM mit > Daten aus dem ISP füttert. Nö, irgendwie reimt sich das nicht. > Auch wird in den Datenblättern nur bei der Programmierung des µCs von > einer Page-weisen Programmierung gesprochen wird, beim Zugriff des > µC-Programms auf das EEPROM wird von einer Page-weisen Vorgehensweise > nicht gesprochen. Da heißt es nur dass, bei setzen der entsprechenden > Bits, die Daten aus dem EEDR ins EEPROM geschrieben werden an die > Adresse EEAR. Nase schrieb: > Man kann das übrigens recht leicht austesten, was auch einige Leute > schon gemacht haben: Einfach eine Zelle immer wieder beschreiben. > Irgendwann wird die Zelle ("das Byte") kaputt sein und den Wert nicht > mehr behalten. Und dann guckt man halt mal, ob ansonsten noch andere > Zellen (die ja angeblich in der Page sind) defekt sind. Erstens ist das gar nicht so einfach, weil eine kaputte EEP-Zelle diesen neuen Wert vielleicht 2 Stunden, vielleicht 2 Tage, vielleicht 2 Wochen behält, aber eine Prüfung gleich nach einschreiben wäre auf jeden Fall sinnlos. Eine Zelle explodiert nicht nach 100000 Mal sondern kann den neuen Wert nicht die garantierte Zeit behalten - laut ATMEL sind es mindestens 20 Jahre. Ich habe es früher mal ausprobiert, lesen gleich nach dem schreiben hat auch nach 1500000 Mal funktioniert. Da hab ich aufgehört und da ich internen EEPROM sowieso nur zur Speicherung der Daten die sich relativ selten ändern benutze, war dieses Thema für mich auch nicht mehr weiter interessant. TINY und MEGA AVRs haben zwischen 128 und 2K EEP, was ja für irgendeine Art von ernsthaftem datalogging ungenügend ist. Und ob sich meine Systemkonfiguration, Netzkonfiguration (oder was auch immer da drin geschrieben wird) 100000 Mal ändern wird - nein, bestimmt nicht. Die alten AT90xxxx hatten (bei mir) manchmal Probleme mit EEP-Adresse 0x00, seitdem benutze ich EEPEOM erst ab Adresse 0x10. Und vertraue ATMEL bezüglich des EEPROM nicht mehr so ganz...
Marc V. schrieb: > Da hab ich aufgehört und da ich internen EEPROM sowieso nur zur > Speicherung der Daten die sich relativ selten ändern benutze, war > dieses Thema für mich auch nicht mehr weiter interessant. Na dafür ist der EEPROM ja auch. Marc V. schrieb: > TINY und MEGA AVRs haben zwischen 128 und 2K EEP, was ja für irgendeine > Art von ernsthaftem datalogging ungenügend ist. Wie gesagt, dafür war das EEPROM auch nie gedacht. Kann man zwar machen, muss man aber nicht.
Marc V. schrieb: > jeden Fall sinnlos. Eine Zelle explodiert nicht nach 100000 Mal sondern > kann den neuen Wert nicht die garantierte Zeit behalten - laut ATMEL > sind es mindestens 20 Jahre. Die Retention wird, zumindest lt. Wiki, durch den Schreibvorgang nicht gemindert, sondern die Beschreibbarkeit. Von daher wäre die Zählung der erfolgreichen Testzyklen schon aussagekräftig.
Ich habe nun die Antwort von Atmel direkt. Atmel bestätigt, dass der Zugriff per Software (also EECR/EEDR) byteweise erfolgt und auch nur die beschriebene Speicherstelle altert. Auf meine explizite Frage antwortet Atmel auch explizit, dass die anderen Bytes in der Page dabei nicht altern. Wer möchte, kann sich die Antwort in der Knowledge Base durchlesen.
M. K. schrieb: > Stefan U. schrieb: >> Warum? Kann man das irgendwo nachlesen? Oder hast du das jetzt einfach >> so aus dem Bauch heraus behauptet? > Was, so denkst du, verschleißt denn? Ich hab den Eindruck, dass du gar > nicht weißt wie ein EEPROM auf Hardwareebene funktioniert. > Kurze Erklärung: Eine Speicherzelle besteht aus einem MOSFET der zum > "normalen Gate" (das heißt hier üblicherweise Control-Gate) noch ein > vergrabenes Gate, das sogenannte Floating Gate, hat. Das sitzt zwischen > Control-Gate und dem Kanal. Ob jetzt eine 1 oder 0 in der Speicherzelle > steht ist abhängig davon wieviel Ladungsträger auf dem Floating Gate > sind. Für eine logische 1 muss das Floating Gate leer sein, für eine > logische 0 muss das Floating Gate geladen sein. Egal, das Beschreiben > erfolgt mit einer vergleichsweisen sehr hohen Spannung da man ja > Ladungsträger durch die Isolationsschicht vom Kanal auf das Floating > Gate bringen muss oder vom Floating Gate holen muss. Source ist > typischer Weise dabei auf GND, Drain auf der Schreibspannung und das > Control-Gate ist entweder auf der Schreibspannung oder auf GND (je > nachdem welchen Wert das Floating Gate annehmen soll). Bei dieser Aktion > wird zum einem die Isolationsschicht gestresst aber, vor allem, der > Kanal des Speicher-Mosfets. Und der ist das, was verschleißt. Hierbei > ist es völlig egal ob ich jetzt Ladungsträger auf das Floating Gate > schaufel oder davon runter hole oder gar nix am Floating gate ändere, > der Stress für den Kanal ist immer der Gleiche. Eine wirklich ausführliche und interessante Erklärung,, M.K. Danke. Ich möchte dann aber doch mal nachfragen, was eigentlich physikalisch den "Stress" bewirkt. Ich könnte auch suchen, aber vielleicht bist Du so nett. (Falls nicht, halte ich Dich aber nicht für un-nett). Nach meinem (bruchstückhaften) Wissen werden dann bei gegensätzlicher Ladung von Floating Gate und Control-Gate Ladungen von ersterem abgezogen bzw. dahin übertragen. Im Halbleiter also Loch- bzw. Elektronenwanderung. Das bewirkt stastisch gesehen (wieder unter Vorbehalt meiner lückenhaften Kenntnisse) eine Verteilung der Atome, so daß die Grenzen zwischen den Strukturteilen Gate, Kanal etc. "unscharf" werden und die Funktion damit beeinträchtigt. Das ist so weil die Elektronen- bzw. Lochwanderung auch Bruchteile der Energie auf das Atom überträgt und damit die Schwingungen des Atoms verstärkt, wobei die Energie letztlich als Bewegungs- und Wärmeenergie wirkt. Ist das so richtig? Falls das so ist, dann ist der Einwand von Stefan U. - auch wenn es ihm an der Begründung mangelt - doch nicht ganz falsch; eher relativ falsch, oder?. Es folgt doch aus dem oben gesagten, dass die "Stärke" des Stresses von dem Potentialunterschied zwischen Control- und Floating-Gate abhängt. Zwar werden aus dem letzteren zwischen zwei Schreibvorgängen immer ein paar Elektronen verschwunden oder dahin gewandert sein, - der Stress tritt also grundsätzlich auf -, aber wenn z.B. die selbe Information geschrieben wird, dann ist doch der Stress geringer, oder? Die Hauptfrage ist allerdings wirklich für mich an dieser Stelle, was physikalisch den Stresse beim Elektronentransport ausmacht. Ein Link würde auch hinreichen, falls Du lieber nicht ausführlich antworten willst.
Spielt das in der Praxis überhaupt ne Rolle, wenn jedes EE-Byte vor dem
Schreiben normalerweise gelöscht wird ("erase/write operation")? Es
werden doch also generell beim Schreibzugriff Bits gekippt und damit
verschleißt das Byte, unabhängig von altem und neuem Bytewert, von
Spezialfällen 00, FF mal abgesehen?
batman schrieb: > Spielt das in der Praxis überhaupt ne Rolle, wenn jedes EE-Byte vor dem > Schreiben normalerweise gelöscht wird ("erase/write operation")? Es > werden doch also generell beim Schreibzugriff Bits gekippt und damit > verschleißt das Byte, unabhängig von altem und neuem Bytewert, von > Spezialfällen 00, FF mal abgesehen? Deswegen gibt es die eeprom_update_...() Funktionen. Die schreiben nur die geänderten Bytes. Auch wenn 2 oder mehr Bytes an eine der "Multibyte"-Eeprom-Update-Funktion gegeben werden, wird Byteweise verglichen und ggf. geschrieben. Was anderes kann ein AVR ja auch nicht.
Nase schrieb: > Wer möchte, kann sich die Antwort in der Knowledge Base durchlesen. Ich möchte, nur wo genau bitte (Titel) ?
.. was mich zu der Frage bringt, ob jemand mal in den Atmel Datenblättern mal was über die 'Fuse Endurance' gelesen hat. Also, wie oft kann man die Fusebytes zuverlässig ohne Werteverlust ändern?
Matthias S. schrieb: > .. was mich zu der Frage bringt, ob jemand mal in den Atmel > Datenblättern mal was über die 'Fuse Endurance' gelesen hat. Also, wie > oft kann man die Fusebytes zuverlässig ohne Werteverlust ändern? Ich weiß nicht mehr wo aber ich hab gelesen/gehört dass die Fuse Bits EEPROM-Zellen sind, also 100.000 Zyklen aushalten. Lurchi schrieb: > Ich möchte dann aber doch mal nachfragen, was eigentlich physikalisch > den "Stress" bewirkt. Ich könnte auch suchen, aber vielleicht bist Du so > nett. (Falls nicht, halte ich Dich aber nicht für un-nett). Vor allem handelt es sich hierbei um thermischen Stress. Man will es ja so fix wie möglich machen und das geht über (vergleichsweise) hohe Spannungen/Ströme. U.a. geht man an die Grenze von Durchschlagsfestigkeit und Co, das Material wird u.a. warm und es verschieben sich Dotiergrenzen und ähnliches. Wie es genau ist müsste ich auch wieder nachlesen, mein Studium ist schon ein paar Tage her.
M. K. schrieb: [...] > Lurchi schrieb: [...] > Vor allem handelt es sich hierbei um thermischen Stress. Man will es ja > so fix wie möglich machen und das geht über (vergleichsweise) hohe > Spannungen/Ströme. U.a. geht man an die Grenze von > Durchschlagsfestigkeit und Co, das Material wird u.a. warm und es > verschieben sich Dotiergrenzen und ähnliches. Wie es genau ist müsste > ich auch wieder nachlesen, mein Studium ist schon ein paar Tage her. Dankeschön für die Antwort, M.K. Es ist doch ein wichtiges Detail, dass man wegen der Geschwindigkeit an die Belastungsgrenzen geht. Wie auch immer: Ich lese dann auch mal nach.
Nase schrieb: > Wer möchte, kann sich die Antwort in der Knowledge Base durchlesen. Zum zweiten Mal: Ich möchte, nur wo genau bitte (Titel) ?
Na das ist ja super. Erst bricht der große Shitstorm über meine "Behauptung" aus und dann bestätigt Atmel diese.
Vielleicht das hier? http://atmel.force.com/support/articles/en_US/FAQ/What-is-Endurance-of-EEPROM?q=eeprom&l=en_US&c=Product%3AAVR_8_and_32_bit_MCUs&fs=Search&pn=1
Falk B. schrieb: > Vielleicht das hier? > > http://atmel.force.com/support/articles/en_US/FAQ/What-is-Endurance-of-EEPROM?q=eeprom&l=en_US&c=Product%3AAVR_8_and_32_bit_MCUs&fs=Search&pn=1 Hm. Lustig. Oder war das nicht lustig gemeint? Wohl eher sowas: http://isbn-nr.net/3-540-21384-8_halbleiter-bauelemente_%28springer-lehrbuch%29.htm
Marc V. schrieb: > Nase schrieb: >> Wer möchte, kann sich die Antwort in der Knowledge Base durchlesen. > > Zum zweiten Mal: > Ich möchte, nur wo genau bitte (Titel) ? Du musst dich bei Atmel einloggen (Support --> Knowledge Base). Dort gibt es einen Case zum Thema "EEPROM endurance vs. page size". Ich habe aber keine Ahnung, ob die Support Cases öffentlich einsehbar sind und/oder automatisch in den FAQ landen oder nicht. Stefan U. schrieb: > Na das ist ja super. Erst bricht der große Shitstorm über meine > "Behauptung" aus und dann bestätigt Atmel diese. Das ist hier doch normal.
Nase schrieb: >> Zum zweiten Mal: >> Ich möchte, nur wo genau bitte (Titel) ? > Du musst dich bei Atmel einloggen (Support --> Knowledge Base). > Dort gibt es einen Case zum Thema "EEPROM endurance vs. page size". Habe ich, nix da. Nase schrieb: > Auf meine explizite Frage antwortet Atmel auch explizit, dass die > anderen Bytes in der Page dabei nicht altern. Na, du must aber wissen, wo deine explizite Frage und die explizite Antwort von Atmel gelandet sind, oder ? Ich nehme an, es war nicht im Telefongespräch, gibt es emails ?
@ Stefan U. Nach dem ich mal einige Beiträge von Dir gelesen hatte, würde ich nicht mal eine Auskunft über die Uhrzeit von Dir unhinterfragt hinnehmen. Wenn Du den Text von Atmel mal lesen würdest, würdest Du auch erkennen, dass es sich hier fraglos um ein "Executive Summary" handelt, dass leicht erkennbare logische Widersprüche enthält, die für einen Techniker relevant bleiben, mindestens aber enthält es unvollständige Angaben. Zu folgern ist aber daraus, dass es Bruchteile von "Endurance-Cycles", wie Atmel sie publiziert, gibt, wenn man sich auf Bytes bezieht. Es wird lediglich ein "Executive-Way-To-Count" beschrieben. Kein technischer Zusammenhang im engeren Sinn. Deiner "Behauptung" mangelt die technische Begründung und sie ist nachweislich falsch. Das Du damit einen Shitstorm, wie Du es nennst, auslöst ist verständlich, wenn auch sinnlos. Deine Beiträge lese ich in der Regel nicht mal und nehme sie nur zur Kenntnis, falls jemand daraus zitiert.
> Deiner "Behauptung" mangelt die technische Begründung und > sie ist nachweislich falsch. Ich habe es so in der Ausbildung gelernt, und das war zu einer Zeit, als eine Ausbildung auch wirklich noch etwas Wert war. Außerdem hat Atmel meine Aussage in einer Email bestätigt, in eine Application Note geschrieben und in die FAQ geschrieben. Aber ich bin für neues offen. Weise nach, dass die Information falsch ist! > Ich möchte dann aber doch mal nachfragen, was eigentlich > physikalisch den "Stress" bewirkt. Ich könnte auch suchen, > aber vielleicht bist Du so nett. (Falls nicht, halte ich > Dich aber nicht für un-nett). Das ist ein bisschen mager, findest du nicht? Bist du nun Experte auf diesem Gebiet oder nicht? Wenn nicht, dann würde ich andere, die etwas dazu zu sagen haben, nicht so hart ins Gericht nehmen. Ich war da ja nicht der Einzige betroffene.
> Welche deiner Behauptungen war denn nun die richtige?
Das findest du heraus, indem du diesen Thread liest. Interessiert es
dich wirklich, oder bist du der Lurchi?
Nein ich bin der batman und es war doch keine so schlimme Frage, dachte ich. Ok, also Ratespiel. War es die hier? Stefan U. schrieb: > eine Page (also 4 Bytes)
Marc V. schrieb: > Nase schrieb: >> Auf meine explizite Frage antwortet Atmel auch explizit, dass die >> anderen Bytes in der Page dabei nicht altern. > > Na, du must aber wissen, wo deine explizite Frage und die explizite > Antwort von Atmel gelandet sind, oder ? > Ich nehme an, es war nicht im Telefongespräch, gibt es emails ? EDIT geht nicht mehr, also: Deine explizite Frage und die explizite Antwort von Atmel habe ich zwar nicht gefunden, aber, um Fair zu bleiben, ich habe folgendes gefunden:
1 | Question
|
2 | Which is more stressfull when storing data is an SEEPROM, byte writing or page writing? |
3 | |
4 | Answer
|
5 | Atmel SEEPROMs are byte writeable. Meaning you can write one byte on a |
6 | page, several bytes on a page, or a whole page. |
7 | When you write one byte, only that byte is stressed on the page. |
8 | When you write several bytes on a page, only those bytes are stressed |
9 | on the page. When you write a whole page, the entire page is stressed. |
Nun, "stress" ist nicht gleichbedeutend mit "wear", aber selbst wenn ich es gelten lasse, kommt ATMEL mit folgender Antwort:
1 | Question
|
2 | What is the definition of "number of write cycles"? |
3 | |
4 | Answer
|
5 | The number of write cycles is the number of times each page within a 2-wire or SPI device |
6 | can be written into. For Serial EEPROMs that support 1 million cycles, this means each and |
7 | every page in the memory array can be written 1 million times in page mode. |
Was den nun ?
1 | "Every Byte" in der ersten Antwort, "Every Page" in der zweiten... |
Wenn ich nun Byteweise schreibe, Pagesize ist z.B. 4 Bytes, soll das heissen, dass ich "4 Million cycles" habe und bei Pagesize = 16 Bytes habe ich "16 Million cycles" ? Glaube ich nicht, ergibt auch keinen Sinn. Deswegen sagte ich, dass ich Atmel nicht mehr glaube.
:
Bearbeitet durch User
Ich fasse zusammen: Die EEprom in AVR Mikrocontrollern werden Byteweise gelöscht und beschrieben. Atmel stellt auch andere EEproms her, die eine größere Pagesize haben. Bei AVR Mikrocontrollern wird der selbe Puffer verwendet, der auch beim Beschreiben des Programmspeichers zum Einsatz kommt. Das bedeutet aber nicht, dass das EEprom ebenso große Pages hat. Eine gelöschte Zelle hat den Wert 1. Verschleißen tut die dünne Isolation zwischen den Floating Gates und dem Source, wenn sie von Elektronen überwunden wird. Als ein Zyklus gilt, wenn die Elektronen einmal hin und einmal wieder zurück geflossen sind. Also ein Wechsel von 1 nach 0 und wieder zurück. Bei der Zählung der Schreibzyklen sind nur die Zellen betroffen, die durch den Löschvorgang von 0 nach 1 wechseln. Danach kann man jedes Bit einzeln von 1 nach 0 ändern. Nach diesen 9 Zugriffen ist das ganze Byte um einen Zyklus gealtert. Die avr C Library kombiniert Schreibzugriffe immer mit Lösch-Vorgängen. Die obige Methode (1x Löschen und dann 8x einzelne Bits wieder mach 0 Ändern) wird von der Library nicht unterstützt.
> Wenn ich nun Byteweise schreibe, Pagesize ist z.B. 4 Bytes, > soll das heissen, dass ich "4 Million cycles" habe und bei > Pagesize = 16 Bytes habe ich "16 Million cycles" ? > Glaube ich nicht, ergibt auch keinen Sinn. Nee, tut es nicht. Du hast da was herein interpretiert, was Atmel ganz sicher nicht so gemeint hat. Bei dem EEprom der AVR Mikrocontroller wird jedes Byte einzeln gelöscht. Die Pagesize ist 1 Byte! Wenn die sagen, dass ein EEprom so und so viele Schreibzyklen verträgt, dann gibt das für jedes Bit. Die Pagesize sagt nur aus, wie viele Bytes gleichzeitig gelöscht werden. Für den Verschleiß ist aber relevant, wie oft die einzelnen Bits von 1 nach 0 und wieder zurück geändert werden. Bei einem (anderen) EEprom mit einer Pagesize von 512 Bits kannst du die ganze Page einmal löschen und dann mit 215 Zugriffen einzelne Bits auf 0 setzen. Diese 513 Zugriffe zählen dann als ein einziger Zyklus. Das ist natürlich ein seltener Sonderfall - ist mir klar. In einer realen Anwendung wird es wohl häufiger vorkommen, dass man eine ganze Page neu schreiben muss, wenn man nur ein einzelnes Byte ändern wollte. Und das ist dann schon lästig. Denn dann erlebt die ganze Page einen Schreibzyklus, um nur ein einziges Byte tatsächlich zu ändern. Da fällt mir übrigens noch ein schöner Sonderfalls ein. Nehmen wir an, das ganze EEprom ist leer (also mit 0xFF Werten) und es hätte nur eine riesige Page von 64 Kilobytes. Ein Datenlogger könnte nach und nach einzelne Bytes hinein schreiben, ohne es zu löschen. Nach 65535 Schreibzugriffen wäre das ganze EEprom erst um einen halben Zyklus gealtert! Aber wie gesagt, bei AVR µC ist die Pagesize 1 Byte.
Stefan U. schrieb: > Als ein Zyklus gilt, wenn die Elektronen einmal hin und einmal wieder > zurück geflossen sind. Also ein Wechsel von 1 nach 0 und wieder zurück. Genauer gesagt: der Wechsel von 0 nach 1 „kostet“, also das Löschen. > Bei der Zählung der Schreibzyklen sind nur die Zellen betroffen, die > durch den Löschvorgang von 0 nach 1 wechseln. Danach kann man jedes Bit > einzeln von 1 nach 0 ändern. Nach diesen 9 Zugriffen ist das ganze Byte > um einen Zyklus gealtert. Mir ist nach dem Lesen des Knowledgebase-Artikels jedoch nicht klar, ob dieses Verhalten tatsächlich bereits durch die Logik im AVR so garantiert wird (sie könnte ja selbstständig feststellen, ob für die Zelle ein Löschvorgang nötig ist oder nicht), oder ob das Programm sicherstellen muss, dass es explizit nur dann ein Löschen der Zelle verlangt, wenn es auch nötig ist. Wenn das nicht durch die Hardware garantiert wird: ja, die Implementierung in der avr-libc ist so aufgebaut, dass sie jedesmal sowohl löscht als auch schreibt. (Bei älteren AVRs konnte man beide Operationen ohnehin nicht trennen.)
> und dann mit 215 Zugriffen einzelne Bits auf 0 setzen
Sorry, das sollte natürlich 512 sein.
> sie könnte ja selbstständig feststellen, ob für die > Zelle ein Löschvorgang nötig ist oder nicht Schön wäre das. Doch was nicht ausdrücklich zugesichert wird, ist wohl tendenziell eher nicht vorhanden. Im Datenblatt des Amega328P steht: "It is possible to program data in one atomic operation (erase the old value and program the new value) or to split the Erase and Write operations in two different operations." Es heisst "erase the old value AND program the new value", nicht OR und es fehlt auch der erhoffte Beisatz "erase the old value if necessary".
Stefan U. schrieb: > Ich fasse zusammen: Lieber nicht. > Die EEprom in AVR Mikrocontrollern werden Byteweise gelöscht und > beschrieben. Atmel stellt auch andere EEproms her, die eine größere > Pagesize haben. Sogar ATMEL sagt so etwas nicht. IN DaBla steht es nur, dass einzelne Bytes gelesen und geschrieben werden können. Wie das im Einzelnen geschieht, wird nicht genau beschrieben oder es wird mal so, mal so erklärt. > Bei AVR Mikrocontrollern wird der selbe Puffer verwendet, der auch beim > Beschreiben des Programmspeichers zum Einsatz kommt. Das bedeutet aber > nicht, dass das EEprom ebenso große Pages hat. Bei einzelnen Bytes besteht keine Notwendigkeit für einen Pagebuffer.
Stefan U. schrieb: >> Wenn ich nun Byteweise schreibe, Pagesize ist z.B. 4 Bytes, >> soll das heissen, dass ich "4 Million cycles" habe und bei >> Pagesize = 16 Bytes habe ich "16 Million cycles" ? >> Glaube ich nicht, ergibt auch keinen Sinn. > > Nee, tut es nicht. Du hast da was herein interpretiert, was Atmel ganz > sicher nicht so gemeint hat. Bei dem EEprom der AVR Mikrocontroller wird > jedes Byte einzeln gelöscht. Die Pagesize ist 1 Byte! Warum schreist du den ? Erst mal DaBla lesen und dann so etwas schreiben. Eeprom Pagesize ist min. 4 Bytes.
Also beim Atmega 5 Bytes und bei den Tiny manchmal nur viereinhalb, sag ich jetzt mal.
Stefan U. schrieb: > Verschleißen tut die dünne Isolation zwischen den Floating Gates und dem > Source, wenn sie von Elektronen überwunden wird. Als ein Zyklus gilt, > wenn die Elektronen einmal hin und einmal wieder zurück geflossen sind. > Also ein Wechsel von 1 nach 0 und wieder zurück. Jörg W. schrieb: > Stefan U. schrieb: >> Als ein Zyklus gilt, wenn die Elektronen einmal hin und einmal wieder >> zurück geflossen sind. Also ein Wechsel von 1 nach 0 und wieder zurück. > > Genauer gesagt: der Wechsel von 0 nach 1 „kostet“, also das Löschen. Beides falsch. Ich zitiere mal den obigen, verlinkten, FAQ >> What is Endurance of EEPROM? >> ... >> 3. When is the endurance of EEPROM reduced by ONE? >> ... >> 3. Writing a "0" to a location regardless if it is "1" or "0" to baring >> with, will 'stress' the cell, reducing the endurance by 1. The endurance of >> a single byte is affected in this case not the endurance of the entire >> EEPROM array. >> ... Also praktisch immer wenn man Elektronen auf die Reise schickt. Das Löschen kostet also keinen Zyklus (Ein Zelle ist gelöscht wenn sie den Wert 0xFF enthält), das war mir so auch nicht bewusst.
In einer detaillierten Application Note von ST habe ich gestern Abend wieder was anderes gelesen. Offensichtlich gibt es unterschiedliche Bauarten von EEProms und die Datenblätter der AVR Mikrocontrolelr lassen einige Details offen.
Stefan U. schrieb: > In einer detaillierten Application Note von ST habe ich gestern > Abend > wieder was anderes gelesen. > > Offensichtlich gibt es unterschiedliche Bauarten von EEProms und die > Datenblätter der AVR Mikrocontrolelr lassen einige Details offen. Ja, das auf jeden Fall. EEPROMs zu beschreiben kann sehr vielfältig sein und jeder Hersteller fährt da eine etwas andere Strategie. In der Regel ist das auch recht wurscht wenn man das EEPROM auch nur dafür benutzen will, wofür es eigentlich gedacht ist: Zum Speichern von Werten die sich zur Laufzeit ggf. ändern können aber idR nicht ändern werden.
Marc V. schrieb: > Eeprom Pagesize ist min. 4 Bytes. Das gilt aber nur für die Programmierschnittstelle. M. K. schrieb: >> Genauer gesagt: der Wechsel von 0 nach 1 „kostet“, also das Löschen. > > Beides falsch. Ich zitiere mal den obigen, verlinkten, FAQ Meine Bemerkung wiederum basiert auf dem, was ich von den IC-Entwicklern gehört habe … Am Ende bleibt es sich ziemlich gleich. Eine „volle Runde“ (Schreiben nach 0 und Löschen nach 1) ist halt ein Zyklus.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Marc V. schrieb: >> Eeprom Pagesize ist min. 4 Bytes. > > Das gilt aber nur für die Programmierschnittstelle. Auch mit ISP kann man einzelne Bytes ins EEPROM schreiben. Muss aber nicht unbedingt heissen, dass die Bytes auch einzeln geschrieben werden. > Am Ende bleibt es sich ziemlich gleich. Eine „volle Runde“ (Schreiben > nach 0 und Löschen nach 1) ist halt ein Zyklus. Whatever. Um das alles zu prüfen, müßte man eine Eeprom-Zelle beschreiben, nach 20 Jahren dessen Inhalt mit reingeschriebenem Wert vergleichen, neuen Wert reinschreiben, 20 Jahre warten, vergleichen... Und nach 2 Millionen Jahren wüßte man es dann ganz genau. ATMEL weiß, dass deren Behauptung (20 Jahre) einfach nicht zu widerlegen ist und deswegen ist es auch egal, ob Byte oder Page. Was mich aber unheimlich nervt, ist dieses blinde vertrauen auf Hersteller und deren Aussagen. Wie war das noch mit Volkswagen und Abgasaffäre ?
Marc V. schrieb: > ATMEL weiß, dass deren Behauptung (20 Jahre) einfach nicht zu > widerlegen ist und deswegen ist es auch egal, ob Byte oder Page. Im Gegensatz zu dir machen sie aber interne Stresstests, genannt HTOL. Ein bisschen was findest du im Netz dazu.
Jörg W. schrieb: > Marc V. schrieb: >> ATMEL weiß, dass deren Behauptung (20 Jahre) einfach nicht zu >> widerlegen ist und deswegen ist es auch egal, ob Byte oder Page. > > Im Gegensatz zu dir machen sie aber interne Stresstests, genannt > HTOL. Ein bisschen was findest du im Netz dazu. Was soll das denn heißen? Auch im Gegensatz zu dir - oder machst du etwa Stresstests ? HTOL sagt aber absolut nichts darüber wie lange die Daten erhalten bleiben. Es ermöglicht nur eine ungefähre Voraussage auf das Verhalten und Zuverlässigkeit der Chips im Normalbetrieb. HTOL läuft auf 125C oder mehr, bei max. VCC und das ist aber auch schon alles. Bleibt schön innerhalb der ATMEL Spezifikationen. Wie gesagt, VW hat auch EPA Anforderungen erfüllt - auf Prüfstand.
Jörg W. schrieb: > Meine Bemerkung wiederum basiert auf dem, was ich von den IC-Entwicklern > gehört habe … Von welchen Entwicklern? Hier gings um die EEPROMs in den AVRs und darauf beziehe ich mich. Bei anderen EEPROMs kann es anders aussehen. Jörg W. schrieb: > Am Ende bleibt es sich ziemlich gleich. Eine „volle Runde“ (Schreiben > nach 0 und Löschen nach 1) ist halt ein Zyklus. Wie gesagt, bei den AVRs nicht. Da verbraucht "nur" das Schreiben einer 0 einen Zyklus, das Schreiben einer 1 verbraucht keinen Zyklus, unabhängig vom Wert der in der Zelle steht (siehe auch oben zitierten Atmel AVR FAQ). Marc V. schrieb: > Um das alles zu prüfen, müßte man eine Eeprom-Zelle beschreiben, > nach 20 Jahren dessen Inhalt mit reingeschriebenem Wert vergleichen, > neuen Wert reinschreiben, 20 Jahre warten, vergleichen... Warum willst du denn 20 Jahre warten? Hier gings doch darum wie oft man ne Zelle beschreiben kann, nicht wie lange sie ihren Wert hielt. Und das kann man auch in kürzerer Zeit testen, da braucht man keine 2 Millionen Jahre für. Mal ganz abgesehen davon: Es gibt auch "Klimaschränke" mit denen man eine künstliche Alterung durchführen kann. ;) Marc V. schrieb: > Wie gesagt, VW hat auch EPA Anforderungen erfüllt - auf Prüfstand. Und welche Alternative hast du dazu? Nach deiner bisherigen Aussage bleibt dir eigentlich nix anderes übrig als den Herstellerangaben zu vertrauen da du sie nicht überprüfen kannst. Ist also schon etwas anders als bei VW und Co, da konnte man wenigstens gegenprüfen.
:
Bearbeitet durch User
M. K. schrieb: > Von welchen Entwicklern? Hier gings um die EEPROMs in den AVRs und > darauf beziehe ich mich. Ich mich auch. ;-) > Wie gesagt, bei den AVRs nicht. Da verbraucht "nur" das Schreiben einer > 0 einen Zyklus, das Schreiben einer 1 verbraucht keinen Zyklus, > unabhängig vom Wert der in der Zelle steht (siehe auch oben zitierten > Atmel AVR FAQ). Nein, ein „Zyklus“ ist halt ein kompletter Kreis. Daher der Name. Ist auch müßig, sich über halbe Zyklen streiten zu wollen, wenn man von 100000en redet …
Jörg W. schrieb: > Nein, ein „Zyklus“ ist halt ein kompletter Kreis. Daher der Name. Hier bitte noch mal lesen, Punkt 3: http://atmel.force.com/support/articles/en_US/FAQ/What-is-Endurance-of-EEPROM?q=eeprom&l=en_US&c=Product%3AAVR_8_and_32_bit_MCUs&fs=Search&pn=1 Ist das jetzt wirklich so schwer? Da steht eindeutig, dass nur das Schreiben einer 0 einen Zyklus verbraucht. Unter Punkt 5 steht noch mal explizit dass das Schreiben von 0xFF, also alle 8 Bits auf 1 setzen, die Haltbarkeit nicht beeinflusst.
M. K. schrieb: > Marc V. schrieb: >> Um das alles zu prüfen, müßte man eine Eeprom-Zelle beschreiben, >> nach 20 Jahren dessen Inhalt mit reingeschriebenem Wert vergleichen, >> neuen Wert reinschreiben, 20 Jahre warten, vergleichen... > > Warum willst du denn 20 Jahre warten? Hier gings doch darum wie oft man > ne Zelle beschreiben kann, nicht wie lange sie ihren Wert hielt. Und das > kann man auch in kürzerer Zeit testen, da braucht man keine 2 Millionen > Jahre für. Nicht ganz. Mittlerweile habe ich die alte Mega rausgeholt, nach 2,5 Millionen Schreib- und Lesezyklen geht es immer noch. Ob dieser Wert aber nach 2 Wochen oder 20 Jahren immer noch dasselbe ist ? Wie gesagt, 100000 Mal werde ich wohl kaum eine Zelle beschreiben, aber erwarten, dass diese Zelle ihren Wert auch nach 1 oder 2 Jahren behält, ganz sicher. > Mal ganz abgesehen davon: Es gibt auch "Klimaschränke" mit denen man > eine künstliche Alterung durchführen kann. ;) Selbst danach nur Voraussagen und nur ungefähr. > Marc V. schrieb: >> Wie gesagt, VW hat auch EPA Anforderungen erfüllt - auf Prüfstand. > > Und welche Alternative hast du dazu? Nach deiner bisherigen Aussage > bleibt dir eigentlich nix anderes übrig als den Herstellerangaben zu > vertrauen da du sie nicht überprüfen kannst. Ist also schon etwas anders > als bei VW und Co, da konnte man wenigstens gegenprüfen. Eben. Ich kann es nicht zu Lebzeiten überprüfen, also bleibe ich skeptisch und nehme immer den worstcase Fall um 50% vermindert.
M. K. schrieb: > Da steht eindeutig, dass nur das Schreiben einer 0 einen Zyklus > verbraucht. Ja, und? Wenn du die geschrieben hast, ist er eben von mir aus „verbraucht“ – bis du die Zelle wieder löschst. Weitere Nullen kannst du schließlich nicht auf das gleiche Bit schreiben. Erst nach dem Löschen kann überhaupt ein neuer beginnen. „Zyklus“ bedeutet jedoch (im Sinne des Wortes selbst), dass man damit einen kompletten Umlauf bezeichnet – egal, wie Atmel das nun nennt. Wenn du „bicycle“ sagst, willst du wohl auch keine zwei Halbkreise unterm Hintern haben. :-) Und nochmal: sich um halbe Zyklen zu streiten, ist witzlos.
Naja demnach hat eben jedes einzelne Bit 100000 Zyklen. Es kann 100000 auf 0 gesetzt werden - unabhängig von den anderen Bits.
Marc V. schrieb: > Nicht ganz. > Mittlerweile habe ich die alte Mega rausgeholt, nach 2,5 Millionen > Schreib- und Lesezyklen geht es immer noch. Ob dieser Wert aber nach > 2 Wochen oder 20 Jahren immer noch dasselbe ist ? > Wie gesagt, 100000 Mal werde ich wohl kaum eine Zelle beschreiben, > aber erwarten, dass diese Zelle ihren Wert auch nach 1 oder 2 Jahren > behält, ganz sicher. Na und? Wenn der Hersteller maximal 100000 Zyklen des EEPROM und gleichzeitig eine Retention von 20 Jahren garantiert, ist doch alles klar oder nicht? Warum soll man unbedingt irgendwas anderes glauben, als der Hersteller angibt? Paranoia?
batman schrieb: > Naja demnach hat eben jedes einzelne Bit 100000 Zyklen. Es kann 100000 > auf 0 gesetzt werden - unabhängig von den anderen Bits. Nein, nicht wirklich. Du kannst es nur immer gemeinsam mit 7 anderen wieder auf 1 zurücksetzen, erst danach kann es einen neuen Zyklus für dieses Bit geben. Insofern sind sie eben nicht unabhängig voneinander.
Hmm aber das Setzen der Bits auf 1 bzw. Löschen erhöht doch nicht deren Zyklenzahl? Erst wenn sie auf 0 gesetzt werden.
batman schrieb: > Hmm aber das Setzen der Bits auf 1 bzw. Löschen erhöht doch nicht deren > Zyklenzahl? Du klebst immer noch zu sehr an der wortwörtlichen Formulierung von Atmel fest. Die halte ich eher für unglücklich. Nochmal, das Ding heißt „Zyklus“, weil es ein Kreislauf ist, bestehend aus dem Setzen von Bits auf 0 (individuell für jedes Bit möglich) und dem Löschen auf 1 (immer für 1 Byte zusammen beim EEPROM). Da du kein einzelnes Bit wieder löschen kannst, hat die Angabe der Zyklenzahl nur für komplette Bytes einen Sinn, auch wenn du die Bits (so du das willst) individuell auf 0 setzen kannst. In deiner Sichtweise kannst du also . Bit 0 auf 0 setzen (und hast damit dafür einen Zyklus „verbraucht“), . Bit 1 auf 0 setzen (dafür ein Zyklus „verbraucht“), . … . Bit 7 auf 0 setzen (dafür einer verbraucht) Danach kannst du nur alle diese Bits auf einmal löschen. Erst, wenn du das gemacht hast, kann das Spiel von vorn beginnen. (Hier wäre für mich der Kreis geschlossen, also ein Zyklus „verbraucht“.) Allerdings ist das alles zusammen eben ein Zyklus (für dieses Byte), nicht etwa 8, auch wenn die Bits einzeln auf 0 gesetzt werden dabei.
batman schrieb: > Na und? Wenn der Hersteller maximal 100000 Zyklen des EEPROM und > gleichzeitig eine Retention von 20 Jahren garantiert, ist doch alles > klar oder nicht? Sage ich doch, oder liest du etwas anderes ? > Warum soll man unbedingt irgendwas anderes glauben, als der Hersteller > angibt? Paranoia? Um sicherzugehen. Nur wird es bei einer normaler Anwendung nie passieren, dass man an die Grenzen stößt. Und wenn doch, nimmt man die nächsthöhere Klasse. Wenn ein Transistor Hersteller sagt, dass bei Typ XX Ic 100mA ist, dann kann man das ganz schnell prüfen. Wenn ein Eeprom Hersteller sagt, dass der Eeprom Typ XX 10 Millionen Mal beschreibbar ist und Datenerhaltungszeit von 20 Jahren angibt, wie willst du das prüfen ? Selbst dieser Hersteller hat das nicht geprüft, es sind voraus- sichtliche Werte, weil die Datenerhaltungszeit nach jedem Schreibzyklus neu geprüft werden sollte. Also, es ist schon ein Riesenunterschied zwischen EEPROM und Transistor und was man nicht prüfen kann, soll man auch nicht für bare Münze nehmen. Jörg W. schrieb: > Und nochmal: sich um halbe Zyklen zu streiten, ist witzlos. Genau.
Jörg W. schrieb: > Weitere Nullen kannst > du schließlich nicht auf das gleiche Bit schreiben. Siehst du, und genau das steht da im FAQ anders. Da steht, dass das Schreiben einer 0 immer einen Zyklus verbraucht, egal ob in der Zelle vorher eine 1 oder eine 0 stand. Marc V. schrieb: > Also, es ist schon ein Riesenunterschied zwischen EEPROM und Transistor > und was man nicht prüfen kann, soll man auch nicht für bare Münze > nehmen Und welchen Wert würdest du dann annehmen? So wie du es beschreibst kann niemand einen Speicher prüfen, egal welchen Typs. Aber dafür gibt es Klimaschränke und Co mit denen eine künstliche Alterung simuliert wird. Man kann es also schon prüfen und Atmel hat das sicher auch.
:
Bearbeitet durch User
M. K. schrieb: > Und welchen Wert würdest du dann annehmen? So wie du es beschreibst kann > niemand einen Speicher prüfen, egal welchen Typs. worstcase / 2 > Aber dafür gibt es > Klimaschränke und Co mit denen eine künstliche Alterung simuliert wird. > Man kann es also schon prüfen und Atmel hat das sicher auch. Künstliche Alterung hat herzlich wenig mit Data Retention zu tun. Für Quarze und so ist es anwendbar, aber um eine verlässliche Aussage über Datenerhaltungszeit zu geben, müsste mindestens ein Zyklus in Echtzeit abgelaufen sein - also spätestens 1996 gestartet sein. Und das ist mit Sicherheit nicht der Fall. Nicht das ich glaube, dass Atmel da besonders schlimm dasteht, aber es sind ganz einfach angenommene Werte die von allen Herstellern übernommen werden. Ich kann weder sagen, dass die Werte richtig sind, noch dass die falsch sind, aber die Hersteller können es ganz einfach auch nicht. Deswegen bin ich skeptisch.
Marc V. schrieb: > Ich kann weder sagen, dass die Werte richtig sind, noch dass die falsch > sind, aber die Hersteller können es ganz einfach auch nicht. Ja, und genau da frage ich mich was Marc V. schrieb: > worstcase / 2 der Worst Case denn sein soll. Womit willst du denn rechnen wenn du den Daten der Hersteller nicht trauen kannst.
:
Bearbeitet durch User
M. K. schrieb: > der Worst Case denn sein soll. Womit willst du denn rechnen wenn du den > Daten der Hersteller nicht trauen kannst. Mit 5-8 Jahren ohne Auffrischen, da bin ich auf der sicheren Seite.
@ Marc Vesely (Firma: Vescomp) (logarithmus) >> der Worst Case denn sein soll. Womit willst du denn rechnen wenn du den >> Daten der Hersteller nicht trauen kannst. > Mit 5-8 Jahren ohne Auffrischen, da bin ich auf der sicheren Seite. Aha. Und womit begründest du diese Festlegung? Mit deinem Bauchgefühl. Und das ist NATÜRLICH besser als alle Messungen und theoretischen Überlegungen von vielen Halbleiterspezialisten . . . ;-)
Falk B. schrieb: >> Mit 5-8 Jahren ohne Auffrischen, da bin ich auf der sicheren Seite. > > Aha. Und womit begründest du diese Festlegung? Mit deinem Bauchgefühl. Warum muss ich das begründen ? Ich verkaufe keine EEPROMs, ich benutze die nur. > Und das ist NATÜRLICH besser als alle Messungen und theoretischen > Überlegungen von vielen Halbleiterspezialisten . . . ;-) Und gerade weil entsprechende Messungen nicht existieren, sagt mir mein Bauchgefühl, dass 5-8 Jahre angemessen sind. Reifen an meinem Auto werden auch nicht bis zur gesezlichen Mindestprofiltiefe abgefahren, Bremsbeläge und Oel werden auch früher gewechselt, obwohl dessen Verschleiss messbar ist. Bei EEPROM ist das nicht der Fall und da will ich sicher sein, dass das was ich bei mir oder meinen Kunden eingebaut habe, auch noch nach Jahren funktioniert. So einfach ist das.
Falk B. schrieb: > Beitrag "Re: Elektroauto Tesla Model 3 konkurrenz für 3er BMW und Audi A4" > > ;-) Aha, deswegen führst du keine Selbstgespräche...
@ Marc Vesely (Firma: Vescomp) (logarithmus) > Beitrag "Re: Elektroauto Tesla Model 3 konkurrenz für 3er BMW und Audi A4" > Aha, deswegen führst du keine Selbstgespräche... Schon wieder falsch. Ich führe gern Selbstgespräche. Denn wenigstens einmal am Tag sollte man sich mit einem intelligenten Menschen unterhalten. ;-)
Marc V. schrieb: > Und gerade weil entsprechende Messungen nicht existieren, sagt mir > mein Bauchgefühl, dass 5-8 Jahre angemessen sind. Marc V. schrieb: > Mit 5-8 Jahren ohne Auffrischen, da bin ich auf der sicheren Seite. Also der Worst Case, mit dem du rechnest, liegt im Bereich von 10 - 16 Jahre. Bist du vielleicht auch schon mal auf die Idee gekommen, dass bei Atmel einer saß der sich ähnliches wie du sagte und die 20 Jahre schon "Worst Case / 2" bedeutet? Marc V. schrieb: > Reifen an meinem Auto werden auch nicht bis zur gesezlichen > Mindestprofiltiefe abgefahren, Hm, so unterschiedlich ist die Welt: Ich fahr sogar meine Motorradreifen bis zur gesetzlichen Mindestprofiltiefe runter bevor die gewechselt werden. Wieso auch nicht? Das haben sich Leute überlegt, die davon mehr Ahnung haben als ich. Warum sollte ich das also in Frage stellen. Beim EEPROM ist es ähnlich. Marc V. schrieb: > Und gerade weil entsprechende Messungen nicht existieren, sagt mir > mein Bauchgefühl, dass 5-8 Jahre angemessen sind. Natürlich existieren entsprechende Messungen. Nur weil dir die Techniken zu Alterung nicht gefallen heißt das noch lange nicht, dass es keine Messungen gibt. Klar, kann man sagen in der Realität verhält es sich anders aber mal ehrlich: Du kannst nicht beweisen, dass der EEPROM keine 20 Jahre die Daten halten kann. Damit dürfte niemand von uns ein Problem haben Atmel zu glauben, dass der EEPROM die Daten 20 Jahre halten wird. Und ja, da darf man auch einer künstlichen Alterung zunächst vertrauen bis das Gegenteil bewiesen ist.
Falk B. schrieb: > Ich führe gern Selbstgespräche. Denn wenigstens einmal am Tag sollte man > sich mit einem intelligenten Menschen unterhalten. ;-) Ja, das ist sicher nicht verkehrt :D
Mein Bauchgefühl sagt mir, daß die Daten eher 100 Jahre auf dem EEPROM halten werden. Die letzten 80-90 Jahre davon liegt das Ding eh in kühler Umgebung, Keller oder Müllgrube.
M. K. schrieb: > Klar, kann man sagen in der Realität verhält es sich anders aber mal > ehrlich: Du kannst nicht beweisen, dass der EEPROM keine 20 Jahre die > Daten halten kann. LOL. Ist auch nicht nötig und auch nicht so schlimm. Das Schlimme ist, dass ATMEL seine Behauptung nicht beweisen kann. Das Gute daran ist, dass es zu so einem Fall wahrscheinlich nie kommen wird. batman schrieb: > Mein Bauchgefühl sagt mir, daß die Daten eher 100 Jahre auf dem EEPROM > halten werden. Die letzten 80-90 Jahre davon liegt das Ding eh in kühler > Umgebung, Keller oder Müllgrube. Stimme ich zu (und die Herren von ATMEL haben wahrscheinlich auch so oder ähnlich kalkuliert).
Marc V. schrieb: > Das Schlimme ist, dass ATMEL seine Behauptung nicht beweisen kann. Das Schlimme ist, dass du etwas nicht verstehst: Es gibt anerkannte Verfahren zur künstlichen Alterung mit denen das Verhalten von Bauteilen überprüft werden kann wie sie sich nach 20 Jahren Betrieb verhalten werden. Und damit prüft sicher auch Atmel. Nur weil dir das nicht passt lehnst du dich hier aber ganz schön weit aus dem Fenster.
M. K. schrieb: > Das Schlimme ist, dass du etwas nicht verstehst: Es gibt anerkannte > Verfahren zur künstlichen Alterung mit denen das Verhalten von Bauteilen > überprüft werden kann wie sie sich nach 20 Jahren Betrieb verhalten > werden. Und damit prüft sicher auch Atmel. Warum klammerst du dich an der künstlichen Alterung fest ? Das hat mit Datenerhaltungszeit des EEPROM ungefähr so viel zu tun wie die Tests unter Wasser. Ob ein gewisser Prozent der Chips nach einer bestimmten Zeit ausfallen wird, kann man mit HALT oder HTOL ziemlich genau voraussehen, aber wie lange ein EEPROM die Daten behalten wird, ganz sicher nicht. > Nur weil dir das nicht passt > lehnst du dich hier aber ganz schön weit aus dem Fenster. Und nur weil dir das nicht passt, bleibst du im dunklen Zimmer. Im Endeffekt wird wahrscheinlich keiner von uns an die Grenzen stossen, aber eine Diskussion darüber ist auch nichts verkehrtes. Das hier ist aber keine argumentierte Diskussion, Sätze wie:
1 | ATMEL hat es bestimmt gemacht |
2 | Leute beim ATMEL haben sich bestimmt Gedanken darüber gemacht |
3 | ATMEL hat bestimmt mit diesem und jenem geprüft |
4 | Es gibt Leute beim ATMEL, die wissen das besser als du |
und ähnliche Quasi-Argumente können bei Kindern bis 10 Jahren durchgehen, mir wird es langsam zu dumm, ich bin raus.
Marc V. schrieb: > Ob ein gewisser Prozent der Chips nach einer bestimmten Zeit > ausfallen wird, kann man mit HALT oder HTOL ziemlich genau > voraussehen, aber wie lange ein EEPROM die Daten behalten wird, > ganz sicher nicht. Doch, kann man. Die Mechanismen für den Datenverlust sind bekannt und ähneln denen der Alterung zumindest teilweise. Genauso klar ist, dass durch hohe Temperatur auch diese Mechanismen sehr viel schneller ablaufen. Andernfalls könnte dir kein Hersteller überhaupt irgendwelche Zahlen da garantieren (das machen sie aber mit ihren Datenblattangaben).
Vielleicht von Interesse: Vor Jahren testete ich das EEPROM eines PIC16 F877A zu "Tode". Ein Schreib/Lese Program brachte es bei Raumtemperatur auf ueber 14 Millionen erfolgreiche Schreib Operationen bevor sich Fehler zeigten. Interessant war, dass auch benachbarte unbeschriebene Zellen fehlerhaft wurden. Microchip spezifizierte im Datenblatt eine Million Schreibvorgaenge. Gerhard
Gerhard. schrieb: > Interessant war, dass auch benachbarte unbeschriebene Zellen fehlerhaft > wurden. Ist aber auch ein bekanntes Phänomen.
Marc V. schrieb: > Im Endeffekt wird wahrscheinlich keiner von uns an die Grenzen stossen, Dann ist dein Vorgehen aber, Worst Case / 2, ziemlich sinnlos, findest du nicht? Marc V. schrieb: > Und nur weil dir das nicht passt, bleibst du im dunklen Zimmer. Wie kommst du denn jetzt auf sowas? Marc V. schrieb: > Warum klammerst du dich an der künstlichen Alterung fest ? Weil das anerkannte Verfahren sind. Die Alternative ist ja, wie du schon selbst festgestellt hast, nicht sehr gut umsetzbar. Marc V. schrieb: > Das hat mit Datenerhaltungszeit des EEPROM ungefähr so viel zu tun wie > die Tests unter Wasser. Doch, hat es. Die physikalischen Eigenschaften die zu dem Datenverlust über Zeit beitragen sind hinreichend bekannt und mit künstlicher Alterung sehr gut simulierbar. Oder, ich frag da doch mal anders, was denkst du denn warum der EEPROM die Daten verliert? Die Elektronen werden sicher nicht. so mir nichts, dir nichts, verpuffen.
Der Marc V. wird uns sicher sehr bald eine neuartige Testanlage präsentieren, die viel realistischere Test machen kann, als was alle Chiphersteller bisher anwenden. Und dann wird er super Reich mit seiner Erfindung. Oder er wird die Daten besser aus dem Bauch heraus schätzen, als alle Testanlagen und damit zum höchsten Berater aller Chip Hersteller, die Wert auf Qualität legen. Wünschelrutengänger sind ja auch wieder gefragt, ebenso belebtes Wasser.
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.