Ajout d’un support RS-485 au BeagleBone avec court délai de redressement

Au département des solutions industrielles de Savoir-faire Linux, nous avons récemment décidé d’investiguer la possibilité d’ajouter au BeagleBone un support RS-485. Il s’avère que certains de nos clients pourraient être très intéressés par ces cartes supportant le standard de communication RS-485, en autant qu’on puisse garantir un délai de redressement très court. Comme nous le verrons, c’est là une condition essentielle.

Qu’est ce qu’un BeagleBone?

Le BeagleBone, c’est une petite carte qui ne coûte presque rien et qui fournit un port Ethernet, un hôte USB, une interface MMC et deux ports d’extension de 46 broches chacun où sont disponibles des entrées/sorties libres : GPIO, I²C et UART, entre autres.

Au coeur de cette carte se trouve un système sur puce (SoC) AM3358 de Texas Instruments, système qui comprend un processeur ARM Cortex-A8. L’AM3358 exécute Linux sans effort à 720 MHz. Notons également l’existence du plus récent BeagleBone Black, ou BBB, qui ajoute une capacité HDMI, en plus de posséder un SoC un peu amélioré (AM3359) qui tourne maintenant à 1 GHz, d’avoir 2 GB de mémoire Flash intégrée et de consommer moins d’énergie électrique que son homologue blanc.

Le standard RS-485

RS-485 (ou, plus formellement, TIA-485-A) est un standard électrique qui définit un bus sériel multipoint semi-duplex sur une simple paire de fils torsadée. Puisqu’il est semi-duplex, un seul dispositif peut écrire sur le bus à tout moment. Au moins 32 différents dispositifs peuvent être connectés en parallèle sur la même paire torsadée à l’intérieur d’un réseau :

De plus, à 100 kb/s, la paire torsadée peut atteindre une longueur de 1200 mètres selon le standard, et ce sans répéteur. Comparons ces chiffres avec ceux du standard RS-232, plus connu. Celui-ci supporte seulement deux dispositifs, la longueur maximale du fil étant habituellement de 15 mètres; il est duplex intégral et, donc, au moins 3 fils sont requis (réception, transmission et masse). La paire torsadée de RS-485 utilise une signalisation différentielle (tout comme USB), ce qui signifie qu’elle est particulièrement immunisée contre les interférences électromagnétiques.

Toutes ces caractéristiques de RS-485 en font une solution peu coûteuse et donc idéale pour l’implémentation de systèmes d’automation industrielle, notamment dans des usines avec plusieurs capteurs, instruments de mesure, valves de contrôle, actuateurs, etc. RS-485 est aussi utilisé en tant que bus dans les cabines de plusieurs avions commerciaux et en tant que couche physique de DMX512, le protocole derrière le contrôle d’éclairage de virtuellement toutes les salles de concert.

Un peu de théorie

La nature semi-duplex de RS-485 signifie que chaque dispositif est soit en train de transmettre, soit en train de recevoir, mais jamais les deux en même temps. Elle signifie également qu’un seul dispositif à la fois peut transmettre sur le bus, sans quoi il y aurait des conflits électriques. C’est pourquoi les transcepteurs RS-485 (les puces qui écrivent/lisent les lignes Rx/Tx des UART pour écrire/lire la signalisation différentielle propre à RS-485) prennent en entrée un autre signal que le dispositif doit fournir : la direction des données. En utilisant cette entrée judicieusement, on peut activer/désactiver le transmetteur du transcepteur et c’est la seule façon d’arrêter d’écrire sur la paire torsadée.

Les protocoles implémentés au-dessus de RS-485 (puisque celui-ci n’est qu’un standard électrique) sont habituellement de type maître-esclave. Voici une séquence typique de communication entre un maître et un esclave avec RS-485 :

1. Le maître acquiert le bus et y écrit un message (par exemple, une lecture de pression), incluant un en-tête muni d’un identifiant de destinataire (une adresse); tous les esclaves reçoivent le message.
2. Lorsque le dernier bit du message est complètement écrit, le maître doit aussitôt relâcher le bus (arrêter d’écrire).
3. Le destinataire esclave reconnait son identifiant dans l’en-tête du message et acquiert le bus (tous les autres esclaves continuent à lire).
4. Le dispositif esclave écrit son message de réponse au maître (tous les autres esclaves lisent ce message, mais l’ignorent).
5. Lorsque le dernier bit du message est complètement écrit, le dispositif doit relâcher le bus aussitôt que possible.
6. Le maître reconnait que le message lui est destiné et le traite, selon l’application.

Les étapes critiques dans le temps sont les n° 2 et 5 : il est très important pour tout dispositif qui écrit sur le bus de le relâcher aussitôt que le message est complètement écrit. L’intervalle de temps entre le moment où le dernier bit de la communication sérielle est écrit et le moment où le bus est relâché est appelé délai de redressement. Un trop long délai de redressement peut être fatal : deux dispositifs écriront en même temps sur le bus, entraînant ainsi une corruption des données. D’un autre côté, il faut s’assurer que le dernier bit du message est complètement transmis avant de relâcher le bus.

Ce qu’on essaie d’accomplir ici, c’est d’avoir un UART disponible sur Linux dans l’espace utilisateur, qui activera automatiquement un signal de direction des données pour relâcher le bus à tout moment lorsqu’il n’est pas en train de transmettre. Il faut absolument garantir que rien ne pourrait arrêter l’activation en temps réel de ce signal lorsqu’il est nécessaire afin d’éviter toute corruption de données. Une fois que cette fonctionnalité sera assurée, les différents protocoles qui dépendent de RS-485 pourront être implémentés du côté utilisateur. On souhaite par le fait même éviter d’introduire au système des composantes externes inutiles puisque la nomenclature s’en verrait alourdie pour une carte sur mesure, en plus d’augmenter la probabilité de défaillance du circuit.

À la lumière des deux contraintes mentionnées ci-dessus, on peut d’ores et déjà éliminer :

• Les UART des puces AM335x. Ces dispositifs ne sont pas directement compatibles avec RS-485 et, sur Linux, un pilote n’a aucune façon d’assurer un changement de direction des données en temps réel. Bien que le pilote puisse gérer une interruption du UART qui indique qu’il n’y a plus transmission, rien ne garantit sa latence sur Linux. Ainsi, le délai de redressement pourrait, dans certaines conditions, être beaucoup trop élevé.
• Un UART externe. Plusieurs circuits intégrés externes implémentant un ou plusieurs UART permettent un redressement RS-485 en temps réel. Ceci dit, il s’agirait ici d’une pièce externe, ce qu’on cherche à éviter.

Nous aurons bien entendu toujours besoin d’un transcepteur RS-485 externe, peu importe l’UART utilisé, le BeagleBone n’ayant pas ce qu’il faut pour comprendre/produire la signalisation différentielle requise par RS-485.

À suivre…

Je vais maintenant explorer les solutions possibles en matière de support RS-485 en temps réel pour les SoC AM335x. Dans mon prochain billet, je publierai les résultats de cette investigation et je présenterai les améliorations possibles aux implémentations actuelles, si besoin est.