Table of Contents
- Conceito, motivação e panorama geral
- O que significa “auto-sincronização” na prática
- Visão geral dos protocolos que vamos estudar
- Boas e más decisões logo no início
- SLIP (Serial Line Internet Protocol): simplicidade que cobra seu preço
- COBS (Consistent Overhead Byte Stuffing): framing determinístico e recuperação real
- CBOR (Concise Binary Object Representation): semântica binária não é framing
- Comparação geral, decisões de projeto e checklist de boas práticas
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:
- Delimitação inequívoca
O receptor precisa identificar onde uma mensagem começa e termina, mesmo após bytes inválidos. - Recuperação após erro
Um erro local (byte perdido, extra, corrompido) não pode invalidar todo o fluxo. - 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
| Protocolo | Natureza | Resolve framing | Auto-sincroniza | Detecta erro | Uso típico |
|---|---|---|---|---|---|
| SLIP | Delimitador + escape | Parcial | Fraca | Não | Debug simples, legado |
| COBS | Codificação de comprimento | Forte | Forte | Não | UART robusta, SPI streaming |
| CBOR | Serialização binária estruturada | Não (sozinho) | Parcial | Opcional | RPC, IoT, payload semântico |
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)
