09) Sixième et septième application autonome.

Comme pour Application_GPS_4.ino avec Application_GPS_6.ino on reprend strictement les mêmes fonctions. Le comportement du programme est strictement identique. La seule modification consiste à changer un peu l’organisation des Entrées/Sorties pour faciliter la réalisation du circuit imprimé. Pour mémoire, la dilution n’est plus indiquée. Le cheminement simple est sans indication de la distance qui reste à parcourir. Le dialogue USB permet avec ‘g‘ d’effacer tous les PI sauf un, avec une seule commande. C’est à ce stade qu’est réalisé le circuit imprimé pour rendre vraiment autonome et surtout « mobile » le petit instrument. Toutefois, le chapitre de réalisation du coffret est décrit plus loin, car je préfère regrouper ceux concernant les dernières versions logicielles.

Version logicielle avec mode cheminement amélioré.

Cette nouvelle proposition ne remet absolument pas en cause le matériel. Électronique terminée et intégrée dans un coffret qui en fait un appareil autonome, on peut à tout moment changer le programme car la mini-prise USB qui permet de téléverser les croquis est directement accessible. C’est du reste un impératif pour effectuer le dialogue Homme / machine de gestion des PI en EEPROM. Cette version nommée Application_GPS_7.ino n’est qu’une variante de la précédente qui à pour motivation une idée d’utilisation qui a émergé juste avant de concrétiser le boitier. Quand on utilise le mode Cheminement, la seule information affichée est la distance qui nous sépare « à vol d’oiseau » du prochain point de passage. Il semble séduisant de remplacer cette approche par une fonction qui indique aussi la distance totale qui reste à couvrir en supposant que la route entre chaque point de passage est une loxodromie, car il faut bien reconnaitre que la distance à vol d’oiseau est certes une information souvent étonnante, mais moins intéressante que la distance qu’il faut encore franchir pour arriver à destination. Bien que calculer une distance totale en ajoutant la longueur de divers segment puisse sembler élémentaire, dans la pratique c’est assez compliqué car on se heurte à une succession de formats dont il faut gérer les spécificités, ces adaptations générant une boulimie en octets de programme. Pour arriver à loger le code spécifique au calcul des distances, il est devenu impératif de dégager de la place en zone réservée au programme. Du coup j’ai sacrifié l‘une des fonctions que je préfère, mais qui reste assez secondaire vu que peu d’internautes se rendront à des distances qui justifient le planisphère à l’affichage. Ce n’est pas tragique, car Application_6 et Application_7 ne sont différentes que par leur croquis, les données en EEPROM restant inchangées. On peut à tout moment téléverser l’une ou l’autre à notre convenance. Sur la Fig.98 actuellement on va vers la Cible n°2 en EEPROM et on en est éloigné de 6,73km. Le trajet complet comporte trois villes de passage pour aller jusqu’à la destination qui en EEPROM est le PI n°6. Noter dans l’encerclé les deux accentués réalisés avec trois PIXELs pour chaque élément. Comme la circulation routière nous oblige à emprunter des trajectoires sinueuses et que les longueurs calculées entre les segments sont des loxodromies, pour afficher des valeurs plus proches de la réalité, les nombres calculés sont majorés avec un coefficient de 1.28 évalué expérimentalement. Pour pouvoir éventuellement l’affiner suite à de plus amples expérimentations en situation réelle, il suffira de modifier la directive #define Correction_distance 1.28 située en tête de programme. Si dans les options nous avons choisi le Mn au lieu du Km, c’est que le mobile est maritime ou un aéronef. Dans les deux cas on navigue en « ligne droite » et le coefficient de correction n’est pas appliqué par l’algorithme. Dans le programme, pour effectuer les calculs utiles à Affiche_la_PAGE_7() on utilise les coordonnées en EEPROM qui sont exprimées en degrés. On doit transformer les décimales des degrés en minutes d’angles. La chaîne de caractères est transformée en un float sur lequel on applique le coefficient 60. Puis il faut le reconvertir en chaîne de caractères pour loger l’équivalent de ce nombre en Tampon_GGA[]. Il serait possible d’utiliser la fonction String pour effectuer cette traduction. Si vous allez décortiquer les séquences de calcul vous constaterez que je n’ai pas utilisé cette facilité et codé par un algorithme personnel. Dans la pratique, j’ai éliminé l’option String car un seul appel à cette dernière consomme 1684 octets. Grâce à toutes les optimisations réalisées, le programme actuel ne consomme que 30522 octets. Au final il nous reste encore 198 octets pour modifier ou corriger le logiciel. Profitant du fait qu’il restait de la place disponible en mémoire, de petits détails esthétiques ont été apportés comme en Fig.99 l’encadrement de la Marge ou en Affiche_la_PAGE_3() la valeur de la vitesse sol en double taille. PILE – TAS dépasse les 650 octets : Donc le programme sera stable.

Format Google ou position en degrés, minutes et secondes d’angle.

Presque au bout, c’est l’avant dernière version du programme. Pour valider les fonctions de positionnement, on utilise la cartographie de Google Maps qui nous le savons est forcément entachée d’une imprécision inhérente à la précision du point sur un écran numérique. Pour le plaisir, lorsque je suis arrivé à destination, je note la position indiquée par le GPS qui est forcément plus précise. L’idée consiste alors à utiliser les valeurs GPS pour remplacer celle un peu approximatives en EEPROM. Le hiatus, c’est que notre GPS donne la position en degrés, minutes et secondes, alors qu’en EEPROM les coordonnées sont en degrés et ses décimales. Aussi, pour nous éviter d’avoir à transposer, les calculs à effectuer n’étant pas toujours évidents, l’idée consiste à ajouter dans les initialisations sur RESET une option « Google » sous laquelle, le format d’affichage pourra être celui de la Fig.71 E en page 38 ou un affichage de position au format adopté sur Google Maps. Sur la Fig.100 et la Fig.101 qui montre les deux options quand on tourne le codeur incrémental, on constate qu’au final c’est l’écran monochrome bleu qui équipe la version définitive dans le coffret. Comme pour les autres options, lorsque le choix que nous voulons privilégier est affiché sur OLED, en cliquant sur le BPC on valide l’option, et comme c’est la dernière dans la liste, on entre dans le Menu de base du GPS. Naturellement l’option est inscrite en EEPROM et rechargée de façon automatique lors de la mise sous tension de l’appareil. La Fig.102 qui est à comparer avec la Fig.71 E présente l’affichage au format « Degrés angulaires » et décimales. Ce sont exactement ces valeurs qu’il faut proposer en EEPROM pour définir un point d’intérêt. Seuls les chiffres sont indiqués dans la ligne de saisie du moniteur, sans le point décimal. Sur la Fig.103 dans les encadrés jaunes A et B on observe que le choix effectué sur RESET est ajouté dans la page des options sur la même ligne que celle qui précise les unités pour indiquer les distances. Pour pouvoir indiquer cette option, il a été indispensable de libérer de la place dans l’espace réservé au code objet. C’est la fonction ‘g‘ du dialogue USB qui a été sacrifiée. Si on désire tout effacer (Sauf un PI nous le savons.) il faudra enchaîner neuf fois la fonction ‘e’ ce qui n’est pas tragique du tout. À ce stade du développement, le programme consomme 30702 octets sur 30720 de disponibles, autant dire que l’ATméga328 est bien rentabilisé. Il est peu probable que les 18 octets qui restent puissent être suffisants pour corriger une éventuelle vermine, il serait alors indispensable de générer de la place. Il suffirait d’enlever ici ou là un complément « de luxe » tel qu’un accentué généré par pixels par exemple. Bref, c’est la vie banale du programmeur fut-il de loisir. L’espace entre la PILE et le TAS est de 633 octets à l’ouverture du dialogue avec le Moniteur USB. En faisant appel aux diverses fonctions de ce dernier suivi par ‘m‘ on constate que l’intervalle peut diminuer de quelques octets, mais relativement peu. Aussi, avec un espace de plus de 600 octets je peux vous assurer de la stabilité du programme. S’il advenait qu’il présente un comportement imprévu, c’est dans les algorithmes qu’il faudrait alors chercher la source du problème. Enfin, dans l’EEPROM il reste encore un peu de place pour loger des textes. Les utiliser obligerait à modifier un peu Ecrire_en_EEPROM_3.ino mais reste un moyen aisé pour diminuer d’environ 39 octets la taille du programme … c’est déjà ça de gagné. Pour pouvoir mettre au point la page qui affiche la vitesse et le cap, terminer la réalisation matérielle pour faire du dispositif un appareil autonome est indispensable. Le bout du tunnel est en vue !

La suite est ICI.