08) Ajout de la gestion du RUN dans le logiciel.

C’est forcément avec cette fonction que tout ce qui a été réalisé en amont va enfin prendre tout son sens. C’était un passage obligé, car on ne peut pas faire « tourner » un algorithme sans pouvoir au préalable le créer, puis configurer le plateau de la machine. Enfin, quand un programme est activé en automatique, il reste encore à pouvoir en observer les effets. Tout le développement effectué en amont avait pour but ultime de posséder tous ces éléments pour enfin rédiger « le moteur » de cette machine virtuelle et l’activer pour le meilleur … ou pour le pire ! C’est le démonstrateur P13_Introduction_du_RUN.ino qui engrange toutes les routines du RUN. Glouton en ressources de l’ATmega328 il consomme 12% de l’espace réservé au programme. Cette boulimie en code peut sembler exagérée. Il n’en est rien, car de nombreux écrans pour les options ont été intégrés, et pratiquement tout ce qui concerne RUN est actuellement implémenté.

Un outil crédible.

Constitué de cinq « switch » le simulateur de clavier de la Fig.26 en page 9 est très utile pour dégrossir l’ossature du logiciel. Toutefois, arrive un moment où la structure définitive du clavier qui sera intégré dans la machine matérielle devient indispensable et ce pour deux raisons. La première réside dans sa géométrie. Les cinq touches de l’ensemble ultime seront placées en croix. Il importe de s’assurer que les choix qui sont faits dans les divers protocoles prouvent leur pertinence. Cette validation n’est fiable qu’avec la version définitive du petit clavier. La deuxième raison résulte du comportement des composants définitifs. Le choix actuel pour les boutons poussoir emploie des mini-composants dont le coût reste acceptable. Outre leur petite taille, ils sont munis de cabochons de toutes les couleurs offrant un bon éventail de combinaisons envisageables. On peut ainsi choisir les teintes à notre guise. Sur cette photographie en A se trouve le corps des ces petits boutons poussoir. La partie active qui s’enfonce quand on clique porte un tenon conique sur lequel s’emboîte le cabochon B disponible en sept couleurs. En C l’un de ces composants est assemblé. Ils se positionnent facilement sur une grille au pas standard. Sur la Fig.78 un clavier de démonstration fait désormais partie intégrante « du laboratoire ». Cette réalisation a montré que la qualité électrique de ces composants reste « médiocre », c’est à dire que lorsque l’on clique, le passage au travail s’accompagne d’un grand nombre de rebonds. Du coup, la procédure de lecture a complètement été revue pour obtenir un fonctionnement antiparasite fiable. Cette dernière a été reportée sur tous les démonstrateurs qui précèdent. Avantage : Quels que soient les composants approvisionnés, en principe ils seront compatibles.

L’écran typique durant le RUN.

Première étape du développement de la fonction RUN, définir l’organisation de la page écran qui sera visualisée durant l’exécution d’un algorithme. C’est une phase cruciale car de nombreuses informations sont susceptibles d’être visualisées. Le choix de leur disposition influence directement la qualité opérationnelle du petit appareil. L’écran OLED sera également secondé par la LED triple dont le comportement informera visuellement l’opérateur du cours de déroulement de certaines étapes ou options validées. Avant de détailler les divers protocoles du mode RUN, commençons par nous faire une idée de l’écran qui lui sera associé. Sur la Fig.79 on a repéré les diverses rubriques qui seront présentées à l’opérateur. Quatre zones sont réparties et seront visualisées à la demande du programmeur. En 1 l’information PAUSE ne sera affichée que lorsque le mode PAS à PAS est validé et que le programme attend que l’opérateur clique sur l’un des boutons du clavier. Par exemple sur la Fig.80 PAUSE n’est plus affiché et les informations sont modifiées en continu. Lors de cette attente, BP1, BP2, BP3, BP5 ont tous le même effet. Ils déclenchent la réalisation d’une nouvelle instruction. Pour son compte, BP4 annule ou valide le mode PAS à PAS. Quand ce dernier est suspendu, les informations sont réinscrites à une cadence qui n’est ralentie que par le temps nécessaire au rafraichissement de l’écran OLED. (Environ 8 images par seconde. Ce ralentissement n’est pas fonction de la quantité d’informations présentées sur la page écran. C’est une durée propre à l’afficheur qui active ces pixels en huit balayages de sa trame à chaque rafraichissement.) Toute la zone 2 présente le carrousel avec les pions et la tête de L/E. Le mot PLATEAU précise qu’il s’agit de l’état actuel du BARILLET et non celui de son INITIALisation préalable. Sur la ligne 3 sont affichées les instructions de l’algorithme en fonction de la TRANSITION Tr active et de l’état binaire du pion situé sous la tête de lecture.

Comportement du clavier et du codeur rotatif.

Deuxième étape primordiale du développement de la fonction RUN, définir les protocoles d’utilisation de l’interface Homme/Machine. Si la machine rend compte de son état et accuse réception des consignes par l’écran et la LED triple, c’est par le clavier et le codeur rotatif que l’opérateur donne ses ordres. Conformément aux indications du tableau Fig.82, quand le programme est en train de se dérouler et qu’il n’est pas en PAUSE, en tournant le codeur incrémental on fait afficher les diverses zones en permutation circulaire fonction du sens de rotation. ATTENTION : Que l’on soit en mode PAUSE ou en déroulement continu des instructions de l’algorithme, cliquer sur le B.P.C. fait sortir sans préavis de l’exécution et affiche le résultat du traitement. Quel que soit l’état d’affichage du tableau de la Fig.82 le comportement du clavier sera celui résumé sur la Fig.83 avec BP1 et BP3 assistés par la LED tricolore. Cliquer sur BP4 valide ou suspend le mode PAUSE. Appuyer sur BP2 fait alterner dans la zone 4 le nombre de cycles effectués, ou le temps écoulé depuis le début du RUN. Par exemple sur la Fig.81 l’opérateur à choisi de faire afficher le temps d’exécution en temps réel. Enfoncer le BP1 passe le déroulement de l’algorithme en fonctionnement ralenti. Dans ces conditions l’horloge cadence deux cycles par seconde. Pour avertir l’opérateur que le programme ne se déroule plus à la vitesse rapide, alors que l’écran serait noir, la LED tricolore clignote rapidement en « violet ». Si on clique sur BP3 le fonctionnement est ralenti à la cadence réelle de la machine électromécanique. Pour signaler ce mode la LED s’illumine en cyan. Il faut entre 3 secondes minimum et 7,4 secondes au maximum par cycle. Noter que lorsque l’un des deux ralentissements est validé, le clavier n’est pris en compte qu’à la fin du cycle. Il faut donc laisser la touche du clavier enfoncée jusqu’à ce que la LED triple s’illumine en vert pour signaler sa prise en compte.

Quand à BP5, elle impose le fonctionnement le plus rapide en annulant affichage et temporisations. Ce mode de fonctionnement est le plus rapide, car seul le traitement du microcontrôleur consomme du temps, le frein de l’affichage n’étant plus pénalisant. Pour que le programmeur puisse vérifier que l’algorithme est bien en train de se dérouler, la LED tricolore n’allume que la couleur bleue. C’est par le truchement de toutes ces teintes lumineuses résumées dans le tableau de la Fig.84 que sont différenciés les différents types d’état de l’appareil.

La page d’ouverture du mode RUN.

Valider l’exécution du programme perforé dans la grille virtuelle commence par afficher la page écran de la Fig.85 qui résume l’état des diverses options mémorisées dans la machine avec en haut le rappel de la référence de l’algorithme présent. (Celui qui devait fonctionner du premier coup tellement l’idée était simple et qui scongregneugneu de scongreugneugneu nous ruine notre patience et bousille les chakras !) Nous savons que dans le mode PAS à PAS seul BP4 inversera ce mode, les quatre autres touches déclenchant un cycle de plus … jusqu’à éventuellement rencontrer le « F » qui fait sortir du programme. Les deux options de temporisation Tréel et Ralenti s’excluent mutuellement, et le BP5 les annules, suspend le mode PAS à PAS et éteint l’écran. Si une BORNE de sortie prématurée a été initialisée, comme on le constate sur la Fig.85 sa valeur n’est pas indiquée, car elle peut être très importante et son affichage déborderait de l’écran. On se contente dans ce cas d’afficher OUI. On peut également avoir positionné l’option SURVEILLE qui exclue le mode PAS à PAS. Si la valeur de cette option est supérieur à zéro, l’affichage de la ligne PAS à PAS : NON est remplacé par
Surveille : OUI. La LED tricolore clignote en vert et n’importe quelle touche du petit clavier activera le déroulement de l’algorithme. Si l’option « Ignorer PAS de FIN dans l’algorithme » est validée et que « F » n’est présent dans aucune des lignes du programme, l’alerte de la Fig.86 s’affiche sur l’écran. Toute touche autre que le BP3 sera considérée comme une réponse négative et engendrera le retour au MENU de BASE. L’acceptation avec BP3 enchaine alors sur la page de la Fig.85 et attente d’une action sur le clavier.

Les diverses façon de sortir du mode RUN.

Victorieuses ou pas vraiment comme prévues. L’expérience montre que c’est la deuxième qui est statistiquement la plus probable. Trois scénarios de fins prévues sont potentiels. Le premier consiste à cliquer sur le B.P.C. car nous savons que « F » n’est pas présent dans l’algorithme, ou que par nature, même à cadence maximale il va falloir beaucoup de temps et que l’on désire reprendre la main. Pour le deuxième cas, le « F » a été rencontré et engendre la sortie. (Et là nous attend la surprise pour l’état du plateau qui s’acharne à montrer des pions « pas comme il faut ».) Enfin, une BORNE est programmée et engendre la sortie au nombre de cycles d’horloge initialisé. Dans ces trois cas il y a affichage du résultat du traitement sous la forme présentée en Fig.87 ou en Fig.88 si on clique sur BP1. On retrouve le comportement du petit clavier indiqué dans le chapitre La fonction PLATEAU donné en page 22. La sortie la plus tragique est celle de la Fig.89 qui ne fait qu’afficher un écran d’alerte. La LED tricolore clignote en vert et annonce le retour direct à la case départ, c’est à dire au MENU de BASE. Si un tel cas se produit, comme nous savons à quel moment cette calamité va se produire, on peut facilement anticiper. On commence par placer une BORNE un peu avant l’incident. Puis on déclenche le RUN. Lorsque le programme arrive au jalon initialisé il se met en PAUSE. On clique alors sur BP4 pour valider le mode PAS à PAS et ainsi analyser sereinement le déroulement de la tragédie. On dispose aussi du mode SURVEILLE comme outil de diagnostic sans compter … que l’on peut aussi vérifier le bienfondé de la feuille perforée virtuelle.

La suite est ici.