Avec cette étude d’une version n°3 nous allons mettre le doigt dans l’engrenage des affichages numériques avec les avantages qu’ils présentent au point de vue interprétation des valeurs, mais également les nombreuses difficultés qu’ils génèrent par nature. (Instabilité des valeurs, affichage du point décimal, nombre de chiffres significatifs etc.) Les dispositifs optoélectroniques dans ce domaine sont légion. Aussi, dans ce démonstrateur on va expérimenter celui de la Fig.55 qui était disponible dans mes composants « pour faire joujou » et qui impose également une technique de multiplexage.
Bien que la gestion d’afficheurs 7 segments s’apparente à du pilotage banal de LED, il s’en différencie par deux facettes propres à ce type d’applications. D’une part il faut disposer d’une table de transcodage entre les caractères à symboliser et les diodes électroluminescentes à illuminer sur les afficheurs. D’autres part le nombre important de LEDs à piloter dépassant celui des sorties disponibles sur le microcontrôleur et il faut avoir recours à du multiplexage. L’afficheur utilisé dans cette application est un SH5461AS facilement disponible actuellement dans le commerce en ligne. Tout modèle à cathodes communes conviendra. La Fig.56 précise la désignation standard des divers éléments d’un afficheur 7 segments banal. Le brochage du SH5461AS est présenté sur la Fig.57 sur laquelle K1 à K4 désigne les cathodes communes des divers chiffres pris dans l’ordre de la gauche vers la droite. Les 
douze broches sont presque toutes utilisées, et onze E/S seront mobilisées sur Arduino pour piloter cet afficheur. (Le point décimal sera ignoré.) Sur la Fig.57 le composant est représenté vu de dessus comme pour un circuit intégré de type DIL. Électroniquement deux approches sont possibles pour interfacer le SH5461AS. La première consiste, comme montré sur la Fig.58 à porter au potentiel de la masse les cathodes communes avec les sorties de pilotage d’Arduino, et à alimenter en +5v les segments à travers une résistance de limitation d’1kΩ par exemple. Cette approche correspond à celle d’une application réelle. Elle présente l’avantage d’avoir une bonne luminosité de l’afficheur, et surtout chaque segment présente une clarté égale et constante quel que soit le symbole représenté. Si les huit éléments sont allumés, l’intensité que doit fournir la sortie d’Arduino qui pilote Ki atteint 40 mA. Ce courant correspond au maximum toléré par une sortie binaire. Cette solution reste donc compatible avec les limitations de l’ATmega328 et n’impose pas de transistor de commutation par exemple. Par contre, dans le cas d’une simple évaluation, il est tout à fait envisageable de simplifier le montage expérimental. La Fig.59 
décrit le schéma optimisé dans lequel on n’utilise que quatre résistances au lieu de huit. Chaque résistance est intercalée dans le pilotage des cathodes communes. De ce fait le courant maximal pour l’ensemble du « DIGIT » ne dépassera pas 5mA. Ce courant va se répartir dans les divers segments allumés. De ce fait, la luminosité de l’afficheur va varier de façon sensible en fonction du nombre de LEDs actives. Quand le chiffre huit est représenté et que le point décimal est allumé, nous obtenons la luminosité minimale. Elle est maximale quand un seul élément s’éclaire. Pour ne pas surcharger ce segment, on limite le courant total aux 5mA annoncés. Compte tenu du très bon rendement des LEDs de l’afficheur, cette solution simplifiée se justifie pleinement et s’avère très largement suffisante pour développer le programme. Que l’on adopte la solution de la Fig.58 ou celle de la Fig.59 dans les deux cas le programme reste strictement le même. Seuls les courants mis en jeu seront différents en fonction du choix effectué. Le plus économe est naturellement le schéma de la Fig.59 qui en moyenne consomme un courant quatre fois plus faible. Par contre, dans une application pérenne il semble évident que le montage de la Fig.58 s’impose.
Étude préliminaire du détecteur de CO2 version n°3.
Avant de s’aventurer dans le développement logiciel, il faut définir « le cahier des charges » duquel dépend, nous le savons, le matériel à intégrer dans l’application. En première analyse, comme on n’utilise qu’un seul afficheur SH5461AS la carte Arduino NANO présente largement assez de broche d’E/S et nous n’aurons pas besoin de mettre en Å“uvre un circuit tel que le MAX7219. Nous allons gérer nous même le multiplexage directement en C++. On conservera l’équivalent de la LED 13 pour souplesse de programmation, mais dans ce cas elle sera câblée sur A1. La LED blanche sera également employée, mais pilotée par la broche A0. Pour le Mode Manuel, ainsi que l’option du TIC/TAC on peut reprendre les comportements de P09 encore que l’affichage multiplexé risque de s’opposer au battement régulier du petit cÅ“ur dans la boucle de base. Il faudra donc tester la faisabilité avant de définir définitivement le schéma électronique. Comme la LED tricolore n’est plus envisagée, on part sur l’idée de l’affichage montré sur la Fig.60 plus explicite à mon sens qu’une couleur convenue sur une LED tricolore. Si le caractère de gauche n’est pas ‘t‘ ou ‘h‘ c’est que le CO2 est alors présenté à l’écran numérique. Pour toutes les valeurs affichées on négligera les décimales.
Principe du multiplexage et gestion par Arduino.
Pratiquement presque tous les dispositifs qui utilisent des afficheurs 7 segments (Tels que les Horloges numériques par exemple.) utilisent le multiplexage. À l’époque des circuits intégrés logiques c’était pour économiser le décodeur couteux qui transformait un chiffre en son équivalent « segmenté ». Avec les microcontrôleurs, c’est 
pour traduire de façon considérable le nombres de broches d’E/S nécessaires. Dans notre application, il faudrait 4 x 7 = 28 broches, et encore on oublie les quatre points décimaux. L’ATmega328 ne nous propose au maximum que 21 broches et encore, sur la carte NANO. La Fig.61 sur laquelle la température affichée fait 23°C va nous servir d’exemple. Dans une variable nommée TAMPON[4] on a placé le texte « t 23« . On commence par puiser le premier caractère ‘t’ et on le transforme en un binaire B00011110 dans une variable OCTET nommée Caractere. Le poids faible sera toujours zéro et ignoré. Puis cet OCTET colorié en jaune sur la Fig.61 est écrit dans les sept sorties binaires consécutives D7 à D13. Puis, on allume le chiffre de gauche en forçant l’état « 0 » sur la sortie D2 illuminant les quatre segments qui forment le ‘t‘. Après 5mS dans le programme, on éteint l’afficheur en ramenant D2 à « 1« . Ensuite on puise le deuxième caractère dans le TAMPON, on le convertit en espace soit B00000000 et on fait passer D3 à « 0 » pendant 10mS. La troisième cellule de TAMPON vient dans Caractere. C’est le ‘2‘ qui se code B11011010. (C’est le cas montré sur la Fig.61) La sortie binaire D4 soumet la broche K3 à l’état « 0 » pendant 5mS puis repasse à « 1« . Enfin on puise le dernier Caractere dans le TAMPON et l’on valide K6 durant 5mS. On a balayé les quatre chiffres en 20mS. C’est suffisamment rapide pour que la rémanence visuelle nous donne l’illusion d’un éclairement simultané et homogène de l’intégralité de l’afficheur. La période d’un balayage fait 20mS, donc la fréquence de rafraichissement avoisine gaiment les 50Hz suffisamment élevée pour écarter tout phénomène de scintillation.
Le démonstrateur pour affichage sur « 7 segments ».
C’est par le téléversement de P10_Test_du_SH5461HS.ino que l’on va mettre en place la technique de multiplexage des affichages et préparer les routines de servitudes indispensables pour visualiser les valeurs des paramètres HYD, TMP et PPM ainsi que le type des erreurs matériels détectées sur les capteurs. Dans la version n°3 de l’appareil, la LED triple n’est plus utile. En revanche on reprend le TIC / TAC de la boucle de base et le clignotement d’une LED rouge. Avec un clic court on change de thème affiché. Un clic long alterne entre silence et battement du cÅ“ur une fois par seconde. Dès qu’une activation du B.P. arrive à la durée de « clic long », la LED blanche s’allume jusqu’au relâcher et durant tout l’enfoncement le bruiteur fait entendre un son grave.
La gestion des problèmes matériels sur les capteurs.
À l’instar des deux autres versions, le logiciel surveillera les quatre problèmes potentiels sur le DHT11 et sur le MQ135. Ces erreur seront référencées de la n°1 à la n°4 et visualisées comme montré sur la Fig.62 pour deux d’entre elles. Dans le programme d’exploitation de la version n°3 on adoptera les conventions du tableau de la Fig.63 donné ci-dessous :
La suite est ici.