09) Gestion de la mémoire non volatile EEPROM.

Dans l’encadré rose en bas de la page 18 était précisé avec insistance : ATTENTION, les tableaux sont les données les plus voraces en espace utilisé et les textes sont intrinsèquement des tableaux. Aussi, si la mémoire non volatile EEPROM n’est pas utilisée pour mémoriser des données à conserver sur coupure alimentation, y loger un maximum de textes affichés. C’est par le respect de ce conseil que l’on peut réaliser le plus facilement une optimisation de la taille du code objet. À ce stade du développement, seule une trace oscilloscopique est prévue pour la sauvegarde en mémoire non volatile. Aussi, l’idée de base consiste à placer les échantillons en haut de la mémoire, et d’y « entasser » les textes affichés au fur et à mesure que l’on va développer les menus et les écrans de données. L’occupation envisagée est représentée sur la Fig.45, la répartition précise des zone restant à définir.

Envisageons la clause n°15 du cahier des charges qui stipule : Enregistrement de « quatre écrans de large » avec affichage fenêtré. Sachant que la largeur possible de la page graphique fait 128 PIXELs, pour sauvegarder quatre fois cette dernière il faudra réserver 512 octets en Zone des échantillons, soit exactement la moitié de l’espace disponible en EEPROM. L’étendue des Données diverses ne devrait pas dépasser les 30 octets au maximum, car elle ne contiendra que les attributs de l’enregistrement : Base de temps, sensibilité verticale, front de déclenchement etc. Il nous reste donc au moins 482 octets pour les divers textes affichés.

Pour compléter les « briques » qui assemblées plus tard constitueront le programme d’application, on va avec P09_Tester_EEPROM.ino développer les routines qui servent à gérer la mémoire non volatile de l’ATmega328. Pour les futurs démonstrateurs il faudra pouvoir sauvegarder une trace oscilloscopique, la récupérer pour l’afficher, effacer la zone des échantillons, encore que ça ne présente pas un gros intérêt. Si par la suite il faut « faire de la place » on pourra toujours enlever cette fonction du programme. Il faudra en outre pouvoir lire les textes figés en EEPROM pour les afficher. Naturellement, pour que P09 puisse effectuer ce travail, il faut impérativement que des textes soient déjà présent en EEPROM. C’est la raison pour laquelle avant de téléverser P09 il faut en préambule transférer P08_Textes_provisoires.ino et en déclencher l’exécution en activant le Moniteur de l’IDE avec initialisé à 115200 baud. Outre quelques textes pour tester les procédures d’affichages, la Zone des échantillons est entièrement remplie par une trace oscilloscopique fictive. On pourra ainsi disposer d’un enregistrement de début pour tester l’effacement de la zone. Ce n’est qu’une fois l’EEPROM en partie initialisée que l’on pourra manipuler avec P09_Tester_EEPROM.ino les séquences qui seront intégrées dans les prochains logiciels de validation. On notera au passage qu’avec un OCTET on dispose de 256 valeurs possibles, alors que la hauteur de l’écran ne fait que 64 PIXELs. Donc il faudra diviser par quatre les valeurs pour les afficher sur l’écran graphique.

Le remplissage provisoire de la mémoire non volatile.

Sachant que la hauteur de l’écran graphique est limitée à 64 PIXELs, il est totalement inutile de conserver la définition de 1024 pour la visualisation. En divisant par quatre la valeur issue du CAN elle sera comprise entre 0 et 256 et sera stockable dans des OCTETs, tenant ainsi deux fois moins de place. C’est la raison pour laquelle la Zone des échantillons n’occupe que la moitié de l’EEPROM. On commence par activer le Moniteur de l’IDE avec l’idéogramme et on initialise la vitesse de transfert à 115200 baud. Puis on transfère le démonstrateur P08_Textes_provisoires.ino et on l’active en cliquant une deuxième fois sur . La fenêtre du moniteur se remplit et ressemble à la copie d’écran de la Fig.46 avec en violet des commentaires au fur et à mesure que le programme se déroule. En particulier dans la zone 1 les textes inscrits sont listés. Puis il y a affichage sous forme de tableau de l’intégralité du contenu de l’EEPROM avec l’indication des adresses des OCTETs dans la zone jaune. (Adresse du premier octet de la ligne à gauche à laquelle on doit ajouter la « valeur » de la colonne affichée ici en hexadécimal.) Noter qu’à tout moment dans la liste des logiciels fournis vous disposez à convenance d’un outil nommé Lister_EEPROM_en_HEXAdecimal.ino qui vous permet de lister le contenu de l’EEPROM de n’importe quelle carte Arduino. Dans la zone 2 sont donc listés les textes, pour ainsi déterminer l’adresse de leur début indispensable aux routines d’affichage qui viendront puiser les caractères. Pour pouvoir facilement lors de l’élaboration du programme qui viendra inscrire les textes du logiciel d’utilisation final, il est utile pour le programmeur de savoir en permanence la zone de 2 qui reste encore disponible à chaque stade du développement. Les OCTETs non utilisés sont repérés par « .. » et détectés par la remise à zéro initiale de l’intégralité de l’EEPROM avec des $FF. Dans la zone des données coloriée en bleu on observe en adresse 511 le chiffre 05. Il indique la façon dont sont sauvegardés les échantillons. Il est à ce stade envisagé deux protocoles possibles si la taille occupée par le programme utilisateur le permet :
• Les 512 OCTETs sont remplis par une Trace longue contenant quatre écrans de large.
• La zone 3 pourra contenir quatre enregistrements différents contenant une largeur d’écran.

La Zone des échantillons est listée en HEXADÉCIMAL car les valeurs peuvent aller jusqu’à 254 qui en décimal impose trois caractères, alors que les colonnes sont formatées à deux.

Utilisation de P09_Tester_EEPROM.ino.

Ayant inscrit les textes et une simulation de Trace longue en EEPROM, on téléverse le logiciel P09 qui affiche l’écran de la Fig.47 à son démarrage. On est ainsi directement renseigné sur la façon d’utiliser le petit clavier. Cliquer sur le bouton du Haut déclenche la visualisation de la Trace actuellement en mémoire. Comme l’oscilloscope n’est pas encore émulé, cette dernière est générée artificiellement au démarrage. Elle est comme sur la Fig.48 constituée d’une dents de scie classique sur les générateurs basses fréquences pour tester la linéarité d’un amplificateur par exemple. Superposé en haut de la trace est indiquée la consigne pour revenir « au MENU de BASE« . Cliquer maintenant sur un bouton quelconque pour sortir et sur le bouton du Bas pour faire afficher la Trace longue actuellement figée en EEPROM. L’écran affiche la belle sinusoïde de la Fig.49 qui pourrait être celle de la sortie d’un transformateur secteur. Comme pour la fonction précédente toute touche du clavier fait sortir de cette page écran. Étant dans le MENU de BASE, cliquer sur le bouton de Gauche génère un BIP sonore pour avertir l’opérateur que s’il valide il y aura « perte » définitive d’informations et l’écran B de la Fig.50 précise l’action en cours. Confirmer avec le BP Haut. Provoquer un RESET, puis cliquer sur le bouton du Haut suivi de deux clics sur celui du Bas. La page écran confirme l’effacement définitif de la trace qui était en EEPROM. Déclencher encore un RESET suivi du bouton poussoir de Droite. Avertissement sonore d’une perte potentielle définitive d’informations. Confirmer avec « OUI« . Cliquer enfin sur la touche du Bas pour vérifier que « la dent de scie » a bien été inscrite en mémoire non volatile. La belle sinusoïde est définitivement perdue sauf à faire usage du démonstrateur P08. Vous avez observé que pour ces deux fonctions, durant l’écriture en EEPROM la composante rouge de la LED triple s’allume confirmant l’opération. À ce stade le programme consomme 8534 Octets et 948 emplacements en mémoire dynamique.

« Passage » des textes en EEPROM.

Nous allons par les manipulations qui vont suivre vérifier le bénéfice patent à inscrire les textes de dialogue opérateur dans la mémoire EEPROM. Dans ce but on va éliminer toutes les procédures qui affichent actuellement du texte et les remplacer par des procédures totalement identiques mis à part que les textes sont puisés en mémoire non volatile. Pour ce faire commencer par transformer le bloc
[ ======== Routines pour les textes dans le programme ======== ] qui contient l’intégralité de ces procédures. Il suffit de le faire précéder par /* et de le terminer par */. Puis enlever ces deux types de délimiteurs dans le bloc [ ======== Routines pour les textes dans l’EEPROM ======== ] situé juste au dessus. Téléverser cette version et vérifier par les manipulations précédentes qu’il n’y a pour l’opérateur strictement aucune différence. Pourtant, le programme fait 142 OCTETs de moins alors que l’on a ajouté la procédure Aff_TEXTE_EEPROM(Paramètres). En mémoire dynamique on économise 184 OCTETs, avantage substantiel pour diminuer le risque de collision de PILE. (Problème abordé en détails plus avant.) On imagine le gain de place que l’on va réaliser quand l’intégralité des dialogues viendront « gonfler les bavardages ». De plus, le bénéfice est encore plus avantageux si le texte contient des accentués, ce qui n’est pas le cas dans ce démonstrateur. La conclusion s’impose : Un maximum de textes sera logé en mémoire EEPROM.

La lisibilité d’un programme.

Finalité de ce petit projet : S’amuser avec Arduino tout en apprenant à programmer avec méthodes. Dans cette optique il me semble incontournable d’aborder le thème de la lisibilité d’un logiciel. En Page 13 ce thème a déjà été abordé et je vous invite avec insistance à relire le chapitre qui commence par la vérité biblique la première qualité d’un logiciel quel qu’il soit est sa LISIBILITÉ. Nous allons observer dans le démonstrateur P09 quelques lignes de programme ou la lisibilité a été pris en compte. Considérons une instruction du type Aff_TEXTE_EEPROM(48,12) utilisée pour le dialogue Homme/Machine. Lors du développement chaque fois que l’on désire modifier un texte, il faut le changer en EEPROM. Puis modifier les paramètres le concernant dans le programme. Pour retrouver la bonne instruction dans le fatras des Aff_TEXTE_EEPROM c’est une galère, car 48,12 n’est vraiment pas lisible. C’est la raison pour laquelle il est important de faire suivre ces instruction par des remarques de type // « RAZ EEPROM : » précisant le texte affiché par l’instruction.
Autre point important qui facilite indubitablement la lecture du logiciel. Considérons la Fig.51 qui précise le numéro arbitraire affecté à chaque touche du petit clavier. Si l’on analyse la séquence de la Fig.52 on est obligé de se reporter au dessin du clavier pour comprendre à chaque fois de quel touche il s’agit, alors que la séquence Fig.53 est bien plus parlante.

La suite est ici.