Table of Contents
- 2 — Interrupções no Zephyr
- 3 — Soft Timers no Zephyr
- 4 — Workqueues no Zephyr
- 5 — Desenhando pipelines completos de eventos no Zephyr
- 6 — Boas práticas industriais
- Prioridades, backpressure e recuperação de falhas
- 6.1 Priorização correta: tempo é um recurso finito
- 6.2 Exemplo — Workqueues com prioridades distintas
- 6.3 Backpressure: quando eventos chegam rápido demais
- 6.4 Exemplo — Limitando eventos com k_msgq
- 6.5 Eventos colapsáveis (coalescing)
- 6.6 Recuperação de falhas no pipeline
- 6.7 Checklist industrial de robustez
- 7 — Estudo de caso completo
- Pipeline Zephyr em um dispositivo IoT industrial (sensor → processamento → nuvem)
- 7.1 Cenário do sistema
- 7.2 Arquitetura do pipeline
- 7.3 Estágio 1 — ISR (evento físico)
- 7.4 Estágio 2 — Soft Timer (normalização temporal)
- 7.5 Estágio 3 — Workqueue de aquisição
- 7.6 Estágio 4 — Workqueue de processamento
- 7.7 Estágio 5 — Workqueue de comunicação
- 7.8 Controle de carga (backpressure)
- 7.9 Recuperação e robustez
- 7.10 O que esse estudo de caso demonstra
- 8 — Conclusão
Em firmware industrial e IoT de produção, o problema raramente é “como ler um sensor” ou “como reagir a uma interrupção”. O desafio real está em como transformar eventos assíncronos e imprevisíveis (interrupções de hardware, timeouts, pacotes de rede, watchdogs) em fluxos determinísticos, observáveis e recuperáveis — sem violar latência, sem bloquear ISRs, sem explodir prioridade e sem criar acoplamentos frágeis entre camadas.
O Zephyr RTOS se destaca exatamente por oferecer primitivas complementares — Interrupções, Soft Timers (k_timer) e Workqueues (k_work) — que, quando combinadas corretamente, permitem desenhar pipelines de eventos robustos, usados em produtos reais: gateways industriais, sensores remotos, equipamentos médicos, automação predial e dispositivos conectados operando por anos no campo.
Este artigo não trata essas primitivas de forma isolada. O foco é arquitetural:
como compor essas ferramentas para criar fluxos de processamento desacoplados, previsíveis e testáveis, respeitando as regras fundamentais de sistemas embarcados modernos:
- ISR mínima: interrupção apenas sinaliza, nunca processa.
- Tempo como evento: temporização explícita, não “sleep espalhado”.
- Processamento fora de ISR: trabalho pesado sempre em contexto de thread.
- Backpressure e ordenação: eventos fluem por etapas bem definidas.
- Escalabilidade: o desenho deve sobreviver ao crescimento do sistema.
Ao longo das próximas seções, vamos evoluir de um modelo mental até códigos concretos em C, mostrando:
- O papel correto de Interrupções no Zephyr.
- Como Soft Timers viram fontes de eventos temporais confiáveis.
- Como Workqueues funcionam como estágios de processamento.
- Como integrar tudo isso em pipelines de eventos industriais, com exemplos reais de firmware.
A ideia é que, ao final, você não apenas “saiba usar” essas APIs, mas consiga enxergar a arquitetura por trás de um firmware profissional — aquele que não depende de sorte, nem de atrasos mágicos, nem de lógica escondida em ISR.
