Mon appareil à moi qu’il m’appartient personnellement !
Pléonasme direz-vous et vous aurez triplement raison. Ce titre amusant va servir à ouvrir un chapitre qui n’entre pas, à franchement parler, dans le cadre de l’utilisation de notre instrument de mesures. Mais figurez-vous que voulant me faire un petit plaisir, je désirais remplacer la SALAMANDRE qui habite déjà dans PICOLAB, par le gentil petit PANDA. Le changement à opérer dans le programme consistait à loger en EEPROM le nouveau dessin. Puis, dans la place restante, tasser un maximum de textes bavards. Enfin, modifier un chouilla la séquence qui affiche le LOGO et revoir toutes les adresses en EEPROM des textes qui y sont gravés dans le marbre. Comme le nouveau LOGO fait 736 octets au lieu de 120, tous les textes d’origine ne peuvent contenir dans l’espace disponible. Donc une petite réorganisation pour optimiser le tout a été affinée, et les textes qui restaient sans « domicile » ont été introduits dans le programme. Tout ça confine à de la routine. En moins de deux heures l’affaire devait « être pliée ». QUE NENNI !
Impossible d’arriver à faire rentrer ce diable de PANDA dans sa belle cage informatique. Pourtant le pointeur PTR est passé de byte à int pour pouvoir couvrir la plage concernée. Prouitchhhh, le programme devenait muet dès que la séquence d’écriture en mémoire non volatile était validée. Après bien des tourments, le problème que je ne peux m’expliquer que par un petit aléa de fonctionnement de la bibliothèque <EEPROM.h> a été contourné. Pour des raisons non élucidées, il semble impossible de pouvoir programmer plus de 512 octets d’affilé.
En fait, c’est la taille de la table du dessin qui semble engendrer ce problème. Quand le tableau complet est écrit dans le source, même si l’on n’en prend que 120 octets par exemple, le programme se bloque. Une tentative a consisté à scinder le dessin en six tableaux, les cinq premiers comportant chacun 128 octets. Le problème persiste. Il semblerait qu’un ou plusieurs tableaux ne doivent pas dépasser les 512 emplacements. Problème d’encombrement sur le TAS où tout autre raison ?
Commençant à saturer sur cette application, j’ai paresseusement éludé la difficulté, si vous trouvez n’hésitez pas à le faire savoir en ligne …
Qu’à cela ne tienne nom d’un panda binaire, la parade est facile. Je vous livre le secret dans le répertoire <Mes programmes PERSONNELS> qui inclus « le nouveau dessin », « les textes réorganisés en EEPROM » et P36_COMPLET_avec_perfectionnements.ino qui exploite toutes ces modifications. Il suffit en définitive d’agencer deux programmes pour inscrire le dessin en EEPROM. Le premier PANDA1_EEPROM.ino « trace » les 512 premiers octets. Le deuxième PANDA2_EEPROM.ino se charge des 224 octets restants. Notez au passage que le premier « paquet » commence en adresse relative $0000, le deuxième bloc doit être décalé de 512 emplacements.
La variable PTR a pour rôle de pointer à la fois dans le tableau et dans l’EEPROM. Comme pour le tableau les indices commencent forcément en 0, l’initialisation avec l’instruction PTR = 0; reste inchangée. Pour « déposer » les octets aux bons emplacements, il importe d’opérer le décalage de +512 dans l’instruction EEPROM.write pour le deuxième logiciel.
Naturellement, il n’y a aucune raison pour que vous désiriez spécialement ce petit panda en écran d’accueil, je ne vous propose le dossier <Mes programmes PERSONNELS> uniquement pour que vous puissiez éventuellement analyser les programmes qui y sont contenus si vous rencontreriez des difficultés à prévoir votre propre dessin. Par contre, il m’a semblé indispensable de vous informer de cette difficulté que la modestie en taille informatique de l’envahissante petite salamandre n’avait pas fait surgir. Prévenus, vous pouvez désormais envisager des dessins de tailles bien plus grandes, cet aléas étant connu et contourné.
