Explicación de las velocidades en baudios UART: de caracteres basura a enlaces seriales confiables

El momento que todos han tenido

Conectas dos tablas. TX a RX, RX a TX, tierra a tierra. Actualizas el firmware, abres el monitor de serie y... basura.ÿÿÿÿo⸮⸮⸮⸮o tal vez nada en absoluto. Vuelves a comprobar el cableado. Cambias TX por RX (todo el mundo hace esto al menos una vez). Sigue siendo basura.

Entonces alguien pregunta: «¿qué velocidad en baudios está configurada?»

Y ahí está. Un lado habla en el § 14, el otro escucha en el § 15. Las señales eléctricas son perfectas (los niveles de tensión, el cableado, todo está en orden), pero los dos dispositivos hablan a velocidades completamente diferentes. Es como intentar leer un libro mientras alguien hojea las páginas a una velocidad triple. Todos los personajes están ahí; simplemente no puedes encontrarles sentido.

Esta es la falla de comunicación en serie más común en los sistemas integrados, y es totalmente evitable una vez que comprenda lo que realmente significa la velocidad en baudios y por qué es tan importante para UART.

---

Qué es realmente la velocidad en baudios

La velocidad en baudios es el número de transiciones de señal (símbolos) por segundo en el cable. En el caso específico del UART, cada símbolo es de un bit, por lo que la velocidad en baudios es igual a la velocidad de bits. Cuando configuras un baudio115200, le dices al transmisor que cambie la tensión de la línea cada 1/115200 segundos, lo que equivale a unos 8,68 microsegundos por bit.

Esto es lo más importante: El UART no tiene cable de reloj. A diferencia del SPI o el I2C, no hay una señal independiente que indique al receptor cuándo debe muestrear. Ambas partes generan de forma independiente su propia sincronización a partir de sus propios relojes. Solo tienen que acordar la velocidad de antemano.

Piense en ello como dos personas leyendo una cinta adhesiva compartida. No hay ninguna campana que suene para cada letra; ambas acordaron mirar al siguiente carácter cada 8,68 microsegundos. Si el reloj de una persona funciona un 5% más rápido, al final empezará a leer los caracteres equivocados. Eso es exactamente lo que ocurre con la UART cuando los relojes no coinciden.

El receptor detecta el inicio de un byte observando el bit de inicio, una transición de alto (inactivo) a bajo. Una vez que detecta ese límite descendente, pone en marcha su temporizador interno y toma muestras de los bits de datos en los intervalos esperados. Si la velocidad en baudios está aunque sea ligeramente inferior, cuando llegue al bit 7 o al bit de parada, estará muestreando en el momento equivocado.

---

Las velocidades de baudios estándar (y por qué esos números raros)

Si alguna vez has trabajado con series, has visto a los sospechosos habituales:

¿Por qué estos números específicos? Son accidentes históricos que perduraron. 75 baudios proviene de la era del telégrafo: el código Baudot utilizaba caracteres de 5 bits y 75 baudios daba tiempo a los operadores para leer la impresión. 110 baudios era la velocidad del Teletype Model 33, determinada por las limitaciones mecánicas del cabezal de impresión. 300 baudios fue la primera velocidad de módem ampliamente utilizada (los acopladores acústicos en los que se metía un microteléfono). A partir de ahí, cada generación prácticamente se duplicó: 1200, 2400, 4800, 9600. Sin embargo, no se trata de potencias de dos, sino de múltiplos de 300.

Entonces, ¿por qué está57600en el conjunto estándar en lugar de56400(lo que sería un múltiplo más limpio)? Es115200 / 2, y el propio115200proviene del chip UART 8250 utilizado en los PC de IBM. El 8250 tenía un oscilador de 1,8432 MHz, y con un divisor de 1, obtenía 115200 baudios (1843200/ 16 = 115200). El sobremuestreo con divisor de 16 está incorporado en el hardware.

El resultado: todos seguimos usando velocidades en baudios dictadas por una frecuencia cristalina elegida en 1981.

¿Por qué 9600 es el valor predeterminado universal

El baudio9600es lo suficientemente lento como para funcionar con casi cualquier fuente de reloj, cualquier longitud de cable de menos de unos pocos metros y cualquier periférico UART, incluso los más básicos. Es la velocidad la que «simplemente funciona». Los módulos GPS lo usan por defecto. Los gestores de arranque lo utilizan. Si no sabes a qué velocidad habla un dispositivo, prueba primero con el9600.

Pero el artículo 23§ también es tremendamente lento para cualquier cosa que no sean mensajes de texto cortos. Con 10 bits por cuadro (formato 8N1), se obtienen 960 bytes por segundo. La impresión de un registro de depuración de 1 KB lleva más de un segundo. Por eso, la mayoría de los trabajos de desarrollo utilizan la sección 24§: es 12 veces más rápida y fiable con cualquier cristal MCU moderno.

---

Ejemplo resuelto: el módulo GPS no coincide

Supongamos que tienes un módulo GPS u-blox NEO-6M. Genera sentencias NMEA en baudios9600por defecto. El firmware del STM32 configura accidentalmente el USART2 en la sección 26§. ¿Qué ocurre?

El GPS envía un carácter$(ASCII 0x24, binario00100100). En el cable en baudios9600, cada bit tiene 104,17 µs de ancho. El fotograma completo de 10 bits (inicio + 8 datos + parada) tarda 1,042 ms.

Sin embargo, el STM32 está muestreando a 30 grados, es decir, bits de 8,68 µs de ancho. Cuando ve el borde descendente del bit inicial, comienza a muestrear cada 8,68 µs. Durante el tiempo que tarda el GPS en enviar UN bit (104,17 µs), el STM32 toma muestras 12 veces. Lee 12 «bits» de lo que en realidad es un solo bit.

El resultado: verás caracteres de apariencia aleatoria en tu terminal. No solo caracteres incorrectos, sino basura completamente impredecible, porque el receptor está cortando la forma de onda en 12 veces más partes de lo previsto.

La solución: Iguala la velocidad en baudios. Configura tu STM32 en9600o reconfigura el GPS (mediante los comandos del protocolo UBX) en115200. No hay negociación ni detección automática (en la mayoría de los casos); ambas partes deben estar configuradas explícitamente a la misma velocidad.

---

Ejemplo resuelto: registro de datos de sensores de alta velocidad

Estás creando un registrador de datos que lee un acelerómetro a 1 kHz (1000 muestras por segundo). Cada muestra tiene los ejes X, Y y Z como números enteros de 16 bits, además de una marca de tiempo. Lo ideal es transmitirlo a través de UART a un adaptador serial USB FTDI para capturarlo en un PC.

Vamos a averiguar qué velocidad en baudios necesita:

Paso 1: Calcula la carga útil de datos.

• 3 ejes × 2 bytes cada uno = 6 bytes por muestra
• 4 bytes para la marca de tiempo = 4 bytes
• 2 bytes de sobrecarga (encabezado + suma de comprobación) = 2 bytes
• Total: 12 bytes por muestra

Paso 2: Calcula los bytes por segundo.

12 bytes × 1000 muestras/s = 12 000 bytes/segundo

Paso 3: Convierte a bits por segundo (teniendo en cuenta la sobrecarga de UART) .

Con el entramado 8N1 estándar, cada byte cuesta 10 bits por cable (1 inicio, 8 datos, 1 parada):

12 000 bytes × 10 bits/byte = 120 000 bits/segundo

Paso 4: Elige una velocidad en baudios con margen.

Necesitas al menos 120 000 bps. La próxima subida de la tarifa estándar es la230400. Pero espera, ¿puedes usar el115200? Eso le da 115 200 bps en la red, lo que es menos de lo que necesita 120 000. Perderás datos.

Así que es230400, lo que le da 230 400/120 000 = 92% de margen de ampliación. Es un margen suficiente para la latencia de las interrupciones, la administración del búfer y las ráfagas ocasionales de tráfico.

Como alternativa, puede utilizar la sección 36§ si reduce la frecuencia de muestreo a 960 Hz (115 200/12/10 = 960). En la práctica, yo recomendaría el modelo230400con la frecuencia máxima de 1 kHz: el margen de ampliación permite que el firmware respire.

Utilice la calculadora de velocidad en baudios UART para verificar la velocidad real alcanzable y el error para su reloj MCU específico.

---

La regla del 2%: tolerancia del reloj

Aquí es donde la UART se complica. Como no hay un reloj compartido, tanto el transmisor como el receptor generan su velocidad en baudios a partir de sus propios osciladores. Si esos osciladores se separan, los bits se malinterpretan.

La tolerancia estándar para una comunicación UART confiable es de ± 2% de error acumulativo entre ambos extremos. En la práctica, la mayoría de las referencias recomiendan mantener cada lado por debajo del ± 1%, de modo que el desajuste total en el peor de los casos se mantenga por debajo del 2%.

¿Por qué el 2%?

Los receptores UART utilizan un sobremuestreo de 16 veces: muestrean la línea 16 veces por período de bits y utilizan las muestras intermedias (normalmente muestras 7, 8 y 9 de un total de 16) para determinar el valor del bit. Esto permite una cierta tolerancia a la desviación temporal.

Para una trama 8N1 (10 bits en total), el último bit muestreado es el bit #10 (el bit de parada). El error acumulado en ese punto es:

Si el error de temporización total hace que el punto de muestreo se desvíe más de medio bit al final del fotograma, muestrearás el bit incorrecto. Trabajando al revés:Pero ese es el máximo teórico con una detección perfecta de los bits iniciales. En la práctica, la propia detección del bit inicial tiene una incertidumbre de ± 0,5 (de un total de 16 muestras), lo que reduce el margen. El límite de seguridad real es aproximadamente del 3,75% en total, y los ingenieros utilizan el 2% como regla de diseño conservadora.

Qué aspecto tiene el 2% en la práctica

En baudios115200, un error del 2% significa que la velocidad real en baudios está entre 112.896 y 117.504. El período de bits tiene una diferencia de ±0,17 µs. En un marco de 10 bits, se acumula una desviación de ±1,7 µs, aproximadamente el 20% de un período de bits. Sigue siendo seguro, pero estás consumiendo tu margen.

En baudios9600, el error del 2% es mucho menos crítico en términos absolutos (±2,08 µs por bit, ±20,8 µs por fotograma) porque los periodos de bits son muy amplios. Esta es otra razón por la que9600es la opción «segura» por defecto, ya que incluso los osciladores más terribles pueden alcanzarla.

---

Error en las fuentes de reloj de la MCU y en la velocidad de transmisión

No todos los relojes se crean de la misma manera para UART:

Oscilador de cristal (HSE)

Precisión: normalmente ± 20 ppm (0,002%). Esencialmente perfecto para UART. Cualquier velocidad en baudios estándar funcionará con un error insignificante. Esto es lo que utilizan la ESP32, la mayoría de las placas de desarrollo STM32 y Arduino Uno (cristal de 16 MHz).

Oscilador RC interno (HSI)

Precisión: de ± 1% a ± 5% según la temperatura y el voltaje. El HSI interno de 8 MHz del STM32 viene ajustado de fábrica a ± 1% a 25 °C, pero puede variar hasta ± 2% en todo el rango de temperatura. El oscilador RC interno de 8 MHz del ATmega328P no está calibrado en un ± 10% (!) pero un ± 2% después de la calibración de fábrica.

Aquí es donde las cosas se ponen peligrosas. Si tanto su transmisor como su receptor utilizan osciladores RC, podría tener un desajuste total de hasta un 4%. El UART fallará de forma intermitente: funciona bien en una mesa a temperatura ambiente y luego deja caer los caracteres en el campo cuando hace calor o frío.

Regla empírica: Si utilizas un UART por encima de9600baudios sin un cristal, calcula el error de velocidad en baudios en el peor de los casos con la calculadora de UART y comprueba que se mantiene por debajo del 2%.

El problema del divisor BRR

Incluso con un cristal perfecto, es posible que no consigas una velocidad exacta en baudios. El periférico UART divide el reloj entre un entero (el registro BRR) para generar la velocidad en baudios:

Si la división no es uniforme, se obtiene un error de cuantificación. Por ejemplo, un reloj de 16 MHz que intenta generar un baudio115200:No puedes cargar 8.68 en una caja registradora, se redondea a 9. La velocidad en baudios real pasa a ser:Error:$(115200 - 111111) / 115200 = 3.55\%$. Eso supera el 2% . Esta combinación específica de velocidad de reloj y velocidad en baudios no funcionará de forma fiable sin la compatibilidad con divisores fraccionarios.

Algunos MCU (STM32, SAM, nRF) tienen divisores BRR fraccionarios que resuelven este problema. Otros (ATmega) no lo tienen; debe elegir la frecuencia de sus cristales con cuidado. Los cristales clásicos de 7,3728 MHz y 11,0592 MHz existen específicamente porque se dividen uniformemente en velocidades de baudios estándar.

Observe el patrón: 7,3728, 11,0592 y 18,432 MHz dan cero error porque son múltiplos de 115200 × 16 × (algún número entero). Las frecuencias «redondas», como 8 y 16 MHz, son en realidad peores para la UART.

Los chips STM32 y ESP32 modernos utilizan divisores fraccionarios de 4 a 8 bits fraccionarios, lo que elimina este problema de manera efectiva. Pero si trabajas con un ATmega328P (Arduino Uno) a 16 MHz, ese error del 3,55% en el115200es real. De hecho, el gestor de arranque de Arduino usa el115200y se sale con la suya porque el chip FTDI del otro extremo es muy preciso y tolerante, pero está justo al límite.

---

Errores comunes

1. Velocidad de baudios incorrecta en el código

La causa número uno de la basura en serie. Compruebe tres veces que ambos lados coincidan. Trampas comunes:

• Los módulos GPS usan por defecto el artículo 45, no el 46
• La ROM de arranque del ESP32 emite en baudios74880(algo raro)
• Algunos módulos Bluetooth (HC-05) utilizan la sección 48 para los comandos AT y la sección 49 para el modo de datos
• Muchos sensores utilizan por defecto el comando9600, independientemente de lo que diga el marketing sobre la «alta velocidad»

2. Limitaciones del UART (Bit-Banging) del software

El UART del software (el artículo 51§ de Arduino, por ejemplo) genera tiempos en el software mediante bucles de retardo. Esto significa:

• Las interrupciones pueden alargar la temporización de los bits de forma impredecible
• La velocidad máxima fiable suele ser de entre 52 y 53 baudios
• La carga de la CPU se escala linealmente con la velocidad en baudios
• Recibir mientras se transmite es a menudo imposible

Si necesita el artículo 54 o superior, utilice un periférico UART de hardware. Siempre.

3. Discordancia en el nivel de voltaje (parece un problema de velocidad en baudios)

Un UART de 3,3 V que se comunica con un UART de 5 V (o viceversa) puede producir una salida confusa que se parece exactamente a una falta de coincidencia de velocidad en baudios. El umbral de voltaje del receptor no se cruza correctamente, lo que provoca bits de arranque falsos y datos corruptos. Compruebe siempre la compatibilidad del voltaje antes de culpar a la velocidad en baudios.

4. Olvidar la sobrecarga de UART

Los nuevos ingenieros suelen calcular el ancho de banda requerido comodata_rate / 8y lo establecen como la velocidad en baudios. Sin embargo, cada byte cuesta 10 bits (8N1) u 11 bits (8E1) en el cable. El rendimiento útil real de un baudio115200con 8N1 es:

No 14,4 Kb/s (lo que sería 115200/8). Esa sobrecarga del 20% que suponen los bits de inicio/parada es importante.

5. Sin tener en cuenta la deriva de temperatura

Tu enlace UART funciona perfectamente en una mesa a 22 °C. Luego pasa a un producto que funciona entre -20 °C y +85 °C. El oscilador RC interno oscila un 3% y, de repente, pierdes bytes en las mañanas frías. Compruebe siempre las especificaciones del oscilador en todo su rango de temperatura de funcionamiento.

---

Cuándo usar qué velocidad en baudios

Algunas pautas prácticas:

• 9600: predeterminado para dispositivos desconocidos, módulos de GPS, módulos de sensores con datos poco frecuentes y respaldo al gestor de arranque. Funciona con cualquier fuente de reloj.
• 115200: estándar para el desarrollo y la depuración, flujos de datos moderados y la mayoría de las comunicaciones entre la MCU y el PC. Requiere un HSI cristalino o calibrado.
• 230400—460800: registro de sensores de alto rendimiento, actualización del firmware mediante UART y herramientas basadas en FTDI. Requiere cables de cristal y cortos (<30 cm).
• 921600—3000000: aplicaciones especializadas de alta velocidad (registro ESP32, FTDI a máxima velocidad). Requiere cristales iguales, trazas cortas y un buen diseño de PCB. La integridad de la señal empieza a importar.

Por encima del artículo 63, estás llevando la UART más allá de lo que es cómodo. En ese momento, considera la posibilidad de cambiarte a SPI (sincrónico, mucho más rápido) o USB (diferencial, inmune al ruido).

---

Uso de la calculadora

La calculadora UART de velocidad en baudios y temporización de fotogramas de rftools.io calcula todo lo que hemos explicado:

1. Introduce tu velocidad en baudios objetivo:9600,115200o lo que necesite tu periférico.
2. Establece tu formato de fotograma: bits de datos (normalmente 8), bits de parada (normalmente 1), paridad (normalmente ninguno).
3. Introduzca la frecuencia de reloj de su MCU: el reloj APB/periférico, no necesariamente el reloj del núcleo. Consulta tu hoja de datos.

La calculadora devuelve:

• Período de bits: la longitud de cada bit en el cable (útil para las mediciones con osciloscopio)
• Período de fotograma: tiempo total para un carácter
• Rendimiento efectivo: velocidad de datos real después de restar la sobrecarga de UART
• Divisor BRR: el valor de registro exacto que necesitas (para un sobremuestreo de 16 veces)
• Velocidad en baudios real: lo que realmente se obtiene después del redondeo de números enteros

< 0.5%), yellow (0.5— 2%), red (>- Error de velocidad en baudios — verde (2%)

El indicador de error es el resultado más importante. Si está en rojo, tu enlace tendrá problemas. Cambia la frecuencia del reloj, usa un divisor fraccionario (si tu MCU lo admite) o elige una velocidad en baudios diferente.

---

Referencia rápida: fórmulas de velocidad en baudios UART

Para cualquiera que quiera tener los cálculos en un solo lugar:

Mantenga el error por debajo del 2%. Usa un cristal cuando la velocidad importa. Haga coincidir sus velocidades en baudios. Tus enlaces seriales te lo agradecerán.