Explicação das taxas de transmissão do UART: de caracteres inúteis a links seriais confiáveis

O momento que todos tiveram

Você conecta duas placas. TX a RX, RX a TX, terra a terra. Você atualiza o firmware, abre o monitor serial e... lixo.ÿÿÿÿou⸮⸮⸮⸮ou talvez nada. Você verifica novamente a fiação. Você troca TX e RX (todo mundo faz isso pelo menos uma vez). Ainda é lixo.

Então, alguém pergunta: “qual taxa de transmissão você está configurada?”

E aí está. Um lado está falando no9600, o outro está ouvindo no115200. Os sinais elétricos são perfeitos — níveis de tensão, fiação, tudo está certo — mas os dois dispositivos estão falando em velocidades completamente diferentes. É como tentar ler um livro enquanto alguém vira as páginas em velocidade tripla. Os personagens estão todos lá; você simplesmente não consegue entendê-los.

Essa é a falha de comunicação serial mais comum em sistemas embarcados e é totalmente evitável quando você entende o que a taxa de transmissão realmente significa e por que ela é tão importante para o UART.

---

O que realmente é a taxa de transmissão

A taxa de transmissão é o número de transições de sinal — símbolos — por segundo no fio. Especificamente para UART, cada símbolo tem um bit, então a taxa de transmissão é igual à taxa de bits. Quando você define115200baud, você está dizendo ao transmissor que altere a tensão da linha a cada 1/115200 segundos, o que resulta em cerca de 8,68 microssegundos por bit.

Aqui está o ponto crítico: O UART não tem fio de clock. Ao contrário do SPI ou do I2C, não há sinal separado informando ao receptor quando fazer a amostragem. Ambos os lados geram de forma independente seu próprio tempo a partir de seus próprios relógios. Eles só precisam concordar com a velocidade de antemão.

Pense nisso como duas pessoas lendo uma fita adesiva compartilhada. Não há nenhum sino tocando para cada letra — ambos concordaram em olhar para o próximo caractere a cada 8,68 microssegundos. Se o relógio de uma pessoa funcionar 5% mais rápido, ela acabará por começar a ler os caracteres errados. Isso é exatamente o que acontece com o UART quando os relógios não coincidem.

O receptor detecta o início de um byte observando o bit inicial — uma transição de alto (inativo) para baixo. Depois de ver essa borda caindo, ele inicia seu cronômetro interno e coleta amostras dos bits de dados nos intervalos esperados. Se a taxa de transmissão estiver um pouco baixa, quando chegar ao bit 7 ou ao bit de parada, a amostragem está no momento errado.

---

As taxas de transmissão padrão (e por que esses números estranhos)

Se você já trabalhou com seriais, já viu os suspeitos de sempre:

Por que esses números específicos? São acidentes históricos que permaneceram. 75 baud vem da era do telégrafo — o código Baudot usava caracteres de 5 bits e 75 baud dava aos operadores tempo para ler a impressão. 110 baud era a velocidade do Teletype Model 33, definida pelas limitações mecânicas da cabeça de impressão. 300 baud foi a primeira velocidade de modem amplamente usada (os acopladores acústicos nos quais você encaixaria um telefone). A partir daí, cada geração praticamente dobrou: 1200, 2400, 4800, 9600. No entanto, essas não são potências de dois — são múltiplos de 300.

Então, por que57600está no conjunto padrão em vez de56400(o que seria um múltiplo mais limpo)? É115200 / 2, e o próprio115200vem do chip 8250 UART usado em PCs IBM. O 8250 tinha um oscilador de 1,8432 MHz e, com um divisor de 1, você tinha 115200 baud (1843200/16 = 115200). A sobreamostragem do divisor de 16 é incorporada ao hardware.

O resultado: todos nós ainda estamos usando taxas de transmissão ditadas por uma frequência cristalina escolhida em 1981.

Por que 9600 é o padrão universal

O9600baud é lento o suficiente para funcionar com praticamente qualquer fonte de relógio, qualquer comprimento de fio abaixo de alguns metros e qualquer periférico UART — mesmo os mais básicos. É a velocidade que “simplesmente funciona”. Os módulos GPS são padronizados. Os bootloaders o usam. Quando você não souber a que velocidade um dispositivo fala, tente primeiro o 9600.

Mas o9600também é dolorosamente lento para qualquer coisa além de mensagens de texto curtas. Com 10 bits por quadro (formato 8N1), você obtém 960 bytes por segundo. A impressão de um log de depuração de 1 KB leva mais de um segundo. É por isso que a maioria dos trabalhos de desenvolvimento usa o115200— é 12 vezes mais rápido e ainda é confiável com qualquer cristal MCU moderno.

---

Exemplo resolvido: incompatibilidade do módulo GPS

Digamos que você tenha um módulo GPS u-blox NEO-6M. Ele emite sentenças NMEA em9600baud por padrão. Seu firmware STM32 configura acidentalmente o USART2 em115200. O que acontece?

O GPS envia um caractere$(ASCII 0x24, binário00100100). No fio a9600baud, cada bit tem 104,17 µs de largura. O quadro completo de 10 bits (início + 8 dados + parada) leva 1,042 ms.

Mas seu STM32 está amostrando a115200— esperando bits com 8,68 µs de largura. Quando vê a borda descendente do bit inicial, ele inicia a amostragem a cada 8,68 µs. No tempo que o GPS leva para enviar UM bit (104,17 µs), o STM32 faz uma amostragem 12 vezes. Ele lê 12 “bits” do que na verdade é um único bit.

O resultado: você vê personagens de aparência aleatória em seu terminal. Não apenas caracteres errados — lixo completamente imprevisível, porque o receptor está cortando a forma de onda em 12 vezes mais partes do que o pretendido.

A correção: Combine a taxa de transmissão. Defina seu STM32 para9600ou reconfigure o GPS (via comandos do protocolo UBX) para115200. Não há negociação, nem detecção automática (na maioria dos casos) — os dois lados devem ser configurados explicitamente com a mesma velocidade.

---

Exemplo resolvido: registro de dados do sensor de alta velocidade

Você está construindo um registrador de dados que lê um acelerômetro a 1 kHz (1000 amostras por segundo). Cada amostra tem eixos X, Y, Z como números inteiros de 16 bits, além de um carimbo de data/hora. Você deseja transmitir isso via UART para um adaptador serial USB FTDI para captura no PC.

Vamos descobrir qual taxa de transmissão você precisa:

Etapa 1: Calcular a carga útil de dados.

• 3 eixos × 2 bytes cada = 6 bytes por amostra
• 4 bytes para carimbo de data/hora = 4 bytes
• 2 bytes de sobrecarga (cabeçalho + soma de verificação) = 2 bytes
• Total: 12 bytes por amostra

Etapa 2: Calcular bytes por segundo.

12 bytes × 1000 amostras/s = 12.000 bytes/segundo

Etapa 3: converter em bits por segundo (contabilizando a sobrecarga de UART) .

Com o enquadramento 8N1 padrão, cada byte custa 10 bits no fio (1 início + 8 dados + 1 parada):

12.000 bytes × 10 bits/byte = 120.000 bits/segundo

Etapa 4: Escolha uma taxa de transmissão com margem.

Você precisa de pelo menos 120.000 bps. O próximo aumento da taxa padrão é230400. Mas espere — você pode usar o115200? Isso fornece 115.200 bps no fio, o que é menos do que sua necessidade de 120.000. Você perderá dados.

Então é o 230400 — dando a você 230.400/120.000 = 92% de espaço livre. Essa é uma margem suficiente para latência de interrupção, gerenciamento de buffer e tráfego intermitente ocasional.

Como alternativa, você pode usar o115200se reduzir sua taxa de amostragem para 960 Hz (115.200/12/10 = 960). Na prática, eu recomendaria o230400com a taxa total de 1 kHz — o espaço livre permite que seu firmware respire.

Use a calculadora de taxa de transmissão UART para verificar a taxa e o erro reais alcançáveis para seu relógio MCU específico.

---

A regra dos 2% — Tolerância ao relógio

É aqui que o UART fica complicado. Como não há relógio compartilhado, tanto o transmissor quanto o receptor geram sua taxa de transmissão a partir de seus próprios osciladores. Se esses osciladores se separarem, os bits serão mal interpretados.

A tolerância padrão para comunicação UART confiável é de ± 2% de erro cumulativo entre as duas extremidades. Na prática, a maioria das referências recomenda manter cada lado abaixo de ± 1%, para que a pior incompatibilidade total permaneça abaixo de 2%.

Por que 2%?

Os receptores UART usam sobreamostragem de 16 × — eles amostram a linha 16 vezes por período de bits e usam as amostras intermediárias (normalmente amostras 7, 8, 9 de 16) para determinar o valor do bit. Isso dá alguma tolerância ao desvio de tempo.

Para um quadro 8N1 (total de 10 bits), o último bit amostrado é o bit #10 (o bit de parada). O erro acumulado nesse ponto é:

Se o erro de temporização total fizer com que o ponto de amostragem se desvie em mais de meio período de bits até o final do quadro, você coletará a amostra errada. Trabalhando de trás para frente:

Mas esse é o máximo teórico com uma detecção perfeita de bits iniciais. Na prática, a detecção do bit inicial em si tem ± 0,5 de incerteza amostral (de 16 amostras), afetando sua margem. O limite de segurança no mundo real é de cerca de 3,75% no total, e os engenheiros usam 2% como uma regra de projeto conservadora.

Qual é a aparência de 2% na prática

Em115200baud, um erro de 2% significa que a taxa de transmissão real está em algum lugar entre 112.896 e 117.504. O período de bits está errado em ±0,17 µs. Em um quadro de 10 bits, isso se acumula até ± 1,7 µs de desvio — cerca de 20% de um período de bits. Ainda é seguro, mas você está usando sua margem.

Em9600baud, 2% de erro é muito menos crítico em termos absolutos (± 2,08 µs por bit, ± 20,8 µs por quadro) porque os períodos de bits são muito amplos. Essa é outra razão pela qual o9600é o padrão “seguro” — até mesmo osciladores terríveis podem atingi-lo.

---

Fontes de relógio do MCU e erro de taxa de transmissão

Nem todos os relógios são criados da mesma forma para o UART:

Oscilador de cristal (HSE)

Precisão: normalmente ± 20 ppm (0,002%). Essencialmente perfeito para UART. Qualquer taxa de transmissão padrão funcionará com erros insignificantes. É isso que o ESP32, a maioria das placas de desenvolvimento STM32 e o Arduino Uno (cristal de 16 MHz) usam.

Oscilador RC interno (HSI)

Precisão: ± 1% a ± 5% dependendo da temperatura e da tensão. O HSI interno de 8 MHz do STM32 é ajustado de fábrica para ± 1% a 25° C, mas pode variar para ± 2% em toda a faixa de temperatura. O oscilador RC interno de 8 MHz do ATmega328P está ± 10% não calibrado (!) mas ± 2% após a calibração de fábrica.

É aqui que as coisas ficam perigosas. Se o transmissor e o receptor estiverem usando osciladores RC, você poderá ter uma incompatibilidade total de até 4%. O UART falhará de forma intermitente — funcionando bem na bancada em temperatura ambiente e, em seguida, eliminando caracteres no campo quando estiver quente ou frio.

Regra prática: Se você estiver executando o UART acima de9600baud sem um cristal, calcule seu pior erro de taxa de transmissão usando a calculadora UART e verifique se ele permanece abaixo de 2%.

O problema do divisor BRR

Mesmo com um cristal perfeito, você pode não obter uma taxa de transmissão exata. O periférico UART divide o relógio por um inteiro (o registro BRR) para gerar a taxa de transmissão:

Se a divisão não sair uniforme, você receberá um erro de quantização. Por exemplo, um relógio de 16 MHz tentando gerar o baud115200:

Você não pode carregar 8,68 em um registrador — ele arredonda para 9. A taxa de transmissão real se torna:

Erro:$(115200 - 111111) / 115200 = 3.55\%$. Isso excede 2% . Essa combinação específica de relógio e taxa de transmissão não funcionará de forma confiável sem o suporte de divisor fracionário.

Alguns MCUs (STM32, SAM, nRF) têm divisores BRR fracionários que resolvem isso. Outros (ATmega) não — você precisa escolher sua frequência de cristal com cuidado. Os cristais clássicos de 7,3728 MHz e 11,0592 MHz existem especificamente porque se dividem uniformemente em taxas de transmissão padrão.

Observe o padrão: 7,3728, 11,0592 e 18,432 MHz fornecem zero erro porque são múltiplos de 115200 × 16 × (algum número inteiro). As frequências “redondas”, como 8 e 16 MHz, são na verdade piores para o UART.

Os chips STM32 e ESP32 modernos usam divisores fracionários com 4 a 8 bits fracionários, eliminando efetivamente esse problema. Mas se você estiver trabalhando com um ATmega328P (Arduino Uno) a 16 MHz, esse erro de 3,55% no115200é real. O bootloader do Arduino, na verdade, usa o115200e se safa porque o chip FTDI na outra extremidade é cristalino e tolerante, mas está bem no limite.

---

Erros comuns

1. Taxa de transmissão errada no código

A causa número um do lixo em série. Verifique três vezes se os dois lados coincidem. Armadilhas comuns:

• O padrão dos módulos GPS é9600, não115200- Saídas de ROM de inicialização do ESP32 em74880baud (uma saída estranha)
• Alguns módulos Bluetooth (HC-05) usam o38400para comandos AT, mas o9600para o modo de dados
• Muitos sensores usam como padrão9600, independentemente do que o marketing diz sobre “alta velocidade”

2. Limitações do software UART (Bit-Banging)

O software UART (oSoftwareSerialdo Arduino, por exemplo) gera temporização no software usando loops de atraso. Isso significa:

• As interrupções podem aumentar o tempo de bits de forma imprevisível
• A velocidade máxima confiável é normalmente19200—38400baud
• A carga da CPU é dimensionada linearmente com a taxa de transmissão
• Receber durante a transmissão geralmente é impossível

Se você precisar de115200ou superior, use um periférico UART de hardware. Sempre.

3. Incompatibilidade de nível de tensão (parece um problema de taxa de transmissão)

Um UART de 3,3 V conversando com um UART de 5 V (ou vice-versa) pode produzir uma saída distorcida que se parece exatamente com uma incompatibilidade de taxa de transmissão. A tensão limite do receptor não está sendo ultrapassada de forma limpa, causando falsos bits de partida e dados corrompidos. Sempre verifique a compatibilidade de tensão antes de culpar a taxa de transmissão.

4. Esquecendo a sobrecarga do UART

Os novos engenheiros geralmente calculam a largura de banda necessária comodata_rate / 8e a definem como a taxa de transmissão. Mas cada byte custa 10 bits (8N1) ou 11 bits (8E1) no fio. A taxa de transferência útil real de115200baud com 8N1 é:

Não 14,4 KB/s (o que seria 115200/8). Essa sobrecarga de 20% dos bits de início/parada é importante.

5. Não contabilizando a variação de temperatura

Seu link UART funciona perfeitamente na bancada a 22°C. Em seguida, ele entra em um produto que opera de -20°C a +85°C. O oscilador RC interno oscila 3% e, de repente, você perde bytes nas manhãs frias. Sempre verifique as especificações do oscilador em toda a faixa de temperatura operacional.

---

Quando usar qual taxa de transmissão

Algumas diretrizes práticas:

• 9600 — Padrão para dispositivos desconhecidos, módulos GPS, módulos de sensores com dados pouco frequentes, fallback do bootloader. Funciona com qualquer fonte de relógio.
• 115200 — Padrão para desenvolvimento/depuração, fluxos de dados moderados, a maioria das comunicações entre MCU e PC. Requer cristal ou HSI calibrado.
• 230400—460800 — Registro de sensores de alto rendimento, atualização de firmware via UART, ferramentas baseadas em FTDI. Requer cristal e fios curtos (<30 cm).
• 921600—3000000 — Aplicações especializadas de alta velocidade (registro ESP32, FTDI na velocidade máxima). Requer cristais combinados, traços curtos e bom layout de PCB. A integridade do sinal começa a importar.

Acima de1 Mbaud, você está empurrando o UART além de onde é confortável. Nesse ponto, considere mudar para SPI (síncrono, muito mais rápido) ou USB (diferencial, imune a ruídos).

---

Usando a calculadora

A calculadora UART Baud Rate & Frame Timing em rftools.io calcula tudo o que discutimos:

1. Insira sua taxa de transmissão alvo —9600,115200ou qualquer que seja a necessidade de seu periférico.
2. Defina o formato do quadro — bits de dados (geralmente 8), bits de parada (geralmente 1), paridade (geralmente nenhuma).
3. Insira a frequência do relógio do MCU — o relógio APB/periférico, não necessariamente o relógio principal. Verifique sua ficha técnica.

A calculadora retorna:

• Período de bits — quanto tempo cada bit fica no fio (útil para medições de escopo)
• Período do quadro — tempo total para um personagem
• Taxa de transferência efetiva — taxa de dados real após subtrair a sobrecarga de UART
• Divisor BRR — o valor exato do registro que você precisa (para superamostragem de 16 ×)
• Taxa de transmissão real — o que você realmente obtém após o arredondamento de números inteiros

< 0.5%), yellow (0.5— 2%), red (>- Erro na taxa de transmissão — verde (2%)

O indicador de erro é a saída mais importante. Se estiver vermelho, seu link terá problemas. Altere a frequência do relógio, use um divisor fracionário (se o MCU suportar) ou escolha uma taxa de transmissão diferente.

---

Referência rápida: fórmulas de taxa de transmissão UART

Para quem quer a matemática em um só lugar:

Mantenha o erro abaixo de 2%. Use um cristal quando a velocidade importa. Combine suas taxas de transmissão. Seus links seriais agradecerão.