C’est pratiquement sa sœur jumelle avec quasiment les mêmes ingrédients. Comme tout le monde n’a pas forcément un codeur incrémental à sa disposition, on peut envisager de le remplacer pas un petit clavier car des touches de toutes les tailles sont disponibles dans le commerce en ligne. Pour ma part je fais souvent appel à celles de la Fig.56 que l’on trouve par lot de cent. Outre leur petite taille, elles sont munies de cabochons de toutes les couleurs offrant un bon éventail de combinaisons envisageables. On peut ainsi choisir les teintes à notre guise. Sur cette photographie en A se trouve le corps des ces petits boutons poussoir. La partie active qui s’enfonce quand on clique porte un tenon conique sur lequel s’emboîte le cabochon B disponible en sept couleurs. En C l’un de ces composants est assemblé. Ils se positionnent facilement sur une grille au pas standard. Autant dire l’idéal pour se concocter un petit clavier parfaitement adapté à notre besoin. Dans un premier temps, on va partir sur l’idée d’un petit clavier à deux touches pour des raisons d’encombrement et chercher une utilisation conviviale.
Expérience_24 : Clavier à deux boutons poussoir.
Dans ce chapitre nous allons prendre en modèle un clavier élémentaire géré par A1 par exemple. La Fig.57 reproduit le schéma électrique du dispositif de la Fig.58 (Voir également la photographie d’IMAGE 07.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. La première source de parasitage dans la lecture d’une entrée analogique vient avec le « bruit alimentation ». Considérons la Fig.59 qui montre l’évolution de la tension alimentation au cours de temps. En théorie la ligne USB du P.C. ou d’un adaptateur secteur fournissent 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 le dessin de la Fig.59 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 de la Fig.57 la tension dépasse légèrement le seuil de comparaison interne de 3,3V sur A1. Pour s’adapter à cette référence interne imposée par l’instruction analogReference(INTERNAL); une résistance de 10kΩ est ajoutée entre la broche qui devait aller au +5V et le +Vcc. Tout se passe maintenant comme si R1 faisait 10kΩ. La tension sur A1 chute à environ 1,4V et la numérisation par le CAN donne la valeur de 400 lorsque l’on clique sur BP2. Cliquer sur BP1 a pour effet de faire un court-circuit entre A1 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 études qui vont suivre, Experience_24.ino est conçu pour mesurer ces valeurs numérisées et les afficher en permanence à 19200 baud sur le Moniteur de l’IDE. Sur mon exemplaire la valeur à vide est de 1023. Cliquer sur BP1 : La numérisation qui devrait en théorie donner zéro tourne aux environs de 53. Agir ensuite sur BP2 engendre une numérisation de l’ordre de 400. Ces valeurs étant notées, nous allons pouvoir optimiser les programmes d’application. Sur la Fig.59 ont été reportées les valeurs numérisées avec 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 400 + 1023 / 2 = 711. 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 53 + 400 / 2 = 226 valeurs portées sur la Fig.59 situant la « frontière » entre BP1 et BP2. Toute valeur plus grande que 226 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 logiciels qui vont suivre.
Expérience_25 : Assurer l’anti-rebonds.
Avec P24 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.60 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.61 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. (P25 utilise là.) Cet organigramme n’explique pas comment se fait l’anti-rebonds. En analysant le code source d’Experience_25.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 pérenne. 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 à 19200 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 24 et en ligne 25.
Expérience_26 : 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 servant au dialogue Homme/Machine. Il m’est arrivé souvent de n’installer que deux boutons poussoir comme montré sur la Fig.57 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_26.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 P25 le démonstrateur le signale à 19200 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èrera l’action à conduire en fonction du désir de l’utilisateur. Noter qu’en ligne 22 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.57 est le seul possible. Par exemple sur la Fig.62 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_A1() est à réécrire mais le code objet ne sera pas plus encombrant.
Experience_27 pour préparer la deuxième application.
Par rapport à Application_GPS_1.ino elle ne fait que remplacer le codeur incrémental par un petit clavier personnel à deux touches. Il n’est toujours plus possible d’ajouter de nouvelles fonctions par manque de place entre la PILE et le TAS.
Globalement l’usage de l’appareil sera identique. Quand on tournait le codeur incrémental dans un sens ou dans l’autre, on changeait de PAGE écran sur le GPS ou on modifiait les options. Maintenant, le bouton rouge correspond à la rotation horaire, et la touche bleue fait revenir en arrière. Pour sortir d’une fonction ou valider une option, le BPC est remplacé par un clic long sur l’une quelconque des deux touches. Apprenons à utiliser le clavier à deux touches :
Manipulations :
01) Activer l’IDE et téléverser Experience_27.ino.
02) Ouvrir le Moniteur et vérifier que sa vitesse est de 19200bauds.
03) Faire un RESET. Attendre que l’appareil se mette à afficher la date et l’heure.
04) Faire un clic court sur le BP rouge : L’écran affiche la position géographique.
05) Continuer par un clic court sur le BP rouge : L’écran affiche la distance à la cible.
06) Poursuivre avec un clic court sur le BP bleu : L’écran revient en arrière sur les coordonnées.
>>> Touche rouge on avance dans le menu, Touche bleue on y recule.
07) Enchaîner des clics courts sur le BP rouge jusqu’à invoquer la PAGE qui affiche les caractéristiques de quatre satellites. La LED bleue s’illumine précisant ce mode particulier. On peut cliquer rapidement sur les touches, elles sont immédiatement prises en compte. Les clics courts présentent les caractéristiques des satellites en permutation circulaire. La seule façon de sortir de ce mode qui éteindra la LED bleue consiste à effectuer un clic long sur l’un quelconque des deux BP qui fait revenir en première page du Menu du GPS.
Application_GPS_2.ino.
Outre le remplacement du codeur incrémental par un petit clavier personnalisé, dans cette version du GPS on va changer radicalement de stratégie et effectuer une approche assez différente. En effet, avec les démonstrateurs précédents ou Application_GPS_1.ino les ressources de l’ATmega328 saturaient et il n’était plus possible d’ajouter des fonctions. Hors c’est tout à fait envisageable si l’on réalise des économies substantielles d’occupation mémoire et en particulier entre la PILE et le TAS car c’est actuellement la pierre d’achoppement. Pour contourner cette limite, dans la nouvelle mouture nous allons :
• Placer les textes du dialogue Homme/Machine en mémoire non volatile EEPROM. Dans ce but il faut y libérer de la place. À l’usage on constate que trente PI c’est vraiment inutile, avec dix on couvrira largement nos besoins ordinaires. Gain de place : 20 x 33 = 660 octets. Largement de quoi y loger tout les textes que l’on désire figer.
• Quand on efface un PI, décaler l’intégralité des emplacements est très pénalisant en temps de traitement. On ne déplacera plus que le nécessaire. Du coup la durée devient assez courte et il n’est plus nécessaire d’attirer l’attention de l’opérateur avec un BIP sonore.
• On va empêcher ‘e‘ d’effacer tous les PI, il devra en rester au moins un. De ce fait le code objet s’allège de 26 octets et surtout il n’y a plus besoin d’un BIP sur RESET dont l’interprétation n’était pas évidente. (BIP lorsqu’il n’y avait pas de PI à charger par défaut.)
• L’espace mémoire disponible étant redevenu important, on pourra ajouter la fonction ‘g‘ pour Gommer (Effacer) tous les PI sauf le premier, ‘c‘ pour Corriger un PI et éventuellement prévoir la PAGE d’affichage de la vitesse et du cap s’il est possible de la développer correctement.
Passage des textes du dialogue USB en EEPROM.
Par nature, les textes d’interfaçage entre l’ordinateur et l’humain ne changent pas. Ce sont intrinsèquement des données constantes. Hors pour le compilateur une string est un tableau de variables de type char que l’on peut manipuler à notre guise. Comme ces chaînes de caractères doivent être initialisées, elles sont déjà présentes dans l’espace réservé au programme. Mais en tant que tableau de variables, l’ATme328 subit une double peine : On doit leur réserver un emplacement en mémoire dynamique pour pouvoir les modifier à notre guise. Par exemple la chaîne « Bonjour. » va consommer neuf octets dans la zone programme et ajouter également neuf octets en mémoire dynamique, donc diminuer d’autant l’espace libre entre la PILE et le TAS. (Neuf octets car il faut ajouter un octet au texte pour la sentinelle de fin de chaîne ‘\0’.)
L’implantation des données en mémoire non volatile est détaillée dans Fiche n°19 et Fiche n°20. On observe que l’EEPROM est entièrement utilisée. Il ne reste plus qu’un seul octet de libre représenté par ‘*’ dans la zone bleue de la Fiche n°20. Autant dire que pour la rentabilité du matériel on ne peut pas faire mieux. Le gain de mémoire obtenu est tel que non seulement il a été possible d’améliorer le programme, d’ajouter deux fonctions et le compilateur n’affiche toujours pas le message d’erreur de la Fig.53. On pourra ajouter du code si l’exploitation de la vitesse et du cap s’avère possible …
Fonction ‘g‘ : Gommer tous les PI sauf le premier.
Quand nous avions désiré effacer les 30 PI, l’opération s’était avérée particulièrement indigeste. Dans la nouvelle mouture du logiciel, il n’y en a plus que neuf à effacer, et la manipulation reste encore un peu galère. Aussi, comme il reste de la place à revendre, autant ajouter une petite fonction « de luxe » pour faire tout le travail :
Manipulations : (Suite)
08) Maintenir l’un des deux BP cliqué et activer le Moniteur.
09) Lorsque la LED d’Arduino s’illumine, relâcher la touche.
10) Des clics courts sur le BP rouge font alterner entre la valeur OUI et la valeur NON.
11) Lorsque OUI est présent, engendrer un clic long sur l’une des deux touches. Le Menu du RESET montré en Fig.63 s’affiche dans la fenêtre contextuelle du Moniteur. Nous y trouvons deux nouvelles fonctions en A et en B.
12) Proposer ‘g‘. Comme l’action peut s’avérer destructrice, un BIP sonore attire notre attention et le logiciel demande confirmation. Seule la lettre ‘o‘ ou ‘O‘ sera considérée comme une approbation. Confirmer avec ‘o‘. Le programme affiche la liste des PI, et il n’en reste plus qu’un.
13) Réitérer la commande ‘o‘. Le programme ne vérifie pas le nombre des PI. Il efface tous ceux qui sont après le premier même s’ils n’existent pas. Exactement comme le faisait la commence ‘e‘, le PI qui sera chargé par défaut sur RESET sera le n°1.
14) Tester derechef la commande ‘e‘. Le programme génère un BIP d’erreur, affiche le texte « Il ne reste qu’un seul P.I. » et refuse maintenant d’effacer le dernier PI présent en EEPROM. Ainsi sur RESET on sera certain de charger des données cohérentes.
15) Petite exploration de la mémoire avec ‘m‘. On peut vérifier sur la Fig.64 que l’espace disponible entre la PILE et le TAS pour les données dynamique fait maintenant 877 octets. Il n’y a strictement aucun risque de collision de pile.
Fonction ‘c‘ : Corriger le contenu d’un PI.
Qutant la commande ‘g‘ ne sera pas utilisée souvent et constitue un petit plus, autant pouvoir corriger l’une des trois entités d’un PI qui contient une erreur peut s’avérer bien pratique. Pour vérifier que l’on peut modifier n’importe quel PI présent, nous allons réinscrire en EEPROM les exemples initiaux pour avoir un « tronc commun ».
Manipulations : (Suite)
16) Téléverser une deuxième fois l’outil Ecrire_en_EEPROM_1.ino et l’exécuter au moins une fois en activant le Moniteur de l’IDE.
17) Téléverser ensuite Application_GPS_2.ino pour retrouver le programme d’exploitation.
18) Effectuer les manipulations pour activer le « dialogue H/M sur USB ».
19) Commande ‘L‘ pour vérifier la présence des sept PI.
20) Nous commençons par corriger le premier : ‘c‘ suivi de ‘1‘.
21) Le programme désire alors savoir quel est des trois items celui que l’on désire modifier. Comme montré sur la Fig.65 on doit le préciser par deux lettres, LA, LG ou LB. C’est la deuxième lettre qui sera analysée par le programme pour vérifier si elle est correcte et orienter le traitement. Tester « lf » par exemple. Comme la deuxième lettre n’est pas légale on est tancé d’un message d’erreur « Item incorrect. » suivi d’un BIP d’alerte.
NOTE : comme on va le voir dans les manipulations qui suivent, pour simplifier le programme, la première lettre n’est pas vérifiée ni la longueur du texte.
22) Tester ‘c‘ suivi de ‘1‘ puis de « xa » : Bien que le premier caractère ne soit pas correct, pour le logiciel la consigne est claire et il nous demande la valeur de la Latitude. Proposer « 1234567s » par exemple. (Penser éventuellement à du Copier/Coller comme déjà mentionné.)
23) Maintenant tester ‘c‘ suivi de ‘7‘ puis de « xgmmmmmmmmmmmmm » par exemple. Le deuxième caractère étant légal, la Longitude est requise. Proposer « 12345678w« .
24) On continue avec ‘c‘ suivi de ‘5‘ puis de « xbsssssss » par exemple. Commande acceptée le programme va modifier le nom du PI : « Bonjour les amis. ». On remarque qu’avec le point final on dépasse 16 caractères et il est ignoré. En revanche la casse est conservée pour les noms.
25) Dernier test correct : ‘c‘ suivi de ‘2‘ puis de « xg » par exemple avec « 12345678w« .
Ces manipulations montrent que l’on peut modifier l’item que l’on désire sur n’importe quel PI. Ce sera bien commode si on s’est trompé sur une cible, car nous ne sommes plus obligés de tout retaper.
26) Pour finir, ‘c‘ suivi de ‘9‘ : L’analyseur syntaxique surveille la logique de nos consigne.
Une fonction ‘p‘ un peu tardive.
À ce stade du développement, une idée d’amélioration du dialogue H/M a émergé des manipulations qui précèdent dans le didacticiel. En effet, quand on ajoute un PI en EEPROM, c’est que probablement il va devenir celui par défaut. Alors, pouvoir le désigner dans le dialogue USB par la fonction ‘p‘ a été ajouté. L’espace entre la PILE et le TAS a un peu diminué à 859 octets qui sont plus que suffisants pour garantir une bonne stabilité du programme. Ces deux modifications sont commentées sur la Fig.66 et ne coutent que 124 octets ce qui n’est vraiment pas onéreux.
Manipulations : (Suite)
27) Avec ‘p‘ désigner le PI n°3 par exemple suivi de ‘L‘. (Voir la Fig.66)
28) Commande ‘m‘ pour constater que maintenant l’espace entre la PILE et le TAS fait 859 octets.
29) Indiquer ‘p‘, PI n°1 suivi de ‘L‘ on vérifie que l’on peut bien désigner le premier.
30) Recommencer et désigner le dernier.
31) Tester ‘p‘ puis désigner le PI n°9. On se doutait que l’analyseur syntaxique n’accepterait pas.
32) Proposer ‘L‘ pour vérifier que rien n’a changé.
L’affichage du rappel des commandes a été modifié. Pour gagner de la place en EEPROM le texte « Rappel de ces commandes. » s’est simplifié et en A devient « Ce MENU.« . En B est ajouté la présence de la nouvelle commande ‘P‘. Quand on utilise cette commande, en C le logiciel demande quel sera le PI qui sera chargé par défaut sur RESET. À partir de cette dernière version du logiciel lors du listage des PI présents en mémoire non volatile EEPROM, celui qui est désigné au rechargement est pointé par « <RESET » repéré en D sur la copie d’écran. Sans que ce soit une révolution, pour la bagatelle de 124 octets de programme en plus, l’utilisation du petit appareil est encore plus agréable.
Un point singulier.
Pluriel aurait été plus circonstancié, car dans ce dernier chapitre nous allons aborder le cas particulier des deux pôles. Ils sont particuliers à plus d’un titre comme nous l’avons abordé dans le document, Cartographie et loxodromie.pdf et dans ce chapitre nous allons voir la conséquence du fait que les pôles sont à la convergence de tous les méridiens. De ce fait, pour calculer la valeur de la loxodromie, en théorie, que l’on donne 0,15,-73 pour la valeur de la longitude, la distance calculée doit en principe rester identique. C’est précisément ce que l’on va vérifier.
Manipulations : (Suite)
33) Avec ‘q‘ passer dans le Menu du GPS.
34) Cliquer deux fois sur le BP rouge. La distance cible fait 5062,34km ce qui est cohérent. En effet, le périmètre terrestre avoisine 40000km. Le GPS étant aux environs de la Latitude +45°, La distance qui nous sépare du pôle Nord est de 40000 / 8 soit 5000km. (Voir la Fig.67)
35) Revenir dans le dialogue H/M sur la ligne USB. (Vous devez savoir faire maintenant.)
36) Modifier la longitude avec ‘c‘, ‘1‘, « lg » et « 12100000w.
37) Consigner ‘q‘ suivi de deux clics sur le BP rouge. On retrouve la distance de 5062,34km.
38) Reprendre le dialogue H/M sur la ligne USB. (La routine à ce stade.)
39) Imposer ‘p‘ désigner le PI n°2 et vérifier par ‘L‘.
40) On recommence avec Consigner ‘q‘ suivi de deux clics sur le BP rouge. Cette fois la distance fait 14941,18km. C’est logique, elle avoisine 40000 / 8 * 3 soit 15000km. La précision des calculs de loxodromie sur des méridiens sont confirmés.
41) Provoquons un dernier retour dans le dialogue H/M sur USB.
42) Dernière modification de la longitude avec ‘c‘, ‘2‘, « lg » et indiquer vers l’est cette fois : « 16500000e« .
43) Encore ‘q‘ suivi de deux clics sur le BP rouge. On retrouve la distance de 14941,18km. OUF … tout fonctionne !
Mis à par le fait que la vitesse et le cap n’ont pas été explorés, on peut considérer qu’en l’état le programme est mature et « complet ». Pour celles et ceux qui ont la version « codeur incrémental », je vous ai concocté Application_GPS_3.ino pour remplacer la gestion du clavier par celle du capteur rotatif sachant que si l’on n’a pas trop l’habitude, c’est inévitablement un travail un peu laborieux et toutes et tous n’aurez pas forcément le temps de disponible pour vous y coller. On peut passer à ce stade à une autre version utilisant un écran graphique.
La suite est ICI.
