Ajouter un dessin à afficher est l’une des méthodes les plus efficace pour consommer des octets, et ce d’autant plus que l’image est de grande définition. Aussi, comme ce tutoriel vise à couvrir un maximum d’aspect en programmation, j’ai décidé d’introduire dans le chapitre suivant une facette graphique, car pour construire un dessin, l’écran OLED est assez particulier.
Les diverses options possibles sur RESET.
Outre le RESET effectué avec le bouton poussoir activé, option présentée dans le chapitre précédent, si le B.P. est libre, sept options sont émulées en fonction de la position du bouton flèche d’indexation du potentiomètre. Déjà précisé en rouge dans le chapitre 22, la position n°1 correspond au fonctionnement banal avec affichage standard du taux de CO2, qui demeure la motivation de cet appareil. Les autres options sont consignées dans le tableau de la Fig.130 qui liste les divers modes obtenus.
Un petit dessin pour faire joli !
Toujours dans l’optique d’une boulimie d’octets, une page montrée en Fig.131 s’agrémente de la petite salamandre, 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. Dans la pratique, cette fonction montrée en Fig.131 a été écrite avant que le nombre d’échantillons ne soit présent sur la page du mode standard. (Voir la Fig.125) Ce petit dessin va vous permettre d’observer dans le listage du logiciel la façon dont on réalise une matrice graphique sur OLED. C’est assez particulier. Pour comprendre la technique, reportez-vous en page 12 et page 13 du petit livret qui accompagne ce tutoriel. La partie de loin la plus laborieuse consiste à construire la matrice d’octets qui définit la « composition ». Comme je suis très paresseux, je me suis contenté de 
reprendre ici un dessin figurant sur un autre projet, sauf que j’ai utilisé dans cet exemple la technique de la page 13, mais comme le dessin original était petit, la double grandeur a été appliquée pour que le petit animal occupe la majeure partie de l’écran. Du coup la définition est très grossière, car chaque pixel de l’original devient un carré de quatre points ce que la surcharge en rouge met en évidence. Du coup, montré par quelques exemples en violet sur la Fig.132 le dessin est affecté par de nombreuses « marches d’escalier » qui dégradent singulièrement le contour du sympathique batracien. Pour atténuer cette médiocrité de contours, quelques lignes colorées en jaune sur la Fig.132 ont été ajoutées à l’affichage. Comme je cherchais à consommer des octets, passer à une définition deux fois plus grande aurait été logique. De façon très générale, multiplier par deux toutes les dimensions d’un élément augmente sa surface par quatre. Du coup, dans notre cas j’aurais été obligé de réétudier quatre fois plus d’octets, opération tellement indigeste que franchement le courage m’a manqué ! Ceci dit, au moins cette dernière n’a pas la tête cachée par une vis comme sur la façade du coffret, je suis totalement consolé.
Non précisé dans ce qui précède, toutes les options sur RESET allument en violet la LED triple, mis à part on s’en doute la n°1 du mode standard. La sortie de toutes ces possibilités se fait de manière homogène avec un clic long, bien que pour plusieurs un clic court suffit.
Option d’index n°2 : Historique en POLAIRE.
Visualiser l’évolution d’un paramètre quelconque en POLAIRE est une façon assez particulière qui impose à l’observateur une certaine habitude pour interpréter du premier coup d’Å“il. Ce mode de représentation est particulièrement adapté lorsqu’un évènement est fonction de la direction géographique considérée. Par exemple, sur un avion ou un navire en mer le « gisement » sur une trace radar est réalisé en mode POLAIRE. (Polaire : Fait référence au pôle central point d’origine des rayons vecteurs.) J’avoue qu’ici je me suis un peu « amusé » avec les calculs de trigonométrie, car à vraie dire cette fonction n’apporte pas vraiment plus d’informations que l’affichage de l’historique en représentation cartésienne. Quand on fait tourner le rayon vecteur pour situer le point analysé, on obtient dans l’encadré jaune de la Fig.133 la datation relative de l’échantillon ainsi que son ordre dans la mémoire EEPROM. Cette information n’était pas envisagée dans le graphe rectangulaire par manque de place. C’est pourtant une aide bien utile qui … justifie un peu ce « joujou informatique » qui dévore allègrement 312 octets de programme et 28 octets dans les données principalement pour les textes. Presque 4% de la zone programme boulottée, c’est pas mal pour combler le vide !
Chaque clic court dans ce mode fait changer de thème affiché en permutations circulaires. On passe ainsi du CO2 en A, puis de TMP en B et enfin d’HYG en C. Assez typique d’une augmentation linéaire du paramètre visualisé, les courbes A et C sont des spirales linéaires. (C’est normal puisque le point figuratif de la donnée est d’autant plus éloigné du pôle central que la valeur est importante.) Moins évident en B sont tracés des arcs de spirale, la fréquence de variation étant plus grande.
En tête du listage du programme dans la zone des constantes paramétrables, on trouve la directive : #define Aff_PTR 0 équivalent de false. Il s’agit d’un booléen. Si avant de téléverser le code dans l’ATmega328 on le force à 1, équivalent de true, alors on valide l’affichage de l’adresse en EEPROM de la donnée pointée. Ce complément présent sur la Fig.134 n’est utile que pour le programmeur lors du développement, raison pour laquelle dans le croquis que je vous propose le booléen est consigné à false.
Option d’index n°3 : Historique sur ligne USB.
Fonction qui s’approprie 616 octets de programme, soit 4% de l’espace disponible, (Et rien de plus dans les données dynamiques.) cette possibilité peut s’avérer particulièrement utile pour celle et ceux qui voudraient transporter les données de l’historique dans un tableur. En effet, la copie d’écran de la Fig.135 présente la façon dont est présentée l’ensemble des données 
sur la fenêtre d’écran du Moniteur de l’IDE. Dans la pratique les 111 échantillons sont listés en une seule colonne verticale et il faut utiliser « l’ascenseur latéral » pour en explorer toute la hauteur. (La Fig.135 est un montage de trois copies d’écran partielles.) L’une des caractéristiques vraiment très utile de la fenêtre du Moniteur de l’IDE réside dans la possibilité de copier sous forme de textes n’importe quelle zone que l’on sélectionne par balayage avec le bouton gauche de la souris. Quand la zone sélectionnée montrée en bleu convient, [CTRL c] pour la copier et [CTRL v] pour la coller dans un traitement de texte pour en formater la structure, ou dans un tableur. Le transfert des donnée sur la voir série USB est très rapide car programmé à 115200 baud. La façon la plus simple pour obtenir ce listage consiste à brancher l’appareil sur une ligne USB libre de l’ordinateur. Puis ouvrir l’IDE en cliquant deux fois sur un skech quelconque. Placer la flèche du potentiomètre sur l’index n°3. Enfin, cliquer sur 
pour ouvrir la fenêtre du Moniteur. Cette action provoque la vidange des 111 échantillons quel que soit leur contenu. Si un effacement de l’EEPROM a été effectué, il n’y aura que des valeurs nulles. On peut remarquer sur la Fig.135 dans le médaillon rouge une valeur 100 qui décale les nombres. Dans la réalité on n’aura jamais une valeur de 100% pour 
l’hygrométrie. Dans cet exemple les 111 valeurs ont été générées automatiquement d’où cette « incongruité ». Pour que l’on puisse examiner l’historique avant que le programme ne liste en continu les valeurs de CAN, (Conversions numériques potentiométriques.) le logiciel attend un clic long ou un clic court pour revenir au mode standard. Sur le listage USB les nombres sont regroupés par quatre ce qui correspond à la durée d’une journée. Puis toutes les sept lignes est tracée une séparation de tirets pour visualiser la durée « d’une semaine ». Pour rappel, notre appareil ne possède pas un calendrier interne. Toutes ces durées ne correspondent pas à des périodes allant du lundi au dimanche, mais des durées de 24H et de 168H entre ces divers éléments représentatifs.
Réaliser simplement un graphe pour archivage.
Écolo convaincu devant animer une réunion publique sur les conséquences de l’industrialisation à outrance, vous désirez projeter l’influence des activités humaines sur notre atmosphère. Dans ce but vous voulez transformer l’historique préservé en EEPROM en un graphe analogue à celui de la Fig.138 ou sous toute autre présentation. La première étape consiste à copier les valeurs dans le fenêtre du Moniteur comme explicité dans le chapitre précédent. Puis avec la combinaison [CTRL v] on les colle dans un traitement de texte aussi banal que le Bloc notes de Window’s. Dans ce dernier avec Edition > Remplacer … on substitue toutes les virgules par « rien ». Comme je ne sais pas dans Excel traiter des tableaux à deux dimensions, j’ai manuellement provoqué un passage à la ligne pour avoir dans le Bloc notes une seule colonne comme montré sur la Fig.137 donnée ci-contre. Ensuite on recopie ces 111 lignes que l’on colle verticalement dans une colonne du tableur Excel. On sélectionne alors les 111 valeurs de la colonne et on clique sur Insertion > Colonne ou toute autre présentation possible, et avec les protocoles du logiciel Excel ou d’un équivalent on réalise le graphe. Le but de ce chapitre était surtout de vous proposer une piste relativement aisée pour extraire les données de notre appareil et de les formater de façon simple pour les fournir à un tableur.
Option pour la flèche du bouton placée exactement entre l’index n°3 et le n°4.
Logiquement, ce paragraphe vient après la position n°3 et avant l’orientation n°4, bien que cette option soit la dernière qui a été ajoutée pour gloutonner des octets. C’est la raison pour laquelle j’ai opté pour une orientation intermédiaire exactement entre deux index. Cette option n’est donc qu’un amusement informatique pour consommer des octets. Avec ce petit « délire » on explore un domaine assez peu courant en programmation : l’utilisation du générateur de nombres aléatoires avec ici en prime l’emploi d’opérateurs booléens pour générer des points lumineux à des emplacements aléatoires. Ce petit amusement abuse de 606 octets de programme et surtout de 1008 octets de données dynamiques sur les 2048 disponibles. Un vrai « escandale de gaspillage ». Une telle consommation résulte de l’utilisation de l’afficheur OLED. En effet, chaque fois que l’on affiche une page sur son écran, la précédente est automatiquement effacée. Pour avoir une variation rapide de la présence des flocons à l’image, on est obligé de passer par la visualisation d’un dessin qui prend la forme matérielle d’un tableau d’octets dont la gestion ici est très intéressante. Pour couvrir globalement la surface de l’écran on doit gérer une image de 128 x 62 points soit 7936 PIXELs ce qui conduit à un tableau de 7936 / 8 = 992 Octets d’où la place occupée par byte Neige[992]. C’est précisément ce tableau qui se taille une part de lion dans la zone des données dynamiques. Quand cette option est active, un clic long comme prévu fait sortir du mode et retourne au début de la fonction de base. Par contre, un clic court ne fait pas sortir de l’HIVER mais efface sans préavis les flocons et relance immédiatement une tempête de neige. Passons à l’examen de la séquence météorologique :
Dans cette séquence polychrome toutes les instructions de la zone délimitée en bleu seront réalisées tant que l’on ne réalisera pas un clic long. Les instructions comprises entre { et } seront réalisées vingt fois avant chaque rafraichissement de l’écran. Ainsi chaque affichage comportera vingt flocons de plus à chaque fois. Comme l’image comporte 7936 dalles lumineuses, même à ce régime il faut une durée assez longue pour arriver « à du brouillard ». Pour créer des points lumineux en coordonnées aléatoire, le problème vient principalement du fait que l’on ne peut dans le tableau Neige modifier que des octets. Pour comprendre l’algorithme utilisé ici, commençons par analyser le contenu de Flocon au cours du temps. En entrée de procédure il est initialisé à 00000001. Puis, durant chaque boucle for l’octet est décalé à gauche. (Instruction SHIFT : <<.) Le tableau de la Fig.141 précise son évolution au cours du temps. Les sept premiers décalages conduisent à la valeur binaire 10000000. Le décalage suivant provoque 00000000 car lors d’un SHIFT à gauche on fait « entrer » des ‘0‘ à droite. Aussi quand l’octet Flocon devient nul, on le réinitialise à 00000001 et le cycle recommence. Maintenant il faut dans le tableau modifier aléatoirement un octet en lui forçant un BIT à ‘1‘ sans effacer les autres. C’est 
l’instruction qui se trouve dans l’encadré rose qui se charge de cette mission. Elle comporte l’opérateur booléen OU. On exécute un OU logique entre l’ancienne valeur de l’octet de rang Indice et la valeur de Flocon. La Fig.142 propose un exemple. Pour mémoire il convient de savoir que lorsque l’on effectue un OU logique, il suffit que dans l’une des deux données un BIT soit à ‘1‘ pour que celui de même rang dans le résultat soit forcé à ‘1‘. Ces correspondances sont mises en évidence en orange sur la Fig.142 sachant que dans « l’instruction rose » c’est l’octet d’ordre Indice qui est modifié. Hors l’Indice est recalculé à chaque fois par l’instruction jaune et contiendra aléatoirement une valeur comprise entre 0 et 991. C’est donc l’un des 992 octets du tableau Neige qui voit l’un de ses BITs forcé à ‘1’. Si ce BIT était déjà dans cet état, il 
n’est pas modifié. La Fig.143 montre la neige qui petit à petit colonise toute la surface ce qui prouve que le générateur de valeurs aléatoire random() est fiable est arrive à créer une distribution assez homogène des valeurs calculées entre les deux limites qui lui sont imposées en paramètres. Sachez toutefois que si l’on n’impose pas une valeur de démarrage avec randomSeed(VALEUR) la séquence générée sera toujours identique suite au RESET. VALEUR peut elle même être issue de la durée d’enfoncement manuel d’un B.P.
Option d’index n°5 : Les figures de LISSAJOUS.
Célèbre marseillais, Lissajous a étudié la trajectoire d’un point dont les composantes cartésiennes sont sinusoïdales avec des fréquences pouvant être différentes ainsi que leur déphasage. (Représentations nommées aussi les courbes de Bowditch.) Cette option qui grignote 470 octets de programme n’est qu’un divertissement informatique de plus qui nous amène encore dans le domaine de la trigonométrie pour servir de la représentation graphique.
Dans cette option, quand on active un clic court on incrémente d’une unité la fréquence du déplacement vertical. On peut passer ainsi d’un rapport de fréquence de 1 à 10 en permutation circulaire. C’est en classique clic long que l’on sort de cette option. Pour toutes les expériences la phase se modifie et l’on voit « tourner » les lobes sur les graphiques. Sur la Fig.144 la fréquence verticale est quatre fois plus importante que l’oscillation horizontale alors que sur la Fig.145 le rapport vertical sur horizontal est de sept. Sur la Fig.146 c’est le rapport maximal de dix qui est affiché.
Un clic court de plus et l’on revient au rapport unitaire qui est par défaut en entrée de l’option.
Option d’index n°6 : De belles sinusoïdes.
Encore un petit délire d’informaticien pour simuler sur l’écran graphique le graticule d’un oscilloscope dont l’entrée serait en présence d’un signal sinusoïdal avec une base de temps non synchronisée. Il ne consomme que 304 octets de logiciel, car bien plus simple à programmer puisqu’il n’y a qu’une seule fréquence à programmer. Sur la Fig.147 on observe donc la forme ultra classique d’un signal alternatif sinusoïdal pur strictement sans présence d’harmoniques. L’oscilloscope simulé étant supposé non synchronisé, la courbe se décale en permanence vers la gauche. Du reste, cet exemple montre clairement que la définition de l’écran OLED employé est largement suffisante pour ce type d’application, et moyennant de réaliser une interface qui transforme le signal d’entrée pouvant être négatif en variation de tension comprise entre 0 et +5V, Arduino est parfaitement adapté à la réalisation d’un petit oscilloscope numérique. Du reste, on arrive aussi à réaliser un oscilloscope en utilisant un afficheur LCD comme prouvé sur : https://www.robot-maker.com/ouvrages/mini-laboratoire-autonomeatmega328/oscilloscope-numerique/ avec bien entendu de faibles performances.
Avec une EEPROM entièrement saturée, une mémoire programme et une mémoire dynamique consommées à 87% on commence à obtenir une rentabilité raisonnable de notre ATmega328.
Le message d’alerte en orange est très encourageant sur ce point. Rassurez-vous, il ne signifie absolument pas que le programme ne sera pas stable. J’ai déjà produit des logiciel où 100% de la zone programme était utilisée. (Oui, oui, c’est vrai !) Et bien ils ronronnent comme des montres suisses. Si vous compilez avec la version 1.8.0 de l’IDE la taille du programme chute à 23714 octets. Aussi il reste certainement dans les 3836 octets non utilisés largement de quoi ajouter entre les positions n°5 et n°6 une option OSCILLOSCOPE numérique. À votre tour de programmer …
La suite est ici.