C’est un phénomène bien connu, la richesse pousse l’individu à dilapider. Plus cette dernière est importante, plus l’on gaspille. C’est vrai dans la vie de tous les jours, mais aussi en programmation et ce projet va dans ce domaine montrer un exemple scandaleux de plus !
L’exemple à ne surtout pas suivre !
Créer un dessin sous forme d’une matrice de nombres que l’on intègre dans un programme est à proscrire car la consommation en ressources du microcontrôleur est « catastrophique ». Dans ce projet on peut se le permettre car le programme d’utilisation est terminé et qu’il reste encore 30% d’espace disponible pour le programme et la moitié de la RAM dynamique pour les données. Donc on peut dilapider, ce qui dans ce contexte ludique va nous permettre d’aborder la facette graphique de l’utilisation d’OLED qui dans ce domaine est très particulière. Pour ce petit cheminement complémentaire, on va développer P18_Page_de_garde_avec_LOGO.ino qui ajoute le petit dessin de la salamandre quand on affiche la version du logiciel. Cette dernière étant mon avatar graphique pour toutes mes prestations sur l’Internet. Cette signature s’insinue partout y compris en filigrane dans les pages de textes qui manquent d’images ou en bas de page pour proposer un amusement et alléger tous
ces propos trop sérieux pour une activité de loisir.
La toute petite salamandre.
Contrairement à ce qui avait été envisagé dans le chapitre Un petit dessin pour faire joli ! avec la Fig.10 donné en page 6, ici on ne double pas la taille de l’image. Pourtant, comme le prouve la Fig.138 elle agrémente singulièrement la page de présentation de la version du logiciel. Bien qu’elle soit discrète, elle empêche d’afficher « USB =  » du coup six caractères redeviennent disponibles en EEPROM. Pour ne pas les perdre, ils ont été récupérés et remplacés par le texte « signal » qui va faire économiser autant de caractères dans le programme. Attention, maintenant dans les démonstrateurs précédents le texte de la page de garde est faussé et affiche « signal57600baud« . Comme c’était le cas pour la version de taille double, pour générer le dessin on s’en tient à un nombre d’octets entiers. Pour économiser des données dans la matrice, la queue du petit animal est complétée par le tracé repéré en rouge sur la Fig.139 obtenu par deux lignes verticales.
Coder une image pour l’afficheur OLED.
Procédure spécifique au composant utilisé, l’instruction u8g.firstPage() commence par remplir la matrice d’affichage de « 0 » c’est à dire de PIXELs noirs. Ensuite, par les instructions graphiques on va y loger des « 1 » qui allumeront les pavés relatifs. Par exemple utiliser l’instruction u8g.drawLine(XA,YA,XB,YB) va inscrire des « 1 » pour les PIXELs de la mosaïque qui sont sur la droite qui joint A et B. 
Pour écrire un dessin sur cette mosaïque la première opération consiste à transformer le portrait de Bubule (Qui a accidentellement été mangé par le chat mais vous vous en fichez.) en une matrice de carrés noir et blancs comme représenté sur la Fig.141 en supposant sur cet exemple qu’OLED de faible définition ne comporte que huit PIXELs de large et quatre lignes de haut. Notre dessin construit sur une grille dont l’étendue représente la grandeur du dessin occupant l’afficheur doit maintenant être transformé en une matrice binaire comme celle de la Fig.142 ou chaque point allumé contiendra un « 1 » et chaque point éteint sera codé par un « 0« . Jusqu’ici c’est assez évident, toutefois il est impératif à ce stade d’ouvrir en page 12 et page 13 le petit livret Bibliothèque U8glib.pdf qui accompagne ce tutoriel. Pour envoyer les valeurs binaires vers la bibliothèque, on utilise l’instruction facile à comprendre u8g.drawXBM(11, 32, Largeur_du_dessin, Hauteur_du_dessin, Salamandre).
Les valeurs 11 et 32 correspondent aux coordonnées de l’angle supérieur gauche de la matrice dans la mosaïque complète de l’afficheur. La Largeur_du_dessin doit correspondre à un nombre entier d’OCTETs. Cette largeur sera donc un nombre multiple de huit. La Hauteur_du_dessin représente le nombre de « lignes de PIXELs ». Enfin, Salamandre désigne un tableau de byte où les OCTETs sont codés avec les « 0 » et les « 1« . C’est ici que se complique singulièrement le codage qui doit « découper en tranches de demi-octets » le dessin avec symétrisation verticale. Glups !
Pas de panique, le principe reste assez élémentaire. On commence comme sur la Fig.143 par tracer une grille qui correspond exactement à celle du dessin que l’on désire construire. Normalement, sur la Fig.143 il devrait y avoir cinq octets de largeur. J’en ai représenté que quatre pour que le dessin ne soit pas trop confus. Il devrait y avoir également 24 lignes alors qu’il n’y en a que 21 pour que les carreaux de la mosaïque soient presque carrés. Lorsque la grille est réalisée, on l’imprime en grand sur un format A4 et on trace le contour du LOGO sur cette dernière. Puis, c’est un travail d’artiste, on noirci les cases dans lesquelles passe le contour en minimisant l’effet d’escalier. Il faudra coder par des « 1 » les PIXELS qui sont sur ce contour, ainsi que ceux qui sont à l’intérieur mis à part les yeux du petit animal. On se retrouve avec un carrelage binaire de 40 x 24 dalles l’extérieur en non rempli, l’intérieur noirci au crayon. C’est un peu laborieux car ça représente tout de même 960 carreaux. (Personnellement je ne noirci que le contour extérieur et les mirettes.)
Riche de ce modèle on le cloisonne en huit tranches verticales. C’est maintenant que l’opération devient franchement rébarbative. Il faut coder les « 0 » et les « 1 » en les regroupant par OCTETS sachant que chaque tranche doit être symétrisée verticalement. C’est un travail long et qui exige beaucoup d’attention. Il faut donc l’aborder avec calme et sérénité. Si on désire doubler les dimensions de notre Å“uvre d’art, c’est 3840 BITs qu’il faudra traduire. On comprend assez bien pourquoi on va éviter de se « cogner » une fresque de 3m sur 2m ! Une fois que l’on a transcodé l’ensemble, on aboutit au tableau de byte de la Fig.146 qui est déverminé car vous allez rapidement vous rendre compte que lorsque vous désirerez le remplacer par un LOGO personnel, il va y avoir une foule de petites erreurs dont on a un mal fou à retrouver la position dans ce fatras. Ceci dit, une fois que la matrice est parfaite et que l’on a abouti, la satisfaction est à la hauteur des difficultés rencontrées. C’est à vous maintenant de prendre la palette et le pinceau informatique, et de développer votre propre avatar.
Le prix à payer.
Intégrer un dessin dans un programme n’est pas du tout gratuit et d’autant plus pénalisant qu’il n’est pas logé en EEPROM. À l’instar des chaînes de caractère, il est traduit sous forme d’un tableau. Dans ce projet ce dernier contient 120 bytes , alors la taille du programme enfle d’autant. (Plus les routines de traitement mais l’on ne peut pas s’en passer.) Surtout, comme vous pouvez le vérifier sur la Fig.147 l’espace disponible entre la PILE et le TAS diminue d’autant. Conclusion : Autant que faire ce peut il faut impérativement loger la matrice du dessin dans l’EEPROM pour éliminer ces deux conséquences.
Une grille spécifique à l’afficheur OLED.
Avec les outils graphiques disponibles sur l’ordinateur, il est particulièrement facile de créer une grille de 128 colonnes et de 64 lignes. On ajoute à cette dernière des indications des coordonnées tous les huit PIXELs et l’on obtient le fichier GRILLE pour OLED.pdf à imprimer que je vous livre dans le dossier <Documents>. Il ne faut pas croire que l’on développe des écrans graphiques tel que celui de la Fig.65 par exemple, d’un simple claquement des doigts. Dès que la police de caractères est connue et les dimensions de ces derniers notés, on trace sur la grille de référence les divers cadres dont on optimise les surfaces. Puis on ajoute les textes en vérifiant qu’ils ne débordent ni de leurs encadrements ni des limites de l’afficheur. C’est un travail préalable absolument indispensable sans lequel on va consommer en pure perte un temps considérable lors de la programmation. Vous avez l’outil, à vous de vous en servir …
La suite est ici.
