22A) La version RUBAN de la machine de TURING / 22B La réalisation des petits manuels.

Chère lectrice, cher lecteur, ce chapitre improvisé tombe comme un cheveu dans la soupe. Normalement, on devrait avoir ici le chapitre 22) Réalisation des petits manuels tel que le titre l’annonce dans la dernière branche de l’arbre des liens situé à droite. Visiblement un intrus s’est intercalé. Du coup, deux « sections » 22A) et 22B vont se succéder dans le chapitre 22. C’est que je n’ai pas voulu solliciter MIKE 118 pour qu’il corrige « la pagination ». Je me suis contenté d’intercaler ce chapitre. Tout ce qui concerne cet apport de dernière minute (Le didacticiel, les fiches d’utilisation et les deux programmes pour Arduino …) est disponible ici.

22A) Machine à remonter le temps.

Plus de deux ans et six mois que la machine de Turing autonome a été mise en ligne sur Robot Maker. Il se trouve que récemment j’ai été amené, presque par hasard, à faire reprendre du service à la petite électronique. Je me suis alors rendu compte que le petit écran utilisé représentait le plateau tournant de la machine électromécanique physique également décrite sur le site. Focalisant à l’époque sur cette machine qui avait occupé mes heures de loisir durant un période très longue, je suis passé un peu à coté du concept fondamental de l’illustre savant. En effet, la machine de Turing électronique est directement influencée pour les graphiques par celle avec un plateau tournant et des pions verticaux à la périphérie de ce dernier. J’ai occulté le RUBAN imaginé par Allan !
C’est assez dommage, car peu nombreuses et nombreux seront les internautes qui vont s’aventurer à construire une telle machine. Outre le prix de revient, les usinages sont tout de même relativement complexes et pas forcément à la portée de tout un chacun. Aussi, j’imagine assez bien qu’au lieu d’afficher à l’écran un plateau avec des pions verticaux, beaucoup d’internautes préfèreraient une représentation plus proche de celle du RUBAN de longueur infinie imaginé par Allan Turing avec des cellules dans lesquelles on peut écrire et lire des « 0 » et des « 1« .
C’est précisément l’objet de cette description pour laquelle la réalisation pratique Fig.1 du petit appareil électronique à base d’Arduino reste strictement inchangée. Il suffit de téléverser le logiciel P18_BANDE_PAPIER.ino et le dispositif va immédiatement adopter le comportement décrit dans ce chapitre ajouté tardivement sur ROBOT MAKER. Dans la pratique, par rapport au programme dont cette version est directement issue, de nombreuses améliorations ont été apportées sur le plan fonctionnel, et pas uniquement sur la présentation graphique du RUBAN qui remplace celle du plateau tournant. La longue liste de ces nouveautés est résumée en tête de listage et les détails les plus pertinents font précisément l’objet de ce document. En résumé, non seulement P18 adopte la représentation symbolique prônée par Turing, mais apporte une foule de petites améliorations par rapport à P16. (P17 est une version personnelle non diffusée.) En particulier on dispose maintenant d’une option qui permet de permuter dans un programme tous les sens de déplacements, on verra plus avant les services qu’elle peut rendre. Pour ne pas avoir à refondre l’intégralité du programme initial, on va continuer à travailler sur une machine dont la taille des données est de 56 cellules, (Huit OCTETS.) ainsi la représentation « GRILLE » restera fonctionnelle avec tous les avantages qu’elle apporte. La bande de papier sur notre réalisation sera donc limitée à 56 emplacements avec un bouclage du dernier avec le premier. Autrement dit, un déplacement de la tête de lecture à droite quand elle est sur la cellule 56 la refait passer sur la n°1. On retrouve cette petite entorse au concept de ruban de longueur infinie qui forcément affecte obligatoirement Toutes les réalisations matérielles, car l’infini n’existe pas dans le monde réel. (Sauf éventuellement pour l’Univers, mais c’est un sujet hors propos dans cette narration.)

La linéarisation du cercle.

Adopter plus directement le concept formulé par Turing engendre une refonte totale de la simulation graphique Fig.2 A à celui de la Fig.2 B dans un premiers temps. C’est à dire on « transforme » le plateau circulaire en une bande de longueur infinie dans laquelle les pions sont représentés par des chiffres « 0 » et des chiffres « 1« . Puis on

commence par limiter la longueur à 56 cellules de données cette bande linéaire de longueur infinie. Enfin, en C on courbe cette bande de papier pour en faire une boucle fermée dont la cellule n°56 voisine avec la cellule n°1. Sur l’écran graphique le ruban virtuel sera représenté perpendiculairement à sa surface, ressemblant au plateau A vu par la tranche. Comme le petit écran OLED n’a pas une définition suffisante pour représenter toutes les cases, on va devoir « fenêtrer » l’affichage à une largeur de douze cellules.
Comme c’était déjà le cas pour la représentation du plateau rotatif, on déplacera la bande de papier à droite ou à gauche de la fenêtre de visualisation avec les touches BP4 et BP5 du clavier. Avec un protocole d’utilisation semblable à celui de P16 le pas de déplacement sera de 1 ou de 5 cellules, choisi en cliquant sur BP2. Il reste à ajouter à la bande des repères de numérotage des cellules comme c’était le cas précédemment. Ce n’est qu’un complément informationn

rel assistant la visualisation. Il n’est pas obligatoire on s’en doute, mais c’est un plus incontestable qui facilite grandement l’établissement d’une relation directe entre le mode GRILLE et le mode RUBAN de papier. Avec cette nouvelle approche on aboutit à la représentation globale de la Fig.4 qui reprend les informations qui étaient proposées avec le programme P16. La portion de RUBAN visible dans la fenêtre est délimitée par deux lignes horizontales avec délimitation verticale des cellules. Correspondant verticalement, sous le RUBAN on trouve une bande associée qui indique le numéro des cellules toutes les dix positions : 1, 10, 20, 30, 40 et 50. Puis, les Multiples de 5 sont repérés par des petits +. La position de l’origine est indiquée en haut et à droite de l’écran graphique. Sur la bande de papier virtuelle l’encadrement de la cellule est doublé. Comme c’était le cas dans P16, le Nombre de pas lors des déplacements manuels est indiqué dans le petit rectangle en bas à gauche. Le temps de traitement total est précisé ainsi que le nombre de cycles effectués par l’horloge. Ces options sont inchangées. Enfin le texte BARILLET a été remplacé par Bande-P bien plus conforme avec la nouvelle représentation de cette machine de Turing électronique.

La refonte des protocoles d’utilisation.

Attention, comme c’était le cas pour les démonstrateurs précédents, avant de téléverser le logiciel d’exploitation, il faut au préalable loger les textes en mémoire non volatile EEPROM. Comme des petites modifications aux textes ont été apportées, il faut impérativement téléverser l’outil nommé P0B_Initialiser_EEPROM.ino et l’activer une fois en ouvrant le Moniteur de l’IDE. Ce programme en profite pour gaver l’EEPROM avec dix logiciels de type Turing pour avoir une base de travail de départ et ainsi expérimenter l’utilisation de la machine. Le Menu de Base en Fig.5 reste inchangé et comporte strictement les mêmes rubriques. Toutefois, y figure une petite information complémentaire. Comme avant, dans un petit rectangle est précisée la référence du programme actuellement en mémoire de travail. Sur cet exemple c’est le n°034, celui qui simule la construction d’un mur. Juste en dessous est précisé l’emplacement en EEPROM dans lequel il est préservé. Ici l’emplacement n°3. Comme ces deux informations sont associées, elles sont regroupées dans un petit cadre.

L‘évolution la plus importantes des procédures opérationnelles concerne les diverses options qui ont été simplifiées. Par exemple Fig.6 dans le menu Analyse, l’ancien choix d’affichage des données de chargement sur RESET a été remplacé par une nouvelle fonction Permuter G et D dont il sera question plus avant. De même que dans le menu OPTIONS Fig.7 l’item Accueil n’existe plus, il est remplacé par Fuite qui permet de sortir sans rien modifier. Actuellement, l’utilisation du clavier lors de l’affichage du Menu de Base est bien plus riche. C’est lui qui permet d’avoir à convenance l’affichage d’informations qui avant relevaient de validations dans les options. Maintenant, quand on clique sur BP2 l’écran devient tout noir et la LED triple illumine en blanc. Pour les quatre autres touches la LED triple clignote rapidement en vert incitant l’opérateur à cliquer sur l’une quelconque des touches pour revenir au Menu de Base. BP3 fait afficher le portrait d’Alan TURING. BP5 indique la version du logiciel et sur la ligne du bas précise la place qu’il reste en mémoire dynamique entre la PILE et le TAS. C’est une information qui ne concerne que les programmeurs avertis. Elle ne complète cette page écran que pour des raisons de mise en page et parce-que le logiciel laissait encore beaucoup de place inoccupée dans la mémoire de l’ATmega328 réservée au programme. BP1 précise à l’écran les données préservées en EEPROM qui sont rechargées automatiquement lors d’un RESET. Enfin, c’est la touche BP4 qui résume les options qui sont prises en compte lors du déroulement d’un RUN.

Une affaire qui tourne !

L’entête du listage précise dans l’ordre chronologiques les modifications qui ont été apportées à P16 avec incidence sur la taille occupée par le programme dans la zone dédiée de l’ATmega328. On constate qu’avant d’avoir introduit la nouvelle fonction de modification automatique du programme situé en mémoire de travail, l’affichage de la bande de papier virtuelle a été complété par la représentation symbolique de l’index d’HORLOGE de la machine électromécanique. Avant cet ajout, lors du fonctionnement en temps réel de la machine électromécanique, la LED tricolore s’éclairait en cyan durant le traitement de l’instruction en cours de réalisation. Un délai dépassant les quatre secondes laissait l’écran inerte donnant un peu l’impression que le logiciel était enlisé ou stoppé. Aussi, pour redonner « du mouvement » à l’affichage du ruban virtuel, en bas à droite de l’écran OLED est symbolisé l’index tournant Fig.9 de la machine réelle, indiquant quelle est la phase en cours d’exécution lors du traitement d’une instruction. La représentation simplifiée de l’aiguille est complétée en bas à droite par les lettres :

 

 

 

 

(C’est également cet ordre dans le déroulement du logiciel.) La durée pour effectuer un cycle complet est calculée par le programme et conforme à celui chronométré sur la machine réelle. Cette durée par instruction est variable. On se doute que s’il n’y a pas écriture ou rotation du plateau, le temps de déroulement d’une instruction sera plus faible. Par contre, sur la simulation graphique, pour simplifier le logiciel, chaque phase de l’horloge est de durée identique et calculée comme étant égale à la durée totale de l’instruction divisée par cinq.
Lors du déroulement d’un programme en fonction RUN et en temps réel, la durée de traitement n’est plus affichée, car la ligne de texte afférente à cette donnée peut venir se superposer à l’affichage graphique de l’horloge. Lorsque le programme se termine, le temps total écoulé durant toute la durée du RUN est affiché. L’aiguille n’est plus affichée durant l’exploitation des résultats. Par contre, la représentation du noyau central qui ne gène pas les écritures reste présent pour informer l’opérateur que le système est en mode temps réel.
NOTE : Quand le programme est en cours d’exécution, si on clique sur la touche BP3, le système passe en temps réel quel que soit le mode présent. Dans cette configuration la ligne relative aux temps de traitement est à nouveau affichée, restant utile pour l’analyse du comportement, et tout particulièrement en mode PAS à PAS.

La Fig.11 présente l’écran lorsque le programme a été entièrement exécuté, ou que l’on a provoqué une sortie anticipée en cliquant sur le bouton central du codeur incrémental jusqu’à ce que la LED tricolore s’éclaire en rouge. Le système est en configuration temps réel, raison pour laquelle le noyau de l’aiguille de l’horloge est affiché. La durée du traitement total de la fonction RUN est affiché.

Confondre sa droite et sa gauche !

L’expérience montre, qu’intervertir tous les G et les D d’un programme peut en modifier de façon séduisante le comportement. La construction de la donnée change alors de sens sur la machine. Hors, remplacer tous les G par des D et réciproquement est une opération systématique qui s’avère particulièrement indigeste. Hors demander au programme de le faire à notre place est vraiment libérateur, et surtout n’alourdit vraiment pas beaucoup le code. Alors pourquoi s’en priver ?
Le mieux pour illustrer cette fonction consiste à manipuler sur un exemple :
01) Charger en mémoire le programme n°1 qui se trouve à l’emplacement zéro dans l’EEPROM.
02) Dans les OPTIONS sélectionner V Maxi.
03) Revenir au Menu de Base et cliquer sur BP4 pour vérifier que toutes les options sont à NON.
04) Cliquer sur BP1 et s’assurer que le programme actuel est bien le n°0. Si l’état du RUBAN sauvegardé en EEPROM a été chargé, c’est sans importance puisque le programme 001 n’effectue aucune lecture d’état, il construit la frise en aveugle.
05) Activer la fonction RUN et observer lors du déroulement le sens de décalage du RUBAN et de l’écriture de la succession des états « 0 » et « 1 ».
06) Activer le bouton central du codeur rotatif jusqu’à ce que la LED tricolore s’illumine en rouge.
07) Cliquer encore une fois sur ce BPC pour revenir au Menu de Base.
08) OPTIONS > Analyse > Permuter G et D > BIP > OUI > Retour MENU de BASE.
09) RUN : On constate maintenant que la construction de la frise se fait dans l’autre sens.
Reprendre exactement toutes ces manipulations, mais avec le programme 034 logé en EEPROM à l’emplacement n°3 qui cette fois impose d’avoir une bande initiale configurée avec origine et tête de LECTURE/ECRITURE en cellule n°6. La construction du mur se fait exactement dans le sens réciproque de celui du programme initial.
Inverser tous les sens de déplacements dans un programme peut être utile dans deux cas :
• À la programmation on s’est trompé, raisonnant déplacement de la tête au lieu de la BANDE.
• Obtenir un effet réciproque avec un programme qui fonctionne.
Cette fonction sera au final bien plus utile qu’il serait logique de le penser, et principalement si on manque d’expérience dans ce type de programmation.

De nombreuses petites améliorations.

Déjà exprimé dans divers autres didacticiels, lorsque je développe un projet un peu « cossu », je ne considère que le travail est terminé que lorsque les ressources internes de l’ATmega328 sont pratiquement entièrement exploitées. J’ai en programmation un comportement radin. On a financé un microcontrôleur avec 30720 octets pour le programme, et 1023 pour l’EEPROM. Rentabiliser économiquement notre investissement consiste à tous les utiliser !
Ce préambule masque en pratique un point de vue important en programmation :
• Un projet abouti doit offrir un maximum de possibilités pour l’utilisateur.
• Dans cette optique il faut optimiser à outrance l’utilisation des ressources du microcontrôleur. Il faut donc utiliser au maximum l’EEPROM pour y loger des textes et des données non volatiles.
Ces deux aspects fondamentaux poussent au comportement « radin » dont il est question en préambule. Quand le programme fonctionne à merveille et que l’on a épuisé toutes les idées pour obtenir un logiciel agréable à utiliser et optimal, s’il reste des ressources disponibles dans l’ATmega328, alors pourquoi ne pas les consommer pour des améliorations de présentation, voir d’un dessin pour faire joli. C’est un peu futile certes, mais ça participe à l’ambiance. Compléter le code pour de tels petits plus et proposer « du parfait » en présentation est précisément l’objet de ce chapitre.

L‘intégralité des petites améliorations apportées à P16 est précisée en tête de listage. On va ici les passer en revue. Certains détails sont issus du fait que dans le programme on n’envisage plus un plateau tournant, mais une bande de papier virtuel qui se déplace en translation rectiligne. Dans cet ordre d’idée, un petit détail a été changé dans la page graphique Fig.12 qui affiche en mode GRILLE. Avant, dans le petit cadre mis en évidence en jaune, c’était la lettre P pour PLATEAU qui était affichée. Maintenant c’est un R pour RUBAN plus approprié. Quand c’est la configuration d’origine avant traitement, le symbole reste inchangé.
Lorsque l’on fait appel à l’option pour définir une BORNE, un accent a été ajouté au mot Incrément, rendant l’affichage plus correct. Dans la même optique, trois accentué ont été ajoutés à la page-écran de la Fig.14 tous constitués par le tracé de PIXELS. (C’est toute la différence entre un écran de mosaïques figés comme un module LCD par exemple, et un écran graphique sur lequel les textes ne sont pas autre chose que du dessin spécifique.)
À ce stade du développement du programme d’exploitation il restait encore 94 octets de non utilisés dans la zone réservée au programme. Un vrai scandale ! Aussi, pour éviter ce gaspillage invraisemblable, deux autres accentués montrés en Fig.15 ont été « pixelisés ». Dans l’état actuel, quand on compile le logiciel d’exploitation, l’IDE annonce 30660 octets de programme. Il ne reste plus que 60 octets de disponibles. Il devient raisonnable d’en rester là, et ce d’autant plus que tous les textes ont été entièrement accentués. Si d’aventure un problème de programme surgissait et qu’il y aurait un manque de place pour le corriger, la première variable d’ajustement pour faire des économies consisterait à « licencier » les accentués ce qui serait le moins pénalisant sur le plan fonctionnel et pour la qualité opérationnelle du petit appareil. Enfin, si vous désirez implanter une fonction nouvelle magique imposant pas mal de place pour l’émuler, supprimer le portrait resterait la solution la plus logique bien que la moins poétique. Quand à l’EEPROM, ses 1023 octets sont utilisés, elle est entièrement saturée de données. Coté rentabilité on ne peut pas faire mieux …

Réalisation matérielle d’un petit livret au format A5. (22B)

Faisant partie intégrante de mes didacticiels, généralement des petits livrets accompagnent le tutoriel. Dans ces livrets au format A5 on trouve souvent le manuel d’utilisation du projet, un autre document sur l’agencement du logiciel etc. Par exemple, pour ce projet de Machine de Turing Autonome, le programme utilise un afficheur dont la bibliothèque fournie met à disposition des protocoles très performants. Encore faut-il pouvoir les mettre en Å“uvre correctement. Pour celles et ceux qui chercheront à appréhender le logiciel qui anime la machine, le petit livret décrivant U8glib me semble indispensable. Que ce soit pour un livret informatique ou un manuel d’utilisation du prototype, dans tous les cas il importe de s’y prendre correctement pour imprimer et assembler le petit livret.

Agencé à un format A5, les faibles dimensions de ce manuel en font un document parfaitement adapté à son usage. Pas trop petit, les dessins et schémas sont de dimensions suffisantes, pas trop gros, il trouve facilement sa place dans un tiroir de rangement. Les fichiers tels que , sont prévus pour être imprimés RECTO/VERSO. Il importe donc de choisir du papier d’épaisseur « normale » pour ne pas que l’encre ne traverse. Papier recyclé méga écolo s’abstenir ! Personnellement je commence par imprimer toutes les pages impaires. Puis, paquet de feuilles replacé sur le bac à papier de la machine CORRECTEMENT ORIENTÉ ET DANS LE BON ORDRE je fais imprimer toutes les pages paires. Pour cette phase il me semble moins risqué d’opérer page par page, et vérifier à chaque tentative que deux A4 n’ont pas été « aspirés » par le mécanisme qui tracte les feuilles sous les têtes d’impression. Vous ne perdrez ainsi qu’une seule épreuve, alors que si vous engagez l’opération pour toutes les feuilles … c’est tout le paquet qu’il faudra entièrement réimprimer. Bien réfléchir quand on replace le paquet dans le bac de la machine, car les pièges sont nombreux. (Inverser le haut et le bas, face sur le dessus qui n’est pas la bonne, pages entassées dans l’ordre incorrect …)
Éventuellement tester avec une feuille brouillon en mode économique noir et blanc. Puis, quand tout est imprimé, réaliser l’assemblage est relativement élémentaire :
1) Commencez par plier toutes les pages en deux. (Et si possible du bon coté !)
2) Trouvez une plaque de polystyrène ou du carton bien classique. (Voir Fig.158)
3) Positionnez les pages bien à plat et surtout bien les unes cadrées sur les autres.
4) Avec une petite agrafeuse qui accepte de s’ouvrir complètement mettre en place quatre « crochets ». ATTENTION : Quand on appuie sur l’agrafeuse il faut bien la tenir latéralement car elle veut se décaler sur les cotés. Du coup comme montré en Fig.159 l’agrafe est mal enfoncée et se plie. Quand une agrafe s’est tordue, la retirer avec un cutter et en placer une deuxième exactement au même endroit. Le deuxième essai sera le bon …

5) Retourner le livret sur un support rigide et fermer les agrafes à la main avec un outil quelconque. Dans mon cas j’utilise une règle de section carrée comme montré sur la Fig.160 sur laquelle à peine visible on voit un coté de l’agrafe non encore replié.
Notez que pour vous faciliter la tâche les pages sont numérotées verticalement au centre pour repérer plus facilement l’ordre d’assemblage. Gutembérisez bien les ami(e)s …

Ici c’est la fin mais vous pouvez retourner au début ici.