Naturellement, vous vous êtres précipité dans le dossier <Platine UNIVERSELLE> pour lire avec attention le document nommé PLATINE D’expérimentation UNIVERSELLE.pdf dans un souci d’originalité. J’espère que vous avez au final réalisé un tel module qui vous servira pendant des années pour développer des programmes sur Arduino. Pour savoir ce qu’est un réseau en anneau, vous avez également parcouru entièrement le chapitre les concernant dans Types de réseaux et aspects logiciels.pdf. Nous avons tout ce qu’il faut pour reprendre allègrement « le trio infernal ».
Les choix logiciels.
Toute la stratégie organisée dans l’analyseur syntaxique qui sera chargé de décrypter le contenu des JETONS et d’en informer le démonstrateur sera basée sur des paquets de données vraiment élémentaires, affin de rendre la plus facile possible la lisibilité des listages des programmes. Les données seront constituées de textes alphanumériques ne comportant que trois caractères. Toute longueur plus importante ou plus faible engendrera une erreur de type AnE. (A pour l’adresse.)
Les JETONS seront de structure A:L , le séparateur « : » et la longueur de 3 seront vérifiés.
• A est l’adresse du poste de Travail. (Chiffre entre 1 et 4 si vous possédez le matériel.)
• L est la lettre de l’Action locale à gérer. (1)
• Les types d’erreurs possibles sont consignés dans le tableau Fig.71 qui reste bien modeste.
Les actions possibles sur chaque poste vont se résumer à allumer ou éteindre des LEDs histoire de n’avoir à câbler que des circuits élémentaires. On va prévoir aussi quelques actions particulières pour gérer l’activité des écrans de visualisation dans le cadre de fonctionnement en mode INFINI comme c’était le cas pour les réseaux de type Alternats :
Compte tenu du comportement attendu de l’ensemble, et vu que l’unité de pilotage n’attend plus forcément un retour, la présence du TIME OUT reste nécessaire. Par ailleurs la technique pour synchroniser l’ensemble va se simplifier et consister par envoyer un JETON qui ne concerne personne (Adresse inconnue de tous les postes de travail.) et attendre son retour en orphelin. Quand ce sera le cas, c’est que la boucle s’est refermée et que tous les modules communiquent.
Les choix matériels.
Tester le fonctionnement d’un réseau en anneaux impose au moins deux Postes de Travail. En ajoutant la station de pilotage, on retrouve globalement la structure du « trio infernal ». L’aspect logiciel est toutefois « plus léger », car dans le chapitre précédent il fallait développer trois démonstrateurs de structures vraiment différentes. Dans le cas du réseau en anneau, c’est plus simple puisqu’il suffit de créer le programme pour gérer la console de pilotage et le démonstrateur pour animer un poste de Travail. Ce sera le même logiciel pour toutes les unités « de fabrication », car elles ont toutes une structure identique. Seul l’analyseur syntaxique devra tenir compte des spécificités locales, et adapter les routines d’Action. Il nous faut faire des choix pour affecter les rôles dans le nouveau « ménage à trois » … ou plus si vous avez le matériel.
• C’est une carte UNO ou une NANO qui se chargera de gérer le Poste de pilotage, avec un afficheur OLED de 64 x 128 PIXELs de définition, on peut y afficher plus de données pertinentes. Évidemment, nous serons obligés d’utiliser RX sur D0 de la ligne de dialogue USB pour réceptionner les JETONS orphelins et les retours signalant une erreur. (Inverseur d’isolement pour téléverser …)
• La carte NANO du module « UNIVERSEL » pouvant gérer deux modules Bluetooth sera tout naturellement affectée à la gestion de l’un des Postes de pilotage. Autant choisir le n°1 car il n’y aura pas à compléter son câblage et l’on pourra tester le dialogue avec seulement deux unités.
• La carte NANO du programmateur de Bluetooth sera bien utile pour s’occuper du Postes de pilotage n°2, mais il faudra réaliser le circuit corrigé et complété des cinq LEDs oranges pour gérer un deuxième module de transmission sur 2,4GHz. C’est parti, on peut commencer à programmer les démonstrateurs. Mais avant, il faut décider des adresses affectées aux modules et établir la liste des travaux réalisables sur chaque Unité de Travail ainsi que les protocoles qui en découlent. Après une analyse préalable je propose les comportements résumés dans le tableau de la Fig.72 sachant qu’un seul témoin logique sera allumé à la fois sur tous les modules de Travail.
Pour bien résumer la structure d’un réseau en anneaux dans lequel chaque module Bluetooth ne sera exploité que sur RXD ou sur TXD mais pas sur les deux, la Fig.73 résume l’architecture globale.
Il faut également décider des comptes-rendus qui seront affichés sur les divers écrans OLED.
Logiciel sur un poste de travail.
À part quelques petites différences listées dans l’encadré par étoiles dans le listage du démonstrateur, tous les croquis ayant pour cible un poste de travail sont identiques. Il suffit de les intercaler dans le réseau en anneau avec deux modules Bluetooth. Celui en entrée est de type Esclave appairé avec le transmetteur situé en amont, celui en sortie est de type Maître et accouplé avec le module de réception situé en aval.
Sur RESET ou à la mise sous tension, l’afficheur OLED présente le démonstrateur, et en Fig.74 on observe qu’il nous prévient qu’il est en attente d’un JETON Tant qu’il n’aura pas reçu une première consigne le concernant ou pas la LED d’Arduino clignotera. Chaque JETON reçu est analysé s’il concerne le poste, ou simplement remis en ligne vers l’Aval si le message n’est pas pour lui. Si le JETON concernant le poste de travail est correct, il n’est pas transmis et l’écran OLED sur la Fig.75 indique bien avec le « /// » que ce message n’a pas été remis en réseau. JETON correct, l’action qu’il indique est immédiatement réalisée. S’il concerne le poste mais qu’il comporte l’une des trois erreurs potentielle, l’analyseur syntaxique la détecte. Le JETON est alors renvoyé dans le réseau avec le numéro de l’erreur et l’origine du poste qui en est victime. Ce dernier dans ce cas se contente de poursuivre le Travail qui était en cours. En relation avec la Fig.73 on va commenter le contenu des écrans, car les textes peuvent sembler « curieux ». Sur la ligne du haut on affiche le contenu du JETON qui arrive. On s’attendrait alors à un RX pour récepteur. Hors c’est TX1 qui est précisé. C’est que l’on fait référence au Bluetooth Esclave 1 placé en entrée. Hors c’est sa sortie TX1 qui fournit le JETON. En sortie, on retourne les données sur RX2 du Bluetooth Maitre 2 qui fait suivre les données en Aval. Donc les affichages font référence à ces désignations. Sur la Fig.75, le poste de Travail n°1 a réceptionné 1:J. Le JETON est pour lui. L’action J existe. Le ‘:‘ est en place et la longueur du message est bien de 3. L’analyseur syntaxique accepte la donnée qui ne sera pas transmise en aval, d’où le « ///« . En Fig.76 l’adresse est 2. Le poste de Travail n’est pas concerné. Il se contente de transmettre en aval le JETON complet sans l’analyser.
Finalement, quand on va devoir répartir les modules Bluetooth sur les cartes Ardiono, on risque de se tromper entre position entrée et position sortie. Pour vous éviter toute erreur, la Fig.77 résume la structure du réseau. Que ce soit pour attendre le premier JETON qui concerne le poste de Travail, ou dans le fonctionnement courant, c’est la procédure Recevoir_un_JETON() qui effectue tout le travail du démonstrateur. La structure du programme est proposée en Fig.78 sous forme d’un organigramme. Du reste, c’est la seule action programmée dans la boucle de base void loop().
En (1) le contenu de JETON est mémorisé en vue de l’afficher sur la ligne du haut de l’écran OLED en (5). On peut se demander pourquoi en (2) le chiffre qui caractérise l’erreur détectée est de type char. C’est pour simplifier considérablement le logiciel. En effet, le contenu de JETON[N] est de type char. Comme la donnée retournée en ligne contient ce nombre, pour l’insérer il faudrait le convertir en char, alors autant utiliser directement ce type de donnée. C’est en (3) que le JETON est modifié pour signaler une Erreur issue du poste de Pilotage, donc de l’opérateur. En (4) le travail consiste globalement à allumer ou éteindre des LEDs. Très rapide à exécuter, le logiciel peut immédiatement repasser en attente d’informations sur le réseau. C’est la raison pour laquelle il n’est pas obligatoire dans le démonstrateur de prendre en charge les JETONs par interruptions. Le logiciel s’en trouve grandement simplifié.
Vérification du démonstrateur en aveugle.
C’est par le développement des démonstrateurs pour les postes de Travail qu’ont débuté les analyses et l’écriture des croquis. Sur les deux circuits imprimés, (PROGRAMMATEUR et UNIVERSEL.) c’est RX qui dessert la ligne de dialogue USB qui sert d’entrée d’informations issues du module Bluetooth connecté. Quand on effectue un affichage vers le Moniteur de L’IDE, c’est TX qui est sollicité. Hors il est branché sur le Bluetooth situé en Entrée. Ce dernier transmet ver le Maître situé en amont le texte intégral de l’affichage. En amont, les réceptions sur le circuit 2,4GHz ne sont pas exploitées. Il est donc possible d’afficher sur la ligne USB tout ce que l’on désire. C’est ce que fait le démonstrateur. Aussi, si vous n’avez pas investi dans une carte NANO élargie, il vous sera possible de visualiser, comme montré sur la Fig.79, ce qui se passe sur les deux postes de Travail. C’est tout l’avantage de la compatibilité totale entre une NANO classique et une carte étendue. Vous ne serez « en aveugle » que sur le circuit imprimé proprement dit.
La souplesse matérielle du Poste de Travail n°1.
Bien qu’utilisable uniquement avec le Moniteur de l’IDE, comme pour le réseau en mode alternat, le démonstrateur P19 est prévu pour une carte NANO élargie avec afficheur OLED de 32 x 128 PIXELs intégrée. Hors, souvent, les offres de composants incluant plusieurs unités étant avantageuses, on les approvisionne par deux ou trois … voir plus. Du coup, comme le circuit imprimé prétendu UNIVERSEL peut loger un tel afficheur de type OLED de 1,3 pouce de diagonale, autant en faire profiter celles et ceux qui disposeraient d’au moins deux de ces afficheurs. Dans ce cas, pour effectuer les manipulations de vérification des postes de Travail, dans l’item 05) il suffit de téléverser le démonstrateur adapté P19_Bis_Poste_de_Travail_1.ino sur le circuit « UNIVERSEL ».
Sur ce démonstrateur les affichages ont été adaptés et l’expérimentation ne sera plus « en aveugle ».
La suite est ICI.
