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.