UART (Universal Asynchronous Receiver-Transmitter)
L’UART est un protocole matériel permettant la communication série entre deux appareils.
Baud Rate
UAL’UART échange des données de manière asynchrone, sans signal d’horloge. À la place, les deux appareils synchronisent leur timing en utilisant la même vitesse de transmission, appelée Baud Rate. Le Baud Rate désigne le nombre de symboles (bits) transmis par seconde.
Par exemple, avec un Baud Rate = 9600 :
- 9 600 bits transmis par seconde
- Durée d’un bit = 1 / 9 600 ≈ 104 microsecondes
Le récepteur lit l’état de la ligne toutes les 104 μs à partir de la détection du Start bit, pour déterminer si la valeur est 0 ou 1. Si les Baud Rates des deux côtés diffèrent, même légèrement, le timing se décale progressivement et les données sont corrompues.
Structure d’une trame
L’UART transmet les données trame par trame, selon l’ordre suivant :
① Start bit (1 bit) Signal indiquant le début de la transmission, toujours à 0 (LOW). Lorsque la ligne, normalement à l’état HIGH au repos, chute soudainement à LOW, le récepteur comprend : « Ah, des données arrivent ! » et commence à compter.
② Bits de données (généralement 8 bits) Les données réelles à transmettre. À noter : la transmission commence par le LSB (bit de poids faible).
Exemple :
'A'= 0b01000001 → transmission bit par bit depuis la droite :1, 0, 0, 0, 0, 0, 1, 0
Si l’on est amené à lire directement une forme d’onde, ne pas connaître cet ordre peut vite prêter à confusion — mieux vaut le garder en tête.
③ Bit de parité (optionnel, 0 ou 1 bit) Bit facultatif destiné à la détection d’erreurs. Il enregistre si le nombre de 1 dans les bits de données est pair ou impair, afin que le récepteur puisse le vérifier. Cependant, étant un mécanisme simple sur 1 bit, il est incapable de détecter les erreurs portant sur 2 bits ou plus.
④ Stop bit (1 à 2 bits) Signal indiquant la fin de la transmission, toujours à 1 (HIGH). La ligne est ramenée à HIGH, prêt à détecter le prochain Start bit..
Représentation par tension (HIGH / LOW)
L’UART représente les valeurs 0 et 1 par des niveaux de tension :
- État Idle (aucune transmission) : la ligne reste à HIGH (généralement 3,3 V ou 5 V)
- Start bit : la ligne chute brusquement à LOW (0 V)
- Bits de données : HIGH = 1, LOW = 0
- Stop bit : la ligne revient à HIGH, signalant la fin de la transmission
Le fait que le Start bit soit à 0 et le Stop bit à 1 découle directement de cette convention de tension. Puisque l’état Idle est HIGH, la chute soudaine à LOW constitue le signal de « début », et le retour à HIGH celui de « fin ».
Avantages et inconvénients
Si l’UART est encore largement utilisé aujourd’hui, c’est avant tout parce que sa configuration est extrêmement simple. Il suffit d’aligner les Baud Rates et de connecter trois fils (TX, RX, GND) pour établir une communication. Il est également très adapté au débogage — dans les environnements de développement embarqué, le débogage par printf passe presque toujours par l’UART.
Il présente cependant des inconvénients : une détection d’erreurs limitée, une vitesse plafonnée (quelques Mbps au maximum, inférieure à SPI ou USB) et une communication uniquement en point à point (1:1). Pour connecter plusieurs appareils sur un même bus, il faut se tourner vers I2C ou SPI.
Cas d’utilisation réels
Grâce à sa simplicité, l’UART est présent dans de nombreux domaines :
OBD-II automobile : la puce ELM327 interprète le protocole OBD, puis transmet les données via UART → Bluetooth vers le smartphone
Arduino / STM32 : Serial.print() transmet les données via UART vers le PC, et le moniteur série de l’IDE les affiche
Raspberry Pi : les broches TX/RX du GPIO permettent un accès headless sans moniteur ni clavier
Modules GPS (NEO-6M, etc.) : les données de position au format NMEA sont streamées via UART
Modules sans fil (ESP8266, HC-05, SIM800L) : connectés au MCU via UART et contrôlés par commandes AT
Équipements industriels : RS-232 et RS-485 sont tous deux des protocoles basés sur l’UART
Projet personnel en cours
Parmi ces cas d’utilisation, celui qui m’intéresse particulièrement est l’OBD-II, car je suis en train de concevoir un projet de sécurité dans ce domaine.
L’idée est de connecter un dongle Bluetooth au port OBD-II du véhicule, d’envoyer les données vers le cloud, puis d’utiliser un logiciel de sécurité intégré dans ce cloud pour analyser l’état du véhicule et détecter d’éventuelles anomalies. Des constructeurs automobiles mènent des projets similaires, mais ce que je recherche, c’est une méthode de détection plus intuitive pour l’utilisateur.
Bien sûr, les limites actuelles sont réelles : absence de chiffrement sur le CAN Bus, visibilité très partielle du trafic CAN via le port OBD-II, formats de messages différents selon les modèles de véhicules, entre autres. Mais en avançant pas à pas, d’autres idées et solutions pourraient bien émerger.
