Version imprimable
Bjr,
J'ai mis au point un petit logiciel pour l'Arduino.
J'ai lu sur la doc, sans plus de précisions, qu'il était possible de graver un programme dans une EEPROM.
Est-ce intéressant pour la fiabilité du logiciel ?
Il y a-t-il besoin d'un matériel spécifique ?
Bonjour Frédéric
Réponse pour les Arduino à base d'ATMega. Non valable pour les autres!
L'EEPROM ce n'est pas pour le programme mais pour les données qui doivent être modifiées par le programme et sauvegardée lors de l’interruption d'alimentation.
Quand tu téléverses un programme Arduino, il est d'office sauvegardé en mémoire non volatile: la flash. Donc ce que tu demandes c'est le cas d'office et c'est la seule possibilité.
La différence entre la flash et l'EEPROM c'est:
- l'EEPROM s'efface byte par byte et est accessible en lecture / écriture par le programme.
- la flash s'efface en bloc, en l’occurrence deux, la partie principale et le bootloader. Le bootloader peut y écrire mais le programme ne peut y accéder qu'en lecture (utile pour récupérer des constantes, par exemple des chaines de caractère à émettre).
Le code ne peut être exécuté que depuis la flash (contrairement à beaucoup d'architectures plus avancées où le code doit être mis en RAM avant exécution).
Les deux peuvent se programmer par un programmateur ISP et les autres. C'est d’ailleurs la méthode pour recharger le bootloader Arduino.
Précise ta question!
Delias
(Envoyé sans avoir vu la réponse de Delias préparée entre temps)
L'Arduino possède un petite mémoire morte qu'il est possible d'utiliser pour stocker des "données".
Si tu veux conserver des valeurs de variables, c'est cet espace de stockage qu'il faudra utiliser.
Typiquement si ton programme lit une température et conserve le minimum et le maximum, c'est en EEPROM qu'il faudra les conserver.
Sinon, ces deux températures seront perdues au prochain démarrage.
Un autre cas: un Web serveur sur ton Arduino sur lequel tu lui donnes par un POST ou autres, une valeur, comme celle de générer une alarme ou des leds couleurs en fonction d'une limite de température que tu changeras régulièrement, et sans mettre à jour ton sketch après recompilation dans l'IDE de l'Arduino.
Tu pourrais alors conserver cet valeur en EEPROM.
Il faudrait se limiter d'utiliser l'EEPROM à cause du nombre limité de cycle de lecture: je ne l'ai jamais utilisé!
Il y a sans doute plein d'autres exemples que d'autres ici se feront le plaisir de te donner.
Cordialement
Est-ce possible si on coupe l’alimentation d'une manière abrupte!?!Citation:
Envoyé par Delias
Ce serait cool!
Bonjour
Cela garde ce qu'on y a sauvegardé (à la manière d'une mémoire 24Cxxx ou d'une carte SD externe).
Et sur ATMega l'arrêt est généralement brutal, il n'y a pas beaucoup d'autres méthodes.
Pour la suite c'est déjà en partie ici: Garder une variable en mémoire après coupure d'alimentation
La limitation du nombres d'écritures, la durée d'écriture, bien des embuches... . Pour sauvegarder à la coupure il faut planifier l'arrêt (matériellement et logiciellement).
Delias
Pardon, je croyais au père Noël et je faisais plusieurs choses en même temps!Citation:
Envoyé par boijea
Dans ma tête, je m'imaginais que lorsqu'on coupait l'alimentation, une procédure particulière, style de watchdog hardware, forçait l'exécution d'un morceau de code pour sauvegarder deux trois variables en EEPROM.
Ce serait similaire à un
en Python (ici pour un Raspberry Pi) où un Ctrl-C au clavier va forcer un cleanup().Citation:
except KeyboardInterrupt: # Interruption avec 'Ctrl+C'
GPIO.cleanup() # Ressources libérées
Les watchdogs hardware sont en principe des cartes extérieurs avec timers.
Mais si on revient à la phrase peut-être pas trop bien formulée en fait:
on ne peut pas sauvegarder des données lors de l'interruption d'alimentation ... mais bien avant!Citation:
Envoyé par Delias
Delias devrait reconnaître que cette phrase ne passerait pas dans un article publié ici (et j'en écris un en ce moment :zoubi:). :D
Je croyais que l'EEPROM permettait d'écrire le code logiciel de manière définitive, ce qui n'est absolument pas le cas.
Bon, dans dans ce cas, pour sauvegarder des variables d'un reboot à un autre, pourquoi ne pas utiliser un shield micro-sd ?
Je dis une bêtise ou quoi ?
Bonjour frederic13870
Non, ce n'est pas une bêtise, c'est une autre option. L'usage de l'EEPROM, pour quelques variables dans un programme à sauver est plus facile à mettre en oeuvre et se trouve "sous la main", la micro SD est plus justifiée quand les quantités deviennent plus importantes.Citation:
Envoyé par frederic13870
Dans la plus part de mes programmes, les paramètres de fonctionnement peuvent être modifiés par des ordres à la console et sont sauvés en EEPROM.
Cordialement
jpbbricole
Non, pas ici.Citation:
Envoyé par frederic13870
Non, ce n'est pas une bêtise du tout et on aurait vraiment de la place!Citation:
Envoyé par frederic13870
Oui, mais c'est très cher (côté marketing pour un produit 8O).
Et je retape sur le clou: un ESP32 ou mieux un ESP8266 fera l'affaire!
Un EEPROM c'est petit, juste pour quelques données et très rarement écrites à cause de sa durée de vie.
Un Arduino avec WiFi ou un ESP peut aller chercher ou écrire des données à l'extérieur.
Cordialement
Bonsoir à tous
L'EEPROM est intégrée car 99% des applications en ont besoin et 60% peuvent se contenter de ce qui est embarqué (chiffres au doigt mouillé). Donc moins de composants externes -> moins de coût, de consommation et de place. Avant d'être un Arduino, l'ATMega c'est d'abord de l'embarqué de faible taille et très faible consommation que l'on retrouve partout.
L'accès y est plus rapide et on peut envisager une sauvegarde à la coupure sur la simple réserve des condensateurs d'alimentation, chose bien plus compliquée sur une EEPROM externe (vu qu'une carte SD ce n'est qu'une EEPROM). Et avec l'EEPROM interne on évite d'utiliser des lignes d'E/S pour cela. (Avec les puces à 8 pattes de la même famille, pas question d'en gaspiller :aie:)
Ensuite la Flash qui contient le programme est une variante d'EEPROM (on l'efface que en bloc, c'est de là que vient son nom). Mais pour éviter la confusion entre cette mémoire et celle pour les données on n'utilise pas le terme EEPROM pour la mémoire programme!
:fleche: Donc le programme, une fois téléversé dans l'Arduino, y reste même si on coupe l'alimentation.
Je le répète ce n'est valable que pour les Arduino à base d'ATMega (Uno, Micro, Nano, Lenardo, Mega, etc.)
Delias
bonsoir,
une question : que se passe-t-il si l'alimentation est coupée pendant l'écriture sur l'EEPROM ? Est-ce que cela endommage le composant ?
Cette mémoire n'a pas un nombre limité de lecture et d'écriture ?
Une EEPROM (Electrically Erasable Programmable Read-Only Memory - mémoire morte reprogrammable électriquement) est une mémoire non volatile dont le contenu peut être redéfini par application d’une différence de potentiel importante (de mémoire de l’ordre de 20V générés en interne par une charge-pump) pour faire transférer des électrons d’une couche à une autre (en gros c’est un transistor à effet de champ avec 2 couches de métal-oxyde ou “floating-gate transistor”). L’application de cette forte tension est ce qui à la longue endommage la cellule (un bit) et ATMEL pour nos cartes à base d’ATMEGA garantit 100.000 écritures. La lecture ne faisant pas appel à une forte tension, elle n’endommage pas l’EEPROM.Citation:
Envoyé par Auteur
Comme dit ci dessus, à la différence des mémoires Flash (une variété de mémoire EEPROM rapide) qui est effaçable par secteur complet, une EEPROM est effaçable par cellule individuelle. C’est une opération «longue» (relativement) et suivant les EEPROM la taille du bloc effaçable peut être du niveau du bit (le cas du ATMEGA) et si vous perdez l’alimentation durant un cycle d’écriture, l’état de l’octet impliqué devient indéterminé, mais vous n’avez pas endommagé votre processeur, il faudra juste refaire un cycle d’effacement à la prochaine opération.
Si on dépend de valeurs stockées en eeprom proprement, on ajoute généralement un petit étage de détection de perte d’alimentation (réalisée en appliquant une partie de la tension d'alimentation (au travers d’un pont diviseur) sur une pin du micro-contrôleur capable de générer une interruption - genre D2/INT0).
Sur perte d’alimentation, l'interruption est activée et Le code de l’interruption se charge de l’écriture en mémoire EEPROM.
bien sûr comme il n’ y’a plus d'alimentation, il faut une source d’énergie. On ajoute donc un condensateur (électrolytique le moins cher) de secours placé au plus près du processeur qui se charge à travers une diode quand l’alimentation est présente (la diode empêchant le condensateur de se décharger dans le pont diviseur lors de la perte d’alim).
La capacité du condo est dimensionnée pour maintenir l’alimentation du processeur pendant le temps d’écriture de tout ce que vous devez sauvegarder (et de la diode qui va créer une chute de tension donc vous ne serez pas chargé à 5V pleins par exemple).
Enfin Pour s’assurer que la sauvegarde s’est bien déroulée, on calcule le plus souvent une «*signature*» (code CRC16, hash) de ce qu’on a écrit et on le met aussi en eeprom. ainsi au redémarrage si la signature correspond à ce qu’on a lu en mémoire, on est quasiment sûr que l’opération de sauvegarde s’était déroulée correctement.
Voilà ;)
Bon, je vais potasser mes vieux bouquins d'électronique pour mettre au point un pont diviseur avec un gros Condo, qui déclenchera une interruption .
Merci à tous.;)
J’étais tombé sur un tuto bien fichu pour ATMEGA - je vais essayer de le retrouver dans mes bookmarks
ÉDIT:
voici le lien
Attention si vous utilisez un ESP, il n’y a pas d’EEPROM à proprement parler. la librairie EEPROM va en fait écrire dans un secteur de la mémoire flash dédié de 4K octets. En se souvenant de ce qui est décrit ci dessus, la mémoire flash ne s’efface pas octet par octet mais d’un bloc, et donc lorsque l’on met à jour cette «émulation d’EEPROM», on efface tout le secteur et ensuite on écrit en fait TOUT le buffer qui est en cache. C’est important à garder en tête pour le dimensionnement de son condensateur.