Bonjour, j'aimerais savoir, n'ayant jamais utilisé la mémoire EEPROM, si la mémoire EEPROM est vidée à chaque reprogrammation du micro-contrôlleur.
Si oui, à quelle valeur ?
Bonjour,
Non elle est conservée lors de la rep^reprogrammation (du moins pour le processeurs AVR).
Merci ! Et pour les ARM ? Ca dépend ?
Sur les processeurs ARM l'EEPROM n'est pas effacée lors du téléchargement avec l'IDE.
Donc pareil que les AVR ?
J'ai peut être dit une bêtise en répondant trop vite. Je ne suis pas sur que les processeurs ARM aient de l'EEPROM.
Sur ESP ou MKR il n’y a pas d’EEPROM, c’est simulé en mémoire flash par l’utilisation d’une bibliothèque. Ces partitions ne sont pas affectées il me semble par l’upload (sans doute tant que vous ne changez pas la structure des partitions )
Dans ce document
aucune carte présentée en ARM n'a de l'EEPROM.
Il faudrait que je relise la doc, très intéressante d'ailleurs.
Je lis que :
- l'Eeprom a un nombre d'écritures limité, avr = 100 000, ESP32 ?
- la flash, c'est pareil dans le principe, mais en pire : avr = 10 000, ESP32 ?
Précision : c'est chaque octet pris individuellement qui ne peut être écrit qu'un nombre limité de fois. La lecture n'est pas limitée.
Avec un programme en cours de développement, c'est-à-dire avec des erreurs ou maladresses à corriger, les 10 000 enregistrements en flash ne me semblent pas impossibles à atteindre.
Une eeprom externe qui dialogue en I2C me parait plus sûre, surtout pendant le développement.
Dans un micro, l'eeprom, je la vois plutôt pour stoker des réglages qui ne changent pas ou exceptionnellement.
Mais ce n'est que mon avis.
le file system intègre un algo de wear leveling qui évite d’écrire trop souvent au même endroit physique même si vous avez l’impression d’accéder à la même mémoire
Merci mais je ne suis pas plus à un composant près, il y a longtemps que je n'ai plus de contraintes industrielles.
Je suis dans le plaisir et je préfère ne pas chercher les emm***des.
Effectivement rajouter une FRAM n’est pas très coûteux si besoin de bcp d’espace sur AVR
Si on n’a besoin que de 512 octets sur ARM et qu’on a une partition de 2Mo pour les data ca vous laisse quand même environ 41 millions d’écritures de tout ce bloc… de quoi voir venir
Avis favorable auquel j'y ai déjà pensé, et qui tient. Je ne vais pas faire tenir dedans des chaînes de caractères, mais plutôt la version du système, les broches des composants reliés, le temps de rebond (2ms suffisent) d'un bouton-poussoir, etc.
J'y ai pensé, pour l'EEPROM, voire autre (carte SD). J'ai pensé que déplacer régulièrement les fichiers/valeurs qui ne bougent pas suffirait. Et on stocke par exemple dans un fichier le nombre d'écriture à tel endroit de l'EEPROM où ça nous servira plus tard à écrire à l'endroit le moins utilisé.
Évidemment ce système prend du temps en plus à l'écriture, mais si on ne compte pas souvent écrire (justement dans l'EEPROM faut éviter), ça va aller.
Et autre question :
Il me semble que quand on n'écrit pas dans la mémoire pendant un certain temps, la valeur se "dégrade" et donc peut provoquer une corruption du fichier voire du stockage. Vrai ou faux ?
Bizarre, on ne peut pas écrire dans la mémoire Flash en cours d'exécution à part pour l'Arduino Due, en théorie (je ne connais pas de bibliothèque pour ça).
Ces cartes peuvent le faire ?
Bonjour techvij
Une mémoire permanente qui n'a pas de problème de nombre de cycles d'écriture, du moins beaucoup moins est la mémoire FRAM.
Cordialement
jpbbricole
Ce n’est pas le cas sur ces autres puces. Vous avez des API de gestion de fichiers avec différents formats (par exemple SPIFFS ou LittleFS) ou un système de clé/valeur avec Préférences sur ESP32
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.