Approche « évidente » pour gagner de la place en RAM dynamique :
L’expérience qui précède nous a clairement montré que la collision de PILE constitue un risque permanent pour le programmeur. Elle peut conduire à un blocage complet du processeur. D’un seul coup, plus rien ne se passe. Rien ne nous précise la source des aléas constatés. La première hypothèse à laquelle on va penser est celle d’une boucle infinie qui s’est caché par mégarde dans une zone quelconque du programme. On peut toujours chercher … en vain. Nous avons eu de la chance, car n’ayant inséré que du code « certifié », la validité de la modification du programme complet était fortement probable. Et puis, surtout, l’affichage étrange nous a montré de façon « visuelle » qu’il s’agissait bien d’un comportement anormal du programme et non d’une boucle infinie. Soupçonner une collision de PILE devenait presque naturel. Pour déjouer un piège vicieux de ce type qui peut survenir même sur des programmes relativement petits mais comportant beaucoup de textes, n’oubliez jamais cette expérience. Notez définitivement « sur vos plaquettes » :
Quand un programme se met brusquement à présenter un comportement étrange, vérifier qu’il ne s’agit pas d’un écrasement du TAS par la PILE. Pour en avoir une première confirmation, diminuez provisoirement la taille des tableaux et des « TEXTES ». Quand vous avez « économisé » entre 20 et 30 octets, réactivez le programme. S’il fonctionne à nouveau c’est presque certain. Utilisez ensuite la petite séquence de code donnée dans l’encadré déjà proposé en début de didacticiel. L’espace « faible » réellement disponible apportera probablement la validation « définitive » de l’hypothèse d’une collision de PILE.
Avant d’envisager d’ajouter des lignes dans le MENU de PICOLAB, notre première action va consister à chercher à gagner de la place dans la mémoire dynamique. La première possibilité que l’on doive envisager est précisée en ligne 1) des pistes énumérées en début du chapitre Perfectionnement de PICO LAB. Maintenant que nous sommes informés sur l’occupation des 625 octets du haut de l’EEPROM de l’ATmega328 par les sauvegardes d’écran, nous pouvons établir un bilan actuel de la place encore disponible. La zone comprise entre [0 et 195] est occupée respectivement par le LOGO et la table de la BASE DE TEMPS. Nous pouvons donc disposer de [196 à 398] pour loger des données constantes soit 202 octets. Ce n’est pas Byzance, mais quand on a faim, une telle place disponible c’est déjà le Pérou.
Sur un appareil de mesure on cherche à remplir l’écran d’informations. Des valeurs numériques sans préciser ce qu’elles représentent, ainsi que leurs unités, sont peu conviviales. Alors on bourre le code de textes affichés, car un logiciel qui « bavarde » est vivant. On ne s’en rend pas compte, car on pense que tous ces caractères ASCII seront intégrés dans le programme. C’est du reste ce que l’on fait quand l’ASSEMBLEUR est notre langage de haut niveau. Déjà mentionné dans les didacticiels qui précèdent, le compilateur C++ de l’IDE loge les chaînes de caractères en mémoire dynamique, bien que fondamentalement se sont des constantes. Du coup, « bavarder » revient à ajouter de façon tragique des octets sur le TAS. Chaque texte consomme en octets son nombre de caractères plus un pour le délimiteur de fin. Par exemple « PICOLAB » va s’octroyer 8 octets sur le TAS, et « Base de Tmp « en prendra 13 de plus.
Optimiser le programme P30_PICOLAB_complet.ino va donc consister à placer le maximum de textes du programme dans l’espace compris entre les adresses relatives [196 à 398]. La solution optimale revient à choisir des textes de façon à remplir entièrement cette zone. N’oublions pas toutefois que chaque texte composé de caractères ASCII devra se terminer par le délimiteur $00. Le choix des textes à loger en EEPROM est arbitraire, vous pouvez naturellement adopter une autre sélection. Toutefois, si l’on désire tirer le meilleur parti de cette approche, la technique sera d’autant plus rentable que la taille du texte logé en EEPROM est grande. En effet, moins il y aura de textes intercalés dans la zone disponible, moins on en « perd » avec les délimiteurs $00 qui occupent chacun un octet. On sélectionnera donc dans l’ensemble du programme « les bavardages les plus étendus », c’est le critère majoritaire. Par ailleurs, on va chercher à occuper l’intégralité des octets disponibles. Le dernier trou sera « rempli » par un texte qui le comblera intégralement, avec 
naturellement son délimiteur $00. Ayant effectué les choix pertinents, le candidat retenu est « PICOLAB ». Les divers textes peuvent être logés dans un ordre absolument quelconque, mais pour des raisons de « discipline », ils ont été placés dans l’ordre de leur rencontre dans le programme complet. Comme ce fut le cas pour le LOGO et pour la table des valeurs de la BASE DE TEMPS, un programme spécifique va se charger d’inscrire ces textes aux bons emplacements. Quand vous allez consulter le contenu du dossier <PERFECTIONNEMENT> qui contient tous les modules relatif à cet ultime didacticiel, vous constaterez que le programme P07_Ecrire_les_textes_en_EEPROM.ino contient des textes qui n’ont encore jamais étés rencontrés pour élaborer PICOLAB. La raison résulte du fait que je désire vous éviter d’avoir à utiliser plusieurs programmes, chacun ajoutant quelques textes de plus. Chronologiquement diverses fonctions ont été développées, puis la possibilité de les ajouter au programme complet étant acquise, le MENU de base était alors enrichi d’un item de plus. Ensuite, optimisation maximale du programme « actuel », développement d’une nouvelle fonction, logement différé d’autres textes en EEPROM. Bref, un cheminement laborieux dans lequel on va se promener. Quand la saturation totale et définitive est devenue une certitude, alors seulement le programme de servitude P07_Ecrire_les_textes_en_EEPROM.ino a été réalisé. Ainsi, vous pouvez directement le faire fonctionner, et tout ce dont nous aurons besoin par la suite sera disponible. Voici la liste des textes logés en EEPROM :
Inutile de se précipiter sur la calculette, on constate immédiatement que le total fait exactement 203 octets et ce n’est surtout par le fruit d’un hasard bienfaiteur !
La première adresse libre à l’adresse relative 399 correspond bien au début de la zone de sauvegarde des empreintes.
Il me semble qu’un petit résumé de la situation présente semble le bienvenu :
Désirant enrichir le MENU de base actuel par des fonctions qui sont déjà intégrées au MINI LABORATOIRE, nous devons impérativement libérer de la place en RAM dynamique car la collision de PILE n’est pas très loin. Dans ce but, on a placé un maximum de textes en EEPROM, en puisant dans les plus longs pour optimisation. Ayant conduit jusqu’à son terme le développement du projet, tous les textes étant alors connus, le tri a été effectué et se trouve résumé dans le tableau donné ci-contre. Le premier texte « PICOLAB » a été choisi pour combler le « dernier trou ». Les textes sont placés dans l’ordre où ils seront utilisés dans le programme complet. Vous avez activé P07_Ecrire_les_textes_en_EEPROM.ino qui se charge de loger en EEPROM tous les textes qui permettront d’aboutir au programme « définitif ». Cet utilitaire commence par afficher dans l’ordre les textes qui seront inscrits en mémoire non volatile, puis il procède à l’écriture des 203 octets. Chacun exigeant au minimum 3mS, cette phase va consommer plus
d’une demi-seconde. 
Puis, il y a affichage du contenu complet de l’EEPROM. (Dump mémoire.) Si l’octet visualisé est un caractère ASCII, il est affiché « en texte ». Dans le cas contraire « •• » nous précise qu’il ne s’agit pas d’un caractère ordinaire. Forcément, si l’implantation est correcte, on doit retrouver une répartition conforme à celle indiquée en Fig.94 donnée ci-avant.
La Fig.120 montre une copie d’écran partielle telle que vous l’obtiendrez si le programme de servitude fonctionne correctement et que vous activez le moniteur série USB. La zone bleue contient le LOGO. Puis, entre les adresses relatives [120 à 195] dont la zone est coloriée en vert clair, sont « alignées » les diverses valeurs de la Base de Temps.
C’est à partir de 196 que commence la suite des chaînes de caractères, chacune terminée par le délimiteur 
. Enfin, à partir de l’adresse 399 jusqu’à la dernière cellule de l’EEPROM on trouve les 625 octets contenant les informations relatives aux cinq empreintes de mémorisation d’écrans.
L’intégralité des octets non volatiles sont occupés, coté stockage en EEPROM il est devenu strictement impossible de gagner quoi que ce soit.
L’intégralité des textes pouvant être logés en EEPROM sont maintenant disponibles. Nous pouvons donc passer à la suite de la recherche du gain de place, mais en utilisant les autres approches possibles que celle précisée en ligne 1) des pistes déjà énumérées. Nous allons pour la circonstance reprendre le programme P30_PICOLAB_complet.ino et chercher à gagner dans ce dernier un maximum d’octets. Si l’on arrive à dégager assez de place, il sera alors possible d’ajouter une nouvelle fonction dans PICOLAB. Comme rien ne nous prouve qu’il sera réellement possible de concilier les impératifs qui vont se dégager des prochaines études, on ne modifie pas le programme actuel. C’est P08_Optimise_avant_ajout_nouvelles_fonctions.ino que l’on va « triturer » pour en récupérer jusqu’au plus petit espace « gaspillé ». Avant d’utiliser les textes déplacés en EEPROM, j’ai préféré commencer par analyser en détail l’intégralité du source pour en compacter la taille occupée, et ce par tous les moyens « évidents ». La première action qui emprunte l’approche 3) Repérer toutes actions de même nature et n’en écrire qu’une seule sous forme de procédure a consisté à introduire une petite procédure qui affiche « OUI » ou « NON » en fonction d’un booléen qui lui est passé en paramètre. On gagne déjà 20 octets dans le programme. Puis, divers modules ont été ajoutés. L’un pour réaliser l’affichage propre au calibre de 1A dans la mesure des intensités, les autres pour préparer l’avenir. Cette version du programme optimisé anticipe déjà un peu sur les fonctions qu’il sera possible d’ajouter au MENU de base. Le logiciel augmente de 186 octets. En revanche, la place occupée par les données dynamiques s’effondre de 104 octets, soit de très bons augures pour s’affranchir des collisions de PILE tant redoutés.
On consomme encore 10 octets pour introduire void ATTENDRE_un_BP(), mais ce coût sera largement récupéré lors des développements futurs.
Enfin, le programme étant bien reconditionné dans son ensemble, les divers textes disponibles en EEPROM ont été exploités. Le programme a maigri de 166 octets, et la RAM dynamique augmenté de 144 emplacements.
Le bilan final aboutit à un programme qui intègre le calibre 1A et ne fait au final que 10 octets de plus. Les données dynamiques ont été diminuées de 248 octets, on peut raisonnablement envisager de remplacer l’oscilloscope par la version qui sauvegarde les empreintes.
