Fråga:
Vad är EEPROMs verkliga livstid?
Marlon Abeykoon
2014-02-15 10:09:14 UTC
view on stackexchange narkive permalink

ATMEL säger att celltiden för en EEPROM-cell är cirka 100 000 skrivcykler / celler. Är det faktiskt så som EEPROM fungerar i naturen?

Om jag inte ändrar värdet på en cell, gör detta stress hela livet? Om jag till exempel skriver värdet 0xFF till samma cell om och om igen, är det något annat än att skriva 0x00 , 0xFF , 0x00 etc.

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

Som du säger har den interna EEPROM en livstid på 100 000 skrivcykler. Det här är inte en gissning - en mycket betydande del av ATmega328 når detta nummer utan problem. Jag har testat tre processorer tidigare och alla nådde 150 000 cykler utan problem.

Det är viktigt att notera EEPROM: s felläge. De flesta "EEPROM-förstörare" -projekt läser / skriver upprepade gånger tills informationen inte skrivs alls. Innan denna punkt kommer EEPROM fortfarande att skadas. Detta skulle manifesteras genom att uppgifter inte lagras under en rimlig period. Det är oklokt att förlita sig på mer än 100 000 skrivcykler av denna anledning.

EEPROM skiljer sig från RAM på en ATmega. Att skriva till det är inte enkelt eller snabbt, men det är förpackat i ett vänligt Arduino-bibliotek, vilket döljer denna komplexitet för användaren.

Den första indirektionsnivån är EEPROM-bibliotek, vilket är trivialt enkelt], bara anropa två andra funktioner för att läsa och skriva. Detta kallar eeprom_write_byte, finns här.

Denna funktion använder inbyggd montering, så det kanske inte är lätt att förstå. Det finns dock en kommentar som är lätt att förstå:

Ställ in programmeringsläge: radera och skriv

Detta antyder en av komplexiteten i att hantera EEPROM - för att skriva toit måste du först radera det. Det betyder att om du ringer till EEPROM.write () kommer den att utföra en skrivcykel oavsett vilket värde du skriver.

Detta innebär att upprepade gånger skriver 0xFF troligen kommer att ha samma effekt som att skriva 0xFF, 0x00 , 0xFF, 0x00 etc.

Det finns sätt att kringgå detta - du kan försöka ringa EEPROM.read () före EEPROM.write () för att se om värdet redan är detsamma, men det tar ytterligare tid.

Det finns andra tekniker för att undvika överdrivet EEPROM-slitage, men deras användning beror på din applikation.

Slitageutjämning för EEPROM: http://electronics.stackexchange.com/questions/60342/wear-leveling-on-a-microcontrollers-eeprom
@Cybergibbons Jag försöker bestämma varför en EEPROM i ett system bara behåller ett värde i sekunder. T.ex. om jag läser tillbaka värdet omedelbart ser det ut som att skrivningen lyckades. Om jag läser tillbaka några sekunder senare börjar jag se bitar gå från 1 till 0. Du nämnde ovan "Innan denna punkt kommer EEPROM fortfarande att bli skadad. Detta skulle manifestera sig genom att data inte sparas under en rimlig period." Låter det felläge som jag beskriver som något som kan uppstå från ett stort antal raderings- / skrivcykler till en viss EEPROM-plats?
#2
+9
TheDoctor
2014-02-15 10:47:55 UTC
view on stackexchange narkive permalink

Jag körde en gång ett experiment på en extern EEPROM med 1 miljon max. cykler. Det tog ungefär 6 miljoner cykler för att bli mycket korrupta, och innan det hade utvecklats med sporadiska mängder korruption.

När du säger att du inte ändrar värdet antar jag att du skriver samma data till en adress flera gånger. Detta skulle nästan säkert stressa livet, även om det förmodligen inte skulle stressa de omgivande cellerna.

#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/

Arduino var ansluten till en väggvarta och satt "bakom en soffa i ett par månader." EEPROM såg att det var det första skrivfelet efter 47 dagar och 1230 163 cykler. Detta är en storleksordning bättre än specifikationen på atmel-databladet, men liknar resultaten från liknande experiment.

Detta verkar alldeles för högt. Jag hade hört talas om 150k till 200k tidigare, men aldrig detta: o
Problemet är att detta inte upptäcker alla fellägen. När EEPROM skadas minskar det gradvis hur lång tid det kommer att behålla data. Vid 100 000 cykler garanterar Atmel 20 års datalagring. Utöver detta minskar datalagringen. När 1,2 m cykler uppnås och du ser ett fel är detta ett omedelbart fel. vid 1230 160 cykler kan det inte ha uppstått ett omedelbart fel, men data kan bara ha lagrats i flera dagar.
#4
  0
Jorge
2019-11-26 15:02:22 UTC
view on stackexchange narkive permalink

Den magiska lösningen - om du inte vill koda vad Cybergibbons sa om att läsa innan du skrev, är funktionen EEPROM.update (). Det gör exakt det:

EEPROM.update (adress, värde);

skriver bara och stressar minnet om värdet skiljer sig från det som redan har lagrats.

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

För ett par år sedan skapade jag körtidsloggare för utrustning. Minnet skadades efter 6 månader och 40 timmar loggades med 1s upplösning => 144000 skriver. Min lösning var att sprida skrivningar över hela eeprom.

Kan du ge mer information om hur du gjorde det?


Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 3.0-licensen som det distribueras under.
Loading...