13) Dernière application autonome.

Cette expérience Application_GPS_9.ino n’est qu’une variante dans laquelle on utilise la carte Arduino un peu spécifique de la Fig.117 qui incorpore sur le circuit imprimé un afficheur OLED de définition 128 x 32. Elle présente le même format qu’une carte Arduino NANO en étant juste plus large de 5mm. Ses caractéristiques sont strictement identiques à celles d’une NANO, mis à part le fait que A4 et A5 sont réservées et reliées à SDA et SCL de l’afficheur. On pourrait à juste titre se demander pourquoi la version avec coffret n’est pas décrite la dernière. Je n’avais pas envisagée cette ultime proposition, car impossible depuis plusieurs semaines d’arriver à faire fonctionner cette carte. Et puis, alors que je n’ai pas encore mis en ligne, j’ai réussi à téléverser du code et trouvé la bibliothèque adaptée à ce module. Bien qu’ayant utilisé CH34x_Install_Windows_v3_4.EXE, le dialogue entre le PC et la carte s’avérait impossible. J’ai tenté de remplacer le Boot Loader depuis une carte Arduino UNO et les téléversements ont immédiatement fonctionné. Enfin, j’ai rencontré de réelle difficultés à me procurer une bibliothèque U8g2lib.h qui soit acceptée par le compilateur. Aussi, je vous la fournit dans le dossier <EXPERIENCE_30>. À toutes fins utiles, je vous propose également dans le dossier <EXPERIENCE_30> trois petits démonstrateurs qui m’ont permis de tester les instructions de base de cette bibliothèque dédiée à l’afficheur local à cette carte Arduino. C’est l’un d’eux qui sur la Fig.117 sert à tester l’afficheur, conjointement au codeur incrémental. Sur la Fig.118 on peut voir le montage provisoire de mise au point du programme. Il est évident que si vous adoptez cette carte, l’électronique sera plus compacte et il vous faudra adapter les dimensions du coffret et simplifier le circuit imprimé pour optimiser l’ensemble. Compte tenu de la faible résolution verticale de l’afficheur, le concept qui préside la conception du programme consiste à adopter la police de caractère la plus grande possible, permettant comme pour la version Application_GPS_1.ino de disposer de deux lignes de 16 caractères. Nous allons donc reprendre globalement les pages-écran de l’afficheur LCD avec juste en plus l’encadrement extérieur comme sur la Fig.117 qui constitue un test d’utilisation de l’afficheur avec le codeur incrémental relié au module Arduino. Il aurait été plus séduisant de ne pas encadrer et d’employer une police de caractère plus grande, mais parmi toutes celles disponibles et compatibles qui permettait de loger 16 caractères en largeur reste introuvable.

Lorsque l’on effectue un RESET ou à la mise sous tension, la première .
page-écran qui sera affichée est celle de la Fig.119 qui présente la Date ainsi que l’heure. La date ainsi que toutes les données issues du système ne seront correctes que lorsqu’un minimum de satellites sera capté dans des conditions utilisables. Comme montré sur la Fig.120 le changement de l’heure est cadencé au rythme de réception des groupes de données, c’est à dire une fois par seconde. Sur la Fig.119 on peut observer que la LED rouge PW de la carte Arduino qui était vraiment trop lumineuse se fait discrète, car elle a été masquée par de l’encre de chine noire. Elle reste toutefois légèrement lumineuse pour permettre des vérifications tout en laissant la vedette à la LED sur D13 et celles de TX et RX. Noter au passage que dès le démarrage du programme une LED jaune sur D6 s’illumine durant le traitement des données en moyenne une fois par seconde pour témoigner du bon fonctionnement de la boucle de base.

Les manipulations logicielles indispensables.

Attention, le programme Application_GPS_9.ino ne fonctionnera pas si vous vous contentez de le téléverser directement. Il faut au préalable utiliser deux outils logiciels. Bien que ce soit précisé en tête de listage, il me semble raisonnable d’insister ici sur ce préalable impératif. Avant de pouvoir utiliser ce croquis d’exploitation, il faut commencer par téléverser Ecrire_en_EEPROM_2.ino sur la carte Arduino et surtout activer le Moniteur de l’IDE pour que les données de base soient effectivement inscrites en EEPROM. Au départ il sera également indispensable d’inscrire des points d’intérêt en mémoire non volatile en utilisant l’outil nommé Emplir_EEPROM.ino mais ATTENTION : Prendre celui qui est rangé dans le sous-dossier <Experience_30> qui regroupe les démonstrateurs relatif à cette version ultime du GPS. (Nécessaire car sur RESET le programme charge en mémoire vive le P.I. par défaut.)

Les écrans de base dans le sens horaire.

Tout changement de position du codeur incrémental allume la LED bleue pour nous informer que l’action à été prise en compte. Elle s’éteint lorsque le programme qui doit terminer la séquence en cours commence à traiter la requête de changement de Page-écran. Dans l’ordre croissant, c’est à dire pour une rotation dans le sens horaire, on voit défiler les uns après les autres les écrans de la Fig.119 à la Fig.123 qui enchaine sur la page qui ouvre la fonction de cheminement explicitée dans le chapitre suivant. En Fig.121 l’appareil précise la distance qui nous sépare de notre cible qui par défaut est chargée depuis l’EEPROM sur RESET. En Fig.122 ce sont les coordonnées géographiques de positionnement qui sont indiquées. C’est un peu le minimum que l’on puisse exiger d’un GPS ! La page de la Fig.123 indique le décalage en hauteur par rapport au niveau moyen des océans sur la ligne du haut. Sur la ligne du bas le programme précise le nombre de satellites en poursuite et le nombre de ceux utilisés pour extraire les données de positionnement. (Comme déjà précisé, tant que le nombre de satellites en position favorable n’est pas suffisant, les données affichées par notre GPS sont incomplètes ou incorrectes.) Enfin, lors d’un RESET ou étant en page de la Fig.119 on tourne le codeur incrémental dans le sens négatif, on ouvre la page de la Fig.124 qui précise l’état des deux options qui peuvent être librement modifiées lors du dialogue homme / machine sur RESET décrit plus avant.

La fonction cheminement.

Déjà développé en page 45 et en page 50, le principe est strictement analogue, seule la façon de saisir les deux jalons de début et de fin diffèrent ainsi que la présentation de l’écran durant l’utilisation de cette fonction. Comme pour Application_GPS_8.ino l’ouverture du mode cheminement commence par saisir en Fig.125 le point d’intérêt d’ARRIVEE de notre route. Pour montrer que l’on est en phase d’itialisation du cheminement, l’écran ne trace pas l’encadrement. La rotation du codeur incrémental fait défiler en ligne du bas les noms des PI disponibles en EEPROM. Pour mémoire ils doivent être placés les uns à la suite des autres. Aussi, pour faciliter le travail, demandant la cible d’ARRIVEE le programme indexe la dernière disponible en EEPROM. Durant la rotation en fin de ligne du haut est précisé le numéro d’ordre en EEPROM du PI pointé. Pour valider on clique sur le BPC, la page écran de la Fig.126 s’affiche alors pour nous faire préciser le premier point de passage servant de cible. Tourner le codeur incrémental fait défiler les PI dans un sens ou dans l’autre en commençant par indiquer le premier situé en EEPROM car DEBUT doit dans cette dernière se trouver avant ARRIVEE. Cliquer sur le BPC fait passer en Fig.127 c’est à dire à l’affichage courant du mode cheminement. On retrouve l’encadrement dans la présentation des données. Sur la ligne du haut est indiqué le nom du prochain point de passage vers lequel on est en train de se déplacer. Sur la ligne du bas on trouve à gauche la distance qui nous en sépare. Sur la droite la distance qui nous sépare de la destination d’ARRIVEE. Les deux distances sont indiquées dans les mêmes unités et comme on peut le constater sur la Fig.127 et sur la Fig.128 on pourra à notre guise choisir entre les kilomètres ou les miles marins notés Nm. La difficulté de mise en page avec l’afficheur intégré à la carte Arduino réside dans ses polices de caractères dont la largeur des lettres est différentes en fonction de leurs formes. Par exemple le 1 et bien plus étroit que le 8 et sur la Fig.127 on voit que le point décimal de 21.73 est relativement petit et à peine visible sur la photographie pourtant saisie en « MACRO ». Par ailleurs, on désire pouvoir afficher les distances avec une précision de 10m. Hors, si on envisage un déplacement à un point opposé du notre sur la Terre, l’affichage devrait ressembler à 1234.56 / 22375.42 km. Une telle information est bien trop large pour l’écran. Aussi, j’ai adopté le compromis qui consiste à n’afficher les deux décimales que lorsque la valeur de la distance devient inférieure à 100 quelles que soient les unités adoptées. Ainsi, sur la Fig.127 on se trouve à 21,73km du prochain point de passage, avec les 100m et les 10m, lors que la distance jusqu’à l’arrivée est de 3456km, les décimales étant alors ignorées.

Le dialogue USB sur RESET.

C’est une solution qui impose l’utilisation d’un ordinateur avec l’IDE installé sur ce dernier. Du coup l’appareil n’est pas totalement autonome. En revanche, la gestion des PI en EEPROM est particulièrement agréable, et l’on n’a vraiment pas besoin d’avoir en tête tout un tas de protocoles. Le dialogue reprend strictement les techniques décrites en page 24 et page 25 avec quelques commandes différentes. Pour ouvrir le menu du dialogue série il faut :

Lorsque le dialogue série sur RESET démarre, le programme commence par préciser sa version dans la zone jaune. Puis, en deuxième ligne la « classique » information sur la place qui reste entre la PILE et le TAS avec pour « incidence » le regret qui clôture ce dernier chapitre. La zone bleue pastel est la liste des PI actuellement en EEPROM, leur nombre maximal étant de dix. Pouvoir les ordonner avec la commande « d » est important pour construire un cheminement. Les PI doivent se suivre dans l’ordre de rencontre sur la route. Par exemple ici, le cheminement prévu « commence » en n°2 jusqu’en n°5 en passant par le n°3 puis le n°4. Si on doit en ajouter, ils se trouvent forcément à la fin. Avec « d » il est facile ensuite de les ordonner. Dans cette liste, celui qui est chargé automatiquement sur un RESET est pointé par le texte <RESET. Il est facile à modifier avec la commande « p« . Trois options sont initialisables et leur état est précisé dans l’affichage du menu. En vert c’est uniquement le mode dialogue homme / machine sur RESET qui est concerné. En rose, ce sont les deux options pour le Menu de base. Chaque fois que l’on utilise « h » ou « n » l’option concernée est inversée. Son état dans le listage des commandes est alors mis à jour. Quand l’option Dst en Nautique est à OUI, les distances seront affichées en miles marins. À NON elles seront en kilomètres. Les commandes relatives à la gestion des PI en EEPROM sont repérées par les lignes oranges. Il aurait été logique de les regrouper dans le rappel des commandes. Toutefois, j’ai préféré les placer dans l’ordre alphabétique d’où leur dispersion apparente. Si certaines commandes ne vous semblent pas évidentes à utiliser, elles sont toutes décrites dans les chapitres précédents.
J’aurais bien aimé ajouter une Page-écran qui indique la vitesse du mobile ainsi que le cap suivi, ces deux fonctions étant au point sur Application_GPS_8.ino il suffirait de modifier la présentation des données à l’écran. Mais toutes les fonctions ajoutées obligent à placer des textes directement dans le programme. Nous savons que les textes, même s’ils ne sont utilisés que pour des menus, c’est à dire qu’ils sont des constantes, pour le compilateur ils sont considérés comme des tableaux de char. C’est la double peine, car chaque texte augmente la taille du programme de sa longueur, mais surtout diminue d’un même nombre d’octets la zone libre entre la PILE et le TAS. Dans l’état actuel du logiciel d’exploitation, il n’est plus possible d’ajouter du texte en EEPROM, et PILE – TAS = 190 à l’ouverture du dialogue Homme/Machine. C’est tout juste suffisant pour ne pas se heurter à un problème de collision de pile. Du reste, le phénomène se produisait quand j’ai ajouté Affiche_la_PAGE_6(). Pour arriver à faire fonctionner le programme, j’ai été obligé de réduire certains textes et d’adopter un style plus « télégraphique » pour arriver aux 190 octets actuels. Donc, bien qu’il reste encore plus de 3000 octets de disponibles en mémoire de programme, permettant d’ajouter encore beaucoup de code, il est difficile de compléter avec des fonctions, car chacune imposerait du texte sur l’écran, et actuellement ce n’est plus envisageable.

La suite est ici.