À ce stade du développement, on peut envisager la version d’Application_GPS_1.ino opérationnelle directement issue du démonstrateur P22 auquel on a ajouté la fonction indispensable qui permet à l’aide du Moniteur de l’IDE de gérer les points d’intérêts sauvegardés en mémoire non volatile EEPROM. La mise en œuvre du dialogue Homme/Machine constitue la partie la plus technique ajoutée au programme et a été accomplie en plusieurs étapes.
Réorganisation du Menu du GPS.
Dans le démonstrateur Expérience_22.ino les fonctions ont été intégrées dans l’ordre de leur développement. Les premières étaient naturellement les plus importantes. Puis ont suivi les « fonctions secondaires ». Ensuite, le Menu du RESET ayant été ajouté au logiciel, il est apparu comme indispensable de compléter dans le Menu du GPS avec la fenêtre de la Fig.49 qui résume les données de base chargée depuis l’EEPROM lors d’un RESET. En A est précisée si c’est l’heure d’été ou l’heure d’hiver qui est affichée. En B les unités de distance et de vitesse. Enfin en C sur la ligne du bas, la nature du point d’intérêt dont la loxodromie sera calculée. L’ordre des informations de la liste de toutes les fonctions du Menu du GPS a été repensé en plaçant dans l’ordre les fonctions les plus importantes au début et celles secondaires vers la fin. Le tableau de la Fig.50 résume cette nouvelle organisation. Par exemple l’heure ou la position et la distance à la cible sont bien plus opérationnelles que le type de positionnement, la dilution ou les caractéristiques de quatre satellites parmi « beaucoup ». De même que les valeurs des options sont vitales pour que l’on sache quelle est la Cible sans avoir à invoquer le Menu du RESET.
Modification du Menu du RESET.
Après plusieurs expérimentations pour trouver un comportement agréable du programme, le protocole le plus convivial pour ajouter le dialogue Homme/Machine par l’entremise du Moniteur de l’IDE consiste à placer l’option en tête du Menu du RESET. L’approche explicitée en Fig.46 de la page 23 devient celle de la Fig.52 qui reprend le concept de rotation du codeur incrémental pour changer la valeur de l’item et d’un clic sur son bouton central pour valider l’option. On commence par activer un croquis quelconque pour invoquer en 1 l’éditeur de texte de l’IDE. Puis, on clique sur le bouton central du codeur incrémental, et en le maintenant enfoncé, on clique sur la puce 2 qui ouvre la fenêtre contextuelle du Moniteur en 3. Attendre que la LED d’Arduino s’illumine pour libérer le bouton central du codeur rotatif et ouvrir sur l’afficheur LCD l’écran de la Fig.51 avec l’option NON par défaut. En tournant le codeur incrémental on fait alterner OUI et NON. Si on valide avec le bouton central étant en option NON on enchaîne sur la séquence de la Fig.46 en page 23. Au contraire, si la validation se fait avec OUI affiché, on enchaîne alors sur le Menu du dialogue Homme/Machine. S’affiche alors en 4 dans la fenêtre contextuelle du Moniteur le rappel des commandes et en 5 le programme patiente pour une directive de votre part. La LED bleue va alors clignoter tant que l’on restera dans ce mode. Dans l’attente d’une Commande on doit fournir une lettre minuscule ou une lettre majuscule suivie immédiatement de la validation. Quand on tapera une commande, elle sera immédiatement exécutée. Si c’est l’ordre ‘Q‘ qui est imposé, le texte « Fin du dialogue USB. » s’affiche, un BIP sonore prévient l’opérateur, la LED bleue s’éteint et le logiciel passe directement au MENU du GPS. Un analyseur syntaxique vérifie toutes les sollicitations de l’opérateur et chaque erreur de logique sera accompagnée d’un texte adapté et d’une alerte sonore. Cette dernière impose le petit ajout de la Fiche n°18 par rapport au schéma de la Fiche n°17. Comme l’ajout du bruiteur n’est pas impératif, je n’ai pas corrigé le contenu de la fiche 18, libre à vous de l’installer ou non en fonction de sa disponibilité.
Tester le dialogue Homme/Machine.
Une petite prise en main me semble la bienvenue pour explorer les multiples facettes de la gestion des points d’intérêts. À ce stade de vos expérimentations vous avez déjà utilisé l’outil Ecrire_en_EEPROM_1.ino et téléversé Application_GPS_1.ino. Quand on compile le croquis, s’affiche en orange l’alerte de la Fig.53 qui sera commentée plus avant. Ne pas s’en préoccuper.
Manipulations :
01) Ouvrir le Moniteur de l’IDE et imposer la vitesse de 19200bauds. (Le 57600baud à été réduit à 19200baud car il était trop rapide et la fonction ‘A’ ne fonctionnait pas du tout correctement.)
02) Maintenir enfoncé le bouton central du codeur incrémental. (BPC.)
03) Cliquer sur la puce « Symbole loupe » pour ouvrir à nouveau le Moniteur de l’IDE.
04) Attendre que la LED d’Arduino s’illumine et relâcher le BPC.
05) Tourner le codeur incrémental pour obtenir OUI sur l’afficheur LCD.
06) Cliquer sur le BPC, la liste des Commandes possibles s’affiche dans la fenêtre contextuelle.
07) Proposer ‘x‘ dans la fenêtre de saisie et valider. L’analyseur syntaxique ne reconnait pas cette lettre comme étant valide et vous le signifie par un texte associé et un BIP pour attirer l’attention.
08) Valider à vide. Le programme affiche « Longueur 0 ou > 1 ! » pour nous signifier qu’un texte de longueur nulle ou supérieure à un ne sera pas accepté. (La loi c’est la loi !)
09) Tenter le texte « 123456789abcdefghijklmnopqrstuvwxyz« . (C’est pas la peine d’insister !) Observez au passage que le logiciel affiche entre crochet le texte qu’il a enregistré. Vous pouvez constater que sa longueur est limitée à 16 caractères.
REMARQUE : Pour ne pas avoir à frapper tous les caractères de l’exercice, il suffisait de faire un Copier dans le logiciel de présentation du didacticiel et un coller dans la ligne de saisie du Moniteur. La réciproque est vraie. On peut effectuer un Copier dans la fenêtre contextuelle du Moniteur suivi d’un coller dans n’importe quel traitement de texte.
Manipulations : (Suite)
10) Proposer ‘l’ ou ‘L’ dans la fenêtre de saisie et valider. Lettre minuscules ou majuscules sont équivalentes. Les minuscules sont plus faciles à frapper.
11) À tout moment la Commande ‘,‘ ou son équivalent majuscule ‘?‘ listera un rappel des commandes possibles. Tester ‘,‘ puis ‘?‘. Quand on a oublié les lettres valides, « on se pose une question » et le caractère qui vient à l’esprit est le point d’interrogation. Toutefois la virgule nous évite d’avoir à solliciter la touche majuscule.
12) On va tester le mode silencieux. Frapper ‘s‘. Le programme affiche « BIPs NON« .
13) Avec ‘n‘ ou toute autre lettre non valide tester l’erreur. « Commande incorrecte. » est affiché dans le plus grand silence. Ce mode est bien utile quand on ne veut pas déranger un entourage éventuel.
14) Indiquer une deuxième fois ‘s‘. Le « BIPs OUI » confirme que le mutisme n’est plus d’actualité.
15) Enchaîner les deux commandes ‘L‘ suivie de ‘e‘. Le programme affiche « PI a effacer ?« .
16) Commencer par effacer la dernière, la n°7. Le programme affiche « Effacement en cours » et attire notre attention avec un BIP sonore. Avant de réitérer le prompt, il s’écoule plusieurs secondes. En effet, effacer un PI qui se trouve vers le début engendre le décalage de l’intégralité des emplacements qui suivent, qu’ils soient occupés ou non. Le listage de l’EEPROM qui suit l’effacement du PI confirme bien que la Cible qui était en emplacement n°7 n’est plus présente en mémoire non volatile et qu’il n’en reste plus que six.
17) Frapper ‘q‘. Bip sonore, texte « Fin du dialogue USB. » et présentation de la date et de l’heure sur l’afficheur LCD. La LED bleue est éteinte.
18) Tourner le codeur incrémental de trois pas dans le sens horaire pour faire afficher les paramètres des options. C’est bien la cible « Ma Maison. » qui est rechargée sur un RESET. À partir d’ici, c’est donc le premier PI qui sera rechargé par défaut.
19) Pour confirmer que c’est bien l’emplacement n°1 qui est placé en Cible par défaut provoquez un RESET avec le petit bouton de la carte NANO et reprendre les manipulations de (18).
20) Recommencer les actions pour à nouveau revenir en Menu du dialogue Homme/Machine. Si vous avez encore une difficulté, reprendre en (02).
21) Commandes ‘L’ suivie de la consigne ‘e’. On a vu qu’effacer la dernière fonctionne correctement. Cette fois on va désigner la première. Scongregneugneu ! le coup d’avant c’est la Terre qui a perdu son pôle SUD. Franchement je supporte. Mais cette fois c’est « Ma Maison » qui n’existe plus !!!
22) Le programme à confirmé qu’il efface correctement les PI des deux extrémités. Pour vérifier qu’il est aussi fiable avec les intermédiaires effacer le PI n°2 et le PI n°3 qui à ce stade sera celui de PARIS. OK, le logiciel fonctionne comme on le désire. On va tester l’analyseur syntaxique.
23) Commandes ‘e‘ et ‘0‘ comme cible. (Zéro et pas O majuscule.)
24) Tenter ‘e‘ puis ‘-3‘ comme cible et Tenter ‘e‘ suivi de ‘9‘. Il ne sera pas possible d’effacer des PI qui n’existent pas.
25) Effacer maintenant les trois derniers P.I. Les manipulations sont montrées sur la Fig.54 qui en A ne contient plus que deux PI. L’effacement en B ne laisse plus qu’une adresse. Enfin en C on élimine la dernière position, le logiciel attire notre attention avec un BIP sonore et en D précise que maintenant l’EEPROM est vide.
26) Tenter d’effacer un PI avec ‘e‘. BIP et « EEPROM vide ! »
27) Tester ‘L‘ : Même sanction. (On ne peut plus lister ou effacer des PI.)
Il est naturel de se poser la question :
– Quelle sera la cible rechargée par défaut sur RESET ?
La réponse est facile : Tester par vous-même :
28) Provoquer un RESET : Un BIP d’alerte nous prévient que quelque chose n’est pas correct.
Dialogue Homme/Machine : Ajout de PI.
Ajouter à convenance un ou des PI est indispensable, car il n’est pas question de faire appel à un programme tel que Ecrire_en_EEPROM_1.ino chaque fois qu’une nouvelle cible devient pertinente dans notre usage du petit appareil. On se doute que la Commande ‘A’ doit obéir à certaines règles de bonne conduite :
39) Maintenant que les formats vous sont familiers, vous pouvez vous amuser à ajouter les coordonnées de votre domicile, quitter, imposer de recharger ce dernier sur RESET et vérifier que pour l’indication de la distance (Loxodromie) le GPS indique bien zéro. C’est pas mal de manipulations à enchaîner, aussi prenez votre temps, ce sera un bon exercice de révisions.
Manipulations : (Suite)
40) On va tester l’analyseur syntaxique. Tenter ‘a‘. Latitude ? 1234567n. Pas de problème car le ‘n‘ a été changé en ‘N‘ durant la saisie.
41) Longitude ? 12345678S : BIP et Valeur incorrecte ! car S n’est pas valide en longitude.
42) Tester ‘a‘. Latitude ? 123456n : BIP et Valeur incorrecte ! car il manque un chiffre.
43) Continuer ‘a‘. Latitude ? 12345678n : BIP et Valeur incorrecte ! car cette fois il y a trop de chiffres, du coup le ‘N‘ n’est pas au bon endroit et l’analyser syntaxique se fâche.
44) Proposer ‘a‘. Latitude ? hhhhhhhn : Pas de BIP et la valeur est acceptée !
CONCLUSION : L’analyseur syntaxique vérifie la longueur de la coordonnée, les indicateurs ‘N‘, ‘S‘, ‘E‘ et ‘W‘. Il ne vérifie pas la cohérence de la valeur numérique.
Dialogue Homme/Machine : Saturation de l’EEPROM.
L’analyser syntaxique vérifie la longueur des données de position et leur cohérence. Nous avons vu qu’il ne vérifie pas les caractères qui logiquement devraient être des chiffres. Il vérifie encore moins la vraisemblance des positions indiquées. Par exemple il acceptera sans siller une latitude de 99 degrés ce qui naturellement est totalement illogique de même qu’une longitude de 999 degrés. Effectuer des vérifications sur les chiffres imposerait un gros travail logiciel et la place pour loger le code n’est plus disponible, on va y revenir. L’expérience acquise lors des innombrables vérifications effectuées en cours de développement m’a montré que ce n’est pas en donnant les informations de position que l’on se trompe, d’autant plus qu’elles sont faciles à relire. C’est principalement lors de leur détermination sur Google Maps que le risque de se tromper est significatif. Il reste à vérifier le comportement du programme si on tente d’ajouter un PI et que les trente postes sont déjà utilisés. (Ce qui est peu probable ou alors c’est que vous voyagez beaucoup !)
Manipulations : (Suite)
45) Franchement, se « cogner » trente adresses est tellement indigeste que j’ai de loin préféré improviser un petit logiciel qui sature l’EEPROM à ma place, quitte à avoir des doublons, des triplons et des trucplons. Téléverser l’outil Emplir_EEPROM.ino dont l’identificateur pas très « parlant » est choisi pour qu’il soit placé en tête dans l’explorateur de Windows.
46) Téléverser immédiatement Application_GPS_1.ino pour pouvoir manipuler.
47) RESET et BPC pour revenir dans le Menu du dialogue Homme/Machine sur USB.
48) Commende ‘L‘ : On dispose bien de 30 PI avec certains en triple ou en quadruple. Ils sont tous cohérents et rien n’interdit de les collectionner. (Pas très logique mais toléré.)
49) Provoquer un RESET et cette fois refuser le dialogue USB. Tourner le bouton du codeur incrémental dans les deux sens. Il est effectivement possible de charger n’importe lequel d’entres eux au moment d’un RESET. On peut aussi faire tourner précipitamment le codeur pour effectuer rapidement des sauts dans un sens ou dans l’autre.
50) Revenir dans le Menu du dialogue Homme/Machine sur USB.
51) Tenter la Commande ‘a‘ : BIP et EEPROM pleine ! Il n’est plus possible d’ajouter un PI, il faudra impérativement libérer un ou des emplacements avec ‘e‘.
52) À titre d’exercice repérer le contenu du n°16 par exemple et l’effacer. C’est un peu long.
53) Continuer en effaçant le premier. C’est encore bien plus long car cette fois c’est toute l’EEPROM qu’il faut translater.
54) Insister en effaçant la dernière. Cette fois c’est très rapide car on ne déplace que 33 octets.
Dialogue Homme/Machine : OUPS … j’ai oublié la commande ‘D’.
Emporté par l’expérimentation d’Effacer, Ajouter, Lister et observer le comportement de l’analyseur syntaxique, j’allais oublier la Commande ‘D‘ qui pourtant est bien indiquée lors de l’affichage par la consigne ‘?‘. Cette fonction permet de permuter deux PI pour en changer l’ordre dans la mémoire EEPROM. On peut inverser les positions dans les deux sens.
Manipulations : (Suite)
55) Commençons d’échanger le premier et le dernier : ‘d‘ puis ‘27‘ et enfin ‘1‘ … ça fonctionne.
56) Dans l’autre sens et des PI du « centre » : ‘d‘ puis ‘5‘ et enfin ‘22‘ … ça roule également !
57) Tester ‘d‘ puis ‘0‘ … BIP et Nombre incorrect comme punition.
58) Tenter ‘d‘ puis ‘3‘ et enfin ‘29‘ … même punition.
L’analyseur syntaxique interdit toute tentative d’inverser deux emplacements si l’un d’eux n’existe pas. Reste à tester les incongruités logiques :
59) Armez-vous de courage et effacer tous les P.I. sauf le premier. Pour minimiser les temps d’effacement indiquer chaque fois le dernier PI.
60) Quand il ne reste plus qu’un seul PI, soumettre ‘d‘ puis ‘1‘ et enfin ‘1‘ … BIP et le texte d’erreur Echange 1 avec 1 ??? qui montre qu’un échange « doublon » sera refusé.
61) Effacer le dernier PI. Puis ‘d‘ qui nous gratifie de BIP et EEPROM vide !
L’analyseur syntaxique ne se laisse pas faire. La fonction de permutation entre deux PI présente un comportement sain. Commande ‘a‘ pour ne pas laisser l’EEPROM vide …
On vient de vérifier que même si l’EEPROM est très encombrée, gérer les PI reste parfaitement cohérent. Pratiquement toutes les fonctions sont surveillées par l’analyseur syntaxique. On peut considérer que le programme est fiable et validé. Il reste encore à aborder le problème de la collision de la PILE avec le TAS.
Collision de PILE !
Grâce à cette expérience qui va changer votre vie, (C’est une boutade !) vous allez non pas assister à une collision entre deux véhicules automobiles, de deux aéronefs, de deux particules dans un cyclotron apériodique, de deux discutions qui dégénèrent, mais à une Collision de PILE ! On peut affirmer sans risquer de se tromper, que si à un moment donné votre programme se met à « diverger » alors que l’on a ajouté une « bricole » qui ne devrait pas le perturber, c’est qu’il y a une forte probabilité de collision entre la PILE avec le TAS. Pour rencontrer ce phénomène le mieux est de l’expérimenter :
Manipulations : (Suite)
62) Téléverser le démonstrateur Experience_23.ino copie conforme de Application_GPS_1.ino qui à ce stade ne comporte que des remarques en plus.
63) Pour comprendre en détails ce que signifie Collision de PILE commencer par consulter dans le dossier <Documents> le fichier Collision_entre_la_PILE_et_le_TAS.pdf, on peut maintenant passer à la suite : Activer le Menu du dialogue Homme/Machine sur USB.
64) Proposer la commande ‘m‘. Le programme précise sa version. Et surtout il nous indique que la place qui reste dans la mémoire dynamique fait 298 octets. Compte tenu des campagnes de test effectuées on a validé sérieusement le programme et l’on peut considérer sérieusement qu’il est stable.
65) Modifier le programme pour ajouter une fonction qui aurait été bien utile : La commande ‘G‘ qui permet d’effacer d’un coup tous les PI sauf le premier :
• Transformer la ligne 545 et la ligne 553 en remarques.
• Valider la ligne 445 ainsi que la ligne 565.
La taille du programme passe de 21592 à 21806 octets et surtout l’espace occupé en mémoire dynamique monte à 84%. On va voir que maintenant le programme « diverge ».
66) Téléverser une deuxième fois Experience_23.ino.
67) Activer le Menu du dialogue Homme/Machine. On observe en Fig.55 A la présence de la nouvelle fonction.
68) Tester ‘L‘ , ‘?‘ … tout semble normal.
69) Proposer ‘m‘, le logiciel se présente et annonce en B que l’espace en mémoire dynamique ne fait plus que 193 octets. Avec certains programmes ce serait suffisant mais pas ici car le code empile pas mal de données temporaires.
70) Lorsque la Commande est en attente, frappez un texte de longueur exagérée tel que trente fois ‘a‘ par exemple. L’accusé de réception en C est correct, mais seuls cinq caractères ont été retenus alors qu’il devrait y en avoir seize. Ce n’est pas normal et l’ajout de A ne peuvent pas avoir cet effet.
71) Essayer en D d’ajouter un PI. Impossible, le programme ne récupère plus tous les caractères frappés dans la ligne de saisie. Hors nous n’avons fait qu’ajouter une fonction de plus qui en aucun cas ne devrait avoir d’effet sur celles qui fonctionnaient parfaitement avant. On ne peut soupçonner alors qu’un effet de collision de PILE.
Conclusion : La conséquence prédite par le message d’alerte du compilateur n’est pas systématique. Toutefois, quand cette ligne orange est affichée, il vaut mieux faire « le test de collision de PILE » et surtout si brusquement le logiciel ne se comporte plus « comme avant », soupçonner une collision de la PILE avec le TAS.
Remède : Libérer de la place en occupation de l’espace réservé aux données temporaires et locales. Ce n’est pas forcément évident, mais l’un des moyens les plus efficaces pour y arriver consiste à placer les textes du dialogue H/M en mémoire non volatile EEPROM. (Voir l’application n°2.)
Considérons que le programme Application_GPS_1.ino est aboutit et remplit assez bien les objectifs fondamentaux de ce type d’appareil. On a appris à extraire les informations arrivant « des étoiles » et tel qu’il est, notre petit instrument est déjà bien sympathique. Il reste toutefois un regret à formuler. Dans cette application on n’utilise pas la possibilité potentielle d’extraire du GPS notre vitesse par rapport au sol ainsi que notre cap. Pour développer ces fonctions il faudrait pouvoir les vérifier, c’est à dire embarquer notre module dans un véhicule automobile et observer son comportement. C’est faisable, encore faut-il qu’il soit autonome. Hors je ne dispose plus dans « mes stocks » de composants électroniques d’un afficheur vraiment de type LCD c’est à dire qui n’a pas besoin de rétro-éclairage. Celui des expérimentations est actif et consomme beaucoup trop pour envisager de l’alimenter avec un petit accumulateur 9V. Aussi je repousse ces études à une version utilisant un afficheur graphique infiniment moins gourmand en énergie que mon module prétendu LCD.
La suite est ICI
