Implémenter un réseau multi-points sur Atari ST

L'Atari ST est une machine assez riche en terme de connectique externe, il dispose notamment, en plus d'un port paralléle bi-directionnel, d'un port série RS232.

Ce port permet une connection de type "point à point", autrement dit avec une seule machine. Dans cette configuration il suffit de s'équiper d'un câble série croisé, dit "null-modem", pour échanger des données avec un autre ordinateur.

Au niveau logiciel il faut alors avoir recours à un logiciel de communication permettant d'échanger avec l'autre machine via un protocole de communication. (comme Kermit ou Xmodem par exemple).

Le protocole va dans ce cas établir de quelle façon seront structurés les messages afin qu'ils puissent être déchiffrés de façon appropriée de part et d'autre.

Le modèle OSI est modèle établissant les différentes couches d'un réseau, et l'on peut tout à fait replacer ce qui vient d'être dit dans ce contexte.

La norme électrique RS232, qui définit comment doivent être véhiculées les données physiquement (amplitude du signal, fréquence, type de câblage recommandé, distance maximum, etc ...), se situe au niveau le plus bas de l'architecture OSI, il s'agit de la couche physique.

Le protocole de communication, o˘ la façon d'encoder les messages de façon logique (dans quel ordre envoyer les octets de données, contrôle éventuel d'intégrité, ...) constitue le niveau le plus haut de cette même architecture, on parlera alors de la couche Application.

Mais comme évoqué succinctement, la norme RS232 ne répond pas du tout à la problématique de liaison multi-points, et de plus elle est limitée en terme de distance maximum de communication.

Heureusement cette norme a une descendance plus intéressante : les normes RS422 et RS485.

Pour faire simple, ces deux normes étendent la norme RS232 en proposant une liaison multi-points permettant une vrai topologie réseau, à des débits plus élevés, et sur des distances bien plus longues.

La norme RS422 se retrouve d'ailleurs sur les Mega ST, le port correspondant étant désigné sur la machine comme "port LAN".

Après quelques investigations, j'ai vu qu'il existait des adaptateurs RS232/RS485 en vente sur Internet. Ces convertisseurs m'ont paru très intéressants car auto-alimentés par le port série, et surtout ne nécessitant pas de driver logiciel pour la conversion entre les deux normes.

Une commande et quelques jours plus tard et je recevais mes convertisseurs LTC100 de Sena.

Le câblage est très simple, 3 fils à câbler dont un dédié à la masse.

Mes premiers tests ont été réalisés à partir d'une liaison entre mon Atari 1040STE et un PC portable, tous deux équipés d'un convertisseur LTC100 et d'un logiciel Kermit.

Le transfert des fichiers se passant à merveille, je pouvais alors valider que mes convertisseurs fonctionnaient (on ne sait jamais), que le port série du ST pouvait fournir suffisamment de courant pourra alimenter le convertisseur (dans le cas contraire un connecteur permet le branchement d'une alimentation externe), et que le tout se faisait de façon transparente sans adjonction de pilote logiciel.

Ceci fait, reste à maintenant à établir une connexion multi-points, pour laquelle j'ai heureusement un 3ème ordinateur à portée de main, disposant lui d'une interface USB/RS485.

Le problème posé est alors celui du protocole de communication, car Kermit et XModem ne sont dédiés qu'à une utilisation entre deux machines.

J'ai donc pris en charge la réalisation d'un protocole de communication en GFA Basic.

Après quelques recherches sur internet, il m'est apparu que le protocole Modbus était particulièrement simple à mettre en oeuvre, et qu'il était assez largement utilisé, notamment dans le monde de l'automatisme o˘ il existe bon nombre de capteurs directement contrôlables par RS485/Modbus.

Il existe également bon nombre de sites, souvent en anglais toutefois, expliquant Modbus dans ses moindres détails.

Ici je me suis intéressé à la variante Modbus ASCII, probablement la plus simple à mettre en oeuvre car proposant de coder systématiquement chaque quartet de donnée (4bits) sous forme d'un caractère ASCII (8 bits).

Vous l'aurez compris les données prennent donc de la place dans la trame envoyée, et l'on perd donc en vitesse de transmission, mais le protocole Modbus RTU, le plus efficace, demande un timing extrêmement précis puisque les début et fin de message doivent être matérialisés par un niveau logique bas sur la ligne pendant une durée précise.

A l'inverse Modbus ASCII propose un mode presque asynchrone, puisqu'il utilise simplement le caractère ":" pour désigner le début d'un message et la séquence "carriage return" "line feed" pour la fin du message.

En outre, et puisqu'il s'agit d'un protocole de communication "multi-points", la trame à envoyer prévoit deux octets pour signaler l'identifiant de la machine destinataire du message.

Ce qui fixe le nombre de machines maximum à 255 (car on commence à l'identifiant "01").

Les spécifications modbus prévoient un certains nombre de "commandes" (identifiant de la commande sur deux octets), avec dans chaque cas une structure de message standardisée.

Par exemple la commande 05, "Force Single Coil", permet l'activation/la désactivation d'un flag (écriture d'un bit), ce qui est intéressant par exemple dans le cas de la domotique pour commander un relais, une led,  ou autre ...

Il existe des commandes pour la lecture/l'écriture de données de type "flag" (1 bit) ou "mot" (16 bits), ce qui laisse tout un éventail d'applications possibles.

En fin de message se trouve enfin, avant les octets de fin de message, une valeur de contrôle d'intégrité du message. Ainsi cette valeur est calculée en début de message en fonction des données envoyées, et le destinataire la recalcule pour s'assurer qu'aucune donnée n'a été corrompue pendant la transmission.

Le programme GFA réalisé est plus une façon de défricher une piste qui me parait intéressante, et ne propose notamment pas de gérer la réception par interruption.

Parmi les évolutions possibles et/ou programmées, il y a l'implémentation de tous les types de message faisant partie des spécifications modbus, l'envoi de réponse de l'esclave au maître, et pourquoi pas le passage à la variante Modbus/BIN, qui propose d'envoyer les données sous forme binaire (donc gain en terme de longueur de message) tout en restant dans un mode asynchrone avec des caractères de début et fin de message.

En attendant, il m'a permis de piloter la lecture distante de chiptunes sur deux STs (l'un réel, l'autre émulé).