05) Optoélectronique : Les afficheurs alphanumériques multiples.

Compte tenu du succès des dispositifs à segments LEDs obtenu dans l’industrie, les fournisseurs ont développé à cette époque lointaine des modules comportant plusieurs « digits » regroupés dans un même encapsulage. Certains sont encore d’actualité. On a rapidement vu « débarquer » des composants doubles, quadruple et même jusqu’à huit éléments dans un boitier unique. Nous allons dans ce chapitre nous contenter de deux exemples ce qui sera largement suffisant pour explorer cette facette de la programmation sur Arduino. Toutefois, comme l’une des expériences implique l’utilisation de deux boutons poussoir, ouvrir un chapitre sur ce type d’interface s’impose en préalable.

Expérience 031 : Clavier à deux boutons poussoir.

Dans ce chapitre nous allons prendre en exemple un clavier élémentaire gérée par A4 par exemple. La Fig.65 reproduit le schéma électrique du dispositif de la Fig.64 (Voir également l’Image 006.JPG) faisant partie intégrante des modules de mise au point de mes programmes. Non représenté sur le schéma, le circuit comporte en plus une LED jaune L avec sa résistance de limitation de courant de 10kΩ. Si le « strap » S est en place, elle indique la présence du +5Vcc. Si on enlève S du petit connecteur HE14 on dispose d’un témoin logique prêt à l’emploi. Bien que dans ce démonstrateur P031 on ne va prendre en compte que deux boutons poussoir, ce thème reste directement utilisable pour des claviers bien plus conséquents, voir des matrices multiplexées de touches. La première source de parasitage dans la lecture d’une entrée analogique vient avec le « bruit alimentation ». Considérons la Fig.66 qui montre l’évolution de la tension alimentation au cours de temps. En théorie l’adaptateur secteur fournit un +5V bien filtré et continu représenté par le trait rouge horizontal. Dans la réalité, à cette tension continue se superposent des variations très rapides que les techniciens nomment « herbe » ou « bruit blanc ». Sur la Fig.66 cette perturbation est considérablement exagérée. (Ou alors l’adaptateur secteur doit être mis à la poubelle !) Même si l’alimentation est parfaite, le +5V du bloc secteur fournit la polarisation par la ligne électrique dans laquelle se trouve la résistance R1 de protection de 1kΩ. Elle est indispensable, car sans elle si l’opérateur clique sur le BP1 on réalise un court-circuit franc entre le +5V et le GND. Cette ligne dans un environnement électromagnétique très encombré capte les parasites hertziens et sera forcément affectée par moment de petites impulsions parasites. Plus la résistance sera de valeur faible, moins ces phénomènes seront présents. À vide, en A la tension est de l’ordre de 4,5V sur A4. Elle chute à 2,5V et la numérisation par le CAN donne la valeur de 419 lorsque l’on clique sur BP2. Cliquer sur BP1 a pour effet de faire un court-circuit entre A4 et GND. Donc quand on cliquera sur le bouton poussoir BP1, A se retrouvera au potentiel nul. Pour minimiser l’influence des parasites captés par la ligne des touches, il suffit de prendre comme seuil de décision la moitié de la tension présente entre celle du repos et celle de l’enfoncement de la touche concernée. Ce qui compte pour le programme, ce n’est pas la tension mesurée, mais le résultat de la numérisation du CAN. Les valeurs seront directement concernées par celles des résistances R1, R2 et R3 qui ont une tolérance de fabrication. (Probablement dans les 5%.) Du coup sur votre prototype elles ne seront pas forcément les mêmes. Pour optimiser le code des expériences qui vont suivre, Experience_031.ino est conçu pour mesurer ces valeurs numérisées et les afficher en permanence à 57600 baud sur le Moniteur de l’IDE. Sur mon exemplaire la valeur à vide est de 939. Cliquer sur BP1 : La numérisation qui devrait en théorie donner zéro tourne aux environs de 7 ou 8. Agir ensuite sur BP2. La tension mesurée aux environs de 2,5V engendre une numérisation de l’ordre de 519. Ces valeurs étant notées, nous allons pouvoir optimiser nos programmes d’application.
Sur la Fig.66 ont été reportées les valeurs numérisées sur le prototype. Pour optimiser le filtrage des parasites on détermine des seuils de décision situé « à la moyenne » des valeurs mesurées. Le premier seuil de décision vaut respectivement 519 + 939 / 2 = 729. Toute numérisation inférieure à cette valeur sera significative de l’activation de l’un des deux boutons poussoir. (Voir la flèche bleue). Le deuxième seuil vaut 8 + 519 / 2 = 263 valeurs portées sur la Fig.66 situant la « frontière » entre BP1 et BP2. Toute valeur plus grande que 263 désignera BP2, (Voir la flèche verte) toute valeur inférieure BP1. (Voir la flèche violette) Ces valeurs optimisées par mesurage seront à préciser par des #define dans les trois démonstrateurs qui vont suivre.

Expérience 032 : Assurer l’anti-rebonds.

Avec P031 on a réglé le problème des parasites hertziens mais il reste à éliminer les rebonds du contact électrique. Quand on bascule la mécanique d’un inverseur ou celle d’un bouton poussoir, on engendre le mouvement de pièces métalliques qui viennent en contact. Électriquement on génère un état « X » sur une entrée analogique ou binaire. Et bien cet état est inutilisable directement. En effet, lorsque deux pièces mécaniques sont « bousculées » l’une contre l’autre, il y a des rebonds mécaniques et l’évolution de l’état logique sur l’entrée concernée ressemble au signal de la Fig.67 qui correspond à un élément de très bonne qualité, car ici le contact ne rebondit que quatre fois lors de l’activation. Les transitoires verts sont représentés par des « durées nulles » car ils se font très rapidement. Si on ne tient pas compte de ce phénomène, alors le logiciel va croire que l’action sur le composant a été déclenchée quatre fois et les traiter en conséquence. Dans la pratique, un interrupteur de qualité va présenter entre dix et vingt « ricochets ». Un composant médiocre peut en générer jusqu’à deux cents voir plus ! Aussi, il faut systématiquement faire de l’anti-rebonds. Parmi les techniques ordinaires, on peut adopter celle de la Fig.68 dans laquelle le traitement peut être effectué juste après le relâcher du bouton poussoir en là ou dès que le clic est stabilisé en ici. L’approche « ici » est en général moins pénalisante en taille de programme, et peut surtout faire gagner un peu de temps en exécution si le composant met du temps à se stabiliser, car ce délai sera en partie « masqué » par la durée du traitement. La stratégie « là » impose la gestion d’un booléen mais autorise l’appel multiple à la séquence de surveillance d’une utilisation du clavier. (P032 utilise là.) Cet organigramme n’explique pas comment se fait l’anti-rebonds. En analysant le code source d’Experience_032.ino, on constate que l’on utilise un COMPTEUR. Chaque fois qu’une mesure signale un état « attendu » il est incrémenté. Si durant le comptage on constate un état « contradictoire », c’est qu’il y a rebond et le COMPTEUR est remis à zéro. Il faut atteindre un nombre de lecture stables égal à NB_tests_antirebonds pour considérer que le contact électrique est stabilisé ou que le relâcher est stabilisé. La valeur affectée à NB_tests_antirebonds est trouvée expérimentalement. Plus le composant est médiocre, plus il faut l’augmenter au détriment naturellement du temps pris par le traitement des « ricochets ». On peut « juguler » un peu ces faux contacts en plaçant un condensateur entre l’entrée logique et GND mais je ne le fais que dans des cas particuliers car ce sont des composants en plus à ajouter à la circuiterie électronique. Chaque fois que l’un des deux boutons poussoir est cliqué, le démonstrateur le signale à 57600 baud sur le Moniteur de l’IDE et précise lequel. Avec NB_tests_antirebonds = 50 le fonctionnement pour le petit clavier de la Fig.64 est parfait et la boucle de base, donc sa prise en compte est très rapide. Pour votre programme il faudra mettre à jour les deux #define en ligne 13 et en ligne 14.

Expérience 033 : Quatre actions différentes avec seulement deux B.P.

L’expérience montre que très souvent une petite application n’a pas besoin d’un grand nombre de touches sur le clavier. Il m’est arrivé souvent ne n’installer que deux boutons poussoir comme montré sur la Fig.65 alors qu’il y avait quatre fonctions à gérer dans l’application. C’est tout à fait possible en faisant appel à la notion de clic court ou de clic long. Cette technique est applicable quel que soit le nombre de touches du clavier. Il suffit de chronométrer la durée du clic … et chronométrer on sait faire ! Dès qu’elle dépasse un seuil déterminé expérimentalement, le clic sera considéré comme long. Pour mettre en œuvre Experience_033.ino il n’y a strictement rien à modifier électriquement. On téléverse le « Sketch » et on se contente de cliquer sur BP1 ou sur BP2. Comme pour P032 le démonstrateur le signale à 57600 baud sur le Moniteur de l’IDE, précise lequel est activé et en plus indique si c’est un clic court ou un clic long. C’est alors le programme qui gèrerait l’action à conduire en fonction du désir de l’utilisateur. Noter qu’en ligne 16 la déclaration de la constante T_pour_Long permet d’adapter à votre guise le délai à partir duquel vous désirerez que c’est un clic long. N’aller surtout pas croire que le schéma de la Fig.65 est le seul possible. Par exemple sur la Fig.69 on trouve une variante dont le courant permanent passe de 417µA à 238µA. Plus économe en énergie il fonctionne également très bien. Naturellement les seuils sont alors à revoir et l’agencement de Tester_entree_A4() est à réécrire. Maintenant que l’on sait gérer un petit clavier à deux boutons poussoir, on peut passer à l’application suivante qui enfin en arrive à l’utilisation d’un afficheur 7 segments double.

Expérience 034 : Retour sur la génération de nombres aléatoires.

Quand nous aurons résolu le problème de la génération de nombre vraiment aléatoire, alors il sera possible d’envisager la gestion par ordinateur d’un jeu de LOTO. C’est la première expérience qui sera effectuée en utilisant un afficheur de type 7 segments à deux digits.
Principe du jeu du LOTO : Chaque joueur est muni de cartons de LOTO et de pions. Un numéro est tiré aléatoirement parmi 90 boules. Le joueur place un pion sur les cases de ses grilles imprimées à ce numéro. Le premier joueur qui à l’un des ses cartons entièrement rempli gagne le lot mis en jeu. On conçoit aisément qu’informatiquement on pourra présenter le résultat d’un tirage sur un afficheur à deux digits. Le principe consiste à générer un nombre aléatoire compris entre 1 et 90. Nous avons déjà rencontré ce thème dans le démonstrateur P021. Toutefois, il importe ici de détailler le comportement de l’instruction random. Cette fonction retourne une très très longue suite de nombres compris dans la fourchette imposée. Le même nombre va donc sortir plusieurs fois comme on peut l’observer sur la Fig.70A qui montre une partie de la séquence générée par random(90). La fonction retourne les valeurs comprises entre 0 et 89. Pour émuler un tirage LOTO on se contente d’incrémenter la valeur d’une unité. Comme au LOTO une boule ne sort qu’une seule fois, il faut impérativement filtrer les résultats et ne garder la valeur retournée par random(90) que si elle n’est pas déjà rencontrée. C’est le rôle du tableau de booléens Deja_sortie[90] qui est entièrement rempli de false au début d’une partie. Chaque fois qu’une boule est tirée, on commence à vérifier si dans le tableau sa « position » n’est pas à true. Si la cellule est à false, alors le tirage est valide. Le numéro de la boule est affiché et son indice dans le tableau est passé à true. Si la cellule est à true, la boule est un doublon et on recommence le tirage jusqu’à en trouver une valide. Rassurez-vous, même si le logiciel doit faire un grand nombre de tentatives, ça reste extrêmement rapide. Dans le démonstrateur Experience_034.ino on compte les boules sorties. Quand toutes sont rencontrées, il n’y a plus de tirage possible et l’on doit recommencer une partie même si personne n’a gagné. Comme invité à l’écran provoquez plusieurs RESETS. Vous allez constater que c’est toujours la même séquence montrée en Fig.70B qui est générée … le LOTO est truqué !

Expérience 035 : Générer un nombre vraiment aléatoire.

Tricherie interdite ! Il n’est pas question d’utiliser un logiciel pour un jeu de LOTO qui se comporterait comme celui de P034. Il suffirait alors de sélectionner dans les grilles celle qui serait la première remplie et vous gagneriez à tous les coups le premier lot mis en jeu. Fondamentalement il faut trouver un moyen pour que la très longue séquence générée par des appels successifs à random() ne soit jamais la même. Hors tout ordinateur est une machine 100% déterministe, c’est à dire qu’il fonctionnera à chaque démarrage de façon strictement identique. Il faut introduire un phénomène vraiment aléatoire. C’est finalement très simple car prévu dans le langage C++ d’Arduino avec la fonction randomSeed(Entier) qui impose à la fonction random() de commencer sa séquence à la valeur de position Entier. Il suffit de générer un nombre Entier vraiment aléatoire et le déterminisme du programme sera contourné. La Fig.71 résume la séquence d’initialisation d’Experience_035.ino qui assurera une génération de boules vraiment aléatoire. En (1) le programme invite l’opérateur à cliquer sur l’un des deux boutons du clavier. En (2) un COMPTEUR est mis à zéro. En (3) tant qu’un BP n’est pas cliqué COMPTEUR est incrémenté en (4). Cette séquence est ultra rapide est en permanence COMPTEUR recycle entre zéro et 65535. Dès qu’un BP est activé (Puis relâché.) en (5) la valeur de COMPTEUR sert à indiquer la « borne » de début de la génération des nombres aléatoires. En (6) la partie peut alors commencer. Tester cet algorithme en faisant plusieurs RESETS. Cette fois ce n’est jamais la même suite.

Expérience 036 : Dernier test avec le générateur de nombre aléatoires.

C’est promis, prochaine expérience on jouera vraiment au LOTO avec affichage du tirage des boules sur afficheur à sept segments. Dans le document SYNTAXE à imprimer.pdf en page P19 il est précisé : « La séquence génère une suite de valeurs aléatoires très longue ». Je n’ai pas été capable de trouver sur Internet combien de valeurs elle va « calculer » avant que la suite ne recommence identique à elle même. Beaucoup ? Très Beaucoup ? Très très méga-Beaucoup ?
Pour le savoir, le mieux consiste à se concocter un petit logiciel pour le déterminer. C’est précisément le but d’Experience_036.ino pour laquelle il n’y a rien à brancher. On téléverse cet automatisme aveugle et on observe le résultat sur le Moniteur de l’IDE toujours initialisé à 57600baud.
Ce logiciel permet de déterminer combien de tirages doit effectuer la fonction random avant de générer une séquence qui recommence identique à elle même. La Fig.72 présente un montage réalisé avec plusieurs copies d’écrans générés par P036. En rose la séquence servant d’empreinte pour la reconnaissance d’un clone. En A on constate qu’il faut 18993 tirages pour retrouver une « copie » à deux chiffres. Pour une séquence de trois caractères identiques en B il faut 183 fois plus de tirages. En C la durée de traitement avoisine les cinq minutes, car c’est encore 11 fois plus de tirages qu’il faut effectuer avec quatre chiffres dans la séquence. On observe que la durée de traitement ne grimpe pas de façon linéaire, les temps mesurés augmentent de façon considérable. C’est l’histoire « du grain de blé sur l’échiquier ». Cette « explosion du chronométrage » résulte du fait que le nombre de tests augmente significativement chaque fois que l’on ajoute un chiffre à la séquence, et la durée des comparaisons augmente aussi puisqu’à chaque test il y en a une de plus. Par exemple avec seulement cinq chiffres examinés en D on passe à une durée de plus de 24 heures de traitement ce qui n’est plus du tout dérisoire, malgré la rapidité d’exécution du code compilé. Pour que vous puissiez vous amuser à changer la taille de la séquence, cette dernière est paramétrée en ligne 18 du programme. Comme il n’est pas question de monopoliser un ordinateur durant des heures si l’on veut tester des séquences plus longues, sur un RESET les données sauvegardées en mémoire non volatile EEPROM lors du dernier test effectué sont affichées sur le Moniteur de l’IDE initialisé à 57600 baud. On peut ainsi faire fonctionner le programme durant une très longue période alimenté par un petit bloc secteur vers USB. Quand la LED Arduino ne clignote plus, c’est que le traitement est terminé et à sauvegardé les données en EEPROM. On branche alors la carte Arduino sur une prise USB de l’ordinateur et sur le Moniteur de l’IDE on télécharge le résultat mémorisé par un simple RESET manuel. En ligne 18 on peut paramétrer le nombre d’éléments identiques pour effectuer les tests. Aussi, pour effectuer un nouvel essai, vous modifiez à votre guise le #define Nb_Echantillons en ligne 18 du démonstrateur P036 et vous observez « en direct le résultat » sur l’écran vidéo.
ATTENTION : Avec 2 clones c’est rapide, avec 4 c’est encore raisonnable, mais avec 5 à raison d’un tirage par seconde il faudrait jouer pendant plus de 49 ans ! Alors vous pouvez tenter « sur secteur » des séquences plus « grassouillettes », mais le temps de clignotement risque rapidement de devenir FARAMINEUX. C’est démontré, random est fiable pour générer des nombres aléatoires.

Expérience 037 : Un LOTO électronique.

Chic chic chic, on va enfin pouvoir jouer et gagner le gros jambon de pays! Nous disposons de tous les ingrédients pour concocter notre programme qui utilisera un clavier à deux touches comme celui du schéma Fig.65 expérimenté avec P032. Chaque action sur BP1 engendrera le tirage d’une boule, alors que BP2 permettra de recommencer une partie. Comme on désire un programme « qui ne triche pas », la première touche utilisée initialisera avec l’instruction randomSeed le générateur de nombres aléatoires, puis effectuera un premier tirage.

Avec l’afficheur LTD-6910HR montré sur la Fig.73 on ouvre le débat. Cette référence « trainait » dans mes tiroirs, avec une kyrielle d’autres compères de même acabit. Tous ont des points communs. Si j’ai opté pour ce modèle, c’est qu’il va nous servir d’introduction à l’expérience qui suivra. La Fig.74 propose son brochage ainsi que les liaisons à effectuer avec Arduino. Vous pouvez consulter ses caractéristiques dans le fichier LTD-6910HR.pdf disponible dans le dossier <Documents>. Vous constaterez qu’il s’agit d’un modèle à Anode commune imposant un pilotage en logique négative. (On est donc dans un exercice de révision.) Comme pour l’expérience de P030 il va falloir « jongler » un peu avec les sorties binaires. Pour simplifier, ici les points décimaux ne seront pas utilisés. Par ailleurs, le numéro d’une boule devra subir une dichotomie pour être présentée sur deux digits séparés ce qui ne simplifie pas le traitement. Je vous invite fortement à consulter la procédure Separe_deux_digits() pour voir comment est réalisé cette « coupure ».

Expérience 038 : Quatre digit dans un boitier.

Encapsulé dans un boitier de 50mm x 19mm l’afficheur SH5461AS en Fig.75 est nettement plus « bavard » puisqu’il intègre quatre afficheurs sept segments broché en norme DIL à 12 broches. Bien que la gestion d’afficheurs 7 segments s’apparente à du pilotage banal de LED, il s’en différentie 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 LED à 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 dans le commerce actuellement. Tout modèle à cathodes communes conviendra. La Fig.76 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.77 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 toutes utilisées, c’est le nombre d’E/S qui seront mobilisées sur Arduino pour piloter entièrement cet afficheur. Sur la Fig.77 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.78 à porter au potentiel de la masse GND les cathodes communes. Le pilotage en +5v par Arduino des anodes des segments se fait à travers des résistances de limitation de courant 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.79 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 Ki. 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 LED 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 LED de l’afficheur, cette solution simplifiée se justifie pleinement et s’avère très largement suffisante pour développer le démonstrateur. Que l’on adopte la solution de la Fig.78 ou celle de la Fig.79 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.79 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.78 s’imposerait.

Principe du multiplexage.

Pour réaliser un afficheur identique avec deux composants LTD-6910HR de l’expérience précédente et pouvoir se servir des quatre points décimaux, il faudrait mobiliser 18 x 2 broches d’E/S sur l’ATmega328. Hors la carte Arduino UNO n’en fournit au maximum que 20 obligeant de surcroit à se servir de D0 et de D1 ce qui complique le travail. C’est grâce au multiplexage qu’avec seulement 12 broches on gère les quatre digits. Ce nombre est largement compatible avec une carte Arduino. Pour expliciter le principe du multiplexage nous allons raisonner sur un exemple concret. Supposons que nous désirions, comme envisagé sur la Fig.80, afficher les quatre premières lettre du mot bonJour. (Nous savons qu’avec seulement sept segments on doit mixer les majuscules et les minuscules.) La technique consiste à n’allumer qu’un seul DIGIT à la fois et de balayer rapidement et en permanence les afficheurs. Le sens est arbitraire mais généralement on active les DIGITS de la gauche vers la droite. Sur la Fig.80 on envisage le traitement du segment central G. Les anodes de tous les segments G sont réunies à l’anode commune G. Toutes les cathodes d’un DIGIT individuel sont réunies à son pilotage Ki. Le balayage commence par mettre un « 1 » sur G, et des « 0 » et des « 1 » sur les autres segments pour compléter la lettre. Puis K1 passe à « 0 » pour allumer le DIGIT 1. Après un court délai, K1 repasse à « 1 » pour éteindre le DIGIT 1. On continue avec un « 1 » sur G, des « 0 » et des « 1 » sur les autres segments. Puis K2 passe à « 0 » pour allumer le DIGIT 2. Après un court délai, K2 revient à « 1 » pour éteindre le DIGIT 2. On fait pareil avec le DIGIT 3. Enfin on termine avec le DIGIT 4 sauf que pour lui c’est un « 0 » qu’il faut mettre sur G, car pour la lettre ‘J‘ le segment G doit être éteint. Quand un cycle est terminé, on recommence tant que le texte ne doit pas changer. Comme nous l’avons déjà précisé avec P006, si la fréquence de balayage dépasse les 40Hz on a l’impression que l’affichage est permanent.

Avantages et inconvénients du multiplexage.

L’avantage est évident. Avec peu de broches de pilotage on gère un grand nombre de digits. Le problème résulte de la valeur du rapport cyclique, notion abordée avec le démonstrateur P005. Il est inversement proportionnel au nombre de DIGITS. Avec quatre caractères le courant moyen est quatre fois plus faible. Pour retrouver la luminosité d’une alimentation constante il faut donc multiplier le courant impulsionnel par quatre. Avec huit digits ou plus on peut arriver à des courant crêtes qui dépassent les intensités autorisés sur les sorties binaires d’Arduino. C’est la limite principale à l’usage du multiplexage sous cette forme.

Passons à l’Experience_039.ino qui consiste à émuler sur notre afficheur SH5461AS un chronomètre. Dans cette manipulation on va retrouver un asservissement en logique positive, c’est à dire qu’il faut appliquer des états « 1 » sur les segments à allumer. Qui dit asservissement impose la présence de capteurs qui ici se résume au petit clavier à deux boutons poussoir de la Fig.65 ce qui est largement suffisant pour notre application :
• BP1 : MARCHE / ARRÊT.
• BP2 : Remise à 0.00.0.
• Sur RESET le chronomètre est « immobile » et affiche 0.00.0.
• Chaque déclenchement est cumulatif, c’est à dire que le comptage reprend sans remise à zéro.
• La capacité maximale est de neuf minutes et provoque l’arrêt automatique du comptage. Il suffit de remettre l’appareil à zéro avec BP2 pour pouvoir reprendre le chronométrage avec BP1.

NOTE : Lorsqu’un programme gère entièrement un affichage multiplexé, le balayage des DIGITS devant être rapide et permanent, le processeur passe son temps à cette action dans la boucle de base. Les autres fonctions ne doivent perturber que peu de temps void loop() car durant leur traitement l’afficheur est entièrement noir pour éviter une « intensité crête » en permanence.

Expérience 039 : Un journal défilant.

Pour ce démonstrateur on continue à mettre en œuvre l’afficheur SH5461AS de la Fig.75 avec comme avantage de ne strictement rien modifier au câblage précédent. Si le petit clavier reste branché, il sera purement ignoré. Ce démonstrateur utilise la ligne série du Moniteur de l’IDE pour assurer l’interface Homme/Machine. On se contente d’initialiser à 57600baud la vitesse de transmission. On frappe une phrase quelconque dans le champ de saisie. On peut aussi s’amuser à copier du texte sur l’écran vidéo de l’ordinateur et de le coller avec [CTRL V] en fenêtre contextuelle de saisie. Quand on le valide, ce texte défile lentement sur l’afficheur et chaque étape de décalage d’un caractère est listée ligne à ligne sur le Moniteur. La police des caractères permet d’afficher les dix Chiffres et les lettres ainsi que certains caractères de ponctuation. Quel que soit l’état de la lettre saisie, nous savons que sur un afficheur 7 segments on doit mélanger majuscules et minuscules. Il en résulte que ‘W’ et ‘Z’ ne sont pas très beaux. Les caractères ignorés sont remplacés par des ‘-‘ pour prévenir le lecteur. Chaque saisie continue à « pousser à gauche » le texte déjà présent. Pour vider entièrement l’afficheur frapper un ‘@‘. Le « + » n’est pas traité. Les lettres accentuées sont filtrées et remplacées par leur équivalent simple. Si la chaîne saisie est très longue, seuls les 60 premiers caractères seront pris en compte, les autres seront ignorés. Pour montrer un exemple, sur la Fig.81 le texte « bonJour » est photographié à deux stades de son affichage. Téléversez Experience_039.ino pour vous amuser avec cette petite application. C’est la dernière expérience avec des afficheurs de type 7 segments.

Expérience 040 : « Retour » sur les 16 segments.

Retournons un peu dans le passé avec ce démonstrateur. La technologie de pointe pour afficher des informations en était alors à l’avènement des afficheurs à LEDs qui ont fait l’objet des exercices précédents. Les composants genre LCD ou à LEDs n’étaient pas encore créés. Pour les chiffres il y avait les tubes NIXIE tels que celui de la Fig.82 ou ceux de la Fig.7 mais ces technologie imposaient des tensions élevées de l’ordre de 150v et les chiffres étaient les uns derrière les autres. Ajouter 26 lettres aurait engendré un masquage mutuel exagéré. Pour les textes importants il y avait bien le bon vieux tube cathodique qui équipait les téléviseurs et les moniteurs vidéo de l’époque, mais il s’avérait « énorme et goinfrivore » en énergie.

Imaginez d’associer 16 afficheurs du type précédent. Avec un rapport cyclique de 0,06 bonjour le courant impulsionnel. Pour une luminosité normale, c’est 40 x 16 = 640mA que devrait piloter la sortie du microcontrôleur ! C’est dans ce contexte que les afficheurs à gaz tel que celui de la Fig.83 ont vu le jour. Cette technologie qui en 2024 semble poussiéreuse présentait pourtant de sacré avantages à son époque. Ces tubes à gaz n’exigeaient que 24v pour s’ioniser. D’une consommation dérisoire ils présentaient une très grande luminosité et s’avéraient pratiquement inusables lorsqu’ils étaient en fonctionnement 24 heures sur 24. Avec seulement 33 broches, on doit piloter pas moins de 256 segments élémentaires.

On se doute que la solution réside dans le multiplexage. Pour ne pas « enliser » le microcontrôleur dans une boucle qui ne fait que balayer l’affichage, l’industrie a créé un circuit intégré spécifique qui se charge intégralement du pilotage de l’afficheur à gaz de type Futaba 16-LY-01 (Z). Encapsulé dans un boitier DIL 24 broches le MIC10937-P se charge intégralement du multiplexage et se pilote par une ligne série à seulement deux fils : Un pour l’horloge de synchronisation, l’autre pour les données. (Avec en outre, on s’en doute, GND.) Les caractères à afficher sont codés en ASCII.
(Pour le code ASCII voir la Fiche n°1.) Sa description technique est fournie dans le fichier MIC10937.PDF rangé dans le dossier <Documents/Composants>. Il intègre le générateur de caractères mais ne visualise que les lettres MAJUSCULES ce qui est un peu dommage.

Un chtipeu d’histoire.

C’est en 1983 que dans la revue ELEKTOR la description d’un fréquencemètre utilisait l’afficheur à gaz 3 sur la Fig.84 associé à un KIT commercial fournissant le transformateur 7 et le beau circuit imprimé 8 qui est autrement plus fin que le mien en 9. À cette époque je programmais en langage machine, c’est à dire en assembleur. Je n’avais aucune idée de l’application qui utiliserait ce module d’affichage. Aussi, bien que ne consommant qu’un courant dérisoire sur le +5Vcc, j’avais réalisé une alimentation pouvant débiter 3A … pour le cas où. À cette époque, le summum de la technologie résidait dans les régulateurs intégrés tripolaires 10 associé à un redressement du courant par pont de diode et filtrage par condensateur réservoir 11. Ça chauffait beaucoup d’où le radiateur 12. Ayant développé les programmes pour un microprocesseur 6805, le module étant relié avec des « pinces crocodiles », j’ai tout rangé dans une boite … et oublié ces éléments. Entre temps les afficheurs LCD et compères à LEDs sont venus bousculer l’électronique d’amateur et je suis passé à autre chose. Et puis en 2024, pour le plaisir et dans le cadre de ce didacticiel j’ai décidé de reprogrammer en langage C++. Du coup, j’ai réalisé le montage expérimental de la Fig.84 pour travailler dans un contexte matériel sérieux. J’ai donc récupéré les anciens modules et utilisé mon alimentation d’atelier pour fournir le 24V régulé que je branche en 5 et 6. (Environ 150mA.) J’ai en complément réalisé à la sauvette le petit circuit imprimé avec en 1 le connecteur HE14 de liaison avec Arduino, en 2 une LED pour le +5Vcc et en 4 une pour le 24Vcc.

Reprenant les repères des schémas de la documentation avec un rappel sur la Fig.86 de la désignation des segments, la Fig.85 fournit le schéma électrique à réaliser. Il est évident que s’il s’agit d’afficheurs à LEDs tel que celui de la Fig.57 il faudra diminuer la tension VDISP à 5V et revoir les valeurs des résistances à la baisse pour fournir aux LEDs des courants suffisants. C’est VSS qui reçoit le +5Vcc et le négatif de cette alimentation régulée qui sert de référence à GND d’Arduino. Les autres tensions sont à fournir conformément à la notice du fichier MIC10937.PDF.

Après avoir téléversé Experience_040.ino qui est relativement bien documenté l’utilisation est facile. Il suffit dans la fenêtre de l’IDE d’activer avec sa « puce dédiée » le Moniteur, et de l’initialiser à 57600baud. Puis dans sa fenêtre contextuelle de frapper librement du texte, voir de procéder par du Copier / Coller. Le logiciel filtre la saisie et transforme les accentués ainsi que le ‘ç‘ en équivalents simples. Les lettres minuscules sont converties en majuscules. L’apostrophe et les ponctuations de base sont acceptées. (Voir en page 7 la police de caractères interne au MIC10937-P.) Lorsqu’une virgule ou un point décimal est saisi, il ne provoque pas de décalage sur l’afficheur et P040 le traite correctement ce que montre la Fig.87 en A. Par contre le caractère tout à droite n’affiche pas le point décimal observable en A , sur la Fig.88 et en B. Sur cette copie d’écran le texte original affiché entre crochet est colorié en vert pastel. Le texte filtré par le démonstrateur est placé entre ‘<‘ et ‘>‘ et mis en évidence en violet clair. On voit bien que dans les deux exemples la dernière lettre a été saisie suivie d’un point décimal qui n’est pas présent sur Futaba 16-LY-01. Si la ligne saisie contient moins de 16 caractères, l’affichage est complété automatiquement par des ESPACES. (Pour éteindre entièrement l’afficheur il suffit d’envoyer un espace.) Si la ligne de saisie contient plus de 16 caractères, le surplus sera purement et simplement ignoré. Pour le plaisir et conclure ce chapitre « du passé », vous pouvez consulter quatre photographies donnant des exemples avec les photographies Image 008.JPG à Image 11.JPG disponibles dans le dossier <IMAGES>. Avec ce dernier démonstrateur, nous allons quitter le domaine des afficheurs individuels à LEDs pour enfin profiter des technologies qui ont suivi, c’est à dire des afficheurs orientés textes et chiffres en lignes sous forme de segments ou de matrices de points. C’est précisément le but des quelques expériences qui vont suivre.

La suite est ici.