Pour le démonstrateur P03_Premier_Rotor.ino on va se contenter de simuler la transformation quand le caractère circule de l’entrée à droite vers le Réflecteur à gauche. Puis on suppose que le Réflecteur le retourne sans le modifier pour émuler le comportement réciproque. Ainsi le caractère en sortie du « mouvement » de gauche vers la droite redevient celui initial. Il suffit de réutiliser P02 et d’y introduire le Rotor et de s’en servir dans la procédure provisoire Crypte_le_caractere(). Le tableau de la Fig.33 résume les transpositions effectuées.
Par exemple A entrant devient E sur le Réflecteur dans le sens Direct.
Renvoyé par le Réflecteur dans le sens Réfléchi ce E redevient un A.
Lorsque P03 est activé, rien n’interdit d’utiliser le mode TEXTE, mais je vous recommande dans un premier temps d’imposer le mode LETTRES. Si on frappe les caractères dans l’ordre alphabétique on obtient le résultat de la Fig.34 sur laquelle le caractère en entrée est dans la zone bleue et celui de sortie dans la colonne verte suivi en surface jaune par l’équivalent Morse. Sur le Réflecteur c’est la lettre dans la colonne rose qui est retourné de la gauche vers la droite. On teste ainsi le codage Direct avec le tableau Rotor_de_DroiteD[26] et le codage Réfléchi avec le tableau Rotor_de_DroiteR[26]. Pour la codeuse du programme ultime d’utilisation, il suffira de créer cinq Rotors de ce type, d’en choisir trois en fonction du jour du « conflit 39/45 » et de les positionner sur la machine virtuelle.
OUPS … il manquait une commande !
Désolé amis Internautes, mais quand j’ai réalisé le programme du dialogue utilisateur P02 j’ai oublié une commande très importante. En effet, il est vital sur notre ÉNIGMA de pouvoir à tout moment vérifier sa configuration d’initialisation. C’est maintenant chose faite avec la commande ‘C‘ qui dans P03 devient valide. Du coup elle est ajoutée dans la liste de la Fig.30 et repéré en gris car lors de l’utilisation de P02 elle est encore interdite. Comme pour les autres fonctions non encore développées elle se contente de se nommer pour indiquer sa prise en compte.
Bilan relatif à la simulation d’un rotor.
Quand on valide P03 le compilateur annonce « Le croquis utilise 7 058 octets (22%) » soit à peine 180 octets de plus pour créer ce Rotor simulé. Autant dire presque rien, inutile de corriger le thermomètre représentatif de l’occupation le la mémoire réservée au programme, il ne change strictement pas. Pourtant, force est de constater
qu’avec une si faible modification, le compilateur devient craintif et soucieux et sur la copie d’écran de la Fig.35 il affiche un message d’alerte en orange. En réalité ce n’est pas la taille du programme qui le préoccupe, j’ai déjà réalisé des logiciels qui occupaient 100% des octets réservés sans que ça ne pose problème. Son inquiétude vient du fait que trop de données sont logées dans la mémoire dynamique, il préfèrerait que la place occupée soit inférieure aux 79% actuels. Nous pourrions continuer à créer d’autres organes sur la machine, ne serait-ce que les quatre autres rotors. Hors ces derniers vont encore ajouter 208 octets dans la mémoire dynamique. Hors la solution consiste à placer ces tableaux en mémoire non volatile EEPROM comme précisé dans l’encadré rose en bas de la page 22. Aussi, pour éviter de créer ces Rotors dans le programme comme actuellement et avoir à Réécrire les routines routines d’émulation avec stockage en EEPROM, je vous propose d’adopter la stratégie suivante :
1) On code les cinq Rotors tout en « haut » de la mémoire EEPROM.
2) On en profite pour loger à partir de l’adresse 0000 les textes qui seront utilisés de façon certaine.
3) On rédige la routine de rechargement d’un rotor. (Et les procédures d’affichage des textes.)
4) On teste dans P04_Les_cinq_Rotors.ino les quatre autres Rotors avec la technique de P03.
Pour que vous puissiez comprendre le codage en C++ de ces Rotors le tableau de la Fig.36 en résume les permutations effectuées par les quatre que l’on va ajouter au n°I.
L’implantation de l’EEPROM va respecter l’organisation de la Fig.37 avec dans les adresses hautes le codage des cinq Rotors possibles en premier et des deux Réflecteurs potentiels tout en haut. Pour les cinq Rotors il faut prévoir 5 x 2 x26 = 260 emplacements. Pour les deux réflecteurs c’est 2 x 26 = 52 cellules qu’il faut employer. La zone rose qui ne sera plus modifiée consomme donc 312 octets et va des l’adresses décimales 712 à 1023. Puis, dans la zone bleue qui précède, commence en 666 et se termine à la cellule 711, on logera la configuration initiale sauvegardée en mémoire non volatile. Elle sera de taille constante et à ce stade du
projet l’organisation de cette donnée analysée consommera 46 OCTETs. Le développement le confirmera ou imposera une modification de l’implantation. Juste « en dessous » dans la région jaune on prévoit huit OCTETS pour des données ou options qui ne sont pas encore définies. (Développement futur.) Enfin, en partant du bas de 
l’adresse relative 0000 et s’étendant vers le haut dans la région verte, on logera un maximum de textes. Cette zone est saturée. Elle a été optimisée. Les autres chaînes de caractères résideront dans le programme. Ce n’est pas idéal, mais nous n’avons pas le choix.
Textes, Rotors et Réflecteurs en EEPROM.
Dans la suite « Loupe » désignera l’idéogramme du Moniteur 
.
Première étape avant de pouvoir utiliser les textes, et les éléments virtuels de la machine, il faut les inscrire dans la mémoire non volatile du microcontrôleur. Dans ce but, disponible mais non encore utilisé, on va mettre en Å“uvre P00A_Initialiser_EEPROM.ino prévu pour cette mission. La Fig.38 liste les textes qui sont possibles, car l’EEPROM est saturée et seulement une partie du dialogue H/M peut y être logé. La zone bleue est occupée par la sauvegarde de l’initialisation d’ÉNIGMA dont une étude préliminaire à ce stade du projet estime l’encombrement à 46 OCTETs. On commence par activer le Moniteur de l’IDE avec l’idéogramme « Loupe » et on initialise sa vitesse de transfert à 57600 baud. Puis on téléverse l’outil informatique P00 que l’on active ensuite en cliquant une deuxième fois sur « Loupe« . La fenêtre du moniteur se remplit et ressemble à la copie d’écran de la Fig.38 avec en violet des commentaires au fur et à mesure que le 
programme se déroule. En particulier dans la zone verte les textes inscrits sont listés. Puis il y a affichage en Fig 39, sous forme de tableaux, de l’intégralité du contenu de l’EEPROM avec l’indication des adresses des OCTETs dans la zone orange. (Adresse du premier octet de la ligne à gauche à laquelle on doit ajouter la « valeur » de la colonne affichée ici en hexadécimal.) Noter qu’à tout moment dans la liste des logiciels fournis vous disposez à convenance de Lister_EEPROM_en_HEXAdecimal.ino un outil informatique qui vous permet de lister le contenu de l’EEPROM de n’importe quelle carte Arduino.
Dans la zone verte de ce long listage formaté en matrice, sont donc listés en clair les caractères des mots, pour ainsi déterminer l’adresse de leur début indispensable aux routines d’affichage qui viendront puiser les éléments. On remarque au passage trois accentués, car leur codage en EEPROM ne pénalise plus la taille occupée par le code OBJET. La zone rose de la Fig.39 a été fragmentée pour repérer dans notre magasin les divers composants de la machine. Dans les secteurs violets et roses sont confinés les Rotors dans le sens direct et dans le sens réfléchi. Dans la zone marron clair on trouve le Réflecteur B et enfin dans l’encadré gris clair le Réflecteur C. Les divers éléments sont en place, il ne reste plus qu’a les exploiter dans le démonstrateur P04.
Simplification de l’affichage des commandes.
Dans le but de restreindre un peu « les bavardages », car nous savons maintenant que de nombreux textes vont encore résider en mémoire de programme, l’affichage par la commande ‘?‘ de la Fig.30 a été diminué, car les deux zones bleu clair et jaune n’apportent pas vraiment de l’information pertinente. Elles sont donc éliminées dans P04_les cinq_Rotors.ino. Par ailleurs, le texte « E ou e suivi de R, F ou G : Corriger. » n’était pas idéal car la lettre ‘E’ choisie ne correspondait pas directement à la fonction réalisée par cette commande. C’est la raison pour laquelle le texte a été modifié en « E ou e suivi de R, F ou G : ERREUR. » ce qui correspond mieux et du coup fait passer la zone jaune des OCTETS disponibles à 10 emplacements. (Gain d’un octet.)
La lisibilité d’un programme.
Finalité de ce petit projet : S’amuser avec Arduino tout en apprenant à programmer avec méthodes. Dans cette optique il me semble incontournable d’aborder le thème de la lisibilité d’un logiciel. En Page 9 ce thème a déjà été abordé et je vous invite avec insistance à relire le chapitre qui commence par la vérité biblique la première qualité d’un logiciel quel qu’il soit est sa LISIBILITÉ. Nous allons observer dans le démonstrateur P04 quelques lignes de programme où la lisibilité a été prise en compte. Considérons une instruction du type Aff_TEXTE_EEPROM(76,30) utilisée pour le dialogue Homme/Machine. Lors du développement chaque fois que l’on désire modifier un texte, il faut le changer en EEPROM. Puis modifier les paramètres le concernant dans le programme. Pour retrouver la bonne instruction dans le fatras des Aff_TEXTE_EEPROM c’est une galère, car 76,30 n’est vraiment pas lisible. C’est la raison pour laquelle il est important de faire suivre ces instructions par des remarques de type //  » I ou i : Mode INITIALISATION. » précisant le texte affiché par l’instruction.
Vérifier les cinq rotors qui sont dans notre magasin virtuel.
Par magasin virtuel vous avez bien compris qu’il est fait référence à la mémoire EEPROM de l’ATmega328.C’est non seulement cinq éléments qu’il va falloir vérifier, mais également dans les deux sens de « traversée » du courant électrique. De ce fait le démonstrateur P04 doit permettre de choisir le Rotor à tester, mais également le sens Direct ou Réfléchi. Le mieux pour tester ces séquences vitales du futur programme d’utilisation reste encore à effectuer un jeu d’essais complet dont voici le protocole :
MANIPULATIONS :
01) Faire un RESET et téléverser P04_Les_cinq_Rotors.ino.
02) Cliquer sur « Loupe » pour activer le Moniteur à 57600 baud.
03) Dans la fenêtre de saisie frapper ‘1‘ pour tester le Rotor I.
04) Imposer ‘d‘ pour tester dans le sens Direct.
05) Frapper un ‘i‘ pour Initialiser la machine dans cette configuration de test.
06) Frapper alors un « & » pour passer en mode CRYPTAGE.
07) Proposer les 26 lettres possibles en validant pour chacune. On obtient le résultat de la Fig.40 avec dans la colonne bleue les lettres « entrantes » et dans la colonne verte celles cryptées. Il faut donc comparer ces dernières avec celles du tableau de la Fig.33 de la page 21.
08) Revenir au mode COMMANDE avec ‘&‘.
09) Modifier le sens de « traversée » avec ‘r‘ pour Réfléchi.
10) Retourner en CRYPTAGE avec ‘&‘.
11) Reprendre les 26 lettres possibles et vérifier le résultat sur les valeurs rouges du tableau.
12) Retour au mode COMMANDE avec ‘&‘.
13) Frapper ‘2‘ pour tester le Rotor II.
14) Revenir au sens de « traversée » Direct avec ‘d‘ et ‘i‘ pour Initialiser. (On teste dans l’ordre.)
15) Reprendre les 26 lettres possibles et vérifier le résultat dans le tableau de la Fig.36 de la page 22.
16) Touche ‘&‘, touche ‘r‘ suivie de ‘i‘ pour tester le sens Réfléchi.
17) Reprendre ces procédures pour les autres Rotors :
• Touche ‘&‘ / ‘3‘ / ‘d‘ / ‘i‘ / ‘&‘ / 26 lettres / ‘&‘ pour tester le Rotor III dans le sens Direct.
• Touche ‘&‘/ ‘r‘/ ‘i‘/ ‘&‘ / 26 lettres / ‘&‘ pour vérifier le Rotor III dans le sens Réfléchi.
• Touche ‘&‘ / ‘4‘ / ‘d‘ / ‘i‘ / ‘&‘ / 26 lettres / ‘&‘ pour tester le Rotor IV dans le sens Direct.
• Touche ‘&‘/ ‘r‘/ ‘i‘/ ‘&‘ / 26 lettres / ‘&‘ pour vérifier le Rotor IV dans le sens Réfléchi.
• Touche ‘&‘ / ‘5‘ / ‘d‘ / ‘i‘ / ‘&‘ / 26 lettres / ‘&‘ pour tester le Rotor V dans le sens Direct.
• Touche ‘&‘/ ‘r‘/ ‘i‘/ ‘&‘ / 26 lettres / ‘&‘ pour vérifier le Rotor V dans le sens Réfléchi.
18) Tester ‘m‘ deux fois pour vérifier les textes logés en EEPROM.
19) Tester ‘v‘ deux fois pour vérifier également leurs textes en EEPROM.
20) Tester ‘p‘ pour valider son texte. (Explications plus avant.)
21) Enfin frapper sur ‘l‘ et sur ‘t’ toujours pour vérifier les textes non volatiles.
Noter que dans le Menu apparait la commande ‘G‘ non encore émulée. (Étudiée plus avant.)
Un nouveau bilan sur l’évolution du programme.
Vous avez remarqué qu’en tête de listage des démonstrateurs, en remarque sont précisés les évolutions par thèmes de la taille du skech lors de ses modifications. Les informations précisées par le compilateur sont fonction de sa version raison pour laquelle cette dernière est précisée.
On constate que le fait de loger un maximum de textes en EEPROM a fait diminuer la taille du programme de 562 octets ce qui n’est pas du tout négligeable alors que simultanément les routines pour échanger des données avec l’EEPROM ont été ajoutées. Surtout, c’est la mémoire dynamique qui s’est allégée de 656 octets correspondant aux textes logés en EEPROM auxquels s’ajoutent 208 octets relatifs à la simplification de l’affichage du menu.
Par ailleurs, avec les essais effectués dans les manipulations, nous avons vérifié le comportement des cinq rotors, ainsi que tous les textes logés en EEPROM soit presque l’intégralité de cette dernière. On va pouvoir maintenant sereinement créer les deux Réflecteurs virtuels.
La suite est ici.
