07) Quatrième application autonome.

Intégrant un petit afficheur OLED bien moins gourmand en énergie que mon module LCD avec rétro-éclairage, il sera alors possible d’utiliser un banc d’essai en autonomie dans un véhicule automobile et tester la possibilité d’extraire des données satellites la vitesse sol et le cap actuel. Les afficheurs OLED existent en taille et en définition très variables. Je vais donc pour cette application utiliser celui de 1,3 pouce de diagonale monochrome disponible dans mes composants prévus pour expérimentation. Ce modèle existe en blanc ou en bleu. Au final, il me semble plus rapide de reprendre Application_GPS_3.ino et de remplacer une à une les routines d’affichage que de tout reconstruire à partir d’Experience_19_Noyau.ino. Ce travail préparatoire sera effectué dans le démonstrateur Expérience_28.ino avant de tester de nouvelles fonctions.

Experience_28 : Préparation de l’Application autonome n°3.

Coté matériel, l’architecture électronique s’oriente vers le schéma proposé dans la Fiche n°21. Avant d’envisager la liberté, le système étant autonome et « transportable » pour pouvoir être expérimenté dans un véhicule automobile en déplacement, il faut réécrire les fonctions pour présenter les informations sur l’afficheur OLED. Le dialogue Homme/Machine sur la ligne USB reste strictement inchangé et l’ordre de saisie des options sur RESET reste également le même. Seules les présentations à l’écran sont légèrement modifiées. ATTENTION : Sur la Fig.68 les mosaïques sont blanches et l’ordre Vcc et GND est montré dans l’encadré rouge. En fonction du fournisseur ces deux broches peuvent être permutées. Donc bien observer la sérigraphie pour la mise en œuvre correcte. Étant sur la page-écran de la Fig.68, si on clique sur le BPC on enchaîne sur le dialogue via le Moniteur de l’IDE sa sortie activant le Menu du GPS. Si l’option est sur NON on bascule dans les options de la Fig.69 du Menu du RESET. En A le programme précise qu’il y a actuellement huit PI en EEPROM et que c’est la 5 qui est indexée pour le chargement par défaut. En B est listé le nom de ce point d’intérêt. Tourner le codeur incrémental change l’indexation et liste en permutation circulaire les PI disponibles. Cliquer sur le BPC valide l’option et fait passer au choix de l’heure d’été ou d’hiver. Tourner le bouton change l’option, le BPC fait alors passer aux unités de distance et de vitesse. La validation de l’option active le Menu du GPS.

Le menu de l’Application autonome n°3.

Comme avec le type d’afficheur utilisé on peut présenter facilement jusqu’à quatre lignes de texte, nous allons en profiter pour réorganiser les fonctions de base et diminuer le nombre des pages-écran simplifiant ainsi l’utilisation de l’appareil. Les nouveaux écrans sont montrés dans l’ordre des photographies de la Fig.71 avec en Fig.70 l’attente d’un nombre suffisant de satellites. En C on retrouve un compteur qui recycle à 255 et qui permet à l’opérateur de vérifier que la boucle de base n’est pas inerte. Par ailleurs, toujours dans ce but, en mode GPS et présentation des données, la LED Arduino s’illumine durant l’affichage sur OLED. L’ordre des pages-écran en Fig.71 est dicté par l’importance que l’utilisateur accorde à leur contenu. Il est évident que d’une personne à une autre le point de vue pourra être totalement évident. Il vous sera très facile de le modifier. Il suffit dans le switch (Page_Ecran) de la procédure void Affiche_la_PAGE_Ecran() d’intervertir les indices de Affiche_la_PAGE_N(); dans les diverses lignes des instructions case. Pour ma part, c’est la page B qui sera probablement la plus utilisée. Toutefois, si j’ai mis en premier l’affichage A c’est qu’il saute plus aux yeux et permet du premier coup d’œil de constater que le nombre suffisant de satellites à été capté pour avoir des données cohérentes. L’affichage en C est provisoire. Cette troisième page sera consacrée à la vitesse sol et au CAP si j’arrive à extraire correctement ces données lorsque le GPS sera en mouvement.

Comme la page-écran C n’est pas encore validée, pour sa mise au point le contenu de la trame de type VTG est listée sur les deux lignes du haut. Les deux lignes du bas occuperont toute la page si ces séquences peuvent fonctionner. Comme en laboratoire le GPS est immobile, ces données ne sont pas cohérentes. Toutefois, dans une optique de mise au point du programme, les données sont extraites en position correcte dans Tampon_VTG[n] et coloriées pour faire ressortir la logique de l’extraction et de l’affichage. Si l’option choisie utilise les unités marines, le logiciel en tient compte tant en sélection des données que dans l’affichage des unités. Dans la page D sont résumées les options actuelles et dans la ligne du bas est précisée la tension en entrée Vin. Dans la troisième ligne est précisé le nom de la Cible. En E sont précisées les coordonnées géographique, l’altitude et la correction en hauteur Δh par rapport au géoïde de référence. La lettre Δ est remplacée par D pour ne pas avoir à la construire avec trois segments de droite ce qui alourdirait trop le code objet. Enfin en F sont résumés les facteurs de fiabilité. Sur la ligne du haut on lit qu’actuellement neuf satellites sont en visibilité mais que seulement sept sont en poursuite et aptes à servir aux calculs. Du facteur de dilution en est déduit le type de précision officiel, Nominale étant le meilleur. Enfin en ligne du bas on trouve le type de positionnement. Dans l’encerclé rouge on remarque que le caractère ‘e’ et bien accentué. Ce type d’attribut n’existe pas dans la police de caractères OLED. Aussi il est ajouté sous la forme de deux PIXELs moins gourmands en code objet que si l’on avait utilisé le tracé de lignes.

La liberté dans une boite de chaussures !

Boitier non encore réalisé, car le choix définitif de l’afficheur qui sera utilisé n’est pas encore décidé, pour tester en mobile le programme il faut bien organiser le banc d’essais pour qu’il soit transportable et autonome. La Fig.72 présente « le laboratoire embarqué » avec tous les éléments vitaux réunis dans le couvercle relativement rigide d’une boite de chaussure qui fait merveille. Pinces crocodiles 13 et 14 ainsi que plaque à essais 2 sont les deux mamelles de la mise au point du matériel et du logiciel. Ici en débranchant 13 on coupe l’alimentation par l’accumulateur rechargeable 11 ce qui permet alors de pouvoir brancher la ligne USB à l’ordinateur de

développement. En 1 on trouve une colonne qui supporte OLED bien au dessus des fils de liaison. En situation mobile ce support un peu haut est couché. En 3 un petit galvanomètre surveille le +5Vcc d’alimentation de la carte NANO. Très lumineuse en 6 se trouve une petite LED blanche d’éclairage local chaque fois que je dois modifier un branchement. Pour ne pas qu’elle n’éblouisse, en temps normal elle est insérée dans le petit « abat-jour » 4, mais ici elle s’est un peu écartée. Tout le long de la platine de raccordement 2 sur laquelle il y a Arduino, se trouve en arrière plan un complément expérimental 5 avec ampèremètre, huit LEDs de témoins logiques et des rampes de branchement. Pour ces activités elle est ignorée mais étant sur une semelle commune avec 2 elle est forcément présente et il ne faut pas en tenir compte. En 7 se trouve, pas très visible, le bruiteur et la LED orange mise en série. En 8 l’antenne du GPS est reliée à son module 9 et l’ensemble peut être placé horizontalement ou verticalement pour chercher si l’une des deux orientations ne serait pas plus favorable que l’autre. Le codeur rotatif relié avec des lignes un peu longues se trouve en 10 alors qu’en 11 se trouve le petit accumulateur de 9Vcc. Il est réputé présenter une capacité de 1000mAH. Des mesures ont montré que dans la réalité c’est assez exagéré. Le module GPS se taille la part du lion en gloutonnant ses 50mA. Le reste de l’électronique plafonne à 45mA. Avec une intensité de 95mA on peut toutefois espérer une autonomie comprise entre 4H et 6H à 7H, les mesures n’ont pas encore été effectuées pour le vérifier. Enfin, c’est toujours au moment d’utiliser un appareil que l’on réalise que les piles sont vides. Aussi, disposant d’un deuxième accumulateur qui a été chargé parallèlement à celui qui est en service, dans le boitier 12 ce trouve cet élément de réserve. Enfin, lors d’une « expédition expérimentale » il faut ajouter une petit carnet pour prendre des notes et naturellement … de quoi écrire. La toute première sortie est un échec, raison pour laquelle l’écran C conserve son aspect provisoire. Pour ne pas encombrer le didacticiel, le document Compte-rendu.txt détaille l’expérience.

La page de présence des satellites.

Gourmande en octets de code objet, elle sera toutefois retenue pour l’application n°3 car elle participe à rendre plus agréable l’utilisation du GPS et contribue à minimiser certaines séquences de code qui font gagner de la place pour le programme. Par ailleurs, à se stade on ne consomme encore que 85% de la zone mémoire dédiée au code objet, et toutes les fonctions désirées initialement sont en place. On n’exploite pas les données d’orientation des satellites ni leur élévation au dessus de l’horizon, mais ce sont vraiment des informations secondaires. Il sera certainement plus « amusant » d’utiliser les possibilités graphiques de l’afficheur que de consommer des ressources pour montrer ces indications peu importantes.

Bien que ce ne soit pas fréquent, il peut arriver que l’on capte jusqu’à quatre trames de type GSV. Comme chaque trame peut contenir jusqu’à quatre identifications de satellites, on peut avoir à afficher potentiellement jusqu’à 16 colonnes représentant le niveau de réception de ceux qui sont visibles. L’un d’entre eux peut fort bien avoir un niveau de réception nul comme le cinquième par exemple. Jusqu’à présent le plus fort niveau reçu et observé a été de 43. Si par la suite une valeur plus grade survenait, l’affichage déborderait en hauteur. Il suffirait dans ce cas de modifier l’instruction située en tête de listage #define MAX_NIV_sat 43.

L’application autonome n°4.

Elle reprend intégralement les fonctions des différentes pages-écran. Les protocoles d’initialisation des paramètres, le menu du RESET et le dialogue Homme/Machine avec le Moniteur de l’IDE sont inchangés. Naturellement, le schéma électronique reste intégralement celui présenté en Fiche n°21. L’un des avantages notable des afficheurs OLED réside dans l’aptitude à les piloter avec uniquement deux fils auquel naturellement on doit ajouter le +Vcc et GND. L’interface entre Arduino et le module électronique se fait par l’entremise des protocoles I2C. Pour les intégrer dans le logiciel on bénéficie de la bibliothèque « Two Wire Interface » native dans le compilateur. Pour celle et ceux qui désirent en savoir plus sur les protocoles I2C je vous propose les Fiche n°15 et Fiche n°16. Pour faire plus ample connaissance avec l’afficheur OLED de 1,3 pouce de diagonale, c’est la Fiche n°13 qu’il vous faut consulter. L’ordre d’affichage et un peu modifié. C’est toujours la page qui affiche la présence des satellites qui est présentée sur RESET. Mais on a intercalé une carte graphique qui affiche les contours de la France et y positionne le GPS et la Cible.

Construire le dessin de la France sur l’écran graphique.

Avec une définition de 64 x 128 points lumineux, il ne faut pas rêver, on ne va pas présenter une carte avec le nom des rues et représenter la maisonnette de Tante Gertrude. D’autant plus, que la France s’inscrivant globalement dans un hexagone, la surface utilisée sera pratiquement carrée. La définition devient 64 x 64 PIXELs et le dessin va ressembler à une caricature. Toutefois, dans le cadre d’une activité ludique, il serait dommage de ne pas aborder le graphisme en mode filaire. L’objet de ce chapitre est de vous présenter l’approche utilisée pour construire cette petite carte rudimentaire.

Première étape : Préparer le travail de codage en C++. Il serait totalement illusoire de se mettre face à l’écran et de commencer à programmer. La première phase consiste à définir ce que l’on désire obtenir. Pour ma part, j’ai réalisé un dessin que j’imprime sur une feuille de papier format A4 horizontal. Vous pouvez en faire autant car je vous propose dans le répertoire <DOCUMENTS> ce petit outil dans le fichier GRILLE pour OLED.pdf qui outre la grille précise les coordonnée de chaque ligne et de chaque colonne. Il sera alors évident de repérer la position de n’importe quel point. On commence par décider dans quelle zone sera représenté le dessin désiré. Dans notre cas j’ai opté pour un décalage complètement à gauche, laissant ainsi la possibilité à droite d’ajouter du texte. L’idée consiste alors à faire entrer l’intégralité des formes désirées de façon à ce qu’elles utilisent toute la Hauteur. On se doute que la belle carte de la Fig.74 ne sera pas possible la définition de l’écran étant bien insuffisante. Par ailleurs il faut choisir entre tracer toutes les frontières par des PIXELs qui se touchent, ou adopter un contour plus symbolique en traçant des segments de droite contigus. C’est cette deuxième option qui sera choisie, car avec environ 33 segments on arrive à tracer l’intégralité de la carte, alors qu’il faudrait définir environ 600 à 700 dalles pour tracer le contour, ce qui en terme de taille de programme est naturellement inenvisageable. Comme le montre la Fig.75 les extrémités des segments doivent être centrés sur des luminophores de la matrice lumineuse. Le contour obtenu avec des segments de droite reste une affaire de compromis entre un dessin séduisant et une économie de place en mémoire de programme. Divers essais ont montré qu’il était assez illusoire d’augmenter significativement le nombre des segments, l’augmentation du code n’étant pas compensée par une nette amélioration du tracé. Si vous le désirez il sera toujours possible d’ajouter quelques points dans les Alpes, les Pyrénées et la Bretagne mais ce sera peu visible sur le petit écran. J’ai un peu triché dans l’estuaire de la Gironde, (Voir l’encerclé marron dans la Fig.76) car Respecter la position du point de « fermeture » rendait le visuel peu évident. Au final cette fonction agréable à utiliser ne consomme que 7% de l’espace dédié au programme ce qui n’est pas exagéré, car les graphiques sont toujours boulimiques en octets de code objet. Sur la Fig.76 dans la copie d’écran en noir, il n’y a qu’un seul point représenté. Dans cet exemple, les coordonnées de la cible et celles du GPS sont identiques. C’est tout simplement que le véhicule automobile est arrivé à sa destination. Les séquences de calcul pour positionner les deux « points » ont été assez délicates à mettre au point. Aussi une campagne d’essais pertinente a été utilisée. Dans ce but, comme montré sur la Fig.77 plusieurs PI caractéristiques ont été ajoutés. Le premier en zone rose montré en A de la Fig.78 concerne PARIS. Sur tous les dessins de cette figure la position du GPS est repérée par le disque rouge. On notera au passage que chaque clic sur le BPC active ou désactive le tracé de la loxodromie entre le GPS et la cible. Par exemple en B cette dernière est invalidée. C’est Strasbourg en zone violette qui a été choisir car située le plus à l’Est. En C c’est BREST (Zone verte.) qui est sélectionnée car située le plus à l’Ouest. Son disque représentatif n’est représenté qu’à moitié, le coté gauche étant hors matrice de PIXELs. Pour repérer ce disque incomplet la loxodromie à été validée. Il importe de noter que le programme est simplifié et ne teste pas la position des deux disques. Si les positions sont hors de la France, ils seront tracés n’importe où. Par exemple en D c’est l’île de Pâques qui est ciblée alors qu’en E c’est le Pôle SUD. Nous avons déjà vu que la saisie des données de PI n’est pas analysée sur les valeurs indiquées. Alors la longitude de 900°W étant erronée, la loxodromie n’est pas verticale comme on s’y attendrait. Je vous invite fortement à tester avec Bordeaux, Marseille ou Dunkerque par exemple pour compléter les tests et valider la séquence.

Affichage du planisphère avec positionnement de la cible.

Constatant qu’il restait de la place pour loger du code et que dans mes applications je cherche toujours à « saturer » le matériel, j’ai décidé d’ajouter une page graphique couvrant l’intégralité du globe. Pour pouvoir voyager dans des contrées lointaines il faut disposer de temps de liberté et surtout de pouvoir financer les voyages. Il est assez-peu probable que ce sera la majorité des lectrices et des lecteurs. Toutefois, il m’a semblé séduisant de créer une petit GPS certes modeste, mais pouvant être utilisé n’importe où sur Terre. (J’ai limité les latitudes entre -50° et +70° pour des raisons précisées plus avant, mais je reste persuadé que pratiquement personne n’ira se perdre dans les deux « solitudes polaires ».) Par ailleurs, cette nouvelle fonction est particulièrement pertinente au point de vue exemple de programmation car elle réalise … l’impossible et on va y revenir. En première approche, j’avais envisagé comme montré sur la Fig.79A de représenter l’intégralité du globe. De fait, plus d’un tiers de la surface en hauteur était occupée par les régions polaires engendrant un tassement exagéré des continents habités. L’imprécision de positionnement qui résulte des informations données dans le document Cartographie et Loxodromie.pdf engendrait un positionnement un peu trop haut de la Cible qui sur cet écran est Point Hope. Bien trop au dessus de l’Alaska.

Comme aller dans ces régions désertiques glacée constitue un rare privilège d’exception, représenter ces zones « blanche » sur notre planisphère est strictement sans intérêt. J’ai donc recalculé tous les points représentatifs de la carte en limitant à -50° la latitude SUD et à +70° la latitude Nord. On peut observer sur la Fig.79B que le visuel est nettement plus crédible. D’autres parts le positionnement des points y est bien plus rigoureux. Enfin les graduations tous les 10° tant en latitude qu’en longitude sont plus faciles à tracer sur le petit écran.

Construction du planisphère.

L’impossible est contourné par logiciel. Avant de s’aventurer dans un travail aussi considérable que tracer segment de droite par segment de droite une carte sur un dallage de luminophores, il importe d’en vérifier la faisabilité. Pour tracer la carte de France, il a fallu 33 segments de droite. Chaque segment consomme 16 octets entre les coordonnées, les passages de paramètres et l’appel à la procédure. Pour tracer le planisphère, ce n’est pas moins de 178 segments sans compter les graduations. On aboutit à 16 x 178 = 2848 octets. C’est impossible car à ce stade il ne restait que 2406 octets de disponible pour le programme. Et pourtant on va rendre possible l’impossible !
ANALYSE : Quand on utilise une instruction de type u8g.drawLine(53,59,44,56); il faut pour chaque instruction préciser Xd, Yd, Xf, Yf. Hors sauf quatre cas particuliers, tous les segments sont contigus. Du coup on précise deux fois les mêmes points. Si l’on décrit les coordonnées dans un tableau de byte, il suffit de ne décrire qu’une fois chaque point. On divise déjà par deux la taille des données. Par ailleurs au lieu d’écrire chaque instruction de type u8g.drawLine on peut procéder par usage de boucles for. Pour l’ensemble de la carte on ne fait plus appel que 20 fois à cette procédure. Par adoption de cette approche, non seulement la fonction devient possible, mais entièrement émulée il reste encore 798 octets dans l’espace réservé au programme.

Détermination des coordonnées des extrémités des segments.

Sachant que le méridien zéro passe par Greenwich, il semble tout naturel de cadrer horizontalement la mappemonde en centrant ce méridien horizontalement. Du coup, la France qui adopte l’heure de ce méridien se trouvera centrée latéralement sur la carte. La première étape montrée en Fig.80A pour déterminer les positions des

extrémités des segments dans notre matrice de 128 x 64 points consiste à sélectionner la zone à représenter sur un planisphère et à y construire notre tracé en tenant compte du fait qu’il faut absolument aboutir à un compromis entre diminution maximale du nombre de segments et dessin résultant crédible. Comme on travaille sur une

grande surface, celle du fichier GRILLE pour OLED.pdf imprimé sur une page de format A4, on a tendance à exagérer la finesse du tracé d’autant plus que sur l’écran OLED deux lignes qui se touchent engendrent une surface et l’on ne distingue plus les deux segments. Sur cette mappemonde le méridien de Greenwich n’est pas centré. La première adaptation va consister à décaler latéralement l’ensemble pour centrer la « ligne bleue ». La deuxième modification nous oblige à centrer les extrémités des segments sur les luminophores de la mosaïque de l’afficheur OLED. On aboutit au compromis de la Fig.80B sur laquelle on constate que la France et l’Italie dans l’encerclé bleu sont plus détaillées que ne le montre le visuel sur l’afficheur OLED. Au détroit de Gibraltar les deux segments se touchent et sur OLED la zone reste assez confuse. Il est clair qu’il aurait été possible de simplifier quelques segments dans cette zone, mais à ce stade du développement ce serait du « gagne petit ». On remarquera que les trois segments verts « sortant du cadre » à droite n’ont pas été reproduits à gauche. Noyés dans les graduations de latitude ils n’auraient qu’ajouter de la confusion. Alors autant simplifier.

Un jeu d’essais complet.

Dans la mesure où l’on ne peut pas démonter la justesse d’un programme, il faut impérativement organiser une campagne de test la plus complète possible qui embrasse les cas classiques, et surtout les cas particuliers avec spécifiquement ceux qui engendrent des « effets de bord ». C’est particulièrement le cas sur un écran graphique où l’on va représenter la position de la cible par un petit disque qui peut se trouver centré sur le cadre extérieur de la carte. Il importe alors de vérifier que dans ces cas « marginaux » les tracés restent cohérents. Dans ce but nous allons sélectionner à la surface du globe des cibles situées dans des endroits caractéristiques et vérifier que les petits disques de situation sont correctement placés. Outre l’île de Pâques qui était dans la liste des PI logés en EEPROM, on va compléter notre campagne de tests par les villes ou les points singuliers listés sur la copie d’écran de la Fig.81 qui dans les zones jaunes situent des villes « à l’intérieur du cadre ». Sur toutes les photographies de l’afficheur OLED les cibles ont été surchargées par un petit disque rouge pour en faciliter le repérage. En A la ville de Sydney à été choisie car elle est loin à l’Est de l’hexagone et située très au Sud. Son positionnement sur la carte est parfait. Plus centrée en B et également très au Sud Johannesburg est également bien située. Enfin en C la célèbre Miami a été ajoutée car très éloignée à l’Ouest de la France et située dans l’hémisphère Nord. Globalement les placements sur la carte sont corrects, il nous reste à tester les cas extrêmes. On commence avec la ville d’Ushuaïa en D de la Fig.83, célèbre car c’est la plus au Sud dans notre monde. Pour sa part, Krasneno en E est située complètement à droite et vers le Nord. Enfin, Tout à l’Ouest de l’Alaska en F se trouve complètement à gauche Point Hope. Pour les deux extrêmes latérales le programme est également validé. Il reste encore à traiter le cas étrange du pôle Nord et du pôle sud qui sont deux points représentés ici par le cadre haut et le cadre bas sur toute la largeur de l’écran. On va tester avec diverses longitudes. En Fig.84 G le pole est positionné à 90° de latitude Est. En H il est à peine visible car tout en haut et tout à gauche de la matrice de PIXELs. Théoriquement il ne devrait pas se trouver sur l’écran car à +90° de latitude. Tout point situé plus haut que la latitude 70° Nord sera représenté sur le coté haut du cadre. Le demi-disque supérieur n’est pas représenté car hors mosaïques lumineuses. Pour les latitudes Sud on retrouve un filtrage analogue et toute latitude inférieure à -50° sera « rabotée » à cette valeur. Par contre, en K le disque symbole est entier car contenu dans la mosaïque contrairement à celui en J dont la moitié droite est hors luminophores. En K la longitude est nulle et le cercle semble placé sur la verticale à gauche de la latitude zéro de Greenwich tracée en pointillés. Le cadre est de largeur paire, alors le centre théorique est déterminé à ±1.

Sur toutes les images du chapitre précédent seul le disque représentatif de la Cible est représenté. Si l’on désire ajouter le symbole de position du GPS il suffit de cliquer sur le BPC qui se comporte comme une bascule de type OUI/NON. Pour différencier les deux repères, celui du GPS est légèrement plus grand. Du coup, on le constate sur la Fig.85 A, il masque complètement la France et l’Italie. Aussi, comme généralement nous allons utiliser ce petit appareil en France, j’ai pensé que de ne pas l’afficher par défaut serait préférable. Son affichage est donc une option. Noter qu’il faut cliquer assez longuement pour que le BPC soit pris en compte, car il n’est testé qu’une fois par seconde. Pour vérifier l’universalité de comportement du programme, en B nous avons voyagé virtuellement jusqu’à Miami. Il suffit dans le programme de modifier en true le false la ligne #define Voyager_a_Miami false située dans les paramètres en tête de listage. Du reste vous pouvez tester n’importe quelle autre destination en remplaçant les coordonnées dans l’instruction qui utilise if (Voyager_a_Miami).

Le mode cheminement.

Ayant intégré la fonction Planisphère, force est de constater qu’il reste encore 798 octets de disponible pour le programme. (En fait si on compile avec une version plus récente de l’IDE, par exemple la version 1.8 on gagnerait encore environ 1800 octets car elle est bien plus optimisée. C’est pour des raisons personnelles que je préfère la 1.7.9 et je ne passe à plus récent que lorsque je n’ai plus assez de place pour arriver à développer un projet plus conséquent.) Ne pas employer ces 798 octets, c’est un peu agassif, une sorte de gaspillage. Aussi, j’ai cherché une idée qui pourrait s’avérer séduisante, d’où l’idée de la fonction « CHEMINEMENT ». L’idée directrice est assez simple. Elle consiste à considérer qu’une suite de PI sauvegardés en EEPROM constitue une route que l’on désire parcourir jalonnée par ces points de passages. Quand on tourne le codeur incrémental en antihoraire, juste avant la page de l’affichage graphique de la France, on ouvre la Fonction Cheminement. Pour nous prévenir que l’on ne peut sortir de cette fonction qu’avec le BPC, la LED bleue s’allume jusqu’à revenir dans le Menu de base du GPS sur la page d’affichage de la date et de l’heure. En Fonction Cheminement la rotation du codeur incrémental fait changer de cible en permutation circulaire, les « sauts » étant imposés par le sens de rotation. L’écran OLED présente les informations de la Fig.86 qui précise qu’elle est la prochaine Cible et la distance à laquelle elle se trouve. Si durant le voyage on n’intervient pas, chaque fois que l’on va se trouver à moins de 2Km de l’un des jalons, le programme changera automatiquement de Cible et passera à la suivante sauf si c’est la dernière. Si par exemple on a changé de route pour éviter un incident et que le jalon prévu n’a pas été approché suffisamment, il suffit de tourner le codeur incrémental pour passer au suivant. L’implémentation de la Fonction Cheminement ne rend pas caduque le choix du PI par défaut car on doit pouvoir conserver cet automatisme, nous évitant d’avoir à choisir un PI chaque fois que le GPS est remis sous tension. Par contre, si on va un peu loin, et que le GPS soit coupé durant les pauses, il faut reprendre l’initialisation des phases A et B. En entrée de fonction, lorsque la LED bleue s’illumine, en Fig.87 A le programme nous invite à lui préciser le PI d’arrivée qui peut être n’importe laquelle des cibles enregistrées en EEPROM. Puis en B c’est le premier PI du cheminement qu’il faut indiquer au logiciel. Tous les PI trouvés dans l’ordre entre DEBUT et ARRIVEE constituent le cheminement supposé et seront surveillés au cours du déroulement du programme. (L’interface de dialogue commence par demander l’ARRIVÉE car ainsi on diminue un peu la taille du programme.)

Un petit exercice pratique.

Observant la Fig.81 on arrive à la conclusion que le voyageur va partir de France, aller à Krasneno, puis à Sydney, puis à Johannesburg pour finir à Point Hope. Soit il fait son voyage en vélocipède, soit il prend l’avion … et bonjour le réchauffement climatique ! Plus simplement, dans l’exercice qui va suivre, nous allons envisager le cas d’un transporteur qui va aller charger à PARIS, puis livrer à LYON et à MARSEILLES. Ce petit parcours à pour but de montrer que l’on peut loger un cheminement n’importe où en EEPROM. En situation de départ on a la liste de PI montrés sur le listage de la Fig.81 dans laquelle on doit faire un peu de place.
Manipulations :
01) Pour commencer sur une base commune, nous allons effectuer un RESET en ouvrant le Moniteur de l’IDE le BPC étant activé.
02) Attendre que la LED Arduino s’illumine et le relâcher.
03) Tourner le codeur incrémental pour faire afficher l’option OUI.
04) Cliquer sur le BPC : La liste des PI s’affiche dans la fenêtre contextuelle du Moniteur.
05) Effacer les trois derniers PI n°8, n°9 et n°10.
06) Ajouter PARIS comme premier jalon. (48886198N 00234655E PARIS. (Halles))
07) Déplacer ce PI n°8 en position n°4 à la place de Johannesburg.
08) Ajouter LYON comme deuxième jalon. (4576270N 00485100E LYON. (P Bocuse))
09) Déplacer ce PI n°9 à la place de celui de Point Hope en n°5.
10) Enfin compléter avec le dernier jalon. (4329312N 00537331E MARSEILLES)
11) Il nous reste à déplacer le PI n° 10 à la place de celui de Miami.
On se trouve avec l’organisation de la Fig.88 dans laquelle en vert se trouvent les PI déplacés, le but étant de montrer qu’un cheminement peut se trouver n’importe où en EEPROM.
12) Commande ‘q‘ pour quitter le dialogue USB et retrouver le Menu de base du GPS.
13) Revenir en arrière de trois pas pour activer la Fonction Cheminement.
14) Désigner MARSEILLES comme jalon.
15) Cliquer sur le BPC et indexer PARIS qui sera notre première cible pour le trajet envisagé.
16) Activer le BPC et aller sur la carte de France. L’image confirme la position.
17) Revenir sur la Fonction Cheminement. Et reprendre l’initialisation n°6 puis n°4.
18) Tourner le codeur incrémental et cette fois pointer LYON.
19) Sortir et revenir sur la carte de France : Lyon est bien situé sur le dessins.
20) Réinvoquer la Fonction Cheminement et réitérer l’initialisation n°6 puis n°4.
21) Enfin tourner le codeur incrémental pour désigner la destination d’arrivée.
22) Un clic un peu long sur le BPC pour retrouver le Menu de base du GPS.
23) Encore trois pas dans le sens antihoraire pour faire afficher la carte de France. OUF, la cité phocéenne est toujours au bon endroit.
Avec ces manipulations on a vu que chaque fois que l’on quittera un cheminement pour une quelconque raison, il faudra à nouveau réintroduire les jalons de DEBUT et d’ARRIVEE. Ce n’est pas tragique car c’est assez rapide. Si on a oublié l’ordre des jalons, dans un premier temps on peut tous les faire « défiler » à l’écran. Actuellement il ne reste plus que 48 octets de disponibles en mémoire réservée pour le programme, et l’EEPROM est saturée. Autant dire que pour la rentabilité matérielle on ne peut pas faire mieux, on a utilisé pratiquement toutes les ressources de l’ATmega328. Espérons que nous n’aurons pas besoin de place pour corriger d’éventuelles erreurs de programme !

La suite et ICI.