Zephyr e Integração Avançada: Interrupções + Soft Timers + Workqueues

7 — Estudo de caso completo

Pipeline Zephyr em um dispositivo IoT industrial (sensor → processamento → nuvem)

Vamos consolidar tudo em um caso realista, muito próximo do que se encontra em firmware industrial de produção:
um nó IoT que coleta eventos físicos, valida no tempo, processa dados e publica para a rede — tudo sem bloqueios, sem lógica em ISR e com controle de carga.

7.1 Cenário do sistema

Dispositivo: nó industrial de monitoramento
Eventos:

• Pulso em GPIO (sensor físico)
• Aquisição periódica
• Publicação MQTT

Requisitos:

• Debounce temporal
• Latência previsível
• Não perder o último evento relevante
• Comunicação isolada do tempo real

7.2 Arquitetura do pipeline

[ GPIO ISR ]
      ↓
[ Timer de Debounce ]
      ↓
[ Workqueue: Aquisição ]
      ↓
[ Workqueue: Processamento ]
      ↓
[ Workqueue: Comunicação ]

[ GPIO ISR ]
      ↓
[ Timer de Debounce ]
      ↓
[ Workqueue: Aquisição ]
      ↓
[ Workqueue: Processamento ]
      ↓
[ Workqueue: Comunicação ]

Cada estágio tem contexto, prioridade e responsabilidade própria.

7.3 Estágio 1 — ISR (evento físico)

static void gpio_isr(const struct device *dev,
                     struct gpio_callback *cb,
                     uint32_t pins)
{
    /* Evento bruto → próximo estágio */
    k_timer_start(&debounce_timer, K_MSEC(10), K_NO_WAIT);
}

static void gpio_isr(const struct device *dev,
                     struct gpio_callback *cb,
                     uint32_t pins)
{
    /* Evento bruto → próximo estágio */
    k_timer_start(&debounce_timer, K_MSEC(10), K_NO_WAIT);
}

✔ ISR mínima
✔ Nenhuma lógica
✔ Nenhuma decisão

7.4 Estágio 2 — Soft Timer (normalização temporal)

static void debounce_handler(struct k_timer *timer)
{
    k_work_submit_to_queue(&acq_workq, &acq_work);
}

K_TIMER_DEFINE(debounce_timer, debounce_handler, NULL);

static void debounce_handler(struct k_timer *timer)
{
    k_work_submit_to_queue(&acq_workq, &acq_work);
}

K_TIMER_DEFINE(debounce_timer, debounce_handler, NULL);

✔ Remove ruído
✔ Evita rajadas
✔ Garante espaçamento mínimo

7.5 Estágio 3 — Workqueue de aquisição

static void acquisition_handler(struct k_work *work)
{
    latest_value = read_sensor();
    k_work_submit_to_queue(&proc_workq, &proc_work);
}

K_WORK_DEFINE(acq_work, acquisition_handler);

static void acquisition_handler(struct k_work *work)
{
    latest_value = read_sensor();
    k_work_submit_to_queue(&proc_workq, &proc_work);
}

K_WORK_DEFINE(acq_work, acquisition_handler);

Características:

• Rápido
• Determinístico
• Sem comunicação externa

7.6 Estágio 4 — Workqueue de processamento

static void processing_handler(struct k_work *work)
{
    if (validate(latest_value)) {
        filtered = filter(latest_value);
        k_work_submit_to_queue(&net_workq, &net_work);
    }
}

K_WORK_DEFINE(proc_work, processing_handler);

static void processing_handler(struct k_work *work)
{
    if (validate(latest_value)) {
        filtered = filter(latest_value);
        k_work_submit_to_queue(&net_workq, &net_work);
    }
}

K_WORK_DEFINE(proc_work, processing_handler);

Aqui ocorre:

• Validação
• Filtragem
• Decisão

Nada depende de tempo físico direto.

7.7 Estágio 5 — Workqueue de comunicação

static void network_handler(struct k_work *work)
{
    publish_mqtt(filtered);
}

K_WORK_DEFINE(net_work, network_handler);

static void network_handler(struct k_work *work)
{
    publish_mqtt(filtered);
}

K_WORK_DEFINE(net_work, network_handler);

✔ Pode bloquear
✔ Pode falhar
✔ Não afeta o tempo real

7.8 Controle de carga (backpressure)

Aplicando coalescing no estágio de aquisição:

static atomic_t pending;

static void trigger_acquisition(void)
{
    if (atomic_cas(&pending, 0, 1)) {
        k_work_submit_to_queue(&acq_workq, &acq_work);
    }
}

static atomic_t pending;

static void trigger_acquisition(void)
{
    if (atomic_cas(&pending, 0, 1)) {
        k_work_submit_to_queue(&acq_workq, &acq_work);
    }
}

✔ Último valor vence
✔ Sem fila infinita
✔ Sistema previsível

7.9 Recuperação e robustez

• Timeout lógico com k_timer
• Watchdog de pipeline
• Estados degradados
• Logs fora do caminho crítico

Isso permite:

• Detecção de travamentos
• Recuperação sem reset global
• Observabilidade em campo

7.10 O que esse estudo de caso demonstra

✔ Firmware reativo
✔ Arquitetura escalável
✔ Isolamento de responsabilidades
✔ Uso correto das primitivas do Zephyr
✔ Padrão usado em IoT industrial real

Esse não é um exemplo didático simplificado — é um esqueleto arquitetural que pode ser levado diretamente para produção.