48) 27/12/2017 : Gestion d’un clavier multiplexé (MJD 58114)

Laissant un peu la bride sur le cou à l’équipe des programmeurs, on se rend ce jour en salle électronique S12 dans laquelle nous avons négligé un peu les personnels. Il est temps d’aller les voir pour évaluer l’avancement de leurs travaux. Quand on arrive, il sont en train de commencer à assembler une magnifique console dont plusieurs modèles seront installés un peu partout dans les stations de poursuite autour du globe, ainsi qu’à Toulouse au centre principal de contrôle. Ce jour Julien 58114 ils sont en train de déballer de magnifiques claviers à intégrer sur les pupitres de maîtrise.
Lorsqu’on s’amuse à programmer de petites applications qui ne comportent que deux ou trois touches, il est assez naturel de ne pas se compliquer la vie et des les prendre en compte comme montré sur la Fig.228 en réalisant un diviseur potentiométrique dont la tension est mesurée sur une entrée analogique. Plus on place de touches dans le diviseur de tension, plus l’écart entre les niveaux représentatifs des contacts électriques devient faible et le risque qu’un parasite fausse la mesure en cours du CAN augmente. Aussi, jusqu’à cinq boutons poussoir par entrée on peut considérer que c’est raisonnable, mais guère plus.

Clavier organisé en matrice.

Consultez la Fiche n°32 relative à un petit clavier du commerce dont la Fig.232 montre l’allure. Il est typiquement organisé en matrice. Pour simplifier, quand on ne fait pas référence aux mathématiques, une matrice est un damier organisé en lignes et en colonnes. Un jeu d’échec est une matrice 8 x 8. La bataille navale, un écran graphique comme celui que nous allons utiliser, un caractère texte affiché sur un écran LCD textuel, tous ces éléments sont des matrices. La Fig.233 montre le schéma électrique du petit clavier commercial qui est vendu sans les composants de mise en œuvre, laissant à l’utilisateur le soin de l’agencer comme il l’entend. Souvent on se contente d’affecter quatre sorties pour les colonnes et quatre entrées pour les lignes, c’est la façon banale et « standard » d’exploiter un tel dispositif. La technique qui consiste à utiliser cinq résistances de plus et quatre diodes augmente un peu la complexité du circuit électronique. Elle fait économiser trois E/S sur le microcontrôleur et simplifie un peu l’exploitation logicielle. Toutefois elle n’est utilisable que si le processeur utilisé dispose de convertisseurs AN, grand avantage de l’ATmega328. Naturellement il est possible de concevoir des matrices 3 x 3 pour 9 touches, 5 x 4 pour 20 touches etc. Le petit clavier de la Fig.232 est bien commode pour conduire des expérimentations car il regroupe sous un faible volume un grand nombre de touches. Matricé 4 x 4 il comporte 16 boutons poussoir qui sont géométriquement également agencée en quatre lignes de quatre colonnes. Pour développer, c’est utilisable, mais pour la qualité opérationnelle, les touches seront disposées par des regroupements fonctionnels. On concevra un clavier « maison » et ce n’est qu’électriquement que les boutons poussoir seront comme sur la Fig.233 organisés en matrice.

Circuit imprimé expérimental.

Faisant partie intégrale du laboratoire « Développement Arduino », le petit clavier dont il est question dans le chapitre qui précède est associé à un tout petit circuit imprimé qui se place en gigogne directement sur le connecteur HE14 du module commercial. Sois dit en passant, avoir soudé un connecteur vertical sur leur produit est à mon avis une très mauvaise idée. Un connecteur HE14 coudé se branchant latéralement serait bien plus commode. De ce fait ce module devient pratiquement inutilisable dans un quelconque coffret. Dommage qu’il était livré tout soudé, dans le cas contraire un connecteur bien plus adapté aurait été installé. Bien qu’un circuit imprimé sera spécialement dédié à la Raquette de commande, à titre d’information je vous livre sur la Fiche n°33 le petit circuit de complément expérimental. Pour mieux comprendre comment cette interface électronique est réalisée et surtout enfichée sur le clavier, les Image 55.JPG et Image 56.JPG sont disponibles dans le dossier <Galerie d’Images> qui accompagne ce TOME 5 du didacticiel.

Principe du multiplexage : Le balayage.

Prendre la Fiche n°32 car nous allons raisonner sur la Fig.2 tant électroniquement qu’informatiquement. Si les diodes D n’étaient pas insérées dans le circuit, les résistances de ligne R3 seraient en parallèle, et n’en formeraient physiquement qu’une seule. Le circuit ne fonctionnerait pas. Quand ces diodes D ne sont pas conductrice, elles se comportent comme des isolants électriques et l’entrée A6 se trouve « en l’air ». Soumis à un haute impédance, le fil de liaison forme antenne radio et capte des parasites hertziens. La résistance de 47kΩ a donc pour rôle de maintenir A6 à zéro volt tant qu’aucun B.P. n’est enfoncé. (Sa valeur est choisie assez importante pour ne pas trop changer celle des résistances placées sur les lignes, car elle se trouve en parallèle. Il faut toutefois ne pas prendre beaucoup plus que 47kΩ car plus l’impédance est élevée, plus l’entrée sera sensible aux parasites radios.) Tout multiplexage est basé sur l’idée de balayage. Pour tester le clavier, le principe consiste à « regarder » par exemple si sur la colonne C1 une touche est enfoncée. Si ce n’est pas le cas, alors on teste C2, C3 et C4. Si aucune colonne de touches n’a été sollicitée, le programme en déduit que le clavier est au repos. La séquence est terminée et le logiciel poursuit infiniment sa boucle de base pour traiter d’autres séquences. (On peut effectuer cette exploration des colonnes dans un ordre quelconque, de même que l’on peut balayer les lignes et mesurer les tensions sur les colonnes, toutes les combinaisons sont possibles.) Imaginons par exemple que cette exploration du clavier arrive sur C4. Dans ce but, comme montré sur la Fig.2 D10 passe au niveau « 1 ». Supposons qu’au moment de la mesure nous ayons appuyé sur la touche S12 par exemple. Le +5Vcc disponible sur D10 est divisé par deux par la résistance de 1kΩ R2 et la résistance de 1kΩ R3. La diode D prélève ses 0,5V environ et R1 fait diminuer un peu la tension qui sur A6 avoisine alors +1,95Vcc. La « sortie » du convertisseur CAN fournit une valeur numérique de 392. Le programme sait alors que l’une des touches de la ligne L3 a été sollicitée. Comme c’est lui qui active D10, il sait aussi que c’est sur C4 que se trouve le B.P. cliqué. Il en déduit que c’est L3/C4, donc la touche S12.

L’immunité aux parasites hertziens.

L’anti parasitage doit dans la pratique compléter la théorie abordée dans le chapitre précédent. Examinons en détail la conception de l’interface du clavier, sachant que deux sortes de pollutions viennent se superposer. La première a pour origine l’environnement électromagnétique. Les résistances ont été astucieusement choisies pour n’employer que des composants ordinaires de valeurs standards, qui dans le montage vont diviser la tension +5Vcc en cinq zones « identiques ». Chaque palier est séparé de »1Vcc. Supposons que l’on teste la ligne L3. La sortie D10 passe à ++5Vcc début de la zone jaune sur la Fig.234 qui propose un diagramme temporel de la valeur de la tension présente sur l’entrée de numérisation A6. (Ligne „ du programme listé sur la Fig.236.) Le convertisseur analogique numérique pour effectuer son travail exige la durée coloriée en jaune. Si tout était parfait, la tension mesurée serait de +1,95v bien constante. Dans la réalité, durant cette période il peut se produire une grande variété de perturbations. Par exemple en permanence se superpose « du bruit en herbe » comme symbolisé en 3. En 1 on a coupé un moteur électrique voisin provoquant un parasite de type oscillation amortie, sans compter qu’en 2 un éclair orageux à induit sur le réseau électrique une surtension qui atténuée se retrouve en sortie des alimentations régulées de nos électroniques. Bref, le +1,95v est en permanence fluctuant. Les valeurs numérisées des seuils théoriques sont indiquées en vert sur la Fig.234 correspondant à chaque ligne du clavier. Si vous regardez attentivement la ligne (8) du programme, vous constaterez que les tests sont effectués au « milieu » de chaque plage. Par exemple toute numérisation comprise entre 286 et 511 sera considérée dans la batterie de comparaisons comme appartenant à la ligne L3. Toute numérisation comprise entre 511 et 718 sera considérée dans la suite de comparaisons comme appartenant à la ligne L2. Le logiciel introduit par cette technique une immunité aux parasites de ±0,5 volt ce qui dans la pratique s’avère suffisant et fiable. Notez au passage que si l’on augmente le nombre de touches par colonne les écarts entre seuils diminuent, donc l’immunité logicielle. C’est la raison pour laquelle il reste recommandé de ne pas dépasser cinq B.P. par colonne.

L’aspect logiciel en C++.

Outre les parasites issus de l’environnement électromagnétique, on se heurte à un autre problème d’origine mécanique. Quand on entend le clic caractéristique d’un bouton poussoir à bascule, la théorie suppose que le contact électrique est établi de façon immédiate et stable comme représenté sur la Fig.235 en sur 1. Laissez tomber une balle de votre hauteur sur un sol dur. Étant donné quelle est élastique, elle rebondit et remonte presque aussi haut. Un peu moins car la déformation due au choc consomme un peu d’énergie. Puis elle retombe et rebondit encore, toujours un peu moins haut. Chaque rebond va prendre un peu moins de temps car à chaque fois la vitesse ascensionnelle la fait monter moins haut. Cette balle va ricocher de plus en plus rapidement jusqu’à avoir consommé toute l’énergie « de hauteur initiale ». Si au lieu d’être en caoutchouc elle était en acier, le phénomène serait identique, sauf que le « rendement » étant meilleur la perte à chaque choc serait moindre et le nombre de rebonds plus important. Pour un contact électrique il se produit un phénomène tout à fait analogue. Nous entendons un unique « clic ». Dans la réalité, comme en 2 sur la Fig.235 se produisent une kyrielle de rebonds mécaniques. Chaque saut coupe le contact, et comme le microcontrôleur peut boucler rapidement une séquence, il va croire que l’on a appuyé plusieurs fois sur la touche. Sur un bon interrupteur on compte environ 6 à 8 commutations. Sur un B.P. ordinaire on peut en totaliser entre 30 et 50 !
Pour parer ce genre de problème on peut placer un condensateur de 10nF à 50nF aux bornes du contact. Un composant, c’est concevable, mais pour 16 le coût et la place exigée sur le circuit imprimé sont exagérés. Aussi, on peut alors procéder à de l’antirebonds par logiciel. C’est le premier démonstrateur P21A_Démonstrateur_Raquette.ino qui établit une relation conversationnelle entre les deux cartes Arduino. Seize touches : Seize fonctions comprises entre « 24* » et « 39* » pour tester le clavier et commencer à mettre en place notre stratégie logicielle. La Fiche n°35 donne la liste des codes retenus pour envoyer les Consignes à la Sonde. Examinons le contenu du démonstrateur :

En (1) le code BP prend la valeur zéro qu’il conservera en sortie de Tester_le_clavier() si aucune touche n’est activée lors des quatre mesures effectuées en ligne (5). En ligne (2) on teste successivement les quatre colonnes même si l’une d’elle répond positivement. (Un swich sase a été testé et conduit à un encombrement identique. Comme la cascade des if est plus parlante elle a été conservée.) Pour tester une colonne, on fait monter sa sortie Colonne à +5Vcc en (4). En (5) on mesure la valeur de la tension, parasites inclus. En (6) on ne modifiera la valeur de BP que si une touche dans la colonne testée est enfoncée. La constante C1 désigne la sortie testée D7 et vaut 7. Donc 7 + 6 en ligne (7) donne la valeur 13 à BP. En fonction de la tension mesurée, on aura entre zéro fois et trois fois la soustraction de 4 unités. Pour la colonne de D7 on obtient alors 13, 9, 5 et 1 qui sont les valeurs correspondant aux touches S13, S9, S5 et S1. Ce n’est pas un hasard si les quatre sorties utilisées pour multiplexer ont été choisies consécutives. Ainsi le codage est particulièrement économe en code objet. En (9) le while va boucler tant que l’on détecte l’état « activé ». On temporise 5mS pour laisser passer le rebond et on recommence. Quand il n’y a plus de rebond, on réalise un délai de sécurité de 10mS. Enfin en (10) la vérification sur la colonne est achevée, on fait repasser la sortie à zéro. En toute logique (10) devrait être placée juste après la ligne correspondant à la mesure en (5). Curieusement si on corrige ce « manque d’élégance du programme, le code objet augmente de 10 octets ! Alors le programme source a été conservé en l’état.

Codage des Consignes envoyées à la sonde.

Partie intégrante du changement de stratégie opéré pour ce TOME 5, nous savons qu’il n’est plus nécessaire d’avoir des consignes faciles à mémoriser par l’opérateur. Par exemple sur le démonstrateur la touche S7 « fige les moteurs », la touche S8 les rétablit. Sur le clavier définitif, par exemple on réservera une seule touche notée Moteurs OFF. Un premier clic sur cette dernière allumera la LED rouge, un deuxième clic l’éteindra. Sur la Fiche n°35 on constate que pour suspendre les moteurs on a choisi le code « 31* » et pour rétablir la motorisation le code « 32* ». C’est le programme complet P40_PGM_RAQUETTE_MAITRE.ino qui sera chargé d’envoyer des codes différents en fonction de la chronologie d’utilisation de cette touche de type bascule OUI/NON.
– Pourquoi avoir choisi deux codes différents pour une action de même nature ?
Tout simplement pour optimiser le code de P50_PGM_ESCLAVE_SONDE.ino qui n’aura plus à se préoccuper du booléen dans la boucle de base. En effet, dans l’ancien

programme, chaque rotation de la boucle de base testait le booléen Moteurs_ON. Donc à chaque itération soit le if invoquait la procédure digitalWrite pour allumer, soit le else digitalWrite pour éteindre. Le microcontrôleur passe son temps à allumer ou éteindre des centaines de fois une LED qui est déjà dans l’état logique désiré. Aussi il est bien plus logique de ne le faire qu’une seule fois. Il faut plus de code puisque l’on a deux cas à traiter dans le swich sase. Pour compenser on économise le if et le else. Ce doublement des codes de Consigne sera systématiquement utilisé dans le programme de la Raquette.
Puisque c’est une instruction de type swich sase qui sera chargée d’aiguiller les traitement en fonction du code de la Consigne, on peut adopter ce que l’on désire pour ce dernier. Aussi, pour pouvoir réutiliser la Fiche n°12 durant le développement, les codes « 1* » à « 23* » correspondent directement aux fonctions des programmes « p01* » à « p23* ». Globalement, les autres codes sont attribués au fur et à mesure que le logiciel prend de la consistance.
Les Consignes les plus longues, tout au moins à ce stade des études, font donc trois caractères sentinelle ‘*’ comprise puisqu’il n’y a plus besoin de préciser ‘p‘. Pour la répétition d’un mouvement élémentaire, il sera toujours possible de conserver une lettre de sélection avec une Consigne du genre « p3d* » ou « p4c* » par exemple. Sachant qu’une chaîne de caractères mémorisée par le compilateur est terminée par un délimiteur, on réserve quatre Octets avec la constante LGR_chaine.

Changement de stratégie pour optimisation.

Anciennement la commande « b* » était réservée pour figer les lumières quand le potentiomètre servait à pointer le LASER, à déplacer en TORSION ou à piloter un moteur en mode manuel. Pour son compte, la commande « n* » neutralisait le potentiomètre quand on changeait de moteur cible en mode manuel. Il sera plus logique d’affecter un indicateur pour préciser sur qui on agit quand le codeur rotatif est en cours d’utilisation. Ainsi les variations du potentiomètre virtuel pourront être dosées en fonction de la cible. LASER et Phares pourront être modifiés séparément sans interaction réciproque. Enfin, le pilotage manuel des moteur pourra être amélioré : Chaque changement de moteur cible commencera par forcer le potentiomètre virtuel à la « consigne du moteur » évitant ainsi les mouvements brusques. Les commandes « b* » et « n* » devenues inutiles libèrent leurs LEDs respectives. En revanche, il devient utile de savoir quand le potentiomètre virtuel est arrivé en butée logicielle puisque le codeur incrémental n’a pas de limite angulaire.
La LED jaune de l’ancien « n* » signalera la saturation dans le sens Positif. La LED blanche de l’ancien « b* » signalera la saturation dans le sens Négatif. Émuler un potentiomètre virtuel libère l’entrée A0 qui deviendra une sortie pilotant une LED rouge « BUZZER«  montrée sur le Fig.237 soudée sur un petit adaptateur HE14 à trois broches se branchant à la place de l’ancien potentiomètre. C’est un témoin visuel « système » servant au développement « silencieux » du logiciel.

La suite est ici.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *