Table of Contents
- Visão Geral: por que Máquina de Estados em Firmware “de verdade”
- Estrutura do projeto FreeRTOS: tipos, filas e as duas tasks
- Motor da FSM: transições, deadlines, retentativas e estado seguro
- Tornando “produção”: entry-actions, correlação request/response e boas vs más escolhas
- Exemplo consolidado (mais “real”): correlação req_id, entry-actions, e ISR → fila
- Padrões de projeto embarcados aplicados: nomes, papéis e como encaixar no seu firmware
- Active Object (Objeto Ativo)
- Message Queue / Event-Driven Boundary (Fronteira por Mensagens)
- Gatekeeper (Dono do Periférico)
- State Pattern (variação em C) e disciplina de entry/actions
- Supervisor (FSM acima de FSMs)
- Watchdog lógico (mais útil que só “chutar o cão”)
- Error Containment / Recovery Block
- Como isso vira uma arquitetura real (sem “explodir” em complexidade)
- Checklist prático, métricas de campo e extensões naturais da FSM
Visão Geral: por que Máquina de Estados em Firmware “de verdade”
Em sistemas embarcados, a Máquina de Estados (Finite State Machine, FSM) não é só uma técnica de organização: ela é uma forma de tornar o comportamento previsível, rastreável e recuperável. Quando você está lidando com periféricos reais (UART, ADC, rádio, motores), o sistema não é “sequencial”; ele é reativo. Eventos chegam fora de hora, dados vêm incompletos, sensores falham, o usuário aperta botão no pior momento possível. A FSM é o mecanismo mais direto para modelar isso sem cair em “if-else infinito” ou em código que parece funcionar só em bancada.
O problema típico que vamos resolver neste artigo é este: como projetar um fluxo de controle cíclico (rodando continuamente) e recuperável (capaz de detectar falhas e voltar a um estado seguro) usando FreeRTOS, com duas threads cooperando: uma thread dona da lógica (controle por estados) e outra thread provedora de eventos/dados (E/S, aquisição, comunicação). A ideia é evitar dois extremos comuns: (1) uma thread monolítica que faz tudo e trava o sistema; (2) várias threads competindo por dados sem governança clara.
Para construir isso com rigor arquitetural, vamos “encaixar” a FSM dentro de padrões de projeto clássicos de tempo real: Active Object (um objeto/tarefa dona do seu próprio loop e fila), Message Queuing (fila de mensagens como fronteira limpa entre threads), e uma estratégia de ciclo + timeouts inspirada no raciocínio de padrões de concorrência e arquitetura para sistemas de tempo real (como discutido em catálogos de padrões para RTE systems). Na parte de robustez, vamos adicionar mecanismos de “recuperação” que não são mágicos: Watchdog lógico, Sanity Check (checagens de coerência), e uma política de degradação controlada (fallback para estado seguro).
No final, você terá um exemplo que dá para copiar para um projeto real: duas tasks do FreeRTOS, uma FSM explícita com transições bem definidas, eventos chegando por fila, timeouts, retentativas, e recuperação após erro — sem “gambiarras” como delays espalhados ou variáveis globais sem proteção.
