1. Introdução: por que usar Zephyr no Arduino DUE

O Zephyr Project é um sistema operacional de tempo real (RTOS – Real-Time Operating System) moderno, modular e altamente configurável, projetado para sistemas embarcados que exigem previsibilidade temporal, portabilidade e escalabilidade. Diferente do ecossistema Arduino tradicional — baseado em superloop e bibliotecas monolíticas — o Zephyr oferece um modelo arquitetural profissional, alinhado a práticas industriais, como device tree, Kconfig, CMake e um kernel preemptivo completo.

O Arduino DUE ocupa um espaço interessante nesse contexto. Baseado no microcontrolador Atmel/Microchip SAM3X8E, um ARM Cortex-M3 de 32 bits operando a 84 MHz, ele oferece recursos raros no “mundo Arduino”: barramento externo, controlador DMA (Direct Memory Access), múltiplas UARTs, SPI, TWI (I²C – Inter-Integrated Circuit), além de USB nativo (USB OTG). Esses recursos fazem do DUE uma excelente plataforma didática para aprender Zephyr em um hardware amplamente conhecido.

Neste artigo, você aprenderá passo a passo, de forma minuciosa, como criar um projeto Zephyr totalmente funcional para o Arduino DUE, utilizando todos os recursos documentados oficialmente pela fundação Zephyr para essa placa. O foco não será apenas “compilar e rodar”, mas entender a arquitetura do projeto, as decisões de configuração e o papel de cada arquivo envolvido.

2. Visão geral do suporte do Zephyr ao Arduino DUE

Antes de escrever qualquer linha de código, é fundamental entender como o Zephyr enxerga o Arduino DUE. No Zephyr, placas não são tratadas como “kits genéricos”, mas como descrições formais de hardware, compostas por:

• Board Definition: define CPU, clock, memória e periféricos básicos
• Device Tree (DTS): descreve os dispositivos de hardware de forma declarativa
• Kconfig da placa: habilita ou restringe funcionalidades do kernel
• Arquivos de build: integram a placa ao sistema CMake do Zephyr

No caso do Arduino DUE, o Zephyr fornece oficialmente:

• Arquivo de board baseado no SAM3X8E
• Mapeamento correto de pinos compatível com o layout do DUE
• Suporte a:
  • GPIO (General Purpose Input/Output)
  • UART (console serial)
  • SPI
  • I²C (TWI no SAM)
  • Temporizadores e SysTick
• Programação via porta USB de programação (a mesma usada com o bossac)

Isso significa que não é necessário criar uma placa customizada para começar: o Arduino DUE já está plenamente integrado ao ecossistema Zephyr.

3. Pré-requisitos do ambiente de desenvolvimento

Antes de criar o projeto, o ambiente Zephyr precisa estar corretamente instalado. Assumiremos aqui que você já leu os artigos anteriores da série e possui:

• Linux (Ubuntu 22.04 ou superior recomendado)
• Python 3.10+
• west (ferramenta de meta-build do Zephyr)
• Zephyr SDK instalada
• Toolchain ARM embarcada funcional

Para validar rapidamente se o ambiente está correto, execute:

west --version

west --version

E depois:

west boards | grep due

west boards | grep due

Se o ambiente estiver correto, você verá a placa arduino_due listada entre as placas suportadas. Esse comando é extremamente importante: ele confirma que o Zephyr reconhece oficialmente o Arduino DUE no seu workspace.

4. Estrutura recomendada de workspace

Um erro comum entre iniciantes é misturar código de aplicação com o repositório do Zephyr. A abordagem correta é usar um workspace limpo, com a seguinte estrutura conceitual:

zephyr-workspace/
├── zephyr/              # Código-fonte do Zephyr RTOS
├── modules/             # Módulos externos (opcional)
├── bootloader/          # Bootloaders (opcional)
└── arduino_due_app/     # SUA aplicação

zephyr-workspace/
├── zephyr/              # Código-fonte do Zephyr RTOS
├── modules/             # Módulos externos (opcional)
├── bootloader/          # Bootloaders (opcional)
└── arduino_due_app/     # SUA aplicação

Dentro da pasta arduino_due_app, ficará apenas o código da aplicação, sem dependências diretas do kernel. Essa separação é crucial para manter o projeto sustentável e escalável.

5. Criando o projeto do zero para o Arduino DUE

Agora vamos criar efetivamente o projeto.

5.1 Criando o diretório da aplicação

mkdir arduino_due_app
cd arduino_due_app

mkdir arduino_due_app
cd arduino_due_app

5.2 Estrutura mínima de um projeto Zephyr

Crie a seguinte estrutura inicial:

arduino_due_app/
├── CMakeLists.txt
├── prj.conf
└── src/
    └── main.c

arduino_due_app/
├── CMakeLists.txt
├── prj.conf
└── src/
    └── main.c

Essa é a estrutura mínima obrigatória para qualquer aplicação Zephyr.

6. Arquivo CMakeLists.txt: integração com o Zephyr

Crie o arquivo CMakeLists.txt com o conteúdo:

cmake_minimum_required(VERSION 3.20.0)

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(arduino_due_app)

target_sources(app PRIVATE src/main.c)

cmake_minimum_required(VERSION 3.20.0)

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(arduino_due_app)

target_sources(app PRIVATE src/main.c)

O que esse arquivo faz, exatamente?

• cmake_minimum_required: garante compatibilidade mínima do CMake
• find_package(Zephyr ...): importa todo o sistema de build do Zephyr
• project(...): define o nome lógico do projeto
• target_sources(...): registra os arquivos C da aplicação

Aqui ocorre algo importante: você não define compilador, flags ou linker script. Tudo isso é herdado automaticamente da definição da placa (arduino_due) e do kernel.

7. Arquivo prj.conf: configuração do kernel (Kconfig)

O prj.conf controla quais partes do kernel Zephyr serão compiladas.

Comece com o mínimo funcional:

CONFIG_PRINTK=y
CONFIG_SERIAL=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y

CONFIG_PRINTK=y
CONFIG_SERIAL=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y

Essas opções habilitam:

• printk() – saída básica de debug
• Driver de porta serial
• Console padrão via UART

No Arduino DUE, isso será mapeado automaticamente para a UART correta definida no device tree da placa.

8. Arquivo main.c: primeira aplicação

Crie src/main.c:

#include <zephyr/kernel.h>
#include <zephyr/sys/printk.h>

int main(void)
{
    printk("Zephyr rodando no Arduino DUE!\n");

    while (1) {
        printk("Tick\n");
        k_sleep(K_SECONDS(1));
    }

    return 0;
}

#include <zephyr/kernel.h>
#include <zephyr/sys/printk.h>

int main(void)
{
    printk("Zephyr rodando no Arduino DUE!\n");

    while (1) {
        printk("Tick\n");
        k_sleep(K_SECONDS(1));
    }

    return 0;
}

Conceitos importantes aqui

• #include <zephyr/kernel.h>: acesso ao kernel, threads e temporização
• printk(): saída síncrona simples (não é printf)
• k_sleep(): API de temporização do kernel
• main() existe, mas não é o ponto de entrada real — o kernel já está inicializado antes dela ser chamada

9. Compilando o projeto para o Arduino DUE

Agora vem a parte crítica: build correto para a placa certa.

Dentro da pasta arduino_due_app:

west build -b arduino_due

west build -b arduino_due

O Zephyr irá:

1. Ler a definição da placa Arduino DUE
2. Selecionar o SoC SAM3X8E
3. Configurar clocks, memória e periféricos
4. Gerar o firmware final

Se tudo estiver correto, o build terminará sem erros.

10. Gravando o firmware no Arduino DUE

O Arduino DUE utiliza o bootloader SAM-BA, compatível com a ferramenta bossac.

Com a placa conectada via porta USB de programação, execute:

west flash

west flash

O Zephyr cuidará automaticamente do processo de gravação usando o método correto definido para a placa.

Após o reset, abra um terminal serial:

minicom -D /dev/ttyACM0 -b 115200

minicom -D /dev/ttyACM0 -b 115200

Você deverá ver:

Zephyr rodando no Arduino DUE!
Tick
Tick
Tick

Zephyr rodando no Arduino DUE!
Tick
Tick
Tick

11. Próximos passos

A partir daqui, você já tem:

• Um projeto Zephyr funcional
• Build e flash corretamente configurados
• Console serial ativo
• Base sólida para evoluir

Nos próximos artigos, podemos avançar para:

• Device Tree do Arduino DUE em detalhes
• GPIO e LEDs
• UARTs adicionais
• SPI e I²C
• Timers e interrupções
• Multithreading real no Cortex-M3

The post Criando um Projeto Zephyr RTOS no Arduino DUE – Guia Completo e Didático first appeared on MCU & FPGA.

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.

The post Arquitetura Orientada a Eventos no FreeRTOS first appeared on MCU & FPGA.

Se você é apaixonado por microcontroladores, FPGAs, sistemas embarcados, eletrônica digital, IoT, AIoT, protocolos industriais, processamento de sinais ou arquitetura de hardware, este é o seu lugar.

Criamos um espaço colaborativo no WhatsApp para reunir desenvolvedores, estudantes, pesquisadores e entusiastas que desejam evoluir juntos no universo de MCU e FPGA e todo o seu ecossistema — do firmware ao hardware, do bare-metal ao RTOS, do HDL ao edge computing.

Aqui você poderá:

• Trocar experiências práticas
• Tirar dúvidas técnicas
• Compartilhar projetos e artigos
• Discutir arquiteturas e boas práticas
• Conhecer novas ferramentas e tecnologias
• Expandir sua rede profissional

Nosso objetivo é construir uma comunidade técnica forte, colaborativa e orientada ao crescimento real.

Entre agora pelo link:
https://chat.whatsapp.com/BYXrqPHsRO5FTP7ap7X5yq

Se você acredita na força do conhecimento compartilhado, convide também seus amigos, colegas de trabalho e membros de outros grupos técnicos. Quanto mais mentes engajadas, mais rico será o aprendizado de todos.

Vamos fortalecer o ecossistema de MCU & FPGA juntos.

The post Participe em nossa comunidade no Whatsapp first appeared on MCU & FPGA.

Introdução: comunicação entre tarefas no FreeRTOS

Em sistemas embarcados baseados em Real-Time Operating Systems (RTOS), a comunicação entre tarefas (tasks) e entre interrupções (ISRs – Interrupt Service Routines) é um dos pilares da arquitetura de software. No FreeRTOS, essa comunicação pode ocorrer por diversos mecanismos: queues, semaphores, event groups, task notifications e, mais recentemente, stream buffers e message buffers. Cada um desses mecanismos foi projetado para atender a padrões específicos de troca de dados, com impactos diretos em desempenho, uso de memória, latência e complexidade do código.

Historicamente, as queues foram o principal mecanismo para troca de dados entre tarefas no FreeRTOS. Elas oferecem uma semântica clara, segura e genérica, permitindo o envio de estruturas de dados completas entre produtores e consumidores. No entanto, conforme sistemas embarcados passaram a lidar com fluxos contínuos de dados — como áudio, streams de sensores, bytes vindos de UART, SPI, USB ou stacks de rede —, tornou-se evidente que o modelo tradicional de queue não era o mais eficiente para esse tipo de cenário.

É nesse contexto que surgem os Stream Buffers, introduzidos para lidar com dados orientados a fluxo, onde o mais importante não é a fronteira entre mensagens, mas sim a sequência contínua de bytes. Diferentemente das queues, que operam com itens discretos e de tamanho fixo, os stream buffers operam como um buffer circular de bytes, permitindo escrita e leitura parcial, com controle fino sobre bloqueio, timeout e sincronização entre tarefas e ISRs.

Nesta série de artigos sobre FreeRTOS, esta seção tem como objetivo introduzir formalmente o conceito de stream buffers, posicioná-los corretamente dentro do ecossistema de mecanismos de comunicação do sistema operacional e preparar o terreno para uma comparação técnica aprofundada com queues. Ao longo das próximas seções, veremos como funcionam internamente, quando usá-los, quando evitá-los e como escrever código eficiente e seguro usando esse recurso.

The post FreeRTOS: Stream Buffers, comparação com Queues e critérios de escolha first appeared on MCU & FPGA.

Conteúdo Educacional e Técnico (Portais e Comunidades)

• Embarcados
  https://www.embarcados.com.br
  Principal portal brasileiro sobre sistemas embarcados, microcontroladores, RTOS, Linux embarcado e indústria. Excelente equilíbrio entre teoria, prática e mercado.
• MCU.TEC
  https://mcu.tec.br
  Conteúdo técnico aprofundado sobre microcontroladores, FPGA, RTOS, protocolos, eletrônica aplicada e integração com IA. Forte foco em didática e engenharia real.
• Microgenios
  https://www.microgenios.com.br
  Cursos, treinamentos e artigos focados em PIC, Arduino, ESP32 e IoT, com abordagem prática para iniciantes e intermediários.
• Instituto Newton C. Braga
  https://www.newtoncbraga.com.br
  Acervo clássico e extremamente vasto de eletrônica, incluindo microcontroladores, sensores, fontes e RF. Um verdadeiro repositório histórico-técnico.
• Vichinsky
  https://www.vichinsky.com
  Conteúdo técnico voltado a PIC (especialmente PIC18F2550), 8051 e Arduino, com exemplos diretos e foco em firmware bare-metal.
• All About Circuits
  https://www.allaboutcircuits.com
  Um dos melhores sites internacionais para eletrônica e microcontroladores, com artigos técnicos, fóruns e análises profundas.

Fabricantes e Documentação Oficial

• Microchip Technology
  https://www.microchip.com
  Documentação oficial de PIC, AVR (Atmel), SAM e ferramentas como MPLAB X. Fonte primária obrigatória para quem trabalha com PIC e AVR.
• STMicroelectronics
  https://www.st.com
  Referência absoluta para STM32, HAL, LL, CubeMX e ecossistema ARM Cortex-M e Cortex-A.
• NXP Semiconductors
  https://www.nxp.com
  Forte em microcontroladores industriais, automotivos, i.MX, LPC e segurança embarcada.
• Renesas Electronics
  https://www.renesas.com
  Destaque para famílias RA, RX e RZ, muito usadas em aplicações industriais e IoT avançado.
• Texas Instruments
  https://www.ti.com
  MSP430, Sitara, documentação exemplar e application notes de alto nível.

Lojas e Kits de Desenvolvimento (Brasil)

• AutoCore Robótica
  https://www.autocorerobotica.com.br
  Venda de microcontroladores, módulos ESP, sensores e kits educacionais.
• Baú da Eletrônica
  https://www.baudaeletronica.com.br
  Grande variedade de CIs, microcontroladores, ferramentas e componentes.
• ACEPIC Tecnologia
  https://www.acepic.com.br
  Especializada em kits, treinamentos e soluções educacionais para PIC, ESP32 e sistemas embarcados.

Plataformas de Pesquisa e Datasheets

• Octopart
  https://octopart.com
  Essencial para pesquisa de microcontroladores, comparação de preços, estoque global e acesso rápido a datasheets oficiais.
• Digi-Key
  https://www.digikey.com
  Além da loja, possui uma biblioteca técnica riquíssima (TechForum, artigos, vídeos).
• Mouser Electronics
  https://www.mouser.com
  Excelente para lançamentos recentes, application notes e kits de desenvolvimento.

The post Os Melhores Sites sobre Microcontroladores, Sistemas Embarcados e IoT em 2026 first appeared on MCU & FPGA.

Visão Geral: por que Máquina de Estados em Firmware “de verdade”

Em sistemas embarcados, a Máquina de Estados (Finite State Machine, FSM) não é só uma técnica de organização: ela é uma forma de tornar o comportamento previsível, rastreável e recuperável. Quando você está lidando com periféricos reais (UART, ADC, rádio, motores), o sistema não é “sequencial”; ele é reativo. Eventos chegam fora de hora, dados vêm incompletos, sensores falham, o usuário aperta botão no pior momento possível. A FSM é o mecanismo mais direto para modelar isso sem cair em “if-else infinito” ou em código que parece funcionar só em bancada.

O problema típico que vamos resolver neste artigo é este: como projetar um fluxo de controle cíclico (rodando continuamente) e recuperável (capaz de detectar falhas e voltar a um estado seguro) usando FreeRTOS, com duas threads cooperando: uma thread dona da lógica (controle por estados) e outra thread provedora de eventos/dados (E/S, aquisição, comunicação). A ideia é evitar dois extremos comuns: (1) uma thread monolítica que faz tudo e trava o sistema; (2) várias threads competindo por dados sem governança clara.

Para construir isso com rigor arquitetural, vamos “encaixar” a FSM dentro de padrões de projeto clássicos de tempo real: Active Object (um objeto/tarefa dona do seu próprio loop e fila), Message Queuing (fila de mensagens como fronteira limpa entre threads), e uma estratégia de ciclo + timeouts inspirada no raciocínio de padrões de concorrência e arquitetura para sistemas de tempo real (como discutido em catálogos de padrões para RTE systems). Na parte de robustez, vamos adicionar mecanismos de “recuperação” que não são mágicos: Watchdog lógico, Sanity Check (checagens de coerência), e uma política de degradação controlada (fallback para estado seguro).

No final, você terá um exemplo que dá para copiar para um projeto real: duas tasks do FreeRTOS, uma FSM explícita com transições bem definidas, eventos chegando por fila, timeouts, retentativas, e recuperação após erro — sem “gambiarras” como delays espalhados ou variáveis globais sem proteção.

The post Máquina de Estados em Sistemas Embarcados com FreeRTOS: Projeto Cíclico, Recuperável e Orientado a Eventos first appeared on MCU & FPGA.

Em sistemas de tempo real, especialmente aqueles baseados em FreeRTOS e Zephyr, o tempo não é apenas um detalhe de desempenho: ele é um requisito funcional. O conceito de WCET — Worst Case Execution Time representa o maior tempo possível que uma tarefa, função ou trecho de código pode levar para executar no pior cenário concebível, considerando hardware, compilador, arquitetura e contexto de execução. Diferentemente de métricas médias ou típicas, o WCET assume uma postura conservadora, fundamental para garantir que deadlines (prazos temporais) nunca sejam violados.

A motivação para o uso de WCET surge diretamente da natureza dos sistemas de tempo real hard, firm e soft. Em um sistema hard real-time, como controle de motores, proteção elétrica ou sistemas médicos, perder um deadline equivale a uma falha catastrófica. Já em sistemas firm ou soft real-time, como áudio, vídeo ou gateways industriais, a perda de prazo degrada a qualidade do serviço, mas ainda assim precisa ser controlada. Em todos esses casos, o escalonador do RTOS só consegue tomar decisões corretas se houver limites temporais bem definidos — e o WCET fornece exatamente esse limite superior.

Do ponto de vista prático, o WCET não é simplesmente “medir quanto tempo uma função levou para rodar”. Ele envolve compreender profundamente como o código interage com o pipeline do processador, memória flash e RAM, cache (quando existente), interrupções, preempção e até com o barramento interno do microcontrolador. Em arquiteturas Cortex-M típicas (M3, M4, M7, M33), fatores como wait states da flash, uso de FPU (Floating Point Unit), divisão inteira, acesso a periféricos mapeados em memória e presença de cache (especialmente no M7) influenciam diretamente o WCET. Em outras palavras: o WCET é uma propriedade do código + hardware + compilador, nunca apenas do código-fonte.

Dentro de um RTOS como FreeRTOS ou Zephyr, o WCET é a base para o dimensionamento correto das prioridades, definição de períodos de tarefas, análise de utilização da CPU e verificação de escalonabilidade. Sem WCET, o desenvolvedor trabalha “no escuro”, confiando em testes empíricos que podem falhar exatamente no cenário crítico — aquele que raramente ocorre, mas que precisa ser suportado. Por isso, em engenharia de sistemas embarcados sérios, o WCET não é um luxo acadêmico: ele é uma ferramenta de engenharia de risco.

Nesta série, vamos tratar o WCET de forma prática e aplicada, conectando teoria com exemplos reais em FreeRTOS e Zephyr. Veremos como estimar WCET por medição, por análise estática e por instrumentação, quais armadilhas devem ser evitadas em sistemas preemptivos e como o WCET se relaciona com conceitos como jitter, latência de interrupção, tempo de resposta e análise de escalonamento. Cada seção avançará um nível, sempre conectando o conceito ao código e ao comportamento real do sistema.

Seção 2 — WCET, Tempo Médio, Deadline, Jitter e Tempo de Resposta: colocando ordem no vocabulário

Antes de aplicar WCET na prática em FreeRTOS ou Zephyr, é essencial alinhar corretamente os conceitos temporais mais usados em sistemas de tempo real, pois é muito comum — inclusive em projetos profissionais — ver WCET sendo confundido com tempo médio de execução ou com deadline. Essa confusão leva a arquiteturas frágeis, que funcionam em bancada, mas falham em campo.

O tempo médio de execução representa quanto uma função ou tarefa normalmente leva para executar ao longo de várias medições. Ele é útil para análises de desempenho e otimização, mas não serve para garantir previsibilidade. Em um sistema embarcado sujeito a interrupções, preempções, variações de cache, acesso à flash e concorrência por barramentos, o tempo médio esconde os piores casos. O WCET, por definição, ignora completamente o comportamento típico e foca exclusivamente no pior cenário possível, mesmo que ele ocorra raramente.

O deadline é o prazo máximo permitido para que uma tarefa finalize sua execução ou produza um resultado válido. Ele é uma restrição do sistema, não uma propriedade do código. Uma tarefa pode ter um WCET de 800 µs e um deadline de 1 ms — nesse caso, ela é viável. Se o WCET ultrapassar o deadline, o sistema é intrinsecamente inviável, independentemente de prioridades ou otimizações no escalonador. Assim, o WCET é sempre comparado contra o deadline, nunca contra o tempo médio.

O tempo de resposta amplia a visão: ele mede o intervalo entre o evento que dispara a tarefa (por exemplo, uma interrupção ou liberação periódica) e o momento em que a tarefa efetivamente termina sua execução. Em sistemas preemptivos, esse tempo inclui não apenas o WCET da tarefa, mas também atrasos causados por tarefas de maior prioridade, seções críticas, interrupções mascaradas e latências do kernel. Em outras palavras, o tempo de resposta ≥ WCET, e a diferença entre eles revela o impacto do escalonamento.

Já o jitter representa a variação temporal entre execuções sucessivas. Em uma tarefa periódica ideal, o intervalo entre ativações seria constante. Na prática, interferências do sistema fazem com que esse intervalo oscile. Um WCET bem definido ajuda a limitar o jitter, mas não o elimina sozinho. Em aplicações como controle digital, aquisição de sinais e comunicação em tempo real, jitter excessivo pode ser tão prejudicial quanto perder um deadline, mesmo quando o WCET é respeitado.

A relação entre esses conceitos pode ser resumida da seguinte forma:
– O WCET define quanto tempo o código pode levar no pior caso.
– O deadline define quanto tempo o sistema permite.
– O tempo de resposta mostra o que realmente acontece em execução concorrente.
– O jitter mede a estabilidade temporal ao longo do tempo.

Em FreeRTOS e Zephyr, compreender essa distinção é crucial, pois ambos usam escalonamento preemptivo baseado em prioridades. Isso significa que um WCET aceitável isoladamente pode se tornar inviável quando combinado com outras tarefas de maior prioridade. É exatamente por isso que o WCET não deve ser analisado tarefa a tarefa de forma isolada, mas sim como parte de uma análise sistêmica.

Na próxima seção, entraremos no cerne da prática: como estimar e medir WCET em sistemas embarcados reais, discutindo abordagens por instrumentação, medição por hardware e análise estática, já conectando esses métodos ao uso em FreeRTOS e Zephyr.

Como estimar e medir WCET na prática: instrumentação, medição por hardware e análise estática

A determinação do WCET é um dos pontos mais delicados da engenharia de sistemas de tempo real, porque não existe um método único que sirva para todos os projetos. Na prática profissional, o WCET é obtido por uma combinação de técnicas, cada uma com vantagens, limitações e níveis distintos de confiabilidade. Em sistemas baseados em FreeRTOS e Zephyr, três abordagens são as mais utilizadas: instrumentação por software, medição por hardware e análise estática.

A instrumentação por software é a abordagem mais acessível e comum. Ela consiste em marcar pontos de início e fim de execução usando contadores de tempo fornecidos pelo próprio sistema, como o SysTick, timers de hardware ou contadores de ciclo da CPU. Em arquiteturas Cortex-M, o registrador DWT_CYCCNT (Data Watchpoint and Trace – Cycle Counter) é especialmente valioso, pois permite medir ciclos de clock com resolução de um ciclo. Ao instrumentar uma função ou tarefa, mede-se o tempo gasto em múltiplas execuções, sempre buscando forçar condições de pior caso: caminhos mais longos do código, dados extremos, máxima concorrência e maior número de interrupções. O maior valor observado é tratado como uma estimativa empírica do WCET.

O problema dessa abordagem é conceitual: ela não garante que o pior caso real foi observado. Se um caminho raro do código não foi exercitado, o WCET medido será otimista. Ainda assim, em projetos industriais, essa técnica é amplamente utilizada quando combinada com testes de estresse, fault injection e execução prolongada. Em FreeRTOS, por exemplo, é comum medir o tempo dentro da função da tarefa, excluindo deliberadamente chamadas bloqueantes como vTaskDelay(), pois o WCET se refere ao tempo ativo de CPU, não ao tempo total de vida da tarefa.

A medição por hardware adiciona uma camada extra de confiabilidade. Nessa abordagem, um GPIO é ativado no início da execução e desativado ao final, permitindo que um osciloscópio ou analisador lógico meça diretamente o tempo com alta precisão. Essa técnica elimina interferências do próprio código de medição e fornece uma visão clara do impacto de preempções e interrupções. Em sistemas com RTOS, o traço observado no pino revela visualmente se a tarefa foi interrompida, quantas vezes e por quanto tempo. Em Zephyr, essa técnica é frequentemente usada em conjunto com o subsistema de tracing, enquanto em FreeRTOS ela é comum em análises de validação temporal.

Mesmo assim, a medição por hardware continua sendo uma técnica observacional, não matemática. Ela mostra o que aconteceu, não tudo o que poderia acontecer. Por isso, em sistemas críticos, entra a terceira abordagem: a análise estática de WCET. Nessa técnica, ferramentas especializadas analisam o código compilado, constroem o grafo de fluxo de controle e calculam o tempo máximo considerando instruções, pipeline, cache e latências conhecidas do hardware. Esse método é o único que pode oferecer garantias formais, mas tem custo elevado, depende fortemente da previsibilidade da arquitetura e raramente é usado em microcontroladores com cache complexo ou execução fora de ordem.

Em projetos com FreeRTOS e Zephyr, a análise estática completa é pouco comum fora de domínios como aeroespacial e automotivo (ISO 26262, DO-178C). O que se pratica na maioria dos sistemas industriais é uma análise híbrida: estimativas por instrumentação, validação por hardware e margens de segurança explícitas. Por exemplo, se o maior tempo medido foi 420 µs, o WCET adotado pode ser 500 ou 600 µs, absorvendo incertezas do sistema.

É fundamental compreender que o WCET não é um número absoluto imutável. Ele muda quando se altera o nível de otimização do compilador, a versão do GCC/LLVM, a configuração de cache, o clock do sistema ou até o layout do linker. Por isso, WCET deve ser tratado como um artefato de engenharia, versionado junto com o firmware e reavaliado sempre que o sistema evoluir.

Na próxima seção, vamos conectar diretamente o WCET ao escalonamento em FreeRTOS e Zephyr, mostrando como ele impacta prioridades, utilização da CPU e análise de escalonabilidade, com exemplos práticos de tarefas concorrentes.

WCET aplicado ao escalonamento em FreeRTOS e Zephyr

Com o WCET estimado, o próximo passo — e talvez o mais importante — é usar esse valor para tomar decisões arquiteturais reais dentro do RTOS. Em FreeRTOS e Zephyr, o escalonamento é preemptivo e baseado em prioridades, o que significa que o comportamento temporal do sistema não depende apenas do WCET de uma tarefa isolada, mas da interação entre todas as tarefas, ISRs e seções críticas.

O primeiro conceito-chave aqui é a utilização da CPU. Para tarefas periódicas, a utilização pode ser aproximada por:

\[
U = \sum_{i=1}^{n} \frac{WCET_i}{T_i}
\]

onde (WCET_i) é o pior tempo de execução da tarefa (i) e (T_i) é seu período. Em sistemas simples, se a soma das utilizações se aproxima ou ultrapassa 100%, o sistema se torna inviável. Em sistemas preemptivos reais, o limite prático costuma ser menor, pois é preciso considerar overhead do kernel, trocas de contexto, latência de interrupção e tempo gasto em ISRs.

No FreeRTOS, cada tarefa executa até ser bloqueada, preemptada por uma tarefa de maior prioridade ou voluntariamente ceder a CPU. Se uma tarefa de baixa prioridade possui um WCET elevado, ela pode atrasar significativamente tarefas de prioridade intermediária, criando efeitos indiretos difíceis de perceber sem uma análise baseada em WCET. É por isso que tarefas com WCET alto tendem a ser:
– quebradas em subtarefas menores,
– convertidas em tarefas cooperativas com pontos de bloqueio bem definidos, ou
– executadas em janelas temporais controladas.

No Zephyr, embora o modelo seja semelhante, há diferenças importantes. O kernel oferece tanto threads preemptivas quanto cooperativas, além de um sistema de prioridades mais explícito. Threads cooperativas, por definição, não sofrem preempção, o que significa que seu WCET deve ser extremamente bem conhecido e limitado. Um erro aqui pode bloquear completamente o sistema. Já threads preemptivas exigem uma análise cuidadosa do tempo de resposta, pois o WCET da thread inclui apenas o tempo ativo, mas o tempo até completar depende de quantas threads de maior prioridade podem interferir.

Outro ponto crítico é a relação entre WCET de tarefas e WCET de ISRs. Em ambos os RTOS, interrupções têm precedência sobre tarefas. Se uma ISR executa código excessivo, seu WCET se soma indiretamente ao tempo de resposta de todas as tarefas. Boas práticas determinam que ISRs sejam curtas e que o processamento pesado seja delegado a deferred execution (queues, workqueues, task notifications). Do ponto de vista temporal, isso transforma um WCET difícil de controlar (ISR) em um WCET analisável (tarefa).

A análise de tempo de resposta fecha o ciclo. Para uma tarefa (i), o pior tempo de resposta pode ser aproximado como:

\[
R_i = WCET_i + \sum_{j \in hp(i)} \left\lceil \frac{R_i}{T_j} \right\rceil WCET_j
\]

onde (hp(i)) são as tarefas de prioridade maior. Essa equação deixa claro por que WCET é a base de tudo: sem ele, não há como prever se uma tarefa cumprirá seu deadline em um ambiente concorrente.

Na prática, muitos sistemas embarcados falham não por falta de CPU, mas por falta de análise temporal. O código “funciona”, mas em uma combinação específica de eventos — uma ISR frequente, uma tarefa longa, um pico de comunicação — os deadlines são perdidos. O uso sistemático de WCET permite identificar esses cenários ainda na fase de projeto.

Na próxima seção, vamos tratar dos principais erros e armadilhas ao trabalhar com WCET em FreeRTOS e Zephyr, incluindo cache, otimizações do compilador, chamadas bloqueantes e falsas suposições comuns em projetos embarcados.

Armadilhas comuns no uso de WCET em sistemas com FreeRTOS e Zephyr

Mesmo quando o desenvolvedor conhece o conceito de WCET, muitos sistemas falham por aplicar o conceito de forma incompleta ou ingênua. Em RTOS modernos como FreeRTOS e Zephyr, há diversas armadilhas que distorcem a análise temporal e levam a estimativas perigosamente otimistas. Entender essas armadilhas é tão importante quanto saber calcular o WCET em si.

Uma das mais comuns está relacionada às otimizações do compilador. Alterar o nível de otimização (-O0, -O2, -Os) pode mudar drasticamente o WCET, não apenas reduzindo o tempo médio, mas também alterando o pior caminho de execução. Loops desenrolados, inlining agressivo e reordenação de instruções afetam pipeline e uso de cache. Um WCET medido em debug raramente é válido para release. Por isso, WCET deve ser sempre analisado no binário final, com as mesmas flags, linker script e layout de memória que serão usados em produção.

Outra armadilha crítica envolve cache e memória flash. Em microcontroladores como Cortex-M7, o acesso à flash pode ter wait states, enquanto dados em RAM ou cache executam muito mais rápido. O pior caso ocorre frequentemente quando o cache está frio ou sofre thrashing. Um teste que mede WCET com o sistema “aquecido” pode subestimar o pior cenário. Em Zephyr, onde o sistema é mais modular e pode carregar mais código em execução, esse efeito é ainda mais pronunciado. Para sistemas críticos, é comum desabilitar cache para código crítico ou fixar rotinas em RAM para tornar o WCET mais previsível.

Chamadas bloqueantes são outra fonte clássica de erro conceitual. Funções como vTaskDelay(), xQueueReceive() ou k_sem_take() não fazem parte do WCET, pois o WCET mede apenas tempo ativo de CPU. Misturar tempo de bloqueio com tempo de execução leva a conclusões erradas, como superestimar a carga da CPU ou mascarar gargalos reais. Em análises sérias, o WCET da tarefa é separado do seu comportamento de sincronização.

Há também o problema das seções críticas e mutexes. Quando uma tarefa entra em uma seção crítica longa ou segura um mutex por muito tempo, ela indiretamente aumenta o WCET efetivo de outras tarefas que dependem desse recurso. Isso não aparece em uma análise isolada da tarefa, mas emerge claramente quando se analisa o sistema como um todo. FreeRTOS oferece mecanismos como priority inheritance, mas isso não elimina o impacto temporal; apenas evita inversão de prioridade não controlada.

Uma armadilha frequentemente ignorada é o WCET do próprio kernel. Trocas de contexto, manipulação de listas, temporizadores de software e tratamento de tick consomem tempo. Em sistemas com alta taxa de ticks ou muitos timers ativos, esse overhead se acumula. Zephyr, por exemplo, permite tickless kernel, o que reduz interferências temporais — mas altera completamente o perfil de WCET. Ignorar esse efeito pode levar a análises excessivamente otimistas.

Por fim, talvez o erro mais perigoso seja tratar WCET como um número fixo e eterno. Qualquer alteração no sistema — novo driver, nova tarefa, mudança no clock, atualização do RTOS — invalida a análise anterior. WCET deve ser revisto continuamente, como parte do processo de engenharia, e não como uma etapa pontual do projeto.

Na próxima e última seção, faremos um fechamento prático, conectando WCET a boas práticas de projeto, checklist de validação e recomendações específicas para quem trabalha com FreeRTOS e Zephyr em sistemas reais.

Seção 6 — Boas práticas, checklist de engenharia e fechamento

Após compreender o conceito, as técnicas de medição e as armadilhas do WCET, o ponto central passa a ser como incorporar o WCET no dia a dia do projeto, de forma sistemática e sustentável. Em sistemas com FreeRTOS e Zephyr, o WCET não deve ser tratado como um artefato acadêmico isolado, mas como um parâmetro de engenharia tão importante quanto consumo de memória, corrente ou clock.

Uma boa prática fundamental é projetar tarefas pequenas e coesas, com responsabilidades bem delimitadas. Tarefas monolíticas tendem a ter WCET alto, difícil de medir e ainda mais difícil de justificar. Quando o processamento é naturalmente longo, a divisão em fases — com pontos claros de bloqueio ou sincronização — permite reduzir o WCET individual e melhorar drasticamente a previsibilidade do sistema. Esse estilo de projeto se alinha naturalmente com arquiteturas orientadas a eventos, amplamente usadas tanto em FreeRTOS quanto em Zephyr.

Outra prática essencial é classificar tarefas por criticidade temporal. Nem todas precisam de análise rigorosa de WCET. Tarefas de controle, aquisição de sinais, comunicação em tempo real e segurança devem ter WCET explícito, revisado e documentado. Tarefas de logging, interface de usuário ou manutenção podem operar com margens mais flexíveis. Essa separação evita desperdício de esforço e reduz a complexidade da análise global.

Do ponto de vista operacional, é altamente recomendável manter um registro formal de WCET no projeto. Esse registro deve indicar: versão do firmware, hardware alvo, clock, compilador, flags de otimização, método de medição e margem aplicada. Em projetos profissionais, esse documento evolui junto com o código. Sempre que uma tarefa crítica é modificada, seu WCET precisa ser reavaliado. Essa disciplina simples evita uma das causas mais comuns de falhas temporais em campo: a degradação silenciosa do comportamento em tempo real ao longo das versões.

Um checklist prático para validação de WCET em FreeRTOS e Zephyr inclui:
– O WCET foi medido no binário final de produção?
– O pior caminho lógico do código foi exercitado?
– ISRs têm WCET mínimo e processamento delegado?
– Seções críticas são curtas e bem justificadas?
– O impacto do kernel e do tick foi considerado?
– Há margem explícita entre WCET e deadline?
– O WCET foi revisado após mudanças no sistema?

Por fim, é importante destacar uma visão crítica: RTOS não resolvem problemas temporais sozinhos. FreeRTOS e Zephyr fornecem mecanismos poderosos de escalonamento, sincronização e temporização, mas a previsibilidade nasce da engenharia do software, não do kernel. Projetos que ignoram WCET acabam funcionando “por sorte”, até que um cenário extremo revele falhas difíceis de reproduzir e ainda mais difíceis de corrigir.

Encerrando este artigo, a mensagem central é clara: WCET é a ponte entre código e tempo. Ele transforma sistemas embarcados de “funcionam na média” em sistemas confiáveis no pior caso, que é exatamente onde sistemas de tempo real precisam funcionar.

Material para SEO

Título do artigo
WCET em Sistemas de Tempo Real: Aplicação Prática no FreeRTOS e Zephyr

Frase-chave foco

Meta descrição (≥ 600 caracteres)

Lista de palavras-chave

The post WCET (Worst Case Execution Time) em FreeRTOS e Zephyr first appeared on MCU & FPGA.

A aplicação Nx_WebServer é um exemplo prático que demonstra como construir um servidor web embarcado utilizando o Azure RTOS NetX Duo em conjunto com a placa STM32F429ZI-Nucleo. Esse exemplo é particularmente útil porque reúne, em um único projeto, conceitos fundamentais de sistemas embarcados modernos: uso de um RTOS (Sistema Operacional de Tempo Real), pilha de rede embarcada, sistema de arquivos em memória flash e a disponibilização de serviços através de um WebServer HTTP.

Para um iniciante, pode ser difícil compreender como tudo isso se conecta, por isso este artigo tem como objetivo explicar, de forma didática e detalhada, cada uma das etapas e conceitos envolvidos. Além de mostrar como carregar e executar o exemplo, também apresentaremos os fundamentos do que é o NetX Duo, o papel de um servidor HTTP e por que ferramentas como o STM32CubeProgrammer devem ser usadas corretamente — inclusive pela linha de comando — para garantir 100% de sucesso na gravação do conteúdo.

No decorrer do artigo, você aprenderá:

• O que é o Azure RTOS NetX Duo e por que ele é utilizado neste projeto.
• Como funciona um servidor HTTP embarcado e qual a diferença entre páginas estáticas e dinâmicas.
• O papel das threads criadas no exemplo (AppMainThread e AppWebServerThread).
• A importância da correta preparação da memória flash, incluindo a gravação do arquivo de conteúdo web.
• Como interpretar os comportamentos esperados e os sinais de erro durante a execução.
• Dicas para iniciantes compreenderem como o RTOS gerencia recursos como memória, temporização e comunicação de rede.

A partir dessa visão, mesmo um leitor leigo poderá entender como uma simples placa de desenvolvimento pode se transformar em um servidor web funcional, capaz de exibir páginas HTML diretamente de sua memória interna e até mesmo interagir com o usuário, por exemplo, acionando o LED verde da placa através de um navegador.

O que é o Azure RTOS NetX Duo e sua Função no Projeto

Para compreender o funcionamento do Nx_WebServer, é essencial primeiro entender o que é o Azure RTOS NetX Duo. Trata-se de uma pilha de protocolos de rede TCP/IP projetada especificamente para sistemas embarcados. Diferente de sistemas operacionais completos, como Linux ou Windows, em que a pilha de rede já faz parte do núcleo, no mundo dos microcontroladores é necessário integrar uma biblioteca que permita ao dispositivo se comunicar em redes Ethernet ou Wi-Fi.

O NetX Duo é chamado de “Duo” porque implementa tanto o IPv4 quanto o IPv6, garantindo compatibilidade com redes atuais e futuras. Ele é otimizado para rodar em dispositivos com recursos limitados, como microcontroladores STM32, oferecendo:

• Baixo consumo de memória e processamento
• Confiabilidade em tempo real, essencial em aplicações críticas
• Escalabilidade, permitindo adicionar ou remover recursos de acordo com a necessidade

Dentro do projeto Nx_WebServer, o NetX Duo é responsável por todo o gerenciamento da comunicação em rede. É ele quem:

• Cria e administra a instância de IP (NX_IP) usada pela placa.
• Configura protocolos de suporte, como ARP (Address Resolution Protocol), ICMP (Internet Control Message Protocol), UDP e TCP.
• Controla o cliente DHCP, que negocia automaticamente um endereço IP com o roteador ou servidor da rede local.

Em outras palavras, sem o NetX Duo, a placa STM32 não conseguiria sequer obter um endereço IP para se comunicar na rede. Ele funciona como a “cola” que conecta o hardware da placa ao mundo da Internet.

Um aspecto importante é que o NetX Duo foi projetado para rodar em conjunto com o ThreadX, o RTOS (Real-Time Operating System) do qual falaremos mais adiante. Essa integração é fundamental porque permite que tarefas de rede sejam executadas de forma concorrente, sem travar outras funções do sistema. Por exemplo, enquanto o servidor HTTP responde a uma requisição de página, outras threads podem continuar monitorando sensores, gravando em memória ou atualizando o display.

Em resumo:
O NetX Duo é o coração da conectividade de rede neste exemplo. Ele transforma o STM32 em um dispositivo capaz de se comportar como qualquer outro nó de rede, participando de trocas de pacotes, comunicação cliente-servidor e, especificamente, como servidor HTTP embarcado.

O que é um Servidor HTTP Embarcado e Como Funciona no STM32

Um servidor HTTP é um programa capaz de responder a requisições feitas por um navegador (como Google Chrome, Firefox ou Edge). Quando digitamos um endereço como http://192.168.0.10/index.html, o navegador envia uma solicitação (request) ao servidor, que responde com o arquivo correspondente (response), normalmente uma página em formato HTML.

No mundo dos computadores convencionais, esses servidores costumam ser softwares robustos como Apache, Nginx ou IIS, rodando em máquinas com sistemas operacionais completos. Porém, em sistemas embarcados como o STM32F429ZI, a situação é diferente: o servidor precisa ser leve, rápido e econômico em memória, ao mesmo tempo em que oferece funcionalidades básicas para interação com o usuário.

O Nx_WebServer mostra exatamente isso: como transformar a placa STM32 em um servidor web simples, mas funcional. No exemplo:

• Os arquivos HTML, imagens ou scripts são gravados diretamente na memória flash do microcontrolador.
• O servidor HTTP, criado com a biblioteca do NetX Duo, responde a requisições de navegadores conectados à mesma rede.
• Páginas como index.html e dashboard.html podem ser acessadas digitando o IP da placa no navegador.

Páginas Estáticas e Dinâmicas

Um ponto importante é a diferença entre páginas estáticas e páginas dinâmicas:

• Estáticas: São arquivos prontos, como index.html, que apenas exibem informações fixas (texto, imagens).
• Dinâmicas: São geradas ou modificadas em tempo real pelo servidor. No exemplo do Nx_WebServer, a página dashboard.html é dinâmica, porque permite interagir com a placa – o usuário pode, por exemplo, clicar em um botão para acender ou apagar o LED verde da Nucleo, e a ação é refletida imediatamente no hardware.

Threads no Servidor

O servidor HTTP embarcado funciona através de threads criadas pelo RTOS ThreadX:

• A AppMainThread inicia a rede, aguarda a obtenção de um endereço IP via DHCP e, quando tudo está pronto, libera a execução do servidor.
• A AppWebServerThread é responsável por abrir o sistema de arquivos na flash e iniciar o servidor HTTP.

Essa separação é essencial porque permite que o sistema seja multitarefa, garantindo que cada função (rede, servidor, controle de LED, etc.) tenha o seu espaço de execução ordenado pelo RTOS.

Benefício para o Usuário

Na prática, o que o usuário vê é simples:

1. Conecta a placa à rede.
2. Descobre o endereço IP no terminal serial.
3. Digita esse IP no navegador.
4. Visualiza páginas hospedadas dentro do próprio microcontrolador.

Isso transforma o STM32F429ZI em um servidor web portátil e independente, sem precisar de um computador externo para entregar as páginas.

O Papel das Threads AppMainThread e AppWebServerThread

O funcionamento do Nx_WebServer depende diretamente da coordenação entre duas threads principais criadas pelo ThreadX, o sistema operacional de tempo real que organiza a execução das tarefas. Essas threads são como “linhas de trabalho” independentes que, juntas, mantêm a aplicação em funcionamento estável e responsivo.

AppMainThread – Inicialização e Rede

A primeira thread criada é a AppMainThread, responsável por preparar o ambiente de rede e dar início ao funcionamento do sistema. Ela é configurada para iniciar automaticamente assim que o kernel do ThreadX é carregado.

Dentro dessa thread, as principais ações realizadas são:

1. Inicialização do cliente DHCP – permite que a placa obtenha automaticamente um endereço IP da rede local, evitando a necessidade de configurar manualmente.
2. Aguardando resolução de IP – a thread permanece em espera até que o endereço IP seja corretamente atribuído. Esse passo é essencial, pois sem IP não há comunicação de rede possível.
3. Ativação da AppWebServerThread – quando a rede está pronta, a AppMainThread “acorda” a thread do servidor web, garantindo que o HTTP Server só comece a funcionar quando a conectividade estiver estabelecida.

Em resumo, a AppMainThread é responsável pela fase de configuração e preparação da rede, funcionando como um “porteiro” que só libera o servidor quando tudo está em ordem.

AppWebServerThread – O Servidor HTTP

A segunda thread, chamada AppWebServerThread, é criada mas não inicia de imediato. Ela depende da autorização da AppMainThread para começar, respeitando a ordem correta de inicialização.

As funções principais dessa thread são:

1. Abrir o driver da memória flash – é nessa memória que os arquivos HTML e outros conteúdos foram gravados previamente, como veremos mais adiante.
2. Iniciar o servidor HTTP – cria a instância do servidor e começa a escutar por requisições vindas dos navegadores.
3. Processar requisições – cada vez que um cliente acessa uma página (index.html, dashboard.html, etc.), a requisição é passada para o webserver_request_notify_callback, que decide como responder.
   • Se o arquivo for estático (como index.html), o conteúdo é apenas enviado de volta.
   • Se for dinâmico (como no caso do controle do LED), a resposta é adaptada ao comando solicitado.

Assim, a AppWebServerThread é o coração da aplicação, transformando a placa em um servidor funcional que pode ser acessado de qualquer navegador da rede local.

Coordenação entre as Threads

A separação em duas threads garante que a aplicação seja robusta e modular:

• Uma thread cuida da rede e inicialização.
• A outra cuida do servidor HTTP.

Essa divisão evita erros comuns em sistemas embarcados, como tentar iniciar um serviço de rede antes de ter um endereço IP válido. Além disso, permite que cada parte do sistema seja ajustada ou expandida no futuro sem comprometer o funcionamento das demais.

Preparando a Memória Flash com o STM32CubeProgrammer

Um dos pontos mais importantes para o funcionamento do Nx_WebServer é garantir que os arquivos web (páginas HTML, imagens e scripts) estejam gravados corretamente na memória flash do STM32F429ZI. Sem esse passo, mesmo que o servidor HTTP seja iniciado com sucesso, não haverá conteúdo para enviar ao navegador.

O papel do STM32CubeProgrammer

O STM32CubeProgrammer é a ferramenta oficial da STMicroelectronics para gravação de firmwares, configuração de memória e depuração básica em microcontroladores STM32. Embora ele possua uma interface gráfica, no caso do Nx_WebServer a recomendação é utilizar a linha de comando.

Isso porque a execução via CLI (Command Line Interface) garante:

1. Precisão absoluta no endereço de gravação – evita erros ao selecionar o ponto inicial da memória flash.
2. Automação – o mesmo comando pode ser repetido sempre que necessário, sem depender de cliques manuais.
3. Compatibilidade com tutoriais e exemplos – a própria ST fornece os comandos prontos para uso, facilitando a reprodução dos resultados.

O comando essencial

Para gravar o conteúdo web na memória flash, deve-se executar no terminal:

<INSTALL_PATH>STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe -c port=swd -w <INSTALL_PATH>web_content\web_demo.bin 0x08100000 -v

Explicando cada parte:

• <INSTALL_PATH> → caminho onde o STM32CubeProgrammer foi instalado.
• STM32_Programmer_CLI.exe → executável da versão de linha de comando.
• -c port=swd → indica que a conexão com a placa será feita via SWD (Serial Wire Debug), o protocolo padrão para gravação em STM32.
• -w <arquivo> <endereço> → grava o arquivo binário especificado no endereço de memória desejado.
  • <arquivo> → no caso, web_demo.bin, que contém as páginas web.
  • <endereço> → 0x08100000, local da flash reservado para armazenar os arquivos web.
• -v → ativa a verificação após a gravação, garantindo que o conteúdo foi escrito corretamente.

Importância de seguir o processo corretamente

Muitos erros relatados por iniciantes acontecem porque:

• O arquivo binário não foi gravado no endereço correto.
• A gravação foi feita apenas pelo IDE, sem incluir os arquivos web.
• Não houve a etapa de verificação após a gravação.

Por isso, insistimos: use sempre o STM32CubeProgrammer pela linha de comando, como mostrado acima, para garantir 100% de sucesso.

Ao final dessa etapa, a memória flash da placa conterá não apenas o firmware principal, mas também o sistema de arquivos com as páginas HTML. Isso permite que, ao digitar o IP da placa no navegador, o conteúdo seja carregado corretamente.

Comportamentos Esperados e Sinais de Erro

Depois de gravar corretamente o firmware e o conteúdo web na memória flash do STM32F429ZI, é importante saber o que observar para confirmar que tudo está funcionando como deveria. O projeto Nx_WebServer foi projetado para dar ao usuário indicações claras de sucesso ou falha, tanto pelo terminal serial quanto pelos LEDs da placa.

Comportamento de Sucesso

Quando o servidor HTTP é iniciado com sucesso, os seguintes sinais aparecem:

1. Endereço IP exibido no terminal
   • Assim que o DHCP atribui um IP válido à placa, o endereço é mostrado na saída serial.
   • Exemplo: Board IP address: 192.168.0.105
   • Esse é o endereço que você deve digitar no navegador.
2. Páginas acessíveis via navegador
   • Ao abrir o navegador e digitar http://<IP>/index.html, a página inicial deve ser carregada.
   • Ao acessar http://<IP>/dashboard.html, você verá a página de controle.
3. Interação com a placa
   • Na página dashboard, é possível interagir com a placa, por exemplo, ligando ou desligando o LED verde.
   • Também são exibidas informações do ThreadX e do NetX Duo, demonstrando a integração entre o RTOS e a pilha de rede.

Esses três sinais confirmam que todo o sistema – firmware, pilha de rede, servidor HTTP e arquivos web – está funcionando corretamente.

Comportamento de Erro

Caso algo não tenha sido configurado ou gravado corretamente, os sintomas mais comuns são:

1. LED verde apagado
   • Se o servidor HTTP não foi inicializado corretamente, o LED verde da placa permanece desligado.
   • Esse é o sinal mais direto de falha na execução.
2. Páginas não carregam no navegador
   • Se ao digitar o IP no navegador não houver resposta, pode significar:
     • O arquivo web_demo.bin não foi gravado no endereço correto (0x08100000).
     • O servidor HTTP não foi inicializado.
     • A rede não atribuiu um IP válido à placa (falha do DHCP).
3. Mensagens de erro no terminal
   • Algumas falhas podem ser identificadas nas mensagens exibidas pela porta serial, como erro ao abrir a flash ou falha na inicialização do servidor.

A importância dos testes iniciais

Esses sinais de sucesso ou falha servem como guia rápido para depuração. Se algo não estiver funcionando, a primeira verificação deve ser:

• O firmware foi carregado corretamente?
• O arquivo web_demo.bin foi gravado no endereço exato?
• A placa obteve um endereço IP válido da rede?
• O LED verde indicou o estado esperado?

Com essas checagens simples, mesmo um usuário iniciante consegue identificar o que precisa ser corrigido.

Ajustes e Dicas de Uso do ThreadX

O ThreadX é o sistema operacional de tempo real (RTOS) utilizado no projeto Nx_WebServer. Ele é responsável por organizar a execução das threads, gerenciar recursos de memória e garantir que as tarefas mais críticas recebam atenção no momento certo. Para que a aplicação funcione corretamente e seja expansível, é necessário conhecer alguns detalhes importantes sobre seu funcionamento.

O Tempo Base do Sistema

O ThreadX utiliza o SysTick (um temporizador do processador ARM Cortex-M) como sua referência de tempo. Isso significa que:

• Por padrão, o ThreadX é configurado com 100 ticks por segundo, ou seja, cada tick equivale a 10 ms.
• Esse valor impacta diretamente chamadas de espera (sleep, timeout) dentro do sistema.
• Caso o desenvolvedor deseje alterar essa taxa, é necessário modificar o arquivo tx_user.h, ajustando o valor TX_TIMER_TICKS_PER_SECOND.

É importante manter consistência: ao alterar esse parâmetro, deve-se também atualizar o arquivo de inicialização em assembly (tx_initialize_low_level.s), garantindo que o tempo do kernel e o tempo real estejam alinhados.

Cuidados Durante a Inicialização

Durante o processo de inicialização do kernel, o ThreadX desabilita todas as interrupções para evitar comportamentos inesperados. Isso significa que chamadas a funções de hardware (como HAL ou BSP) não devem ser feitas diretamente dentro da função tx_application_define().

Essa função deve ser utilizada apenas para criar recursos do ThreadX, como:

• Threads
• Semáforos
• Filas de mensagens
• Memórias pool

Qualquer chamada ao hardware deve ser feita dentro das threads de aplicação, depois que o sistema já está em execução.

Memória Dinâmica e Linker Script

Outro ponto importante é a memória utilizada pelo ThreadX. Quando se opta por usar alocação dinâmica, o RTOS precisa receber um ponteiro para a primeira região de memória livre em RAM. Para isso, o arquivo de linkagem deve ser ajustado:

• No STM32CubeIDE: adicionar uma nova seção no linker script (.ld), como no exemplo:

._threadx_heap : 
{
  . = ALIGN(8); 
  __RAM_segment_used_end__ = .; 
  . = . + 64K; 
  . = ALIGN(8); 
} >RAM_D1 AT> RAM_D1

._threadx_heap : 
{
  . = ALIGN(8); 
  __RAM_segment_used_end__ = .; 
  . = . + 64K; 
  . = ALIGN(8); 
} >RAM_D1 AT> RAM_D1

Nesse caso, foi reservado um heap de 64 KB para o ThreadX.

• O local dessa seção deve ficar entre .bss e ._user_heap_stack, para evitar conflitos de memória.
• O arquivo tx_initialize_low_level.s também deve ser modificado para habilitar o uso de memória dinâmica, ativando a flag USE_DYNAMIC_MEMORY_ALLOCATION.

Essas alterações garantem que o RTOS tenha uma área de memória segura para alocação de objetos e buffers durante a execução da aplicação.

Por que isso é importante?

Sem os ajustes corretos, a aplicação pode apresentar falhas sutis, como:

• Travamentos aleatórios
• Falta de memória para criar threads adicionais
• Erros no uso de timers ou timeouts

Ao entender como o ThreadX organiza o tempo e a memória, o desenvolvedor ganha maior controle sobre a aplicação e evita problemas difíceis de rastrear.

Ambiente de Hardware e Software Necessário

Para executar o projeto Nx_WebServer com sucesso, é fundamental preparar tanto o hardware quanto o software de forma adequada. Essa preparação garante que a aplicação rode sem problemas e que o usuário consiga acompanhar os logs e testar o servidor HTTP de forma prática.

Hardware Utilizado

O exemplo foi desenvolvido e validado especificamente para a placa:

• STM32F429ZI-Nucleo (referência MB1137 B-01).

Características relevantes dessa placa:

• Microcontrolador STM32F429ZI com núcleo ARM Cortex-M4.
• Conector Ethernet disponível para integração em rede local.
• LEDs e botões de usuário, que podem ser usados para testes interativos (ex.: acender o LED verde via navegador).
• Interface ST-LINK integrada, que permite gravação e depuração sem a necessidade de ferramentas adicionais.

Embora o exemplo seja voltado para essa placa, ele pode ser adaptado a outros microcontroladores STM32 compatíveis, desde que possuam recursos de rede e memória flash suficientes.

Comunicação Serial

Durante a execução, a placa envia informações pela interface USART3, que serve como um terminal de depuração. Para visualizar essas informações, é necessário conectar a placa a um computador via USB e abrir um terminal serial (como PuTTY, Tera Term ou o terminal do STM32CubeIDE).

A configuração correta da porta serial é:

• Baud Rate: 115200
• Word Length: 8 bits
• Stop Bit: 1
• Paridade: Nenhuma (None)
• Controle de fluxo: Nenhum

Esses parâmetros garantem que as mensagens (como o endereço IP atribuído pelo DHCP) sejam exibidas de forma legível.

Software Necessário

1. STM32CubeIDE ou outra ferramenta de compilação suportada.
   • Responsável por compilar e carregar o firmware do projeto.
2. STM32CubeProgrammer
   • Usado para gravar o arquivo de conteúdo web (web_demo.bin) na memória flash.
   • Recomenda-se utilizar a versão CLI (linha de comando), como explicado na seção anterior.
3. Navegador Web (Chrome, Firefox, Edge ou outro).
   • Necessário para acessar as páginas hospedadas pelo microcontrolador.
4. Cliente de terminal serial
   • Permite monitorar mensagens da aplicação em tempo real.

Ambiente de Rede

A placa precisa estar conectada a uma rede local com acesso a um servidor DHCP (geralmente fornecido pelo roteador doméstico ou corporativo). Sem DHCP, será necessário configurar manualmente o endereço IP no código.

Com esse ambiente devidamente configurado, o usuário terá todos os recursos para compilar, gravar e executar o projeto, podendo visualizar tanto o funcionamento interno pelo terminal quanto o acesso externo via navegador.

Passo a Passo para Colocar a Aplicação em Funcionamento

Agora que já entendemos os conceitos fundamentais, os recursos do RTOS e a configuração de hardware e software, podemos partir para o guia prático de execução do projeto Nx_WebServer. A seguir está o passo a passo completo para que até um iniciante consiga reproduzir o funcionamento do servidor web embarcado.

1. Preparar o Projeto

Abra sua IDE favorita (recomendado STM32CubeIDE) e carregue o projeto de exemplo do Nx_WebServer. Esse projeto já vem configurado para a placa STM32F429ZI-Nucleo, facilitando a compilação.

Compile o código para gerar o binário do firmware principal.

2. Gravar o Conteúdo Web na Flash

Além do firmware, é necessário gravar os arquivos web que serão servidos pelo microcontrolador. Esses arquivos estão reunidos em um binário chamado web_demo.bin.

Use o STM32CubeProgrammer (CLI) e execute o seguinte comando no terminal:

<INSTALL_PATH>STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe -c port=swd -w <INSTALL_PATH>web_content\web_demo.bin 0x08100000 -v

<INSTALL_PATH>STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe -c port=swd -w <INSTALL_PATH>web_content\web_demo.bin 0x08100000 -v

• Esse comando grava o conteúdo na memória flash a partir do endereço 0x08100000.
• O parâmetro -v garante a verificação, confirmando que os dados foram gravados corretamente.

Atenção: Esse passo é obrigatório. Sem os arquivos web na flash, o servidor não terá páginas para enviar ao navegador.

3. Carregar o Firmware

Com o conteúdo web gravado, volte para a IDE e carregue o firmware do projeto Nx_WebServer na placa STM32F429ZI. Esse firmware contém toda a lógica do RTOS, do NetX Duo e do servidor HTTP.

4. Conectar à Rede

Ligue a placa à rede local usando o cabo Ethernet. Certifique-se de que o roteador ou switch forneça endereços IP via DHCP.

5. Monitorar a Porta Serial

Abra um terminal serial no computador, configurado da seguinte forma:

• Baud Rate: 115200
• 8 bits de dados, 1 stop bit, sem paridade, sem controle de fluxo.

Ao inicializar, a placa exibirá mensagens no terminal, incluindo o endereço IP atribuído pelo DHCP.

Exemplo:

Board IP address: 192.168.0.105

Board IP address: 192.168.0.105

6. Acessar pelo Navegador

No computador conectado à mesma rede, abra o navegador e digite o endereço IP informado no terminal:

• Para a página inicial: http://<IP>/index.html
• Para a página de controle (dashboard): http://<IP>/dashboard.html

Se tudo estiver correto, as páginas serão exibidas.

7. Interagir com o Sistema

Na página dashboard, você poderá interagir diretamente com a placa:

• Alternar o estado do LED verde.
• Visualizar informações sobre o ThreadX e o NetX Duo em tempo real.

8. Verificar Sinais de Erro

Caso algo dê errado:

• Se o LED verde não acender, significa que o servidor HTTP não foi inicializado.
• Se o navegador não carregar a página, confira se o arquivo web_demo.bin foi gravado corretamente no endereço indicado.
• Se o terminal não mostrar um IP válido, verifique a conexão de rede e o DHCP.

Com esse passo a passo, a placa STM32F429ZI passa a funcionar como um servidor web completo, servindo páginas HTML e permitindo interação via navegador, tudo de forma embarcada.

The post Construindo um Servidor Web Embarcado com STM32F429ZI e Azure RTOS NetX Duo first appeared on MCU & FPGA.

Este artigo explora a convenção de nomenclatura do FreeRTOS, explicando a lógica por trás da escolha dos prefixos e sufixos, além de fornecer exemplos práticos e amplamente documentados para ajudar iniciantes no uso desse sistema operacional.

1. Convenção de Nomenclatura no FreeRTOS

O FreeRTOS segue um conjunto de regras bem definido para nomear funções, variáveis e tipos de dados. Essas regras são fundamentais para manter a legibilidade e a consistência do código. As principais características da nomenclatura são:

1. Prefixos das Funções – Indicam a categoria da função.
2. Tipos de Dados e Estruturas – Usam typedefs com convenções específicas.
3. Uso de Sufixos – Algumas funções e variáveis possuem sufixos que indicam propriedades específicas.

Nos tópicos seguintes, vamos explorar essas convenções com mais detalhes e exemplos práticos.

2. Prefixos das Funções no FreeRTOS

As funções do FreeRTOS seguem uma padronização de prefixos para indicar a categoria ou funcionalidade à qual pertencem. Isso facilita a organização do código e a compreensão rápida do que cada função faz. Os prefixos mais comuns são:

2.1. Funções de Gerenciamento de Tarefas

Essas funções lidam com a criação, suspensão, retomada e exclusão de tarefas no FreeRTOS. O prefixo usado é vTask ou xTask, dependendo do tipo de retorno. Elas são definidas no arquivo de cabeçalho tasks.h que deve ser incluído para seu uso.

• xTaskCreate() – Cria uma nova tarefa.
• vTaskDelete() – Exclui uma tarefa existente.
• vTaskDelay() – Suspende a tarefa por um período de tempo.
• xTaskGetSchedulerState() – Obtém o estado atual do escalonador.

Exemplo: Criando uma tarefa no FreeRTOS

#include "FreeRTOS.h"
#include "task.h"

void vTaskFunction(void *pvParameters) {
    while(1) {
        // Código da tarefa
        vTaskDelay(pdMS_TO_TICKS(1000)); // Atraso de 1 segundo
    }
}

void app_main(void) {
    xTaskCreate(vTaskFunction, "MinhaTarefa", configMINIMAL_STACK_SIZE, NULL, 1, NULL);
}

Neste exemplo, xTaskCreate() é usada para criar a tarefa, e vTaskDelay() para introduzir um atraso.

2.2. Funções de Gerenciamento de Filas

As filas são amplamente utilizadas no FreeRTOS para comunicação entre tarefas. As funções relacionadas a filas começam com o prefixo xQueue. As funções relativas ao Queue são definidas no header queue.h que deve ser incluído sempre que forem usadas.

• xQueueCreate() – Cria uma fila.
• xQueueSend() – Envia um item para a fila.
• xQueueReceive() – Recebe um item da fila.
• uxQueueMessagesWaiting() – Retorna o número de itens na fila.

Exemplo: Criando e usando uma fila

QueueHandle_t xQueue;

void vTaskSender(void *pvParameters) {
    int valor = 42;
    while(1) {
        xQueueSend(xQueue, &valor, portMAX_DELAY);
        vTaskDelay(pdMS_TO_TICKS(500)); // Envio a cada 500ms
    }
}

void vTaskReceiver(void *pvParameters) {
    int recebido;
    while(1) {
        if (xQueueReceive(xQueue, &recebido, portMAX_DELAY)) {
            printf("Recebido: %d\n", recebido);
        }
    }
}

void app_main(void) {
    xQueue = xQueueCreate(10, sizeof(int)); // Cria fila com 10 posições
    xTaskCreate(vTaskSender, "Sender", configMINIMAL_STACK_SIZE, NULL, 1, NULL);
    xTaskCreate(vTaskReceiver, "Receiver", configMINIMAL_STACK_SIZE, NULL, 1, NULL);
}

Aqui, xQueueCreate() cria a fila, xQueueSend() insere valores e xQueueReceive() os lê.

2.3. Funções de Semáforos e Mutexes

Os semáforos e mutexes são usados para sincronizar tarefas e gerenciar acesso a recursos compartilhados. O prefixo para essas funções é xSemaphore ou xMutex. Estas funçõe são definidas no arquivo de cabeçalho semaphore.h.

• xSemaphoreCreateBinary() – Cria um semáforo binário.
• xSemaphoreGive() – Libera um semáforo.
• xSemaphoreTake() – Captura um semáforo.
• xSemaphoreCreateMutex() – Cria um mutex.

Exemplo: Uso de mutex para evitar condições de corrida

SemaphoreHandle_t xMutex;

void vTask1(void *pvParameters) {
    while(1) {
        if (xSemaphoreTake(xMutex, portMAX_DELAY)) {
            printf("Tarefa 1 acessando recurso\n");
            vTaskDelay(pdMS_TO_TICKS(500));
            xSemaphoreGive(xMutex);
        }
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

void vTask2(void *pvParameters) {
    while(1) {
        if (xSemaphoreTake(xMutex, portMAX_DELAY)) {
            printf("Tarefa 2 acessando recurso\n");
            vTaskDelay(pdMS_TO_TICKS(500));
            xSemaphoreGive(xMutex);
        }
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

void app_main(void) {
    xMutex = xSemaphoreCreateMutex();
    xTaskCreate(vTask1, "Task1", configMINIMAL_STACK_SIZE, NULL, 1, NULL);
    xTaskCreate(vTask2, "Task2", configMINIMAL_STACK_SIZE, NULL, 1, NULL);
}

Aqui, xSemaphoreCreateMutex() cria um mutex, enquanto xSemaphoreTake() e xSemaphoreGive() garantem o acesso seguro ao recurso.

2.4. Funções de Timers

Os timers no FreeRTOS permitem a execução periódica de funções. As funções relacionadas a timers começam com xTimer. As funções de Timer são definidas no arquivo de cabeçalho timer.h.

• xTimerCreate() – Cria um novo timer.
• xTimerStart() – Inicia um timer.
• xTimerStop() – Para um timer.
• xTimerReset() – Reinicia um timer.

Exemplo: Criando um timer no FreeRTOS

TimerHandle_t xTimer;

void vTimerCallback(TimerHandle_t xTimer) {
    printf("Timer expirado!\n");
}

void app_main(void) {
    xTimer = xTimerCreate("MeuTimer", pdMS_TO_TICKS(2000), pdTRUE, NULL, vTimerCallback);
    if (xTimer != NULL) {
        xTimerStart(xTimer, 0);
    }
}

O timer dispara vTimerCallback() a cada 2 segundos.

3. Tipos de Dados e Estruturas no FreeRTOS

No FreeRTOS, a padronização dos tipos de dados e estruturas é essencial para garantir a portabilidade entre diferentes arquiteturas de microcontroladores. A nomenclatura segue convenções bem definidas para facilitar a leitura e evitar ambiguidades.

Os principais tipos de dados no FreeRTOS são:

• BaseType_t – Tipo base genérico para representar valores numéricos.
• TickType_t – Usado para armazenar valores de tempo (ticks do sistema).
• UBaseType_t – Variante sem sinal de BaseType_t, usada para contadores e índices.
• TaskHandle_t – Representa uma referência para uma tarefa.
• QueueHandle_t – Representa uma referência para uma fila.
• SemaphoreHandle_t – Representa um semáforo ou mutex.
• TimerHandle_t – Manipulador para um timer do FreeRTOS.

A seguir, exploraremos esses tipos de dados com exemplos práticos.

3.1. BaseType_t e UBaseType_t

O tipo BaseType_t é a base para a maioria dos tipos de retorno no FreeRTOS. Ele é definido de forma genérica para ser compatível com diferentes arquiteturas (8, 16, 32 ou 64 bits).

• BaseType_t pode ser positivo, negativo ou zero.
• UBaseType_t é sempre positivo e é usado para índices e contadores.

Exemplo: Verificando retorno de uma função

BaseType_t xStatus;
UBaseType_t uxCount = 0;

void app_main(void) {
    xStatus = xTaskCreatePinnedToCore(vTaskFunction, "Task", configMINIMAL_STACK_SIZE, NULL, 1, NULL, 0);

    if (xStatus == pdPASS) {
        printf("Tarefa criada com sucesso!\n");
    } else {
        printf("Falha ao criar tarefa.\n");
    }

    uxCount++;
    printf("Número de tentativas: %u\n", (unsigned int)uxCount);
}

Aqui, BaseType_t verifica se a criação da tarefa foi bem-sucedida, enquanto UBaseType_t conta as tentativas de criação.

3.2. TickType_t

O tipo TickType_t é usado para armazenar valores de tempo no FreeRTOS. O sistema mede o tempo em “ticks”, que dependem da frequência configurada (configTICK_RATE_HZ).

Exemplo: Obtendo o tempo atual do sistema

TickType_t xStartTime, xElapsedTime;

void app_main(void) {
    xStartTime = xTaskGetTickCount(); // Obtém o tempo atual em ticks
    vTaskDelay(pdMS_TO_TICKS(500)); // Aguarda 500ms
    xElapsedTime = xTaskGetTickCount() - xStartTime; // Calcula o tempo decorrido

    printf("Tempo decorrido: %lu ticks\n", (unsigned long)xElapsedTime);
}

Aqui, xTaskGetTickCount() é usado para medir o tempo decorrido de uma operação.

3.3. TaskHandle_t

O tipo TaskHandle_t é um ponteiro que referencia uma tarefa, permitindo manipulá-la dinamicamente.

Exemplo: Criando e suspendendo uma tarefa

TaskHandle_t xTaskHandle = NULL;

void vTaskFunction(void *pvParameters) {
    while (1) {
        printf("Tarefa executando...\n");
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void app_main(void) {
    xTaskCreate(vTaskFunction, "Task1", configMINIMAL_STACK_SIZE, NULL, 1, &xTaskHandle);

    vTaskDelay(pdMS_TO_TICKS(5000)); // Espera 5 segundos antes de suspender a tarefa
    vTaskSuspend(xTaskHandle);
    printf("Tarefa suspensa!\n");
}

Aqui, xTaskHandle é usado para suspender a tarefa após 5 segundos.

3.4. QueueHandle_t

O tipo QueueHandle_t armazena uma referência a uma fila, permitindo sua manipulação por diferentes tarefas.

Exemplo: Criando e verificando uma fila

QueueHandle_t xQueue;

void app_main(void) {
    xQueue = xQueueCreate(5, sizeof(int)); // Cria uma fila com capacidade para 5 inteiros

    if (xQueue != NULL) {
        printf("Fila criada com sucesso!\n");
    } else {
        printf("Falha ao criar a fila.\n");
    }
}

Aqui, QueueHandle_t é usado para armazenar a referência da fila criada.

3.5. SemaphoreHandle_t

O tipo SemaphoreHandle_t é usado para armazenar referência a semáforos e mutexes.

Exemplo: Criando um semáforo binário

SemaphoreHandle_t xSemaphore;

void app_main(void) {
    xSemaphore = xSemaphoreCreateBinary();

    if (xSemaphore != NULL) {
        printf("Semáforo criado!\n");
    } else {
        printf("Falha ao criar semáforo.\n");
    }
}

Aqui, SemaphoreHandle_t armazena o manipulador do semáforo criado.

3.6. TimerHandle_t

O tipo TimerHandle_t é usado para armazenar referências a timers criados no FreeRTOS.

Exemplo: Criando um timer que dispara a cada 2 segundos

TimerHandle_t xTimer;

void vTimerCallback(TimerHandle_t xTimer) {
    printf("Timer expirado!\n");
}

void app_main(void) {
    xTimer = xTimerCreate("MeuTimer", pdMS_TO_TICKS(2000), pdTRUE, NULL, vTimerCallback);

    if (xTimer != NULL) {
        xTimerStart(xTimer, 0);
        printf("Timer iniciado!\n");
    } else {
        printf("Falha ao criar o timer.\n");
    }
}

Aqui, TimerHandle_t armazena a referência do timer criado.

4. Uso de Sufixos em Funções e Variáveis do FreeRTOS

Além dos prefixos e tipos de dados padronizados, o FreeRTOS também utiliza sufixos em funções e variáveis para indicar propriedades específicas. Esses sufixos ajudam a identificar rapidamente características como escopo, tipo de dado ou comportamento esperado da função.

Os principais sufixos usados no FreeRTOS são:

• FromISR – Indica que a função pode ser chamada a partir de uma interrupção.
• _t – Indica que o nome refere-se a um tipo de dado.
• Handle – Representa um manipulador para um objeto do FreeRTOS.
• Ticks – Refere-se a unidades de tempo do sistema (ticks).
• MS – Representa valores em milissegundos.

A seguir, exploramos cada um desses sufixos com exemplos práticos.

4.1. Sufixo FromISR

Funções que podem ser chamadas dentro de um handler de interrupção possuem o sufixo FromISR. Isso é necessário porque chamadas dentro de interrupções não podem executar determinadas operações do sistema operacional, como esperar indefinidamente (portMAX_DELAY).

Exemplo: Enviando um item para uma fila dentro de uma interrupção

QueueHandle_t xQueue;

void IRAM_ATTR vISRHandler(void *arg) {
    int valor = 10;
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;

    xQueueSendFromISR(xQueue, &valor, &xHigherPriorityTaskWoken);

    if (xHigherPriorityTaskWoken == pdTRUE) {
        portYIELD_FROM_ISR();
    }
}

void app_main(void) {
    xQueue = xQueueCreate(5, sizeof(int));

    gpio_install_isr_service(0);
    gpio_isr_handler_add(GPIO_NUM_4, vISRHandler, NULL);
}

Aqui, xQueueSendFromISR() é usado para evitar bloqueios dentro da interrupção.

4.2. Sufixo _t

O sufixo _t indica que o nome representa um tipo de dado definido pelo FreeRTOS.

Exemplo: Utilizando tipos de dados do FreeRTOS

BaseType_t xStatus;
TickType_t xTime;
QueueHandle_t xQueue;

Aqui, BaseType_t, TickType_t e QueueHandle_t seguem essa convenção.

4.3. Sufixo Handle

O sufixo Handle é usado para representar manipuladores de objetos do FreeRTOS, como tarefas, filas, semáforos e timers.

Exemplo: Criando e manipulando uma tarefa

TaskHandle_t xTaskHandle = NULL;

void vTaskFunction(void *pvParameters) {
    while (1) {
        printf("Executando tarefa...\n");
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void app_main(void) {
    xTaskCreate(vTaskFunction, "MinhaTarefa", configMINIMAL_STACK_SIZE, NULL, 1, &xTaskHandle);
    vTaskDelay(pdMS_TO_TICKS(5000));
    vTaskDelete(xTaskHandle);
}

Aqui, TaskHandle_t armazena o manipulador da tarefa para que possamos manipulá-la posteriormente.

4.4. Sufixo Ticks

O sufixo Ticks indica que o valor da variável ou função está expresso em ticks de sistema.

Exemplo: Calculando tempo em ticks

TickType_t xStartTime, xElapsedTime;

void app_main(void) {
    xStartTime = xTaskGetTickCount(); // Obtém tempo atual
    vTaskDelay(pdMS_TO_TICKS(2000)); // Aguarda 2 segundos
    xElapsedTime = xTaskGetTickCount() - xStartTime;

    printf("Tempo decorrido: %lu ticks\n", (unsigned long)xElapsedTime);
}

Aqui, xStartTime e xElapsedTime armazenam valores em ticks do sistema.

4.5. Sufixo MS

O sufixo MS é usado para representar valores em milissegundos.

Exemplo: Definindo tempos em milissegundos

#define TEMPO_DELAY_MS 500

void app_main(void) {
    vTaskDelay(pdMS_TO_TICKS(TEMPO_DELAY_MS)); // Converte para ticks
    printf("Aguardou %d ms\n", TEMPO_DELAY_MS);
}

Aqui, TEMPO_DELAY_MS representa um tempo em milissegundos.

Resumo da Seção

Os sufixos no FreeRTOS ajudam a identificar o propósito de variáveis e funções rapidamente:

5. Prefixos de Retorno de Funções e Variáveis no FreeRTOS

Além dos prefixos usados para categorizar funções (xTask, vTask, xQueue etc.), o FreeRTOS também utiliza prefixos em variáveis e valores de retorno para indicar tipos de dados específicos. Esses prefixos ajudam a identificar rapidamente a natureza da variável ou o tipo de dado que uma função retorna.

Os principais prefixos utilizados no FreeRTOS incluem:

A seguir, exploramos cada um desses prefixos com exemplos práticos.

5.1. Prefixo u (Unsigned)

O prefixo u indica que a variável é um número inteiro sem sinal, ou seja, não pode armazenar valores negativos.

Exemplo: Contador sem sinal

uint8_t uCounter = 0;

void app_main(void) {
    for (uCounter = 0; uCounter < 10; uCounter++) {
        printf("Contador: %u\n", uCounter);
    }
}

Aqui, uCounter é uma variável do tipo uint8_t, que é um inteiro sem sinal de 8 bits.

5.2. Prefixo x (Retorno de Função)

O prefixo x é usado em funções que retornam um valor de status, geralmente do tipo BaseType_t.

Exemplo: Verificando status da criação de uma tarefa

BaseType_t xStatus;

void app_main(void) {
    xStatus = xTaskCreate(vTaskFunction, "Task1", configMINIMAL_STACK_SIZE, NULL, 1, NULL);

    if (xStatus == pdPASS) {
        printf("Tarefa criada com sucesso!\n");
    } else {
        printf("Falha ao criar a tarefa.\n");
    }
}

O xTaskCreate() retorna um BaseType_t, e o valor de retorno xStatus indica se a operação foi bem-sucedida.

5.3. Prefixo v (Void)

O prefixo v é usado para funções que não retornam valores, ou seja, cujo tipo de retorno é void.

Exemplo: Função sem retorno

void vTaskFunction(void *pvParameters) {
    while (1) {
        printf("Executando tarefa...\n");
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

A função vTaskFunction() não retorna valores, então segue a convenção v.

5.4. Prefixo ux (Unsigned BaseType_t)

O prefixo ux é usado para variáveis do tipo UBaseType_t, que é um inteiro sem sinal usado para contadores e índices.

Exemplo: Usando UBaseType_t para armazenar um índice

UBaseType_t uxIndex;

void app_main(void) {
    for (uxIndex = 0; uxIndex < 5; uxIndex++) {
        printf("Índice: %u\n", (unsigned int)uxIndex);
    }
}

O UBaseType_t é frequentemente usado para contadores e índices em loops.

5.5. Prefixo e (Enumeração)

O prefixo e indica que a variável é uma enumeração (enum), usada para definir valores simbólicos.

Exemplo: Obtendo o estado de uma tarefa

eTaskState eState;

void app_main(void) {
    eState = eTaskGetState(NULL);
    printf("Estado da tarefa: %d\n", eState);
}

O eTaskGetState() retorna um valor do tipo eTaskState, que segue a convenção e.

5.6. Prefixo p (Pointer)

O prefixo p é usado para variáveis que armazenam ponteiros.

Exemplo: Ponteiro para uma string

char *pMessage = "Olá, FreeRTOS!";

void app_main(void) {
    printf("%s\n", pMessage);
}

O pMessage armazena um ponteiro para uma string.

5.7. Prefixo s (String)

O prefixo s indica que a variável é uma string.

Exemplo: Definição de uma string

const char *sWelcomeMessage = "Bem-vindo ao FreeRTOS!";

void app_main(void) {
    printf("%s\n", sWelcomeMessage);
}

Aqui, sWelcomeMessage representa uma string constante.

5.8. Prefixo pc e pu (Ponteiros para constantes)

Os prefixos pc e pu são usados para indicar ponteiros para constantes, diferenciando entre char e unsigned.

Exemplo: Ponteiro para constante

const char *pcMessage = "Mensagem constante";
const uint8_t *puData;

O pcMessage aponta para uma string constante, enquanto puData pode apontar para um buffer de dados constantes.

5.9. Prefixo c (Char)

O prefixo c indica que a variável é do tipo char.

Exemplo: Armazenando um caractere

char cCharacter = 'A';

void app_main(void) {
    printf("Caractere: %c\n", cCharacter);
}

Aqui, cCharacter armazena um único caractere.

5.10. Prefixo pd (Port Define)

O prefixo pd é usado para constantes internas do FreeRTOS, geralmente definindo estados ou resultados de funções.

Exemplo: Uso de pdPASS e pdFALSE

if (xTaskCreate(vTaskFunction, "Task", configMINIMAL_STACK_SIZE, NULL, 1, NULL) == pdPASS) {
    printf("Tarefa criada com sucesso!\n");
}

if (xSemaphoreTake(xSemaphore, 0) == pdFALSE) {
    printf("Semáforo não disponível.\n");
}

O pdPASS indica sucesso e pdFALSE indica falha na tentativa de captura do semáforo.

6. Boas Práticas na Nomenclatura do FreeRTOS

O uso correto da nomenclatura do FreeRTOS não é apenas uma questão de padronização, mas também uma prática essencial para aumentar a legibilidade, manutenibilidade e clareza do código. Aqui estão algumas boas práticas recomendadas ao trabalhar com o FreeRTOS.

6.1. Use os Prefixos e Sufixos Corretamente

O FreeRTOS adota uma convenção de nomenclatura bem estruturada para ajudar os desenvolvedores a entender rapidamente o propósito de funções e variáveis. Para manter essa clareza:

Use os prefixos apropriados para funções:

• Funções que retornam um status devem começar com x (ex.: xTaskCreate()).
• Funções que não retornam valores devem começar com v (ex.: vTaskDelay()).
• Funções que podem ser chamadas dentro de interrupções devem terminar com FromISR (ex.: xQueueSendFromISR()).

Use os tipos de dados apropriados:

• Utilize BaseType_t e UBaseType_t para variáveis de controle.
• Use TickType_t para valores relacionados ao tempo.
• Manipuladores devem ser sempre declarados com seus respectivos tipos (TaskHandle_t, QueueHandle_t, etc.).

Respeite a nomenclatura dos sufixos:

• Para variáveis que representam tempo, use Ticks ou MS.
• Para ponteiros, use p, pc, ou pu, conforme necessário.
• Para caracteres e strings, use c e s.

6.2. Evite Modificar os Nomes das Funções do FreeRTOS

As funções do FreeRTOS seguem uma convenção bem definida e não devem ser renomeadas. Isso pode causar confusão e dificultar a manutenção do código.

Evite fazer isso:

#define CriarTarefa xTaskCreate  // NÃO RECOMENDADO
CriarTarefa(vTaskFunction, "Task1", configMINIMAL_STACK_SIZE, NULL, 1, NULL);

Forma correta:

xTaskCreate(vTaskFunction, "Task1", configMINIMAL_STACK_SIZE, NULL, 1, NULL);

Alterar nomes de funções pode tornar o código difícil de entender para outros desenvolvedores.

6.3. Nomeie Tarefas, Filas e Recursos de Forma Clara

Sempre nomeie tarefas e recursos do FreeRTOS com nomes descritivos que indiquem sua função.

Evite nomes genéricos:

TaskHandle_t xTarefa1;
QueueHandle_t xFila;

Use nomes descritivos:

TaskHandle_t xTaskSensor;
QueueHandle_t xQueueMensagens;

Nomes descritivos tornam o código mais intuitivo e fácil de depurar.

6.4. Utilize pdMS_TO_TICKS() para Conversão de Tempo

O FreeRTOS mede o tempo em ticks, então é essencial converter corretamente valores de tempo em milissegundos para ticks.

Evite valores fixos em ticks:

vTaskDelay(100); // NÃO RECOMENDADO, pois depende da configuração do sistema

Use pdMS_TO_TICKS():

vTaskDelay(pdMS_TO_TICKS(100)); // Correto e portátil

Isso garante que o código funcione corretamente em diferentes configurações de configTICK_RATE_HZ.

6.5. Declare Variáveis no Escopo Adequado

Variáveis globais podem ser úteis, mas devem ser usadas com cuidado para evitar conflitos e garantir encapsulamento.

Use escopo local sempre que possível:

void vTaskFunction(void *pvParameters) {
    uint32_t ulContador = 0; // Variável local, melhor encapsulamento
    while (1) {
        ulContador++;
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

Evite variáveis globais desnecessárias:

uint32_t ulContadorGlobal; // Pode causar conflitos e dificultar depuração

void vTaskFunction(void *pvParameters) {
    while (1) {
        ulContadorGlobal++;
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

Sempre prefira variáveis locais, a menos que seja essencial compartilhá-las entre tarefas.

6.6. Documente Seu Código

O FreeRTOS facilita o desenvolvimento de sistemas embarcados, mas um código mal documentado pode se tornar difícil de entender e manter.

Exemplo de código bem documentado:

/**
 * @brief  Função da tarefa que lê sensores periodicamente.
 * @param  pvParameters: Parâmetros da tarefa (não usados aqui).
 */
void vTaskSensor(void *pvParameters) {
    while (1) {
        printf("Lendo sensor...\n");
        vTaskDelay(pdMS_TO_TICKS(1000)); // Espera 1 segundo
    }
}

Uma boa documentação ajuda a equipe de desenvolvimento e facilita futuras manutenções.

6.7. Teste e Valide o Código Com Regularidade

Ao trabalhar com o FreeRTOS, é essencial testar o código regularmente para garantir que ele funcione corretamente e não tenha problemas de concorrência.

Dicas para testes eficazes:

• Use configASSERT() para verificar condições críticas.
• Monitore o uso de memória e pilha (uxTaskGetStackHighWaterMark()).
• Teste cenários de alta concorrência e preempção para evitar deadlocks e starvation.

Conclusão

O FreeRTOS fornece um sistema operacional leve e eficiente para sistemas embarcados, mas seu uso correto exige boas práticas na nomenclatura e estrutura do código. Resumindo:

Use os prefixos e sufixos corretamente para garantir legibilidade.
Não modifique nomes das funções do FreeRTOS para manter compatibilidade.
Dê nomes descritivos a tarefas, filas e semáforos para facilitar manutenção.
Sempre converta milissegundos para ticks com pdMS_TO_TICKS().
Evite variáveis globais desnecessárias para reduzir riscos de conflitos.
Documente e teste seu código regularmente para manter qualidade.

Seguindo essas boas práticas, você garantirá que seus projetos baseados no FreeRTOS sejam mais organizados, confiáveis e fáceis de manter.

The post Introdução à Nomenclatura do FreeRTOS first appeared on MCU & FPGA.

Neste artigo, iniciamos uma série de artigos sobre padrões de projeto aplicáveis ao desenvolvimento em C para microcontroladores. Para cada padrão, descreveremos seu propósito, vantagens e um cenário de aplicação. Cada um desses padrões será tratado com mais profundidade em artigos separados ao longo desta série.

Este material tem como base os seguintes livros de referência:

• Design Patterns for Embedded Systems in C de Bruce Powel Douglass
• Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems de Bruce Powel Douglass
• Patterns of Enterprise Application Architecture de Martin Fowler
• Domain-Driven Design de Eric Evans
• Design Patterns: Elements of Reusable Object-Oriented Software de Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (Gang of Four)

Minha Jornada com Padrões de Projeto em C

Quando comecei a programar em Java, há 20 anos, fiquei fascinado com a capacidade da linguagem de representar objetos em forma de código. Isso me levou a buscar mais conhecimento sobre o assunto, e logo me deparei com livros como Domain-Driven Design de Eric Evans, Patterns of Enterprise Application Architecture de Martin Fowler e Design Patterns. O entendimento desses padrões de projeto abriu minha mente para a importância de desenvolver código altamente estruturado e de qualidade.

Entretanto, nunca havia considerado que no contexto procedural da linguagem C também pudessem existir tais padrões. Para minha surpresa, em uma conversa recente com meu tutor na Embarcatech, fui apresentado ao conceito de Orientação a Objetos em C. Não estou falando de C++, mas sim de C puro! Isso me despertou uma enorme curiosidade, e iniciei uma pesquisa sobre o tema. Foi então que me deparei com os livros de Bruce Powel Douglass sobre padrões de projeto em sistemas embarcados.

Ainda não tive meu boooommmm de entendimento total no contexto de microcontroladores, pois não consegui ler os livros por completo. No entanto, como tudo que estudo vira material para meus sites e livros (um dia eles saem!), decidi abordar um padrão de projeto por mês e compartilhar essas descobertas com vocês.

Padrões de Projeto para Sistemas Embarcados

Aqui está uma lista abrangente dos principais padrões de projeto aplicáveis ao desenvolvimento de software para microcontroladores e sistemas embarcados. Eles estão organizados por categoria para facilitar a compreensão:

1. Padrões de Arquitetura de Subsistema e Componentes

Os padrões desta categoria ajudam a estruturar o software embarcado de forma modular, facilitando a manutenção, a escalabilidade e a reutilização de código. Eles definem como os diferentes módulos do sistema interagem entre si e organizam a arquitetura geral do software.

1.1 Layered Pattern (Padrão em Camadas)

• Problema que resolve: Mistura de responsabilidades dentro do código, dificultando a manutenção e a reutilização.
• Cenário de uso: Projetos que exigem separação clara entre hardware, drivers, middleware e aplicação.
• Vantagens: Organização do código, maior reutilização de componentes e facilidade de manutenção.
• O que é: Divide o sistema em camadas hierárquicas onde cada uma depende apenas da camada inferior, promovendo um código mais organizado e de fácil escalabilidade.

1.2 Microkernel Architecture Pattern

• Problema que resolve: Sistemas grandes e complexos com funcionalidades variáveis que precisam ser ativadas ou desativadas dinamicamente.
• Cenário de uso: Sistemas embarcados modulares que precisam suportar diferentes configurações de hardware ou software.
• Vantagens: Melhor gerenciamento de recursos e flexibilidade na ativação/desativação de módulos.
• O que é: Mantém um núcleo mínimo do sistema (microkernel) e permite adicionar funcionalidades por meio de módulos externos.

1.3 Component-Based Architecture Pattern

• Problema que resolve: Alto acoplamento entre módulos, dificultando a reutilização e a substituição de componentes.
• Cenário de uso: Sistemas embarcados que precisam de alta modularidade, como IoT e automação industrial.
• Vantagens: Facilita a manutenção e a atualização do sistema sem afetar outros componentes.
• O que é: Estrutura o software em componentes independentes que interagem por meio de interfaces bem definidas.

1.4 Virtual Machine Pattern

• Problema que resolve: Dificuldade em portar software para diferentes plataformas de hardware.
• Cenário de uso: Sistemas embarcados que precisam rodar em múltiplos tipos de hardware sem grandes adaptações no código.
• Vantagens: Independência de hardware e reutilização de código entre diferentes plataformas.
• O que é: Cria uma camada de abstração que simula um ambiente de execução padronizado, permitindo que o software funcione de forma mais genérica.

1.5 Hierarchical Control Pattern

• Problema que resolve: Falta de organização em sistemas embarcados que possuem múltiplos níveis de controle.
• Cenário de uso: Sistemas que exigem tomada de decisão em diferentes níveis, como controle de motores e automação.
• Vantagens: Melhor separação de responsabilidades e hierarquia clara no fluxo de controle.
• O que é: Divide o controle do sistema em diferentes níveis hierárquicos, permitindo um gerenciamento mais eficiente e modular.

1.6 Recursive Containment Pattern

• Problema que resolve: Complexidade na organização de subsistemas que possuem componentes recursivos ou aninhados.
• Cenário de uso: Sistemas embarcados que possuem módulos que precisam ser tratados como subsistemas independentes.
• Vantagens: Organização modular clara e facilidade na expansão do sistema.
• O que é: Estrutura os componentes do sistema de maneira hierárquica e recursiva, onde cada elemento pode conter outros elementos semelhantes.

1.7 ROOM Pattern (Real-Time Object-Oriented Modeling)

O que é: Um padrão que fornece uma abordagem orientada a objetos para modelagem de sistemas de tempo real.

Problema que resolve: Falta de um modelo estruturado para desenvolvimento orientado a objetos em sistemas embarcados.

Cenário de uso: Sistemas de tempo real que precisam seguir um modelo de desenvolvimento baseado em objetos.

Vantagens: Modelagem bem definida, facilitando o desenvolvimento e manutenção do sistema.

2. Padrões de Concorrência

Os padrões desta categoria lidam com a execução de múltiplas tarefas em sistemas embarcados, garantindo que processos concorrentes operem de maneira eficiente e segura. Eles ajudam a evitar condições de corrida, otimizar a comunicação entre tarefas e melhorar a previsibilidade do sistema.

2.1 Message Queuing Pattern

• Problema que resolve: Concorrência e sincronização inadequada entre diferentes tarefas que compartilham dados.
• Cenário de uso: Sistemas embarcados multitarefa onde tarefas precisam trocar informações de forma controlada.
• Vantagens: Evita condições de corrida e melhora a organização da comunicação entre tarefas.
• O que é: Utiliza filas de mensagens para permitir a comunicação assíncrona entre tarefas de forma controlada.

2.2 Interrupt Pattern

• Problema que resolve: Latência alta ao lidar com eventos externos devido a verificações contínuas (polling).
• Cenário de uso: Sistemas que precisam responder rapidamente a eventos externos, como acionamento de sensores.
• Vantagens: Reduz consumo de CPU, melhora tempo de resposta e eficiência energética.
• O que é: Utiliza interrupções de hardware para lidar com eventos externos de forma imediata, evitando verificações constantes.

2.3 Guarded Call Pattern

• Problema que resolve: Concorrência inadequada e acesso simultâneo a recursos compartilhados.
• Cenário de uso: Sistemas embarcados multitarefa que precisam garantir a execução segura de chamadas a funções compartilhadas.
• Vantagens: Previne corrupção de dados e melhora a confiabilidade do sistema.
• O que é: Implementa verificações e sincronização para garantir que chamadas a funções críticas sejam executadas apenas quando seguras.

2.4 Rendezvous Pattern

• Problema que resolve: Sincronização inadequada entre duas ou mais tarefas que precisam se comunicar diretamente.
• Cenário de uso: Sistemas onde duas tarefas dependem do estado da outra para avançar, como protocolos de comunicação.
• Vantagens: Melhora a coordenação entre tarefas e evita espera passiva.
• O que é: Estabelece um mecanismo onde duas tarefas precisam estar prontas simultaneamente para prosseguir com a comunicação.

2.5 Cyclic Executive Pattern

• Problema que resolve: Complexidade e overhead na gestão de múltiplas tarefas concorrentes.
• Cenário de uso: Sistemas embarcados simples sem RTOS, onde tarefas precisam ser executadas periodicamente.
• Vantagens: Controle determinístico e fácil implementação.
• O que é: Um loop fixo que executa cada tarefa em uma ordem predefinida dentro de um ciclo fixo de tempo.

2.6 Round Robin Pattern

• Problema que resolve: Falta de tempo de CPU equitativo entre tarefas concorrentes.
• Cenário de uso: Sistemas embarcados com multitarefa onde cada processo deve receber um tempo justo de execução.
• Vantagens: Distribuição justa de CPU entre tarefas, evitando monopolização do processador.
• O que é: Um mecanismo de escalonamento que alterna a execução de cada tarefa por um tempo determinado, em um ciclo contínuo.

2.7 Static Priority Pattern

• Problema que resolve: Falta de controle sobre a execução de tarefas críticas em tempo real.
• Cenário de uso: Sistemas de tempo real que exigem resposta imediata para determinadas tarefas prioritárias.
• Vantagens: Garante que tarefas críticas sejam executadas antes das menos prioritárias.
• O que é: Define prioridades fixas para cada tarefa, garantindo que aquelas com maior prioridade sempre sejam executadas primeiro.

2.8 Dynamic Priority Pattern

• Problema que resolve: Problemas de bloqueios ou inversão de prioridade em sistemas multitarefa.
• Cenário de uso: Sistemas onde a prioridade das tarefas pode mudar com base na carga de trabalho.
• Vantagens: Melhora o balanceamento de carga do processador e evita deadlocks.
• O que é: Ajusta dinamicamente as prioridades das tarefas conforme necessário para garantir melhor desempenho e tempo de resposta.

3. Padrões de Gerenciamento de Memória

Os padrões desta categoria ajudam a otimizar o uso da memória em sistemas embarcados, onde os recursos são frequentemente limitados. Eles garantem que a alocação e a liberação de memória ocorram de forma eficiente, evitando desperdícios e garantindo previsibilidade no consumo de RAM.

3.1 Static Allocation Pattern

• Problema que resolve: Uso imprevisível de memória devido a alocações dinâmicas, que podem causar fragmentação e falhas em sistemas embarcados críticos.
• Cenário de uso: Sistemas embarcados com recursos limitados que precisam de controle total sobre a alocação de memória.
• Vantagens: Evita fragmentação da memória e melhora a previsibilidade do uso de RAM.
• O que é: Utiliza apenas alocações estáticas, definindo variáveis globais e buffers fixos durante a compilação.

3.2 Pool Allocation Pattern

• Problema que resolve: Ineficiência e fragmentação de memória ao alocar e desalocar pequenos blocos dinamicamente.
• Cenário de uso: Sistemas que precisam gerenciar dinamicamente a alocação de pequenos blocos de memória sem risco de fragmentação.
• Vantagens: Reduz fragmentação e melhora a previsibilidade no tempo de acesso à memória.
• O que é: Aloca um conjunto fixo de blocos de memória e os gerencia em um pool pré-definido, evitando alocações e desalocações imprevisíveis.

3.3 Fixed-Sized Buffer Pattern

• Problema que resolve: Overhead e fragmentação ao lidar com buffers de tamanho variável.
• Cenário de uso: Aplicações que precisam de buffers para comunicação ou armazenamento temporário de dados.
• Vantagens: Maior eficiência no gerenciamento de memória e redução de falhas associadas a alocações dinâmicas.
• O que é: Define buffers de tamanho fixo e pré-alocados para operações específicas, garantindo previsibilidade e eficiência no uso da memória.

3.4 Smart Pointer Pattern

• Problema que resolve: Vazamento de memória devido a alocações dinâmicas sem liberação adequada.
• Cenário de uso: Sistemas embarcados que precisam gerenciar dinamicamente a memória sem risco de vazamentos.
• Vantagens: Reduz a necessidade de gerenciar manualmente a liberação de memória, evitando erros de alocação.
• O que é: Implementa ponteiros inteligentes que controlam automaticamente a alocação e liberação da memória associada.

3.5 Garbage Collection Pattern

• Problema que resolve: Necessidade de liberação manual de memória em sistemas que fazem uso intenso de alocação dinâmica.
• Cenário de uso: Aplicações complexas que utilizam alocação dinâmica e exigem gerenciamento automatizado da memória.
• Vantagens: Libera automaticamente memória não utilizada, reduzindo erros de alocação e melhorando a estabilidade do sistema.
• O que é: Implementa um mecanismo que monitora e libera memória não referenciada automaticamente.

3.6 Garbage Compactor Pattern

• Problema que resolve: Fragmentação de memória ao longo do tempo devido a alocações e desalocações dinâmicas.
• Cenário de uso: Sistemas embarcados com uso dinâmico de memória onde a fragmentação pode comprometer a alocação de novos blocos.
• Vantagens: Reduz fragmentação de memória e melhora a eficiência da alocação.
• O que é: Reorganiza a memória alocada periodicamente para eliminar fragmentação e garantir blocos contíguos livres.

4. Padrões de Gerenciamento de Recursos

Os padrões desta categoria garantem o acesso eficiente e seguro a recursos compartilhados em sistemas embarcados. Eles ajudam a evitar problemas como deadlocks, inversão de prioridade e acesso concorrente inadequado a periféricos e variáveis globais.

4.1 Critical Section Pattern

• Problema que resolve: Condições de corrida causadas por múltiplas tarefas acessando simultaneamente um mesmo recurso.
• Cenário de uso: Sistemas multitarefa onde variáveis globais ou periféricos precisam ser acessados por diferentes processos.
• Vantagens: Evita corrupção de dados e garante acesso controlado aos recursos compartilhados.
• O que é: Implementa seções críticas onde apenas uma tarefa pode acessar um recurso por vez, utilizando mutexes, semáforos ou desativação de interrupções.

4.2 Priority Inheritance Pattern

• Problema que resolve: Inversão de prioridade, onde uma tarefa de baixa prioridade impede a execução de uma tarefa crítica.
• Cenário de uso: Sistemas de tempo real onde tarefas críticas podem ser bloqueadas por tarefas de menor prioridade.
• Vantagens: Garante que tarefas de alta prioridade não fiquem bloqueadas desnecessariamente.
• O que é: Permite que uma tarefa de baixa prioridade herde temporariamente a prioridade de uma tarefa de maior prioridade até liberar o recurso.

4.3 Highest Locker Pattern

• Problema que resolve: Deadlocks gerados por múltiplas tarefas bloqueando recursos de forma desordenada.
• Cenário de uso: Sistemas onde várias tarefas competem por múltiplos recursos compartilhados.
• Vantagens: Evita deadlocks e melhora a previsibilidade do sistema.
• O que é: Assegura que apenas a tarefa com a maior prioridade entre as que precisam do recurso possa bloqueá-lo, forçando uma ordem de acesso previsível.

4.4 Priority Ceiling Pattern

• Problema que resolve: Inversão de prioridade e bloqueios inesperados devido a compartilhamento inadequado de recursos.
• Cenário de uso: Sistemas embarcados críticos onde múltiplas tarefas acessam o mesmo recurso.
• Vantagens: Evita bloqueios imprevisíveis e melhora o tempo de resposta das tarefas críticas.
• O que é: Define uma prioridade máxima para cada recurso compartilhado, garantindo que apenas tarefas com prioridade igual ou superior possam acessá-lo.

4.5 Simultaneous Locking Pattern

• Problema que resolve: Deadlocks e ineficiência ao acessar múltiplos recursos compartilhados ao mesmo tempo.
• Cenário de uso: Sistemas onde múltiplas tarefas precisam acessar vários recursos simultaneamente.
• Vantagens: Reduz o risco de deadlocks e melhora a eficiência no gerenciamento de recursos.
• O que é: Implementa um mecanismo de bloqueio simultâneo de todos os recursos necessários antes de iniciar uma operação crítica.

4.6 Ordered Locking Pattern

• Problema que resolve: Deadlocks causados por ordem inconsistente de bloqueio de recursos.
• Cenário de uso: Sistemas multitarefa onde diferentes processos podem acessar recursos em ordens variadas.
• Vantagens: Previne deadlocks sem necessidade de mecanismos complexos de verificação.
• O que é: Impõe uma ordem fixa de bloqueio de recursos, garantindo que todas as tarefas sigam a mesma sequência ao acessá-los.

5. Padrões de Distribuição e Comunicação

Os padrões desta categoria garantem uma comunicação eficiente entre diferentes partes do sistema, seja dentro de um único microcontrolador ou entre múltiplos dispositivos conectados em rede. Eles ajudam a estruturar a troca de informações de forma confiável e escalável.

5.1 Shared Memory Pattern

• Problema que resolve: Comunicação ineficiente entre tarefas devido ao uso de filas ou mensagens que geram sobrecarga.
• Cenário de uso: Sistemas embarcados que precisam compartilhar grandes volumes de dados entre múltiplas tarefas ou processadores.
• Vantagens: Baixa latência e alta taxa de transferência de dados.
• O que é: Um espaço de memória compartilhado é utilizado como meio de comunicação entre processos, evitando a necessidade de cópias de dados desnecessárias.

5.2 Remote Method Call Pattern

• Problema que resolve: Comunicação entre processos distribuídos sem uma interface de baixo nível bem definida.
• Cenário de uso: Sistemas embarcados que se comunicam via redes como CAN, Modbus ou Ethernet.
• Vantagens: Oculta a complexidade da comunicação e facilita a implementação de chamadas remotas.
• O que é: Permite que um processo invoque funções em outro sistema remoto como se fossem chamadas locais.

5.3 Observer Pattern

• Problema que resolve: Comunicação ineficiente entre módulos que precisam ser notificados sobre mudanças de estado.
• Cenário de uso: Sistemas de eventos, sensores e notificações em tempo real.
• Vantagens: Reduz o acoplamento entre os módulos e melhora a escalabilidade do sistema.
• O que é: Define um mecanismo de notificação assíncrona onde múltiplos observadores podem ser informados sobre mudanças de estado de um único sujeito.

5.4 Data Bus Pattern

• Problema que resolve: Comunicação complexa e desorganizada entre múltiplos módulos do sistema.
• Cenário de uso: Arquiteturas de sistemas embarcados que exigem comunicação padronizada entre diversos componentes.
• Vantagens: Centraliza a comunicação, reduz a complexidade e melhora a modularidade.
• O que é: Implementa um barramento de dados onde múltiplos componentes podem publicar e assinar mensagens de forma padronizada.

5.5 Proxy Pattern

• Problema que resolve: Comunicação ineficiente e insegura entre componentes distribuídos ou remotos.
• Cenário de uso: Sistemas embarcados que utilizam interfaces de comunicação externas ou protocolos remotos.
• Vantagens: Melhora a segurança, reduz a latência e otimiza a comunicação entre módulos separados.
• O que é: Um intermediário que atua como representante de outro objeto, fornecendo uma interface simplificada e segura para acessá-lo.

5.6 Broker Pattern

• Problema que resolve: Dependência direta entre módulos que precisam trocar informações de forma distribuída.
• Cenário de uso: Sistemas de comunicação assíncrona, como IoT e redes industriais.
• Vantagens: Desacopla os módulos e permite escalabilidade na comunicação.
• O que é: Introduz um broker (intermediário) que gerencia a comunicação entre diferentes partes do sistema sem que elas precisem conhecer diretamente umas às outras.

6. Padrões de Segurança e Confiabilidade

Os padrões desta categoria garantem que o sistema continue operando de forma segura e confiável mesmo diante de falhas de hardware, software ou interferências externas. Eles são especialmente importantes em sistemas críticos, como automação industrial, aeroespacial e dispositivos médicos.

6.1 Protected Single Channel Pattern

• Problema que resolve: Falhas na comunicação entre módulos devido a corrupção de dados.
• Cenário de uso: Sistemas que transmitem dados críticos via barramentos compartilhados.
• Vantagens: Garante a integridade dos dados transmitidos.
• O que é: Implementa mecanismos de verificação, como CRC e checksum, para assegurar que as mensagens recebidas sejam íntegras.

6.2 Homogeneous Redundancy Pattern

• Problema que resolve: Falhas em componentes críticos sem um sistema de backup imediato.
• Cenário de uso: Sistemas embarcados de missão crítica, como aeronaves e equipamentos médicos.
• Vantagens: Aumenta a confiabilidade do sistema ao replicar funcionalidades críticas.
• O que é: Usa múltiplas instâncias idênticas de um componente para fornecer redundância e permitir recuperação automática em caso de falha.

6.3 Triple Modular Redundancy (TMR) Pattern

• Problema que resolve: Erros transitórios ou permanentes em hardware crítico.
• Cenário de uso: Sistemas de controle de segurança, como sensores de usinas nucleares e controle de motores em aeronaves.
• Vantagens: Aumenta a resiliência do sistema contra falhas de hardware.
• O que é: Utiliza três módulos independentes executando a mesma tarefa e um votador que decide o resultado correto com base no consenso entre os três.

6.4 Heterogeneous Redundancy Pattern

• Problema que resolve: Falhas que afetam sistemas idênticos devido a vulnerabilidades comuns.
• Cenário de uso: Aplicações onde falhas sistêmicas devem ser evitadas a todo custo.
• Vantagens: Maior robustez contra falhas comuns.
• O que é: Usa diferentes implementações de um mesmo sistema para reduzir o risco de falhas sistêmicas.

6.5 Monitor-Actuator Pattern

• Problema que resolve: Falta de monitoramento automático para detectar falhas antes que causem danos ao sistema.
• Cenário de uso: Sistemas que precisam garantir operação contínua sem intervenção humana constante.
• Vantagens: Aumenta a resiliência do sistema.
• O que é: Implementa sensores e atuadores que monitoram o estado do sistema e tomam ações preventivas quando necessário.

6.6 Sanity Check Pattern

• Problema que resolve: Comportamento imprevisível do sistema devido a erros internos ou falhas não detectadas.
• Cenário de uso: Sistemas embarcados que precisam garantir um funcionamento previsível e seguro.
• Vantagens: Detecta erros rapidamente e evita falhas catastróficas.
• O que é: Implementa verificações automáticas que garantem que o sistema esteja operando dentro dos parâmetros esperados.

6.7 Watchdog Pattern

• Problema que resolve: Travamento do sistema devido a loops infinitos ou falhas inesperadas.
• Cenário de uso: Qualquer sistema embarcado onde a operação contínua deve ser garantida.
• Vantagens: Melhora a estabilidade e recuperação do sistema.
• O que é: Utiliza um temporizador de supervisão (watchdog) que reinicia o sistema se uma falha for detectada.

6.8 Safety Executive Pattern

• Problema que resolve: Falha na tomada de decisões de segurança em sistemas críticos.
• Cenário de uso: Sistemas de segurança industrial e dispositivos médicos.
• Vantagens: Melhora a confiabilidade e a resposta a falhas.
• O que é: Implementa um mecanismo de supervisão que avalia continuamente os riscos e toma ações para evitar falhas graves.

7. Conclusão

Os padrões de projeto desempenham um papel fundamental no desenvolvimento de sistemas embarcados eficientes, seguros e escaláveis. Cada categoria de padrões abordada neste artigo fornece soluções estruturadas para problemas recorrentes, desde a organização da arquitetura até o gerenciamento de concorrência, memória, recursos, comunicação e segurança.

A escolha adequada dos padrões a serem utilizados em um projeto pode impactar diretamente na modularidade, desempenho e confiabilidade do sistema embarcado. Implementar esses padrões corretamente pode reduzir a complexidade do código, melhorar a manutenibilidade e garantir que o software funcione de forma previsível, mesmo em cenários críticos.

Nos próximos artigos desta série, exploraremos cada padrão em detalhes, apresentando exemplos práticos e sua aplicação em C para sistemas embarcados. Assim, engenheiros e desenvolvedores poderão aplicar esses conceitos de maneira eficaz em seus projetos.

The post Padrões de Projeto para Sistemas Embarcados em C first appeared on MCU & FPGA.