Armez-vous de patience car dans ce chapitre on ne va pas encore aborder l’agencement virtuel de l’un quelconque des organes de la machine. La raison en est fort simple. En effet lorsque l’on va émuler un Rotor par exemple, il nous faudra présenter au programme un caractère alphabétique, et voir comment les séquences élaborées le transforment. Le plus simple consiste à envoyer les consignes par l’entremise du Moniteur et réceptionner les accusés de réception sur ce dernier.
La chaîne de transmission est résumée sur la Fig.29 la fenêtre contextuelle du Moniteur étant affichée sur l’écran de l’ordinateur. Lorsque l’opérateur frappe un caractère au clavier, ce dernier est affiché dans le champs de saisie. Puis à la validation ce caractère ou le texte saisi est validé. Il est alors transmis à 57600baud sur la ligne USB. Capturé par le programme d’Arduino qui est en attente, ce texte ou ce caractère sont traités conformément au logiciel. Ce dernier retourne un accusé de réception qui est alors retourné sur la ligne USB. Le Moniteur réceptionne ce « compte rendu » et l’affiche dans la fenêtre de visualisation du Moniteur. Tous ces échanges sur la ligne USB sont simples à programmer avec l’instruction Serial.println(). Ce sont les protocoles de traitement du programme d’Arduino, c’est à dire le dialogue Homme / Machine qui vont être développés ici.
L’organisation de l’interface Homme / Machine.
Par expérience, je peux m’engager à affirmer que c’est probablement la mise en Å“uvre de cette fonction de dialogue qui risque de conduire aux séquences les plus grandes en taille, car il va falloir établir du dialogue à la fois caractère par caractère, et aussi sous forme de textes. Généralement ce type de protocoles est assez glouton en octets, en particulier quand il faut extraire des caractères élémentaires (Et en vérifier la validité.) d’une chaîne textuelle. De plus, l’Analyseur Syntaxique des commandes s’avère généralement du genre un peu compliqué donc avec pas mal de cas particuliers à traiter.
Enfin, les textes affichés pour l’opérateur sont nombreux et particulièrement boulimiques.
Chaque fois que l’on désire établir un dialogue entre deux entités, on doit prendre en compte un maitre et un esclave. Le maitre « parle » en envoyant une consigne à l’esclave qui « écoute ». Puis le maitre passe immédiatement en réception, et l’esclave réalise le travail imposé par la consigne. Puis il retourne un accusé de réception.
Avec P02_Dialogue_Homme_Machine.ino on va mettre en place l’interface d’utilisation. Lorsque le programme démarre, il affiche la référence de sa version suivi, comme montré sur la Fig.30, des protocoles envisagés à ce stade du développement. Ensuite nous pourrons commencer à créer l’Énigma virtuelle. Dans ces derniers on observe la commande ‘P‘. Cette dernière sera explicitée plus avant dans l’un des derniers chapitres. Bien qu’elle soit émulée dans ce démonstrateur, pour le moment on peut royalement l’oublier. Pour se faire une idée du comportement que présentera le programme ultime, on va « se faire la main » avec le démonstrateur P02 que vous téléversez dans les neurones de l’ATmega328. On va explorer les COMMANDES et le comportement en mode CRYPTAGE :
MANIPULATIONS :
01) Faire un RESET pour débuter sur une configuration « vierge de toute action préalable ».
02) Cliquer sur 
pour activer le Moniteur de l’IDE.
03) Si l’écran affiche des incohérences, c’est que la vitesse de transmission sur la ligne USB n’est pas
à 57600 baud. Dans ce cas la modifier puis refaire un RESET.
04) Dans le champ de saisie A frapper la lettre de commande « F » puis valider.
– Bande de Dudules, ce n’est pas une COMMANDE valide dont la liste est résumé dans la zone B.
РBon, on se concentre, et on continue avec all̩gresse !
NOTE : Chaque fois que l’Analyseur Syntaxique des commandes détecte une erreur, il génère un texte d’alerte et un BIP sonore pour prévenir l’opérateur. Le caractère erroné est alors ignoré.
05) Toujours dans le champs de saisie A proposer la lettre de commande « i« . Elle est transformée en équivalent majuscule et le programme précise que la fonction est traitée.
Dans ce démonstrateur les fonctions ne sont que titrées et ne font rien d’autre.
Naturellement on est autorisé à frapper les équivalents MAJuscules pour tous les caractères des protocoles adoptés. Néanmoins personnellement je trouve bien plus convivial de travailler exclusivement en minuscule, c’est à dire de ne pas avoir à « shifter ». Donc, pour assurer la qualité opérationnelle du dialogue d’interface, les caractères valides frappés au clavier seront tous translatés en leurs équivalents majuscules comme précisé dans le MENU.
MANIPULATIONS : (Suite)
06) Imposer les consignes des fonctions réciproques « s« , valider puis « r » et valider. Dans les deux cas le démonstrateur précise le travail qui sera effectué quand ces fonctions seront émulées.
07) Pour voir ce qui va se passer frapper « sr » et valider cette paire de caractères tous deux valides.
08) Frapper alors un « & » pour passer en mode CRYPTAGE. Le changement de mode est signifié de façon non ambigüe. Maintenant seules des lettres sont autorisées ainsi que « &« . Le texte d’invite « Commande -> » est remplacé par « Une lettre -> » précisant exactement ce qui est possible.
09) Proposer « a » et valider. Quand la machine Énigma sera simulée, chaque caractère sera « brouillé ». Pour le moment le démonstrateur se contente de la transformer en sa suivante et cette dernière une fois modifiée est affichée en code Morse.
10) Revenir au mode COMMANDE avec ‘&‘.
11) Choisir l’option ‘m‘ puis repasser en CRYPTAGE avec ‘&‘.
12) Maintenant frapper quelques caractères individuels. Ils sont traduits en Morse sonore et simultanément la LED bleue s’illumine à la cadence des traits et des points.
13) Revenir au mode COMMANDE avec ‘&‘.
14) Changer la cadence avec ‘v‘ qui passe en Vitesse Rapide.
15) Retourner en CRYPTAGE avec ‘&’.
16) Tester quelques caractères pour voir la différence.
17) Reprendre le mode COMMANDE et museler le bruiteur avec ‘m‘.
18) Modifier la cadence avec ‘v‘. (La rapidité s’inverse pour redevenir Lente.)
19) Tenter à nouveau d’envoyer des caractères avec ‘&’ suivi de quelques lettres.
20) Expérimenter le message « bonjour » en ne validant qu’à la fin. Comme on a dépassé un caractère
l’expérience se solde par un échec et aucune action n’est réalisée à part l’alerte.
21) Recommencer, mais en validant à chaque lettre. C’est vraiment laborieux. Aussi, on va changer
radicalement de protocole en passant en mode TEXTE.
22) Imposer le mode COMMANDE avec ‘&‘ puis proposer ‘t‘.
MANIPULATIONS : (Suite)
23) Tester avec le texte « a b c d e f g h i j k l m n o p q r s t » précédé de ‘&‘. On remarque que les espaces ne provoquent plus d’erreur et sont ignorés. Quand on codera des phrases on pourra ainsi intercaler (Par la force de l’habitude.) des espaces entre les mots sans pénalité.
24) Continuer la séquence avec « uvwxyz« . (Les caractères complètent le formatage.)
25) Continuer avec « bonjour les amis. Tout va bien.« . Le cryptage se poursuit sans incident. On constate que le ‘.‘ n’a pas engendré d’erreur. (Comme pour l’espace le logiciel « pardonne.)
26) Expérimenter en proposant « à âéèêëîïôçûü« . Les caractères sont tous acceptés.
27) Introduisons une erreur avec « aaa(bbb« .
Considérons la Fig.31 dans laquelle en bleu pastel se trouve le cryptage précédent. Puis les caractères valides sont encodés dans la zone jaune. Un BIP sonore se fait entendre et entre crochets dans la zone orange le caractère incriminé est dénoncé suivi du texte vert. Le texte du message qui suit le caractère erroné est purement ignoré. (Il peut contenir n’importe quoi y compris des erreurs.) Pour que l’opérateur puisse continuer à crypter, le texte correct qui a été transcodé est précisé entre ‘<‘ et ‘>’ non brouillé pour mémoire. Il suffit de reprendre la suite sans autre difficulté.
28) Pour finir cette prise en main de la machine, revenir aux COMMANDEs avec ‘&‘.
29) Enfin consigner la lettre ‘p‘.
– Bande de Dudules, ce n’est pas le moment comme indiqué en début de ce chapitre !
Un bilan sur l’évolution du programme.
Nous n’avons toujours pas écrit une seule ligne pour commencer à réaliser notre codeuse virtuelle et déjà un cinquième de l’espace réservé au programme est consommé. Pourtant, à ce stade du développement il n’y a pas vraiment de raison de s’inquiéter. En effet, avec l’interface H/M je vous avais prévenu que le code serait probablement glouton en octets. De plus, les « dialogues » sont en place et l’analyse syntaxique est complète pour les fonctions actuelles. Par ailleurs on peut s’informer dans l’encadré situé en bas de la page 22 qui conseille que si la mémoire non volatile EEPROM n’est pas utilisée pour mémoriser des données y loger un maximum de textes affichés. C’est bien entendu ce que nous allons faire dans un démonstrateur futur. Sur le thermomètre est symbolisée en orange la place occupée par les textes affichés soit environ 5% de l’espace réservé au programme ce qui n’a rien de négligeable. Et surtout, ces textes considérés comme des tableaux sont clonés en mémoire dynamique dans laquelle ils consomment environ 849 octets sur les 2048 disponibles. Aussi, lorsque les textes seront passés en EEPROM ces 849 emplacements redeviendront disponibles pour les données temporaires. Il serait possible de procéder maintenant à cette refonte du programme. Mais si l’on ne commence pas à créer « du matériel », je sens que vous allez devenir fébriles ou nerveux. Aussi, dans le démonstrateur suivant on va débuter la création de la machine virtuelle en réalisant et en testant un Rotor virtuel. Il sera alors judicieux de le ranger en « magasin », c’est à dire en EEPROM nous en verrons la raison plus avant. On en profitera pour y loger tous les textes de l’interface H/M pour alléger le programme.
la suite est ici.
