Belle journée qui commence ce lundi MJD58133. Passant devant la vitre de la salle S6, je constate que JEKERT béta est au repos, les lumières sont éteintes. Béta est un clone strictement identique à la machine qui a été sélectionnée pour le grand voyage. On a réalisé une deuxième sonde totalement identique à JEKERT, mis à part qu’elle n’a pas sa centrale de génération électrique nucléaire. Cette machine sera activée chaque fois que les ingénieurs chargés du suivi auront à tester de nouveaux programmes, ou mettre au point des manipulations qui sur site pourraient mettre en danger la mission. Béta étant en sommeil, j’ai compris que ce jour les « ingés » vont plancher sur du visuel animant les consoles, et non sur des séquences complexes agissant sur la motorisation.
Visualiser un programme sur l’écran OLED.
Incontestablement, le mode apprentissage constitue le thème principal de la version J avec des séquences assez lourdes à mettre au point. Dans ce chapitre on va s’occuper de la présentation sur le petit écran du listage d’un programme. On peut supposer qu’afficher des codes numériques n’est pas spécialement vital, et qu’il serait plus judicieux de chercher en premier à faire fonctionner correctement l’édition, l’exécution, l’effacement etc. La réalité informatique est plus compliquée que ça. En effet, visualiser un listage sur le Moniteur vidéo de l’IDE ne présentait pas de contraintes en nombre possible de codes dans un programme, la liste défilant verticalement sur l’écran.
Il serait possible d’envisager sur OLED un tel défilement, ce qui générerait deux gros problèmes :
• Le traitement d’un défilement vertical engloutit beaucoup d’octets, (À été testé.)
• Outre qu’il impose de cliquer sur des touches pour faire évoluer les lignes affichées, le résultat n’est pas agréable du tout car nous n’avons jamais la totalité du programme sous les yeux.
Aussi, la solution adoptée consiste à afficher intégralement le programme sur la petite surface du cadre bleu de la matrice graphique. Mettre au point une présentation est complexe et impose de très nombreux essais. Si chaque tentative doit téléverser un programme de plus de 18ko, le temps de transfert devient excessif. Il faut impérativement, dans un tel cas, se créer un démonstrateur très allégé ne comportant que les routines de servitude pour afficher sur l’écran. En l’occurrence, c’est le module Test_AFF_PGM.ino que vous téléversez sur Arduino, « Sketch » qui pourra éventuellement vous servir à modifier à votre guise le code source pour adopter une présentation personnelle.
Purement visuel, quand vous activez ce programme, il commence par construire une grille dans laquelle seront placés les codes du programme listé. L’ordre de lecture consiste à balayer du haut vers le bas la colonne la plus à gauche. Puis on passe à la colonne voisine à droite et ce jusqu’à ce que tous les ordres soient affichés. Ce démonstrateur à permis d’optimiser l’usage de l’écran. On a recherché à placer le plus de lignes et le plus de colonnes possibles, tous en ayant facilité de lecture pour les codes chiffres inscrits dans les cases. En conservant un espace de deux pixels tout le tour des codes, on aboutit à une grille de 8 x 4 soit 32 cellules.
Désirant un maximum d’informations simultanément présentes à l’écran, l’avant dernière cellule, mise en évidence par une inversion de luminosité, sert à préciser quel est le programme actuellement en cours de traitement. Nous savons que maintenant ce seront neuf programmes indépendants qui seront possibles. La grille étant définie, c’est à ce stade qu’ont été définitivement adoptées les coordonnées d’affichage de la commande envoyée à la sonde. Ainsi, on réserve la dernière case pour y afficher le symbole des ordres transmis sur la voie montante.
Deuxième difficulté à aplanir, et pas des moindres : Comment présenter à l’écran l’évolution d’un programme qui serait déclenché en exécution ? Plusieurs méthodes sont possibles, il importe de sélectionner la plus « visuelle ». L’une de celles qui ont été testée consistait à effacer dans les cases les consignes au fur et à mesure qu’elles sont réalisées par la sonde. L’inconvénient, c’est que l’on voit bien ce qui reste à réaliser, mais on perd l’information de ce qui a été déroulé. Aussi, la solution estimée la plus judicieuse consiste à cocher chaque case lorsque l’action a été confirmée par la sonde. C’est ce que fait le démonstrateur actuel. Pour voir ce que donne ce cochage, assez similaire au protocole suivi par un pilote sur un aéronef qui consulte ses check-lits, vous devez enlever le « // » du démonstrateur en ligne 45 de la boucle de base. Vous pouvez ensuite valider la ligne 47 du code source et voir l’effet qui en résulte sur OLED.
Nouvelle implantation EEPROM du programme Esclave.
Ayant mis au point la présentation des listage qui sera émulée par le programme, il devient alors possible de définir le nombre de commandes maximal par programme, soit trente, et par voie de conséquence établir l’implantation en mémoire non volatile de ces derniers. Chaque programme va donc consommer 30 octets pour la place réservée aux trente instructions possibles. Il faut également prévoir un octet pour indiquer combien de codes sont contenus dans le programme. Comme nous disposons en EEPROM de place à revendre, on peut se permettre de « gaspiller » une cellule par programme. De cette façon chaque bloc sera séparé du suivant de 32 octets ce qui sur un listage du type de celui de la Fig.288 facilite le travail informatique. Dans l’ancienne organisation, la zone violette était réservée à la sauvegarde d’un balayage télémétrique. C’est toujours le cas du reste. C’est à la suite que l’on va placer les neuf blocs réservés à l’apprentissage. Les encadrés rouges indiquent le nombre d’instructions contenues dans le bloc. Dans l’exemple de la copie d’écran tous les programmes sont vierges, dans ce cas la valeur dans la cellule est zéro. Puis les zones coloriée en rose correspondent aux emplacements des codes d’instructions. Le plus grand code envisagé est 99, donc un octet est largement suffisant. Enfin laissés en blanc, les neuf octets non représentatifs qui sont honteusement gaspillés. La Fig.288 résulte d’une mémoire EEPROM vierge pour laquelle les neuf programmes ont été effacés, ainsi il sera impossible de travailler (Mis à part y loger des instructions.) sur des blocs dont les cellules ne contiennent que des aberrations.
Tester les nombreux démonstrateurs qui sont proposés dans ce didacticiel peut engendrer des incidents si vous utilisez un microcontrôleur neuf, avec une EEPROM vierge. Vous avez impérativement inscrit les postures pour que les mouvements de la sonde ne soient pas des « étrangetés » qui amènent les moteurs au blocage mécanique. Reste que faire afficher un spectre coloribétrique, un panoramique ultrasons ou une posture personnelle conduira à des incohérences sur l’écran. Pour avoir dès le début une mémoire EEPROM entièrement remplie par des données cohérentes, un programme spécifique P60_Clone_EEPROM_sonde.ino sera mis à votre disposition.
La suite est ici.
