UART. Le protocole qui n'a pas besoin de présentation (mais en a quand même une)

UART existe depuis les années 1960. Votre Arduino en a un. Votre ESP32 aussi. Le module GPS de votre drone l'utilise. Idem pour le module Bluetooth, le modem, le lecteur de code-barres et la console de débogage de pratiquement tout processeur embarqué jamais fabriqué. Ce n'est pas excitant. C'est juste partout.

La raison pour laquelle il a survécu si longtemps : il est presque impossible de se tromper une fois qu'on comprend son fonctionnement. Et quand quelque chose ne va pas. octets corrompus, données manquantes, caractères occasionnellement erronés. la cause est presque toujours l'une de ces trois choses.

La trame

Pas de fil d'horloge signifie que les deux extrémités doivent s'accorder sur une vitesse avant l'envoi. Cette vitesse, c'est le débit en bauds: bits par seconde. Les valeurs courantes sont 9600, 115200, 921600. L'émetteur envoie les bits exactement à ce rythme, et le récepteur échantillonne au même rythme.

Chaque octet est enveloppé dans une trame :

Repos  START  D0  D1  D2  D3  D4  D5  D6  D7  [parité]  STOP
  1    [ 0 ]   b   b   b   b   b   b   b   b    (opt)    [ 1 ]

Rendering diagram...

La ligne au repos est HIGH. Le bit de start est toujours LOW. ce front descendant indique au récepteur qu'un octet arrive. Puis 8 bits de données LSB en premier. Puis un ou deux bits de stop (HIGH) pour laisser le récepteur récupérer avant la prochaine trame.

Le récepteur n'échantillonne pas en continu. Il attend le front de start, puis la moitié d'une période de bit pour se centrer sur le bit 0, et échantillonne ensuite à intervalles d'un bit. C'est pourquoi la précision du débit en bauds compte : au bit 7, même une petite erreur s'est accumulée.

Désaccord de débit. la cause la plus fréquente de données corrompues

Un écart de 2% entre émetteur et récepteur est généralement acceptable. Le point d'échantillonnage dérive d'environ 16% sur 8 bits, ce qui reste dans la fenêtre de bit. Au-delà de 5% de désaccord, des erreurs de trame et des octets corrompus apparaissent. Au-delà de 10%, rien ne fonctionne du tout.

Quand un microcontrôleur dérive son débit depuis un oscillateur à quartz ou PLL qui n'est pas un multiple exact du débit cible, il y a toujours une erreur résiduelle. La plupart des fiches techniques indiquent l'erreur de débit résultante dans la section UART. vaut la peine de vérifier avant de supposer que deux appareils vont se parler de manière fiable.

TX se connecte à RX. toujours croiser les fils

Cela piège plus de personnes qu'il ne devrait.

Rendering diagram...

Connectez le GND. Toujours. Les niveaux logiques sont mesurés par rapport à la masse. sans référence commune, les tensions sur les lignes de données n'ont aucun sens pour le récepteur.

Quand RS-232 entre en jeu

Si l'autre appareil a un connecteur DB9 et a été fabriqué avant 2010, c'est probablement du RS-232. Les niveaux électriques sont inversés et amplifiés par rapport au TTL :

Un MAX232 ou MAX3232 gère la conversion. Ne connectez pas directement TTL UART à RS-232. les tensions négatives endommageront le microcontrôleur.

Quand l'utiliser et quand ne pas l'utiliser

UART est le bon choix pour : les consoles de débogage, les modules GPS, les modules Bluetooth et Wi-Fi avec commandes AT, les interfaces de chargeur de démarrage, tout lien point à point simple. Simple, support logiciel universel, connexion à un émulateur de terminal en 30 secondes.

Ce n'est pas le bon choix quand vous devez parler à plusieurs appareils sur un même bus (il n'y a pas d'adressage), ou quand vous avez besoin d'un débit élevé vers quelque chose sur le même PCB.

Les trois choses qui causent 90% des problèmes UART : mauvais débit en bauds, TX/RX non croisés, masse commune absente. Vérifiez d'abord ces points avant d'aller plus loin.