Pièce maitresse du mécano logiciel embarqué par la sonde : Sa faculté d’apprendre, de pouvoir installer dans sa mémoire non volatile de nouveaux programmes qui seront développés en toute sérénité à Terre. L’expérience à montré depuis des décennies que cette possibilité de télécharger du code à bord des vaisseaux spatiaux a sauvé plus d’une mission, les exemples astronautiques foisonnent. En salle S4 les ingénieurs logiciel se sont partagé la tâche, car c’est un gros morceau.
– Bonjour les binaires, ça discute fort ce matin, zavez gagné au LOTO ?
– Ben non chef, sinon nous ne serions plus ici à gamberger des lignes de code à n’en plus finir.
– Ouais … on a réparti les blocs à écrire, car ya du maille.
– Moi j’ai pas de chance, je dois me coltiner l’éditeur.
– Plains-toi, ma pomme c’est le listage à l’écran que je vais devoir pondre.
– Bricole l’affichage, perso c’est l’exécution des ordres qu’il me faut tortiller, c’est le plus costaud.
– Arrêtez les lamentations les gars, dès que l’un aura torché son module, il aidera les autres !
Chamboulement du mode APPRENTISSAGE.
Effectivement, émuler un mode apprentissage impose plusieurs fonctions supplémentaires à ajouter au jeu d’instructions des programmes résidents sur la machine. On comprend pourquoi les personnels se sont répartis la tâche. Il aurait été possible de se contenter du minimum vital comme c’était le cas pour la version qui dialoguait sur la ligne USB du moniteur de l’IDE. La version de pilotage par pupitre autonome apporte des améliorations substantielles au regard du service minimal. Voici la liste des fonctionnalités qui seront désormais disponibles, les perfectionnements étant colorés en violet, alors que ce qui relève du strict indispensable est en bleu :
• Créer un programme préservé en EEPROM, (Et parer d’éventuelles erreurs.)
• Effacer le programme pour pouvoir en inscrire un autre,
• Lister le programme pour impérativement le vérifier avant de le soumettre à la machine,
• Faire exécuter les instructions du programme sauvegardé par JEKERT,
• Éditer le programme, c’est à dire pouvoir y ajouter des instructions,
• Corriger le programme, c’est à dire pouvoir effacer sa (Ou ses) dernière(s) instruction(s),
• Créer non pas un seul programme, mais jusqu’à neuf logiciels indépendants,
• Pouvoir déplacer l’un des programmes dans l’une des séquences à condition qu’elle soit vide.
Nous allons pas à pas passer en revue ces différentes fonctions, et décrire leurs spécificités ainsi que les écrans dédiés sur l’afficheur OLED. C’est l’objet des chapitres qui vont se succéder.
Indexer le programme cible.
Indexer signifie : Montrer du doigt. Instinctivement, quand on désire désigner une direction à notre interlocuteur, on utilise le doigt le plus long de notre main, c’est à dire l’index. Le vocable « indexer » en dérive. Dans notre cas il signifie que dans les neuf 
candidats « nominés », on devra systématiquement préciser au logiciel lequel on veut effacer, lister, modifier etc. Que l’opérateur soit en permanence informé de la cible est vital. Aussi, quand on consulte les pages du menu des DONNEES, l’emplacement réservé aux ACR dans les autres menus indiquera quel est actuellement le programme indexé par la sonde. Par exemple sur la Fig.289 en X on note qu’actuellement la sonde pointe le programme n°3 dans la liste, c’est lui qui sera l’objet des traitement relatifs à l’apprentissage. C’est dans le menu des OPTIONS que l’on trouve l’item de la Fig.290 qui si on le valide avec OUI affiche dans le cadre Y le n° du programme indexé. Lorsque l’on fait tourner le BPccr dans un sens ou dans l’autre, chaque nombre est incrémenté ou décrémenté, envoyé à la sonde puis P : n s’affiche en Y. L’information présente dans le cadre jaune concerne celle qui est effectivement indexée par le programme esclave. Quand on arrive aux valeurs extrêmes il y a recirculation à 1 ou à 9. La LED jaune clignote, il faut donc sortir impérativement par FIN pour revenir à un écran « propre ».
Activer ou suspendre le mode APPRENTISSAGE.
Particulier par certains des effets qu’il implique, engager ce mode ne doit pas risquer de se faire inopinément. C’est la raison pour laquelle il faudra au préalable allumer la LED rouge de SÉCURITÉ. C’est encore dans le menu des OPTIONS que l’on trouve la commande. Tenter d’activer l’apprentissage alors que la LED rouge est éteinte 
retournera l’accusé de réception E12 qui va souvent venir nous titiller. Sécurité armée, la touche OUI peut générer une erreur E13 qui signale que l’on veut tenter un apprentissage sur un programme non effacé. Ce n’est que provisoire, car vous pouvez constater que dans la version ultime l’erreur n°13 n’existe plus, nous verrons pourquoi plus avant. Pour l’heure il suffit d’indexer l’un des programmes, de l’effacer avec le code 88. Suite à ces deux manipulations il sera alors possible d’activer l’apprentissage. (Si la sécurité est armée !) La sonde retourne l’accusé de réception 1. Comme l’ordre n’a pas posé de problème, le programme maître transmet l’ordre 44 comme montré en 3. Le programme esclave renvoie alors l’état des 
booléens de la sonde, information qui décortiquée est alors visualisée en 2. Si les LED de servitude sur la sonde sont actives, celle qui en rouge témoigne du mode apprentissage est alors allumée. Si on tente une deuxième ouverture, le code erreur E11 signale qu’activer l’apprentissage une deuxième fois n’est pas valide. Comme pour l’erreur E12 ce n’est qu’un comportement provisoire qui sera modifié sur les programmes « définitifs ». Pour mettre fin au mode apprentissage, il faut revenir sur l’item de la Fig.291 et frapper sur NON. La sécurité n’est pas du tout exigée car l’action est neutre. Le résultat est montré sur la Fig.292 sur laquelle on retrouve une procédure analogue à celle de l’ouverture du mode, le résultat final en 2 étant cette fois négatif.
Enregistrement des instructions dans un programme.
Naturellement, vous avez compris que chaque commande envoyée à la sonde verra son code s’inscrire en EEPROM à partir de la première cellule du bloc concerné, puis les unes à la suites des autres viendront encombrer la zone réservée au programme actuellement indexé. Ce naturel admet toutefois des limites, car il faut parer un certain nombre de problèmes. Le premier qui vient à l’esprit, c’est la saturation des trente cellules. L’opérateur portant son attention sur les instructions qu’il impose, et sur les conséquences possibles n’a pas le loisir de compter. Aussi, quand toutes les cellules sont remplies, la sonde n’inscrira plus rien dans l’EEPROM et retournera le code d’erreur E14. L’attention étant attirée par le BIP sonore, l’opérateur sera alors averti et pourra prendre les mesures adéquates. La deuxième pierre d’achoppement réside dans certaines fonctions qui bloqueraient l’exécution du programme enregistré. La difficulté réside dans l’alternat qui sera engagé entre les deux machines. Ce problème sera abordé dans le chapitre d’utilisation du bloc enregistré. Consultez les pages Codage des consignes 1/3 à 3/3 du MANUEL d’UTILISATION qui donnent l’intégralité des codes possibles et précise ceux qui ne seront pas valides pour un enregistrement.
Effacer un programme.
Comme vu dans le chapitre précédent, pour pouvoir ouvrir le mode apprentissage il faut dans la version actuelle que le programme indexé soit vide. Aussi, on se doute qu’une commande spécifique permet d’effacer à convenance le programme de notre choix, ce qui suppose au préalable de l’indexer. Présente actuellement dans le menu EXPLOITER, la commande présentée sur la Fig.293 impose d’avoir allumé la LED SÉCURITÉ pour pouvoir valider l’effacement du programme actuellement indexé. Dans le cas contraire une erreur E12 déclenchera un BIP sonore. Le dernier code transmit à la sonde est 44, le plus souvent, c’est celui qui achève une commande pour en vérifier les effets réels sur la sonde.
Corriger un programme.
Actuellement n’est possible que durant une ouverture du mode apprentissage. Quand on ferme la session la seule modification possible reste l’effacement total pour recommencer. Déjà signalé, cette limite sera levée dans les versions futures. « Corriger » est à prendre dans ces lignes avec un sens très restrictif. Comme le précise la commande montrée sur la Fig.294 la correction consiste à effacer le dernier code de la liste. Tenter la manipulation hors mode apprentissage vous gratifiera d’une erreur E16 signalant l’obligation d’avoir la LED apprentissage allumée. Vous savez qu’en version opérationnelle il sera facile d’ouvrir le mode y compris sur un programme dont le listage n’est pas vide. Sécurité activée et mode apprentissage ouvert, OUI effacera le dernier code du programme actuellement indexé. On peut réitérer cette commande à notre guise, les effacements « remontant » vers le début. Les codes 89 se soldent par un OK tant que c’est possible. Quand il ne reste plus rien à enlever, E17 nous précise que ce n’est plus la peine d’insister … circulez ya rien à voir ! Notez que cette commande n’est logique que dans la mesure où quelques codes sont à enlever en vue de corriger un listage. Si c’est pour tout effacer autant faire appel à la commande de la Fig.293 qui élimine la totalité d’un coup.
Éditer un programme.
Également restreinte, cette commande constitue la réciproque de la précédente. Quand on active ce mode, on se retrouve dans l’état qui correspond à l’ouverture d’un apprentissage, sauf que cette fois on ajoute des instructions à la suite de celles qui sont déjà enregistrées en EEPROM. Sécurité active et mode apprentissage ouvert, la raquette de commande se contente d’envoyer l’ordre 20 et de faire positionner sur la sonde le pointeur correctement en EEPROM à la suite du dernier code inscrit pour le programme indexé. En version ultime du logiciel cette commande sera disponible inconditionnellement et servira à ouvrir le mode apprentissage. (Voir la Fig.295) On pourra ainsi éditer directement à partir d’un programme vide, ou le compléter à convenance.
La Fig.296 résume les deux méthodes qui nous octroient la possibilité de modifier le contenu d’un programme. En A on procède avec Suppr. dernier code. Chaque validation avec OUI décale « vers la gauche » l’emplacement de la dernière « case disponible » dans le bloc des trente codes possibles. La valeur de Nb est décrémentée conjointement avec le pointeur d’écriture en EEPROM.
En B la fonction Editer le PGM n est active. Chaque commande valide est inscrite en EEPROM à l’emplacement du pointeur qui est alors incrémenté conjointement avec la valeur Nb.
Lister le contenu du programme actuel.
Fonction absolument indispensable, que ce soit en cours d’écriture du programme ou avant d’en déclencher l’exécution, il importe de pouvoir à tout moment en consulter le contenu. La présentation à l’écran est actuellement acquise puisqu’avec le module Test_AFF_PGM.ino nous avons effectué les tests préliminaires pour organiser au mieux les informations présentes à l’écran. Du coup, la Fig.297 présente un aspect de « déjà vu » et n’appelle que peu de commentaires. Il est évident que sur cet exemple c’est le programme n°3 qui est indexé, donc listé. Ce dernier comporte actuellement sept instructions, la dernière consistant à éteindre le LASER. Il est clair que pour passer en revue un listage, nous aurons besoin d’avoir sous la main la correspondance des divers codes, dont l’intégralité figure dans les pages Codage des consignes 1/3 à 3/3 du MANUEL d’UTILISATION ouvert à la demande. Dans la grille de la Fig.297 nous ne devrions jamais voir figurer les codes non valides repérés par les symboles ‘/‘. Si c’est le cas il faudra impérativement analyser le problème potentiel.
Déplacer le contenu d’un programme.
Plusieurs raisons peuvent nous amener à déplacer un programme. Neuf zones possibles constituent une manne qui sera probablement largement mise à contribution. Chaque utilisateur va se concocter des programmes « meumeu » que l’on sera ravi de déclencher pour faire une petite présentation de JEKERT à des amis. Aussi, au cours du temps certains vont ressortir comme méritant une résidence pérenne en EEPROM alors que d’autres moins ludiques seront effacés. On aura probablement envie de placer à la fin les incontournables, et mettre au début les expérimentations nouvelles. Enfin, en version ultime il sera possible de chaîner en automatique plusieurs programmes. On pourra de ce fait réaliser des modules qui une fois mis au point devront se succéder en EEPROM. Cinq étapes seront nécessaires pour déplacer un programme d’une zone à une autre :
• Écrire dans le bloc qui servira de source. (Voui voui voui, on s’en doutait un tantinet !)
• Préciser à la sonde quel est le bloc ciblé pour effectuer un transfert. La commande sur la raquette est visualisée sur la Fig.298 qui n’impose pas la SÉCURITÉ, car ne présente pas de risque particulier.
• Indexer le programme qui servira de réception du code SOURCE transféré.
• Effacer la zone de réception. En effet, pour ne pas courir le risque d’écraser un module,
(C’est la terminologie consacrée en informatique.) le transfert ne peut se faire que sur une zone vide. Comme l’effacement impose d’armer la SÉCURITÉ, on ne perdra pas un listage par erreur … tout au moins en principe mais alors c’est vraiment que vous n’aurez pas fait bien attention !
• Transférer le programme source dans la zone de réception supposée préalablement vidée, ou vous serez « punitionnés » par un 
E24. Transférer un programme sur lui même est illégal, car par définition le transfert se termine par l’effacement de la zone SOURCE pour qu’elle soit disponible à l’édition. De ce fait, un transfert gigogne effacerait le programme source. (Dommage !) Pour éviter cet aléa une telle tentative se solde par une erreur E23. Pour procéder à un transfert, il faut que le mode apprentissage soit fermé. Comme montré sur la Fig.299 si ce n’est pas le cas une erreur E22 sera générée. Enfin, vous vous en doutez probablement, la SÉCURITÉ sera armée pour que le OUI ne se solde pas par E12 dont on finit par bien cerner la signification. Quand toutes les conditions sont respectées, enfin le code 13 se solde par le OK tant attendu. Certains vont trouver que la procédure complète est un peu compliquée. Concrètement, elle est bien plus facile à pratiquer qu’à décrire. Seule lourdeur, le fait d’avoir à quitter EXPLOITER pour armer SÉCURITÉ, puis y revenir et avoir à naviguer dans les nombreux items pour retrouver la commande souhaitée. Ce n’est que provisoire, car en version ultime toutes les commandes du mode apprentissage seront regroupées dans un menu APPRENDRE indépendant.
Exécuter le programme indexé.
Raison d’être de toutes les commandes d’apprentissage qui ont occupé les chapitres précédents, déclencher l’exécution d’un programme enregistré n’a rien d’anodin. La logique de base semble simple et se résume à une boucle du genre : « tant que l’on n’a pas terminé, on analyse le code pointé, on réalise la fonction qui le concerne, on passe au code suivant ». Sous cette forme, l’opération globale semble assez simple. La difficulté consiste à continuer le dialogue entre la sonde et le pupitre, hors perdre la synchronisation est particulièrement risqué dans une telle séquence. C’est du reste pour cette raison que certains codes ne sont pas autorisés, le chapitre suivant va décrire la boucle et son fonctionnement. Si tout se passe bien, quand la 
raquette aura donné l’ordre 87, le programme esclave va dérouler les instructions. Quand toutes auront été réalisées, il retournera le OK qui sur le pupitre rendra la main à l’opérateur. Plusieurs problèmes peuvent se présenter. Vous avez compris que pour JEKERT cette fonction est l’une des plus dangereuses. Par exemple vous avez aligné un nombre exagéré de mouvements en avant, puis sans trop réfléchir déclenché le processus :
– Et Totoche, ya plus la sonde, c’est normal ?
– Ben oui Dudule, regardes en bas du ravin !
– Et Totoche, la caméra montre le ciel de Mars, c’est prévu ça ?
– Ben non Dudule, mais sur la droite il y avait un obstacle et JEKERT a basculé sur son flanc …
D’accord, pour déclencher l’exécution du programme indexé il sera sage de bien analyser le listage pour valider la procédure. Ensuite, on devra impérativement armer SÉCURITÉ pour ne pas croiser l’inévitable E12. Imaginez également ce qui se passerait si 
la fonction était invoquée alors que le mode apprentissage est en cours. Il y aurait de l’auto-apprentissage en boucle avec à la clef une saturation à trente, suivie de plus rien … car le dialogue et la synchronisation seraient bloqués. Aussi pour vous éviter cette fin tragique de la mission, la Fig.300 montre que tout au plus un E19 pénalisera notre amour propre, on s’en remettra plus rapidement que les scientifiques qui ont investi dans JEKERT tous leurs espoirs. Par ailleurs, si vous tentez de déclencher un programme vide, E18 se rappellera à votre bon souvenir. Si tout va bien, OUI sera accepté par le logiciel esclave qui affichera la grille, listera les codes du programme pointé du doigt, ainsi que dans la case à droite en bas visualisera le 87. À partir d’ici, le pupitre n’est plus opérationnel, inutile de titiller les touches ou le codeur rotatif. Sur l’écran OLED, un dialogue de type alternat étant établi entre pupitre et sonde, chaque fois qu’une instruction est achevée on voit, comme sur la Fig.301, la cellule la concernant être biffée. Ainsi nous savons exactement ce qui se passe. (Frimeur !) Puis, si toutes les instructions sont réalisables, un OK final achèvera la séquence, le programme 
maître rendant alors la main à l’opérateur. Outre l’accusé de réception qui signale que le processus a été jusqu’à son terme, la LED SÉCURITÉ s’éteint sur le pupitre. L’écran reste affiché jusqu’à ce que l’on clique sur l’un des boutons permanent de menu ou que l’on tourne le codeur incrémental. Reste qu’il n’est jamais exclus que l’une des instructions soit irréalisable. Par exemple le code 3 est puisé dans le listage pour faire avancer la petite machine d’un pas. Si un obstacle se trouve à moins de 8cm, le programme esclave retournera le code d’erreur E20, c’est à l’opérateur de déterminer la cause du problème rencontré. Ce ne sera probablement pas trop délicat d’en diagnostiquer l’origine, car l’écran reste figé et la case de l’instruction qui a engendré une impossibilité n’est pas cochée. Avec dix messages d’erreur typés et spécifiquement réservés pour le mode apprentissage, on peut dire que le logiciel pare déjà pas mal de cas illogiques. Par exemple, et j’ai oublié de le mentionner sur le chapitre du listage d’un programme indexé, si vous tentez la fonction sur un module vide, E15 vous informe pourquoi, comme visible sur la Fig.302, les cases de la grille réservées aux codes des instructions restent toutes sans contenu. Nous allons pouvoir passer au démonstrateur suivant, mais avant on va analyser un petit bout de logiciel.
Exécuter un programme et simultanément continuer le dialogue.
Incontournable, les deux machines sont intimement liées par la nécessité de maintenir un alternat permanent au cours du déroulement d’un programme EEPROM. En effet, le choix d’afficher sur l’écran l’état du système en cochant « la grille du LOTO » implique forcément qu’entre la sonde et le pupitre on conserve l’échange des informations. Le dialogue ressemble à ceci :
– L’esclave est à l’écoute et attend sagement une consigne envoyée par le Maître,
– Le Maître donne son ordre 87 puis immédiatement repasse à l’écoute,
– L’esclave décode 87, vérifie que le programme existe et répond OK puis immédiatement écoute,
– Le Maître parle et dit : Continue, puis repasse à l’écoute,
À ce stade l’esclave entame la boucle pour épuiser toutes les instructions :
– Si NON l’esclave retourne OK qui signale que c’est terminé puis attend une nouvelle commande,
– Le Maître éteint la LED SÉCURITÉ puis attend une touche au clavier ou un mouvement du BPccr.
ATTENTION, dans ce processus il n’y a plus alternat ou chacun attend que l’autre ait parlé pour intervenir à son tour. En aveugle veut dire que l’Esclave ne se préoccupe plus de savoir si le Maître est à l’écoute. Il continue son travail inexorablement. Cette technique simple ne peut fonctionner QUE SI LE MAÎTRE EST REPASSÉ À L’ÉCOUTE AVANT QUE L’ESCLAVE NE PARLE. C’est ici le cas, car pour cocher une case dans la grille il faut bien moins de temps que pour récupérer le code en EEPROM, pointer le code suivant, exécuter l’instruction, vérifier qu’il n’y a pas un E20 et envoyer l’ACR. Remarquez au passage que tout problème survenu en exécution retourne un code unique E20. C’est une facilité informatique, car sur le Maître il n’y a besoin de tester que les deux cas possibles pour détecter la fin du processus et informer l’opérateur. (OK ou E20.)
Sont interdits par ‘/‘en apprentissage tous les codes qui retournent en ACR autre chose que OK, car il y aurait perte de la synchronisation et blocage des deux microcontrôleurs.
La procédure Activer_le_PGM_cible() qui traite la directive 87, est listée ci-dessus. En ligne (1), non seulement la variable Compteur_de_Code_PGM reçoit la valeur du nombre d’instructions dans le programme, mais également positionne le pointeur de codes PTR_Apprentissage sur « début du PGM – 1 ». Soit en (2) on constate que le programme est vide, le processus se termine avec un ACR E18, soit en (3) on poursuit en précisant que pour le moment tout va bien. Tant qu’en (4) on n’a pas terminé, en (5) on pointe la prochaine instruction. Puis en (6) on capture son code en EEPROM. Avant d’envoyer la sentinelle ‘*‘ en (7) on commence par un delay d’attente de sécurité de 0,2 seconde. Puis, en (8) on réalise l’instruction comme si elle avait été instanciée par le pupitre. Si le traitement se déroule normalement, num_ERR est nul et en (9) on décompte le nombre d’instructions qui restent à traiter. Si une erreur quelconque a entravé l’exécution de l’instruction, en (10) le code 20 est généré pour se voir envoyé en ACR et simultanément Compteur_de_Code_PGM est forcé à zéro précisant à la boucle while qu’elle est achevée et qu’il faut en sortir. Fastoche tout ça non ?
La suite est ici.
