O que é Baud Rate

O termo baud representa a quantidade de símbolos transmitidos por segundo em um canal de comunicação. Em sistemas simples, como UART (Universal Asynchronous Receiver/Transmitter), cada símbolo geralmente corresponde a um bit, e por isso, na prática, baud rate costuma ser tratado como equivalente a bits por segundo (bps).

No entanto, tecnicamente, eles não são sempre iguais. Em sistemas mais complexos (como modulações QAM), um único símbolo pode carregar múltiplos bits. Mas no contexto mais comum em microcontroladores — como STM32, ESP32 ou RP2040 — temos:

1 baud ≈ 1 bit por segundo

Origem do termo

O nome baud vem de Émile Baudot, engenheiro francês que desenvolveu um dos primeiros sistemas de telegrafia digital no século XIX. Seu sistema utilizava códigos binários para transmitir caracteres, sendo um dos precursores diretos da comunicação digital moderna.

Na época, a preocupação principal era sincronizar transmissor e receptor em meios físicos limitados, como linhas telegráficas. Essa limitação influenciou diretamente as primeiras taxas padronizadas que ainda vemos hoje.

Como o Baud Rate é utilizado na prática

Em sistemas modernos, especialmente embarcados, o baud rate é fundamental em protocolos como:

• UART (comunicação serial clássica)
• RS-232, RS-485 (ambientes industriais)
• Comunicação com módulos (GPS, GSM, Bluetooth)
• Bootloaders e debug via terminal serial

Cada taxa define quanto tempo dura cada bit, o que impacta diretamente:

• sincronização entre dispositivos
• tolerância a ruído
• distância da comunicação
• consumo de energia

Por exemplo, em 9600 baud, cada bit dura aproximadamente 104 µs, enquanto em 115200 baud, dura apenas 8.68 µs, exigindo maior precisão de clock.

Entendendo a diferença entre velocidade teórica e real

Na tabela fornecida, aparecem dois valores importantes:

• Speed (bytes/s) → taxa teórica considerando 8 bits por byte
• Actual speed (bytes/s) → taxa real considerando overhead da UART

Esse overhead vem do formato típico de transmissão:

1 bit de start + 8 bits de dados + 1 bit de stop = 10 bits por byte

Ou seja:

A eficiência real é de aproximadamente 80% (8/10)

Tabela de Baud Rates

Abaixo está a tabela organizada com os dados fornecidos:

Velocidades mais usadas e seus contextos

Na prática, algumas taxas se tornaram padrão de mercado:

9600 baud
Muito utilizado em sistemas legados, sensores simples e comunicação robusta em ambientes com ruído. Ideal quando confiabilidade é mais importante que velocidade.

19200 e 38400 baud
Utilizados em sistemas industriais e automação, oferecendo bom equilíbrio entre velocidade e estabilidade.

57600 baud
Comum em comunicação com módulos embarcados intermediários (GPS, modems antigos).

115200 baud
O padrão mais usado atualmente para debug serial, comunicação com PCs e bootloaders. É rápido o suficiente para logs e transferência moderada de dados.

230400 a 921600 baud
Usados em aplicações mais exigentes, como:

• streaming de dados de sensores
• comunicação com displays
• transferência de arquivos
• aplicações IoT de maior throughput

Porém, nessas velocidades, entram desafios importantes:

• precisão do clock (erro percentual)
• interferência eletromagnética
• qualidade do layout de PCB

Considerações de Engenharia

Ao escolher o baud rate em um projeto embarcado, você deve considerar:

• Clock do sistema: erros de divisão podem gerar falhas de sincronização
• Comprimento do cabo: quanto maior, menor deve ser a taxa
• Ambiente: ruído industrial exige taxas menores
• Buffer e DMA: taxas altas exigem melhor gestão de dados

Uma decisão errada aqui pode gerar desde perda de dados até travamentos intermitentes difíceis de depurar.

The post Baud Rate: o que é, origem, tabela completa e como escolher a taxa ideal na comunicação serial first appeared on MCU & FPGA.

Conceito, motivação e panorama geral

Em sistemas embarcados reais, dados seriais não chegam “limpos”. Há ruído elétrico, bytes perdidos, reinicializações assíncronas, buffers cheios e tarefas concorrentes. Protocolos auto-sincronizáveis surgem exatamente para resolver esse cenário: eles permitem recuperar o alinhamento do fluxo mesmo quando o receptor começa a ler no meio de um pacote, sem depender de resets globais ou estados externos.

Um protocolo é auto-sincronizável quando o receptor consegue, observando apenas o fluxo de bytes, reencontrar limites válidos de mensagem após erros. Isso contrasta com abordagens frágeis como “leia N bytes e confie”, que falham assim que um único byte se perde. Em UART, SPI em modo streaming, CDC-ACM, ou qualquer link byte-oriented, essa propriedade define se o sistema se recupera sozinho ou trava silenciosamente.

Nesta série, vamos analisar três abordagens amplamente usadas — SLIP, COBS e CBOR — não como “formatos bonitos”, mas como decisões de engenharia. Vamos discutir o que cada uma garante, o que não garante, onde usar, onde evitar, e como implementar corretamente em firmware de produção.

O que significa “auto-sincronização” na prática

Do ponto de vista do firmware, auto-sincronização implica três capacidades essenciais:

1. Delimitação inequívoca
   O receptor precisa identificar onde uma mensagem começa e termina, mesmo após bytes inválidos.
2. Recuperação após erro
   Um erro local (byte perdido, extra, corrompido) não pode invalidar todo o fluxo.
3. Parsing incremental (streaming)
   O protocolo deve permitir processamento byte-a-byte, sem exigir buffers gigantes ou leituras bloqueantes.

SLIP, COBS e CBOR resolvem esses pontos de formas fundamentalmente diferentes, e entender essas diferenças é o que separa firmware de laboratório de firmware industrial.

Visão geral dos protocolos que vamos estudar

Um erro comum é tratar CBOR como protocolo de transporte — ele não é. CBOR define como os dados são codificados, não como são enquadrados no fluxo. Por isso, em sistemas bem projetados, CBOR quase sempre aparece sobre COBS ou outro método de framing.

Boas e más decisões logo no início

Boas escolhas

• Pensar em framing antes de escrever o parser
• Separar claramente: transporte × serialização
• Assumir que bytes serão perdidos em algum momento

Más escolhas

• Usar scanf() ou parsing por strings
• Depender de timeouts para “adivinhar” fim de pacote
• Achar que CRC substitui framing (não substitui)

The post Protocolos auto-sincronizáveis em sistemas embarcados first appeared on MCU & FPGA.

UART não é uma porta: é uma decisão de arquitetura

Para a maioria dos engenheiros, o primeiro contato com um microcontrolador envolve ligar um conversor USB-UART, abrir um terminal serial e enviar caracteres. Essa experiência inicial cria um vício conceitual perigoso: tratar UART como se fosse uma “porta de texto”, algo próximo de um printf() com fio. Esse modelo mental funciona em demos, provas de conceito e exemplos de datasheet — mas ele quebra imediatamente quando o sistema passa a existir no mundo real.

UART não é uma porta, não é um periférico isolado e definitivamente não é um canal confiável por definição. UART é apenas um mecanismo físico de serialização de bits, sem noção de mensagens, pacotes, estados, erros ou intenção semântica. Tudo o que faz sentido — início, fim, significado, validade, recuperação — precisa ser projetado em cima dela. Quando isso não é feito, o sistema não “falha de vez”; ele falha de forma intermitente, imprevisível e difícil de depurar.

Um teste simples revela rapidamente o nível de maturidade de um firmware: o que acontece quando um byte se perde? Se a resposta for “nunca acontece” ou “o terminal não mostra”, o sistema já está arquiteturalmente comprometido. Em sistemas reais há ruído elétrico, interrupções concorrentes, buffers cheios, clocks ligeiramente desalinhados, resets parciais e firmware sendo atualizado em campo. UART expõe todas essas fragilidades sem piedade.

O erro clássico: UART como “linha de printf”

O padrão mais comum — e mais frágil — de uso de UART é este:

// <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/274c.png" alt="❌" class="wp-smiley" style="height: 1em; max-height: 1em;" /> Abordagem frágil e não determinística
void loop(void) {
    char cmd[32];
    scanf("%s", cmd);

    if (strcmp(cmd, "ON") == 0) {
        led_on();
    } else if (strcmp(cmd, "OFF") == 0) {
        led_off();
    }
}

// ❌ Abordagem frágil e não determinística
void loop(void) {
    char cmd[32];
    scanf("%s", cmd);

    if (strcmp(cmd, "ON") == 0) {
        led_on();
    } else if (strcmp(cmd, "OFF") == 0) {
        led_off();
    }
}

Esse código pressupõe coisas que não são garantidas pela UART:

• Que os dados chegam completos
• Que não há bytes extras ou truncados
• Que o buffer nunca estoura
• Que o alinhamento entre transmissor e receptor é perfeito
• Que ruído não existe
• Que o tempo não importa

Além disso, scanf() bloqueia a execução, mistura parsing com transporte, não detecta framing e não oferece nenhuma estratégia de recuperação. Funciona em bancada, falha em produção.

A mudança de mentalidade: UART como canal bruto

Um sistema robusto parte do princípio oposto:

UART não transporta comandos, transporta bytes.
Quem transporta mensagens é o protocolo que você desenha.

Isso muda completamente a arquitetura. Em vez de “ler comandos”, o firmware passa a:

1. Receber bytes de forma assíncrona
2. Bufferizar dados
3. Detectar início e fim de quadros
4. Validar integridade
5. Interpretar significado
6. Responder ou recuperar estado

Um primeiro passo correto é separar recepção de interpretação:

// <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/2705.png" alt="✅" class="wp-smiley" style="height: 1em; max-height: 1em;" /> UART tratada como stream bruto
#define RX_BUFFER_SIZE 128

volatile uint8_t rx_buffer[RX_BUFFER_SIZE];
volatile uint16_t rx_head = 0;

void USART_IRQHandler(void) {
    uint8_t byte = USART_ReadByte();
    rx_buffer[rx_head++] = byte;
    rx_head %= RX_BUFFER_SIZE;
}

// ✅ UART tratada como stream bruto
#define RX_BUFFER_SIZE 128

volatile uint8_t rx_buffer[RX_BUFFER_SIZE];
volatile uint16_t rx_head = 0;

void USART_IRQHandler(void) {
    uint8_t byte = USART_ReadByte();
    rx_buffer[rx_head++] = byte;
    rx_head %= RX_BUFFER_SIZE;
}

Aqui não há “comandos”, apenas dados crus entrando no sistema. Isso é proposital. O firmware assume que os bytes podem estar incompletos, desalinhados ou corrompidos — e projeta em cima disso.

A partir desse ponto, tudo o que vier depois — framing, parsing, validação — deixa de ser improviso e passa a ser engenharia deliberada.

UART como espelho do engenheiro

UART é brutal porque ela não esconde nada. Não há retransmissão automática, não há ordenação garantida, não há controle de fluxo implícito. Se o sistema funciona bem sobre UART, ele provavelmente funcionará bem sobre SPI, CAN, RS-485, TCP ou rádio. Se ele só funciona quando tudo dá certo, então ele não funciona.

Projetar bem sobre UART é um divisor de águas. É o ponto em que o engenheiro deixa de “fazer firmware” e começa a construir sistemas distribuídos embarcados, capazes de sobreviver ao mundo real.

The post UART não é Porta Serial: Como Projetar Protocolos Robustos em Sistemas Embarcados first appeared on MCU & FPGA.