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.

O que é um RTOS?

Um Real-Time Operating System (RTOS) é um sistema operacional projetado para executar tarefas dentro de restrições de tempo rigorosas, garantindo previsibilidade e determinismo. Em contraste com sistemas operacionais tradicionais, como Windows e Linux, um RTOS é otimizado para aplicações embarcadas que exigem resposta rápida e controle preciso de eventos.

Os RTOS são amplamente utilizados em sistemas embarcados, como automação industrial, dispositivos médicos, sistemas automotivos, redes de comunicação e eletrônicos de consumo. Eles oferecem mecanismos como agendamento de tarefas, gerenciamento de interrupções, sincronização entre tarefas e controle de memória, permitindo que microcontroladores executem múltiplas funções de maneira eficiente.

Diferença entre um RTOS e um Sistema Operacional Convencional

Os sistemas operacionais convencionais (como Windows, Linux ou macOS) utilizam escalonamento baseado em prioridades dinâmicas e fairness, garantindo que todas as aplicações tenham a oportunidade de serem executadas. Já um RTOS utiliza escalonamento baseado em prioridades fixas ou tempo real, garantindo que tarefas críticas sejam sempre executadas dentro de seus prazos.

A principal diferença entre eles pode ser vista na forma como tratam tarefas urgentes:

A escolha entre um RTOS e um sistema operacional tradicional depende das exigências temporais do sistema. Aplicações que necessitam garantir que tarefas sejam executadas em momentos específicos geralmente utilizam um RTOS.

Principais RTOS para Microcontroladores

Existem diversos RTOS disponíveis para microcontroladores, cada um com características específicas que os tornam mais adequados para determinadas aplicações. Alguns são de código aberto e gratuitos, enquanto outros são comerciais e oferecem suporte premium. Abaixo, analisamos os RTOS mais populares e em quais microcontroladores são mais utilizados.

1. FreeRTOS

Descrição: O FreeRTOS é um dos RTOS mais populares e amplamente utilizados no mundo dos microcontroladores. Ele é de código aberto, possui uma grande comunidade e é altamente modular, permitindo que os desenvolvedores escolham apenas os componentes necessários para otimizar o uso de recursos.

Principais Características:

• Kernel leve e de baixa latência.
• Suporte a multitarefa preemptiva e cooperativa.
• Gerenciamento eficiente de filas e semáforos.
• Portado para diversas arquiteturas, incluindo ARM Cortex-M, RISC-V, ESP32, AVR, STM32, PIC32, entre outros.
• Suporte oficial pela Amazon AWS, permitindo integração com serviços em nuvem.

Microcontroladores mais comuns:

• STM32 (Cortex-M)
• ESP32 (Xtensa LX6 e RISC-V)
• Microchip PIC32
• Atmel AVR
• NXP LPC (Cortex-M)
• TI MSP430 e TM4C

2. Zephyr OS

Descrição: O Zephyr OS é um RTOS open-source mantido pela Linux Foundation, projetado para ser seguro, modular e escalável. É uma excelente opção para aplicações IoT, oferecendo suporte a protocolos de comunicação modernos e segurança aprimorada.

Principais Características:

• Núcleo modular e altamente configurável.
• Segurança integrada, seguindo boas práticas de desenvolvimento seguro.
• Suporte nativo a Bluetooth, Wi-Fi e LoRa.
• Compatível com a API POSIX, facilitando a portabilidade de código.
• Modelo de desenvolvimento baseado em Device Tree, semelhante ao Linux.

Microcontroladores mais comuns:

• STM32 (Cortex-M)
• NXP i.MX RT (Cortex-M)
• Nordic nRF52 (Bluetooth LE)
• Espressif ESP32
• RISC-V (SiFive, Kendryte K210)

3. RTEMS (Real-Time Executive for Multiprocessor Systems)

Descrição: O RTEMS é um RTOS de código aberto voltado para sistemas embarcados críticos e de alta confiabilidade. Ele é muito utilizado em aplicações aeroespaciais, defesa e indústria.

Principais Características:

• Certificável para segurança e confiabilidade, com uso em missões espaciais da NASA e ESA.
• Suporte a multitarefa preemptiva e gerenciamento avançado de memória.
• Compatível com diversas arquiteturas, incluindo ARM, PowerPC, SPARC e RISC-V.
• Ampla compatibilidade com APIs POSIX e suporte a networking TCP/IP.

Microcontroladores mais comuns:

• ARM Cortex-M e Cortex-A
• Microchip SAM (ARM)
• PowerPC (usado em sistemas aeroespaciais)
• SPARC (utilizado em satélites e sistemas espaciais)
• RISC-V

4. ThreadX (Azure RTOS)

Descrição: O ThreadX é um RTOS comercial desenvolvido pela Express Logic e adquirido pela Microsoft. Ele faz parte do Azure RTOS, sendo altamente otimizado para aplicações conectadas à nuvem.

Principais Características:

• Baixa latência e alto desempenho.
• Escalonador de tarefas eficiente e determinístico.
• Compatível com sistemas multicore.
• Integração nativa com Microsoft Azure IoT.
• Usado em aplicações médicas, industriais e automotivas.

Microcontroladores mais comuns:

• STM32 (usado oficialmente pela ST Microelectronics)
• NXP i.MX RT
• Renesas RX e Synergy
• Microchip PIC32
• TI Sitara (Cortex-A)

5. NuttX

Descrição: O NuttX é um RTOS compatível com POSIX, projetado para ser leve e oferecer funcionalidades avançadas encontradas em sistemas operacionais completos. Ele é usado em dispositivos como drones da DJI e wearables.

Principais Características:

• Baixo consumo de memória e compatibilidade POSIX.
• Suporte a múltiplos sistemas de arquivos, incluindo FAT, NFS e SmartFS.
• Gerenciamento de energia otimizado.
• Interface compatível com Linux, facilitando a portabilidade de aplicativos.

Microcontroladores mais comuns:

• STM32 (diversas variantes)
• ESP32
• Nordic nRF52
• RISC-V (SiFive, Bouffalo Lab)

6. µC/OS (Micrium OS)

Descrição: O µC/OS é um RTOS de alto desempenho e segurança, com certificação para uso em aplicações médicas e automotivas. Ele é comercializado pela Silicon Labs.

Principais Características:

• Determinismo e previsibilidade elevados.
• Compatível com sistemas críticos e certificáveis.
• Multitarefa preemptiva com suporte a gerenciamento de memória avançado.
• Integração com stacks de rede e sistema de arquivos robustos.

Microcontroladores mais comuns:

• STM32
• NXP Kinetis
• Renesas RX
• Microchip SAM e PIC32

Comparação entre os RTOS mais populares

A escolha do RTOS adequado depende das exigências do projeto. O FreeRTOS é ideal para sistemas pequenos e de código aberto, enquanto o Zephyr OS é excelente para IoT. Se o projeto requer certificação para segurança e confiabilidade, opções como RTEMS e µC/OS são mais apropriadas. Já o ThreadX, com integração ao Azure, é uma excelente opção para dispositivos conectados.

Critérios de Escolha de um RTOS para Microcontroladores

A escolha de um Real-Time Operating System (RTOS) adequado para um microcontrolador depende de diversos fatores técnicos e operacionais. A seguir, analisamos os principais critérios que devem ser considerados ao selecionar um RTOS para um sistema embarcado.

1. Requisitos de Tempo Real

Um dos aspectos mais críticos ao escolher um RTOS é entender o tipo de restrição de tempo do sistema:

• Soft Real-Time: O sistema pode tolerar pequenos atrasos ocasionais. Exemplo: áudio e vídeo em streaming.
• Firm Real-Time: O atraso ocasional não causa falha catastrófica, mas deve ser minimizado. Exemplo: controle de motores industriais.
• Hard Real-Time: Cada tarefa deve ser executada estritamente dentro de seu prazo; qualquer atraso pode levar a falhas severas. Exemplo: sistemas médicos e aeroespaciais.

Exemplo de escolha:
Se o sistema exige Hard Real-Time, opções como RTEMS e µC/OS são ideais. Se for um sistema Soft Real-Time, FreeRTOS e Zephyr OS podem ser mais adequados.

2. Suporte à Arquitetura do Microcontrolador

Cada RTOS oferece suporte a diferentes famílias de microcontroladores. Antes de escolher um, é fundamental verificar a compatibilidade com a arquitetura do hardware:

• ARM Cortex-M (STM32, NXP, Microchip, TI) → FreeRTOS, Zephyr OS, ThreadX, µC/OS.
• ESP32 (Xtensa LX6, RISC-V) → FreeRTOS, Zephyr OS, NuttX.
• AVR (Atmel, Microchip) → FreeRTOS, NuttX.
• PowerPC, SPARC (usados em aplicações aeroespaciais) → RTEMS.
• RISC-V (SiFive, Kendryte K210, Bouffalo Lab) → Zephyr OS, FreeRTOS, NuttX.

Exemplo de escolha:
Se o sistema utiliza STM32 (ARM Cortex-M), FreeRTOS e ThreadX são opções ideais. Para ESP32, o FreeRTOS já vem integrado no framework ESP-IDF.

3. Uso de Recursos (Memória RAM e Flash)

Cada RTOS tem um overhead de memória diferente. Para microcontroladores com poucos recursos, um RTOS leve é essencial.

• Microcontroladores com pouca RAM (< 16 KB) → FreeRTOS, NuttX.
• Microcontroladores intermediários (16 KB a 512 KB de RAM) → Zephyr OS, µC/OS.
• Microcontroladores avançados (> 512 KB de RAM, processadores de 32 bits) → ThreadX, RTEMS.

Exemplo de escolha:
Se o microcontrolador possui apenas 32 KB de RAM, o FreeRTOS ou NuttX são opções viáveis. Se houver mais memória disponível, o Zephyr OS pode ser utilizado para aplicações IoT.

4. Tipo de Escalonamento e Gerenciamento de Tarefas

O modo como o RTOS gerencia as tarefas afeta a previsibilidade e desempenho do sistema:

• Preemptivo: Tarefas de maior prioridade interrompem tarefas de menor prioridade. Ideal para sistemas de tempo real estrito.
• Cooperativo: As tarefas só liberam o processador voluntariamente. Útil para sistemas simples e de baixo consumo de energia.
• Round-Robin: Todas as tarefas recebem tempo de CPU de forma equitativa.
• Escalonamento baseado em eventos: Permite melhor eficiência energética e resposta rápida a interrupções.

Exemplo de escolha:
Se o sistema precisa de baixa latência e alta previsibilidade, o ThreadX ou µC/OS são ideais, pois oferecem escalonamento preemptivo determinístico.

5. Comunicação entre Tarefas (IPC)

Para sistemas embarcados multitarefa, o RTOS deve oferecer mecanismos eficientes de comunicação entre as tarefas:

• Filas (Message Queues) → Envio de mensagens entre tarefas.
• Semáforos e Mutexes → Controle de acesso a recursos compartilhados.
• Eventos e Sinais → Sincronização de tarefas em tempo real.

Exemplo de escolha:
Se o projeto envolve múltiplas tarefas interagindo constantemente, como em sistemas industriais, um RTOS como Zephyr OS ou RTEMS pode ser mais eficiente devido ao suporte avançado a IPC.

6. Suporte a Pilhas de Rede e Comunicação

Se o sistema precisar de conectividade, é necessário um RTOS que ofereça suporte a protocolos de rede, como:

• Ethernet e TCP/IP → Zephyr OS, FreeRTOS+TCP, NuttX.
• Wi-Fi e Bluetooth → Zephyr OS, FreeRTOS (ESP-IDF).
• LoRa e Zigbee → Zephyr OS.
• Modbus, CAN, RS-485 → FreeRTOS, NuttX.

Exemplo de escolha:
Se o microcontrolador precisa se comunicar via Wi-Fi e MQTT, o Zephyr OS ou FreeRTOS são boas opções.

7. Certificações e Segurança

Algumas aplicações exigem certificação para segurança e confiabilidade, especialmente em setores como automotivo, aeroespacial e médico:

Exemplo de escolha:
Se o sistema precisa de certificação ISO 26262 para automotivos, o µC/OS ou uma versão certificada do FreeRTOS são opções adequadas.

8. Licenciamento e Custos

Os RTOS podem ser gratuitos (open-source) ou comerciais (licenciamento pago):

• Open-source e gratuitos:
  • FreeRTOS (MIT License)
  • Zephyr OS (Apache 2.0)
  • RTEMS (GPL)
  • NuttX (Apache 2.0)
• Comerciais (pagos, com suporte premium):
  • ThreadX (Azure RTOS)
  • µC/OS (Silicon Labs)
  • QNX Neutrino RTOS (usado em automotivos)

Exemplo de escolha:
Se o projeto requer baixo custo e flexibilidade, o FreeRTOS ou Zephyr OS são boas opções. Se for um sistema crítico que exige suporte dedicado, um RTOS comercial pode ser mais adequado.

A escolha de um RTOS adequado deve levar em consideração diversos fatores, como requisitos de tempo real, consumo de recursos, escalonamento, comunicação entre tarefas e certificações. Não existe um RTOS universalmente melhor — a decisão deve ser baseada nas exigências do sistema e nas características do microcontrolador.

Implementação e Boas Práticas no Uso de RTOS em Microcontroladores

Após a escolha do Real-Time Operating System (RTOS) adequado, a implementação eficiente do sistema é essencial para garantir desempenho, estabilidade e previsibilidade. Nesta seção, abordamos as melhores práticas para a implementação de um RTOS em microcontroladores, desde a configuração inicial até a otimização do sistema.

1. Configuração Inicial do RTOS

Cada RTOS exige um processo de configuração antes do uso. Normalmente, é necessário ajustar parâmetros como o tamanho das pilhas de tarefas, a prioridade dos processos e a memória disponível.

Passos básicos para configurar um RTOS:

1. Definir a Tabela de Tarefas: Identificar todas as tarefas do sistema e definir suas prioridades.
2. Configurar o Timer do Sistema (SysTick): O RTOS utiliza um temporizador para gerenciar mudanças de contexto.
3. Ajustar o Tamanho das Pilhas: Cada tarefa tem sua pilha de execução, e definir um tamanho adequado evita estouros de pilha.
4. Selecionar o Mecanismo de Escalonamento: Escolher entre preemptivo, cooperativo ou round-robin conforme as necessidades do projeto.
5. Habilitar Mecanismos de Sincronização: Configurar semáforos, mutexes e filas de mensagens para comunicação entre tarefas.
6. Ativar o Gerenciamento de Memória Dinâmica: Muitos RTOS oferecem alocadores dinâmicos otimizados para sistemas embarcados.

Exemplo no FreeRTOS (Configuração do SysTick no STM32):

void SysTick_Handler(void) {
    HAL_IncTick();       // Atualiza o contador de tempo do HAL (se necessário)
    osSystickHandler();  // Atualiza o RTOS
}

Dica: O uso do SysTick para multitarefa pode impactar outras funções do microcontrolador, como o HAL da STMicroelectronics. É importante verificar se não há conflitos.

2. Estruturação do Código para um RTOS

Um código bem estruturado melhora a manutenção, facilita a depuração e reduz erros de escalonamento.

Boas práticas para organização do código:

• Separar cada tarefa em arquivos próprios (task_sensor.c, task_comunicacao.c).
• Usar funções de inicialização separadas para evitar código redundante.
• Definir constantes e macros no arquivo de configuração (config.h).
• Manter tarefas leves, delegando o máximo possível para interrupções.

Exemplo de Estrutura para um Projeto com FreeRTOS:

/Projeto_RTOS
├── main.c
├── config.h
├── tasks/
│   ├── task_sensor.c
│   ├── task_comunicacao.c
│   ├── task_interface.c
└── drivers/
    ├── sensor_driver.c
    ├── uart_driver.c

3. Uso Eficiente de Tarefas

Criar tarefas de forma descontrolada pode levar a alto consumo de memória e dificuldades de depuração.

Dicas para criar tarefas corretamente:

Evite muitas tarefas simultâneas: Em microcontroladores com menos de 256 KB de RAM, limite-se a 5-8 tarefas ativas.
Atribua prioridades com cuidado: Uma prioridade mal ajustada pode causar inversão de prioridade.
Use delays e bloqueios com inteligência: O uso excessivo de vTaskDelay() pode desperdiçar CPU.

Exemplo de Criação de uma Tarefa no FreeRTOS:

void Task_Sensor(void *pvParameters) {
    while (1) {
        int valor = Ler_Sensor();
        Enviar_Para_Interface(valor);
        vTaskDelay(pdMS_TO_TICKS(100));  // Aguarda 100ms antes da próxima leitura
    }
}

void Criar_Tarefa_Sensor(void) {
    xTaskCreate(Task_Sensor, "Sensor", 128, NULL, 2, NULL);
}

4. Sincronização e Comunicação entre Tarefas

A troca de informações entre tarefas deve ser bem planejada para evitar deadlocks e corridas críticas.

Mecanismos de Sincronização:

Exemplo de uso de Semáforo para Sincronização:

SemaphoreHandle_t xSemaforo;

void ISR_Handler(void) {
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    xSemaphoreGiveFromISR(xSemaforo, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

void Task_Controle(void *pvParameters) {
    while (1) {
        xSemaphoreTake(xSemaforo, portMAX_DELAY);  // Aguarda sinal da interrupção
        Executar_Acao();
    }
}

5. Tratamento de Interrupções no RTOS

Interrupções são fundamentais em sistemas embarcados, mas seu uso em conjunto com um RTOS deve ser bem planejado.

Boas Práticas para Interrupções:

Mantenha interrupções curtas: Processamentos demorados devem ser feitos em tarefas.
Use “Deferred Interrupt Processing”: A interrupção apenas notifica uma tarefa para processar os dados.
Evite chamar funções do RTOS dentro de interrupções: Se necessário, use as versões FromISR, como xQueueSendFromISR().

Exemplo de Interrupção Notificando uma Tarefa:

void ISR_ADC_Handler(void) {
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    int resultado = Ler_ADC();
    xQueueSendFromISR(xQueueADC, &resultado, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

6. Monitoramento e Depuração de um RTOS

A depuração de sistemas embarcados com RTOS pode ser mais complexa do que em sistemas bare-metal. Para isso, existem algumas abordagens eficazes:

Ferramentas de Monitoramento:

• Percepio Tracealyzer → Visualiza tarefas, filas e semáforos em tempo real.
• Segger SystemView → Permite análise detalhada do funcionamento do RTOS.
• GDB com OpenOCD → Depuração com breakpoints e inspeção de registradores.

Métricas Importantes para Monitoramento:

Exemplo de Monitoramento no FreeRTOS:

vTaskGetRunTimeStats(buffer);
printf("Tempo de execução das tarefas:\n%s", buffer);

Implementar um RTOS corretamente exige planejamento e boas práticas para garantir um sistema eficiente, estável e confiável. A correta alocação de tarefas, o uso inteligente de mecanismos de sincronização e a monitoração contínua do sistema são essenciais para evitar problemas como deadlocks, starvation e alta latência.

Conclusão e Comparação Final dos RTOS para Microcontroladores

Ao longo deste artigo, exploramos os principais RTOS (Real-Time Operating Systems) para microcontroladores, seus critérios de escolha, boas práticas de implementação e desafios comuns. A decisão de adotar um RTOS deve sempre considerar os requisitos do projeto, como tempo real, consumo de memória, escalabilidade e suporte à arquitetura do hardware.

A tabela abaixo resume as principais características dos RTOS discutidos:

Resumo Comparativo dos RTOS

Principais Considerações na Escolha de um RTOS

• Projetos leves e flexíveis → FreeRTOS e NuttX são opções ideais.
• Sistemas IoT e conectividade → Zephyr OS se destaca pelo suporte avançado.
• Aplicações aeroespaciais e críticas → RTEMS e µC/OS são certificados para segurança.
• Integração com a nuvem → ThreadX (Azure RTOS) oferece suporte nativo ao Microsoft Azure.

Conclusão

A escolha de um RTOS não deve ser baseada apenas na popularidade, mas sim na adequação às necessidades específicas do projeto. A correta configuração e implementação do RTOS são fundamentais para garantir baixo consumo de recursos, alta confiabilidade e determinismo. Além disso, monitoramento e depuração contínuos são essenciais para manter o desempenho do sistema.

The post Introdução aos RTOS para Microcontroladores first appeared on MCU & FPGA.