Consultation du planning : Il va y avoir pas mal de « taf » en salle électronique S12 et en salle informatique S4. Sur les consoles les techniciens s’affairent, car l’intégralité des boutons et des clavier sont en place. Les belles plaques recouvrent les panneaux mécaniques. Ils ont fière allure ces pupitres d’exploitation avec toutes ces inscriptions. Maintenant les trous pour les écrans graphiques vont être comblés car sur les établis les belles dalles de luminophores sont déballées.
Présentation du tout petit écran graphique OLED Adafruit SSD1306.
Quand à la réception du coli postal on ouvre le paquet et que l’on sort ce minuscule module, on reste dubitatif en considérant ses dimensions vraiment discrètes. L’écran en verre ne mesure que 27 x 15mm. Tant que l’on n’a pas vu ce que donne une si petite image, on ne peut que douter de l’efficience de ce composant. Rapidement on « triture » un programme pour afficher le plus grand cadre possible, pour se rendre compte que ses dimensions ne font plus que 22mm x 16mm. Le doute devient encore plus sérieux. Et pourtant, dès que l’on arrive à afficher du texte, la plus petite police reste parfaitement lisible. « Traçons » ensuite des traits, des rectangles, des cercles, une sinusoïde, tout ce petit monde graphique s’avère parfaitement visible, et immédiatement le doute s’évapore. Un si petit écran remplit totalement sa mission, comme vous pouvez le vérifier sur la Fig.239, le plus petit texte en taille ainsi que les graphes sont très facilement « lisibles ». Sur cette photographie, le texte BONJOUR utilise la plus petite police de caractères de 5 x 7 pixels. (Soit une matrice de texte bien classique.) La netteté est en outre assez dégradée par le manque de définition de cette photographie, sur laquelle figure en haut à droite un pixel isolé. Il n’y a plus qu’à programmer …
Installer la bibliothèque indispensable.
Programmer un afficheur graphique est particulièrement laborieux, car il faut définir les caractères textuels, tracer des droites, des cercles, limiter ces derniers à convenance, gérer les débordements de définition de l’écran. Heureusement pour nous, quand un composant du commerce s’avère particulièrement séduisant, on trouve parfois une bibliothèque bien pensée créée par un passionné, ou souvent directement par le concepteur du produit commercialisé. Dans notre cas il suffit de télécharger pour l’IDE la bibliothèque Adafruit_ssd1306syp.h particulièrement efficiente. Il nous faut installer cette « library », rassurez-vous, ce n’est pas bien compliqué :
1) Téléchargez la bibliothèque dans un répertoire quelconque,
2) Décompacter le fichier ZIP dans ce répertoire.
3) Placer le dossier de la bibliothèque décompressé dans un dossier de votre choix, celui dans lequel vous préserverez toutes les « library » que vous ajouterez à votre environnement IDE.
Faisons connaissance avec l’afficheur OLED SSD1306.
Plusieurs bibliothèques personnalisées sont disponibles sur la toile. Il faut bien faire un choix. Celle utilisée dans les programmes proposés dans ce didacticiel m’a semblé la plus « populaire ». Il s’agit de la « library de référence » Adafruit_ssd1306syp.h disponible sur de nombreux sites. Par exemple on peut aller sur : http://www.codeforge.com/read/242813/Adafruit_ssd1306syp.h__html
Tous les programmes qui vont suivre vont utiliser ce module logiciel. Pour les comprendre il faudra consulter en permanence la Fiche n°36 qui détaille chaque instruction de cette bibliothèque.
Disposant de ses fonctionnalités, programmer le SSD1306 devient un jeu d’enfant … Encore que !
En effet, pour tracer tout ce que l’on désire, le code est immédiat pour peu que l’on s’imprime une grille de 64 x 128 carreaux pour repérer les coordonnées. Mais la petite puce fait de la résistance. Le petit écran ne se laisse pas faire et nous oppose dès le départ deux difficultés.
Première embuche : L’approvisionnement peut nous réserver une petite surprise. Ayant mis en service le tout premier de ces composants dans le PICOLABORATOIRE décrit sur :
http://www.robot-maker.com/ouvrages/apprendre-a-programmer-arduino-en-samusant/
c’était un écran monochrome qui sur la Fig.241 est présenté en A. Ayant commandé la même référence pour avoir un exemplaire de rechange en cas de « pépin », (Et oui, ça arrive !) j’ai reçu un modèle un peu différent. Comme montré sur la Fig.241 en B il est bicolore, avec une zone orange de 16 lignes en haut, une ligne de séparation sans pixel (Repérée en rouge.) et le reste inférieur en bleu. Du coup, avec le même programme on constate qu’en blanc sur la photographie A il y a continuité du tracé, alors qu’en bicolore sur l’image B il y a une discontinuité entre les deux couleurs.
Renvoyer le produit au fournisseur était une option, mais tout compte fait, la couleur rend l’écran bien plus attrayant. En tenant compte dans les programmes de la ligne sans pixels, on peut concevoir un logiciel qui favorise l’esthétique, les deux couleurs mettant en évidence des informations de type différent. La version en blanc est bien moins visuelle. (ATTENTION : Les deux photographies présentées ici dégradent considérablement la finesse réelle de l’afficheur, car l’appareil de prise de vues n’est pas prévu pour prendre des clichés en objectif rapproché.)
Personnellement je trouve que la couleur est très séduisante, et l’inconvénient de discontinuité faible puisqu’il n’est présent qu’en mode « dessin plein écran ». Pour que chacun puisse choisir à sa guise le modèle d’afficheur utilisé, tous les programmes seront conçus sur l’afficheur bicolore. (Prise en compte de la discontinuité.) Ainsi les deux versions du composant seront totalement compatibles.
Deuxième difficulté : Fonctionnant en allumant et en éteignant des pixels, l’effacement de l’afficheur total ou partiel prend du temps. Quand on recherchera de la rapidité de rafraîchissement sur l’écran, il faudra faire un gros effort logiciel pour que le code soit optimisé en rapidité d’exécution. Y compris dans ces conditions il ne sera pas possible d’obtenir la « fluidité » d’autres écrans du commerce. Rassurez-vous, mis à part quelques cas particuliers, et d’un usage marginal, dans l’ensemble les performances au final restent très « compétitives ».
NOTE : Le didacticiel était rédigé jusqu’à la page 31. Puis, pas à pas j’ai décidé de développer globalement le logiciel. Ainsi, voyant mieux jusqu’où serait possible l’entreprise, les démonstrateurs de la version C à la version P ont été consciencieusement créés. Chaque version apportait des possibilités nouvelles dont il sera question dans les pages qui suivent. J’avais prévu de vous faire tester les diverses améliorations en téléchargeant sur la carte NANO les démonstrateurs les uns après les autres … BERNIQUE !
Ce n’est plus possible, car l’étude des ces programmes a exigé plus de quatre mois. Les modifications ont régulièrement chamboulé l’organisation des textes en EEPROM. Du coup, toutes les versions entre P22C_Démonstrateur_Sonde.ino et P22E_Démonstrateur_Sonde.ino sont inutilisables car les textes affichés sont incohérents. Ce n’est pas catastrophique. Le didacticiel sera bâti comme si ces démonstrateurs étaient disponibles, sauf que pour expérimenter les améliorations on va ignorer les versions C, D, E et télécharger directement la version F ce qui au final vous épargnera quelques manipulations routinières. Le programme complet et définitif nommé P40_PGM_RAQUETTE_MAITRE.ino contient en tête l’intégralité de l’historique. Vous pourrez ainsi, si vous le désirez, savoir combien coûte en termes d’octets de programme chaque amélioration et évolution logicielle. Notre première expérience va donc se faire en téléchargeant P21F_Démonstrateur_Raquette.ino et P22F_Démonstrateur_Sonde.ino qui ainsi nous font faire un « bond en avant dans le temps ».
Protocoles d’exploitation de la sonde sur le terrain.
Particulièrement délicat à élaborer, l’agencement d’un contexte d’utilisation d’un système quel qu’il soit se heurte à une difficulté particulière liée au fait que les divers MENUS qui permettront le pilotage sont liés à la présentation du pupitre. Hors pour disposer géométriquement ce dernier il faut savoir à quoi serviront les touches, donc avoir présent à l’esprit les protocoles envisagés. Bref, c’est le serpent qui se mord la queue. Dans la conception d’une Raquette de commande c’est de loin la phase la plus délicate car elle sera suivie de longues études logicielles qui seront remises en cause si ce que l’on a imaginé à ce stade aboutit à une NON convivialité et oblige à mettre à la poubelle des heures d’études logicielles. Pour ne pas risquer de gaspiller un temps considérable à des réalisations matérielles qui seraient perdues, on ne passera à la concrétisation que lorsque globalement tout sera défini. Pour l’instant, c’est le petit clavier malcommode expérimental géométriquement « matriciel » qui sera mis à contribution.
L’étude qui va suivre va s’efforcer de concevoir un pupitre « définitif », mais il est évident que seule l’expérience qui sera acquise au cours du développement logiciel confirmera son bienfondé. On doit donc s’attendre à des déconvenues qui obligeront à revoir entièrement notre copie, sachant que c’est statistiquement dans l’ordre des choses. Bon, il faut bien commencer …
Une première réflexion fait apparaitre les divers modes fonctionnels suivants :
1) Consulter la sonde : Configuration système / Données scientifiques. (Consignes passives.)
2) Configurer les OPTIONS : Rapide/Lent, Moteurs OFF/Actifs, VEILLE etc.
3) Imposer une POSTURE. (Peut obliger à vérifier la configuration initiale.)
4) MOUVEMENTS : Déplacements de base translations/Rotations.
5) Mode EXPLOITATION des expériences scientifiques et des facultés d’apprentissage.
Tributaires des positions des trous disponibles sur les plaques de circuit imprimés prépercées, les positions des divers boutons poussoir du clavier ne pourront pas se voir librement réparties. Les positionnements horizontaux et verticaux seront sur des alignements forcément « au dixième de pouce ». Des études préalables pour s’assurer de la faisabilité ont induit le choix de l’accumulateur qui sera inclus dans la raquette pour assurer l’alimentation des deux cartes Arduino. Dans l’espoir de minimiser les 
dimensions du petit pupitre, les dimensions du clavier sont évaluées pour que ce dernier occupe le dessus de l’accumulateur et en adopte « la surface ». La première possibilité représentée sur la Fig.242 est équipée de petits boutons poussoir économiques. On les trouve par paquets de cent pour quelques euros. Le rectangle délimitant le clavier respecte globalement les dimensions de l’accumulateur rechargeable envisagé. Idem pour la Fig.243 sur laquelle sont représentés des boutons poussoir plus coûteux. Ils sont plus beaux, mais plus volumineux. Les couleurs sur le dessin ne sont pas celles qui seraient « logiques », mais celles des B.P. actuellement disponibles. Pour l’heure, aucune des deux solutions n’est choisie, c’est l’avenir qui fera pencher la balance d’un coté ou de l’autre. Les inscriptions non plus ne sont pas taillées dans le marbre. Il ne s’agit ici que d’une estimation rapide de ce pourra être le clavier. Cette esquisse va servir toutefois à dégrossir la géométrie du clavier, la disposition des touches et l’élaboration des protocoles d’utilisation du petit pupitre. On se doute qu’à l’expérimentation concrète nous serons certainement amenés à modifier ce qui nous sert de base de départ. Examinons les concepts généraux qui servent à débroussailler le terrain. Nous allons raisonner sur la version « de luxe ».
Pour faire court, dans l’état actuel des études primaires, les cinq touches noires seront affectées à l’appel des cinq menus de base correspondant aux cinq fonctions mentionnées ci-avant. Le fait de cliquer sur l’une de ces touches fait changer de mode. Elles auront cet usage en permanence sauf MOUVOIR pour le pilotage manuel des moteurs. PHARES et LASER servent à allumer ou éteindre ces deux périphériques. leurs fonctions ne changent pas sauf occasionnellement pour LASER lors du pilotage manuel des moteurs. Dans ce cas particulier, les trois touches « verticales » de la zone verte servent à définir l’articulation pilotée. Dans ce mode le bouton rotatif actionne les servomoteurs. La sortie de ce type de mode particulier se fait par la touche FIN.
Les sept touches rouges seront réservées principalement pour commander les déplacements élémentaires quand l’option MOUVOIR sera validée dans les menus. (Sortie de ce mode par l’une des autres touches noires.) Quand elles sont valides, la LED bleue s’allume.
Ponctuellement le programme demandera de confirmer ou d’infirmer une action, ou simplement valider l’un des items d’un menu déroulant en cours. Ce sont les deux boutons de droite. Celui du haut correspond au « risque maximum », c’est à dire l’accord. Celui du bas au refus. Notez que cette notion de « danger maximum » est aussi présente pour les touches noires. En partant du bas vers le haut les « conséquences » d’une activation augmentent. Par exemple le menu DONNÉES n’engage à rien, si ce n’est obtenir des informations sur l’écran. OPTION commence à modifier le comportement de la sonde. On ne modifie que des bascules de type OUI/NON.
POSTURE engage déjà plus fortement, car à partir d’ici la sonde va se mettre en mouvement avec tous les risques que cela engendre. Pour clore ce rapide tour de ce qui est envisagé à ce stade, tourner le codeur rotatif aura des effets qui seront totalement différents en fonction du mode en cours. Nous verrons les détails au fur et à mesure du développement des programmes. Les grandes lignes d’utilisation pratique du clavier étant tracées, il faut les valider ce qui ne peut se faire qu’expérimentalement, donc avec des démonstrateurs codés en C++ dans l’environnement de l’IDE.
Affectation des touches du clavier.
Pouvant influencer notablement la complexité du code compilé, l’affectation des touches doit privilégier la compacité du code. Par ailleurs, le développement des programmes va exiger un nombre considérable d’essais avec un clavier non ergonomique au point de vue mnémonique. De paire avec l’impact sur la taille du code objet, il 
importe également de faciliter le travail du programmeur. Pour tenir compte de ses deux critères, la Fig.244 montre les choix qui ont été effectués. Placer les touches de fonction entre S1 et S5 permet de simplifier certains traitements , donc de minimiser la taille des démonstrateurs. L’ordre des affectations facilite la mémorisation des touches pour le programmeur car elles sont géométriquement disposées comme sur le clavier « définitif ». OUI et NON sur S7 et S8 est prévu pour le programmeur. Les touches en « diamant » S9, S11, S14 et S6 seront faciles à retenir pour effectuer les translations. Du coup « Annuler les Efforts » est placé au centre. Pour avoir les rotations l’une à coté de l’autre il ne restait de disponible que S16 et S12. Enfin, ayant ainsi réparti les touches il ne reste plus que S13 et S15 qui sont dans l’ordre dévolues aux bascules d’allumage des Phares et du LASER. Ainsi réparties, on optimise en partie le code objet, tout au moins pour le codage des cinq touches de fonction. Pour éviter les effets boule de neige, à partir d’ici on ne modifiera plus ces affectations. Il ne nous reste qu’à espérer que ces choix ne compliqueront pas trop la réalisation du circuit imprimé. Il faut maintenant concrétiser cette stratégie dans P21F_Démonstrateur_Raquette.ino et effectuer les essais avec intégration des premiers menus déroulants ce qui n’est jamais une mince affaire. La gestion d’un l’écran graphique autorise bien des plaisirs esthétiques … au prix parfois de quelques « crises de nerf ! ».
Le MENU des DONNÉES.
Pour pouvoir interroger la petite machine sur son état système ou sur les valeurs mesurées par ses différents capteurs, il importe d’avoir la main sur les options. Aussi, avant de développer le menu des DONNEES SONDE historiquement le menu des OPTIONS SONDE a été élaboré en premier. La vérification de l’effet des consignes était réalisée sur les LEDs affectées aux différents paramètres. Le programme P21F_Démonstrateur_Raquette.ino présenté dans ce chapitre gère les deux menus. Il s’utilise conjointement avec le démonstrateur précédent P22F_Démonstrateur_Sonde.ino qui était 
prévu pour répondre à certaines consignes des menus « déroulants ». Lorsque le programme démarre, il commence par afficher l’écran d’accueil de la Fig.245 et attend un clic sur le clavier. Pour nous en informer, la LED CLAVIER verte clignote rapidement. Dans le cadre jaune est indiquée la version du programme qui anime la Raquette de commande. Dans le cadre bleu en grand la « présentation du système ». Dès que l’on appui sur l’une des seize touches la LED cesse de clignoter et l’écran présente alors le « menu déroulant des DONNEES SONDE. (Bien que son développement ait été effectué après celui des options, c’est le premier menu qui s’active lors de la mise sous tension.)
Représenté sur la Fig.246 l’écran des informations est structuré en quatre zones. Dans le rectangle jaune en 1 le titre du MENU en cours. En 2 le périphérique à utiliser pour changer d’item. Rot indique le codeur rotatif incrémental, CLV le clavier. En 3 se trouve une information d’ordre général. Ici c’est la version du programme Esclave qui est indiquée. Enfin en 4 nous trouvons trois informations de la configuration système ou des données disponibles sur les capteurs scientifiques. En tournant le codeur RRotatif dans un sens ou dans son contraire on fait défiler en permutation circulaire les quatre pages-écran disponibles. Les pages défilent dans l’ordre des photographies Fig.246, Fig.247, Fig.249 et la Fig.250 de présentation différente. Concrètement, entre les écrans de la 
Fig.249 et celui de la Fig.250 vient s’interposer l’affichage représenté sur la Fig 249B mais qui dans la réalité n’a été introduit qu’avec cette version P22F_Démonstrateur_Sonde.ino qui des démonstrateur. La donnée de CAP sera étudiée de ce fait dans un autre chapitre.
En A est précisée la distance télémétrique de l’obstacle éventuel situé devant la sonde. En B sont réunie les trois paramètres météorologiques. Si le capteur d’humidité n’est pas installé sur le connecteur, les deux mesures engendrent une ERReur n°3 ou n°4 en C avec en D le non affichage du texte HYGROMETRIE = nn %. En E est indiquée la tension d’alimentation des servomoteurs avec en F trois options système. Le dernier écran répartit de façon différente ses données. Pour des facilités de lecture les quatre informations utiles sont regroupées par deux en H dans le rectangle du bas. Du coup la zone d’information annexe G étant libre, on y précise la plage de variations possibles pour la valeur des énergies que l’on peut consigner aux deux périphériques à l’aide du gradateur. (Potentiomètre virtuel qui était non exploitable dans la version C du démonstrateur.) Il importe de noter qu’il aurait été possible de mémoriser les valeurs des booléens d’état dans la Raquette, évitant ainsi d’interroger la sonde ce qui diminuerait le nombre des codes et allégerait d’autant le programme objet de la sonde. Cette approche ne serait pas fiable, car on peut envoyer un ordre à la sonde, et que suite à un incident quelconque il ne soit pas exécuté. (Problème de transmission …) Il est donc impératif que ce soit la sonde qui fournisse les états des divers paramètres.
L’ordre des pages écran du menu des DONNEES.
L’agencement d’un menu ne doit pas être considéré à la légère. De sa convivialité dépend directement la qualité opérationnelle « du produit ». Chaque fois que l’on valide la fonction DONNEES SONDE il importe d’ouvrir la page la plus « utile ». Dans cette étude c’est celle qui correspond à la gestion des moteurs et de l’énergie. Ensuite, entrant dans ce menu, les items qui sont voisins doivent privilégier des pages « importantes en exploitation ». Si on tourne dans le sens positif, (Sens horaire.) on ouvre la page des mesures scientifiques. Une rotation dans le sens négatif ouvre les informations des périphériques consommant beaucoup d’énergie, c’est à dire les Phares et le LASER. C’est donc celle des options et informations sur la stabilisation et l’APPRENTISSAGE qui se trouve la plus « éloignée en rotation » de la fenêtre d’entrée. Notez au passage que les affichages ralentissent considérablement le processeur, car le composant OLED étant graphique doit entièrement générer des dessins qui pour vous sont des caractères de texte. Il faut aussi effacer des zones ce qui impose de blanchir beaucoup de points. Aussi, quand vous tournez le codeur ne soyez pas trop rapides, laissez le temps à l’affichage de finir de tracer les informations concernées avant de tourner fébrilement d’un nouveau cran. Notez au passage que le symbole 
visible sur la Fig.146 et qui sera rencontré sur plusieurs écrans représente un Soleil. Il symbolise l’alimentation en énergie de la ligne qui peut être disjonctée et qui allume en particulier les phares, le LASER et les nombreuses LEDs situées sur la sonde.
Le MENU des OPTIONS.
Concrètement, certaines sont vérifiables par deux possibilités. Par exemple l’allumage des Phares et du LASER sont observables visuellement et par interrogation de la sonde. Moteurs figés la LED rouge confirme l’information disponible avec le menu DONNEES SONDE. Quand le programme sera au point, la crédibilité consistera à enlever le petit « strap » à languette pour éteindre toutes les LEDs système. Il faudra alors faire confiance aux télémesures, le réalisme est à ce prix. Beaucoup plus épurés que pour le menu des données, les écrans pour les OPTIONS SONDE ne présentent qu’un seul item à la fois. Dans le rectangle jaune, Rot précise que l’on changera d’option avec le codeur rotatif. Sur la Fig.251 est précisé en 1 l’option en cours de saisie et en 2 son état actuel. La LED CLAVIER verte clignote rapidement précisant que le programme P21F_Démonstrateur_Raquette.ino attend une saisie au clavier. La logique veut que l’on clique sur la touche OUI ou sur le bouton poussoir NON. Ces deux touches auront l’effet escompté. Toutes les autres touches du clavier seront ignorées et n’auront aucun effet mis à part l’arrêt du clignotement tant que le bouton poussoir reste enfoncé. Immédiatement après avoir sollicité la touche S7 ou la touche S8 l’état actuel du booléen concerné est mis à jour en 2. (Par exemple, ici la ligne des énergies n’est pas disjonctée.) Tourner le codeur incrémental dans un sens ou dans l’autre fait changer d’item dans la liste des options. La permutation circulaire est naturellement fonction du sens de rotation. Les cinq items du menu des options sont présentés par ordre croissant sur les Fig.251, Fig.252, Fig.253, Fig.254 et Fig.255 dont la qualité des images laisse parfois à désirer. Plusieurs origines en sont la cause. L’écran est petit et les images sont prises en macrophotographie, mon appareil numérique n’étant pas idéal dans ce domaine. Obligation de prendre au flash ce qui fait ressortir toutes les poussières. Par ailleurs l’écran OLED est multiplexé, c’est à dire que ces PIXELs sont balayés rapidement et non lumineux de façon constante. Par exemple on constate bien sur la Fig.255 que le texte bleu est tout juste lumineux en bas de la ligne du centre alors qu’il y a surexposition sur la ligne du bas. Je vous prie donc de bien vouloir accepter ces images parfois assez peu visibles. Et encore, elles sont considérablement retouchées à la main pour ajuster le cadrage horizontal, optimiser la lumière et la concentration et surtout une foule de petites tâches blanches générées par les poussières sont enlevées.
Quelques éclaircissements sur le démonstrateur.
Contrairement à ce laisserait entendre le chapitre sur L’ordre des pages écran du menu des DONNEES, l’afficheur OLED n’est pas le seul à ralentir la vitesse d’exécution du programme. N’oubliez-pas que tourner le codeur rotatif ou cliquer sur OUI ou NON impose au programme de dialoguer avec le calculateur de bord. Par exemple OUI ou NON impose d’envoyer le code Consigne correspondant à l’item d’option affiché et d’attendre l’accusé de réception. Dans ce chapitre nous allons passer en revue deux ou trois petits détails logiciels.
Retour sur les interruptions : Cherchant à mettre au point les séquences des menus, le codeur rotatif s’est montré particulièrement pointilleux, son fonctionnement s’avérait aléatoire accompagné de très nombreux blocages. Quand on le tournait dans un sens ou dans l’autre il ne se passait rien. Il manquait dans la procédure void setup() les instructions suivantes :
Curieusement elles n’étaient pas dans le démonstrateur précédent qui pourtant semblait fonctionner correctement. Il est vrai qu’utilisé sur le gradateur lumineux, si des « clics » ont été perdus c’était bien moins visible qu’un item affiché à l’écran qui refuse de changer.
Début de la séquence qui traite le clavier :
La ligne (1) teste si une touche est enfoncée. Si c’est le cas elle retourne sa valeur dans BP. Si aucune touche n’est cliquée, elle retourne la valeur 0 et dans (2) le test est négatif, tout ce qui suit dans le bloc du if est ignoré. En (3) toutes les valeurs de BP comprises entre 1 et 5 seront prises en compte. C’est la raison pour laquelle on a placé les « fonctions MENUs » entre S1 et S5, un seul test détermine alors d’un seul coup toutes les touches de « fonctions MENUs ». Dans ce cas, avant d’invoquer le menu déroulant correspondant avec en (4) l’instruction Affiche_Ecran_MENU() on impose la page sur laquelle il sera ouvert. Les autres touches ont un codage assez banal. Par exemple en (5) on inverse le booléen PHARES qui fait office de bascule de type OUI/NON. Puis, en fonction de son état on transmet sur TX en (6) la valeur de consigne qui allume ou éteint les phares.
Un petit détail dans la procédure du MENU_des_OPTIONS :
La procédure en (1) commence par incrémenter ou décrémenter Num_des_options. Puis avec le switch / case en (2) elle procède à l’affichage de l’item pointé dans la liste. La ligne (3) a pour but d’affecter à la variable BIT_Option une valeur correspondant dans Chaine_Memorisee à la position du « 0 » ou du « 1 » représentatif du booléen correspondant au case. Pour en saisir l’écriture, il importe de résumer ce que fait en (4) la procédure Affiche_etat_option_en_cours :
Elle commence par envoyer la Consigne n°44 à l’Esclave sur la sonde qui retourne l’état des booléens système dans la variable Chaine_Memorisee de l’ACR. Ils sont dans l’ordre suivant :
Chaque booléen est donné sous la forme du chiffre « 0 » ou « 1 » avec les conventions de représentation habituelles. En orange sont indiqués l’indice de position dans la chaîne de caractères.
Détaillons les instructions de la ligne (3) :
Le tableau de la Fig.256 résume l’évolution des acteurs agissant sur BIT_Option lors du déroulement du programme. L’instruction de la ligne (2) laisse Num_des_options égal à l’ordre du case qui traite l’affichage des données. En (5) on affecte cette valeur à BIT_Option. En décrémentant de 1 dans l’instruction (6) on constate que mis à part la valeur 4 les autres valeurs sont correctes. Elle est corrigée en (7).
Pourquoi ce traitement particulier alors qu’un classique switch / case montré sur le listage de la Fig.257 serait plus parlant à lecture du programme ? La réponse réside dans ce leitmotiv permanent du programmeur : Optimisation du code. L’utilisation de la ligne (3) fait économiser trente quatre octets ce qui n’est pas rien. N’oubliez jamais que pour atteindre un but dans un logiciel, il existe souvent de nombreuses façons différentes de l’atteindre. L’art de programmer c’est choisir la plus élégante en fonction de critères hiérarchisés. Tout en haut on trouvera la minimisation du code objet,
puis la réduction de la taille des variables dynamique, enfin la lisibilité du programme source. Choisir avec précision de type des variables et l’ordre des données dans les tableaux ou dans les chaînes de caractères fait partie intégrante de cette stratégie omniprésente.
La suite est ici.
