Arquitetura Orientada a Eventos no FreeRTOS

Introdução e Motivação

Em sistemas embarcados modernos, especialmente aqueles baseados em FreeRTOS, a forma como o firmware reage ao mundo externo é tão importante quanto o código em si. Sensores, comunicação, interrupções, timers e pilhas de protocolo geram estímulos de forma assíncrona, e arquiteturas tradicionais baseadas apenas em superloop rapidamente se tornam difíceis de manter, escalar e depurar. É nesse contexto que surge a Arquitetura Orientada a Eventos (Event-Driven Architecture – EDA).

No FreeRTOS, uma arquitetura orientada a eventos não é um “modo especial” do sistema operacional, mas sim uma estratégia de organização do firmware, onde tarefas permanecem bloqueadas aguardando eventos específicos e acordam apenas quando algo relevante ocorre. Esses eventos podem ser sinais de interrupção, mensagens, flags, notificações, timers ou dados disponíveis em buffers. O resultado é um sistema reativo, determinístico e eficiente em consumo de CPU.

Do ponto de vista de engenharia, essa abordagem resolve três problemas clássicos:

1. Desperdício de CPU causado por polling constante
2. Acoplamento excessivo entre módulos
3. Dificuldade de sincronização entre múltiplas fontes de eventos

Ao adotar uma arquitetura orientada a eventos, o firmware passa a se comportar como um conjunto de agentes cooperativos, cada tarefa com responsabilidade clara, reagindo apenas aos eventos que lhe dizem respeito. Isso melhora a legibilidade do código, reduz latência média de resposta e facilita testes unitários e manutenção evolutiva.

No FreeRTOS, essa arquitetura é viabilizada por um conjunto muito poderoso de primitivas nativas: Task Notifications, Queues, Event Groups, Stream Buffers, Message Buffers e Software Timers. Cada uma delas atende a um tipo específico de evento e será explorada detalhadamente ao longo deste artigo, sempre com exemplos práticos e contextualizados.

O que vem a seguir

Na próxima seção, entraremos no modelo conceitual da Arquitetura Orientada a Eventos no FreeRTOS, explicando como eventos fluem pelo sistema, como tarefas devem ser estruturadas e como evitar armadilhas comuns, como event storms, inversão de prioridade e acoplamento indireto.

Modelo Conceitual da Arquitetura Orientada a Eventos

Em uma arquitetura orientada a eventos no FreeRTOS, o sistema deixa de ser centrado em fluxo sequencial de execução e passa a ser organizado em torno de eventos que representam fatos relevantes do sistema. Um evento pode significar “um dado chegou”, “um tempo expirou”, “um periférico terminou uma operação” ou “uma condição de estado foi satisfeita”. O papel central do RTOS é suspender tarefas até que esses eventos ocorram, garantindo previsibilidade temporal e uso eficiente do processador.

Do ponto de vista conceitual, essa arquitetura pode ser dividida em três elementos fundamentais: produtores de eventos, mecanismos de transporte de eventos e consumidores de eventos. Produtores normalmente são ISRs, timers de software, drivers ou tarefas de baixo nível. O transporte é feito pelas primitivas do FreeRTOS, enquanto os consumidores são tarefas que encapsulam lógica de negócio ou processamento de dados. Esse desacoplamento é essencial para sistemas escaláveis.

Um princípio importante é que tarefas orientadas a eventos devem permanecer bloqueadas na maior parte do tempo. Em FreeRTOS, isso significa usar chamadas bloqueantes como xQueueReceive(), xEventGroupWaitBits() ou ulTaskNotifyTake(), sempre com portMAX_DELAY ou tempos bem definidos. Dessa forma, não há polling ativo, e o escalonador pode dedicar CPU apenas às tarefas que realmente precisam executar naquele instante.

Outro ponto crítico do modelo é que eventos não devem carregar lógica, apenas sinalização e dados mínimos. A decisão do que fazer em resposta a um evento pertence à tarefa consumidora. Isso evita que ISRs fiquem complexas e garante que decisões de alto nível ocorram sempre em contexto de tarefa, onde mutexes, alocação de memória e chamadas de API são seguras.

Fluxo típico de eventos no FreeRTOS

Um fluxo clássico em arquitetura orientada a eventos segue o seguinte encadeamento lógico:

1. Um periférico gera uma interrupção (por exemplo, UART RX completa).
2. A ISR sinaliza o evento usando uma primitiva segura para interrupções.
3. O kernel do FreeRTOS desbloqueia a tarefa interessada.
4. A tarefa acorda, processa o evento e retorna ao estado bloqueado.

Esse modelo cria um sistema reativo e previsível, onde a latência entre o evento e o processamento é controlada diretamente pela prioridade da tarefa e pela duração das ISRs. Em projetos bem arquitetados, o tempo gasto dentro da interrupção é mínimo, e todo o processamento ocorre em nível de tarefa.

Exemplo conceitual simplificado

void vUartTask(void *pvParameters)
{
    uint8_t rxByte;

    for (;;)
    {
        if (xQueueReceive(uartRxQueue, &rxByte, portMAX_DELAY) == pdPASS)
        {
            processUartByte(rxByte);
        }
    }
}

void vUartTask(void *pvParameters)
{
    uint8_t rxByte;

    for (;;)
    {
        if (xQueueReceive(uartRxQueue, &rxByte, portMAX_DELAY) == pdPASS)
        {
            processUartByte(rxByte);
        }
    }
}

Neste exemplo, a tarefa vUartTask não executa continuamente. Ela permanece bloqueada até que um byte seja colocado na fila por uma ISR ou outra tarefa. Isso caracteriza perfeitamente o modelo orientado a eventos: o evento é a chegada de um dado, e a tarefa existe apenas para reagir a ele.

Implicações arquiteturais importantes

Ao adotar esse modelo, algumas decisões de projeto tornam-se fundamentais. A granularidade dos eventos deve ser cuidadosamente escolhida: eventos muito genéricos levam a tarefas complexas e difíceis de testar; eventos excessivamente específicos geram sobrecarga e fragmentação. Além disso, o uso correto de prioridades é crucial para garantir que eventos críticos sejam tratados com menor latência.

Outro aspecto frequentemente negligenciado é o tratamento de eventos concorrentes. O FreeRTOS permite que múltiplos eventos acordem a mesma tarefa, mas o firmware deve ser capaz de lidar com isso de forma determinística, normalmente utilizando estruturas de estado bem definidas ou state machines orientadas a eventos.

Na próxima seção, entraremos nos mecanismos de eventos disponíveis no FreeRTOS, começando pelo mais eficiente e subutilizado deles: Task Notifications, analisando seu funcionamento interno, vantagens, limitações e padrões de uso.

Excelente, seguimos.

Task Notifications como Mecanismo Central de Eventos

Entre todos os mecanismos oferecidos pelo FreeRTOS, as Task Notifications são, do ponto de vista arquitetural, a forma mais eficiente de implementar uma arquitetura orientada a eventos. Elas funcionam como um canal direto ponto-a-ponto entre o kernel e uma tarefa, sem a sobrecarga de filas, sem alocação dinâmica e com latência mínima.

Cada tarefa no FreeRTOS possui internamente um array de notificações (desde o FreeRTOS 10), onde cada entrada contém um valor de 32 bits e um estado. Isso transforma a task notification em algo conceitualmente próximo a um registrador de eventos privado da tarefa. Esse detalhe é fundamental para entender por que esse mecanismo é tão eficiente e, ao mesmo tempo, tão poderoso.

Diferente de filas ou event groups, uma task notification não é compartilhada. Ela pertence a uma única tarefa. Isso força uma arquitetura mais limpa, onde existe um mapeamento explícito entre quem produz e quem consome o evento. Em arquiteturas bem desenhadas, isso reduz drasticamente o acoplamento implícito e elimina ambiguidades.

Modelo mental correto para Task Notifications

É comum iniciantes tratarem task notifications como “um semáforo mais rápido”. Embora isso seja parcialmente verdadeiro, essa visão é limitada. O modelo correto é pensar nelas como:

• Um evento binário (acordar ou não acordar a task)
• Um contador (quantidade de eventos acumulados)
• Um bitmap de flags
• Um payload de 32 bits

Tudo isso usando a mesma infraestrutura, dependendo apenas da API utilizada.

Essa flexibilidade permite criar arquiteturas orientadas a eventos extremamente compactas, onde um único mecanismo substitui filas, semáforos e flags em muitos cenários.

Exemplo 1 — Evento simples (sinalização pura)

Neste primeiro exemplo, uma ISR sinaliza que um evento ocorreu, e a tarefa apenas reage.

void vEventTask(void *pvParameters)
{
    for (;;)
    {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);

        handleEvent();
    }
}

void vEventTask(void *pvParameters)
{
    for (;;)
    {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);

        handleEvent();
    }
}

A função ulTaskNotifyTake() bloqueia a tarefa até que uma notificação seja recebida. O parâmetro pdTRUE indica que o contador interno será limpo ao acordar, garantindo comportamento de evento simples.

A ISR responsável pelo evento:

void EXTI_IRQHandler(void)
{
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;

    vTaskNotifyGiveFromISR(eventTaskHandle, &xHigherPriorityTaskWoken);

    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

void EXTI_IRQHandler(void)
{
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;

    vTaskNotifyGiveFromISR(eventTaskHandle, &xHigherPriorityTaskWoken);

    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

Aqui, o evento é produzido de forma segura em contexto de interrupção, e o kernel pode realizar context switch imediato se a prioridade justificar. Esse padrão é ideal para eventos como botão pressionado, fim de conversão ADC ou término de DMA.

Exemplo 2 — Contador de eventos acumulados

Em cenários onde múltiplos eventos podem ocorrer antes da tarefa acordar, a task notification pode atuar como contador.

void vLoggerTask(void *pvParameters)
{
    uint32_t events;

    for (;;)
    {
        events = ulTaskNotifyTake(pdFALSE, portMAX_DELAY);

        while (events--)
        {
            logEvent();
        }
    }
}

void vLoggerTask(void *pvParameters)
{
    uint32_t events;

    for (;;)
    {
        events = ulTaskNotifyTake(pdFALSE, portMAX_DELAY);

        while (events--)
        {
            logEvent();
        }
    }
}

Ao usar pdFALSE, o contador não é automaticamente zerado. O valor retornado indica quantos eventos ocorreram desde a última leitura. Isso é extremamente útil em sistemas com bursts de eventos, como recepção de pacotes ou amostras rápidas de sensores.

Exemplo 3 — Task Notification como bitmap de eventos

Outra aplicação avançada é usar o valor de 32 bits como mapa de bits de eventos, substituindo completamente os Event Groups quando o evento é destinado a uma única tarefa.

#define EVT_RX_READY   (1 << 0)
#define EVT_TX_DONE   (1 << 1)
#define EVT_ERROR     (1 << 2)

void vCommTask(void *pvParameters)
{
    uint32_t events;

    for (;;)
    {
        xTaskNotifyWait(0x00, 0xFFFFFFFF, &events, portMAX_DELAY);

        if (events & EVT_RX_READY)
            handleRx();

        if (events & EVT_TX_DONE)
            handleTxDone();

        if (events & EVT_ERROR)
            handleError();
    }
}

#define EVT_RX_READY   (1 << 0)
#define EVT_TX_DONE   (1 << 1)
#define EVT_ERROR     (1 << 2)

void vCommTask(void *pvParameters)
{
    uint32_t events;

    for (;;)
    {
        xTaskNotifyWait(0x00, 0xFFFFFFFF, &events, portMAX_DELAY);

        if (events & EVT_RX_READY)
            handleRx();

        if (events & EVT_TX_DONE)
            handleTxDone();

        if (events & EVT_ERROR)
            handleError();
    }
}

Esse padrão cria uma máquina de eventos compacta, extremamente eficiente e fácil de analisar em termos de latência e consumo de recursos.

Vantagens arquiteturais das Task Notifications

Do ponto de vista de engenharia de sistemas, as task notifications oferecem:

• Menor latência entre evento e execução
• Zero uso de heap
• Menor footprint de memória
• Determinismo temporal elevado
• Código mais explícito e fácil de rastrear

Por esse motivo, em arquiteturas orientadas a eventos bem projetadas, task notifications devem ser a primeira opção, e não a última.

Na próxima seção, vamos tratar de Event Groups, explicando quando eles são necessários, como evitá-los em excesso e como integrá-los corretamente em uma arquitetura orientada a eventos sem criar dependências implícitas.

Seguimos.