Arquitetura Orientada a Eventos no FreeRTOS

Princípios arquiteturais que emergem

A composição correta de eventos leva a algumas regras práticas:

• Eventos acordam tarefas, não executam lógica
• Dados fluem por canais explícitos
• Estados são separados de eventos
• ISRs são produtoras, tasks são consumidoras
• Tempo é tratado como evento

Esses princípios tornam o sistema mais previsível, testável e escalável.

Na próxima seção, faremos uma análise crítica dos erros mais comuns em arquiteturas orientadas a eventos no FreeRTOS, mostrando como identificá-los e corrigi-los em projetos reais.

Perfeito, vamos fechar o núcleo técnico com uma análise crítica — esta seção costuma ser a mais valiosa para quem já desenvolve com FreeRTOS.

Erros Arquiteturais Comuns e Como Evitá-los

Arquiteturas orientadas a eventos trazem ganhos significativos em desempenho, clareza e escalabilidade, mas quando mal aplicadas, produzem sistemas difíceis de depurar e com comportamento errático. Nesta seção, vamos analisar os erros mais recorrentes observados em projetos reais com FreeRTOS, explicando não apenas o que está errado, mas por que o problema surge e como corrigi-lo do ponto de vista arquitetural.

Erro 1 — Polling disfarçado de arquitetura orientada a eventos

for (;;)
{
    if (xQueueReceive(queue, &msg, 0) == pdPASS)
    {
        process(msg);
    }
    vTaskDelay(pdMS_TO_TICKS(10));
}

for (;;)
{
    if (xQueueReceive(queue, &msg, 0) == pdPASS)
    {
        process(msg);
    }
    vTaskDelay(pdMS_TO_TICKS(10));
}

Esse padrão é um anti-pattern clássico. Embora use uma fila, a tarefa não é orientada a eventos, mas sim a tempo. Isso gera latência artificial, desperdiça CPU e dificulta análise temporal.

Correção arquitetural:

xQueueReceive(queue, &msg, portMAX_DELAY);

xQueueReceive(queue, &msg, portMAX_DELAY);

Se a tarefa só existe para reagir ao evento, ela deve permanecer bloqueada até que ele ocorra.

Erro 2 — Lógica pesada dentro de ISRs

void EXTI_IRQHandler(void)
{
    readSensor();
    filterData();
    sendPacket();
}

void EXTI_IRQHandler(void)
{
    readSensor();
    filterData();
    sendPacket();
}

Esse erro destrói determinismo e previsibilidade. ISRs devem ser mínimas e previsíveis, caso contrário o escalonador perde controle fino da execução.

Correção arquitetural:

void EXTI_IRQHandler(void)
{
    vTaskNotifyGiveFromISR(sensorTaskHandle, NULL);
}

void EXTI_IRQHandler(void)
{
    vTaskNotifyGiveFromISR(sensorTaskHandle, NULL);
}

Toda a lógica deve migrar para uma tarefa orientada a eventos.

Erro 3 — Uso excessivo de Event Groups como fila de eventos

xEventGroupSetBits(group, EVT_RX);
xEventGroupSetBits(group, EVT_RX);

xEventGroupSetBits(group, EVT_RX);
xEventGroupSetBits(group, EVT_RX);

Eventos duplicados são perdidos. Event Groups não acumulam eventos. Esse erro gera falhas intermitentes difíceis de reproduzir.

Correção:
Use Event Groups apenas para estado, e não para eventos repetitivos. Para eventos acumuláveis, use task notifications ou queues.

Erro 4 — Fila genérica para tudo

typedef enum {
    EVT_A,
    EVT_B,
    EVT_C
} EventType;

typedef enum {
    EVT_A,
    EVT_B,
    EVT_C
} EventType;

xQueueSend(systemQueue, &event, 0);

xQueueSend(systemQueue, &event, 0);

Esse padrão cria um barramento implícito, semelhante a event bus, que rapidamente se torna difícil de rastrear e testar.

Correção arquitetural:
Prefira filas específicas por domínio funcional ou task notifications direcionadas.

Erro 5 — Tasks que nunca bloqueiam

for (;;)
{
    doWork();
}

for (;;)
{
    doWork();
}

Mesmo quando o trabalho é eventual, esse padrão consome CPU continuamente e inviabiliza sistemas de baixo consumo.

Correção:
Toda tarefa orientada a eventos deve possuir um ponto claro de bloqueio, associado a um mecanismo de evento.

Erro 6 — Misturar estado e evento

#define EVT_ERROR (1 << 0)

#define EVT_ERROR (1 << 0)

Usar o mesmo bit para sinalizar erro ocorrido e erro presente gera ambiguidade e comportamento não determinístico.

Correção arquitetural:
Eventos sinalizam transições. Estados representam condições persistentes. Eles devem ser separados conceitualmente e estruturalmente.

Erro 7 — Overengineering de eventos

Criar múltiplos níveis de abstração, wrappers genéricos e sistemas de despacho excessivamente complexos dificulta análise temporal e debugging.

A arquitetura orientada a eventos no FreeRTOS é poderosa justamente por sua simplicidade direta. Quando algo parece complexo demais, provavelmente está errado.

Checklist arquitetural prático

Um sistema bem projetado tende a responder “sim” para as seguintes perguntas:

• Minhas tasks passam a maior parte do tempo bloqueadas?
• Minhas ISRs apenas sinalizam eventos?
• Cada mecanismo de evento tem um papel claro?
• Estados globais são explícitos?
• Eventos não carregam lógica?
• A latência é controlada por prioridade, não por delays?

Se a resposta for “não” para vários desses pontos, o sistema provavelmente não está verdadeiramente orientado a eventos.