Oublié le réveillon, soirée en famille qui a redynamisé les équipes. Il était temps, car les semaines passées ont été rudes, un peu de repos était devenu indispensable. Alors, se retrouver en famille à proximité du beau sapin relevait autant d’une pause médicale que d’une tradition séculaire. De retour en salle informatique S4, le cliquetis des claviers d’ordinateurs a réinvesti le bruit de fond discret de d’espace de travail encombré de consoles informatiques. Les ingénieurs s’affairent, car ils vont développer du conversationnel entre deux blocs de silicium et ils savent pertinemment que ce n’est pas gagné d’avance …
Faire dialoguer deux machines n’est absolument pas élémentaire. Contrairement aux bavardages humains pour lesquels les messages sont transportés par l’air ambiant, sur des machines ce sont des impulsions binaires qui se succèdent à cadences élevées sur les lignes filaires de communication. Dans notre cas ce seront TX et RX sur D0 et D1 qui seront affectées à cette fonction palabresque. Non seulement pour se comprendre les deux machines devront échanger des propos par le biais de protocoles
très précis, mais surtout des problèmes de synchronisation sérieux pourront rompre et bloquer « les discutions ». La Fig.227 résume l’architecture globale qui présidera la conduite des études indigestes à venir.
Dialogue Homme / Machine : Le retour.
Globalement nous allons retrouver les préceptes qui dominaient le dialogue entre le P.C. et JEKERT. La grande différence réside dans le fait que maintenant c’est une carte Arduino NANO qui sera chargée de gérer un Clavier et un Écran local intégrés dans un Pupitre de commande que l’on nommera aussi Raquette de commande, vocable suggéré par ses dimensions les plus réduites possibles. Décortiquons le principe d’un échange « verbal » entre l’Humain et les deux Machines :
1) Le programme du pupitre P est en attente d’une directive issue du Clavier, l’information qui en résulte transite comme l’indique la flèche bleue. (Par exemple on cliquera sur un bouton poussoir.)
2) Pour aider le technicien qui exploite la sonde, P affiche sur l’Écran local des informations traduisant les actions de l’opérateur sur le Clavier. (Flèche symbole jaune.)
3) La directive de l’opérateur est alors traduite en Consigne et P va Parler sur TX. Puis, comme on va privilégier un mode alternat, P va immédiatement Écouter sur sa broche RX.
4) Le logiciel Esclave S étant à l’Écoute sur sa broche RX enregistre le message reçu.
5) L’analyseur syntaxixe décode cette Consigne. Si elle est valide, immédiatement elle est exécutée. Après une éventuelle action valide, S ensuite Parle sur TX pour ACcuser Réception.
6) Le logiciel Maître du pupitre P décortique l’ACR reçu sur RX et rend compte sur l’Écran local après une mise en forme, puis immédiatement se replace en surveillance du Clavier.
Étant donné que les affichages sur l’Écran local sont gérés par la carte P, il devient totalement parasite d’encombrer les échanges Consigne / ACR par du « bavardage » de présentation claire pour l’humain. Rendre ces « données Machine » aussi compactes que possible aura deux conséquences positives. D’une part les dialogues binaires prendront moins de temps en ligne TX/RX. D’autres parts le logiciel Esclave va considérablement maigrir. Il faut donc revoir entièrement les protocoles de dialogue entre les deux ATmega328. Il importe aussi de déterminer quel type de clavier sera utilisé, et choisir un module électronique pour équiper l’Écran local de la Raquette de commande. Autant pour le clavier on peut se servir de boutons poussoir provisoires, autant pour l’écran il va falloir porter notre dévolu sur un modèle précis, car le développement sera tributaire de sa présence pour arriver à savoir ce que se disent les deux machines … espionnage oblige !
Organiser le développement.
Difficulté nouvelle, deux entités sont concernées à chaque étape des essais. Ce n’est plus un seul démonstrateur qu’il faut mettre au point, mais associer deux programmes qui seront téléversés. L’un sur la carte Arduino NANO S de la sonde, l’autre sur un module P quelconque placé sur une plaque de contacts à essais, entouré d’une foule d’éléments provisoires reliés par plein plein plein de fils électriques. Entre ces deux circuits ATmega328 on va croiser deux lignes filaires sur TX et RX puis, mettre à contribution l’IDE pour développer les deux démonstrateurs.
Facile à dire ! Dans la pratique, la mise en œuvre se complique car on doit programmer pour S, téléverser vers la sonde, puis développer pour P et téléverser. Puis, les deux démonstrateurs étant résidants dans les deux cartes, établir les deux liaisons de dialogue et procéder aux essais.
PROBLÈME : La ligne mini USB qui permet de dialoguer avec le P.C. interfère sur les broches D0 et D1 et réciproquement. Vu le nombre d’essais que l’on va devoir conduire, on ne va pas passer notre temps à brancher et débrancher des lignes USB, sans compter qu’à la fin, la fiabilité des prises risquerait fort de se voir dégrader. Nous avons beaucoup de chance, car l’IDE est conçu pour pouvoir développer plusieurs « Sketch » simultanément. Considérons la Fig.228 qui est dérivée de celle de la Fiche n°31 résumant les techniques à utiliser. Oublions dans un premier temps la façon dont seront alimentées les deux cartes Arduino. Pour le moment ce seront les deux prises USB du P.C. qui fourniront l’énergie aux deux modules, la masse GND étant commune on s’en doutait bien.
Réaliser un premier bavardage entre l’Homme et la Machine.
Première manipulation pour tester le dialogue entre les deux machines, nous allons devoir concrétiser l’agencement de la Fig.228 et le mettre en œuvre matériellement. La Fiche n°31 résume les branchements et la façon de réaliser cette première expérience. Toutefois, comme c’est la première fois que vous allez tenter ce type d’expérience, nous allons y aller progressivement. On partira pour cette tentative d’une configuration où aucune des deux cartes n’est reliée au P.C. et l’éditeur de l’IDE n’est pas ouvert. En résumé on se trouve en activité hors programmation. Sur la plaquette d’essais le module Arduino, le clavier expérimental X et Y et la LED rouge sont câblés. L’inverseur d’isolement est également en place avec les lignes TX et RX branchées.
1) BASCULER l’inverseur vers IDE sur le P.C. c’est à dire ouvrir la ligne croisée de dialogue,
2) Brancher la carte Arduino S de la sonde sur l’une des lignes USB disponible du P.C,
3) Activer l’IDE en ouvrant l’éditeur sur le démonstrateur P19_PGM_Esclave_minimal.ino,
4) Outils > Type de carte > Vérifier la puce : 
,
5) Outils > Port > Valider le port octroyé à cette prise USB. Par exemple le cochage : 
,
6) Téléverser le démonstrateur de la Sonde P19_PGM_Esclave_minimal.ino,
7) Brancher la carte Arduino P de la plaque à essais une autre ligne USB disponible du P.C,
8) Activer un clone de l’IDE en ouvrant son éditeur sur le deuxième démonstrateur logiciel P18_PGM_Maitre_minimal.ino, car on peut ouvrir plusieurs instances du compilateur simultanément. C’est l’un des points forts de l’environnement d’Arduino.
09) Outils > Type de carte > Vérifier la puce : (Rien n’interdit à ce stade d’utiliser une carte UNO par exemple, mais je ne vous le conseille pas. En effet, sur une NANO on ne dispose que de 30720 octets pour le programme, alors que sur UNO il y en a 32256. Autant développer sur la carte cible pour éviter des surprises. De plus UNO ne dispose pas des broches A6 et A7.)
10) Outils > Port > Valider le port octroyé à cette prise USB. Par exemple le cochage : 
,
11) Téléverser le démonstrateur sur la Sonde P18_PGM_Maitre_minimal.ino,
12) BASCULER l’inverseur vers Dialogue TX/RX c’est à dire établir la liaison croisée de dialogue,
13) En fonction des démonstrateurs téléversés procédez aux essais de validation.
14) BASCULER l’inverseur vers IDE sur le P.C. pour reprendre l’édition des logiciels.
Facilité apportée par l’agencement d’une carte Arduino, si sur l’une des deux fenêtres du compilateur on valide le Moniteur série, l’écran du P.C. affiche les textes des messages envoyés par le programme en cours d’exécution. C’est parfois bien commode pour lever un doute. Concernant ce premier essai on valide intégralement la chaîne de dialogue puisque l’on donne une consigne sur l’un des deux boutons poussoir du banc de test, les deux machines dialoguent et le Maître rend compte sur l’écran local qui ici se résume à une LED rouge. La boucle est bouclée …
Allons voir dans l’éditeur du programme P18_PGM_Maitre_minimal.ino le listage du premier démonstrateur qui va assurer les échanges en mode alternat sur la longue ligne du cordon ombilical. Et oui, vous vous en doutiez bien qu’à un moment ou à un autre il faudrait le brancher ce cordon de deux mètres de longueur. Pour valider avec fiabilité les programmes qui vont être développés, il importe de se placer dans les conditions « définitives ». Ainsi on pourra déterminer jusqu’à quelle vitesse de transmission maximale on peut de façon fiable déclencher les échanges. Plus cette vitesse sera élevée, moins les durées pour échanger les données prendront du temps.
Ça alors, pour dialoguer sur les broches D0 et D1 d’Arduino on continue bêtement à utiliser les instructions banales telles que Serial.begin(115200), Serial.print(« texte »), Serial.available() et Serial.read(). Nous n’avons pas à écrire nos propres routines. Magnifique !
Et oui, D0 et D1 sont aussi nommées TX et RX car elles sont directement associées aux lignes de donnée de la prise USB par une électronique installée sur les cartes Arduino. Mise à part la nécessité d’ouvrir les lignes de dialogue sur D0 et D1 pour téléverser un programme et les rétablir pour le tester, il n’y a rien d’autre à faire. C’est proprement génial, car le programme complet peut servir directement pour effectuer des essais … et comme on va le voir ça fonctionne merveilleusement bien. Zavez vu ? Dans le démonstrateur les octets cavalent à 115200 bauds, autant dire que l’on ne perdra pas plus de temps sur le cordon ombilical de deux mètres de longueur qu’en dialoguant avec le moniteur série du P.C. Le concept Arduino est carrément fabuleux.
Le syndrome de la carpe.
Incident agassif au possible, il peut inexorablement arriver que sur une fausse manœuvre un couple de programmes parfaitement au point devienne complètement muet. Inutile de vous escrimer sur le bouton de RESET, quand tout est bloqué, s’acharner sur ce pauvre poussoir ne servira strictement à rien. Cet incident arrivera avec certitude chaque fois que vous tenterez de téverser un programme dans l’une des deux cartes et que l’inverseur est resté sur Dialogue TX/RX. C’est imparable, la seule façon de débloquer le système consiste à suivre la procédure donnée en bas de la Fiche n°31 et nommée pour la circonstance Reprise d’une synchronisation avec l’IDE.
Ce type d’aventure constitue le prix à payer pour bénéficier de l’immense facilité apportée par l’environnement de programmation pour faire usage d’une ligne série. Il faudra donc s’armer de rigueur, et chaque fois que l’on aura terminé des essais BASCULER l’inverseur vers IDE sur le P.C.
pour reprendre l’édition des logiciels. Globalement cette précaution va rapidement devenir une habitude. Reste qu’il suffit que l’une des deux cartes peut facilement faire perdre la synchronisation sur la ligne de dialogue si son programme interne comporte une quelconque erreur.
Ça va dropper !
Maintenant que nous avons vérifié que la cadence de tir sur TX et RX sera considérable, il nous reste à maîtriser des échanges automatiques à des rythmes très élevés et vérifier si on peut le faire raisonnablement sans perte de synchronisation et de façon fiable. Dans ce but on téléverse P30_Programme_COMPLET_T5.ino sur la carte esclave S de la sonde. (Et oui, je vous l’avais dit que l’on pouvait user des logiciels sans modification … à condition toutefois que sur la carte du pupitre P on téléverse un programme adapté.) Puis, sur la carte du pupitre P on télécharge le démonstrateur P20_Maitre_pour_dialogue_rapide.ino qui va se charger de causer de manière entièrement automatique avec JEKERT. Quand les deux machines sont munies des logiciels en question, vous établissez la liaison ombilicale, un petit RESET sur P et vogue la galère.
Chaque alternat inverse l’état de la LED rouge. Si conformément aux remarques données dans le démonstrateur P20_Maitre_pour_dialogue_rapide.ino vous avez branché un bruiteur sur la sortie D6, chaque fois que les machines auront réalisé 1000 alternats, c’est à dire 500 allumages des phares et du LASER et 500 extinctions de ces deux périphériques, un BIP sonore sera généré.
– À donf le bla bla bla, ça cause un max !
Examinons le contenu de la boucle de base du programme Maître :
Sa structure est d’une banalité évidente. En (1) le programme transmet sur la ligne série du cordon ombilical une Consigne pour alterner l’activation des phares. Puis, immédiatement après avoir transmis la Consigne, le logiciel se met à l’Écoute pour réceptionner l’ACR.
Étonnant, on raconte que l’on va chercher à dialoguer le plus rapidement possible, et bêtement on paralyse l’ATmega328 pendant 3mS ! Puis, après ce gaspillage de temps la ligne (2) transmet une Consigne pour alterner l’activation du LASER. Rapidement il repasse à l’Écoute pour réceptionner l’ACR. Et nouvelle consommation de temps de 3mS à se tourner les Octets !
Pas grand chose à dire pour la suite. En (3) on incrémente le compteur de bavardages, puis en (4) on génère le BIP sonore tous les 1000 échanges du type « fais ça » / « C’est fait ».
Pourquoi ces deux instructions delay(3) ?
La synchronisation.
Imaginez-vous à l’école. (Berkkk, on va travailler !) Le Maître Parle sans interruption. Vous Écoutez avec attention, cependant le temps pour tout écrire n’est pas suffisant et la main prend du retard sur les oreilles. Arrivera le moment où quelques mots vont se perdre. Du coup, la phrase qui suit n’est pas complète et vous ne comprenez plus tout à fait ce que raconte le Maître. Vous avez perdu la synchronisation. C’est exactement ce qui peut se produire lorsque deux machines dialoguent. Passez les deux temporisation delay(3) en remarque avec // ou effacez ces instructions dans P20_Maitre_pour_dialogue_rapide.ino et relancez le bavardage. La sonde va immédiatement se fâcher tout rouge et générer à la pelle des BIPs d’alertes sonores. Sa mémoire tampon réservée pour la ligne série est saturée car le Maître cause trop rapidement. L’Esclave n’a pas le temps de tout réaliser. Quand il revient à l’Écoute une partie du message a été perdue car le tampon mémoire de la ligne série est gavé. Le message étant incorrect S fait alors entendre sa désapprobation.
Analysons le listage de la Fig.229 en supposant que l’on n’a pas codé les deux temporisations. En ligne (2) dès que le démonstrateur à reçu et analysé l’ACR issu de l’Esclave, en quelques microsecondes il traite les ligne (3) et (4) puis immédiatement se remet à Parler en (1). Pendant cette courte durée que laissent (3) et (4) l’Esclave doit traiter tout ce qui se trouve dans sa boucle de base entre Accuser réception et Attendre_une_chaine c’est à dire l’intégralité des instructions de (3) à (10) suivies de(1) et (2). Pour beaucoup la ligne se résume à un test négatif et passage à la suite. Par contre, en (6) l’instruction s’avère plus gourmande en µS car elle procède à une mesure sur l’entrée analogique du microcontrôleur avec interpolation des valeurs, et un test négatif active un else.
Toutes ces instructions exigent plus de temps processeur sur l’Esclave que (3) et (4) sur le Maître qui de ce fait parle à une cadence trop rapide. Si on ne ralentit pas son débit « verbal » il y aura perte d’une partie de certaines Consignes et génération d’erreurs.
Pour éviter une telle perte de synchronisation qui pourrait aller jusqu’au blocage complet des dialogues, il importe de temporiser le Maître donc générer un petit délai AVANT de Parler.
Dans le démonstrateur on constate que des loupés se produisent si on limite à delay(2). Il sera impératif de se montrer prudent, car dans cette manipulation aucune des LEDs d’état n’est allumée. Tous les tests sont négatifs. Si certaines fonctions comme la Torsion ou la Stabilisation Gyroscopiques imposent du traitement en temps réel, le délai d’attente devra forcément être augmenté. Se pose alors la question de savoir quelle valeur de « temps gaspillé » adopter.
Nouvelle approche conversationnelle : Pour contourner radicalement ce problème, une approche différente consiste à réorganiser la structure de la boucle de base du programme Esclave. Cette boucle sera conçue avec une chronologie légèrement différente :
Avec cette nouvelle structure, quel que soit le temps passé à traiter les fonctions de la boucle de base, après avoir accusé réception l’Esclave repasse immédiatement à l’Écoute.
Repartir de zéro pourrait sembler pessimiste, voir frustrant. C’est pourtant la façon la plus rationnelle de reconstruire entièrement l’édifice logiciel. La structure de la boucle du programme fonctionnant sur JEKERT sera différente. Nous allons réduire au minimum les informations retournées sur TX puisque la mise en forme sera traitée sur le programme Maître. Par ailleurs, il n’est plus utile d’envoyer des consignes sous forme de texte faciles à mémoriser puisque l’interface Homme/Machine sera sur la Raquette de commande. Aussi, à bien y regarder nous allons concrètement agencer deux programmes entièrement nouveaux. Chercher à récupérer la dernière version P30_Programme_COMPLET_T5.ino et l’adapter serait du « bricolage » avec un risque d’effet « boule de neige » trop important, avec le danger de conserver des commandes qui ne sont plus pragmatiques, de conserver des variables devenues inutiles etc. Il faut entièrement revoir l’analyseur syntaxique, on va remplacer le potentiomètre par un codeur Rotatif etc.
La meilleure approche à mon sens consiste à construire progressivement et simultanément les deux logiciels associés. Pour le programme Esclave on récupérera les séquences au point, mais une à une avec chaque fois les essais de validation qui s’imposent sur les deux machines, ainsi que la mise en place des affichages sur l’écran de contrôle du pupitre de commande. On se doute que la mémoire non volatile sur S contiendra moins de textes, son implantation sera certainement différente.
En préambule à tous ces chamboulements, il semble judicieux de concevoir globalement ce que pourra être le pupitre de commande car sa gestion par P en dépend directement.
Bref, on a pas mal de pain sur la planche …
Remettre entièrement en cause un gros logiciel qui globalement a fait ses preuves ne consiste pas de repartir entièrement depuis zéro. Si l’on désire bénéficier un maximum des fruits précédents, il importe de procéder avec rigueur, on évitera ainsi des pertes de temps considérable et surtout on progressera résolument. On se doute que pour « diviser pour régner » on va produire un grand nombre de démonstrateurs. Aussi, pour ne pas s’égarer dans fichier, tout ce qui va suivre sera rangé à part dans le dossier <Sonde et Raquette>. Tout ce qui précède concernant la faisabilité d’un dialogue Machine/Machine est mis à part dans <Dialogue_entre_Machines>. Voici globalement comment on va procéder pour récupérer le code déjà au point et pour différencier les divers démonstrateurs qui vont se succéder :
1) Copier P30-T5 dans A_VIDER.ino qui servira à puiser les séquences et les initialisations déjà bien au point. (Certaines seront modifiées pour améliorations ou surtout simplifications.) Chaque ligne de cote prise en compte est enlevée. Ainsi à la fin on verra ce qui reste et qui est devenu inutile et surtout on discernera éventuellement des détails oubliés qui ont leur importance.
2) Bien que sur la Sonde le BUZZER n’est plus utile puisque les avertissements seront « sur Terre », BIP() est conservée puisque le matériel est disponible. Ainsi, on peut s’en servir pour traceur auditivement des points de passage durant le développement du démonstrateur et ainsi vérifier si le programme invoque certaines séquences ou non. (C’est un outil de programmation.)
3) On va développer des démonstrateurs progressifs :
P21v_Démonstrateur_Raquette.ino pour les logiciels « fragmentaires. (1)
P22v_Démonstrateur_Sonde.ino pour les logiciels « fragmentaires. (1)
4) P40_PGM_RAQUETTE_MAITRE.ino recevra au fur et à mesure du développement des démonstrateurs les compléments mis au point. C’est donc le programme complet définitif.
5) P50_PGM_ESCLAVE_SONDE.ino recevra au fur et à mesure du développement des démonstrateurs les compléments mis au point. C’est donc le programme complet définitif.
Évalué globalement, le pupitre de commande sera équipé d’un clavier CLv à seize touches. La répartition géométrique sur le coffret n’est pas définitivement définie, le besoin par contre montre que seize boutons poussoir ne seront pas de trop. Ce nombre n’est pas le fruit du hasard. Il correspond à une optimisation fonctionnelle, ainsi qu’à une optimisation dans le cas d’un traitement multiplexé sur un petit clavier matricé du commerce servant aux essais. Pour piloter le LASER, la TORSION, le niveau des éclairages nous utilisions sur le prototype un potentiomètre. Aussi, personnellement je n’aime pas trop ces dispositifs qui dans le temps se mettent à « cracher ». Par ailleurs, balader des signaux analogiques de tension faible sur de longues lignes filaires les rend très sensibles aux parasites électromagnétiques environnants. Aussi ce dernier sera remplacé par un Codeur Numérique Cn. Enfin nous visualiserons les données sur un écran graphique Ecr. La Fig.231 résume assez bien les divers périphériques qui devront être gérés par le logiciel P21v. Nous allons en toute logique devoir développer trois démonstrateurs A, B et C. On va réserver trois chapitres dédiés à ces divers démonstrateurs.
La suite est ici.
