Explication des débits en bauds UART : des caractères inutiles aux liens série fiables

Le moment que tout le monde a vécu

Vous connectez deux cartes. TX à RX, RX à TX, sol à sol. Vous flashez votre firmware, vous ouvrez le moniteur série et... vous n'avez rien à voir.ÿÿÿÿou⸮⸮⸮⸮ou peut-être rien du tout. Tu vérifies le câblage. Vous échangez TX et RX (tout le monde le fait au moins une fois). C'est toujours des ordures.

Puis quelqu'un demande : « Quel débit en bauds êtes-vous réglé ? »

Et ça y est. Une partie parle au9600, l'autre écoute au115200. Les signaux électriques sont parfaits — niveaux de tension, câblage, tout fonctionne correctement — mais les deux appareils parlent à des vitesses complètement différentes. C'est comme essayer de lire un livre pendant que quelqu'un feuillette les pages à trois vitesses. Les personnages sont tous là ; on ne peut tout simplement pas les comprendre.

Il s'agit de la défaillance de communication série la plus courante dans les systèmes embarqués, et elle est totalement évitable une fois que vous comprenez ce que signifie réellement le débit en bauds et pourquoi il est si important pour UART.

---

Qu'est-ce que le débit en bauds

Le débit en bauds est le nombre de transitions de signal (symboles) par seconde sur le fil. Pour UART en particulier, chaque symbole est un bit, donc le débit en bauds est égal au débit binaire. Lorsque vous réglez115200bauds, vous demandez à l'émetteur de modifier la tension de ligne toutes les 1/115200 secondes, soit environ 8,68 microsecondes par bit.

Voici l'essentiel : L'UART n'a pas de fil d'horloge. Contrairement au SPI ou à l'I2C, aucun signal distinct n'indique au récepteur quand il doit échantillonner. Les deux équipes génèrent indépendamment leur propre chronométrage à partir de leurs propres horloges. Ils doivent juste se mettre d'accord sur la vitesse au préalable.

Imaginez que deux personnes lisent un ticker tape partagé. Aucune cloche ne sonne pour chaque lettre. Ils ont tous deux accepté de regarder le caractère suivant toutes les 8,68 microsecondes. Si la montre d'une personne tourne 5 % plus vite, elle finira par commencer à lire les mauvais caractères. C'est exactement ce qui se passe avec l'UART lorsque les horloges ne correspondent pas.

Le récepteur détecte le début d'un octet en surveillant le bit de démarrage, une transition de haut (inactif) à faible. Une fois qu'il voit ce front descendant, il lance son minuteur interne et échantillonne les bits de données aux intervalles attendus. Si le débit en bauds est légèrement différent, au moment où il atteint le bit 7 ou le bit d'arrêt, l'échantillonnage est effectué au mauvais moment.

---

Les débits en bauds standard (et pourquoi ces chiffres étranges)

Si vous avez déjà travaillé avec des séries, vous avez vu les suspects habituels :

Pourquoi ces chiffres précis ? Ce sont des accidents historiques qui ont perduré. 75 bauds date de l'ère du télégraphe : le code Baudot utilisait des caractères à 5 bits, et 75 bauds donnaient aux opérateurs le temps de lire l'impression. 110 bauds était la vitesse du télétype modèle 33, définie par les limites mécaniques de la tête d'impression. 300 bauds a été la première vitesse de modem largement utilisée (les coupleurs acoustiques dans lesquels vous coinceriez un combiné téléphonique). À partir de là, chaque génération a quasiment doublé : 1200, 2400, 4800, 9600. Ce ne sont pas des puissances de deux, mais des multiples de 300.

Alors pourquoi le57600est-il dans l'ensemble standard au lieu du56400(qui serait un multiple plus propre) ? Il s'agit du115200 / 2, et le115200lui-même provient de la puce UART 8250 utilisée dans les PC IBM. Le 8250 avait un oscillateur de 1,8432 MHz, et avec un diviseur de 1, vous obteniez 115200 bauds (1843200/16 = 115200). Le suréchantillonnage par diviseur de 16 est intégré au matériel.

Résultat : nous utilisons toujours des débits en bauds dictés par une fréquence cristalline choisie en 1981.

Pourquoi 9600 est la valeur par défaut universelle

Le9600bauds est suffisamment lent pour fonctionner avec presque toutes les sources d'horloge, toutes les longueurs de fil inférieures à quelques mètres et tous les périphériques UART, même les plus basiques. C'est la vitesse qui « fonctionne tout simplement ». Les modules GPS l'utilisent par défaut. Les bootloaders l'utilisent. Si vous ne savez pas à quelle vitesse parle un appareil, essayez d'abord le9600.

Mais le9600est également terriblement lentement pour tout ce qui va au-delà des courts SMS. À 10 bits par trame (format 8N1), vous obtenez 960 octets par seconde. L'impression d'un journal de débogage de 1 Ko prend plus d'une seconde. C'est pourquoi la plupart des travaux de développement utilisent le115200: il est 12 fois plus rapide et toujours fiable avec n'importe quel microcontrôleur en cristal moderne.

---

Exemple fonctionnel : incompatibilité du module GPS

Supposons que vous ayez un module GPS U-blox NEO-6M. Il génère des phrases NMEA à9600bauds par défaut. Votre microprogramme STM32 configure accidentellement USART2 au115200. Qu'est-ce qui se passe ?

Le GPS envoie un caractère$(ASCII 0x24, binaire00100100). Sur le fil à9600bauds, chaque bit a une largeur de 104,17 µs. La trame complète de 10 bits (démarrage + 8 données + arrêt) prend 1,042 ms.

Mais votre STM32 échantillonne à115200et s'attend à des bits d'une largeur de 8,68 µs. Lorsqu'il voit le front descendant du bit de départ, il commence à échantillonner toutes les 8,68 µs. Pendant le temps nécessaire au GPS pour envoyer UN bit (104,17 µs), le STM32 échantillonne 12 fois. Il lit 12 « bits » à partir de ce qui n'est en fait qu'un seul bit.

Résultat : vous voyez apparaître des caractères d'apparence aléatoire dans votre terminal. Pas seulement de mauvais caractères, mais des déchets totalement imprévisibles, car le récepteur découpe la forme d'onde en 12 fois plus de morceaux que prévu.

Le correctif : Faites correspondre le débit en bauds. Réglez votre STM32 sur9600ou reconfigurez le GPS (via les commandes du protocole UBX) sur115200. Il n'y a pas de négociation, pas de détection automatique (dans la plupart des cas) : les deux côtés doivent être explicitement configurés à la même vitesse.

---

Exemple concret : enregistrement des données des capteurs à haute vitesse

Vous construisez un enregistreur de données qui lit un accéléromètre à 1 kHz (1 000 échantillons par seconde). Chaque échantillon possède des axes X, Y et Z sous forme d'entiers de 16 bits, plus un horodatage. Vous souhaitez le diffuser via UART vers un adaptateur série USB FTDI pour la capture sur PC.

Déterminons le débit en bauds dont vous avez besoin :

Étape 1 : Calculez la charge utile des données.

• 3 axes × 2 octets chacun = 6 octets par échantillon
• 4 octets pour l'horodatage = 4 octets
• 2 octets de surcharge (en-tête + somme de contrôle) = 2 octets
• Total : 12 octets par échantillon

Étape 2 : Calculez le nombre d'octets par seconde.

12 octets × 1 000 échantillons/s = 12 000 octets/seconde

Étape 3 : Convertir en bits par seconde (en tenant compte de la surcharge UART) .

Avec le tramage 8N1 standard, chaque octet coûte 10 bits sur le fil (1 démarrage + 8 données + 1 arrêt) :

12 000 octets × 10 bits/octet = 120 000 bits/seconde

Étape 4 : Choisissez un débit en bauds avec marge.

Vous avez besoin d'au moins 120 000 bits/s. La prochaine hausse du taux standard est le230400. Mais attendez, pouvez-vous utiliser le115200? Cela vous donne 115 200 bits/s sur le fil, ce qui est inférieur à vos besoins de 120 000. Vous allez perdre des données.

Donc, c'est le230400, ce qui vous donne 230 400/120 000 = 92 % de marge capitale. C'est une marge suffisante pour la latence des interruptions, la gestion de la mémoire tampon et les pics de trafic occasionnels.

Vous pouvez également utiliser115200si vous réduisez votre fréquence d'échantillonnage à 960 Hz (115 200/12/10 = 960). En pratique, je recommanderais le230400avec une fréquence maximale de 1 kHz. La marge de manœuvre permet à votre firmware de respirer.

Utilisez le Calculateur de débit UART pour vérifier le débit et l'erreur réellement réalisables pour l'horloge de votre microcontrôleur spécifique.

---

La règle des 2 % : tolérance à l'horloge

C'est là que l'UART se complique. Comme il n'y a pas d'horloge partagée, l'émetteur et le récepteur génèrent leur débit en bauds à partir de leurs propres oscillateurs. Si ces oscillateurs s'éloignent, les bits sont mal interprétés.

La tolérance standard pour une communication UART fiable est de ± 2 % d'erreur cumulée entre les deux extrémités. En pratique, la plupart des références recommandent de maintenir chaque côté en dessous de ± 1 %, de sorte que l'écart total dans le pire des cas reste inférieur à 2 %.

Pourquoi 2 % ?

Les récepteurs UART utilisent un suréchantillonnage 16 fois : ils échantillonnent la ligne 16 fois par période de bits et utilisent les échantillons du milieu (généralement les échantillons 7, 8, 9 sur 16) pour déterminer la valeur du bit. Cela donne une certaine tolérance à la dérive temporelle.

Pour une trame 8N1 (10 bits au total), le dernier bit échantillonné est le bit #10 (le bit d'arrêt). L'erreur cumulée à ce stade est la suivante :

§ 0§

Si l'erreur de synchronisation totale entraîne une dérive du point d'échantillonnage de plus d'un demi-bit à la fin de la trame, vous échantillonnerez le mauvais bit. Travailler à reculons :

§ 1§

Mais c'est le maximum théorique avec une détection parfaite des bits de départ. En pratique, la détection du bit de départ elle-même présente une incertitude d'échantillon de ±0,5 (sur 16 échantillons), ce qui réduit votre marge. La limite de sécurité dans le monde réel est d'environ 3,75 % au total, et les ingénieurs utilisent 2 % comme règle de conception prudente.

À quoi ressemblent 2 % en pratique

À115200bauds, une erreur de 2 % signifie que le débit en bauds réel se situe entre 112 896 et 117 504. La période binaire est décalée de ±0,17 µs. Sur une trame de 10 bits, cela s'accumule jusqu'à ±1,7 µs de dérive, soit environ 20 % d'une période de bits. C'est toujours en sécurité, mais tu es en train d'épuiser ta marge.

À §39 bauds, une erreur de 2 % est beaucoup moins critique en termes absolus (±2,08 µs par bit, ±20,8 µs par trame) car les périodes de bits sont très étendues. C'est une autre raison pour laquelle le9600est la valeur par défaut « sûre » : même de terribles oscillateurs peuvent l'atteindre.

---

Sources d'horloge du microcontrôleur et erreur de débit en bauds

Toutes les horloges ne sont pas créées de la même manière pour UART :

Oscillateur à cristal (HSE)

Précision : généralement ± 20 ppm (0,002 %). Essentiellement parfait pour UART. N'importe quel débit en bauds standard fonctionnera avec une erreur négligeable. C'est ce qu'utilisent l'ESP32, la plupart des cartes de développement STM32 et l'Arduino Uno (cristal 16 MHz).

Oscillateur RC interne (HSI)

Précision : ± 1 % à ± 5 % en fonction de la température et de la tension. Le HSI 8 MHz interne du STM32 est réglé en usine à ± 1 % à 25 °C, mais peut dériver jusqu'à ± 2 % sur toute la plage de température. L'oscillateur RC 8 MHz interne de l'ATmega328P est non calibré à ± 10 % (!) mais ± 2 % après étalonnage en usine.

C'est là que les choses deviennent dangereuses. Si votre émetteur ET votre récepteur utilisent à la fois des oscillateurs RC, vous pourriez avoir un décalage total allant jusqu'à 4 %. L'UART échouera par intermittence : il fonctionne correctement sur le banc à température ambiante, puis laisse tomber des caractères sur le terrain lorsqu'il fait chaud ou froid.

Règle générale : Si vous utilisez un UART au-dessus de9600bauds sans cristal, calculez votre erreur de débit en bauds dans le pire des cas à l'aide du calculateur UART et vérifiez qu'elle reste inférieure à 2 %.

Le problème du diviseur BRR

Même avec un cristal parfait, il se peut que vous n'obteniez pas un débit en bauds exact. Le périphérique UART divise l'horloge par un entier (le registre BRR) pour générer le débit en bauds :

Si la division n'est pas égale, vous obtenez une erreur de quantification. Par exemple, une horloge de 16 MHz essayant de générer115200bauds :Vous ne pouvez pas charger 8,68 dans un registre, il est arrondi à 9. Le débit en bauds réel devient :Erreur :$(115200 - 111111) / 115200 = 3.55\%$. Cela dépasse 2 %. Cette combinaison spécifique d'horloge et de débit en bauds ne fonctionnera pas de manière fiable sans la prise en charge d'un diviseur fractionnaire.

Certains microcontrôleurs (STM32, SAM, nRF) ont des diviseurs BRR fractionnaires qui résolvent ce problème. D'autres (ATmega) ne le font pas. Vous devez choisir la fréquence de votre cristal avec soin. Les cristaux classiques de 7,3728 MHz et 11,0592 MHz existent spécifiquement parce qu'ils se divisent uniformément en débits en bauds standard.

Notez le schéma : 7,3728, 11,0592 et 18,432 MHz donnent tous zéro erreur car ce sont des multiples de 115200 × 16 × (un entier). Les fréquences « rondes » comme 8 et 16 MHz sont en fait pires pour l'UART.

Les puces STM32 et ESP32 modernes utilisent des diviseurs fractionnaires avec 4 à 8 bits fractionnaires, ce qui élimine efficacement ce problème. Mais si vous travaillez avec un ATmega328P (Arduino Uno) à 16 MHz, cette erreur de 3,55 % sur le115200est réelle. Le chargeur de démarrage Arduino utilise en fait le115200et s'en sort car la puce FTDI située à l'autre extrémité est précise et tolérante, mais elle est juste à la limite.

---

Erreurs courantes

1. Débit en bauds incorrect dans le code

La principale cause de déchets en série. Vérifiez trois fois que les deux côtés correspondent. Pièges courants :

• Les modules GPS sont définis par défaut sur9600, et non sur115200- Sorties de la ROM de démarrage de l'ESP32 à74880bauds (étrange)
• Certains modules Bluetooth (HC-05) utilisent le38400pour les commandes AT mais le9600pour le mode données
• De nombreux capteurs sont réglés par défaut sur9600, indépendamment de ce que dit le marketing à propos du « haut débit »

###2. Limitations du logiciel UART (Bit-Banging)

Le logiciel UART (ArduinoSoftwareSerial, par exemple) génère une synchronisation dans le logiciel à l'aide de boucles de retard. Cela signifie que :

• Les interruptions peuvent allonger la synchronisation des bits de manière imprévisible
• La vitesse fiable maximale est généralement de19200—38400bauds
• La charge du processeur évolue de manière linéaire en fonction du débit en bauds
• Il est souvent impossible de recevoir pendant la transmission

Si vous avez besoin du115200ou d'une version ultérieure, utilisez un périphérique matériel UART. Toujours.

3. Inadéquation du niveau de tension (cela ressemble à un problème de débit en bauds)

Un UART 3,3 V communiquant avec un UART 5 V (ou vice versa) peut produire une sortie confuse qui ressemble exactement à une inadéquation du débit en bauds. La tension de seuil du récepteur n'est pas franchie proprement, ce qui provoque de faux bits de démarrage et des données corrompues. Vérifiez toujours la compatibilité de la tension avant de mettre en cause le débit en bauds.

##4. Oublier les frais généraux UART

Les nouveaux ingénieurs calculent souvent la bande passante requise commedata_rate / 8et la définissent comme le débit en bauds. Mais chaque octet coûte 10 bits (8N1) ou 11 bits (8E1) sur le fil. Le débit utile réel de115200bauds avec 8N1 est le suivant :

§ 5

Pas 14,4 Kb/s (ce qui serait 115200/8). Cette surcharge de 20 % due aux bits de démarrage et d'arrêt est importante.

##5. Ne pas tenir compte de la dérive de température

Votre liaison UART fonctionne parfaitement sur le banc à 22 °C. Elle entre ensuite dans un produit qui fonctionne entre -20 °C et +85 °C. L'oscillateur RC interne dérive de 3 %, et tout à coup, vous perdez des octets les matins froids. Vérifiez toujours les spécifications de l'oscillateur sur l'ensemble de votre plage de températures de fonctionnement.

---

Quand utiliser quel débit en bauds

Quelques conseils pratiques :

• 9600 — Par défaut pour les appareils inconnus, les modules GPS, les modules de capteurs contenant des données peu fréquentes, la solution de secours du bootloader. Fonctionne avec n'importe quelle source d'horloge.
• 115200 — Norme pour le développement/le débogage, flux de données modérés, plupart des communications entre microcontrôleurs et PC. Nécessite un cristal ou un HSI calibré.
• 230400—460800 — Enregistrement des capteurs à haut débit, mise à jour du firmware via UART, outils basés sur FTDI. Nécessite du cristal et des fils courts (<30 cm).
• 921600—3000000 — Applications spécialisées à haut débit (journalisation ESP32, FTDI à vitesse maximale). Nécessite des cristaux assortis, de courtes traces et une bonne disposition des circuits imprimés. L'intégrité du signal commence à prendre de l'importance.

Au-delà du1 Mbaud, vous poussez l'UART au-delà de ce qui est confortable. À ce stade, envisagez de passer au SPI (synchrone, beaucoup plus rapide) ou à l'USB (différentiel, insensible au bruit).

---

Utilisation de la calculatrice

Le calculateur de débit en bauds et de synchronisation des images UART sur rftools.io calcule tout ce dont nous avons discuté :

1. Entrez votre débit en bauds cible —9600,115200, ou selon vos besoins en matière de périphériques.
2. Définissez le format de votre trame : bits de données (généralement 8), bits d'arrêt (généralement 1), parité (généralement aucun).
3. Entrez la fréquence d'horloge de votre micro : l'horloge APB/périphérique, pas nécessairement l'horloge centrale. Consultez votre fiche technique.

Le calculateur renvoie :

• Période de bits : durée pendant laquelle chaque bit reste sur le fil (utile pour les mesures de l'oscilloscope)
• Période d'image — durée totale pour un personnage
• Débit efficace : débit de données réel après soustraction de la surcharge UART
• Diviseur BRR : la valeur de registre exacte dont vous avez besoin (pour un suréchantillonnage de 16 fois)
• Débit en bauds réel — ce que vous obtenez réellement après avoir arrondi un entier

< 0.5%), yellow (0.5— 2%), red (>- Erreur de débit en bauds — vert (2 %)

L'indicateur d'erreur est le résultat le plus important. S'il est rouge, votre lien risque de rencontrer des problèmes. Modifiez votre fréquence d'horloge, utilisez un diviseur fractionnaire (si votre microcontrôleur le prend en charge) ou choisissez un débit en bauds différent.

---

Référence rapide : Formules de débit en bauds UART

Pour tous ceux qui veulent faire les calculs en un seul endroit :

§ 6

§ 7§

§ 8§

§ 9

§ 10§

Maintenez l'erreur en dessous de 2 %. Utilisez un cristal lorsque la vitesse est importante. Faites correspondre vos débits en bauds. Vos liens de série vous en seront reconnaissants.