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.

Como Funciona

Imagine caminhar por um labirinto com a mão encostada sempre à parede da direita. Se houver um caminho à direita, vire à direita. Caso contrário, se à frente for possível, siga em frente. Se à frente não for possível, vire à esquerda até encontrar uma direção livre. Essa técnica garante a saída de qualquer labirinto que seja simplesmente conexo (sem loops desconectados ou “ilhas”).

Aplicação no Controle de Robôs

Num robô com dois motores — um para a roda esquerda e outro para a direita — podemos implementar esse algoritmo controlando a direção com base nas leituras de sensores que detectam parede à direita, à frente e à esquerda. A função que aciona os motores será controle_motor(int8_t motor_esq, int8_t motor_dir), onde valores positivos movem o motor para frente e negativos para trás.

Exemplo:

• controle_motor(100, 100); → anda para frente.
• controle_motor(-100, 100); → gira para a esquerda.
• controle_motor(100, -100); → gira para a direita.

Código em C (Simplificado)

Aqui está uma simulação básica do algoritmo, assumindo funções fictícias de leitura de sensores:

#include <stdint.h>
#include <stdbool.h>

// Protótipo da função de controle do motor
void controle_motor(int8_t motor_esq, int8_t motor_dir);

// Protótipos de sensores (implementação depende do hardware)
bool parede_direita();
bool parede_frente();
bool parede_esquerda();

// Ações básicas
void andar_frente() {
    controle_motor(100, 100);
}

void girar_direita() {
    controle_motor(100, -100);
}

void girar_esquerda() {
    controle_motor(-100, 100);
}

void parar() {
    controle_motor(0, 0);
}

// Loop principal
void resolver_labirinto() {
    while (true) {
        if (!parede_direita()) {
            // Gira para a direita e anda
            girar_direita();
        } else if (!parede_frente()) {
            andar_frente();
        } else {
            // Enquanto houver parede à frente, girar à esquerda
            while (parede_frente()) {
                girar_esquerda();
            }
        }
        // Pequeno atraso ou leitura de sensores para próxima decisão
    }
}

• O algoritmo da mão direita não funciona em labirintos com “ilhas” ou passagens desconectadas.
• É simples de implementar em microcontroladores e ideal para robôs iniciantes.
• Pode ser complementado com sensores infravermelhos ou ultrassônicos para detecção de paredes.
• É um bom ponto de partida para algoritmos mais avançados como DFS, BFS ou A*.

The post Algoritmo da Mão Direita para Solução de Labirintos 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.

Introdução ao Cortex-M

Os microcontroladores Cortex-M são uma família de processadores projetados pela ARM, voltados para sistemas embarcados. Seu foco principal é oferecer alto desempenho, baixo consumo de energia e facilidade de programação, tornando-os amplamente utilizados em aplicações como automação industrial, dispositivos IoT, sistemas automotivos e equipamentos médicos.

Diferentemente de outras arquiteturas da ARM, o Cortex-M se concentra em eficiência energética e simplicidade, eliminando recursos complexos como unidades de gerenciamento de memória (MMU) e otimizando a execução de instruções para tempo real. Com suporte à arquitetura RISC e um conjunto de instruções (ISA) otimizado, esses microcontroladores são ideais para aplicações embarcadas críticas.

A família Cortex-M inclui diferentes versões, cada uma voltada para um nicho específico, variando em desempenho, consumo e recursos avançados. Nos próximos tópicos, detalharemos cada uma dessas versões e suas características.

Estrutura do Conjunto de Instruções (ISA)

O Cortex-M adota a arquitetura ARMv6-M, ARMv7-M e ARMv8-M, dependendo da versão do processador. As principais características do ISA incluem:

• Thumb e Thumb-2: Usa um conjunto de instruções compactas de 16 bits para eficiência em memória, com extensão para 32 bits para maior flexibilidade.
• Pipeline Otimizado: Implementação de pipeline de 3 estágios (fetch, decode, execute) ou mais, conforme o modelo, para melhor aproveitamento do tempo de execução.
• Instruções de Multiplicação e Divisão: Algumas versões incluem suporte nativo para operações matemáticas otimizadas.
• Manipulação de Interrupções Eficiente: Utiliza o NVIC (Nested Vectored Interrupt Controller) para gerenciamento rápido e eficiente de interrupções.
• Modo de Execução e Privacidade: Suporte a diferentes níveis de privilégio (usuário e supervisor) para segurança e proteção da memória.

O ISA do Cortex-M é projetado para ser eficiente e simples de programar, tornando-o ideal para aplicações de tempo real e sistemas embarcados de baixo consumo.

Estrutura de Barramentos

Os microcontroladores Cortex-M adotam uma estrutura de barramentos baseada na tecnologia AMBA (Advanced Microcontroller Bus Architecture), que facilita a comunicação entre os diferentes módulos internos do microcontrolador. Os principais barramentos incluem:

• AHB-Lite (Advanced High-Performance Bus Lite): Usado para comunicação de alta velocidade entre o núcleo do processador e os periféricos.
• APB (Advanced Peripheral Bus): Empregado para conectar periféricos de baixa velocidade, como temporizadores, GPIOs e interfaces seriais.
• ITM (Instrumentation Trace Macrocell): Um barramento especializado para depuração e rastreamento de código.
• DWT (Data Watchpoint and Trace): Oferece monitoramento avançado de execução de código e eventos internos.

Essa estrutura permite uma comunicação eficiente e minimiza o consumo de energia, garantindo um desempenho ideal para aplicações de tempo real.

Modelos do Cortex-M

Cada variante do Cortex-M é projetada para um conjunto específico de aplicações. Vamos explorar as principais características de cada modelo.

Cortex-M0 e Cortex-M0+

• Aplicações: Dispositivos IoT, sensores, automação residencial, wearables.
• Recursos:
  • Processador de 32 bits de ultra-baixo consumo.
  • Arquitetura ARMv6-M.
  • Suporte a instruções Thumb.
  • Sem unidade de ponto flutuante (FPU).
  • Pipeline de 3 estágios.

O Cortex-M0+ traz pequenas melhorias em relação ao M0, como menor latência de interrupção e menor consumo de energia.

Cortex-M1

• Aplicações: FPGA (Field Programmable Gate Array).
• Recursos:
  • Núcleo flexível e configurável.
  • Pode ser implementado em FPGA para aplicações customizadas.
  • Similar ao Cortex-M0, mas otimizado para hardware reconfigurável.

Cortex-M3

• Aplicações: Controle industrial, automação, telecomunicações.
• Recursos:
  • Arquitetura ARMv7-M.
  • Suporte a instruções Thumb-2.
  • Pipeline de 3 estágios para execução eficiente.
  • Controle avançado de interrupções via NVIC.
  • Melhor desempenho que Cortex-M0, mantendo baixo consumo.

Cortex-M4

• Aplicações: Processamento de sinais, controle motor, aplicações médicas.
• Recursos:
  • Baseado no Cortex-M3 com adição de FPU (Unidade de Ponto Flutuante) e DSP (Digital Signal Processing).
  • Arquitetura ARMv7E-M.
  • Suporte a instruções SIMD (Single Instruction Multiple Data).
  • Pipeline de 3 estágios com otimização para cálculos matemáticos.

Cortex-M7

• Aplicações: Sistemas embarcados de alto desempenho, áudio e processamento intensivo.
• Recursos:
  • Arquitetura ARMv7E-M com otimizações adicionais.
  • Suporte avançado a DSP e FPU dupla precisão.
  • Pipeline de 6 estágios para maior desempenho.
  • Cache L1 para maior eficiência no acesso à memória.

Cortex-M23 e Cortex-M33

• Aplicações: Segurança embarcada, IoT, criptografia.
• Recursos:
  • Baseados na arquitetura ARMv8-M.
  • Suporte ao TrustZone, que permite execução segura de código.
  • Melhorias em consumo energético e segurança.

Cortex-M55

• Aplicações: Machine learning, visão computacional.
• Recursos:
  • Primeira CPU Cortex-M com suporte ao Helium, um conjunto de instruções otimizadas para IA e DSP.
  • Arquitetura ARMv8.1-M.
  • Alta eficiência em processamento de dados.

O Cortex-M é uma das arquiteturas mais populares para microcontroladores, oferecendo uma variedade de modelos para atender a diferentes necessidades. Com seu conjunto de instruções eficiente, suporte a processamento de sinais e otimizações para tempo real, esses microcontroladores são amplamente utilizados em aplicações industriais, médicas, automotivas e de IoT.

Antes de escolher um modelo, é importante analisar os requisitos da aplicação e os recursos oferecidos por cada variante do Cortex-M. Se precisar de alta eficiência energética, o Cortex-M0 ou M0+ são boas escolhas. Para aplicações que exigem alto desempenho matemático, o Cortex-M4, M7 ou M55 são os mais indicados.

Ótimo! Agora que cobrimos a introdução, o conjunto de instruções (ISA) e a estrutura de barramentos, podemos avançar para a próxima seção.

Arquitetura Interna do Cortex-M

Agora que entendemos os modelos do Cortex-M, sua ISA e barramentos, vamos explorar sua arquitetura interna. Essa seção detalha como os componentes internos trabalham para garantir alto desempenho, baixo consumo de energia e eficiência na execução de código.

Pipeline e Unidade de Execução

Os microcontroladores Cortex-M utilizam pipelines otimizados para melhorar a eficiência do processamento. Dependendo do modelo, o pipeline pode variar:

• Cortex-M0/M0+/M1 → Pipeline de 2 ou 3 estágios (Fetch, Decode, Execute)
• Cortex-M3/M4/M33 → Pipeline de 3 estágios (Fetch, Decode, Execute)
• Cortex-M7 → Pipeline de 6 estágios (Fetch, Decode, Issue, Execute, Memory, Writeback)

Como Funciona o Pipeline?

1. Fetch (Busca): A unidade de busca lê a próxima instrução da memória Flash/RAM.
2. Decode (Decodificação): O decodificador interpreta a instrução e prepara a unidade de execução.
3. Execute (Execução): A instrução é processada e pode acessar registradores ou a memória.

No Cortex-M7, o pipeline expandido permite que múltiplas instruções sejam processadas simultaneamente, aumentando o desempenho geral.

Vantagem: Minimiza os ciclos de espera e aumenta a eficiência energética ao otimizar o fluxo de execução.

Controle de Interrupções com NVIC

O NVIC (Nested Vectored Interrupt Controller) é um componente fundamental no Cortex-M, permitindo gerenciamento rápido e eficiente de interrupções. Ele suporta:

• Priorização de interrupções: Cada interrupção tem um nível de prioridade, permitindo que eventos críticos sejam tratados primeiro.
• Interrupções aninhadas: Se uma interrupção de alta prioridade ocorre enquanto outra de menor prioridade está ativa, a CPU suspende a interrupção de menor prioridade para tratar a mais urgente.
• Vetorização automática: Cada interrupção é automaticamente direcionada para sua rotina de tratamento sem necessidade de verificações manuais.

Benefícios do NVIC

• Latência reduzida: Troca de contexto rápida para respostas imediatas a eventos externos.
• Baixo consumo de energia: O processador pode entrar em estados de baixo consumo (Sleep, Deep Sleep) e ser acordado por interrupções.

Curiosidade: O Cortex-M implementa interrupções do tipo hardware (mais rápidas) em vez de interrupções por polling (software), melhorando eficiência.

Modos de Execução e Segurança

Os processadores Cortex-M suportam diferentes modos de execução, que controlam o nível de acesso aos recursos do sistema.

Modos de Execução

• Modo Privilegiado: Acesso total ao hardware, podendo configurar periféricos e alterar estados do processador.
• Modo Não-Privilegiado: Restringe acesso a algumas operações críticas, usado para aplicações com segurança reforçada.

Importância: Implementação do modelo “supervisor e usuário” para segurança em sistemas operacionais embarcados.

ARM TrustZone (Cortex-M23 e Cortex-M33)

O TrustZone é um mecanismo que permite dividir o sistema em duas regiões:

• Secure World: Processamento seguro, usado para criptografia e proteção de dados sensíveis.
• Non-Secure World: Código de aplicação normal, sem acesso a recursos críticos.

Vantagem: Permite isolar firmware seguro de aplicativos menos confiáveis, ideal para IoT e aplicações críticas.

Gerenciamento de Memória e MPU

A MPU (Memory Protection Unit) está presente em modelos como Cortex-M3, M4, M7, M23 e M33. Ela permite configurar regiões de memória com diferentes permissões de acesso.

Recursos da MPU

• Proteção de memória: Evita acesso não autorizado a regiões críticas.
• Segmentação: Configuração de até 8 regiões de memória com permissões distintas.
• Execução segura: Evita execução de código em áreas de dados (proteção contra ataques de buffer overflow).

Exemplo de uso: Em sistemas embarcados com RTOS, a MPU pode restringir cada tarefa a uma área específica da memória, prevenindo corrupção de dados.

Depuração e Rastreamento (ITM, DWT, ETM)

Os processadores Cortex-M oferecem diversas ferramentas para debug e rastreamento de execução:

ITM (Instrumentation Trace Macrocell)

Permite a transmissão de eventos e mensagens de debug via barramento SWO (Single Wire Output). Pode ser usado para:

• Monitoramento em tempo real sem interromper a execução.
• Envio de mensagens de log diretamente para um software de análise.

DWT (Data Watchpoint and Trace)

Habilita pontos de interrupção de hardware e monitora acessos a registradores e memória. Pode ser usado para:

• Medir tempo de execução de funções (profiling).
• Detectar corrupção de memória por acesso indevido.

ETM (Embedded Trace Macrocell)

Presente no Cortex-M3, M4 e M7, permite rastreamento detalhado do código em tempo real sem impacto significativo no desempenho.

Benefício: Ferramentas de debug avançadas permitem detectar falhas antes da implantação do firmware.

A arquitetura interna do Cortex-M foi projetada para oferecer um balanceamento ideal entre desempenho, consumo energético e flexibilidade. Recursos como pipeline otimizado, controle de interrupções eficiente, modos de segurança e ferramentas avançadas de depuração tornam essa família de microcontroladores uma das mais utilizadas no mercado embarcado.

Ótimo! Agora vamos avançar para a próxima seção: exemplos práticos de uso do Cortex-M em aplicações reais.

Nesta seção, abordaremos:

• Sistemas de Controle Industrial (Cortex-M4 e M7)
• IoT e Automação Residencial (Cortex-M0/M0+)
• Processamento de Áudio e Sinais (Cortex-M4 e M55)
• Aplicações Automotivas e Sensores (Cortex-M3/M4)
• Sistemas Críticos e Segurança (Cortex-M33 com TrustZone)

Vou preparar esse conteúdo e já te apresento para revisão!

Exemplos Práticos de Uso do Cortex-M em Aplicações Reais

Os microcontroladores Cortex-M são amplamente utilizados em diversas áreas da indústria e tecnologia devido à sua eficiência energética, flexibilidade e recursos de processamento. Nesta seção, vamos explorar aplicações práticas que demonstram o impacto e a versatilidade dessa arquitetura.

Sistemas de Controle Industrial (Cortex-M4 e M7)

Os microcontroladores Cortex-M4 e M7 são ideais para controle de motores, automação industrial e sistemas de tempo real, devido ao seu alto desempenho e suporte a processamento de sinais.

Exemplo: Controle de Motores em Máquinas Industriais

• Requisitos:
  • Precisão no controle de velocidade e torque.
  • Baixa latência na resposta a sensores.
  • Capacidade de realizar cálculos complexos de controle.
• Por que usar Cortex-M?
  • O Cortex-M4 oferece suporte a instruções DSP, permitindo o uso de algoritmos avançados como controle PID e FOC (Field Oriented Control).
  • O Cortex-M7 adiciona FPU de dupla precisão e cache L1, permitindo tempos de resposta mais rápidos para aplicações que exigem cálculos intensivos.
• Caso de uso real:
  • Em robôs industriais, sensores de corrente e tensão monitoram o motor, e um Cortex-M4 executa algoritmos para ajustar o torque e evitar superaquecimento.

Benefício: Processamento eficiente com baixo consumo de energia, permitindo controle preciso e seguro de motores industriais.

IoT e Automação Residencial (Cortex-M0/M0+)

O Cortex-M0 e M0+ são amplamente utilizados em dispositivos IoT (Internet das Coisas) devido ao seu baixo consumo de energia e simplicidade.

Exemplo: Sensores Inteligentes para Automação Residencial

• Requisitos:
  • Baixo consumo de energia para operação contínua em baterias.
  • Comunicação via protocolos sem fio (Bluetooth, Zigbee, LoRa).
  • Pequeno tamanho e custo reduzido.
• Por que usar Cortex-M?
  • O Cortex-M0+ tem um pipeline eficiente de 2 estágios, reduzindo o consumo de energia em comparação a modelos mais avançados.
  • Suporte nativo a modos de baixa energia, permitindo que sensores fiquem em deep sleep e só acordem quando necessário.
• Caso de uso real:
  • Em sensores de temperatura Wi-Fi para residências, um Cortex-M0+ coleta dados e os transmite para um servidor na nuvem apenas quando ocorre uma mudança significativa na temperatura.

Benefício: Eficiência energética e conectividade integrada para dispositivos compactos e de baixo custo.

Processamento de Áudio e Sinais (Cortex-M4 e M55)

Aplicações que envolvem reconhecimento de voz, áudio e análise de sinais exigem microcontroladores com suporte a DSP e IA.

Exemplo: Reconhecimento de Voz em Assistentes Inteligentes

• Requisitos:
  • Capacidade de processar sinais de áudio em tempo real.
  • Uso de algoritmos de filtragem e reconhecimento de padrões.
  • Suporte a inteligência artificial para melhorar a precisão.
• Por que usar Cortex-M?
  • O Cortex-M4 oferece instruções DSP, permitindo a execução eficiente de FFT (Fast Fourier Transform) para análise espectral.
  • O Cortex-M55 introduz o Helium, um conjunto de instruções otimizado para IA e processamento vetorial, ideal para redes neurais leves.
• Caso de uso real:
  • Em smart speakers como o Amazon Echo Dot, um Cortex-M55 pode ser usado para pré-processar comandos de voz antes de enviá-los para um servidor de IA.

Benefício: Execução de algoritmos de reconhecimento de voz localmente, reduzindo a necessidade de servidores externos e economizando largura de banda.

Aplicações Automotivas e Sensores (Cortex-M3/M4)

Os microcontroladores Cortex-M3 e M4 são amplamente usados na indústria automotiva para sensores de segurança, controle de motores e telemetria.

Exemplo: Monitoramento de Pressão dos Pneus (TPMS)

• Requisitos:
  • Sensoriamento preciso da pressão e temperatura dos pneus.
  • Baixo consumo de energia para operar continuamente.
  • Comunicação sem fio para envio de dados ao painel do veículo.
• Por que usar Cortex-M?
  • O Cortex-M3 é eficiente para lidar com múltiplas entradas de sensores e comunicação via CAN Bus.
  • O Cortex-M4 pode executar algoritmos para prever vazamentos com base em variações de pressão.
• Caso de uso real:
  • Em sistemas TPMS modernos, um Cortex-M3 coleta dados de sensores embutidos nos pneus e os transmite para o sistema de diagnóstico do carro.

Benefício: Melhor segurança ao motorista, permitindo alertas sobre perda de pressão antes que cause falhas mecânicas.

Sistemas Críticos e Segurança (Cortex-M33 com TrustZone)

Para aplicações que exigem segurança reforçada, o Cortex-M33 é a escolha ideal por oferecer suporte ao TrustZone.

Exemplo: Autenticação Segura em Cartões de Pagamento

• Requisitos:
  • Processamento de criptografia em tempo real.
  • Proteção contra ataques físicos e lógicos.
  • Isolamento seguro entre firmware e aplicações de terceiros.
• Por que usar Cortex-M?
  • O TrustZone permite separar a execução entre um ambiente seguro e um ambiente comum.
  • Suporte nativo a aceleração criptográfica, permitindo operações mais rápidas com menor consumo de energia.
• Caso de uso real:
  • Em cartões bancários com NFC, um Cortex-M33 pode gerenciar a autenticação segura de transações e proteger dados sensíveis.

Benefício: Maior proteção contra fraudes e clonagem de cartões, garantindo um ambiente seguro para transações financeiras.

Os microcontroladores Cortex-M são amplamente utilizados em diferentes setores, desde controle industrial e automação residencial até segurança embarcada e processamento de sinais. A escolha do modelo ideal depende dos requisitos da aplicação, como desempenho, consumo de energia e necessidade de segurança.

Programação e Otimização de Código para Cortex-M

A programação eficiente de microcontroladores Cortex-M exige um entendimento aprofundado de ferramentas de compilação, otimizações e estratégias de depuração. Nesta seção, exploraremos como configurar o ambiente de desenvolvimento, compilar código de forma otimizada e depurar aplicações embarcadas.

Configuração do Ambiente de Desenvolvimento

Os microcontroladores Cortex-M podem ser programados utilizando diversas ferramentas de compilação e ambientes de desenvolvimento. As principais opções incluem:

Compiladores e Toolchains

1. GCC for ARM (GNU Arm Embedded Toolchain)
   • Suporte robusto para Cortex-M0/M3/M4/M7.
   • Boa integração com Makefiles e CMake.
   • Ferramentas adicionais: arm-none-eabi-gcc, arm-none-eabi-objcopy, arm-none-eabi-gdb.
2. LLVM/Clang para ARM
   • Melhor otimização de código em alguns casos.
   • Excelente integração com LLVM LLD para linking eficiente.
   • Ferramentas como clang, lld, llvm-objdump, llvm-mca para análise de desempenho.
3. ARM Compiler 6 (Keil)
   • Otimizações avançadas para microcontroladores ARM.
   • Melhor suporte para Cortex-M55 com Helium.

Ambientes de Desenvolvimento (IDEs)

• Keil µVision: Melhor suporte a depuração para chips ARM, mas é pago.
• IAR Embedded Workbench: Compilador altamente otimizado, comum em sistemas industriais.
• Eclipse + GCC ARM Plugin: Opção gratuita e flexível, compatível com FreeRTOS.
• VS Code + PlatformIO: Alternativa moderna com suporte a múltiplos MCUs.

Recomendação: Para projetos abertos e desenvolvimento flexível, GCC for ARM é a melhor opção. Se precisar de máxima otimização, LLVM/Clang pode ser uma alternativa viável.

Compilação com GCC e LLVM para Cortex-M

Agora que escolhemos a ferramenta, vejamos como compilar um código simples para um Cortex-M4 usando GCC e LLVM.

Código Base (LED Blink)

Aqui está um exemplo básico de piscar um LED em um STM32 (Cortex-M4):

#include "stm32f4xx.h"

void delay(uint32_t count) {
    while (count--) __asm__("nop");
}

int main(void) {
    RCC->AHB1ENR |= (1 << 3);  // Habilita o clock do GPIOD
    GPIOD->MODER |= (1 << 26); // Configura o pino PD13 como saída

    while (1) {
        GPIOD->ODR ^= (1 << 13); // Alterna o estado do LED
        delay(500000);
    }
}

Compilando com GCC

O comando para compilar este código com GCC para um STM32F4 é:

arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -O2 -ffunction-sections -fdata-sections -T stm32f4.ld -o led_blink.elf led_blink.c

Explicação das flags:

• -mcpu=cortex-m4: Especifica a CPU alvo.
• -mthumb: Usa o conjunto de instruções Thumb para compactação de código.
• -O2: Aplica otimizações para velocidade sem comprometer a estabilidade.
• -ffunction-sections -fdata-sections: Remove código morto do binário final.
• -T stm32f4.ld: Utiliza um script de link especificando endereços de memória.

Otimização: Para reduzir ainda mais o tamanho, use -Os em vez de -O2.

Compilando com Clang/LLVM

Se preferir usar LLVM/Clang, a compilação pode ser feita com:

clang --target=arm-none-eabi -mcpu=cortex-m4 -mthumb -O2 -ffunction-sections -fdata-sections -T stm32f4.ld -o led_blink.elf led_blink.c

Benefício do Clang: Melhora o inlining de funções e tem um otimizador mais eficiente para Cortex-M.

Gerando o Binário para Gravação

Após a compilação, é necessário converter o .elf para .bin ou .hex:

arm-none-eabi-objcopy -O binary led_blink.elf led_blink.bin

Para gravar no microcontrolador, utilizamos:

st-flash write led_blink.bin 0x8000000

(Para STM32 usando ST-Link)

Otimizações de Código e Geração de Binários Eficientes

Otimizações Importantes

1. Redução de Código Mortoarm-none-eabi-gcc -flto -ffunction-sections -fdata-sections -Wl,--gc-sections
   • -flto: Link-time optimization para remover código não utilizado.
   • --gc-sections: Elimina funções e dados não referenciados.
2. Otimizações para Baixo Consumo de Energia
   • Utilize modo Sleep e Deep Sleep.
   • Reduza a frequência do clock nos momentos ociosos (HAL_PWR_EnterSLEEPMode).
3. Uso de SIMD no Cortex-M4/M7
   • Para DSP e processamento de sinais, ative instruções SIMD com -mfpu=fpv4-sp-d16 -mfloat-abi=hard.

Depuração e Profiling no Cortex-M

Além de compilar eficientemente, depuração e análise de desempenho são essenciais.

Depuração com GDB e OpenOCD

1. Inicie o OpenOCD para comunicação com ST-Link: openocd -f interface/stlink.cfg -f target/stm32f4x.cfg
2. Conecte-se com gdb: arm-none-eabi-gdb led_blink.elf
3. Dentro do GDB: target remote localhost:3333 monitor reset init load continue

Medição de Performance com DWT

Podemos usar o Data Watchpoint and Trace (DWT) para medir o tempo de execução de funções:

DWT->CTRL |= 1; // Ativar o contador de ciclos
DWT->CYCCNT = 0; // Resetar contador

start_cycles = DWT->CYCCNT;
algoritmo_intenso();
end_cycles = DWT->CYCCNT;

printf("Ciclos consumidos: %d\n", end_cycles - start_cycles);

Benefício: Permite otimizar algoritmos identificando gargalos no código.

A programação eficiente para Cortex-M requer: Escolher a ferramenta de compilação correta (GCC, LLVM ou Keil).
Otimizar o código com flags adequadas para reduzir tamanho e consumo.
Depurar e analisar desempenho usando GDB e DWT.

Uso de RTOS e Comunicação UART/SPI/I2C com FreeRTOS

Agora que cobrimos a programação otimizada para Cortex-M, vamos explorar como utilizar um RTOS (Real-Time Operating System) para gerenciar múltiplas tarefas e como integrar interfaces de comunicação como UART, SPI e I2C.

Introdução ao RTOS e FreeRTOS

Um RTOS (Real-Time Operating System) permite que um sistema embarcado gerencie múltiplas tarefas, garantindo que eventos críticos sejam atendidos com tempos previsíveis.

O FreeRTOS é um dos RTOS mais populares para Cortex-M devido à sua leveza e flexibilidade. Ele fornece:

• Escalonamento baseado em prioridades
• Troca de contexto eficiente
• Suporte para filas, semáforos e mutex
• Baixo consumo de memória

Vantagens de Usar um RTOS em Cortex-M

Melhor organização do código em tarefas separadas.
Facilidade para lidar com interrupções e eventos assíncronos.
Melhor controle do tempo de execução das funções críticas.

Configuração e Gerenciamento de Tarefas no FreeRTOS

Vamos criar um sistema multitarefa utilizando STM32 (Cortex-M4) com FreeRTOS.

Instalação do FreeRTOS

Se estiver usando GCC e Makefile, baixe o código-fonte:

git clone https://github.com/FreeRTOS/FreeRTOS-Kernel.git

Para STM32, use o CubeMX para configurar o FreeRTOS automaticamente.

Criando Tarefas no FreeRTOS

Exemplo de duas tarefas executando simultaneamente:

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

void task1(void *pvParameters) {
    while(1) {
        GPIOD->ODR ^= (1 << 13);  // Alterna LED
        vTaskDelay(pdMS_TO_TICKS(500));  // Aguarda 500ms
    }
}

void task2(void *pvParameters) {
    while(1) {
        printf("Executando tarefa 2...\n");
        vTaskDelay(pdMS_TO_TICKS(1000));  // Aguarda 1 segundo
    }
}

int main(void) {
    SystemInit();
    RCC->AHB1ENR |= (1 << 3); // Habilita clock do GPIOD

    xTaskCreate(task1, "LED Task", 128, NULL, 1, NULL);
    xTaskCreate(task2, "UART Task", 128, NULL, 2, NULL);
    
    vTaskStartScheduler();  // Inicia o escalonador
    while(1);
}

Explicação:

• xTaskCreate: Cria uma nova tarefa.
• vTaskDelay: Pausa a execução da tarefa para permitir que outras rodem.
• vTaskStartScheduler: Inicia o sistema operacional.

Gerenciamento de Prioridades

O FreeRTOS permite definir prioridades para cada tarefa. No exemplo acima:

• Tarefa 2 tem prioridade 2 (mais alta) e executa antes da tarefa 1.
• Tarefa 1 pisca um LED a cada 500ms.

Curiosidade: Em sistemas críticos, priorizar tarefas corretamente evita travamentos.

Comunicação UART, SPI e I2C no FreeRTOS

Os microcontroladores Cortex-M possuem periféricos integrados para comunicação serial. Vamos ver como usá-los dentro de um sistema multitarefa com FreeRTOS.

Comunicação UART no FreeRTOS

O UART (Universal Asynchronous Receiver-Transmitter) é o protocolo mais usado para comunicação serial entre dispositivos.

Configurando o UART

Primeiro, habilite o UART no STM32:

void UART2_Init(void) {
    RCC->APB1ENR |= (1 << 17); // Habilita clock do USART2
    RCC->AHB1ENR |= (1 << 0);  // Habilita clock do GPIOA

    GPIOA->MODER |= (2 << 4) | (2 << 6); // PA2 e PA3 como alternativo
    GPIOA->AFR[0] |= (7 << 8) | (7 << 12); // Seleciona AF7 (USART2)
    
    USART2->BRR = 84000000 / 115200;  // Configura baud rate
    USART2->CR1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_UE;  // Habilita TX, RX e UART
}

void UART2_Write(char c) {
    while (!(USART2->SR & USART_SR_TXE)); // Espera buffer estar vazio
    USART2->DR = c;
}

void UART2_SendString(char *s) {
    while (*s) {
        UART2_Write(*s++);
    }
}

Usando UART no FreeRTOS

Vamos criar uma tarefa para enviar dados pela UART:

void taskUART(void *pvParameters) {
    while (1) {
        UART2_SendString("FreeRTOS e UART funcionando!\n");
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

Dica: Para receber dados na UART sem bloquear o RTOS, utilize filas do FreeRTOS (xQueueReceive).

Comunicação SPI no FreeRTOS

O SPI (Serial Peripheral Interface) é amplamente usado para comunicação rápida entre sensores e microcontroladores.

Configurando o SPI

void SPI1_Init(void) {
    RCC->APB2ENR |= (1 << 12);  // Habilita clock do SPI1
    RCC->AHB1ENR |= (1 << 0);   // Habilita clock do GPIOA

    GPIOA->MODER |= (2 << 10) | (2 << 12) | (2 << 14);  // PA5, PA6, PA7 como alternativo
    GPIOA->AFR[0] |= (5 << 20) | (5 << 24) | (5 << 28); // Seleciona AF5 (SPI1)

    SPI1->CR1 = SPI_CR1_MSTR | SPI_CR1_BR_1 | SPI_CR1_SSM | SPI_CR1_SSI; // Mestre, Baud Rate e SSM ativado
    SPI1->CR1 |= SPI_CR1_SPE; // Habilita SPI
}

uint8_t SPI1_Transfer(uint8_t data) {
    while (!(SPI1->SR & SPI_SR_TXE));
    SPI1->DR = data;
    while (!(SPI1->SR & SPI_SR_RXNE));
    return SPI1->DR;
}

Usando SPI no FreeRTOS

void taskSPI(void *pvParameters) {
    while (1) {
        uint8_t recebido = SPI1_Transfer(0xAA);
        printf("Recebi: %d\n", recebido);
        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

Dica: Para sensores SPI que enviam muitos dados, use semáforos do FreeRTOS para evitar travamentos (xSemaphoreGive).

Comunicação I2C no FreeRTOS

O I2C (Inter-Integrated Circuit) é ideal para comunicação entre múltiplos dispositivos no mesmo barramento.

Configurando o I2C

void I2C1_Init(void) {
    RCC->APB1ENR |= (1 << 21); // Habilita I2C1
    RCC->AHB1ENR |= (1 << 1);  // Habilita GPIOB

    GPIOB->MODER |= (2 << 16) | (2 << 18); // PB8 e PB9 modo alternativo
    GPIOB->AFR[1] |= (4 << 0) | (4 << 4); // Seleciona AF4 (I2C1)

    I2C1->CR2 = (42 << 0); // Clock
    I2C1->CCR = (210 << 0);
    I2C1->TRISE = 43;
    I2C1->CR1 = I2C_CR1_PE;
}

Dica: Para lidar com múltiplos sensores I2C, utilize filas do FreeRTOS (xQueueSend).

Conclusão: Criando Sistemas Embarcados Eficientes com Cortex-M e FreeRTOS

Ao longo deste artigo, exploramos profundamente a arquitetura Cortex-M, abordando desde sua ISA e estrutura de barramentos até sua aplicação em sistemas embarcados reais. Discutimos como otimizar a programação para esses microcontroladores usando GCC, LLVM, depuração com GDB e técnicas de otimização de código.

Também mergulhamos na programação multitarefa com FreeRTOS, aprendendo a: Criar tarefas eficientes e gerenciar prioridades
Trabalhar com interrupções e semáforos
Usar timers para eventos periódicos
Implementar comunicação via UART, SPI e I2C
Integrar protocolos de rede como MQTT e Modbus

Esses conceitos são fundamentais para projetar sistemas embarcados eficientes, confiáveis e conectados, seja para IoT, automação industrial ou aplicações de tempo real.

Próximos Passos

Para aprofundar ainda mais os conhecimentos, algumas direções possíveis incluem:

• Otimização de consumo de energia em Cortex-M usando modos Sleep e Deep Sleep.
• Implementação de algoritmos de controle avançado, como PID e Machine Learning embarcado.
• Segurança embarcada, explorando o ARM TrustZone e criptografia para dispositivos IoT.
• Uso de sensores avançados, como IMUs (acelerômetros e giroscópios), GPS e RFID para aplicações de navegação e rastreamento.

Resumo: Se você deseja projetar firmwares robustos e eficientes, entender profundamente a arquitetura Cortex-M e dominar o FreeRTOS são passos essenciais. Combinando isso com técnicas avançadas de otimização e protocolos de comunicação, podemos desenvolver sistemas inteligentes e conectados para o futuro da computação embarcada.

Agora é hora de colocar esse conhecimento em prática!

The post Arquitetura Cortex-M: Um Guia Detalhado first appeared on MCU & FPGA.

O controle PID (Proporcional-Integral-Derivativo) é um dos métodos mais amplamente utilizados na automação e controle de processos industriais. Sua aplicação se dá em sistemas onde se deseja controlar uma variável de saída a partir de uma entrada desejada, minimizando erros e garantindo estabilidade. Este artigo apresenta os fundamentos do controle PID, explora as diferenças entre sistemas de controle aberto e fechado e fornece uma implementação prática do algoritmo em linguagem C, com explicações detalhadas e documentação apropriada.

Introdução aos Sistemas de Controle

Os sistemas de controle são fundamentais em diversas áreas da engenharia, permitindo a automação de processos mecânicos, elétricos e químicos. De maneira geral, esses sistemas podem ser classificados em controle aberto e controle fechado, cada um com características e aplicações distintas.

Sistemas de Controle Aberto

Um sistema de controle aberto é aquele no qual a saída não influencia diretamente a ação de controle. Ou seja, a entrada é aplicada ao sistema e a saída é gerada sem qualquer tipo de realimentação. Esse tipo de controle é simples, mas apresenta limitações significativas, pois não se ajusta automaticamente às variações externas ou internas do sistema.

Exemplo de Sistema de Controle Aberto

• Torradeira elétrica: Uma torradeira aplica calor ao pão por um tempo pré-determinado sem medir se ele realmente atingiu o nível de tostagem desejado.

Vantagens:

• Simplicidade na implementação;
• Baixo custo.

Desvantagens:

• Sensibilidade a perturbações externas;
• Incapacidade de correção automática de erros.

Sistemas de Controle Fechado

Diferente dos sistemas abertos, um sistema de controle fechado utiliza realimentação (feedback) para ajustar automaticamente a saída conforme a necessidade. Um sensor mede a variável de saída e compara com o valor desejado (setpoint), ajustando o sinal de controle para minimizar o erro.

Exemplo de Sistema de Controle Fechado

• Controle de temperatura de um forno: Um sensor mede a temperatura interna do forno e ajusta a potência do aquecedor para manter a temperatura desejada.

Vantagens:

• Maior precisão no controle da variável de interesse;
• Capacidade de compensação de perturbações externas;
• Melhor estabilidade do sistema.

Desvantagens:

• Maior complexidade e custo;
• Necessidade de calibração e ajuste dos parâmetros.

Fundamentos do Controle PID

O controlador PID é um tipo de controlador de realimentação que utiliza três componentes matemáticos principais para ajustar a resposta do sistema: Proporcional (P), Integral (I) e Derivativo (D). A equação geral do PID pode ser expressa como: u(t)=Kpe(t)+Ki∫e(t)dt+Kdde(t)dtu(t) = K_p e(t) + K_i \int e(t) dt + K_d \frac{d e(t)}{dt}

Onde:

• u(t)u(t) é o sinal de controle;
• e(t)e(t) é o erro, definido como a diferença entre o valor desejado e o valor atual;
• KpK_p é o ganho proporcional;
• KiK_i é o ganho integral;
• KdK_d é o ganho derivativo.

Cada um desses termos tem um papel fundamental no comportamento do sistema:

• Proporcional (P): Controla a resposta imediata do sistema ao erro, ajustando a intensidade do sinal de controle proporcionalmente ao erro.
• Integral (I): Acumula os erros passados para eliminar erros de estado estacionário.
• Derivativo (D): Prever tendências futuras de erro e atuar para minimizar oscilações.

Implementação do Algoritmo PID em C

Para demonstrar o funcionamento do controlador PID, implementamos um algoritmo em C, documentado e estruturado para ser usado em sistemas embarcados e aplicações de controle industrial.

A implementação abaixo utiliza uma estrutura de dados para armazenar os parâmetros do controlador PID e inclui uma função para calcular a saída do controlador com base no erro de entrada.

Código em C

#include <stdio.h>

// Definição da estrutura do controlador PID
typedef struct {
    double Kp;  // Ganho Proporcional
    double Ki;  // Ganho Integral
    double Kd;  // Ganho Derivativo
    double prevError; // Erro anterior
    double integral;  // Acumulador do termo integral
    double dt;  // Tempo de amostragem
} PIDController;

// Função para inicializar o controlador PID
void PID_Init(PIDController *pid, double Kp, double Ki, double Kd, double dt) {
    pid->Kp = Kp;
    pid->Ki = Ki;
    pid->Kd = Kd;
    pid->prevError = 0.0;
    pid->integral = 0.0;
    pid->dt = dt;
}

// Função para calcular a saída do controlador PID
double PID_Compute(PIDController *pid, double setpoint, double measuredValue) {
    double error = setpoint - measuredValue;  // Calcula o erro
    pid->integral += error * pid->dt;  // Calcula o termo integral
    double derivative = (error - pid->prevError) / pid->dt;  // Calcula o termo derivativo

    // Calcula a saída do PID
    double output = (pid->Kp * error) + (pid->Ki * pid->integral) + (pid->Kd * derivative);

    // Atualiza o erro anterior para a próxima iteração
    pid->prevError = error;

    return output;
}

// Exemplo de uso do controlador PID
int main() {
    PIDController pid;
    PID_Init(&pid, 1.2, 0.01, 0.5, 0.1);  // Inicializa o PID com valores arbitrários

    double setpoint = 100.0;  // Valor desejado
    double measuredValue = 90.0;  // Valor real medido

    for (int i = 0; i < 10; i++) {  // Simulação de 10 iterações
        double controlSignal = PID_Compute(&pid, setpoint, measuredValue);
        measuredValue += controlSignal * 0.1;  // Simula um sistema reagindo ao controle

        printf("Iteração %d - Controle: %.2f - Medida Atual: %.2f\n", i + 1, controlSignal, measuredValue);
    }

    return 0;
}

Explicação do Código

O código acima segue uma estrutura modular e bem documentada:

1. Estrutura PIDController:
   • Armazena os parâmetros do controlador (Kp, Ki, Kd).
   • Mantém o erro anterior e o termo integral acumulado.
   • Inclui o tempo de amostragem (dt), necessário para cálculos diferenciais.
2. Função PID_Init:
   • Inicializa os valores do controlador, garantindo que os estados internos sejam zerados.
3. Função PID_Compute:
   • Calcula o erro entre o valor desejado (setpoint) e o valor real (measuredValue).
   • Atualiza o termo integral e computa a derivada do erro.
   • Gera a saída do controlador PID.
4. Função main:
   • Cria um controlador PID e o inicializa com ganhos arbitrários.
   • Simula um sistema onde a saída do PID afeta diretamente a variável controlada.
   • Exibe os valores de controle ao longo das iterações.

The post Sistema PID e Diferenças entre Sistemas de Controle Aberto e Fechado first appeared on MCU & FPGA.

Para isso, três técnicas são amplamente utilizadas: mutex, semáforos e a suspensão do escalonador. Cada uma dessas abordagens tem seu melhor momento de aplicação e, se usada de maneira inadequada, pode levar a problemas de desempenho ou até mesmo a falhas difíceis de depurar. Neste artigo, exploraremos quando e como usar cada uma delas, incluindo exemplos práticos para facilitar a compreensão.

Mutex: Exclusão Mútua para Recursos Compartilhados

O mutex (mutual exclusion) é um mecanismo utilizado para garantir que apenas uma tarefa por vez tenha acesso a um recurso compartilhado. Ele funciona como um cadeado: a primeira tarefa que o adquire pode continuar a execução, enquanto as demais precisam aguardar sua liberação.

Quando Usar Mutex

• Quando há um recurso que não pode ser acessado simultaneamente por mais de uma tarefa.
• Para garantir consistência de dados ao modificar variáveis compartilhadas.
• Em sistemas operacionais com preempção habilitada, onde uma tarefa pode ser interrompida a qualquer momento.

Quando Evitar Mutex

• Quando há altíssima concorrência, pois as tarefas podem passar muito tempo bloqueadas, reduzindo o desempenho.
• Quando um recurso pode ser acessado de forma não exclusiva, ou seja, múltiplas tarefas podem lê-lo sem problemas.
• Quando há risco de deadlocks, onde múltiplas tarefas ficam bloqueadas esperando a liberação de mutexes que nunca ocorrerão.

Exemplo de Uso de Mutex no STM32F411RE com FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include "semphr.h"
#include "stm32f4xx.h"

SemaphoreHandle_t xMutex;
int shared_resource = 0;

void Task1(void *pvParameters) {
    while(1) {
         if (xSemaphoreTake(xMutex, portMAX_DELAY)) {
                    shared_resource++;
                    printf("Task1: Recurso compartilhado = %d\n", shared_resource);
                    xSemaphoreGive(xMutex);
          }
          vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void Task2(void *pvParameters) {
    while(1) {
            if (xSemaphoreTake(xMutex, portMAX_DELAY)) {
                      shared_resource--;
                      printf("Task2: Recurso compartilhado = %d\n", shared_resource);
                      xSemaphoreGive(xMutex);
            }
           vTaskDelay(pdMS_TO_TICKS(500));
     }
}

int main() {
    xMutex = xSemaphoreCreateMutex();
    if (xMutex != NULL) {
            xTaskCreate(Task1, "Task 1", 128, NULL, 1, NULL);
            xTaskCreate(Task2, "Task 2", 128, NULL, 1, NULL);
            vTaskStartScheduler()
    }
    while(1);
}

Semáforos: Controle de Fluxo e Contagem de Recursos

Os semáforos são estruturas mais flexíveis que os mutexes e podem ser usados para diferentes propósitos. Eles operam com um contador interno, que pode permitir múltiplas tarefas acessando um mesmo recurso, dependendo da configuração.

Quando Usar Semáforos

• Para controlar múltiplas instâncias de um recurso compartilhado, como um conjunto de conexões disponíveis em um servidor.
• Para sincronizar tarefas, permitindo que uma aguarde a outra concluir uma operação antes de continuar.
• Em sistemas embarcados onde múltiplas tarefas precisam se comunicar sem causar bloqueios desnecessários.

Quando Evitar Semáforos

• Quando há necessidade de exclusão mútua. Um semáforo mal configurado pode permitir que múltiplas tarefas acessem um recurso crítico simultaneamente.
• Quando o código não foi planejado corretamente, podendo levar a inconsistências difíceis de depurar.
• Quando há possibilidade de inversão de prioridade, onde tarefas de baixa prioridade podem atrasar a execução de tarefas mais importantes.

Exemplo de Uso de Semáforo no STM32F411RE com FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include "semphr.h"
#include "stm32f4xx.h"

SemaphoreHandle_t xSemaphore;
int shared_counter = 0;

void Task1(void *pvParameters) {
    while(1) {
        if (xSemaphoreTake(xSemaphore, portMAX_DELAY)) {
            shared_counter++;
            printf("Task1: Contador = %d\n", shared_counter);
            xSemaphoreGive(xSemaphore);
        }
        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

void Task2(void *pvParameters) {
    while(1) {
        if (xSemaphoreTake(xSemaphore, portMAX_DELAY)) {
            shared_counter--;
            printf("Task2: Contador = %d\n", shared_counter);
            xSemaphoreGive(xSemaphore);
        }
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

int main() {
    xSemaphore = xSemaphoreCreateBinary();
    xSemaphoreGive(xSemaphore);
    if (xSemaphore != NULL) {
        xTaskCreate(Task1, "Task 1", 128, NULL, 1, NULL);
        xTaskCreate(Task2, "Task 2", 128, NULL, 1, NULL);
        vTaskStartScheduler();
    }
    while(1);
}

Suspensão do Escalonador: Controle Total com Custo Alto

A suspensão do escalonador (scheduler lock) é uma abordagem mais extrema, onde o sistema operacional pausa a troca de tarefas, garantindo que a tarefa em execução complete seu trabalho sem interrupções.

Quando Usar a Suspensão do Escalonador

• Quando uma operação crítica precisa ser executada em um curto período de tempo e não pode ser interrompida.
• Para seções de código extremamente curtas e atômicas, onde o impacto da suspensão do escalonador é mínimo.
• Em sistemas bare-metal sem suporte a mutexes ou semáforos.

Quando Evitar a Suspensão do Escalonador

• Quando há tarefas de tempo real que precisam responder rapidamente a eventos externos.
• Se o código protegido for muito longo, pois a suspensão prolongada do escalonador pode causar degradação significativa no desempenho do sistema.
• Em sistemas onde múltiplas CPUs são usadas, pois suspender o escalonador em um núcleo não impede que outros núcleos executem tarefas concorrentes.

Exemplo de Suspensão do Escalonador no STM32F411RE com FreeRTOS

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

void CriticalTask(void *pvParameters) {
    while(1) {
        vTaskSuspendAll(); // Suspende o escalonador
        // Código crítico
        printf("Executando tarefa crítica\n");
        xTaskResumeAll(); // Retoma o escalonador
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

int main() {
    xTaskCreate(CriticalTask, "Critical Task", 128, NULL, 1, NULL);
    vTaskStartScheduler();
    while(1);
}

Abordagem para Dispositivos I2C e SPI

Os protocolos de comunicação como I2C e SPI são amplamente utilizados em sistemas embarcados para comunicação entre microcontroladores e periféricos. A abordagem correta para controle de concorrência depende do tipo de comunicação e do contexto de uso.

I2C com Mutex no STM32F411RE

O protocolo I2C é um barramento compartilhado onde múltiplos dispositivos podem estar conectados ao mesmo controlador. Como apenas um dispositivo pode realizar a comunicação por vez, o uso de mutex é essencial para evitar colisões entre tarefas concorrentes que tentam acessar o barramento ao mesmo tempo.

#include "stm32f4xx_hal.h"
#include "FreeRTOS.h"
#include "semphr.h"

I2C_HandleTypeDef hi2c1;
SemaphoreHandle_t i2cMutex;

void I2C_Write(uint16_t devAddress, uint8_t *data, uint16_t size) {
    if (xSemaphoreTake(i2cMutex, portMAX_DELAY)) {
        HAL_I2C_Master_Transmit(&hi2c1, devAddress, data, size, HAL_MAX_DELAY);
        xSemaphoreGive(i2cMutex);
    }
}