Des LOGOS À GOGO.
Franchement, s’il avait fallu que je me « cogne » une fois de plus la saisie OCTET par OCTET des valeurs pour coder le dessin en EEPROM, je me serais largement contenté de la petite salamandre. Bien qu’elle ait fichu une panique sans nom dans mes didacticiels, elle reste bien mignone et tout à fait artistique. Néanmoins, il semblerait plus logique pour une station météo, de remplacer cette signature personnelle par un LOGO typé qui suggère une grenouille.
Se construire un dessin « binaire » quelconque pour le faire afficher sur un écran quelconque peut conduire à des tableaux de valeurs importants. Avoir à transformer une image en nombres décimaux devient rapidement infaisable, surtout si le dessin présente une définition « meumeu ».
Toujours dans le cadre de la programmation de loisir, pour automatiser ce genre d’activité, j’ai développé une méthode simple et un programme spécifique proposés sur le lien ici.
Vous y trouverez un fichier de type PDF dont le titre est repris pour ce chapitre. Il n’est pas question de détailler ici toute la procédure. Dans le dossier <Grenouille> se trouvent les croquis qui vont vous permettre d’expérimenter ce didacticiel à part si l’aventure vous tente. Vous y trouverez :
x • IMGtest.bmp qui constitue le dessin EN NOIR ET BLANC que l’on désire comme LOGO.
x • P00_Analyseur_BMP.ino qui sert à analyser le dessin et créer le texte TABLEAU.txt.
x • Pour ceux qui n’ont pas de lecteur de carte SD et qui veulent analyser le contenu du croquis P01_Ecriture_LOGO_en_EEPROM.ino vous y
x trouverez TABLEAU.txt pour comparaison.
x • Quand j’ai décidé de créer le nouveau dessin, P02_Complet_avec_grenouille.ino les nombreuses modifications n’étaient pas encore
x envisagées. Seul le LOGO est modifié par rapport au programme P10_NANO_METEO.ino et donnait le résultat de la Fig.128 en A.
Si vous observez attentivement la version actuelle du croquis en B vous allez certainement constater que la grenouille y est moins « empâtée ». Sa tête est plus fine, les deux membres du haut plus dégagés du corps. En résumé, le dessin a été corrigé. Je peux vous certifier que je ne me serais pas donné ce mal s’il avait fallu réécrire les valeurs numériques du modèle une à une dans le tableau. C’est grâce à la technique automatisée que je n’ai pas hésité à peaufiner mon petit dessin.
Contraintes pour concevoir le nouveau dessin.
Remplacer des PIXELs par d’autres PIXELS dans un programme très avancé et volumineux impose des limites incontournables. La Salamandre est en place. Elle est constituée d’une matrice de 24 lignes de 5 octets soit une taille de 120 octets. Son tableau va de l’indice 0 à 119. Si l’on ne veut pas avoir à changer les textes de place dans l’EEPROM, ce qui impliquerait de revoir toutes les adresses relatives dans les procédures d’affichage, il faut que le nouveau dessin reste dans les limites de 120 OCTETs. De plus, si l’on ne veut pas avoir à développer un code complexe pour faire afficher le dessin, il faut que la taille en largeur soit un multiple de huit.
Définitions possibles (Largeurs x Hauteur) :
5 x 24 octets soit 40 x 24 PIXELs = 120 OCTETs (Salamandre.)
4 x 30 octets soit 32 x 30 PIXELs = 120 OCTETs (Grenouille.)
D’autres définitions seraient possibles mais elles conduisent à des finesses de tracé inférieures ou à des proportions incorrectes. Comme notre batracien est presque carré, le format le plus approprié est celui qui a été adopté. Comme les proportions ne sont plus identiques, les coordonnées d’affichage ont été corrigées. Notez que l’image est inversée verticalement, c’est pour na pas avoir à corriger la séquence d’affichage sur OLED.
C’est petit petit le format 32 x 30 !
