Clef de voute de l’interface HOMME/MACHINE, il conditionne intégralement l’agrément d’utilisation de la machine pour tout ce qui concerne l’élaboration et la mise au point d’un algorithme. Que ce soit par l’entremise du moniteur de l’ordinateur dans la version élémentaire, ou du petit écran OLED en version autonome, dans les deux cas il doit :
Lister le programme actuellement en mémoire.
Développer les fonctions de l’éditeur sera facilité par la faculté de lister ce qui est présent en mémoire dédiée. Aussi, la première fonction à assurer consiste à pouvoir transférer l’un quelconque des algorithmes présent en EEPROM. Puis on va élaborer un scénario de visualisation de la table des transitions. Lorsque 
l’on pourra afficher facilement chaque ligne de la grille virtuelle de programme, alors il sera pertinent d’élaborer la rédaction et les modifications. Comme toutes ses actions sont connexes, l’affichage des lignes de programme devra si possible être analogue à celui des modifications. Le démonstrateur élaboré pour valider cette facette des études logicielles se nomme P10_Afficher_un_ALGORITHME.ino que l’on téléverse pour en expérimenter le comportement. Ce démonstrateur est déjà très avancé, car il intègre des fonctions complexes d’affichage. Par ailleurs, il a été très travaillé pour trouver des méthodes d’utilisation simples et d’un usage « naturel ». Il n’est pas évident de faire émerger des protocoles « instinctifs » avec un clavier aussi rudimentaire. Nous allons donc commencer par les écrans d’affichage de l’algorithme présent dans la mémoire dédiée. On peut déjà observer que le MENU de BASE de la Fig.8 est maintenant complété dans l’encadré jaune de la Fig.29 par l’indication en haut et à droite de la référence du programme en cour d’édition. Dans cet exemple on a chargé l’emplacement Pgm7 de la Fig.27 proposée en page 10. On peut en déduire que l’item CHARGER de la Fig.12 est implémenté. Si cette référence est 000 c’est que le programme en mémoire centrale est effacé. Le transfert depuis l’EEPROM tient compte de la possibilité de passer en Machine ÉTENDUE. Provisoirement, en cliquant sur l’item OPTIONS on inverse le type d’algorithme. Si le logiciel gère cette possibilité de Machine ÉTENDUE la référence affichée sur la Fig.30 est alors 255. C’est une référence réservée. Passez à des Algorithmes de 20 transitions possibles n’efface pas celui qui serait en mémoire. Ainsi on peut récupérer un programme standard et le compléter à convenance. On constate sur la Fig.31 que le menu PROGRAMME s’est enrichi d’un petit cadre intérieur qui visualise la référence du programme affectée par l’opérateur et sur la Fig.32 celle affectée automatiquement par le logiciel quand on est en mode Machine ÉTENDUE.
Lorsque l’on valide la fonction REDIGER, on passe directement en saisie des instructions si le mode Machine ÉTENDUE est actif. Dans le cas contraire, ce que montre la Fig.33 l’opérateur doit choisir une référence quelconque comprise entre 1 et 254. La saisie sera limitée à 254 et il sera impossible de proposer 255 la référence réservée. Si on propose 0 comme référence il y a fuite avec génération de trois BIPs sonores d’alerte.
La fonction MODIFIER n’efface pas le programme et ne demande pas sa référence. On débute par la saisie de l’ordre de la transition à partir de laquelle on va effectuer les corrections. Si l’opérateur se trompe et propose 0 il y aura correction à partir de la transition n°1. Comme il y aura au maximum 20 transitions possibles et que c’est le bouton rotatif qui sert à indiquer la valeur, il n’y a pas de coefficients « multiplicateurs » comme dans le cas de la saisie de la référence de l’algorithme. (Un tour de codeur incrémente 20 fois.)
Protocole de saisie de la référence de l’algorithme.
Cliquer sur le B.P.C. en standard validera la valeur saisie. Toutefois enfoncer la touche centrale du mini-clavier aura le même effet. Comme déjà précisé, proposer 0 engendre la Fuite sans modifier l’existant. Tourner le codeur rotatif dans un sens ou dans l’autre incrémentera ou décrémentera la valeur affichée. Si l’on désire la valeur 238, à raison de 20 incréments par tour la manipulation va s’avérer bien indigeste. C’est la raison pour laquelle le petit clavier va introduire à convenance le choix des coefficients multiplicateurs de la Fig.34 avec, il faut le savoir, des effets de bord. Par exemple avec le coefficient 100, partant de 1, en 3 indexations on arrive à 
. Comme le logiciel n’introduit pas de butée numérique, et que la variable est un int, 301 – 256 donne les 45 affichés. Ce n’est pas du tout gênant. La pratique montre qu’avec les coefficients adoptés en quelques clics on obtient rapidement n’importe quelle référence. Pour la saisie des valeurs pour les instructions de l’algorithme, un protocole spécifique est également élaboré et directement influencé par l’affichage de l’état actuel de la grille virtuelle de programme. Commençons par expliciter la façon dont sera présentée la feuille perforée virtuelle.
L’affichage du programme de l’algorithme.
Optimiser l’utilisation de la surface de l’afficheur OLED installé sur l’appareil et tenir compte de sa faible définition a conduit après plusieurs expérimentations à privilégier la solution montrée sur la Fig.35 qui sur une page-écran présente les trois lignes d’instructions d’une transition complète. On remarque que l’une des cellules est « surlign
ée » par le doublement de son encadrement. C’est cette cellule qui sera modifiée quand on tourne le codeur rotatif. Il n’a pas été prévu de fonction 
car elle n’apporterait strictement rien de plus que la fonction REDIGER ou la fonction MODIFIER. En effet, ces deux dernières permettent facilement de se « déplacer » dans les transitions vers le début ou vers la fin avec les touches « jaunes » du petit clavier. La touche centrale octroie dans ce but la faculté de ne pas afficher le surlignage de la cellule pointée ou de le rétablir. Du coup, pour explorer l’ensemble de 
l’algorithme on invoque REDIGER ou MODIFIER, on clique sur le bouton central du clavier pour masquer l’index, et l’on explore les transitions avec les touches « jaunes ». C’est vraiment très convivial, assez intuitif, et cette technique a donc été retenue. La Fig.36 présente l’usage du petit clavier et la Fig.37 symbolise le déplacement du curseur quand les touches rouges et bleues sont cliquées. La bleue engendre un saut du curseur vers la droite. Quand il est sur la colonne T il descend d’une ligne et va à gauche. Quand sur la ligne du B il est à droite, il revient en haut et à gauche. La touche rouge génère des mouvements symétriques. Avec ces deux touches on peut donc rapidement balayer les neuf cellules de la transition en cours de traitement. On se 
doute que le menu EEPROM fait appel aux mêmes fonctions pour le mode standard ou le mode Machine ÉTENDUE. Toutefois, dans le deuxième cas l’affichage du menu est complété comme on peut le constater sur la Fig.38 par l’affichage de son statut particulier. Ainsi l’opérateur est averti de l’état du logiciel. Il n’écrasera pas par erreur un algorithme à 20 transitions par un programme standard. La fonction EFFACER ne sera pas non plus validée par erreur sur l’algorithme le plus long à éditer. Il convient à ce stade de l’étude du croquis P10_Afficher_un_ALGORITHME.ino d’aborder le protocole de modification des instructions.
Protocole de saisie des instructions.
Chaque cellule sera modifiée individuellement. Avec les touches rouge et bleue on indexe la case à modifier. En tournant le codeur rotatif dans un sens ou dans l’autre, on fait changer le contenu de la cellule dans l’ordre ou en rétrograde des possibilités concernant sa nature. Une cellule vide signifie pas de « perforation virtuelle ». On ne peut insérer que des instructions logiques et les contradictions ne sont pas possibles. Par contre une écriture redondante ne sera pas signalée à la saisie. Cliquer sur le B.P.C. en standard fait sortir de l’ÉDITEUR de PROGRAMME.
Optimisation du contenu de l’EEPROM.
Dans la mesure ou l’option de Machine ÉTENDUE est validée, car tous comptes faits elle n’engendre pas une consommation démente d’octets de programme, on n’empiètera pas dans la zone encadrée de la Fig.39 qui est réservée aux algorithme de 20 transitions. Optimiser l’utilisation de la mémoire non volatile consiste à en employer la plus grande partie. Pour ce projet il ne sera pas possible de faire mieux, car 100% des 1024 octets servent à préserver des données.
Le contenu listé en Fig.39 est définitif, car les textes de la zone marron sont figés et il ne sera plus possible d’en ajouter. Pour gagner un octet, (Économies bout de chandelle !) Le M de MODIFIER sert à la fin du texte PGM. Du coup, ce sigle qui était en adresse 182 (Voir la Fig.15) passe maintenant en 133. Au final, dans le programme il a fallu corriger toutes les adresses des textes qui suivent !
Comme les textes figés en EEPROM sont codés en ASCII, il est possible sans aucune pénalité sur la taille occupée, d’introduire à notre guise des accentués. Dans ces conditions ce serait dommage de ne pas en profiter. Aussi, on peut observer dans les textes de la Fig.40 que l’intégralité des caractères qui pouvaient être accentués l’ont été, y compris sur les lettres majuscules. En violet ont été ajoutés les symboles de trois espaces qui sont dans les textes mais non visibles au listage. C’est du reste grâce à l’économie « bout de chandelle » que le mot ÉTENDU rentre exactement dans la place qui restait disponible. À partir d’ici, les nouveaux textes consommeront de la place programme, il ne faudra surtout pas en abuser. Les « bavardages » seront dorénavant réduits strictement à leur juste nécessaire …
La suite est ici.
