L’internaute qui lit ce didacticiel pourrait trouver étrange que l’on passe à une nouvelle version du petit GPS, alors que dans les précédentes l’affichage de la vitesse sol et du cap suivi ne sont pas encore validés et totalement mis au point. Il se trouve que les expéditions du genre de celle abordée avec la Fig.72 ne sont pas aisées à mettre en œuvre imposant des déplacements dans les activités ordinaires. Ce type d’expérience sera grandement facilité lorsque l’appareil sera fonctionnel dans un petit boitier. Hors, tant que toutes les options d’affichage n’auront pas été explorées, ne connaissant pas le composant final qui emportera ma préférence, il serait précipité de développer le circuit imprimé et d’agencer le coffret. Pour cette cinquième version, je vais conserver le codeur incrémental qui emporte ma préférence. Le logiciel sera entièrement refondu, car l’écran graphique sera ici un petit afficheur OLED de 0,96 pouce de diagonale qui pose de réels problèmes d’utilisation. Un peu petit pour ma vision actuelle, il n’emportera probablement pas mon choix, et ce d’autant plus qu’existant en bicolore il est alors affecté d’une discontinuité entre les deux mosaïques de luminophores. Il reste toutefois concevable que certaines et certains d’entre vous disposent déjà d’un tel afficheur et ne veulent pas investir dans un autre modèle. C’est pour ces lectrices et ces lecteurs que je vais reprendre entièrement les routines d’affichage ainsi que l’architecture du programme.
Rendre possible l’usage du petit afficheur OLED de 0,96′ de diagonale.
Bien que beaucoup plus petit en taille d’écran, il consomme bien plus d’espace en mémoire de programme et surtout en mémoire dynamique. En effet, sa police de caractères est nettement plus étendue et contient les accentués ainsi qu’une palanqué de petits symboles dont nous n’avons que faire. Qui dit police de caractères dit tableau logé à la fois dans le programme, mais également sur le TAS. Du coup, à peine avons-nous rédigé les routines de calcul et celles pour afficher la PAGE_1 et la PAGE_2 que le programme se bloque par collision entre la PILE et le TAS. La seule façon de pouvoir loger tout ce petit monde dans les ressources de l’ATmega328 consiste à ranger tous les textes en EEPROM et à abandonner certaines fonctions « secondaire ». Dans ce but, les textes affichés pour le dialogue H/M sur USB ont été allégés au maximum. On libère ainsi de la place pour les textes des fonctions du Menu du GPS. Par ailleurs, pour simplifier le programme et éviter des doublons, toutes les initialisations seront effectuées dans le Dialogue USB dont le menu devient celui de la Fig.89 où les lettres minuscules ne sont plus précisées. Pour la bascule sonore c’est la lettre ‘B‘ qui est choisie car le texte « BIP » est plus court que « Silencieux« . Pour la saison et les unités, l’optimisation conduit à ‘H‘ pour l’heure d’Hiver et ‘K‘ pour les distances en Kilomètres. Comme pour BIP, chaque utilisation de ‘H‘ ou de ‘K‘ inverse l’option et de plus l’inscrit en EEPROM. Aussi, pour faciliter l’usage du petit appareil, l’état actuel enregistré en mémoire non volatile est précisé et repéré dans le cadre rose . Toutes ces optimisations ne sont pas suffisantes pour dégager suffisamment de place entre la PILE et le TAS. Pour libérer 34 octets on abandonne l’affichage de la vitesse et du cap qui n’ont toujours pas été validés et on supprime Tampon_VTG[34]. À ce stade du développement le Dialogue USB est entièrement développé et il reste 254 octets entre la PILE et le TAS ce qui pour le moment semble suffisant. (La suite confirmera ou infirmera, car pour l’Application n°4 on en a 280 pour assurer sa stabilité.) Pour ouvrir le menu du Dialogue USB on active l’IDE sur un croquis quelconque, on maintien cliqué le BPC, on active le Moniteur. On attend que la LED d’Arduino s’illumine et l’on libère le BPC. L’écran OLED présente l’affichage de la Fig.90 et la LED bleue s’illumine. La fenêtre contextuelle du Moniteur affiche la liste des commandes suivie de la liste des PI actuellement disponibles en EEPROM. On peut alors utiliser toutes les commandes du menu du Dialogue USB. La commande ‘q‘ ramène au Menu du GPS qui présente comme montré sur la Fig.91 la date et l’heure. La rotation du codeur incrémental fait changer de PAGE-écran, la deuxième actuellement en place est celle de la Fig.92 indiquant la distance du GPS jusqu’à la Cible actuelle. On peut maintenant commencer à ajouter des fonctions au Menu du GPS et croiser les doigts pour la stabilité du programme.
Particularités du petit afficheur de 0,96 pouce de diagonale.
Outre une police de caractère bien plus fournie que celle de son grand frère, (Qui ici s’avère un inconvénient.) la bibliothèque qui l’accompagne sait tracer des cercles et des rectangles, mais pas des disques et des rectangles pleins. Comme on désire utiliser les deux, on va devoir créer ces éléments géométriques particuliers. Par exemple avec les rectangles disponibles, on obtient la Fig.94 A pour la représentation de l’état de réception des satellites. Pour retrouver la représentation en barres verticales B on ne fait plus appel au tracé des rectangle de la bibliothèque, mais à la technique C de la Fig.93 qui consiste à tracer six segments de droite verticaux les uns contre les autres et de hauteurs égales. Pour les cercles, l’approche est différente. Sur la Fig.93 E et F sont représentés le grand et le petit cercle tels qu’ils sont tracés par la fonction display.drawCircle le moins grand ressemblant à un carré à cette échelle, vu la « pixellisation ». On débute par un PIXEL au centre ici en marron entouré en rose par un carré. (L’instruction étant celle d’un rectangle.) Puis on trace le cercle vert pour le petit disque. Pour le grand disque, on ajoute le carré vert suivi du cercle bleu clair. Dans la réalité, les quatre pixels oranges sont communs au deux dernières instructions. Ce n’est pas pénalisant puisque l’illumination des mosaïques réalise un OU logique si plusieurs tracés se superposent.
Écran bicolore ou écran monochrome.
J’avoue que j’affectionne particulièrement le petit écran bicolore avec ses deux couleurs complémentaires. En monochrome il existe soit en bleu, soit en blanc. Tous présentent une définition identique de 64 x 128 luminophores. Les quatre exemples de la Fig.95 qui montre l’ordre croissant des affichages mettent bien en évidence dans le rectangle jaune un élément important des informations de la page affichée. En A on retrouve la date et l’heure légale. En B la distance qui sépare le GPS de la cible est centrée en largeur, c’est à dire que la marge de gauche est adaptée au nombre de chiffres indiquant la distance. En C l’accentué dans l’encerclé rouge est obtenu artificiellement par deux PIXELs. Il aurait été facile en EEPROM de remplacer le ‘e‘ par le code affecté au ‘é‘ dans la police de caractères de l’afficheur OLED, mais vu qu’il me restait largement assez de place en zone dédiée au programme j’ai été paresseux et je n’ai pas cherché la valeur de ce code. Mon programme n’est donc pas optimisé à outrance, je suis sur ce point en contradiction avec mes « valeurs programmatiques ». Enfin en D on retrouve l’interface Homme/Machine d’un cheminement qui utilise les dix cibles possibles. Actuellement on a indexé le cinquième jalon. Dans le chapitre précédent, dans les explications sur le CHEMINEMENT un point important a été oublié relatif à un « aléas » possible si on se trompe et que l’on désigne en premier jalon celui de la position actuelle du GPS.
Manifestement, chaque fois que j’ai opté pour ce petit afficheur dans mes applications informaticoélectroniques, j’ai préféré esthétiquement le bicolore. Il se trouve toutefois un cas particulier où ce modèle présente un inconvénient, c’est le cas où dans l’application on désire afficher un graphe qui va utiliser les 64 PIXELs de hauteur. En effet, le modèle bicolore présente la même définition que son homologue monochrome, avec toutefois une ligne de séparation entre les mosaïques jaunes et les luminophores bleus. Il en résulte alors une discontinuité dans le dessin graphique que montre bien la Fig.96 qui montre la seule page de tout le programme où ce petit inconvénient se fait sentir. Pour toutes les autres pages d’affichage j’ai tenu compte de la présence de ces deux zones, et le logiciel est totalement compatible avec les deux références. Au final, cette discontinuité n’est pas vraiment pénalisante et quel que soit le modèle qui est à votre disposition l’ensemble reste très séduisant. Toutefois, entièrement compatible ne signifie pas forcément idéal. En effet, le développement s’est effectué sur le bicolore qui concrètement possède deux zones distinctes séparées par une ligne non active. Le monochrome ne présente qu’une seule surface, du coup ce qui était jaune et ce qui était bleu n’est plus séparé. On observe bien sur la Fig.97 que le texte sous le rectangle est plus proche. Aussi, pour celles et ceux qui possèdent le modèle monochrome, il sera esthétiquement favorable de revoir certains cadrages. Ce n’est absolument pas impératif, mais c’est un bon exercice cérébral.
Compte-rendu impératif.
Commencer par noter que le programme ne fonctionnera correctement que si l’EEPROM contient les nouveaux textes adaptés et épurés. Il importe dans ce but de téléverser l’outil nommé Ecrire_en_EEPROM_3.ino qui en outre gave l’EEPROM avec dix PI pour nous aider à valider le programme Application_GPS_5.ino spécifique au petit afficheur OLED de 0,96 pouce de diagonale. Bien que la taille de disponible entre la PILE et le TAS ne fasse plus que 243 OCTETs, le programme s’avère stable. Dans ce dernier, j’ai abandonnée l’idée d’afficher le planisphère. Cet échec résulte de l’impossibilité que j’ai rencontré à obliger les tables des cartes à être des constantes logées dans la zone programme par l’artifice PROGMEM. Mes essais dans cette optique se sont avérés infructueux, et je n’ai pas trouvé pourquoi la lecture du tableau ainsi figé fournit des valeurs incorrectes. Le petit outil Echec_de_PROGMEM.ino permet de mettre en évidence le problème. Si un internaute en trouve la cause qu’il le fasse savoir à la communauté …
Les Fiches n°22 et n°23 listent les textes actuellement logés en EEPROM. Il reste encore quarante emplacements pour modifier ou ajouter du texte dans la mémoire non volatile de l’ATmega328. Par exemple on peut remettre les minuscules dans la liste des commandes du dialogue USB etc. Par ailleurs, le programme actuel ne consomme que 87% de l’espace réservé pour le programme. Il est donc possible d’ajouter pas mal de code objet si on le désire pour améliorer le logiciel que je vous propose. Par exemple sur la page de la Fig.97 remplacer le ‘D‘ de « Dh » par le caractère delta (Soit la lettre Δ) qui serait plus appropriée. Il sera facile de la construire avec trois droites pour former le triangle. C’est tout l’avantage d’un appareil « fait maison » que l’on peut améliorer ou modifier à sa guise, largement de quoi combler les longues soirées d’hiver …
La suite est ICI.
