Comparação geral, decisões de projeto e checklist de boas práticas
Depois de analisar SLIP, COBS e CBOR individualmente, fica claro que eles não resolvem o mesmo problema — e tratá-los como alternativas diretas é um erro conceitual. Em sistemas embarcados bem projetados, o que existe é um pipeline de comunicação, onde cada camada tem uma responsabilidade clara: framing, integridade, semântica e aplicação.
O erro mais comum observado em firmware de campo não é “escolher o protocolo errado”, mas atribuir responsabilidades erradas ao protocolo certo. SLIP tenta fazer framing com escape frágil, COBS resolve framing de forma robusta, e CBOR não faz framing nenhum — ele organiza significado. Quando essa separação não é respeitada, o sistema passa a depender de timeouts, buffers enormes e estados implícitos.
Comparação técnica consolidada
| Critério | SLIP | COBS | CBOR |
|---|---|---|---|
| Resolve framing | Sim (frágil) | Sim (forte) | Não |
| Auto-sincronização | Limitada | Forte | Parcial |
| Delimitador inequívoco | Sim | Sim | Não |
| Overhead previsível | Não | Sim | Sim |
| Parsing streaming | Frágil | Robusto | Depende |
| Detecção de erro | Não | Não (externo) | Opcional |
| Semântica de dados | Não | Não | Sim |
| Uso isolado em UART | Arriscado | Correto | Errado |
| Uso em produção | Raro | Comum | Combinado |
Leitura correta da tabela:
- SLIP é um mínimo histórico
- COBS é transporte sério
- CBOR é conteúdo estruturado
Arquiteturas típicas (boas escolhas)
1. UART robusta entre MCUs
UART → COBS → CRC → aplicação binária
2. RPC embarcado / IoT
UART/SPI → COBS → CRC → CBOR → aplicação
3. Debug humano
UART → texto ASCII delimitado
Misturar os cenários acima normalmente gera sistemas instáveis.
Más decisões clássicas (e por que falham)
❌ “CBOR direto na UART”
Falha por ausência de framing. Um byte perdido quebra toda a estrutura.
❌ “SLIP + comandos críticos”
Um erro de escape invalida pacotes sem diagnóstico.
❌ “Timeout define fim de pacote”
Timeout não é framing. É adivinhação.
❌ “CRC resolve tudo”
CRC detecta erro dentro de um pacote já delimitado. Ele não encontra o pacote.
Checklist de boas práticas (engenharia de firmware)
Framing
- Sempre tenha um delimitador inequívoco
- Garanta re-sincronização sem reset
- Parsing byte-a-byte, sem bloqueio
Transporte
- Não dependa de temporização
- Overhead previsível
- Buffer mínimo necessário
Integridade
- CRC após serialização
- Erro invalida pacote, não o fluxo
- Nunca “tente consertar” pacote corrompido
Semântica
- Use CBOR quando:
- há versionamento
- múltiplos tipos de mensagem
- integração MCU ↔ Linux
- Evite CBOR quando:
- tempo fixo é crítico
- payload é trivial
Arquitetura
- Transporte ≠ significado
- Parser ≠ driver
- Driver não conhece protocolo
Regra prática para não errar
Se você precisa saber “onde começa a mensagem”, você ainda está no transporte.
Se você precisa saber “o que a mensagem significa”, você já está na semântica.
COBS resolve a primeira pergunta.
CBOR resolve a segunda.
SLIP resolve… apenas em ambientes controlados.
Conclusão do artigo
Protocolos auto-sincronizáveis não são um detalhe — eles definem se o sistema se recupera sozinho ou entra em estado inválido silencioso. Em firmware moderno, especialmente com Zephyr, FreeRTOS, gateways e IoT, COBS + CBOR forma uma base extremamente sólida, clara e extensível.
O que separa firmware de demonstração de firmware industrial não é a biblioteca usada, mas o entendimento correto das camadas.
