Discussion :

[frederic13870]

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 ?

[Delias]

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

[boijea]

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.

Est-ce possible si on coupe l’alimentation d'une manière abrupte!?!
Ce serait cool!

[Delias]

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

[frederic13870]

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 ?

[jpbbricole]

Bonjour frederic13870

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 ?

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.
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

[boijea]

Je croyais que l'EEPROM permettait d'écrire le code logiciel de manière définitive, ce qui n'est absolument pas le cas.

Non, pas ici.

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 ?

Non, ce n'est pas une bêtise du tout et on aurait vraiment de la place!
Oui, mais c'est très cher (côté marketing pour un produit ).
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

[boijea]

Est-ce possible si on coupe l’alimentation d'une manière abrupte!?!
Ce serait cool!

Pardon, je croyais au père Noël et je faisais plusieurs choses en même temps!

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

except KeyboardInterrupt: # Interruption avec 'Ctrl+C'
GPIO.cleanup() # Ressources libérées

en Python (ici pour un Raspberry Pi) où un Ctrl-C au clavier va forcer un cleanup().
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:

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.

on ne peut pas sauvegarder des données lors de l'interruption d'alimentation ... mais bien avant!
Delias devrait reconnaître que cette phrase ne passerait pas dans un article publié ici (et j'en écris un en ce moment ).

[boijea]

(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