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

3 — Soft Timers no Zephyr

Tempo como evento, não como delay

Em firmware industrial, tempo não é espera, é informação.
Sempre que você usa k_sleep() como parte da lógica, está misturando controle de fluxo com temporização, criando acoplamentos invisíveis e dificultando recuperação, teste e escalabilidade.

O Zephyr resolve isso com Soft Timers (k_timer), que transformam o tempo em eventos explícitos, integráveis ao mesmo pipeline usado por interrupções.

3.1 O erro comum: k_sleep() como lógica

Considere este padrão (muito comum e problemático):

while (1) {
    read_sensor();
    k_sleep(K_MSEC(100));
}

while (1) {
    read_sensor();
    k_sleep(K_MSEC(100));
}

Problemas:

• Não reage bem a eventos externos.
• Não pode ser interrompido facilmente.
• Não escala para múltiplas fontes de evento.
• Difícil de testar e simular.
• Mistura quando executar com o que executar.

Em sistemas robustos, tempo gera eventos, e eventos disparam ações.

3.2 Conceito de Soft Timer no Zephyr

Um k_timer é:

• Executado pelo kernel.
• Preciso e independente de threads específicas.
• Capaz de gerar callbacks periódicos ou únicos.
• Seguro para sinalização, não para processamento pesado.

⚠️ Assim como ISRs, callbacks de k_timer não são lugar para lógica pesada.

3.3 Exemplo 2 — Timer como fonte de eventos

Vamos transformar um timer periódico em um evento do pipeline.

Definição do timer

#include <zephyr/kernel.h>

/* Semáforo para evento de tempo */
K_SEM_DEFINE(timer_sem, 0, 1);

static void timer_handler(struct k_timer *timer)
{
    /* Callback leve: apenas sinaliza */
    k_sem_give(&timer_sem);
}

K_TIMER_DEFINE(sensor_timer, timer_handler, NULL);

#include <zephyr/kernel.h>

/* Semáforo para evento de tempo */
K_SEM_DEFINE(timer_sem, 0, 1);

static void timer_handler(struct k_timer *timer)
{
    /* Callback leve: apenas sinaliza */
    k_sem_give(&timer_sem);
}

K_TIMER_DEFINE(sensor_timer, timer_handler, NULL);

Inicialização do timer

void timer_init(void)
{
    /* Dispara a cada 100 ms */
    k_timer_start(&sensor_timer,
                  K_MSEC(100),
                  K_MSEC(100));
}

void timer_init(void)
{
    /* Dispara a cada 100 ms */
    k_timer_start(&sensor_timer,
                  K_MSEC(100),
                  K_MSEC(100));
}

📌 Aqui, o tempo virou um evento, igual a uma interrupção de hardware.

3.4 Consumindo eventos temporais

Agora o processamento ocorre em thread normal:

void sensor_thread(void)
{
    while (1) {
        k_sem_take(&timer_sem, K_FOREVER);

        read_sensor();
        validate_data();
        enqueue_processing();
    }
}

void sensor_thread(void)
{
    while (1) {
        k_sem_take(&timer_sem, K_FOREVER);

        read_sensor();
        validate_data();
        enqueue_processing();
    }
}

Perceba algo importante:
👉 o código não “espera tempo”, ele reage a eventos de tempo.

Isso permite:

• Ajustar período sem alterar lógica.
• Pausar, reiniciar ou acelerar o sistema.
• Integrar com outros eventos (GPIO, rede, watchdog).

3.5 Soft Timer como etapa do pipeline

Em firmware profissional, timers normalmente exercem papéis como:

• Debounce temporal
• Timeout de protocolo
• Watchdog lógico
• Trigger periódico de aquisição
• Backoff exponencial
• Janelas de validação

Exemplo mental de pipeline:

[ Interrupção GPIO ]
          ↓
[ Timer de debounce ]
          ↓
[ Processamento ]
          ↓
[ Timer de timeout ]
          ↓
[ Ação corretiva ]

[ Interrupção GPIO ]
          ↓
[ Timer de debounce ]
          ↓
[ Processamento ]
          ↓
[ Timer de timeout ]
          ↓
[ Ação corretiva ]

Nada bloqueia. Nada dorme.
Tudo é evento fluindo pelo sistema.

3.6 Regra de ouro dos Soft Timers

✔ Timer sinaliza, não processa
✔ Timer não conhece regras de negócio
✔ Timer gera eventos claros e observáveis
✔ Timer nunca substitui thread
✔ Timer elimina sleep() da lógica principal

Quando você adota timers dessa forma, o firmware deixa de ser sequencial e passa a ser reativo e arquitetado.