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.