Particularités des programmes dédiés au SHIELD pour afficheur LCD.
Deux différences principales vont distinguer le programme qui anime Arduino muni d’une carte SHIELD pour afficheur LCD. La première résulte d’une répartition différente des broches de l’ATmega328 qui pilotent le LCD. Comme déjà mentionné, la broche D5 pilote l’entrée DB5 de l’afficheur. Cette broche n’est donc plus disponible en tant qu’entrée et fait perdre les fonctions utilisant TIMER1. Ceci dit, ce n’est pas une catastrophe, on « n’oublie » que trois fonctions sur un MENU qui en laisse encore vingt et une. Du reste, la perte n’est pas totale. En effet, si vous avez un jour vraiment besoin de fréquencemètre, du périodemètre ou de l’impulsiomètre, rien ne vous empêche de déposer le shield et d’utiliser le programme qui fonctionne avec la voie série USB.
La deuxième différence vient du fait que le SHIELD comporte cinq boutons au lieu de deux.
Heureusement pour nous ils sont branchés sur D5 ce qui assure une parfaite compatibilité matérielle.
Conséquences d’une répartition différente des E/S.
Outre la perte des trois fonctions utilisant TIMER1, maintenant D13 pilote le transistor de commutation du rétroéclairage. Toutes les instructions qui modifiaient l’allumage de la LED verte sont donc à proscrire. La routine qui teste les boutons poussoir n’aura plus d’effet sur cette LED verte. Sur la ligne série on pouvait afficher à profusion, mais actuellement nous sommes limités drastiquement à trente deux caractères. Sur la version LCD du projet, PAUSE n’affiche plus son état d’activation car les deux lignes peuvent contenir des données. Pour nous prévenir, la LED verte clignote à 20Hz. Comme cet artifice n’est pas utilisable avec le SHIELD, on « se débrouille » pour afficher le mot « PAUSE » à un endroit pas trop pénalisant.
Conséquences logicielle d’un clavier différent.
Représenté sur la Fig.35 donnée ci-dessous, on trouve le schéma électrique adopté pour prendre en compte les cinq boutons poussoir disponibles sur le module électronique, qui reprend l’idée d’un diviseur de tension. C’est la technique classique qui consiste à n’utiliser qu’une seule entrée analogique et à différencier les B.P. appuyés par une tension propre définie par une chaine de résistances. Sur la Fig.35 sont précisées en violet les tensions mesurées sur la broche A0 en fonction de l’état d’activation des divers boutons. En bleu clair figurent les conversions analogiques / numériques qui en résultent. Ce sont celles à prendre en compte pour déterminer les plages de valeurs de détermination. Le fait de disposer de cinq boutons au lieu de deux ouvre des horizons, car ainsi on pourrait modifier les options et rendre encore plus conviviale l’exploitation de cette version. Pour vous laisser l’initiative des choix de protocoles différents et de leur programmation, cette possibilité ne sera pas abordée dans le cadre de ce didacticiel. De telles modifications ne sont pas complexes à traiter, vous pourrez en outre vous inspirer de ce qui est déjà codé dans notre programme.
Pour minimiser l’influence des parasites, on considèrera qu’un B.P. est appuyé si la mesure du CAN est inférieure à 830. C’est la moyenne entre les deux valeurs 1023 et 638. On maximise ainsi l’immunité « au bruit ». Enfin les deux boutons RIGHT et UP auront le même effet et seront considérés comme désignant FC+ alors que LEFT et DOWN (Ainsi que SELECT.) valideront tous les trois FC-. Toujours pour augmenter au maximum la marge d’élimination des parasites, on place le seuil de détection à égale distance des deux niveaux 254 et 99 soit la valeur numérique de 176. Fin prêts pour cliquer sur les boutons …
Compter entièrement géré par logiciel.
Autant mesurer des fréquences et des périodes serait trop limitatif en terme de rapidité avec du comptage purement logiciel, autant compter reste possible si l’on accepte une cadence maximale de 200Hz. Cette restriction rend inutile la tentative de créer le fréquencemètre ou le périodemètre, mais pour un compteur d’événements cette rapidité est largement suffisante pour satisfaire un grand nombre d’applications. Il serait potentiellement possible de remplacer TIMER1 par TIMER2 ou TIMER3, mais nous ne disposons pas librement des entrées et de plus ces éléments sont mobilisés par diverses instructions de type génération PWM ou tone …
C’est le petit programme P09_COMPTEUR.ino qui va nous servir à expérimenter la fonction compteur entièrement gérée par logiciel. Comme déjà développé lors de l’étude du compteur avec TIMER1, compter consiste à analyser l’entrée affectée au capteur d’événements. On surveille
l’apparition d’un front montant ou d’un front descendant et quand il se produit on incrémente le compteur. Avec de l’électronique câblée à l’intérieur du microcontrôleur, ce travail est réalisé en temps masqué et à une cadence extrêmement rapide. Mais par logiciel c’est plus laborieux. Considérons la Fig.36 qui correspond au comptage sur fronts montants. Le seuil de détection est placé au centre des valeurs limites générées par le convertisseur CAN, toujours pour augmenter au maximum l’immunité aux parasites. (Valeur de 512.) En (1) on attend un état « 0 » en préambule au front montant.
Étant à « 0 », quand le CAN fournit une valeur élevée en (2), c’est que l’on est en présence d’un front montant. Rapidement en (3) on incrémente le compteur. Notez que si l’on désirait compter sur un front descendant, il suffirait d’inverser les tests (1) et (2).
Enumérons les divers facteurs qui réduisent à ce point la rapidité du compteur, alors que le microcontrôleur « tourne » à 16MHz et enchaîne les instructions binaires à une cadence vertigineuse : En premier, avant de passer aux instructions (1) et (2) il importe de savoir si l’opérateur à validé un comptage sur front montant ou sur front descendant. Pour ce faire, le programme effectue un test de comparaison sur un booléen suivi d’un branchement à la bonne séquence de programme.
Puis on attend le premier état. Mais si cette surveillance est déclenchée au début de l’état contraire, il faut attendre une demi-période du signal, plus une demi-période pour l’attente du front attendu. Si les événements se produisent à une cadence très lente, on boucle en permanence dans (1) ou (2).
Hors durant ce temps l’opérateur peut faire usage de l’un des deux boutons poussoir. Les séquences (1) et (2) sont donc des boucles durant lesquelles on lit le CAN. Puis la valeur retournée par ce dernier est comparée à 512. On saute ensuite à la procédure de lecture des deux B.P. cette dernière effectuant à son tour un test avant de provoquer son retour. Puis le cycle recommence jusqu’à ce que l’état attendu soit atteint. Si l’on détecte l’état initial (1) au début de ce dernier, il faut attendre une demi-période pour détecter le front de comptage. Toutes ces instructions prennent du temps.
Quand le front évènementiel est détecté, l’ATmega328 « se branche » sur la séquence de comptage. À ce stade l’U.C. doit encore dérouler un grand nombre d’instruction. Elle commence par lire la valeur actuelle du compteur et la compare à 9999999 qui est la butée logicielle attendue. Si cette comparaison est négative, le compteur est alors incrémenté. Le microcontrôleur effectue au préalable les deux tests pour savoir si une fin de cette fonction a été demandée. Si le test est négatif, la boucle de mesure va recommencer. Elle commence par comparer la valeur du compteur à celle qu’il avait précédemment. Si cette valeur est différente, alors est invoquée la procédure qui affiche la valeur. Mais nous savons que cette procédure est laborieuse, car elle découpe la valeur du compteur pour la formater et l’afficher par paquet en insérant des espaces en tête et des points décimaux. Il faut aussi mémoriser cette nouvelle valeur. On comprend maintenant pourquoi la limite logicielle talonne à 200Hz et surtout les raisons qui incitent les fournisseurs de microcontrôleurs à insérer dans ces derniers des unités de comptage rapides et indépendantes.
