Vraag:
Wat is de werkelijke levensduur van EEPROM?
Marlon Abeykoon
2014-02-15 10:09:14 UTC
view on stackexchange narkive permalink

ATMEL zegt dat de levensduur van een EEPROM-cel ongeveer 100.000 schrijfcycli / cel is. Is dit eigenlijk hoe de EEPROM in het wild presteert?

Als ik de waarde van een cel niet verander, doet dit benadrukt het leven? Als ik bijvoorbeeld de waarde 0xFF keer op keer naar dezelfde cel schrijf, is dit anders dan het schrijven van 0x00 , 0xFF , 0x00 enz.

Vijf antwoorden:
#1
+19
Cybergibbons
2014-02-15 13:33:52 UTC
view on stackexchange narkive permalink

Zoals u zegt, heeft de interne EEPROM een levensduur van 100.000 schrijfcycli. Dit is geen gok - een zeer aanzienlijk deel van ATmega328 zal dit aantal zonder problemen bereiken. Ik heb eerder drie processors getest en ze bereikten allemaal 150.000 cycli zonder problemen.

Het is belangrijk om de foutmodus van EEPROM op te merken. De meeste "EEPROM-vernietiger" -projecten lezen / schrijven herhaaldelijk totdat de gegevens helemaal niet zijn geschreven. Vóór dit punt is de EEPROM nog steeds beschadigd. Dit zou tot uiting komen doordat gegevens niet gedurende een redelijke periode worden bewaard. Om deze reden is het onverstandig om op iets meer dan 100.000 schrijfcycli te vertrouwen.

EEPROM is anders dan het RAM op een ATmega. Er naar schrijven is niet eenvoudig of snel, maar het is verpakt in een vriendelijke Arduino-bibliotheek, die deze complexiteit voor de gebruiker verbergt.

Het eerste niveau van indirectheid is de EEPROM-bibliotheek, die triviaal eenvoudig is], door gewoon twee andere functies aan te roepen voor lezen en schrijven. Dit roept eeprom_write_byte aan, vind je hier.

Deze functie gebruikt inline assembly, dus het is misschien niet gemakkelijk te begrijpen. Er is echter een opmerking die gemakkelijk te begrijpen is:

Programmeermodus instellen: wissen en schrijven

Dit verwijst naar een van de complexiteiten van het omgaan met EEPROM - om ernaar te schrijven, moet u het eerst wissen. Dit betekent dat als je EEPROM.write () aanroept, het een schrijfcyclus zal uitvoeren ongeacht de waarde die je schrijft.

Dit betekent dat het herhaaldelijk schrijven van 0xFF waarschijnlijk hetzelfde effect heeft als het schrijven van 0xFF, 0x00 , 0xFF, 0x00 etc.

Er zijn manieren om dit te omzeilen - u kunt proberen EEPROM.read () aan te roepen voor EEPROM.write () om te zien of de waarde al hetzelfde is, maar dit vereist extra tijd.

Er zijn andere technieken om overmatige EEPROM-slijtage te voorkomen, maar het gebruik ervan hangt af van uw toepassing.

Slijtage-egalisatie voor EEPROM: http://electronics.stackexchange.com/questions/60342/wear-leveling-on-a-microcontrollers-eeprom
@Cybergibbons Ik probeer te achterhalen waarom een ​​EEPROM in een systeem slechts seconden een waarde vasthoudt. Bijv. als ik de waarde onmiddellijk teruglees, lijkt het erop dat het schrijven is gelukt. Als ik het seconden later teruglees, begin ik te zien dat bits van 1 naar 0 gaan. U zei hierboven "Vóór dit punt zal de EEPROM nog steeds beschadigd zijn. Dit zou zich manifesteren doordat gegevens niet gedurende een redelijke periode worden bewaard." Klinkt de foutmodus die ik beschrijf als iets dat kan optreden bij een groot aantal wis- / schrijfcycli naar een bepaalde EEPROM-locatie?
#2
+9
TheDoctor
2014-02-15 10:47:55 UTC
view on stackexchange narkive permalink

Ik heb ooit een experiment uitgevoerd op een externe EEPROM met 1 miljoen max. nominale cycli. Het kostte ongeveer 6 miljoen cycli om ernstig beschadigd te raken, en daarvoor was het gevorderd met sporadische hoeveelheden corruptie.

Als u zegt dat u de waarde niet verandert, neem ik aan dat u dezelfde gegevens meerdere keren naar een adres schrijft. Dit zou vrijwel zeker het leven belasten, hoewel het waarschijnlijk niet de omringende cellen zou belasten.

#3
+2
80HD
2014-02-15 14:47:32 UTC
view on stackexchange narkive permalink

http://hackaday.com/2011/05/16/destroying-an-arduinos-eeprom/

De Arduino is aangesloten op een muurwrat en zat "een paar maanden achter een bank". De EEPROM zag zijn eerste schrijffout na 47 dagen en 1.230.163 cycli. Dit is een orde van grootte beter dan de specificatie op het atmel-gegevensblad, maar vergelijkbaar met de resultaten van vergelijkbare experimenten.

Dit lijkt veel te hoog. Ik had eerder gehoord van 150k tot 200k, maar dit nooit: o
Het probleem is dat dit niet alle storingsmodi detecteert. Wanneer de EEPROM beschadigd raakt, wordt de tijd dat het gegevens vasthoudt geleidelijk verminderd. Bij 100.000 cycli garandeert Atmel 20 jaar dataretentie. Afgezien hiervan neemt de gegevensretentie af. Wanneer cycli van 1,2 m zijn bereikt en u een fout ziet, is dit een onmiddellijke fout. bij 1.230.160 cycli was er misschien geen onmiddellijke fout, maar de gegevens werden misschien maar dagen bewaard.
#4
  0
Jorge
2019-11-26 15:02:22 UTC
view on stackexchange narkive permalink

De magische oplossing - als je niet wilt coderen wat Cybergibbons zei over lezen voordat je gaat schrijven, is de functie EEPROM.update (). Het doet precies dat:

EEPROM.update (adres, waarde);

zal alleen het geheugen schrijven en belasten als de waarde verschilt van de waarde die al is opgeslagen.

#5
  0
Sasquatch
2020-01-03 01:49:34 UTC
view on stackexchange narkive permalink

Een paar jaar geleden heb ik een runtime-logger gemaakt voor een apparaat. Geheugen werd beschadigd na 6 maanden 40 uur loggen met 1s resolutie => 144000 schrijfbewerkingen. Mijn oplossing was om het schrijven over het hele eeprom te verspreiden.

Kunt u meer informatie geven over hoe u dit heeft gedaan?


Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...