ATMEL indique que la durée de vie d'une cellule EEPROM est d'environ 100 000 cycles d'écriture / cellule. Est-ce vraiment la manière dont l'EEPROM fonctionne à l'état sauvage?
Si je ne modifie pas la valeur d'une cellule, cela met-il l'accent sur la durée de vie? Par exemple, si j'écris la valeur 0xFFencore et encore à la même cellule, est - ce différent à l' écriture 0x00, 0xFF, 0x00etc.
Réponses:
Comme vous le dites, l'EEPROM interne a une durée de vie de 100 000 cycles d'écriture. Ce n'est pas une supposition - une proportion très importante d'ATmega328 atteindra ce nombre sans problème. J'ai déjà testé trois processeurs, et tous ont atteint 150 000 cycles sans problème.
Il est important de noter le mode de défaillance de l'EEPROM. La plupart des projets "EEPROM destroyer" lisent / écrivent à plusieurs reprises jusqu'à ce que les données ne soient pas écrites du tout. Avant ce point, l'EEPROM sera toujours endommagée. Cela se manifesterait par le fait que les données ne seraient pas conservées pendant une période raisonnable. Il n'est pas judicieux de compter sur plus de 100 000 cycles d'écriture pour cette raison.
L'EEPROM est différente de la RAM d'un ATmega. L'écrire n'est ni simple ni rapide, mais il est enveloppé dans une bibliothèque Arduino conviviale , cachant cette complexité à l'utilisateur.
Le premier niveau d'indirection est la bibliothèque EEPROM , qui est trivialement simple], appelant simplement deux autres fonctions pour la lecture et l'écriture. Cela appelle eeprom_write_byte, trouvé ici .
Cette fonction utilise l'assemblage en ligne, donc peut ne pas être facilement comprise. Il y a cependant un commentaire qui se comprend facilement:
Définir le mode de programmation: effacer et écrire
Cela fait allusion à l'une des complexités du traitement de l'EEPROM - pour y écrire, vous devez d'abord l'effacer. Cela signifie que si vous appelez EEPROM.write (), il effectuera un cycle d'écriture quelle que soit la valeur que vous écrivez.
Cela signifie que l'écriture répétée de 0xFF aura probablement le même effet que l'écriture de 0xFF, 0x00,0xFF, 0x00 etc.
Il existe des moyens de contourner ce problème - vous pouvez essayer d'appeler EEPROM.read () avant EEPROM.write () pour voir si la valeur est déjà la même, mais cela prend plus de temps.
Il existe d'autres techniques pour éviter une usure excessive des EEPROM, mais leur utilisation dépend de votre application.
J'ai déjà mené une expérience sur une EEPROM externe avec 1 million de cycles nominaux max. Il a fallu environ 6 millions de cycles pour devenir largement corrompu, et avant cela, il avait progressé avec des quantités sporadiques de corruption.
Lorsque vous dites que vous ne modifiez pas la valeur, je suppose que vous écrivez plusieurs fois les mêmes données à une adresse. Cela stresserait presque certainement la vie, bien que cela ne stresserait probablement pas les cellules environnantes.
http://hackaday.com/2011/05/16/destroying-an-arduinos-eeprom/
L'Arduino a été branché sur une verrue murale et s'est assis «derrière un canapé pendant quelques mois». L'EEPROM a vu sa première erreur d'écriture après 47 jours et 1 230 163 cycles. C'est un ordre de grandeur meilleur que les spécifications de la fiche technique atmel, mais similaire aux résultats d'expériences similaires.
La solution magique - si vous ne voulez pas coder ce que Cybergibbons a dit sur la lecture avant d'écrire, c'est la fonction EEPROM.update (). Il fait exactement cela:
EEPROM.update (adresse, valeur);
n'écrira et ne stressera la mémoire que si la valeur est différente de celle déjà stockée.