Liaisons séries

Règles de série

> Le protocole série asynchrone comporte un certain nombre de règles intégrées, des mécanismes permettant d’assurer des transferts de données robustes et sans erreur. Ces mécanismes, que nous obtenons pour éviter le signal d'horloge externe, sont les suivants:

Bits de données, Bits de synchronisation, Bits de parité, et taux de bauds.

Grâce à la variété de ces mécanismes de signalisation, vous constaterez qu’il n’existe pas un seul moyen d’envoyer des données en série. Le protocole est hautement configurable. La partie critique est de s'assurer que les deux périphériques sur un bus série sont configurés pour utiliser exactement les mêmes protocoles . Débit en bauds

Le débit en bauds spécifie la rapidité avec laquelle les données sont envoyées sur une ligne série. Il est généralement exprimé en unités de bits par seconde (bps). Si vous inversez le débit en bauds, vous pouvez savoir combien de temps il faut pour transmettre un seul bit. Cette valeur détermine la durée pendant laquelle l’émetteur maintient une ligne série haute / basse ou à quelle période l’appareil récepteur échantillonne sa ligne.

Les taux de bauds peuvent être n'importe quelle valeur raisonnable. La seule exigence est que les deux appareils fonctionnent au même taux. L'un des débits en bauds les plus courants, en particulier pour les choses simples où la vitesse n'est pas critique, est de 9600 bps . Les autres bauds «standard» sont 1200, 2400, 4800, 19200, 38400, 57600 et 115200.

Plus le débit en bauds est élevé, plus les données sont envoyées / reçues rapidement, mais la vitesse de transfert des données est limitée. Vous ne verrez généralement pas des vitesses supérieures à 115200, ce qui est rapide pour la plupart des microcontrôleurs. Si vous êtes trop élevé, vous verrez des erreurs du côté de la réception, car les horloges et les périodes d'échantillonnage ne peuvent tout simplement pas suivre. Encadrer les données

Chaque bloc (généralement un octet) de données transmises est en réalité envoyé dans un paquet ou une trame de bits. Les cadres sont créés en ajoutant des bits de synchronisation et de parité à nos données.

Paquet en série

Un cadre en série. Certains symboles dans le cadre ont des tailles de bits configurables.

Entrons dans les détails de chacune de ces pièces du cadre. Morceau de données

La vraie viande de chaque paquet en série sont les données qu'il transporte. Nous appelons de manière ambiguë ce bloc de données un bloc , car sa taille n'est pas spécifiquement indiquée. La quantité de données dans chaque paquet peut être définie entre 5 et 9 bits. Certes, la taille de données standard correspond à votre octet de base de 8 bits, mais d’autres tailles ont leur utilité. Un bloc de données 7 bits peut être plus efficace que 8, surtout si vous ne faites que transférer des caractères ASCII 7 bits.

Après s'être mis d'accord sur une longueur de caractères, les deux périphériques série doivent également s'accorder sur le caractère final de leurs données. Les données envoyées ont-elles le bit le plus significatif (msb) au moins, ou inversement? Si ce n’est pas dit autrement, vous pouvez généralement supposer que les données sont transférées en premier . Bits de synchronisation

Les bits de synchronisation sont deux ou trois bits spéciaux transférés avec chaque bloc de données. Ce sont le bit de départ et le (s) bit (s) d'arrêt . Fidèles à leur nom, ces bits marquent le début et la fin d'un paquet. Il y a toujours un seul bit de départ, mais le nombre de bits d'arrêt est configurable à un ou deux (bien qu'il soit généralement laissé à un).

Le bit de départ est toujours indiqué par une ligne de données inactive allant de 1 à 0, tandis que le ou les bits d’arrêt repassent à l’état inactif en maintenant la ligne à 1. Bits de parité

La parité est une forme de vérification d'erreur très simple et de bas niveau. Il vient en deux saveurs: impair ou pair. Pour produire le bit de parité, tous les 5 à 9 bits de l'octet de données sont additionnés et la régularité de la somme détermine si le bit est activé ou non. Par exemple, si la parité est définie sur pair et est ajoutée à un octet de données tel que 0b01011101 , qui a un nombre impair de 1 (5), le bit de parité serait défini sur 1 . Inversement, si le mode de parité était défini sur impair, le bit de parité serait 0 .

La parité est optionnelle et peu utilisée. Cela peut être utile pour la transmission sur des supports bruyants, mais cela ralentira également un peu le transfert de vos données et nécessitera que l'expéditeur et le destinataire implémentent le traitement des erreurs (généralement, les données reçues qui échouent doivent être renvoyées). 9600 8N1 (un exemple)

9600 8N1 - 9600 bauds, 8 bits de données, pas de parité et 1 bit d’arrêt - est l’un des protocoles série les plus couramment utilisés. Alors, à quoi ressemblerait un paquet ou deux de 9600 8N1? Ayons un exemple!

Un appareil transmettant les caractères ASCII «O» et «K» devrait créer deux paquets de données. La valeur ASCII de O (en majuscule) est 79, soit une valeur binaire à 8 bits de 01001111 , tandis que la valeur binaire de K est 01001011 . Il ne reste plus qu'à ajouter des bits de synchronisation.

Ce n'est pas spécifié, mais on suppose que les données sont transférées en premier. Notez comment chacun des deux octets est envoyé lorsqu’il lit de droite à gauche.

Paquet "OK"

Comme nous effectuons un transfert à 9 600 bits / s, le temps passé à maintenir chacun de ces bits haut ou bas est de 1 / (9 600 bits / s) ou de 104 µs par bit.

En fait, pour chaque octet de données transmis, 10 bits sont envoyés: un bit de début, 8 bits de données et un bit d'arrêt. Ainsi, à 9 600 bits / s, nous envoyons en réalité 9 600 bits par seconde ou 960 octets (9 600/10) par seconde.

Maintenant que vous savez comment construire des paquets série, nous pouvons passer à la section matériel. Nous verrons comment ces 1 et ces 0 et le débit en bauds sont appliqués au niveau du signal! Câblage et matériel

Un bus série ne comporte que deux fils: un pour l’envoi de données et un autre pour la réception. En tant que tels, les périphériques série doivent avoir deux broches série: le récepteur, RX , et le transmetteur, TX .

Câblage série

Il est important de noter que ces étiquettes RX et TX concernent l'appareil lui-même. Ainsi, le récepteur d'un périphérique doit aller au TX de l'autre, et inversement. C'est bizarre si vous avez l'habitude de brancher VCC à VCC, GND à GND, MOSI à MOSI, etc., mais c'est logique si vous y réfléchissez. L'émetteur devrait parler au récepteur et non à un autre émetteur.

Une interface série où les deux périphériques peuvent envoyer et recevoir des données est en duplex intégral ou en semi-duplex . Full-duplex signifie que les deux appareils peuvent envoyer et recevoir simultanément. La communication semi-duplex signifie que les périphériques série doivent envoyer et recevoir à tour de rôle.

Certains bus en série peuvent ne fonctionner qu'avec une seule connexion entre un périphérique d'envoi et de réception. Par exemple, nos écrans LCD compatibles série sont tous des oreilles et n’ont pas vraiment de données à relayer vers le dispositif de contrôle. C'est ce qu'on appelle la communication série simplex . Tout ce dont vous avez besoin est un seul fil allant du TX du périphérique maître à la ligne RX de l'auditeur. Implémentation matérielle

Nous avons couvert la série asynchrone du point de vue conceptuel. Nous savons de quels fils nous avons besoin. Mais comment la communication série est-elle réellement mise en œuvre au niveau du signal? En fait, de diverses manières. Il existe toutes sortes de normes pour la signalisation série. Examinons quelques-unes des implémentations matérielles les plus courantes de la série: niveau de logique (TTL) et RS-232.

Lorsque les microcontrôleurs et les autres circuits intégrés de bas niveau communiquent en série, ils le font généralement à un niveau TTL (logique transistor-transistor). Des signaux série TTL existent entre la plage d’alimentation en tension d’un microcontrôleur, généralement entre 0V et 3,3V ou 5V. Un signal au niveau VCC (3,3 V, 5 V, etc.) indique une ligne inactive, un bit de valeur 1 ou un bit d'arrêt. Un signal 0V (GND) représente un bit de début ou un bit de données de valeur 0.

Signal TTL

Le RS-232, que l’on retrouve sur certains des ordinateurs et périphériques les plus anciens, est comme un port série TTL renversé. Les signaux RS-232 varient généralement entre -13V et 13V, bien que la spécification permette de +/- 3V à +/- 25V. Sur ces signaux, une tension basse (-5 V, -13 V, etc.) indique la ligne inactive, un bit d'arrêt ou un bit de données de valeur 1. Un signal RS-232 haut signifie un bit de départ ou un bit 0- bit de données de valeur. C'est un peu l'opposé de la série TTL.

Signal RS-232

Entre les deux normes de signal série, TTL est beaucoup plus facile à implémenter dans des circuits intégrés. Cependant, les niveaux de basse tension sont plus susceptibles aux pertes sur les lignes de transmission longues. RS-232, ou des normes plus complexes telles que RS-485, conviennent mieux aux transmissions série à longue portée.

Lorsque vous connectez deux périphériques série ensemble, il est important de vous assurer que leurs tensions de signal correspondent. Vous ne pouvez pas directement interfacer un périphérique série TTL avec un bus RS-232. Vous devrez déplacer ces signaux !

Continuant, nous allons explorer l’outil utilisé par les microcontrôleurs pour convertir leurs données sur un bus parallèle vers et depuis une interface série. UARTs! UART

La dernière pièce de ce puzzle en série consiste à trouver un moyen de créer les paquets en série et de contrôler ces lignes matérielles physiques. Entrez le UART.

Un émetteur / récepteur asynchrone universel (UART) est un bloc de circuits chargé de la mise en oeuvre de la communication série. L’UART sert essentiellement d’intermédiaire entre les interfaces parallèle et série. À une extrémité de l'UART se trouve un bus de huit lignes de données environ (plus quelques broches de contrôle), à ​​l'autre extrémité, les deux câbles série - RX et TX.

UART simplifié

Interface UART super-simplifiée. Parallèle à une extrémité, série à l'autre.

Les UART existent en tant que CI autonomes, mais on les trouve plus souvent dans les microcontrôleurs. Vous devrez vérifier la fiche technique de votre microcontrôleur pour voir s'il contient des UART. Certains n'en ont pas, d'autres en ont un, d'autres en ont plusieurs. Par exemple, l'Arduino Uno - basé sur le «vieux fidèle» ATmega328 - n'a qu'un seul UART, tandis que l'Arduino Mega - construit sur un ATmega2560 - dispose de quatre UART énormes.

Comme le dictent R et T dans l'acronyme, les UART sont responsables de l'envoi et de la réception de données série. Du côté émission, un UART doit créer le paquet de données - en ajoutant des bits de synchronisation et de parité - et envoyer ce paquet par la ligne TX avec un minutage précis (en fonction du débit en bauds défini). Du côté réception, l’UART doit échantillonner la ligne RX à des débits correspondant au débit en bauds prévu, sélectionner les bits de synchronisation et cracher les données.

UART interne

Schéma UART interne (gracieuseté de la fiche technique Exar ST16C550)

Les UART plus avancés peuvent jeter leurs données reçues dans une mémoire tampon , où elles peuvent rester jusqu'à ce que le microcontrôleur vienne les obtenir. Les UART publient généralement leurs données mises en mémoire tampon selon le principe premier entré, premier sorti (FIFO). Les tampons peuvent être aussi petits que quelques bits, ou aussi grands que des milliers d'octets. UART logiciels

Si un microcontrôleur n’a pas d’UART (ou n’en a pas assez), l’interface série peut être bit-bangée - contrôlée directement par le processeur. C'est l'approche que prennent les bibliothèques Arduino, comme SoftwareSerial . Bit-banging est gourmand en ressources processeur et n'est généralement pas aussi précis qu'un UART, mais il fonctionne à la limite! Pièges courants

C'est à peu près tout ce qu'il y a à la communication série. J'aimerais vous laisser quelques erreurs communes faciles à commettre pour un ingénieur, quel que soit son niveau d'expérience: Réception-à-TX, TX-à-RX

Cela semble assez simple, mais c'est une erreur que je sais avoir commis plusieurs fois. Bien que vous souhaitiez que leurs étiquettes correspondent, veillez à toujours croiser les lignes RX et TX entre les périphériques série.

Implémentation en série réelle

Programmation FTDI Basic a Pro Mini . Notez que RX et TX sont croisés!

Contrairement à ce que l’estimé Dr. Egon Spengler aurait mis en garde , traversez les cours d’eau . Décalage du débit en bauds

Les débits en bauds ressemblent aux langues de la communication série. Si deux appareils ne parlent pas à la même vitesse, les données peuvent être mal interprétées ou complètement manquées. Si tout le périphérique de réception voit sur sa ligne de réception des déchets, vérifiez que les débits en bauds correspondent bien.

Baud Mismatch

Données transmises à 9600 bps, mais reçues à 19200 bps. Baud mismatch = garbage. Conflit de bus

La communication série est conçue pour permettre à seulement deux périphériques de communiquer sur un bus série. Si plusieurs périphériques tentent de transmettre sur la même ligne série, vous risquez d'être confronté à des conflits de bus. Dun dun dun….

Par exemple, si vous connectez un module GPS à votre Arduino, vous pouvez simplement câbler la ligne TX de ce module à la ligne RX de l'Arduino. Mais cette broche Arduino RX est déjà connectée à la broche TX du convertisseur USB-série, qui est utilisé chaque fois que vous programmez l'Arduino ou utilisez le moniteur série . Cela définit la situation potentielle dans laquelle le module GPS et la puce FTDI tentent de transmettre sur la même ligne au même moment.

Exemple de conflit de bus

Deux émetteurs qui envoient à un seul récepteur offrent la possibilité de conflits de bus.

Deux appareils essayant de transmettre des données en même temps, sur la même ligne, c'est mauvais! Au mieux, aucun des appareils ne pourra envoyer ses données. Dans le pire des cas, les lignes de transmission des deux périphériques sont perdues (bien que ce soit rare et habituellement protégé).

Il peut être sûr de connecter plusieurs périphériques récepteurs à un seul périphérique émetteur. Pas vraiment à la hauteur des spécifications et probablement mal vu par un ingénieur endurci, mais ça va marcher. Par exemple, si vous connectez un écran LCD série à un Arduino, la solution la plus simple consiste peut-être à connecter la ligne RX du module LCD à la ligne TX de l'Arduino. Le TX de l’Arduino est déjà connecté à la ligne RX du programmeur USB, mais cela ne laisse toujours qu’un seul périphérique en contrôle de la ligne de transmission.

Mise en œuvre sûre mais incertaine d'un émetteur / deux récepteurs

Distribuer une telle ligne d'émission peut toujours être dangereux du point de vue du micrologiciel, car vous ne pouvez pas choisir quel périphérique entend quelle transmission. L’écran LCD finira par recevoir des données qui ne lui sont pas destinées, ce qui pourrait lui ordonner de passer dans un état inconnu.

En général - un bus série, deux périphériques série!

Pour communiquer en liaison série, il faut un terminal type TTY. Sous Unix/MacOs, on peut utiliser la commande screen :
Exemple : screen /dev/cu.usbserial-000014FA 9600
où /dev/cu.usbserial-000014FA est le port de communication pour un Mac équipé d'un convertisseur USB<->Serial. 9600 est la vitesse de communication en bauds. elle peut prendre les valeurs :