Avant de pouvoir intégrer les fonctions de cryptage, il est impératif de conditionner le Brouilleur et le tableau des Fiches croisée. Cette opération initiale que les opérateurs radio devaient effectuer tous les jours avant de pouvoir communiquer va nous obliger à implémenter un Menu de base avec du dialogue Homme/Machine qui nous le savons est toujours très gourmand en octets. C’est le démonstrateur P04_Initialiser_Enigma.ino qui se charge d’établir les procédures d’initialisation. Sur un RESET le logiciel démarre en mode CRYPTAGE et la LED tricolore clignote rapidement en vert incitant à frapper une LETTRE sur le clavier. Pour déclencher une option en mode COMMANDE, on clique sur Mode puis sur l’une des touches. Si elle n’est pas valide, un BIP d’erreur en informe l’opérateur. À ce stade du développement sont implémentées les fonctions :
Le petit clavier secondaire.
Établir une interface commode pour assurer le dialogue HOMME/MACHINE passe dans notre application par l’utilisation d’un petit clavier auxiliaire qui dans l’état actuel du schéma de la Fiche n°13 nous octroie quatre touches. Par ailleurs, on voit sur la Fiche n°9 qu’outre la LED tricolore, on peut également gérer trois témoins de plus. Actuellement ces trois LEDs seront des petites de 3mm de diamètre et l’ensemble pourrait ressembler à la présentation de la Fig.19 qui rassemble ces huit éléments, et au tableau de la Fig.20 qui en résume l’organisation logicielle. Pour expérimenter le démonstrateur P04_Initialiser_Enigma.ino on va effectuer les nombreuses manipulations proposées jusqu’à la page P8 dans le petit manuel au format A5 nommé UTILISER ÉNIGMA.pdf fourni dans le dossier <Documents>.
Un bilan logiciel s’impose.
Mettre en place le Menu de BASE a fait dramatiquement « monter en température » la place occupée par le programme, ce qui n’a strictement rien d’étonnant, car les procédures effectuent de nombreuses vérifications et surtout les dialogues
Homme/Machine sont très goinfres en octets par les nombreux textes affichés sur le petit écran OLED. Nous savons qu’un texte qui est constant est considéré comme une variable et installé directement dans le programme et dupliqué dans la mémoire dynamique. Il est peu probable que les 28% d’espace restant disponibles soient suffisants pour y loger le reste du programme d’exploitation sans compter que le Brouilleur virtuel et le code Morse vont ajouter encore des tableaux. Aussi, le moment est venu de faire effectuer au démonstrateur une cure de jouvence, et nous savons (Ou pas !) que le moyen le plus efficace pour gagner de la place consiste à faire passer en mémoire non volatile EEPROM un maximum de textes. C’est notre prochaine étape.
La suite est ICI.