10) Un petit délire de luxe.

Manifestement, sur le thermomètre de la Fig.120 on observe que la zone rouge titille allègrement les 28%, c’est est celle goinfrée sans vergogne par la fonction de gestion des OPTIONS. Une boulimie presque scandaleuse qui se justifie toutefois par le nombre d’écrans à émuler et des traitements pas forcément élémentaires. Il est assez singulier de constater que cette gestion de ce qui n’est au fond que des « facilités » d’utilisation de la machine consomme largement plus du double de l’implémentation du RUN qui concerne la raison d’être de cet appareil. C’est un peu inhabituel, avec pour justification la qualité opérationnelle. Avec un clavier nain, un bouton rotatif, une LED triple et un petit écran, il fallait faire aussi bien qu’avec la présence d’un clavier étendu et d’un écran à haute définition sur la machine élémentaire. La mission est accomplie et la version actuelle du démonstrateur valide une technique très agréable à utiliser. Il reste encore un petit 2% d’espace que je me suis réservé depuis longtemps avec l’espoir de pouvoir intégrer un hommage graphique à Alan TURING qui mériterait plus que fortement un prix Nobel, fut-il à titre posthume, vu l’apport formidable au genre humain dont il a fait preuve, et pour lequel il a été ignoré, et méprisé comme un pariât pour son homosexualité. Pas un homme à mon sens a autant contribué à l’avenir des habitants de cette planète.

Un hommage qui s’impose à la mémoire d’Alan Turing.

L’image de la Fig.121 n’est que le pâle reflet de l’admiration sans limite que je vous au génie de ce scientifique qui a contribué à faire évoluer de façon considérables les sciences et les techniques de son époque, et qui contribueront encore de nombreuses années à influencer l’avenir de notre Terre. Ce portrait d’une définition dérisoire d’à peine 3584 Pixels codés sur 448 octets permettra malgré tout d’en graver son « histoire » dans du silicium dont l’architecture est son enfant. Pour construire ce petit dessin, le démonstrateur P15_Page_Turing.ino a servi à écrire et peaufiner la table des valeurs qui constituent le portrait en noir et blanc. Deux stratégies pour générer cette image étaient possibles. La première consiste à créer un tableau d’octets qui par nature sera logé dans la mémoire dynamique. Hors, ce que montre la Fig.115, le logiciel de P14 ne laisse entre la PILE et le TAS que 452 octets pour loger les adresses de retour de subroutines et les variables locales. C’est largement suffisant pour assurer la stabilité du programme. Si dans ces 452 octets on en enlève 448 pour loger l’image, il n’en reste plus que quatre ! Bref, cette approche est totalement inenvisageable. Deuxième solution : Imposer à cette table de valeurs d’être incluse dans la mémoire réservée au programme. Cette SDRAM non volatile n’est pas de la RAM et comme c’est le cas pour l’EEPROM ne doit pas être écrite des millions de fois, sa durée de vie étant estimée à 100000 écriture garanties. Il ne faut pas passer son temps à en modifier sans arrêt les valeurs, comme on le fait dans la RAM prévue à cet effet. Il se trouve que notre image est statique, taillée dans le marbre. Aussi, quand après une galère pour coder les 448 octets elle est construite, on n’y touchera plus. (Sauf chaque fois que le programme sera recompilé suite à une modification de son code source.) Inclure la table des PIXELs dans le logiciel consomme 452 octets, et encore, la largeur a été limitée à 56 points. Ce dessin a été largement réduit par rapport à celui du PAPILLON. Puis l’instruction u8g.drawXBMP(0, 0, 56, 64, DessinBitMap); qui écrit les points lumineux dans la matrice de l’afficheur a été ajoutée au programme. Cette instruction prend 340 octets. Ajoutez les trois petits textes avec les instructions de positionnement et les maigres 2% qui restaient sont largement dépassés. Pour optimiser les encombrements, j’ai tenté de diviser l’image en deux. La moitié logée dans le programme et le reste en mémoire dynamique. Peine perdue, car la place gagnée pour le programme est plus que consommée par la deuxième instruction qui elle aussi consomme ses 300 octets. Bref, place insuffisante veut dire : Soit tu oublie, soit tu fais de la place !
Après diverses optimisations d’optimisations sur les optimisations, quelques octets ont été grappillés ici et là. La procédure qui affichait l’écran de la Fig.115 a été enlevée et une ou deux pages sur l’afficheur OLED ont été un peu simplifiées. Enfin le compilateur a accepté de traiter le programme ultime P16_Machine_de_TURING.ino sans afficher l’effroyable texte « Fichier trop gros ».

Le pinceau informatique.

Avec une image de 56 x 64 points on est bien loin de la Joconde, et la misère de la Fig.121 est très loin de représenter celle de la Fig.122 couleur sépia d’une autre époque. Pourtant, pour arriver à ce tristounet résultat la route à emprunter est assez indigeste. Pour compléter les explications données dans le petit livret on va décortiquer sur la Fig.123 les étapes qui conduisent au résultat final. La première phase consiste à créer une image Noir et Blanc qui doit impérativement contenir un nombre entier d’octets en largeur, soit un nombre de points multiple de huit. Pour la hauteur le nombre de lignes peut être quelconque. Ici 64 pour couvrir la hauteur complète de l’afficheur utilisé. La première étape en A consiste à redimensionner l’image pour lui affecter les proportions et le cadrage désiré. Cette épreuve est alors ajustée en largeur en B pour avoir un nombre de points multiple de huit. Ici sept octets soit 56 points. Puis en C on la transforme en équivalent noir et blanc. Jusqu’à ce stade la définition reste tout à fait acceptable. Mais l’afficheur OLED ne gère pas des nuances de luminosité, c’est du tout ou rien. Il faut alors transformer en D ce dessin en BINAIRE. C’est cette phase qui dégrade le plus le portrait qui devient une triste caricature. Quelques retouches manuelles en E permettent de le rendre presque acceptable. On notera que la hauteur a été ajustée aux 64 lignes que peut restituer l’afficheur. On remarque également la bande noire sur la droite. Elle s’impose pour deux raisons : Cette colonne est obligatoirement contenue dans le « multiple de huit ». Elle sera éteinte pour équilibrer les deux cotés du portrait et élargir un peu la zone de droite qui est limite pour afficher le texte souhaité. On repère alors dans le dessin binaire les colonnes d’OCTETS comme sur la Fig.124 par des bandes de couleur. Puis sur la Fig.125 on retourne horizontalement chaque bande verticale car l’afficheur travaille sur des plages « imbriquées ». Enfin, manuellement, ligne à ligne on analyse PIXEL par PIXEL pour coder les octets successifs, travail assez épouvantable qui justifierait pleinement l’usage d’un microcontrôleur pour l’automatiser. Sur le logiciel « définitif », la version du programme est obtenue avec le BP3 dans le MENU de BASE. Par ailleurs le texte de la Fig.99 est actuellement remplacé par celui de la Fig.126 plus approprié. On constate en compilant P16_Machine_de_TURING.ino que pratiquement 100% de l’espace dédié au programme est utilisé. Il ne reste que quatre octets non utilisés coté rentabilité on ne peut pas faire bien mieux ! Cher Alan … on te devait bien ça !

 

La suite est ici.