Concrètement, ce langage particulier à la syntaxe très simplifiée est prévu non pas pour effectuer du dialogue entre machines, mais pour pouvoir analyser les données internes d’un module Bluetooth et de pouvoir à notre convenance modifier ces constantes et ainsi le conditionner entièrement en fonction des besoins du programmeur. C’est en particulier par cette voie que l’on affectera au module en cours de traitement le rôle de Maître ou celui d’Esclave.
SYNTAXE du « langage » AT.
Bien que d’une structure assez « télégraphique », il s’agit bien d’un langage puisque c’est par lui que l’on peut communiquer avec une machine et se comprendre. Dans toute discussion il faut que le Maître, c’est à dire celui qui anime la « conversation » puisse poser des questions et la deuxième entité, c’est à dire ici le module électronique, puisse apporter des réponses. Dans une telle procédure, le dialogue s’établit en mode alternat. (On verra l’importance de cette remarque dans le prochain chapitre.) La forme grammaticale d’une « phrase » dans le langage AT est la suivante :
En résumé, toute phrase doit commencer par AT+ suivi d’un item. (Saut si l’on ne frappe que les deux lettres AT pour vérifier que le module Bluetooth répond sur sa ligne TX.) Si c’est une question, la phrase se termine par ‘?‘. Si on impose un paramètre, l’item est suivi de ‘=‘ et d’une valeur. La valeur peut être alphabétique, numérique ou complexe en fonction de l’item.
Le contexte du « langage » AT.
Deux faiblesses rendent le programme P01 peu convivial. Il faut gérer entièrement la frappe et en particulier ne proposer que des lettres majuscules. Quand on a validé une consigne, l’écran affiche le contenu de l’accusé de réception. Si c’est FAIL par exemple, la ligne de saisie est effacée dans la fenêtre du Moniteur et il n’est plus possible d’analyser notre erreur. Pour palier ces deux faiblesses, on va changer de logiciel d’exploitation. Mais avant on va réaliser une petite expérience :
La Fig.7 est constituée d’un montage comportant plusieurs copies d’écrans effectuées lors de plusieurs expériences avec deux modules Bluetooth d’origines différentes.
Deux modules d’origines différentes ont été utilisés dans ce montage issu de huit copies d’écran effectuées l’ors de l’expérimentation pour avoir à la fois la consigne, et le contenu de l’accusé de réception qui en résulte. 1 et 2 ont été réalisés avec le premier exemplaire, alors que 3 et 4 sont le résultat de la deuxième référence. Les deux expériences « jaunes » sont réalisées avec l’unité qui pardonne intégralement la présence de lettres minuscules. Pour l’utilisateur on a ainsi un maximum de tolérance. Mais pour certains textes non conformes, il n’y a même pas d’ACR. C’est très ennuyeux sur le plan opérationnel. En effet, si le programme d’exploitation fonctionne en alternat et qu’il attend une réponse, le dialogue se bloque et impose un RESET pour reprendre « la discussion ». Le non respect de la syntaxe officielle pour les lettres n’est pas signalé, c’est intrinsèquement un manque de rigueur. Le risque, c’est de se former avec un tel module, et le jour ou on en change, on est en présence d’erreurs et on ne sait pas pourquoi. Par ailleurs, on constate que le OK peut être à la ligne en 1 ou en fin d’ACR en 2. C’est un manque manifeste d’homogénéité dans les réponses. Pour les deux exemples 3 et 4, il n’y a plus tolérance. L’utilisateur est ainsi obligé de faire un apprentissage rigoureux. Peu importe ces petits détails. Dans tous les cas, même si les réactions de votre module ne sont pas strictement identiques à celle de celui du tutoriel, vous allez rapidement vous rendre compte que ce n’est pas vraiment pénalisant. Pour apprendre le langage AT, nous allons téléverser P02_Configurer_le_module.ino qui va nous apporter quelques facilités :
La pratique du « langage » AT.
Comme je suis assez paresseux, pour ma part je vais utiliser P02_Configurer_le_module.ino pour effectuer les expériences de ce chapitre. Du coup, si vous faites appel à P01, vous aurez à gérer entièrement le texte à frapper dans la ligne de saisie du Moniteur. Dans ce chapitre on va expérimenter « en vrac » un certain nombre de commandes et « brasser large ». Puis à la fin du chapitre, on préparera deux modules, l’un en configuration de Maître, et l’autre en configuration d’Esclave, en vue de les faire dialoguer ce qui constitue le but fondamental de ce didacticiel.
Cette dernière expérience incite à proposer quelques commentaires :
Cette composition Fig.8 de plusieurs copies d’écran correspond aux manipulations qui précèdent.
Dans la zone rose le programme démarre. Il précise sa version puis nous prévient qu’il est en mode questionnement. En 1 nous avons juste proposé name et le logiciel à placé AT+ au début de la saisie et ajouté le ‘?‘ à la fin. Le module électronique à fournit une réponse standard car la commande est correcte. D’une façon générale, l’ACR d’une question commence par le caractère ‘+’ puis du texte de la commande suivi de ‘:’ et enfin la valeur correspondant à l’item. (ACR : ACcusé de Réception.) L’ACR se termine enfin par un espace suivi de OK. En 2 le contenu de la commande n’est pas affiché car le texte commençait par ‘&‘ qui est une consigne. Le programme n’envoie rien à l’esclave et se contente de nous informer de l’état du Mode Question qui en résulte. La valeur étant NON, le ‘?‘ ne sera plus généré, et c’est au programmeur de faire suivre son item d’un ‘=‘ suivi d’une valeur cohérente. Si vous avez respecté le tutoriel en 3, la commande complète comporte 45 caractères au total. Hors en 4 le nombre annoncé est de 32. C’est le nombre maximal de caractères que pourra contenir une saisie, limité par P02. C’est plus que suffisant compte tenu des limites imposées par le langage AT. Comme signalé, bien que le texte ayant été frappé en lettres minuscule, il est transposé en équivalent majuscules. Si vous désiriez un nom de module avec des minuscules, il faudrait utiliser P01, mais franchement ça ne présente strictement aucun intérêt. Chaque fois que l’on imposera une valeur, si la consigne est correcte le module se contentera de répondre par OK confirmant que la donnée a été modifiée. En 5 on revient au Mode Question pour vérifier les paramètres. En 6 on se contente de saisir name et l’on a la réponse. On constate que la longueur la plus importante pour le nom d’un module est de vingt caractères. Ouvrons une parenthèse bien utile :
Comme l’utilisateur peut désirer communiquer à une cadence quelconque, ce paramètre est modifiable à convenance. Ainsi dans les applications le programmeur reste maître de la ligne série n°2.
C’est parfaitement normal. Il est à ce stade configuré pour fonctionner en mode « normal ». Mais comme sa broche EN est toujours au niveau « 1 » il continue dans le mode AT. Ce n’est que lorsque EN sera réunie à GND que le module sera opérationnel pour une application.
Architecture d’une application utilisant deux HC-05.
Avant d’envisager une application concrète dans laquelle deux modules HC-05 vont dialoguer en mode alternat sur la fréquence de 2,4 GHz, il importe d’avoir une idée assez précise de l’organisation globale qui dans la pratique va impliquer du dialogue entre cinq machines. Autant dire que pour synchroniser tout ce petit monde, il importe de bien assimiler qui fait quoi, et dans cette famille qui commande. Dialoguer en mode alternat suppose qu’une hiérarchie soit clairement établie dans les échanges. Il y a le Maître, c’est à dire celui qui donne les ordres. Il y a l’esclave, celui qui cherche à satisfaire la consigne et qui rend compte de l’état, c’est à dire préciser s’il a été capable de satisfaire l’ordre où si la consigne n’a pas été traitée. Si l’ACR est du type ERREUR, c’est que le Maître a proposé une commande incohérente. N’ayant pas compris, l’Esclave ne prend pas d’initiative. Le schéma de la Fig.10 résume la situation. Analysons un échange entre toutes ces unités en supposant que l’opérateur engage un ordre correct assimilable par P03.
• Au sommet de l’échelle, c’est l’humain le « Grand Maître ». Il saisit sur la ligne du Moniteur une consigne conforme à ce que peut comprendre P04 sur l’Esclave 2 par son RX. C’est le Moniteur de l’IDE qui va transmettre sur TX de la ligne USB la consigne sur RX. La vitesse de transmission sur USB peut être quelconque mais identique sur le Moniteur et sur P04.
• Le logiciel P04 étant Maître à son tour par rapport à 3, il communique à ce dernier la consigne élaborée par P04 sur TX par la broche D3. La transmission se fait alors par la Ligne Série n°2 qui peut être à un format quelconque, à condition qu’elle soit la même dans P04 et dans l’initialisation du Module HC-05 1. Le module étant Esclave, il est en attente d’une consigne.
• À son tour, le Module HC-05 1 transmet le message reçu sur son RXD dans l’émetteur TX interne sur une fréquence de 2,4GHz. Sur cette voie il est le Maître par initialisation AT, donc il parle en premier. Puis immédiatement passe en écoute pour attendre le retour. La transmission est aveugle.
• Dans l’environnement immédiat, seul le Module HC-05 2 repéré 5 avec la bonne adresse et ayant le même mot de passe sera concerné et va recevoir sur son RX la consigne qu’il transfère en interne sur TXD. Il était en attente car configuré en Esclave par initialisation AT.
• L’Arduino n°2 reçoit sur RX broche D2 la consigne. Il était en attente car géré en Esclave par P03. Le format des échanges entre 4 et 5 peut être quelconque puisque géré par la Ligne série n°2 avec P03. Mais il faudra que sur 5 lors de l’initialisation en mode AT elle soit identique.
• Le programme d’exploitation dans P03 comprenant la consigne, il réalise le traitement concerné, puis passe en émission sur TX broche D3 et retourne un ACR du genre « OK » vers RXD de 5.
• L’unité 5 était en attente. Elle transmet à son tour l’ACR en aveugle sur son TX interne à 2,4GHz.
• Dans l’environnement immédiat, le Module HC-05 1 repéré 3 qui était en attente récupère par son RX l’ACR car l’adresse du « parleur » correspond et le mot de passe est valide. Il transmet alors ce message sur sa broche TXD.
• Le programme P04 qui était à l’écoute réceptionne l’ACR sur D2, éventuellement le traite et rend compte sur TX.
• Le Moniteur de l’IDE affiche le compte rendu dans sa fenêtre contextuelle.
• Toute la chaine à procédé à un « aller / retour » et se retrouve disponible pour un autre alternat.
L’opérateur peut alors envoyer une autre consigne par l’entremise du Moniteur.
Cet exposé assez long reste toutefois d’une logique assez élémentaire. Le concept de base en dialogue de type alternat réside dans la notion permanente de Maître et d’Esclave. L’Esclave doit être en permanence à l’écoute. Quand il reçoit une consigne il la traite et retourne une réponse. Dans la chaîne analysée ci-avant, la réponse consiste à envoyer la consigne reçue jusqu’au dernier maillon. C’est lui qui va retourner un ACR qui reviendra jusqu’au « Grand Maître ».
Relisez l’exposé qui précède jusqu’à avoir bien compris le mécanisme global, qui est Maître, qui est Esclave et quelles sont les contraintes à respecter sur chaque maillon de la « chaîne de commandement ». En particulier les contraintes de format des lignes de dialogue, les contraintes
d’adresse et de mot de passe. Il sera alors presque facile d’analyser les programmes d’application.
Conditionner deux modules en vue de les faire dialoguer.
Nous savons maintenant que dans une application incluant deux modules Bluetooth qui coopèrent, pour les échanges par radio il faudra bien que l’un des deux soit le Maître et l’autre l’Esclave, ce sera la première phase de préparation des modules. Ensuite il faudra impérativement que le Maître communique ses consignes à un interlocuteur particulier, car dans l’environnement peuvent se trouver une Kyrielle d’autres modules qui ne demandent « qu’à causer ». Le Maître devra donc connaitre l’ADRESSE de l’Esclave. Enfin, pour sécuriser la transmission, les deux unités devront avoir un mot de passe identique sans oublier le respect des formats série entre modules et Arduinos. Le but de ce chapitre est précisément de préparer nos deux unités pour qu’elles puissent dialoguer par radio sur la fréquence de 2,4 GHz. Dans le chapitre précédent nous avons « papillonné » avec un grand nombre de paramètres histoire d’appréhender la richesse de la combinatoire des paramètres AT possibles. Et encore, il en existe bien d’autres, mais mes modules ne les ont pas tous acceptés. Pour préparer deux unités, heureusement les consignes utiles restent peu nombreuses. On va donc les utiliser pour préparer nos « soldats » à leur prochaine mission : Dans les expériences précédentes, nous avons « trituré » notre module Bluetooth en lui imposant un peu n’importe quoi. Aussi, de loin le plus simple et le plus sécuritaire consiste à restituer en interne tous les paramètres par défaut ce sera donc la première action à effectuer dans le logiciel de configuration P02. La Fig.11 est une copie d’écran avec des zones repérées par des couleurs qui montre les manipulations réalisées avec le Moniteur de l’IDE :
C’est fait, on dispose de deux unités qui en principe sont conditionnées pour pouvoir communiquer sur 2,4 GHz. Il nous reste à le vérifier, puis on pourra enfin passer à des applications.
Vérifier que deux unités HC-05 communiquent correctement.
Heureusement qu’il n’y a pas besoin d’élaborer un programme Arduino pour pouvoir procéder à une telle vérification. Les concepteurs de ces circuits extrêmement complexes ont prévu pour les utilisateurs un moyen rudimentaire. Une broche du circuit intégré est disponible pour y brancher un témoin logique. Sur les modules HC-05 cette broche est disponible sur STATE. Il suffit d’adopter pour les deux unités le petit montage de la Fig.13, d’alimenter en +5Vcc et 
d’attendre. En quelques secondes si le Maître et l’Esclave sont correctement appairés, la LED verte sur chaque unité va s’illuminer traduisant la communication établie entre les deux modules. Penser à bien placer les deux circuits en mode exploitation en branchant EN sur GND. Au moment de la mise sous tension le témoin rouge de chaque module clignote rapidement. Dès que les modules communiquent, sur chacun sa LED se met à générer deux impulsions lumineuses proches toutes les quatre secondes. C’est fait, nos deux soldats « papotent » en tâche de fond et l’on peut sereinement envisager de créer des applications. Comme il n’y a intervention d’aucun acteur extérieur, si les deux modules « n’accrochent pas », c’est que forcément l’un au moins des paramètres interne n’est pas correct : Le rôle, le mot de passe ou l’adresse de l’Esclave sur le Maître. Comme les formats d’échange série ne sont pas utilisés à ce stade, ils sont forcément hors de cause. Par contre, si dans une application le système ne fonctionne pas c’est :
• Le programme du Maître qui n’est pas au point,
• Le format de dialogue série sur la ligne Série n°2 qui n’est pas égale à celle du Bluetooth Maître,
• Le programme de l’Esclave qui n’est pas au point,
• Le format de dialogue série sur la ligne Série n°2 qui n’est pas égale à celle du Bluetooth Esclave.
(Bien entendu, plusieurs de ses problèmes peuvent être présents simultanément.)
La suite est ICI.
