Restant dans le monde des diodes électroluminescentes, on va dans ce chapitre aborder le domaine des innombrables dispositifs du commerce qui intègrent directement dans un encapsulage plus ou moins normalisé (Brochage au pas de 2.254mm) un nombre très variable de LEDs visant des applications typiques. (Le nombre de LEDs peut aller jusqu’à des millions sur des affichages publicitaire, sur les écrans vidéos, sur les téléviseurs haute définition …) Nous allons nous cantonner dans ce chapitre à des petits produits industriels très populaires et omniprésents en « petite informatique ».
Expérience 011 : utilisation d’un Barregraphe
Étant donné qu’un Barregraphe n’est rien d’autre qu’un ensemble de LEDs insérées dans un boitier unique, la programmation d’une rampe lumineuse n’est pas vraiment différente de celle de plusieurs LED individuelles. Tout au plus le choix d’un composant qui utiliserait des anodes ou des cathodes communes pourrait influencer le branchement électrique et la programmation. (Par exemple obligation de provoquer l’éclairage par un état « 0 » dans le cas d’anodes communes) Ce n’est pas le cas du LTA1000HR montré en Fig.18 dont le brochage est précisé sur la Fig.19, qui intègre dix LED strictement indépendantes. Le schéma électrique sera donc celui de la Fig.14 avec dix branches au lieu de 8, la résistance de limitation du courant restant de 1kΩ . Comme nous avons le choix, les sorties d’Arduino alimentent en fournissant du +5Vcc, donc allumer va se traduire par un état « 1 » sur la sortie binaire concernée. C’est toujours plus « parlant » sur un listage de programme qu’avoir à coder en logique négative. Le démonstrateur Experience_011.ino démontre que si le logiciel n’utilise pas la ligne série pour son application, les broches D0 et D1 sont totalement disponibles pour servir d’Entrées ou de sorties banales. C’est notre premier asservissement qui prend en compte l’environnement et va mesurer et afficher la valeur d’une tension variable sur l’entrée analogique A0 issue d’un potentiomètre. En préambule à l’analyse des particularités de ce programme, je vous invite à observer la photographie de la Fig.20 sur laquelle on voit bien que la LED de la valeur 1 et la LED de la valeur 6 (Pour une plage de dix incréments.) sont nettement moins lumineuses. La raison réside dans leur tension de seuil plus que celle des autres éléments, du coup elles « pompent » un peu moins de courant que leurs voisines d’où leur luminosité moindre. Si on désirait réellement animer une petite application, nous serions obligés de passer au schéma de la Fig.9 avec dix résistances. Ici c’est juste un exercice, aussi le programme reste parfaitement vérifiable et le câblage sur la platine d’essais bien simplifié.
Mesurer la tension en sortie du potentiomètre sur A0 avec l’instruction fondamentale analogRead(Entree_Analogique) fournit dans la variable Mesure de type int une valeur qui sera comprise théoriquement entre 0 et 1023 lorsque la tension variera entre 0 et +Vcc. Comme l’instruction d’aiguillage switch (Mesure) impose des entiers allant de 1 à 10 il faut transposer la valeur de Mesure en effectuant « un produit en croix » traduisant mathématiquement la proportionnalité :
Proportionnalité et transposition de valeurs.
La Fig.21 traduit schématiquement une transposition. En violet la valeur retournée par le CAN de A0 dans la variable Mesure. Cette valeur est multipliée par 10 en 2 et divisée par 1023 en 3. (Dans le programme par 1010 car le CAN ne dépasse pas cette valeur.) Par exemple si le CAN donne 641, on obtient 6,2659 une valeur réelle qui n’est pas acceptable pour Mesure qui est de type int. C’est la raison pour laquelle l’instruction uint16_t transforme le float du calcul en un int avec arrondi qui est ensuite logé dans la variable Mesure. Observez au passage comment les instructions DDRB, DDRD, PORTB et PORT D permettent en C++ de manipuler directement les huit BITs d’un port au lieu de travailler broche par broche sur les sorties binaires. Pour enrichir cette expérience, le démonstrateur transmet les valeurs mesurées et leur transposition sur la ligne série qui permet de dialoguer avec le Moniteur de l’IDE. Il suffit de valider les lignes 18, 25 et 28 dans Experience_011.ino. Puis on active le Moniteur avec son « bouton puce » qui ouvre sa fenêtre contextuelle. On voit alors défiler en permanence la valeur mesurée par le CAN et sa Transposée. ATTENTION : L’affichage ne sera cohérent que si l’option de la vitesse de transmission est bien initialisée à 57600baud. (En bas à droite de la fenêtre.) Noter que la transmission des valeurs perturbe D0 et D1 qui dans l’éventualité de conservation de cet affichage ne devraient pas servir simultanément à piloter le barregraphe. Replacer donc en remarque les lignes 18, 25 et 28 avant de passer à l’expérience suivante.
Transposition avec l’instruction map ().
Avoir à transposer des valeurs est tellement fréquent en microinformatique, que pour effectuer nos « produits en croix » pour calculer des proportionnalités, le langage C++ à mis à notre disposition la fonction map() décrite en page 30 de SYNTAXE à imprimer.pdf. Pour expérimenter cette variante nous n’avons pas grand chose à faire. Il suffit de passer en remarque la ligne 26 et de valider la ligne 28 de Experience_011.ino et constater que le comportement est strictement identique, le programme source étant plus immédiat à lire et à comprendre. Pour terminer avec cette expérience qui nous a permis de balayer un large éventail logiciel concernant le C++, n’oublions pas qu’analogRead() est une fonction qui retourne un entier et qui peut se placer dans toute ligne de programme où un int est attendu. Du coup on peut aboutir à un programme plus compact en remplaçant le couple
Expérience 012 : Chaîner deux barregraphes.
Dispositifs d’affichages linéaires, les composants tels que celui de la Fig.18 sont légion. On en trouve des rouges, des verts, des jaunes et même des polychromes à plusieurs zones. Par exemple le PH QDSP-4822 est encapsulé dans un boitier similaire au précédent mais peint en noir montrant ainsi une grande différence apparente. Dans la pratique il peut se mettre à la place du TLA-100HR et présente un comportement pratiquement identique. L’encapsulation de ces produits industriels est conçue pour pouvoir les placer les uns contre les autres et ainsi former un barregraphe de 20, 30 incréments voir plus si on le désire. Pour tester une telle configuration géométrique on va limiter nos ambitions à deux éléments, étant confinés pour cet exercice à la longueur de la plaquette de branchements. Compte tenu de cette contrainte nous allons revenir à l’automatisme aveugle du lièvre rencontré avec le démonstrateur P007. Par contre, cette fois nous allons gérer les deux modules avec uniquement le PORTD, c’est à dire que D0 à D8 seront suffisantes pour piloter les 20 LEDs. La magie apparente de la technique utilisée réside dans le MULTIPLEXAGE. Le secret de cette technique est dévoilé dans la Fiche n°15 que bien entendu on dévore jusqu’à avoir tout compris. Dans cette manipulation on réutilise la faculté de traiter directement huit broches avec DDRD et PORTD, mais également du travail par broche indépendante avec pinMode et digitalWrite. Rien de bien nouveau, il s’agit de révision des acquis. La subtilité de ce programme réside dans les techniques de balayage matriciel pour effectuer un multiplexage. Le schéma électrique retenu dans Experience_012.ino est celui de la Fig.1 dans la Fiche n°15. Toutefois, ici nous procédons à un balayage dynamique de rapport cyclique 1/20. Il faut donc diminuer la valeur de R à 100Ω pour aboutir à une luminosité normale. Le courant de sortie lors de l’état « 1 » avoisine 30mA parfaitement compatible avec la sortance des broches d’Arduino. La Fig.22 présente un montage graphique obtenu à partir de cinq photographies. Lorsque deux barres semblent illuminées, ce n’est qu’une illusion résultant de la lenteur de la prise de vue. Sur cette expérience les deux afficheurs sont manifestement différents puisque l’un à un boitier gris alors que l’autre est rouge. Idem pour la couleur des segments respectivement verts ou rouge. Et bien que différentes, ces deux références présentent des encapsulations qui permettent l’assemblage corps à corps sur un support au pas standard de 2,54mm.
Expérience 013 : Les Opérateurs LOGIQUES.
Fondement des automatismes ne respirant que du binaire pur et dur, les Opérateurs LOGIQUES sont strictement incontournables et indissociable des Masques logiques. Ils sont prévus pour manipuler de façon individuelles les BITs d’un port d’Entrées/Sorties binaires. On se précipite avec fébrilité sur la Fiche n°17 et la Fiche n°18 et on ne les quitte plus tant que l’on n’a pas tout compris. Le démonstrateur Experience_013.ino qui n’impose aucune modification électrique effectue le même travail que son frère P012 mais en consommant 30 octets de moins tout en étant plus « parlant » pour qui utilise couramment les opérateurs booléens associés à des Masques logiques. Ayant assimilé le contenu des deux fiches dédiées, l’observation du listage de P013 vous fournira un exemple concret d’utilisation de ces outils informatiques orientés binaires.
La Fig.23 représente l’OCTET qui doit être écrit dans D0 à D7 pour effectuer un balayage des cinq Lignes. En vert on observe le « 1 » qui part de la gauche et se décale à droite à chaque changement de LED. Le mot « décalage » est lâché et … s’impose comme outil de traitement logiciel. C’est la première opération qu’effectue la procédure Allume_une_LED() qui reçoit en paramètres les deux Masques logiques pour conditionner les états des colonnes, cases en jaune sur le dessins. Le premier Masque logique permet de forcer les « 1 » avec un opérateur OU alors que le deuxième Masque logique force les « 0 » avec l’opérateur ET.
Expérience 014 : Les opérateurs de décalage.
Faisant partie intégrale de la famille des opérateurs logiques les opérateurs de décalage à gauche << ou à droite >> sont incontournables dans des applications comme celle proposée dans l’exercice précédent. Avec le démonstrateur Experience_014.ino on va traiter un exemple concret de plus. On va matérialiser les informations du bas de la Fiche n°19. Cet exercice supplémentaire n’exige que peu de commentaires. Il s’agit d’un asservissement puisque l’on prend en compte la tension issue d’un potentiomètre situé dans l’environnement du microcontrôleur. La Fiche n°19 traite des variables signées et non signées, l’ouverture d’une parenthèse s’impose :
C’est précisément cette dernière remarque de la parenthèse qui impose la déclaration char Ruban; alors qu’intrinsèquement Ruban est un OCTET dont le représentant naturel serait un byte.
Expérience 015 : Tester une sonde logique.
Développant un programme, il arrive constamment que le résultat obtenu n’est pas du tout celui escompté. Soit, c’est le programme qui comporte une erreur, soit c’est le branchement qui n’est pas conforme au schéma envisagé. (Soit c’est les deux, et déverminer peut alors s’avérer un tantinet indigeste.) Dans notre cas les programmes ont été validés, aussi ce sera forcément le matériel qui est en cause. Pour aider le programmeur, une sonde logique peut s’avérer très utile, et s’en passer serait d’autant plus dommage que c’est un outil véritablement facile à réaliser.
Toujours dans le cadre des automatismes aveugles, Experience_015.ino va nous servir à tester la petite sonde logique et voir divers cas de son utilisation. Pour cet exercice on va se contenter de ne brancher qu’une seule LED sur D6 par exemple, mais pilotée en logique négative. Considérons la Fig.24 traduisant une telle configuration. Ce vocable est utilisé dans le cas d’un effecteur qui est actif lorsque la broche de pilotage est à l’état logique « 0 ». C’est bien le cas ici, mais on va supposer que vous vous êtes trompé et vous allez volontairement placer la LED dans l’autre sens. On constate alors qu’elle ne s’illumine jamais. Problème matériel ou incident logiciel ? La première action à conduire pour lever le doute c’est de brancher la sonde logique sur la sortie en défaut D6. Comme cette 
broche fonctionne en logique négative, autant prendre en compte ce détail et brancher la « pointe LED P1 sur GND et P2 sur D6. Le témoin logique cadence la seconde en couleur verte. Le logiciel est donc correct. Inversez le sens de la LED et tout rentre dans l’ordre. Il serait possible pour cette intervention de brancher de façon classique, P2 sur GND et P1 sur D6. La LED clignoterait en rouge et notre conclusion serait identique. D’une façon plus Générale il serait tout à fait concevable d’utiliser une LED simple à la place de la LTL298 et utiliser un composant plus actuel avec une résistance en série de 10kΩ à 22kΩ chargeant de façon dérisoire la sortie testée. À vous de voir si une diode double est « rentable ». Le cas ou une sonde bilatérale est plus opérationnelle est résumé sur l’exemple de la Fig.25 qui traduit le branchement d’un moteur à courant continu avec en Fig.26 le tableau du fonctionnement attendu. (Deux combinaisons binaires au choix permettent de le mettre au repos.) Pour tester cette disposition, brancher la sonde logique entre les deux sorties D6 et D7. C’est dans un tel cas que la propriété d’être bicolore présente un avantage. Noter au passage que la Fig.25 est incomplète, car il faudrait y ajouter des diodes de « roue libre » dont il sera question quand on abordera les exercices sur la motorisation. Enfin, P2 sur GND tester P1 sur D0 jusqu’à D4. Sur D0 l’éclairement semble constant, car le clignotement se fait à 50Hz et dépasse le seuil d’hystérésis de notre œil. La broche D0 étant à 25Hz le découpage est nettement visible. Noter au passage que la luminosité avec un rapport cyclique de 0.5 reste relativement importante.
La suite est ici.
