Fidèle à mes « traditions », lorsque je propose un didacticiel quelconque sur la toile, ce dernier comme ses prédécesseurs est accompagné de quelques fiches techniques que l’on peut imprimer recto / verso et pour ceux qui possèdent une plastifieuse, à protéger par du film transparent. Ces fiches sont généralement très 
commodes, et ce tutoriel en apporte six qui à mon avis étaient absolument indispensables. En développement logiciel, la plus grande difficulté rencontrée lors de cette étude concernait la grandeur des tables de données qui permettent de définir la police de caractères. Ces octets empiètent directement l’espace réservé aux variables dynamiques à tel point qu’à certain moments une « collision de PILE » a perturbé le fonctionnement du logiciel. Les textes affichés sur le Moniteur pour établir le dialogue homme / machine impactent également la RAM dynamique, aussi, il faut les limiter au stricte minimum.
Pyrograver du texte consiste à déplacer le LASER comme montré sur la Fig.10 avec des mouvements où il grave, et des décalages où il est coupé. Pour tracer cette lettre ‘A’ on va de 1 à 2 en gravant, de 2 vers 3 en traçant. Puis on déplace de 3 vers 4 sans activer le LASER. Enfin on termine la lettre en traçant de 4 vers 5. Pour définir cette lettre ‘A’ il faut donc préciser quatre coordonnées avec leurs valeurs de position sur X et sur Y, et préciser si le déplacement se fait « à vide » ou en traçant. Ce sont ces données qui vont imposer la rédaction de tables boulimiques en octets de mémoire. Pensez que pour une lettre comme le ‘B’ par exemple, c’est onze déplacements qu’il faut décrire, donc 22 octets pour les valeurs sur X et sur Y. La police de caractère intègre les majuscules, les minuscules, les accentués etc. Une banque de donnée « octivore ». Aussi, pour utiliser au mieux les ressources de l’ATmega328, son EEPROM a entièrement été gavée par une première partie de la police de caractères. Puis le complément a été intégré au programme en forçant l’implantation de la table hors mémoire dynamique. Les textes qui sont également goulus en consommation de mémoire dynamique ont été initialement réduits au minimum.
De la place en mémoire dynamique à revendre.
Imposer de placer les données de la police complémentaire en constantes intégrées dans la zone programme a libéré totalement l’espace réservé aux variables dynamiques. Pour ne pas gaspiller cette zone généralement très sollicitée, initialement les textes étaient très laconiques. Puis, ayant trouvé sur Internet un moyen très simple pour les intégrer comme constantes dans la mémoire Flash réservée au programme, ce dernier a rendu possible des bavardages pratiquement sans limites, car dans ce projet le programme d’exploitation en tant que tel reste modeste en taille. Aussi, cette opportunité de liberté dans les texte du dialogue homme / machine a permis d’afficher des « pages » de texte sans pour autant restreindre les options du programme, à tel point que pour « rentabiliser » l’occupation de la zone programme j’ai recherché avec fébrilité des « moyens de consommer des octets » : Une orgie de fonctions annexes pas vraiment indispensable pour l’utilisateur. Par contre, pour le programmeur qui désire modifier le « Sketch » ces petits outils s’avèrent très agréables et font gagner beaucoup de temps. Noter au passage, que cette débauche de textes affichés n’en est pas moins ultra optimisée, ainsi que les diverses procédures du programme. C’est un principe en ce qui me concerne : Optimiser, optimiser et optimiser l’optimisation. Au fil du développement on minimise la place occupée par le code, qui s’avère la bienvenue pour ajouter des options de convivialité.
Dans ce contexte, il a été possible d’intégrer des commandes d’aide à l’utilisateur. En particulier le « HELP » qui liste à l’écran l’intégralité des commandes disponibles comme on va le voir dans le chapitre suivant. De même que la commande « $w » qui engendre la liste complète des caractères de substitution. De ce fait, les fiches initialement créées ne sont plus vraiment indispensables. Celles relatives aux diverses commandes, car les fiches de protocole pour créer et vérifier un texte avant de le soumettre à la machine restent à mon avis indispensables. À vous de voir …
Notez que le chapitre 5 n’est qu’une découverte des commandes, pour la partie opérationnelle et les protocoles conseillés un chapitre dédié spécifique est disponible plus avant.
La suite est ici.
