Linguagem - MCU & FPGA https://mcu.tec.br Microcontroladores & FPGA Sat, 23 May 2026 18:36:11 +0000 pt-BR hourly 1 https://wordpress.org/?v=7.0 https://mcu.tec.br/wp-content/uploads/2025/02/Robo-para-o-site-MCU.tec_.br-512x512-1-150x150.png Linguagem - MCU & FPGA https://mcu.tec.br 32 32 Usando JSON e cJSON em Microcontroladores https://mcu.tec.br/linguagem/c/usando-json-e-cjson-em-microcontroladores/?utm_source=rss&utm_medium=rss&utm_campaign=usando-json-e-cjson-em-microcontroladores https://mcu.tec.br/linguagem/c/usando-json-e-cjson-em-microcontroladores/#respond Sun, 24 May 2026 22:16:00 +0000 https://mcu.tec.br/?p=1443 Aprenda como usar JSON e a biblioteca cJSON em microcontroladores com linguagem C. Neste tutorial didático, mostramos como criar objetos JSON, montar hierarquias de dois níveis, trabalhar com arrays, simular sensores, enviar dados para um serviço web mock e interpretar respostas JSON recebidas do servidor. O conteúdo é genérico e pode ser adaptado para STM32, ESP32, RP2040, AVR, RISC-V, FreeRTOS, Zephyr ou projetos bare-metal. Também são apresentados cuidados essenciais com memória, validação de campos, limites de arrays e boas práticas para aplicações IoT embarcadas.

The post Usando JSON e cJSON em Microcontroladores first appeared on MCU & FPGA.

]]>

Table of Contents

JSON, sigla para JavaScript Object Notation, é um formato textual usado para representar dados estruturados. Apesar de ter nascido no ecossistema JavaScript, hoje ele é amplamente usado em APIs web, sistemas IoT, serviços REST, comunicação entre dispositivos, arquivos de configuração e troca de mensagens entre firmware e aplicações externas.

Em microcontroladores, JSON aparece principalmente quando o dispositivo precisa conversar com algum sistema externo. Por exemplo, um ESP32 pode enviar leituras de temperatura para um servidor HTTP; um STM32 com modem 4G pode publicar dados em uma API; um RP2040 conectado a um gateway pode receber parâmetros de calibração; ou um dispositivo industrial pode gerar mensagens estruturadas para diagnóstico remoto.

A grande vantagem do JSON é a legibilidade. Uma mensagem como esta:

{
  "device": "sensor-01",
  "temperature": 27.5,
  "humidity": 61.2,
  "relay": true
}

é fácil de entender tanto por humanos quanto por máquinas. Isso ajuda no desenvolvimento, no teste, no debug e na integração com sistemas web. Em vez de criar um protocolo binário próprio logo no início do projeto, muitas vezes podemos começar com JSON para acelerar a prototipagem e tornar a comunicação mais clara.

Mas existe um ponto importante: JSON não é o formato mais eficiente para microcontroladores pequenos. Ele consome mais memória que um protocolo binário, ocupa mais bytes na comunicação e exige processamento para converter texto em dados internos. Em um microcontrolador com poucos kilobytes de RAM, isso precisa ser tratado com cuidado.

Por isso, em sistemas embarcados, usamos JSON quando a clareza, a interoperabilidade e a integração com serviços externos são mais importantes do que a máxima economia de memória. Essa é uma decisão típica de projeto embarcado: escolher uma solução que facilite a comunicação, mas sem ignorar restrições de RAM, Flash, tempo de execução e robustez. Esse cuidado está alinhado com a visão clássica de desenvolvimento embarcado em C, onde restrições de memória, desempenho, confiabilidade e custo recorrente influenciam diretamente as decisões de arquitetura.

Neste tutorial, vamos usar a biblioteca cJSON, uma biblioteca em linguagem C para criar e interpretar documentos JSON. A ideia será manter tudo genérico, sem depender de ESP-IDF, STM32 HAL, Pico SDK, Zephyr ou FreeRTOS. Quando precisarmos simular comunicação com um servidor web, usaremos funções mock, ou seja, funções falsas que imitam o comportamento de uma API externa.

A arquitetura básica do nosso exemplo será esta:

+-------------------------+
|     Aplicação MCU       |
|                         |
|  Lê sensores simulados  |
|  Monta JSON com cJSON   |
|  Envia para Web Mock    |
|  Recebe resposta JSON   |
|  Interpreta resposta    |
+-----------+-------------+
            |
            v
+-------------------------+
| Serviço Web Simulado    |
|                         |
| Recebe JSON             |
| Processa dados fake     |
| Retorna JSON            |
+-------------------------+

Neste primeiro momento, podemos imaginar que o microcontrolador coleta dados de sensores e envia essas informações para um servidor. O servidor, por sua vez, responde com alguma configuração, como ligar ou desligar um relé, alterar o intervalo de amostragem ou informar se houve erro na requisição.

Um exemplo de mensagem enviada pelo microcontrolador poderia ser:

{
  "device_id": "mcu-001",
  "temperature": 28.75,
  "voltage": 3.29,
  "uptime": 15240
}

E uma resposta simulada do servidor poderia ser:

{
  "status": "ok",
  "relay": true,
  "sample_interval_ms": 5000
}

Perceba que o JSON permite representar textos, números, valores booleanos, objetos e listas. Isso é muito útil quando queremos criar mensagens flexíveis. Porém, em firmware, devemos evitar documentos JSON muito grandes, objetos muito profundos e alocações dinâmicas descontroladas.

Ao longo do tutorial, vamos trabalhar com quatro ideias principais: criar JSON, converter JSON para texto, interpretar JSON recebido e proteger o firmware contra erros de formato. A biblioteca cJSON facilita bastante esse processo, mas ela não elimina a responsabilidade do programador embarcado. Sempre será necessário verificar ponteiros, validar tipos, controlar tamanho de buffers e liberar memória corretamente.

The post Usando JSON e cJSON em Microcontroladores first appeared on MCU & FPGA.

]]> https://mcu.tec.br/linguagem/c/usando-json-e-cjson-em-microcontroladores/feed/ 0 1443 Assembly ARM vs Thumb: Arquitetura de Instruções nos Cortex-M e Exemplo Prático em Assembly https://mcu.tec.br/linguagem/assembly-arm-vs-thumb-arquitetura-de-instrucoes-nos-cortex-m-e-exemplo-pratico-em-assembly/?utm_source=rss&utm_medium=rss&utm_campaign=assembly-arm-vs-thumb-arquitetura-de-instrucoes-nos-cortex-m-e-exemplo-pratico-em-assembly Wed, 07 Jan 2026 16:14:28 +0000 https://mcu.tec.br/?p=1186 Entenda de forma clara e técnica as diferenças entre o assembly ARM clássico e o Thumb, com foco nos microcontroladores Cortex-M. O artigo explica a evolução das arquiteturas ARMv6-M, ARMv7-M, ARMv8-M e ARMv8.1-M, detalhando como o conjunto de instruções Thumb-2 influencia desempenho, consumo de energia e previsibilidade em sistemas embarcados. Inclui um exemplo completo e comentado de “Hello World” em assembly para Cortex-M3 utilizando UART, ideal para quem deseja compreender o funcionamento do firmware em baixo nível e o que realmente acontece por trás do código C.

The post Assembly ARM vs Thumb: Arquitetura de Instruções nos Cortex-M e Exemplo Prático em Assembly first appeared on MCU & FPGA.

]]>

Table of Contents

1 — ARM Assembly “clássico” vs Thumb: o que realmente muda

Quando falamos em assembly ARM, é comum misturar dois conceitos que, embora relacionados, têm impactos profundos no projeto de firmware: o conjunto de instruções ARM “clássico” (ARM state) e o conjunto de instruções Thumb (Thumb state). Historicamente, o ARM clássico utiliza instruções de 32 bits de largura fixa, enquanto o Thumb surgiu como uma alternativa mais compacta, inicialmente com instruções de 16 bits, visando reduzir o tamanho do código em memória — algo crítico em microcontroladores.

No ARM clássico, cada instrução de 32 bits carrega bastante informação: operação, registradores envolvidos, modos de endereçamento e, em muitas instruções, condicionalidade embutida (flags como EQ, NE, GT, LT diretamente no opcode). Isso resulta em código expressivo e eficiente em termos de ciclos por instrução, mas com custo direto em consumo de Flash e largura de banda de barramento. Esse modelo fez muito sentido em CPUs com cache e memória abundante, como aplicações embarcadas de maior porte ou sistemas operacionais completos.

O Thumb, por outro lado, nasceu com uma proposta pragmática: densidade de código. Ao reduzir o tamanho das instruções, o processador consegue armazenar mais lógica no mesmo espaço de memória, além de melhorar o fetch em barramentos estreitos. A contrapartida inicial era um conjunto de instruções mais restrito, menos modos de endereçamento e menor flexibilidade em certas operações. Com o tempo, essa limitação foi sendo superada, culminando no Thumb-2, que combina instruções de 16 e 32 bits de forma transparente, mantendo alta densidade de código sem sacrificar capacidade expressiva.

É aqui que entra um ponto essencial para quem trabalha com microcontroladores da família ARM Cortex-M: não existe “ARM clássico” nesses núcleos. Todos os Cortex-M executam exclusivamente Thumb/Thumb-2. Isso não é um detalhe de implementação, mas uma decisão arquitetural profunda: simplifica o pipeline, reduz consumo de energia, elimina a necessidade de alternância de estado ARM/Thumb e torna o comportamento mais previsível — algo fundamental para sistemas de tempo real.

Portanto, ao escrever assembly para Cortex-M, falar em “assembly ARM” significa, na prática, assembly Thumb-2, ainda que a sintaxe seja parecida e muitos manuais usem o termo ARM de forma genérica. Entender essa diferença evita confusões comuns, como procurar instruções que simplesmente não existem nesse ambiente ou tentar aplicar modelos mentais válidos para Cortex-A/R em um núcleo projetado desde o início para microcontroladores determinísticos.

The post Assembly ARM vs Thumb: Arquitetura de Instruções nos Cortex-M e Exemplo Prático em Assembly first appeared on MCU & FPGA.

]]> 1186 Introdução ao CMake em Projetos STM32 Gerados pelo CubeMX https://mcu.tec.br/linguagem/builds/introducao-ao-cmake-em-projetos-stm32-gerados-pelo-cubemx/?utm_source=rss&utm_medium=rss&utm_campaign=introducao-ao-cmake-em-projetos-stm32-gerados-pelo-cubemx Thu, 25 Dec 2025 13:16:31 +0000 https://mcu.tec.br/?p=1069 Aprenda a usar o CMake de forma profissional em projetos STM32 gerados pelo CubeMX. Este guia completo e didático explica a história do CMake, os problemas que ele resolve, e como aplicá-lo corretamente em sistemas embarcados bare-metal. O artigo aborda em profundidade diretivas como project, add_executable, add_library, target_sources, target_include_directories, target_compile_definitions, target_link_libraries, uso consciente de file(GLOB), integração de BLOBs binários, criação de bibliotecas estáticas reutilizáveis, configuração de perfis de build, uso de CMakePresets.json e separação correta de toolchains via arquivos .cmake. Inclui um exemplo ideal e comentado de CMakeLists.txt para STM32, além de um arquivo de toolchain arm-none-eabi-gcc.cmake, mostrando como gerar .elf, .bin e .hex fora de IDEs proprietárias. Conteúdo técnico, prático e focado em boas práticas de engenharia de firmware.

The post Introdução ao CMake em Projetos STM32 Gerados pelo CubeMX first appeared on MCU & FPGA.

]]> A história do CMake e o problema que ele veio resolver

O CMake surge no início dos anos 2000, criado por Bill Hoffman no contexto do Kitware, com um objetivo muito claro: resolver o problema da portabilidade e da complexidade crescente dos sistemas de build. Até então, projetos em C e C++ dependiam fortemente de Makefiles escritos manualmente, profundamente acoplados ao sistema operacional, ao compilador e até mesmo à estrutura de diretórios da máquina do desenvolvedor. Em projetos pequenos isso era administrável, mas à medida que o software crescia — especialmente em ambientes multiplataforma — o custo de manutenção dos Makefiles se tornava proibitivo.

O problema se agravava em projetos embarcados. Cada microcontrolador exige um conjunto específico de flags de compilação, scripts de linkedição, opções de ABI (Application Binary Interface), suporte a assembly, bibliotecas de runtime reduzidas (newlib-nano, nosys, etc.) e, frequentemente, múltiplos perfis de build (Debug, Release, Profiling). Manter tudo isso sincronizado manualmente em Makefiles diferentes era uma fonte constante de erros sutis, builds não reproduzíveis e dependência excessiva do conhecimento tácito do desenvolvedor.

O CMake nasce justamente como uma ferramenta de meta-build. Ele não compila código diretamente. Em vez disso, descreve o projeto em um nível mais alto, declarativo, e gera os arquivos de build adequados para o ambiente alvo: Makefiles, Ninja, projetos para IDEs como Eclipse, Visual Studio ou Xcode. Essa abordagem separa claramente o que o projeto é de como ele será construído em cada plataforma.

No contexto de sistemas embarcados, essa separação é fundamental. O mesmo projeto pode ser compilado com GCC bare-metal (arm-none-eabi-gcc), Clang, ou até toolchains customizadas fornecidas por fabricantes. O CMake permite encapsular essas diferenças em arquivos de toolchain, mantendo o CMakeLists.txt do projeto limpo, legível e focado na arquitetura do software, e não nos detalhes do compilador.

Por que o CMake se encaixa tão bem com projetos STM32

Projetos STM32 gerados pelo CubeMX possuem uma característica importante: eles não são apenas aplicações, mas sim sistemas completos, compostos por código C, assembly, bibliotecas HAL, CMSIS, drivers específicos do microcontrolador, além de um script de linkedição altamente acoplado ao layout de memória do chip. O CubeMX tradicionalmente gera projetos voltados para IDEs específicas (STM32CubeIDE, Keil, IAR), mas isso cria um forte lock-in da ferramenta.

Ao adotar o CMake como sistema de build, o projeto STM32 passa a ser agnóstico de IDE. Ele pode ser compilado via linha de comando, integrado a pipelines de CI/CD, analisado por ferramentas como clangd, clang-tidy e cppcheck, ou aberto em qualquer editor moderno. Além disso, o CMake facilita a modularização do projeto, permitindo separar claramente o código gerado pelo CubeMX do código de aplicação, das bibliotecas externas e das bibliotecas internas reutilizáveis.

Outro ponto crucial é que o CMake trabalha com o conceito de targets. Em vez de pensar apenas em arquivos .c e .o, o desenvolvedor passa a modelar o sistema em termos de executáveis, bibliotecas estáticas, bibliotecas de interface e dependências explícitas entre elas. Isso se encaixa perfeitamente no mundo embarcado moderno, onde reutilização, isolamento de responsabilidades e controle fino de símbolos e includes são essenciais para manter projetos grandes sustentáveis ao longo do tempo.

CMake como fundação para arquiteturas escaláveis em firmware

Quando usamos CMake corretamente em um projeto STM32, deixamos de ter apenas um “script de build” e passamos a ter uma descrição formal da arquitetura do firmware. Bibliotecas como drivers, middlewares, stacks de comunicação ou camadas de abstração de hardware podem ser modeladas como bibliotecas estáticas independentes. Cada uma define seus próprios includes, defines e flags de compilação, que são propagados automaticamente para quem as consome.

Isso elimina uma classe inteira de problemas comuns em projetos embarcados: defines globais espalhados, includes duplicados, dependências implícitas e flags de compilação inconsistentes entre módulos. Além disso, o CMake facilita a criação de perfis de build (Debug, Release, Coverage, Profiling), algo essencial quando se trabalha com análise temporal, WCET, uso de heap, watermark de pilha e instrumentação de RTOS.

Em resumo, o CMake não é apenas uma alternativa ao Makefile tradicional. Ele é uma camada de engenharia de software aplicada ao processo de build, especialmente poderosa quando combinada com projetos STM32 gerados pelo CubeMX.

Estrutura básica de um projeto CMake para STM32 gerado pelo CubeMX

Ao abrir um projeto STM32 baseado em CMake, a primeira impressão costuma ser de estranhamento para quem vem de Makefiles tradicionais ou do ecossistema fechado de IDEs como o STM32CubeIDE. Isso acontece porque o CMake não descreve comandos de compilação de forma direta, mas sim relações estruturais entre os elementos do projeto. Antes de entender cada diretiva isoladamente, é fundamental compreender a estrutura conceitual que sustenta um projeto CMake bem organizado para firmware.

Em projetos STM32 modernos, especialmente aqueles que nascem a partir do CubeMX, o ponto de entrada é sempre um arquivo chamado CMakeLists.txt localizado na raiz do projeto. Esse arquivo funciona como o manifesto do firmware: ele declara qual é o projeto, quais linguagens são usadas, quais bibliotecas fazem parte do sistema, quais arquivos devem ser compilados e como tudo isso se conecta para gerar o binário final, geralmente um arquivo .elf.

Uma característica importante é que esse CMakeLists.txt de nível superior não deve conter tudo. Em projetos bem estruturados, ele atua como um orquestrador, delegando responsabilidades para outros CMakeLists.txt menores espalhados pela árvore do projeto. É exatamente isso que vemos em projetos gerados ou adaptados a partir do CubeMX, onde o código automático fica isolado em uma subpasta, normalmente algo como cmake/stm32cubemx, enquanto o código da aplicação permanece sob controle direto do desenvolvedor.

Essa separação é essencial. O código gerado pelo CubeMX pode ser regenerado a qualquer momento, enquanto o código da aplicação e a lógica de build precisam permanecer estáveis. O CMake favorece esse modelo ao permitir a inclusão explícita de subdiretórios, tornando claro o limite entre código gerado e código autoral.

A diretiva cmake_minimum_required: controle de compatibilidade e previsibilidade

Toda configuração CMake começa com a diretiva cmake_minimum_required. Embora muitos desenvolvedores a encarem como uma formalidade, ela desempenha um papel crítico em projetos embarcados. Essa diretiva define a versão mínima do CMake necessária para interpretar corretamente o script, garantindo que comportamentos antigos, obsoletos ou inconsistentes não sejam utilizados de forma implícita.

Em firmware, previsibilidade é tudo. Diferenças sutis no comportamento do sistema de build podem resultar em flags omitidas, bibliotecas ligadas em ordem incorreta ou até mesmo em binários que funcionam em Debug, mas falham em Release. Ao exigir explicitamente uma versão mínima, o projeto estabelece uma linha de base clara para todos os desenvolvedores e para sistemas de integração contínua.

Na prática, projetos STM32 modernos costumam exigir versões relativamente recentes do CMake, pois funcionalidades como FetchContent, presets (CMakePresets.json) e melhor suporte a toolchains cruzadas evoluíram bastante nas últimas versões. Definir essa versão logo no início do arquivo evita erros difíceis de rastrear mais adiante e deixa claro que o projeto não foi pensado para ambientes legados.

Além disso, essa diretiva influencia o modo como o CMake interpreta várias outras instruções. Sem ela, o CMake entra em um modo de compatibilidade que pode alterar silenciosamente o comportamento de comandos fundamentais. Em sistemas embarcados, onde cada byte e cada flag importam, esse tipo de ambiguidade é simplesmente inaceitável.

A diretiva project(): identidade formal do firmware

Logo após definir a versão mínima do CMake, encontramos a diretiva project(). Essa é uma das instruções mais importantes de todo o sistema de build, pois é nela que o firmware passa a existir formalmente como um projeto CMake. Ao declarar o projeto, você não está apenas dando um nome simbólico ao binário final, mas também inicializando internamente todo o modelo de build que o CMake utilizará.

Em projetos STM32, o nome do projeto geralmente coincide com o nome do arquivo final .elf, e frequentemente reflete o hardware alvo ou a função principal do firmware. Isso não é apenas uma convenção estética. O nome do projeto passa a ser utilizado implicitamente em diversas outras diretivas, como na criação do executável, na geração de mensagens de log e na organização dos artefatos de build.

Além do nome, a diretiva project() também declara as linguagens utilizadas. Em firmware STM32, isso quase sempre inclui C e Assembly. Ao fazer isso explicitamente, o CMake passa a configurar corretamente compiladores, regras de build e extensões de arquivos para cada linguagem, algo fundamental quando se trabalha com arquivos .s ou .S de startup e rotinas de baixo nível.

Outro ponto relevante é que a chamada a project() marca o momento em que variáveis globais do CMake passam a estar disponíveis de forma consistente. Por isso, boas práticas recomendam que a maior parte das configurações estruturais do projeto aconteça após essa diretiva, garantindo que o ambiente esteja completamente inicializado.

Definição do padrão da linguagem e controle do compilador

Em sistemas embarcados, definir explicitamente o padrão da linguagem não é um detalhe estético, mas um requisito técnico. O comportamento do compilador, a disponibilidade de recursos da linguagem e até a geração de código variam significativamente entre diferentes padrões do C. O CMake resolve essa questão de forma clara e declarativa por meio de variáveis específicas que descrevem qual versão da linguagem o projeto exige, e não apenas qual compilador será usado.

A variável CMAKE_C_STANDARD estabelece o padrão mínimo do C que o projeto aceita. Em projetos STM32 gerados pelo CubeMX, é comum adotar o C11, pois ele oferece um bom equilíbrio entre modernidade e compatibilidade com toolchains bare-metal. Ao definir esse valor, o CMake garante que o compilador seja invocado com as flags corretas para ativar esse padrão, independentemente de qual GCC esteja instalado no sistema.

Complementando isso, CMAKE_C_STANDARD_REQUIRED força o compilador a respeitar exatamente o padrão definido. Sem essa diretiva, o compilador pode silenciosamente aceitar um padrão diferente, mais antigo ou mais permissivo, o que abre espaço para comportamentos inesperados. Em firmware, onde cada compilação precisa ser reprodutível, esse tipo de ambiguidade não é aceitável.

Já a variável CMAKE_C_EXTENSIONS controla se extensões específicas do compilador — como as extensões GNU — podem ser utilizadas. Em projetos STM32, muitas bibliotecas, incluindo partes do HAL e até do CMSIS, dependem de extensões do GCC. Por isso, permitir essas extensões costuma ser uma decisão consciente, e não um efeito colateral. O CMake torna essa decisão explícita, documentando a dependência do projeto em recursos fora do padrão estrito da linguagem.

Esse conjunto de definições cria um contrato claro entre o firmware e o compilador, algo essencial quando o mesmo projeto pode ser compilado em máquinas diferentes, por pessoas diferentes ou em pipelines automatizados.

Tipos de build: Debug, Release e além

Uma das maiores vantagens do CMake em relação a Makefiles artesanais é o tratamento nativo de tipos de build. Em firmware, isso vai muito além de simplesmente ativar ou desativar otimizações. Um build Debug normalmente inclui símbolos de depuração, otimizações mínimas e, muitas vezes, instrumentação adicional para análise de tempo, uso de memória e comportamento do RTOS. Já um build Release prioriza desempenho, tamanho do binário e previsibilidade temporal.

A variável CMAKE_BUILD_TYPE é o mecanismo básico pelo qual o CMake seleciona esse comportamento. Ao definir um valor padrão quando essa variável não está presente, o projeto garante que o build não ocorra em um estado indefinido. Isso é especialmente importante em ambientes embarcados, onde rodar um binário “meio Debug, meio Release” pode gerar resultados enganosos durante testes de campo.

Mais importante do que a existência de Debug e Release é o fato de que o CMake permite estender esse conceito. É comum em projetos STM32 mais maduros existirem perfis adicionais, como builds para análise de WCET, builds com logs detalhados, builds para testes de estresse ou builds voltados exclusivamente para validação de consumo de energia. O sistema de build deixa de ser apenas um meio de gerar um .elf e passa a ser uma ferramenta estratégica de engenharia.

Essa flexibilidade se torna ainda mais poderosa quando combinada com arquivos como CMakePresets.json, que permitem descrever esses perfis de forma padronizada e reutilizável, eliminando a necessidade de longas linhas de comando e reduzindo drasticamente erros humanos.

Ativação explícita das linguagens C e Assembly

Em firmware STM32, o uso de Assembly não é opcional. Arquivos de startup, rotinas de inicialização da pilha, vetores de interrupção e, em alguns casos, otimizações críticas de desempenho exigem suporte explícito a código Assembly. O CMake trata isso de forma direta por meio da diretiva enable_language.

Ao habilitar C e ASM de forma explícita, o projeto informa ao CMake que esses dois tipos de código fazem parte da arquitetura do firmware. Isso permite que o sistema de build configure corretamente as regras de compilação, extensões reconhecidas e até flags específicas para cada linguagem. Ignorar essa etapa pode levar a erros difíceis de diagnosticar, especialmente quando arquivos .s ou .S são tratados incorretamente como texto ou ignorados durante o build.

Outro ponto relevante é que, ao declarar explicitamente as linguagens, o projeto se torna mais claro para ferramentas externas. Editores, analisadores estáticos e sistemas de indexação conseguem entender melhor a natureza do código, o que melhora significativamente a experiência de desenvolvimento em projetos de médio e grande porte.

Criação do firmware com add_executable(): o nascimento do binário .elf

Em projetos embarcados, o executável gerado pelo CMake não é apenas um programa no sentido tradicional, mas sim a imagem completa do firmware, contendo código, dados, vetores de interrupção, tabelas de inicialização e referências explícitas ao layout de memória definido no script de linkedição. No CMake, esse artefato nasce por meio da diretiva add_executable().

Ao chamar add_executable, o projeto declara formalmente a existência de um alvo executável. No contexto STM32, esse alvo representa o firmware que será gravado na flash do microcontrolador. Diferente de ambientes desktop, o executável não será “executado” pelo sistema operacional, mas sim carregado por um programador ou bootloader. Ainda assim, para o CMake, ele é tratado como um executável completo, com regras claras de compilação e linkedição.

Uma característica interessante é que, em projetos bem estruturados, o add_executable normalmente aparece sem listar arquivos fonte diretamente. Isso não é um erro, mas sim uma decisão arquitetural. O alvo é criado vazio e, ao longo do CMakeLists.txt, vai recebendo fontes, includes, defines e bibliotecas por meio de outras diretivas mais específicas. Esse modelo favorece a modularização e evita grandes listas monolíticas de arquivos difíceis de manter.

Essa abordagem se encaixa muito bem com projetos CubeMX, onde o código gerado automaticamente pode ser adicionado ao executável a partir de um subdiretório específico, mantendo o arquivo principal limpo e legível. O executável passa a ser o ponto de convergência de vários módulos independentes, refletindo com clareza a arquitetura do firmware.

Criação de bibliotecas estáticas com add_library()

Se o add_executable representa o firmware final, add_library representa os blocos de construção que compõem esse firmware. Em projetos STM32 profissionais, bibliotecas estáticas são fundamentais para organizar o código, promover reutilização e limitar o acoplamento entre módulos.

Ao criar uma biblioteca estática no CMake, você está definindo um conjunto coeso de funcionalidades que pode ser compilado de forma independente e depois ligado ao firmware principal. Isso é extremamente comum para drivers, camadas de abstração, middlewares e até para o próprio HAL, quando se deseja maior controle sobre o processo de build.

No CMake, bibliotecas estáticas permitem encapsular não apenas arquivos fonte, mas também includes, defines e opções de compilação específicas daquele módulo. Isso significa que um driver pode expor suas dependências de forma explícita, e o executável que o utiliza herda essas informações automaticamente. Esse modelo elimina a necessidade de repetir configurações globais e reduz drasticamente erros de integração.

Em projetos derivados do CubeMX, é comum transformar partes do código gerado em bibliotecas internas, isolando, por exemplo, a inicialização do hardware da lógica da aplicação. O CMake torna esse processo natural, incentivando uma arquitetura mais limpa e sustentável ao longo do tempo.

O papel central de target_sources()

Uma vez criados os alvos — executáveis ou bibliotecas — surge a necessidade de associar arquivos fonte a eles. É aqui que entra a diretiva target_sources. Em vez de listar arquivos diretamente na criação do alvo, o CMake permite adicioná-los de forma incremental e contextualizada.

Essa abordagem é especialmente poderosa em firmware STM32, pois diferentes módulos podem contribuir com arquivos para o mesmo alvo sem que isso gere dependências implícitas ou confusão estrutural. O código gerado pelo CubeMX, por exemplo, pode ser adicionado a partir de um subdiretório específico, enquanto o código da aplicação é adicionado em outro ponto do projeto.

Além disso, target_sources ajuda a documentar a origem dos arquivos. Ao ler o CMakeLists.txt, fica claro quais fontes pertencem a qual módulo e como elas se integram ao firmware final. Isso facilita manutenção, revisão de código e onboarding de novos desenvolvedores.

Outro benefício importante é que essa diretiva respeita o escopo do alvo. Um arquivo fonte adicionado a uma biblioteca não “vaza” automaticamente para outros alvos, o que reforça o isolamento entre módulos e previne dependências acidentais.

Includes e headers: controle preciso com target_include_directories()

Em projetos STM32 tradicionais, especialmente aqueles criados diretamente dentro de IDEs, é muito comum encontrar listas globais de includes, aplicadas indiscriminadamente a todo o projeto. Esse modelo funciona no início, mas rapidamente se torna frágil: headers passam a depender implicitamente de outros headers, conflitos de nomes surgem e o acoplamento entre módulos cresce silenciosamente.

O CMake resolve esse problema ao introduzir um modelo baseado em escopo, e a diretiva target_include_directories() é o coração dessa abordagem. Em vez de dizer “estes diretórios fazem parte do projeto”, você passa a dizer “estes diretórios fazem parte deste alvo”. Essa diferença conceitual muda completamente a forma como o firmware é organizado.

Quando um diretório de include é associado a um alvo específico — seja um executável ou uma biblioteca — apenas aquele alvo e seus consumidores diretos terão acesso a esses headers. Isso permite que cada módulo exponha exatamente o que precisa ser exposto, nada mais. Em firmware STM32, isso é essencial para separar, por exemplo, drivers de hardware, código de aplicação e camadas de abstração.

Outro aspecto importante é o nível de visibilidade: PRIVATE, PUBLIC e INTERFACE. Um include marcado como PRIVATE só é usado internamente pelo alvo. PUBLIC é usado pelo alvo e também propagado para quem o linkar. INTERFACE não é usado pelo próprio alvo, mas apenas pelos consumidores. Essa distinção é extremamente poderosa para firmware, pois permite criar bibliotecas que funcionam como contratos bem definidos entre módulos.

Ao adotar esse modelo, o projeto deixa de depender de “includes mágicos” e passa a ter uma estrutura previsível, rastreável e muito mais fácil de manter ao longo dos anos.

Definições de compilação e macros com target_compile_definitions()

Macros de compilação são inevitáveis em sistemas embarcados. Defines como STM32F4xx, USE_HAL_DRIVER, opções de debug, flags de instrumentação ou seleção de periféricos fazem parte do dia a dia. O problema surge quando essas macros são definidas globalmente, sem controle de escopo.

A diretiva target_compile_definitions() resolve exatamente isso. Assim como acontece com includes, as definições passam a pertencer a um alvo específico. Isso significa que um driver pode declarar suas próprias macros, um middleware pode exigir determinadas configurações, e o executável final herda apenas aquilo que faz sentido para ele.

Em projetos STM32 baseados em CubeMX, isso é particularmente relevante porque o código gerado assume a existência de certos defines. Ao propagar essas definições corretamente para bibliotecas externas ou módulos internos, o CMake garante que todo o código seja compilado sob o mesmo contexto, evitando erros sutis e difíceis de diagnosticar.

Outro ponto importante é que essas macros passam a ser documentadas implicitamente pelo sistema de build. Ao inspecionar o CMakeLists.txt, fica claro quais símbolos existem, por que existem e onde são utilizados. Isso é um ganho enorme em projetos de longa duração ou com múltiplos desenvolvedores.

Organização modular com add_subdirectory()

Uma das maiores forças do CMake em projetos STM32 é a possibilidade de fragmentar o sistema de build em múltiplos arquivos pequenos e coesos. A diretiva add_subdirectory() é o mecanismo que permite isso.

Ao adicionar um subdiretório, o CMake passa a processar o CMakeLists.txt contido naquele diretório como parte do projeto principal. Isso é exatamente o que permite isolar o código gerado pelo CubeMX em uma pasta dedicada, mantendo o arquivo principal enxuto e focado na arquitetura do firmware.

Esse modelo também favorece a criação de bibliotecas internas bem definidas. Cada módulo pode ter seu próprio CMakeLists.txt, declarando fontes, includes, defines e dependências de forma local. O projeto principal apenas conecta esses módulos, sem precisar conhecer seus detalhes internos.

Em firmware STM32 mais complexos, essa organização é o que torna viável a manutenção ao longo do tempo. O build deixa de ser um arquivo monolítico e passa a refletir a estrutura real do software.

Linkedição em firmware STM32 com target_link_libraries()

Diferente de aplicações desktop, a linkedição em sistemas embarcados não é apenas uma etapa final automática do build. Ela define o que realmente entra no firmware, como o código é organizado na memória e até quais partes do código serão eliminadas pelo linker. No CMake, o controle desse processo é feito principalmente por meio da diretiva target_link_libraries().

Ao usar target_link_libraries, você declara explicitamente que um alvo depende de outro. No caso de um firmware STM32, isso normalmente significa ligar o executável principal a bibliotecas estáticas que representam o HAL, CMSIS, drivers, middlewares ou módulos internos do projeto. O ponto central é que o CMake transforma essa declaração em ordem correta de linkedição, algo extremamente sensível em ambientes bare-metal.

Em sistemas embarcados, a ordem das bibliotecas importa. Diferente de ambientes com linker dinâmico, o linker bare-metal resolve símbolos em uma única passagem ou em grupos explícitos. O CMake entende essa necessidade e organiza a linha de link automaticamente com base nas dependências declaradas entre os targets. Isso elimina a prática perigosa de “testar ordens até funcionar”.

Outro aspecto importante é que, ao linkar bibliotecas como targets CMake — e não como arquivos .a soltos — o sistema de build passa a conhecer não apenas o binário da biblioteca, mas também seus includes, defines e opções de compilação. Isso cria um encadeamento coerente de dependências, reduzindo drasticamente inconsistências entre módulos.

Bibliotecas estáticas, descarte de código e otimizações agressivas

Em firmware STM32, quase sempre se trabalha com linkedição com garbage collection de seções (--gc-sections). Isso significa que qualquer função ou dado não referenciado será eliminado do binário final. Esse comportamento é desejável para reduzir tamanho, mas exige disciplina arquitetural.

Quando uma biblioteca estática é linkada ao firmware, apenas as partes efetivamente utilizadas entram no .elf. Porém, se a ordem de link estiver errada ou se símbolos forem referenciados apenas indiretamente (por exemplo, via ponteiros de função), o linker pode descartar código essencial. O uso correto de target_link_libraries ajuda a minimizar esse risco, pois o CMake mantém a relação explícita entre quem fornece e quem consome símbolos.

Além disso, o uso de bibliotecas bem definidas permite aplicar opções de compilação diferentes para cada módulo. Drivers críticos podem ser compilados com otimizações específicas, enquanto código de diagnóstico pode ser compilado de forma mais conservadora. O CMake torna esse tipo de ajuste local e controlável, algo praticamente inviável com Makefiles globais.

Diretórios de bibliotecas e o papel de target_link_directories()

Embora o uso de target_link_directories() exista, em projetos STM32 bem estruturados ele deve ser usado com cautela. Essa diretiva adiciona caminhos de busca para bibliotecas durante a linkedição, mas não cria dependências explícitas entre targets. Por isso, ela é considerada uma solução de menor nível.

Em firmware moderno com CMake, a prática recomendada é quase sempre trabalhar com targets reais, criados via add_library(), e ligá-los diretamente ao executável. Isso torna o build mais robusto, mais legível e menos dependente de detalhes implícitos do ambiente.

Ainda assim, existem cenários legítimos para target_link_directories, como a integração com bibliotecas pré-compiladas fornecidas por fabricantes ou com blobs binários. Nesses casos, o CMake permite isolar esse comportamento em pontos bem definidos do projeto, evitando que ele se espalhe de forma descontrolada.

O script de linkedição e sua relação com o CMake

Em projetos STM32, o script de linkedição (.ld) é tão importante quanto o código-fonte. Ele define o mapa de memória do microcontrolador, separa flash, RAM, stack, heap e regiões especiais. O CMake não substitui esse script, mas orquestra seu uso.

Ao configurar corretamente as flags de linkedição no CMake, o script .ld passa a fazer parte formal do processo de build. Isso significa que diferentes perfis de build podem usar scripts diferentes, algo extremamente útil para cenários como bootloaders, aplicações dual-bank ou firmware com atualização segura.

Mais uma vez, o CMake atua como um integrador arquitetural, garantindo que compilador, linker e layout de memória trabalhem de forma coerente.

Coleções de arquivos e BLOBs com file(GLOB …)

O CMake oferece a diretiva file(GLOB …) como uma forma de criar automaticamente listas de arquivos a partir de padrões, algo semelhante ao uso de curingas no shell. Em projetos embarcados, essa funcionalidade costuma gerar debates acalorados, pois envolve um equilíbrio delicado entre conveniência e previsibilidade.

Quando usamos file(GLOB), o CMake percorre um diretório e coleta todos os arquivos que correspondem a um determinado padrão, como todos os .c ou .h. Isso permite reduzir listas extensas e repetitivas de arquivos, especialmente em módulos com grande quantidade de fontes homogêneas, como drivers ou middlewares.

Em projetos STM32 derivados do CubeMX, esse mecanismo pode ser útil para lidar com conjuntos de arquivos que seguem uma estrutura estável, como diretórios de drivers ou bibliotecas externas que não sofrem alterações frequentes. Nesses casos, o GLOB atua como uma forma de declaração implícita de intenção: todo arquivo daquele tipo naquele diretório faz parte do módulo.

No entanto, existe um ponto crítico: o CMake não reavalia automaticamente os GLOBs quando novos arquivos são adicionados. Isso significa que, se um desenvolvedor cria um novo arquivo .c, ele pode não ser incluído no build até que o CMake seja reconfigurado. Em firmware, onde builds automatizados e reprodutibilidade são essenciais, esse comportamento precisa ser compreendido e controlado.

Por isso, a recomendação prática é clara: usar file(GLOB) apenas em diretórios cujo conteúdo é considerado estável, ou em bibliotecas externas que não fazem parte do ciclo de desenvolvimento diário. Para o código principal da aplicação, listas explícitas de arquivos continuam sendo a opção mais segura e transparente.

BLOBs binários: quando o código não é tudo

Em projetos STM32 reais, nem tudo é código-fonte. É comum lidar com BLOBs binários, como tabelas de fontes, imagens, firmware de coprocesso, certificados, ou até microcódigos proprietários fornecidos por terceiros. Integrar esses artefatos ao firmware exige cuidado, e o CMake oferece ferramentas adequadas para isso.

Uma abordagem comum é tratar esses BLOBs como arquivos de entrada do processo de build, convertendo-os em objetos ou seções específicas que serão linkadas ao firmware. O CMake permite gerenciar esses arquivos como fontes do alvo, mesmo que não sejam compilados no sentido tradicional.

O ponto central aqui é que o CMake não faz distinção conceitual entre “código” e “dados”. Ele trabalha com artefatos que participam do processo de geração do binário final. Isso torna possível incorporar recursos binários ao firmware de forma controlada, documentada e reproduzível.

Quando combinado com scripts de conversão e regras customizadas, o CMake se torna uma ferramenta poderosa para integrar dados externos ao firmware STM32, sem recorrer a soluções ad hoc ou etapas manuais frágeis.

Perfis de build e CMakePresets.json

À medida que projetos STM32 crescem, o simples uso de CMAKE_BUILD_TYPE passa a não ser suficiente. Diferentes desenvolvedores, máquinas e pipelines precisam gerar builds consistentes sem depender de longas linhas de comando. É aqui que entram os presets do CMake.

O arquivo CMakePresets.json permite definir perfis de configuração e build de forma declarativa. Em vez de memorizar comandos, o desenvolvedor escolhe um preset, e o CMake aplica automaticamente gerador, diretórios de build, toolchain e variáveis de cache. Isso reduz drasticamente erros humanos e melhora a experiência de uso.

Em projetos STM32, presets são especialmente úteis para encapsular diferentes toolchains, placas-alvo ou modos de operação. Um mesmo projeto pode gerar firmware para múltiplas variantes de hardware sem que isso se torne um pesadelo de manutenção.

Além disso, presets se integram muito bem com editores modernos e ferramentas de automação, tornando o fluxo de desenvolvimento mais profissional e previsível.

Toolchains cruzadas no CMake: separando o “como compilar” do “que compilar”

Em sistemas embarcados, o compilador não roda no mesmo ambiente do software gerado. Compilamos no host (Linux, Windows ou macOS) para executar em um microcontrolador ARM Cortex-M. Esse modelo exige uma toolchain cruzada, normalmente baseada no arm-none-eabi-gcc. O CMake trata essa realidade de forma elegante ao separar completamente o conceito de projeto do conceito de toolchain.

No CMake, a toolchain não deve ser definida dentro do CMakeLists.txt principal. Em vez disso, ela é descrita em um arquivo .cmake dedicado, passado ao CMake no momento da configuração. Essa decisão arquitetural é extremamente importante, pois evita que o projeto fique acoplado a um compilador específico ou a caminhos absolutos do sistema.

Um arquivo de toolchain define coisas como:

  • qual compilador C e ASM será usado
  • qual linker será invocado
  • quais ferramentas auxiliares (objcopy, size, objdump) fazem parte do fluxo
  • quais flags são obrigatórias para aquela arquitetura

No contexto STM32, esse arquivo encapsula todo o conhecimento sobre a plataforma Cortex-M, deixando o restante do projeto livre para se concentrar na arquitetura do firmware, e não em detalhes do compilador.

Arquivos de toolchain para STM32 e CubeIDE

Quando usamos o GCC fornecido pelo STM32CubeIDE, a toolchain já existe, mas normalmente está escondida dentro da IDE. Ao trabalhar com CMake, precisamos tornar isso explícito. É exatamente para isso que surgem arquivos como cubeide-gcc.cmake.

Esse tipo de arquivo informa ao CMake onde encontrar o compilador arm-none-eabi-gcc, qual prefixo usar, como tratar o assembler e quais ferramentas adicionais fazem parte do toolchain. Além disso, ele define que o sistema alvo não é um sistema operacional tradicional, mas sim um ambiente bare-metal.

Essa distinção é crucial. Ao informar ao CMake que o sistema alvo não possui libc padrão, filesystem ou runtime POSIX, evitamos que ele tente realizar testes de compilação ou linkedição incompatíveis com microcontroladores. O build passa a ser previsível e alinhado com a realidade do hardware.

Outro benefício direto é que o mesmo projeto pode ser compilado com toolchains diferentes apenas trocando o arquivo de toolchain, sem tocar em uma única linha do CMakeLists.txt principal. Isso é extremamente valioso em ambientes profissionais, onde certificações, auditorias ou requisitos de longo prazo exigem controle fino sobre a ferramenta de compilação.

Integração da toolchain com presets e automação

Quando combinamos arquivos de toolchain com CMakePresets.json, o fluxo de build se torna ainda mais robusto. O preset passa a declarar explicitamente qual toolchain deve ser usada, qual gerador será adotado e onde os artefatos de build serão gerados.

Isso elimina a dependência de documentação informal do tipo “compile assim no seu computador” e transforma o processo de build em algo reproduzível por definição. Qualquer desenvolvedor, ou mesmo um sistema de integração contínua, consegue gerar exatamente o mesmo firmware a partir do mesmo código-fonte.

Em projetos STM32 maiores, é comum ter presets separados para diferentes placas, diferentes microcontroladores ou diferentes perfis de memória. O CMake lida com isso de forma natural, sem duplicação de código e sem gambiarras.

Arquivos de apoio: includes, perfis e configuração externa

À medida que o projeto cresce, surge a necessidade de arquivos auxiliares para organizar o build. Em vez de concentrar tudo no CMakeLists.txt principal, o CMake incentiva a criação de arquivos .cmake especializados: um para toolchain, outro para configuração de RTOS, outro para opções de análise, outro para perfis de instrumentação.

Essa abordagem se encaixa perfeitamente com firmware STM32 moderno, onde diferentes builds podem habilitar logs, medições de tempo, análise de stack ou até funcionalidades experimentais. Cada uma dessas variações pode ser descrita de forma limpa e modular, sem poluir a lógica central do projeto.

O resultado final é um sistema de build que deixa de ser um obstáculo e passa a ser um ativo técnico do projeto.

Fluxo completo de build: do CubeMX ao firmware final

Uma vez compreendidos os conceitos fundamentais do CMake, o fluxo de trabalho em um projeto STM32 torna-se claro, previsível e altamente profissional. O ponto de partida continua sendo o STM32CubeMX, responsável por gerar o código de inicialização, HAL, CMSIS e o script de linkedição. A diferença é que, em vez de amarrar o projeto a uma IDE específica, o CubeMX passa a ser apenas um gerador de código, e não o dono do processo de build.

Após gerar ou atualizar o código, o projeto é estruturado de forma que esse conteúdo fique isolado em um subdiretório, normalmente tratado como um módulo independente. O CMakeLists.txt principal atua como o orquestrador, conectando esse código gerado à aplicação, às bibliotecas internas e às dependências externas. Essa separação garante que futuras regenerações do CubeMX não quebrem a arquitetura do projeto.

A etapa seguinte é a configuração do build. Aqui, o CMake lê o CMakeLists.txt, o arquivo de toolchain e, quando presentes, os presets. Esse momento não gera binários; ele apenas constrói o modelo interno do projeto. É nesse ponto que erros de configuração, caminhos incorretos ou inconsistências arquiteturais aparecem — e é exatamente onde eles devem aparecer.

Com a configuração concluída, o processo de compilação e linkedição passa a ser mecânico. O CMake invoca o compilador correto, aplica as flags definidas, executa o linker com o script apropriado e gera o arquivo .elf, que representa o firmware completo. A partir dele, ferramentas auxiliares convertem o binário para .bin ou .hex, prontos para gravação no microcontrolador.

Esse fluxo é repetível, automatizável e independente de IDE, o que representa um salto de maturidade em relação a projetos embarcados tradicionais.

Geração de bibliotecas estáticas reutilizáveis

Um dos maiores ganhos ao adotar CMake em projetos STM32 é a facilidade de criar e reutilizar bibliotecas estáticas. Drivers, middlewares, camadas de abstração e até subsistemas inteiros podem ser encapsulados em bibliotecas independentes, com seus próprios includes, defines e opções de compilação.

Essas bibliotecas deixam de ser “copiadas e coladas” entre projetos e passam a ser componentes versionáveis, facilmente integrados por meio de add_subdirectory() ou mecanismos como FetchContent. O CMake garante que cada biblioteca seja compilada no contexto correto e ligada de forma consistente ao firmware final.

Esse modelo é essencial para quem mantém múltiplos projetos STM32 ou deseja construir uma base técnica sólida ao longo do tempo. O build passa a refletir a arquitetura do software, e não apenas uma sequência de comandos.

Erros comuns e armadilhas em STM32 + CMake

Apesar de poderoso, o CMake não perdoa descuidos conceituais. Um erro frequente é tratar o CMakeLists.txt como um Makefile disfarçado, concentrando tudo em um único arquivo, com variáveis globais e pouca modularização. Isso anula grande parte dos benefícios do sistema.

Outro problema recorrente é misturar configurações de toolchain com lógica do projeto. Sempre que o CMakeLists.txt começa a conter caminhos absolutos para compiladores ou flags específicas de uma máquina, o projeto perde portabilidade imediatamente. A separação entre toolchain e projeto é inegociável em ambientes profissionais.

O uso indiscriminado de file(GLOB) também merece atenção. Embora conveniente, ele pode comprometer a reprodutibilidade do build se usado sem critério. Em firmware, previsibilidade sempre deve pesar mais do que comodidade.

Por fim, a falta de entendimento sobre escopos — PRIVATE, PUBLIC e INTERFACE — costuma gerar projetos frágeis, cheios de dependências implícitas. O CMake oferece as ferramentas para evitar isso, mas cabe ao engenheiro usá-las corretamente.

Exemplo ideal de CMakeLists.txt para STM32 (CubeMX) + arquivo .cmake de toolchain

Abaixo vai um exemplo de referência (um “padrão ouro” pragmático) para projetos STM32 gerados pelo CubeMX. Ele aplica todas as diretivas que discutimos e deixa claro, por comentários, por que cada parte existe. Em seguida, incluo um arquivo .cmake de toolchain para arm-none-eabi-gcc (modelo compatível com GCC do CubeIDE ou GNU Arm Embedded).

Observação importante: este exemplo assume uma árvore típica:

  • Core/ e Drivers/ vindos do CubeMX
  • startup/ com startup assembly
  • linker/ com o .ld
  • app/ para seu código autoral
  • cmake/ para toolchain e helpers

CMakeLists.txt (raiz do projeto)

# ============================================================
#  CMakeLists.txt - Projeto STM32 (CubeMX) com arquitetura limpa
# ============================================================

# 1) Garante previsibilidade de comportamento do CMake.
cmake_minimum_required(VERSION 3.22)

# 2) Declara formalmente o projeto e as linguagens.
#    Em STM32 quase sempre é C + ASM (startup).
project(stm32_firmware
  VERSION 1.0.0
  LANGUAGES C ASM
)

# 3) Controle do padrão de linguagem (contrato explícito com o compilador).
set(CMAKE_C_STANDARD 11)
set(CMAKE_C_STANDARD_REQUIRED ON)
# Em STM32, frequentemente extensões GNU são úteis (HAL/CMSIS às vezes dependem).
set(CMAKE_C_EXTENSIONS ON)

# 4) Define um build type padrão quando o gerador é single-config (Makefiles/Ninja).
#    Em multi-config (ex.: Visual Studio), isso é ignorado.
if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
  set(CMAKE_BUILD_TYPE Debug CACHE STRING "Build type" FORCE)
endif()

# 5) Diretórios principais do projeto
set(APP_DIR       ${CMAKE_SOURCE_DIR}/app)
set(CORE_DIR      ${CMAKE_SOURCE_DIR}/Core)
set(DRIVERS_DIR   ${CMAKE_SOURCE_DIR}/Drivers)
set(STARTUP_DIR   ${CMAKE_SOURCE_DIR}/startup)
set(LINKER_DIR    ${CMAKE_SOURCE_DIR}/linker)

# 6) Script de linker (ajuste para o .ld do seu MCU)
set(LINKER_SCRIPT ${LINKER_DIR}/STM32xxxx_FLASH.ld)

# ------------------------------------------------------------
#  BLOBS / Coleções de arquivos (file(GLOB))
#  Use com critério: recomendado para diretórios estáveis (ex.: Drivers).
#  Para app/ prefira listas explícitas (reprodutibilidade).
# ------------------------------------------------------------
file(GLOB HAL_SOURCES
  ${DRIVERS_DIR}/STM32*/Src/*.c
  ${DRIVERS_DIR}/CMSIS/Device/ST/*/Source/Templates/*.c
)

# Exemplo de “BLOB”: um binário que você quer embutir no firmware
# (pode ser fonte, lookup table, certificado, etc.)
set(BLOB_BIN ${CMAKE_SOURCE_DIR}/assets/blob.bin)

# ------------------------------------------------------------
#  7) Biblioteca estática para HAL/CMSIS (reutilizável)
# ------------------------------------------------------------
add_library(stm32_hal STATIC)

# Adiciona fontes do HAL/CMSIS (coleção via GLOB; diretório estável)
target_sources(stm32_hal PRIVATE
  ${HAL_SOURCES}
  # Se você tem system_stm32xxxx.c gerado pelo CubeMX, inclua aqui.
  ${CORE_DIR}/Src/system_stm32xxxx.c
)

# Includes do HAL/CMSIS
target_include_directories(stm32_hal PUBLIC
  ${CORE_DIR}/Inc
  ${DRIVERS_DIR}/CMSIS/Include
  ${DRIVERS_DIR}/CMSIS/Device/ST/STM32xxxx/Include
  ${DRIVERS_DIR}/STM32xxxx_HAL_Driver/Inc
)

# Defines exigidos pelo CubeMX/HAL (escopo bem definido)
target_compile_definitions(stm32_hal PUBLIC
  USE_HAL_DRIVER
  STM32xxxx
)

# Flags específicas por target (ex.: warnings do HAL)
# (Você pode ajustar e mover para um helper .cmake se quiser.)
target_compile_options(stm32_hal PRIVATE
  -Wall -Wextra
)

# ------------------------------------------------------------
#  8) Biblioteca estática para sua camada de aplicação (opcional, mas ideal)
# ------------------------------------------------------------
add_library(app_lib STATIC)

# Para o código autoral, prefira listar explicitamente as fontes:
target_sources(app_lib PRIVATE
  ${APP_DIR}/src/app_main.c
  ${APP_DIR}/src/app_tasks.c
  ${APP_DIR}/src/app_drivers.c
)

target_include_directories(app_lib PUBLIC
  ${APP_DIR}/include
)

target_compile_definitions(app_lib PUBLIC
  APP_VERSION=\"${PROJECT_VERSION}\"
)

# Dependência explícita: app usa HAL
target_link_libraries(app_lib PUBLIC stm32_hal)

# ------------------------------------------------------------
#  9) Firmware final (ELF)
# ------------------------------------------------------------
add_executable(${PROJECT_NAME}.elf)

# Startup (ASM) e fontes CubeMX “Core”
target_sources(${PROJECT_NAME}.elf PRIVATE
  ${STARTUP_DIR}/startup_stm32xxxx.s
  ${CORE_DIR}/Src/main.c
  ${CORE_DIR}/Src/stm32xxxx_it.c
  ${CORE_DIR}/Src/stm32xxxx_hal_msp.c
  ${CORE_DIR}/Src/syscalls.c
  ${CORE_DIR}/Src/sysmem.c
)

# Inclui o BLOB no build (como dependência para empacotar/gerar header, se necessário)
# Aqui mostramos como gerar um .o a partir de .bin (técnica comum).
# Isso requer objcopy da toolchain.
set(BLOB_OBJ ${CMAKE_BINARY_DIR}/blob.o)

add_custom_command(
  OUTPUT ${BLOB_OBJ}
  COMMAND ${CMAKE_OBJCOPY} -I binary -O elf32-littlearm -B arm ${BLOB_BIN} ${BLOB_OBJ}
  DEPENDS ${BLOB_BIN}
  COMMENT "Convertendo BLOB binário em objeto linkável: blob.o"
)

# Adiciona o blob.o ao firmware
target_sources(${PROJECT_NAME}.elf PRIVATE ${BLOB_OBJ})

# Includes do firmware (o executável também pode precisar de headers específicos)
target_include_directories(${PROJECT_NAME}.elf PRIVATE
  ${CORE_DIR}/Inc
  ${APP_DIR}/include
)

# Defines do firmware (ex.: debug, features)
target_compile_definitions(${PROJECT_NAME}.elf PRIVATE
  # Exemplo: liga logs em Debug
  $<$<CONFIG:Debug>:APP_LOG_ENABLE=1>
)

# Linka bibliotecas internas (ordem e dependências ficam claras)
target_link_libraries(${PROJECT_NAME}.elf PRIVATE
  app_lib
  stm32_hal
)

# 10) Flags de link: script .ld, map, gc-sections
target_link_options(${PROJECT_NAME}.elf PRIVATE
  -T${LINKER_SCRIPT}
  -Wl,-Map=${PROJECT_NAME}.map
  -Wl,--gc-sections
  -Wl,--print-memory-usage
)

# (Opcional) Se você precisa apontar diretórios extras de bibliotecas pré-compiladas:
# Use com cautela. Prefira targets CMake quando possível.
# target_link_directories(${PROJECT_NAME}.elf PRIVATE ${CMAKE_SOURCE_DIR}/third_party/lib)

# ------------------------------------------------------------
#  11) Geração de .bin e .hex a partir do .elf
# ------------------------------------------------------------
add_custom_command(TARGET ${PROJECT_NAME}.elf POST_BUILD
  COMMAND ${CMAKE_OBJCOPY} -O ihex   $<TARGET_FILE:${PROJECT_NAME}.elf> ${PROJECT_NAME}.hex
  COMMAND ${CMAKE_OBJCOPY} -O binary $<TARGET_FILE:${PROJECT_NAME}.elf> ${PROJECT_NAME}.bin
  COMMAND ${CMAKE_SIZE} $<TARGET_FILE:${PROJECT_NAME}.elf>
  COMMENT "Gerando artefatos: .hex, .bin e exibindo size"
)

Arquivo de toolchain: cmake/toolchains/arm-none-eabi-gcc.cmake

# ============================================================
#  arm-none-eabi-gcc.cmake - Toolchain STM32 (GCC bare-metal)
#  Use com: cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=...
# ============================================================

# Diz ao CMake que estamos compilando para um sistema "genérico" (bare-metal).
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR arm)

# Evita que o CMake tente rodar executáveis gerados (não rodam no host).
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)

# Prefixo padrão da toolchain GNU Arm Embedded / CubeIDE
set(TOOLCHAIN_PREFIX arm-none-eabi)

# Permite sobrescrever via ambiente, útil em CI:
# export ARM_GCC_PATH=/caminho/para/bin
if(DEFINED ENV{ARM_GCC_PATH})
  set(ARM_GCC_BIN "$ENV{ARM_GCC_PATH}")
else()
  set(ARM_GCC_BIN "") # usa PATH
endif()

# Compiladores
set(CMAKE_C_COMPILER   ${ARM_GCC_BIN}${TOOLCHAIN_PREFIX}-gcc)
set(CMAKE_ASM_COMPILER ${ARM_GCC_BIN}${TOOLCHAIN_PREFIX}-gcc)

# Ferramentas auxiliares (usadas para .bin/.hex e size)
set(CMAKE_OBJCOPY ${ARM_GCC_BIN}${TOOLCHAIN_PREFIX}-objcopy CACHE FILEPATH "")
set(CMAKE_SIZE    ${ARM_GCC_BIN}${TOOLCHAIN_PREFIX}-size    CACHE FILEPATH "")

# Flags de arquitetura (AJUSTE conforme seu MCU: cortex-m4/m7/m33 etc.)
set(ARCH_FLAGS "-mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard")

# Flags comuns
set(COMMON_FLAGS
  "${ARCH_FLAGS} -ffunction-sections -fdata-sections -fno-common"
)

# Debug vs Release pode ser refinado no projeto ou via presets
set(CMAKE_C_FLAGS_INIT "${COMMON_FLAGS}")
set(CMAKE_ASM_FLAGS_INIT "${COMMON_FLAGS}")

# Flags típicas de link em bare-metal (você complementa no target_link_options)
set(CMAKE_EXE_LINKER_FLAGS_INIT
  "${ARCH_FLAGS} -Wl,--gc-sections"
)

# (Opcional) Se você usa newlib-nano e nosys
# set(CMAKE_EXE_LINKER_FLAGS_INIT
#   "${CMAKE_EXE_LINKER_FLAGS_INIT} -specs=nano.specs -specs=nosys.specs"
# )

CMake como ferramenta de engenharia, não apenas de build

Adotar CMake em projetos STM32 não é apenas uma escolha técnica; é uma decisão de engenharia de software. Ele transforma o processo de build em algo declarativo, previsível e alinhado com boas práticas modernas, aproximando o desenvolvimento embarcado do rigor encontrado em sistemas de maior escala.

Quando bem utilizado, o CMake deixa de ser um obstáculo e passa a ser um mapa formal da arquitetura do firmware. Ele documenta dependências, explicita decisões técnicas e reduz drasticamente o custo de manutenção ao longo do tempo.

Para projetos STM32 gerados pelo CubeMX, essa combinação representa o melhor dos dois mundos: a produtividade do gerador de código da ST e a flexibilidade de um sistema de build profissional, independente de IDEs proprietárias.

The post Introdução ao CMake em Projetos STM32 Gerados pelo CubeMX first appeared on MCU & FPGA.

]]> 1069 Como Redirecionar o printf para a UART no STM32F411: Um Guia Completo para Debug Serial https://mcu.tec.br/linguagem/c/como-redirecionar-o-printf-para-a-uart-no-stm32f411-um-guia-completo-para-debug-serial/?utm_source=rss&utm_medium=rss&utm_campaign=como-redirecionar-o-printf-para-a-uart-no-stm32f411-um-guia-completo-para-debug-serial Sat, 06 Dec 2025 22:08:24 +0000 https://mcu.tec.br/?p=964 Este tutorial apresenta um guia completo, didático e detalhado sobre como redirecionar a função printf para a UART no microcontrolador STM32F411, utilizando a placa Nucleo e o ambiente STM32CubeIDE. Explicamos desde a configuração inicial da USART2, o funcionamento da Virtual COM Port (VCP) do ST-LINK, até a implementação da função _write() para capturar a saída de printf e transmiti-la via porta serial. Inclui também recomendações práticas, cuidados com bufferização, técnicas de debug, alternativas como ITM/SWO e RTT, além de exemplos de código e validação com terminal serial no PC. Ideal para estudantes, desenvolvedores e engenheiros que desejam aprimorar a depuração em sistemas embarcados usando STM32.

The post Como Redirecionar o printf para a UART no STM32F411: Um Guia Completo para Debug Serial first appeared on MCU & FPGA.

]]> Por que redirecionar o printf para a UART?

Durante o desenvolvimento de firmware para STM32, uma das formas mais simples e eficazes de entender o comportamento do código é imprimir mensagens de log: valores de variáveis, estados de máquina de estados, mensagens de erro, etc. Em ambientes embarcados, não temos um “console” como no PC, então precisamos escolher um canal físico para transportar essas mensagens. A forma mais comum, simples e robusta é usar uma UART (porta serial) ligada ao computador do desenvolvedor.

Na placa de prototipação Nucleo STM32F411 (por exemplo, NUCLEO-F411RE), o próprio ST-LINK já oferece uma porta serial virtual (Virtual COM Port – VCP). Quando você conecta a placa via USB ao PC, além da interface de debug SWD, é criada uma porta serial (como COMx no Windows ou /dev/ttyACMx no Linux). Essa porta está conectada internamente a um dos periféricos UART do microcontrolador (tipicamente USART2, pinos PA2/PA3), permitindo que tudo o que for enviado por essa UART apareça em um terminal serial no computador.

O artigo da ST sobre redirecionar o printf para uma UART segue justamente essa ideia: em vez de mandar o printf para o “stdout” abstrato, fazemos com que a função de baixo nível que o printf usa internamente envie cada caractere pela UART, por meio da função HAL_UART_Transmit(). Em muitos exemplos oficiais da ST, isso é feito definindo um macro do tipo:

#ifdef __GNUC__
  #define PUTCHAR_PROTOTYPE int __io_putchar(int ch)
#else
  #define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f)
#endif

e depois implementando essa função para transmitir o caractere pela UART configurada. (Gist)

No contexto da Nucleo STM32F411, isso significa que, depois de configurarmos corretamente a UART no STM32CubeIDE (por exemplo, USART2 a 115200 bps, 8N1), qualquer chamada a printf("Hello, world!\r\n"); no código C passará a sair pela porta USB da placa, aparecendo no seu terminal serial. Isso elimina a necessidade de ficar alternando LEDs, pausando com breakpoints, ou usando ferramentas mais complexas de trace apenas para ver valores simples.

Neste tutorial, vamos seguir uma abordagem estruturada, inspirada no procedimento descrito pela ST e em exemplos de comunidade:

  1. Entender a UART e o VCP da Nucleo STM32F411 – quais pinos estão envolvidos, como a UART é ligada ao ST-LINK e à porta USB no PC.
  2. Criar e configurar o projeto no STM32CubeIDE – habilitando a UART correta e os clocks necessários.
  3. Implementar o redirecionamento do printf – adicionando o macro PUTCHAR_PROTOTYPE e a função que chama HAL_UART_Transmit().
  4. Ajustar o buffer e o comportamento do printf – explicando questões como setvbuf(), uso de \n/\r e possíveis travamentos.
  5. Testar com um terminal serial no PC – configurando o terminal, verificando a comunicação e mostrando um exemplo de sessão de debug.
  6. Boas práticas e limitações – impacto em tempo de execução, alternativas (ITM/SWO, semihosting, logs condicionais, etc.).

Ao longo das próximas seções, vamos sempre assumir como placa-alvo a Nucleo STM32F411 e o ambiente de desenvolvimento STM32CubeIDE, usando a HAL da ST. A ideia é que, ao final do tutorial, você tenha um “esqueleto” de projeto no qual basta chamar printf() em qualquer parte do código para enviar mensagens de debug pela UART/USB para o seu PC.

2. Entendendo a UART e a Virtual COM Port (VCP) na Nucleo STM32F411

A plataforma Nucleo STM32F411 possui um recurso extremamente útil para debug: o ST-LINK/V2-1, que integra no mesmo cabo USB tanto a interface de programação/debug quanto uma porta serial virtual que aparece no computador como um dispositivo COM (Windows) ou /dev/ttyACMx (Linux). Essa porta é automaticamente conectada, via jumpers na placa, ao periférico USART2 do microcontrolador STM32F411.

Isso significa que não é necessário nenhum conversor USB-Serial adicional: basta conectar a placa ao PC e abrir um terminal serial. Do ponto de vista elétrico e lógico, o ST-LINK faz a ponte entre os pinos da UART do MCU e o USB do computador, simplificando enormemente o processo de debug.

2.1. Mapeamento de pinos na Nucleo F411RE

Na maioria das placas Nucleo baseadas no F4, o mapeamento é:

  • USART2_TX → PA2
  • USART2_RX → PA3

Esses sinais passam pelo circuito do ST-LINK através de jumpers normalmente identificados como:

  • JP5 (ou equivalente) — controla a conexão da UART ao ST-LINK.

Se os jumpers estiverem na posição padrão (factory default), a UART estará conectada ao ST-LINK, e o printf será exibido no terminal do computador.

2.2. Configuração típica da UART para debug

A configuração mais comum, e recomendada pela ST, é:

  • Baudrate: 115200 bps
  • Bits de dados: 8
  • Paridade: None
  • Stop bits: 1
  • Modo: TX (opcionalmente RX se quiser receber dados)
  • Hardware Flow Control: None

Essas configurações funcionam com praticamente todos os terminais como PuTTY, screen, Minicom, CoolTerm, Serial Studio e o monitor serial da própria ST.

2.3. Clocks envolvidos

A UART só funcionará corretamente se:

  1. O clock do barramento APB1 estiver configurado.
  2. O clock da UART seja habilitado (feito automaticamente pelo CubeIDE ao ativar a USART2).
  3. Os pinos PA2 e PA3 estejam configurados como Alternate Function 7 (AF7).

Todos esses passos serão automatizados quando configurarmos o projeto no STM32CubeIDE, mas é importante compreender que a comunicação serial depende diretamente da estabilidade do clock do sistema. Uma configuração inadequada do PLL ou do HSE/HSI pode fazer a UART transmitir dados corrompidos.

2.4. Como o fluxo de debug é estabelecido

O caminho do printf até o terminal serial pode ser resumido assim:

printf() 
    → função de baixo nível __io_putchar() 
        → HAL_UART_Transmit()
            → USART2
                → ST-LINK (Virtual COM Port)
                    → Cabo USB
                        → PC (Terminal Serial)

Esse pipeline deixa claro que:

  • O printf não sabe nada sobre UART; ele apenas escreve caracteres.
  • Quem realmente envia cada caractere é nossa implementação de _write() ou __io_putchar().
  • Se a UART não estiver inicializada, nada será transmitido.
  • Se a UART bloquear (modo polling), o printf também bloqueará.

Por isso, utilizaremos uma implementação simples usando HAL_UART_Transmit(), que é suficiente para debug e fácil de manter.

3. Configurando o Projeto no STM32CubeIDE para Habilitar a UART

Nesta etapa vamos preparar o ambiente no STM32CubeIDE para que a placa Nucleo STM32F411 use corretamente a USART2 como canal de debug. O CubeIDE facilita muito o processo automatizando a configuração de pinos, clocks e inicialização do HAL.

3.1. Criando um novo projeto

  1. Abra o STM32CubeIDE.
  2. Vá em File > New > STM32 Project.
  3. Pesquise por Nucleo-F411RE.
  4. Selecione a placa e avance.
  5. Escolha o nome do projeto (por exemplo: UART_Debug_Printf).

O CubeIDE automaticamente carregará a configuração de pinos padrão da placa.

3.2. Habilitando a USART2 como canal de debug

  1. No Device Configuration Tool (a tela .ioc), clique no pino PA2 e selecione USART2_TX.
  2. Clique em PA3 e selecione USART2_RX.
  3. No menu lateral, selecione Connectivity → USART2.
  4. Configure como:
  • Mode: Asynchronous
  • Baudrate: 115200
  • Word Length: 8 Bits
  • Parity: None
  • Stop Bits: 1
  • Hardware Flow Control: None

O CubeIDE automaticamente adicionará a chamada:

MX_USART2_UART_Init();

no arquivo main.c.

3.3. Verificando os clocks

Entre em Clock Configuration e confirme:

  • SYSCLK: 84 MHz (valor típico no F411 configurado pelo CubeIDE)
  • APB1: ≤ 42 MHz
  • USART2 Clock: habilitado automaticamente pelo CubeIDE

A UART depende diretamente desses clocks. Se você modificar manualmente o PLL, ajuste os divisores para manter APB1 em valores seguros.

3.4. Interação entre HAL e UART para debug

Ao habilitar a UART no .ioc, o CubeIDE:

  • Gera o handle global UART_HandleTypeDef huart2;
  • Cria a função MX_USART2_UART_Init()
  • Configura os pinos PA2 e PA3 como Alternate Function 7
  • Habilita o clock da USART2

Com isso, HAL_UART_Transmit() já pode ser usado imediatamente na aplicação.

Exemplo simples:

uint8_t msg[] = "UART funcionando\r\n";
HAL_UART_Transmit(&huart2, msg, sizeof(msg)-1, HAL_MAX_DELAY);

Esse é o passo fundamental antes de redirecionar o printf. Sem uma UART funcional, o redirecionamento não terá efeito.

3.5. Compilar e validar

Clique em:

  • Project > Build Project
  • Depois Run ou Debug

Ao conectar a placa ao PC, confirme no sistema operacional que a porta serial virtual foi criada.

Exemplos:

  • Windows: COM5
  • Linux: /dev/ttyACM0

4. Implementando o redirecionamento do printf para a UART

Agora que a USART2 da Nucleo STM32F411 está configurada e testada com um HAL_UART_Transmit() simples, podemos dar o passo mais importante: fazer com que o printf() use essa UART como “saída padrão”.

Em microcontroladores ARM com newlib (caso do STM32CubeIDE, que usa arm-none-eabi-gcc), o printf não escreve diretamente no hardware. Ele chama funções de baixo nível, como _write() ou, em alguns exemplos da ST, uma função auxiliar chamada __io_putchar(). A ideia do redirecionamento é simples:

  • Implementar _write() (ou __io_putchar()) para enviar os bytes pela UART;
  • Compilar e linkar essa implementação junto ao projeto;
  • A partir daí, qualquer printf() encaminha os dados para a UART.

A seguir vou mostrar um modelo que funciona muito bem com o STM32CubeIDE/GCC e a Nucleo F411.

4.1. Incluindo os headers necessários

Primeiro, em um arquivo C do seu projeto (pode ser o próprio main.c ou, melhor ainda, um arquivo dedicado como retarget.c), inclua:

#include "stm32f4xx_hal.h"
#include <stdio.h>
#include <unistd.h>

Depois, declare o handle da UART como extern, pois ele é criado em outro arquivo (gerado pelo CubeIDE):

extern UART_HandleTypeDef huart2;

4.2. Implementando _write() para o GCC/newlib

A abordagem mais robusta, em ambiente GCC + newlib, é sobrescrever a função _write(). O printf acaba chamando _write() internamente para escrever os dados:

int _write(int file, char *ptr, int len)
{
    // Envia o buffer "ptr" com "len" bytes pela UART2
    HAL_UART_Transmit(&huart2, (uint8_t *)ptr, len, HAL_MAX_DELAY);
    return len;
}

Alguns detalhes importantes:

  • O parâmetro file representa o descritor de arquivo (stdout, stderr, etc.). Para debug simples, você pode ignorá-lo.
  • ptr é o endereço do buffer com os caracteres já montados pelo printf.
  • len é a quantidade de bytes a transmitir.
  • HAL_MAX_DELAY faz a função bloquear até a transmissão terminar. É simples e suficiente para debug (não é ideal em aplicações com requisitos de tempo real estritos).

Com essa implementação, qualquer printf() que escreva em stdout já será redirecionado para a UART2.

4.3. Implementando __io_putchar() (opcional, mas comum em exemplos ST)

Em muitos exemplos da ST, você verá o uso de um macro PUTCHAR_PROTOTYPE que mapeia para __io_putchar() (no GCC) ou fputc() (em outros toolchains). Você pode combinar as duas ideias:

#ifdef __GNUC__
/* GCC/STM32CubeIDE usa __io_putchar() internamente em printf em alguns exemplos da ST */
int __io_putchar(int ch)
{
    HAL_UART_Transmit(&huart2, (uint8_t *)&ch, 1, HAL_MAX_DELAY);
    return ch;
}
#else
/* Para outros compiladores, como Keil ou IAR */
int fputc(int ch, FILE *f)
{
    HAL_UART_Transmit(&huart2, (uint8_t *)&ch, 1, HAL_MAX_DELAY);
    return ch;
}
#endif

Se você implementar apenas _write(), o printf já funciona no GCC/newlib. Se quiser compatibilidade máxima com exemplos da ST e outros toolchains, mantenha também __io_putchar()/fputc().

4.4. Onde colocar esse código no projeto

Existem duas abordagens:

  1. No próprio main.c
    • Mais simples para começar, ideal para experimentos.
    • Basta inserir a implementação de _write() e/ou __io_putchar() abaixo das includes e da declaração extern UART_HandleTypeDef huart2;.
  2. Em um arquivo separado, por exemplo retarget.c
    • Organização melhor, especialmente em projetos grandes.
    • Crie o arquivo via New > Source File, inclua as cabeçalhos e implemente _write() ali.
    • Não esqueça de adicionar retarget.c ao build (o CubeIDE já faz isso automaticamente ao criar dentro do projeto).

O ponto fundamental é: o arquivo que contém _write()/__io_putchar() precisa ser compilado junto com o projeto para que o linker substitua a implementação fraca (weak) padrão de _write() pela sua.

4.5. Pequeno exemplo de uso no main.c

Depois de configurada a UART e implementado _write(), o main.c pode conter algo como:

int main(void)
{
    HAL_Init();
    SystemClock_Config();
    MX_USART2_UART_Init();   // Importante: inicializa a UART2 antes do primeiro printf

    printf("Sistema iniciado!\r\n");
    printf("Clock do sistema: %lu Hz\r\n", HAL_RCC_GetHCLKFreq());

    while (1)
    {
        printf("Loop principal, tick = %lu\r\n", HAL_GetTick());
        HAL_Delay(1000);
    }
}

Se tudo estiver correto, essas mensagens aparecerão no terminal serial do seu PC, na porta correspondente à Virtual COM Port, a 115200 bps.

5. Cuidados com printf: buffer, quebra de linha e impacto em tempo real

Com o printf já saindo pela UART2, é hora de falar dos detalhes práticos que mais costumam pegar de surpresa: comportamento de buffer, diferença entre \n e \r\n, e o impacto de sair “espalhando printf pelo código” em um sistema que tem requisitos de tempo real.

5.1. \n vs \r\n – por que às vezes o texto “sobe” no terminal?

Em muitos terminais seriais (PuTTY, Minicom, screen, etc.), o caractere \n (line feed) apenas move o cursor para a linha de baixo, sem retornar para a coluna 0. Já \r (carriage return) volta o cursor para o início da linha, mas não desce. O comportamento mais comum em sistemas embarcados é usar a combinação:

printf("Mensagem de debug\r\n");

Se você usar somente \n, é comum ver efeito de “escada” ou textos desalinhados no terminal. O padrão “universal” para logs em interface serial é \r\n. Se quiser, pode criar um helper:

void logln(const char *msg)
{
    printf("%s\r\n", msg);
}

E usar logln("Sistema iniciado"); ao invés de lembrar sempre do \r\n.

5.2. Bufferização do printf (stdout) e “trava” aparente

Por padrão, a biblioteca C pode bufferizar a saída (stdout). Em ambiente embarcado, isso varia conforme a toolchain, mas alguns sintomas são:

  • Você chama printf("Teste\r\n"); e nada aparece no terminal.
  • Ao chamar outro printf maior ou ao encerrar o programa (em PC), tudo aparece “de uma vez”.

Para evitar esse tipo de surpresa, você pode:

  1. Desabilitar o buffer de stdout (quando suportado), logo após iniciar o sistema: setvbuf(stdout, NULL, _IONBF, 0); // stdout sem buffer Em muitos ambientes embarcados com newlib-nano, isso já é o comportamento, mas não custa colocar.
  2. Sempre finalizar as linhas com \r\n, o que, em algumas implementações, força flush.

Se perceber comportamentos estranhos, experimente remover otimizações extremas de compilação e garantir que _write() está sendo realmente linkado (às vezes uma implementação fraca default pode estar sendo usada por engano).

5.3. Cuidado com o tempo de bloqueio: HAL_UART_Transmit() é bloqueante

Na implementação que fizemos:

int _write(int file, char *ptr, int len)
{
    HAL_UART_Transmit(&huart2, (uint8_t *)ptr, len, HAL_MAX_DELAY);
    return len;
}

o HAL_UART_Transmit() é bloqueante: a CPU fica parada até todos os bytes serem transmitidos. Em termos práticos:

  • Uma linha como
    printf("Valor = %d, estado = %d\r\n", x, estado);
    pode gerar 30–60 bytes.
  • A 115200 bps, você transmite cerca de 11.520 bytes/s (aprox. 10 bits por byte, contando start/stop).
  • Então 50 bytes ≈ 4,3 ms de transmissão não-interrompida.

Se você fizer isso dentro de uma ISR (rotina de interrupção) ou em uma tarefa crítica de tempo real, esses milissegundos a mais podem causar problemas:

  • Perda de deadlines.
  • Atraso na leitura de sensores ou controle de motor.
  • Estouro de watchdog, se o sistema for mais rígido.

Boas práticas:

  • Nunca usar printf em ISR.
    Se precisar debugar uma interrupção, registre flags ou copie dados para um buffer e imprima em contexto de thread/tarefa.
  • Usar printf com parcimônia em laços que rodam com alta frequência.
  • Em sistemas com RTOS, considerar uma tarefa de log dedicada.

5.4. Estratégia com RTOS: fila de logs (opcional, mas muito recomendável)

Se você estiver usando FreeRTOS (ou outro RTOS), uma abordagem mais limpa é:

  1. Criar uma fila (queue) para mensagens de log.
  2. Criar uma tarefa “Logger” que:
    • Bloqueia esperando mensagens na fila.
    • Ao receber, chama HAL_UART_Transmit() para mandar pela UART.
  3. Substituir printf por algo como log_printf(), que formata a string e envia para a fila.

Esboço de ideia (bem simplificado):

// Tamanho máximo de uma mensagem de log
#define LOG_MSG_MAX 128

QueueHandle_t xLogQueue;

void LoggerTask(void *argument)
{
    char msg[LOG_MSG_MAX];

    for (;;)
    {
        if (xQueueReceive(xLogQueue, &msg, portMAX_DELAY) == pdTRUE)
        {
            HAL_UART_Transmit(&huart2, (uint8_t *)msg, strlen(msg), HAL_MAX_DELAY);
        }
    }
}

// Exemplo simples de função de log (sem vsnprintf, apenas ilustrativo)
void log_printf(const char *fmt, ...)
{
    char buffer[LOG_MSG_MAX];
    va_list args;
    va_start(args, fmt);
    vsnprintf(buffer, LOG_MSG_MAX, fmt, args);
    va_end(args);

    xQueueSend(xLogQueue, &buffer, 0);
}

Essa abordagem tira a carga do contexto onde a mensagem é gerada e concentra o custo de transmissão em uma única tarefa de menor prioridade.

5.5. printf grande demais e estouro de stack/heap

Outra armadilha comum: strings muito grandes em printf, especialmente em sistemas com pouco RAM:

  • Cada printf complexa pode usar vsnprintf internamente, exigindo buffers temporários.
  • Se o stack ou heap forem pequenos, isso pode levar a stack overflow ou corromper memória silenciosamente.

Recomendações:

  • Evite prints gigantescos; prefira várias mensagens menores e objetivas.
  • Ajuste o tamanho de stack das tarefas em RTOS que usam printf.
  • Se possível, use a newlib-nano com suporte a printf reduzido (sem float), a menos que precise imprimir float/double.

6. Testando o redirecionamento do printf no PC com terminal serial

Com toda a infraestrutura montada — UART configurada, _write() implementado e printf() funcionando — é hora de validar tudo com um terminal serial no computador. Esta etapa confirma que a Virtual COM Port (VCP) do ST-LINK está operando corretamente e que os dados enviados pelo microcontrolador estão realmente chegando até o PC.

6.1. Identificando a porta serial (VCP) no sistema operacional

Quando você conecta a Nucleo STM32F411 ao computador usando o cabo USB no conector do ST-LINK (não no USB OTG do microcontrolador), o ST-LINK cria automaticamente uma porta serial virtual.

Para verificar:

No Windows

Abra o Gerenciador de Dispositivos → Portas (COM & LPT)
Aparecerá algo como:

  • STMicroelectronics Virtual COM Port (COM5)

O número da porta (COM5, COM7 etc.) varia de máquina para máquina.

No Linux

Use no terminal:

ls /dev/ttyACM*

ou observe mensagens do dmesg:

dmesg | tail

Normalmente será:

  • /dev/ttyACM0
  • /dev/ttyACM1

No macOS

Em geral:

ls /dev/tty.usbmodem*

[Espaço para Imagem 9 – Captura mostrando a porta STMicroelectronics Virtual COM Port no Windows /dev/ttyACM0 no Linux]

6.2. Configurando o terminal serial

Você pode usar ferramentas como:

  • PuTTY
  • screen (Linux/macOS)
  • Minicom
  • CoolTerm
  • Serial Studio
  • TeraTerm

As configurações fundamentais:

  • Baud rate: 115200
  • Data bits: 8
  • Parity: None
  • Stop bits: 1
  • Flow control: None

Essas são as mesmas configurações definidas no CubeIDE para a UART2.

Exemplos:

No PuTTY (Windows):

  • Connection type: Serial
  • Serial line: COM5
  • Speed: 115200
  • Clique em Open.

No Linux (screen):

screen /dev/ttyACM0 115200

Para sair:

  • Pressione: Ctrl + A, depois K.

6.3. Primeiro teste: envio de mensagem simples

Carregue o firmware na placa e inicialize. Logo no início, se o seu main.c tiver:

printf("Sistema iniciado!\r\n");

Você deverá ver no terminal:

Sistema iniciado!

Se após alguns segundos o loop do seu exemplo estiver imprimindo:

printf("Loop principal, tick = %lu\r\n", HAL_GetTick());

Você verá:

Loop principal, tick = 1001
Loop principal, tick = 2002
Loop principal, tick = 3003
...

Se nada aparecer:

  • Verifique a porta correta.
  • Confirme a velocidade (115200).
  • Garanta que MX_USART2_UART_Init() é chamado antes do primeiro printf.
  • Confira se _write() está realmente sendo compilado (abra a pasta /Debug e verifique se retarget.o está lá).
  • Veja se PA2/PA3 não foram sobrescritos no .ioc.

6.4. Segundo teste: envio de valores variáveis

Para testar formatação e estabilidade, experimente inserir:

int contador = 0;
while (1)
{
    printf("Contador = %d\r\n", contador++);
    HAL_Delay(500);
}

Após rodar, o terminal deve exibir algo como:

Contador = 0
Contador = 1
Contador = 2
Contador = 3
...

Esse teste simples valida:

  • Integração com printf
  • Transmissão contínua
  • Quebras de linha \r\n
  • Buffer do terminal
  • Confiabilidade da UART

7. Boas práticas, alternativas ao printf e resumo final

Agora que o redirecionamento do printf para a UART está funcionando e validado no terminal, é importante fechar o tutorial consolidando boas práticas e apresentando métodos alternativos de debug que podem ser superiores dependendo do contexto do projeto.

7.1. Boas práticas ao usar printf em sistemas embarcados

O printf é muito útil para desenvolvimento, testes e prototipagem. Porém, em firmware profissional, seu uso deve ser criterioso. Aqui estão as principais recomendações:

1. Evite usar printf dentro de interrupções (ISR)

Como vimos, o HAL_UART_Transmit() é bloqueante. Se for chamado dentro de uma interrupção:

  • A interrupção ficará presa transmitindo os bytes,
  • O sistema pode perder deadlines,
  • Outras interrupções podem ser atrasadas,
  • Pode ocorrer estouro do watchdog.

Sempre registre dados críticos em buffers e imprima em contexto de thread.

2. Não abuse do printf em laços rápidos

Se o loop roda a cada 1 ms e imprime texto extenso, a UART não acompanhará o ritmo. Isso pode causar:

  • Travamento aparente,
  • Perda de cadência no controle,
  • Saturação de buffer,
  • Queda de desempenho.

3. Evite printf com floats

O suporte a float aumenta muito o tamanho do binário e o custo computacional.
Prefira converter para inteiro multiplicando por 100 ou 1000:

printf("Temperatura = %d.%02d C\r\n", (int)temp, (int)(temp * 100) % 100);

4. Desative logs em builds finais

Em builds de produção, é comum:

  • Compilar sem logs,
  • Usar #define DEBUG para habilitar/desabilitar os prints,
  • Criar macros como:
#ifdef DEBUG
    #define debug_printf(...) printf(__VA_ARGS__)
#else
    #define debug_printf(...)
#endif

Assim você elimina overhead quando não precisa de logs.

7.2. Alternativas avançadas ao printf

Embora a UART seja excelente para debug, ela não é a única nem a melhor solução em todos os casos.

1. ITM/SWO (Single Wire Output)

Disponível na maioria dos STM32F4, incluindo o F411.
Oferece:

  • Alta velocidade,
  • Impressão quase imediata,
  • Baixíssimo overhead,
  • Não bloqueia o firmware,
  • Funciona dentro de ISR.

Requer que seu ST-LINK suporte SWO (quase todos os V2-1 suportam).

A função usada no HAL é:

ITM_SendChar(ch);

Muitos desenvolvedores substituem __io_putchar() para cair aqui.

2. RTT (Real-Time Transfer) – SEGGER J-Link

Se você usa J-Link:

  • RTT é extremamente rápido,
  • Zero bloqueio,
  • Permite canais bidirecionais,
  • Ideal para sistemas de alto desempenho.

Funciona mesmo com microcontroladores sem UART sobrando.

3. Semihosting

O printf é exibido no console do IDE, sem precisar de UART.

Porém:

  • Extremamente lento,
  • Bloqueante,
  • Inadequado para quase tudo exceto testes acadêmicos.

4. Logs estruturados por DMA

Você pode configurar a UART com DMA circular para transmitir logs sem bloquear a CPU.
Exige controle mais sofisticado, mas reduz o custo de tempo real.

7.3. Resumo final do processo

Aqui está um resumo objetivo de tudo o que você implementou:

  1. Configure a USART2 no CubeIDE usando PA2 (TX) e PA3 (RX), 115200 bps.
  2. Confirme que a VCP do ST-LINK está ativa (porta COM/ttyACM).
  3. Compile o projeto e inicialize a UART com MX_USART2_UART_Init().
  4. Implemente a função _write() ou __io_putchar() para enviar caracteres via HAL_UART_Transmit().
  5. Teste com um terminal serial como PuTTY, Minicom ou screen.
  6. Use \r\n para evitar quebras de linha incorretas.
  7. Evite printf em ISR e em laços críticos.
  8. Em aplicações mais avançadas, considere alternativas como ITM/SWO ou RTT.

Com isso, você agora possui um ambiente completo, simples e confiável para fazer debug via UART no STM32F411 — exatamente como demonstrado no guia da ST, mas adaptado para o contexto da Nucleo.

The post Como Redirecionar o printf para a UART no STM32F411: Um Guia Completo para Debug Serial first appeared on MCU & FPGA.

]]> 964 Introdução às Estruturas de Controle em C/C++ para Sistemas Embarcados https://mcu.tec.br/linguagem/c/introducao-as-estruturas-de-controle-em-c-c-para-sistemas-embarcados/?utm_source=rss&utm_medium=rss&utm_campaign=introducao-as-estruturas-de-controle-em-c-c-para-sistemas-embarcados Thu, 07 Aug 2025 00:07:27 +0000 https://mcu.tec.br/?p=661 Aprenda a usar if, while, for, switch e outras estruturas de controle em C/C++ com exemplos práticos para STM32. Ideal para iniciantes em firmware!

The post Introdução às Estruturas de Controle em C/C++ para Sistemas Embarcados first appeared on MCU & FPGA.

]]> No universo da programação de sistemas embarcados, especialmente para microcontroladores como os da família STM32, compreender e dominar as estruturas de controle da linguagem C e C++ é absolutamente essencial. Essas estruturas são os blocos fundamentais que determinam o fluxo de execução de um programa — ou seja, quando e como determinadas instruções devem ser executadas. Em firmware embarcado, onde a previsibilidade, a eficiência e o controle fino sobre o hardware são cruciais, esse conhecimento ganha ainda mais relevância.

O que são estruturas de controle?

Estruturas de controle são instruções que permitem ao programador manipular o fluxo de execução de um programa. Elas englobam:

  • Condicionais, como if, else if, else e switch, que executam blocos de código com base em decisões lógicas.
  • Laços de repetição, como for, while e do while, que permitem repetir instruções com base em condições previamente definidas ou atualizadas dinamicamente.

Essas estruturas simulam o raciocínio lógico de um sistema inteligente: “Se a temperatura ultrapassar 50°C, desligue o motor” ou “Enquanto o botão estiver pressionado, mantenha o LED aceso”.

Por que elas são fundamentais em C/C++?

A linguagem C, e por consequência o C++, são linguagens estruturadas que permitem alto desempenho e controle total sobre os recursos da máquina. Esse controle é o que torna o C ideal para programação de baixo nível em sistemas embarcados.

O uso correto de estruturas de controle permite:

  • Melhor legibilidade e organização do código.
  • Execução determinística, essencial para aplicações de tempo real.
  • Otimização de recursos limitados, como memória e processamento.
  • Evitar desperdícios de energia em projetos alimentados por bateria.

Estruturas de controle em programação embarcada vs. programação geral

Embora as estruturas de controle sejam sintaticamente iguais na programação geral (como aplicações desktop) e na programação embarcada, o contexto de uso é profundamente diferente. Na programação geral, errar uma lógica de controle pode causar lentidão ou um travamento. Já em sistemas embarcados, pode causar falha de segurança, mau funcionamento de um equipamento industrial ou dano físico ao hardware.

Além disso, programadores embarcados devem lidar com interrupções, acesso direto a registradores, uso de GPIOs, timers, watchdogs, e necessidades críticas de tempo. Por isso, o uso incorreto de laços ou condicionais pode causar latência inesperada, deadlocks ou até erro de watchdog reset.

Exemplo prático: Controle de um LED com base em um botão

Imagine que queremos controlar um LED no STM32F103C8T6 (Blue Pill) que acende somente se um botão estiver pressionado. Este tipo de lógica depende diretamente de estruturas de controle — neste caso, uma simples instrução if pode definir o comportamento inteiro do hardware.

Nas próximas seções, você entenderá com detalhes cada uma dessas estruturas, incluindo:

  • O que são e como funcionam
  • Diferenças práticas em sistemas embarcados
  • Exemplos didáticos e aplicações reais no STM32
  • Armadilhas comuns e boas práticas

Cada estrutura será explicada com exemplos práticos usando STM32CubeIDE, com foco em GPIOs e timers da família STM32F1 ou STM32F4, promovendo um aprendizado aplicável desde o primeiro projeto.

Estruturas Condicionais – if, else if, else

1. Como funciona if, else if, else em C/C++

Essas são estruturas de decisão que permitem que o programa execute blocos diferentes de código com base em condições lógicas. A estrutura if avalia uma condição: se for verdadeira, executa um bloco de código; se não, pode cair em um else if (nova condição) ou em um else (condição final padrão).

Sintaxe:

if (condicao1) {
    // Bloco executado se condicao1 for verdadeira
} else if (condicao2) {
    // Executado se condicao1 for falsa e condicao2 for verdadeira
} else {
    // Executado se nenhuma das condições anteriores for verdadeira
}

2. Diferenças no uso embarcado vs. uso geral

Na programação embarcada, o uso de condicionais deve ser pensado com mais cuidado, pois:

  • A frequência de execução é geralmente maior (em loops contínuos).
  • Decisões devem ser rápidas, especialmente em tarefas de tempo real.
  • Pode haver dependência de registradores de hardware, como entradas de GPIO, flags de timers ou interrupções.

Em sistemas embarcados, usar condicionais de forma ineficiente pode impactar o tempo de resposta do sistema.

3. Exemplo básico em C (uso genérico)

#include <stdio.h>

int main() {
    int temperatura = 35;

    if (temperatura > 40) {
        printf("Alerta: Temperatura alta!\n");
    } else if (temperatura > 30) {
        printf("Temperatura confortável.\n");
    } else {
        printf("Temperatura baixa.\n");
    }

    return 0;
}

4. Exemplo com STM32 – Acendendo um LED com botão

Este exemplo considera um STM32F103C8T6 (Blue Pill), com o botão ligado ao pino PA0 e o LED ao PC13.

Código comentado (STM32CubeIDE + HAL):

/* Inclusões necessárias */
#include "main.h"

int main(void) {
  HAL_Init();                // Inicializa a HAL da ST
  SystemClock_Config();      // Configura o clock
  MX_GPIO_Init();            // Inicializa os GPIOs configurados no CubeMX

  while (1) {
    // Lê o estado do botão (PA0 configurado como entrada com pull-up)
    GPIO_PinState botao = HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_0);

    // Se o botão estiver pressionado (nível baixo, pois há pull-up)
    if (botao == GPIO_PIN_RESET) {
      // Liga o LED (PC13 com lógica invertida - 0 liga)
      HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_RESET);
    } else {
      // Desliga o LED
      HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_SET);
    }
  }
}

Comentários importantes:

  • HAL_GPIO_ReadPin lê o estado de um pino (retorna GPIO_PIN_SET ou GPIO_PIN_RESET).
  • O botão está ligado entre o pino e o GND, com pull-up interno ativado (nível baixo indica pressionado).
  • O LED do Blue Pill está em PC13, e acende com nível baixo.

5. Boas práticas e armadilhas comuns

✅ Boas práticas:

  • Use else if com parcimônia: muitas condições aninhadas indicam que um switch pode ser mais adequado.
  • Quando usar if em tempo real, certifique-se de que a condição é rápida de avaliar (sem cálculos pesados).
  • Prefira nomes de variáveis claros para as condições: if (botao_pressionado) é mais legível que if (x).

❌ Armadilhas comuns:

  • Evitar if com chamadas de função que tenham efeitos colaterais: if (le_sensor() > 100) {...} // Cuidado se le_sensor() altera estado interno
  • Não esquecer chaves {} mesmo para blocos de uma linha, especialmente em firmware: if (x) comando1(); // perigo se você adicionar um comando2() depois sem {}

Estrutura de Repetição – while

1. Como funciona o while em C/C++

A estrutura while é um laço de repetição que executa um bloco de código enquanto uma condição for verdadeira. Antes de cada iteração, a condição é verificada; se for falsa, o laço termina.

Sintaxe:

while (condicao) {
    // Código repetido enquanto condicao for verdadeira
}

Esse tipo de laço é útil quando não se sabe exatamente quantas vezes o código deverá se repetir, como ao aguardar um sensor alcançar um valor ou esperar uma resposta de comunicação.

2. Diferenças no uso embarcado vs. uso geral

Em sistemas embarcados, o while é frequentemente usado como loop principal infinito (while (1)), responsável por executar continuamente as tarefas do firmware. Também é usado para aguardar estados de hardware, como:

  • Esperar o fim de uma conversão ADC.
  • Aguardar a liberação de um barramento I²C.
  • Detectar a mudança de estado de um botão ou sinal digital.

Entretanto, o uso de while exige cuidados críticos em sistemas embarcados:

  • Não bloquear o sistema indefinidamente em laços sem timeout.
  • Evitar while que prendam o processador em espera ativa (busy-wait) — sempre que possível, usar interrupções.

3. Exemplo básico em C (uso genérico)

#include <stdio.h>

int main() {
    int contador = 0;

    while (contador < 5) {
        printf("Contador: %d\n", contador);
        contador++;  // incrementa para evitar loop infinito
    }

    return 0;
}

4. Exemplo com STM32 – Esperar botão ser solto antes de acender o LED

Neste exemplo, o LED acende somente após o botão ser pressionado e solto (evita múltiplas leituras do mesmo evento).

Código comentado:

#include "main.h"

int main(void) {
  HAL_Init();
  SystemClock_Config();
  MX_GPIO_Init();

  while (1) {
    // Espera o botão ser pressionado
    while (HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_0) == GPIO_PIN_SET) {
      // Espera ativa – botão ainda não pressionado
    }

    // Espera o botão ser solto
    while (HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_0) == GPIO_PIN_RESET) {
      // Espera ativa – botão ainda pressionado
    }

    // Liga o LED após pressionar e soltar
    HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_RESET);

    // Aguarda 500 ms com LED ligado
    HAL_Delay(500);

    // Desliga o LED
    HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_SET);
  }
}

Comentários:

  • Essa técnica é chamada de debounce por espera (muito rudimentar, mas didática).
  • O while é usado para aguardar eventos de hardware, uma prática comum, porém idealmente substituível por interrupções.

5. Boas práticas e armadilhas comuns

✅ Boas práticas:

  • Sempre garanta condições de saída seguras do while, especialmente em firmware crítico.
  • Para laços de espera, utilize timeouts: uint32_t start = HAL_GetTick(); while (!condicao && (HAL_GetTick() - start < 100)) { // Aguarda até no máximo 100 ms }
  • Mantenha o corpo do while curto e determinístico — evite executar códigos pesados dentro dele.

❌ Armadilhas comuns:

  • Loops infinitos não justificados (além do loop principal).
  • Laços de espera ativa prolongada podem causar watchdog reset.
  • Esquecer de atualizar a condição: while (x < 10) { // mas x nunca é alterado – loop infinito! }

Estrutura de Repetição – do while

1. Como funciona o do while em C/C++

A estrutura do while é semelhante ao while, mas com uma diferença importante: o bloco de código é executado ao menos uma vez, independentemente da condição, porque a verificação da condição ocorre após a execução.

Sintaxe:

do {
    // Bloco de código executado pelo menos uma vez
} while (condicao);

Essa estrutura é útil quando a lógica exige pelo menos uma execução antes da checagem da condição, como leitura inicial de sensores ou rotinas de inicialização.

2. Diferenças no uso embarcado vs. uso geral

No contexto embarcado, do while é menos comum que while ou for, mas pode ser muito útil para:

  • Realizar uma leitura ou comando de hardware pelo menos uma vez, mesmo que a condição de repetição falhe logo depois.
  • Implementar menus interativos via UART que sejam exibidos ao menos uma vez e permitam repetição condicional.

Porém, por permitir que o bloco execute antes da checagem, é necessário ter mais cautela, especialmente quando se interage com periféricos sensíveis.

3. Exemplo básico em C (uso genérico)

#include <stdio.h>

int main() {
    int numero;

    do {
        printf("Digite um número (0 para sair): ");
        scanf("%d", &numero);
    } while (numero != 0);

    printf("Programa encerrado.\n");
    return 0;
}

4. Exemplo com STM32 – Piscar o LED pelo menos uma vez após botão

Imagine que você queira piscar o LED sempre que o botão for pressionado, pelo menos uma vez, e continuar piscando enquanto o botão permanecer pressionado.

Código comentado:

#include "main.h"

int main(void) {
  HAL_Init();
  SystemClock_Config();
  MX_GPIO_Init();

  while (1) {
    // Verifica se o botão foi pressionado
    if (HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_0) == GPIO_PIN_RESET) {
      // Pisca o LED ao menos uma vez enquanto o botão estiver pressionado
      do {
        // Liga o LED
        HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_RESET);
        HAL_Delay(200);

        // Desliga o LED
        HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_SET);
        HAL_Delay(200);
      } while (HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_0) == GPIO_PIN_RESET);
    }
  }
}

Explicações:

  • Mesmo que o botão seja solto logo após o primeiro if, o LED ainda piscará uma vez.
  • O do while garante que a ação ocorra ao menos uma vez após a detecção de evento.

5. Boas práticas e armadilhas comuns

✅ Boas práticas:

  • Use do while quando for obrigatório executar a lógica ao menos uma vez.
  • Combine com verificações de segurança para evitar acesso a periféricos inválidos logo na primeira execução.

❌ Armadilhas comuns:

  • Usar do while sem entender que a primeira execução ignora a condição.
  • Criar loops que nunca terminam, especialmente em firmware: do { // alguma lógica } while (1); // sem motivo real
  • Executar comandos de hardware antes de garantir que o periférico está pronto — pode causar falha ou travamento.

Estrutura de Repetição – for

1. Como funciona o for em C/C++

A estrutura for é uma forma compacta e poderosa de repetir blocos de código com controle total sobre a variável de iteração. É ideal quando sabemos de antemão quantas vezes o laço deve ser executado.

Sintaxe:

for (inicialização; condição; incremento) {
    // Bloco executado enquanto condição for verdadeira
}

Cada parte tem uma função:

  • Inicialização: executada uma vez antes do laço começar.
  • Condição: avaliada a cada iteração; se falsa, o laço termina.
  • Incremento: executado ao fim de cada iteração.

2. Diferenças no uso embarcado vs. uso geral

Em sistemas embarcados, o for é usado com frequência para:

  • Laços de espera com timeout, evitando while infinitos.
  • Iteração sobre vetores de dados de sensores.
  • Acionamento repetido de saídas ou varredura de múltiplas entradas (ex: linhas de um teclado matricial).
  • Geração de delays simples (não recomendável em aplicações críticas).

Apesar da familiaridade, é essencial garantir que o for não prejudique o tempo de resposta do sistema, especialmente se contiver instruções pesadas ou interações com periféricos.

3. Exemplo básico em C (uso genérico)

#include <stdio.h>

int main() {
    for (int i = 0; i < 5; i++) {
        printf("Contagem: %d\n", i);
    }
    return 0;
}

4. Exemplo com STM32 – Piscar o LED 3 vezes rapidamente

Neste exemplo, usamos um for para piscar o LED três vezes sempre que o botão for pressionado.

Código comentado:

#include "main.h"

int main(void) {
  HAL_Init();
  SystemClock_Config();
  MX_GPIO_Init();

  while (1) {
    // Detecta o botão pressionado (PA0)
    if (HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_0) == GPIO_PIN_RESET) {
      
      // Pisca o LED (PC13) 3 vezes
      for (int i = 0; i < 3; i++) {
        HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_RESET);  // Liga o LED
        HAL_Delay(200);
        HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_SET);    // Desliga o LED
        HAL_Delay(200);
      }

      // Espera o botão ser solto para evitar múltiplas detecções
      while (HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_0) == GPIO_PIN_RESET);
    }
  }
}

Comentários:

  • O laço for controla quantas vezes o LED pisca.
  • O botão deve ser solto para permitir uma nova sequência de piscadas.
  • Esse é um padrão clássico de uso de for em interações humanas com dispositivos embarcados.

5. Boas práticas e armadilhas comuns

✅ Boas práticas:

  • Prefira for quando souber exatamente quantas repetições são necessárias.
  • Mantenha a lógica de controle (i++, por exemplo) simples e previsível.
  • Declare variáveis de controle (int i) dentro do for sempre que possível, para limitar seu escopo.

❌ Armadilhas comuns:

  • Colocar delays longos ou funções bloqueantes dentro do for, tornando o sistema lento.
  • Usar for aninhado sem considerar o tempo total de execução.
  • Esquecer a condição de parada correta: for (int i = 0; i >= 0; i++) // pode nunca terminar

Estrutura de Seleção – switch

1. Como funciona o switch em C/C++

A estrutura switch permite selecionar uma entre várias opções com base no valor de uma variável inteira, caractere ou enum. É mais organizada e eficiente do que múltiplos if...else if quando se tem muitas comparações contra valores fixos.

Sintaxe:

switch (variavel) {
  case valor1:
    // Código se variavel == valor1
    break;
  case valor2:
    // Código se variavel == valor2
    break;
  default:
    // Código se nenhum valor anterior for compatível
}

O break é essencial para evitar que o fluxo continue para o próximo caso (o que chamamos de fall-through, que às vezes é desejado, mas geralmente é um erro acidental).

2. Diferenças no uso embarcado vs. uso geral

No desenvolvimento de firmware, o switch é bastante usado para:

  • Selecionar comandos recebidos via UART, I2C, SPI, etc.
  • Implementar máquinas de estados de forma clara e eficiente.
  • Interpretar botões, menus ou modos de operação.
  • Lidar com interrupções em registradores com múltiplos eventos possíveis (ex: flags de status).

Comparado com if-else, o switch costuma gerar código mais limpo e, em muitos compiladores, mais eficiente (como jump tables em arquiteturas como Cortex-M).

3. Exemplo básico em C (uso genérico)

#include <stdio.h>

int main() {
    int opcao = 2;

    switch (opcao) {
      case 1:
        printf("Opção 1 selecionada.\n");
        break;
      case 2:
        printf("Opção 2 selecionada.\n");
        break;
      default:
        printf("Opção inválida.\n");
    }

    return 0;
}

4. Exemplo com STM32 – Alternar modos de LED com base em uma variável

Imagine que seu sistema pode operar em três modos diferentes, definidos por uma variável modo, que poderia vir de UART, EEPROM, botão ou sensor.

Código comentado:

#include "main.h"

int modo = 0;  // Modo padrão

int main(void) {
  HAL_Init();
  SystemClock_Config();
  MX_GPIO_Init();

  while (1) {
    switch (modo) {
      case 0:  // LED desligado
        HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_SET);
        break;

      case 1:  // LED aceso fixo
        HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_RESET);
        break;

      case 2:  // LED piscando
        HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13);
        HAL_Delay(300);
        break;

      default:  // Caso de segurança
        modo = 0;
        break;
    }

    HAL_Delay(100);  // Delay básico para estabilidade
  }
}

Comentários:

  • A variável modo pode ser alterada por outra função, interrupção, botão ou comando UART.
  • O uso de switch deixa claro o que cada modo faz.
  • O default é importante como segurança contra valores inválidos.

5. Boas práticas e armadilhas comuns

✅ Boas práticas:

  • Sempre inclua um default, mesmo que apenas para segurança.
  • Use break em cada case, exceto quando o comportamento de queda (fall-through) for proposital.
  • Quando usar enum com switch, cubra todos os casos possíveis (o compilador pode ajudar a verificar isso).

❌ Armadilhas comuns:

  • Esquecer o break e causar queda acidental para o próximo caso: switch (x) { case 1: faz_algo(); // sem break, executará também o case 2 case 2: faz_outra_coisa(); }
  • Usar switch para condições complexas que envolvem intervalos ou expressões lógicas — nesse caso, if é mais apropriado.
  • Deixar default vazio, desperdiçando a chance de capturar erros ou valores inesperados.

Conclusão – Domínio das Estruturas de Controle em Sistemas Embarcados

Ao longo deste tutorial, exploramos em profundidade as principais estruturas de controle da linguagem C/C++ — if, else if, else, while, do while, for e switch — com foco especial no desenvolvimento embarcado utilizando microcontroladores da família STM32. Cada estrutura foi analisada não apenas do ponto de vista sintático e conceitual, mas também sob a ótica das restrições, exigências e boas práticas do mundo embarcado, onde cada ciclo de clock, byte de memória e tempo de resposta pode ser crucial.

Compreender essas estruturas não é apenas uma questão de saber “como programar”, mas de aprender a controlar o comportamento de sistemas físicos reais, muitas vezes em tempo real. Decisões lógicas, ciclos de repetição, seleção de caminhos de execução — tudo isso influencia diretamente a maneira como o hardware responde ao ambiente, interage com sensores, aciona atuadores e mantém a estabilidade e segurança do sistema.

É importante destacar que, embora a linguagem C/C++ seja a mesma para desktop e embarcados, o contexto muda completamente. Aqui, o programador embarcado precisa pensar como um arquiteto de sistemas críticos: avaliar os impactos de cada linha de código, antecipar falhas, garantir determinismo e minimizar consumo. O uso criterioso de cada estrutura de controle contribui diretamente para esses objetivos.

O que você aprendeu:

  • Condicionais (if, else) ajudam o firmware a tomar decisões baseadas no estado do sistema ou entrada do usuário.
  • Laços (while, do while, for) possibilitam repetição controlada de tarefas, desde simples contagens até rotinas de varredura de sensores.
  • Seletores (switch) trazem clareza e desempenho para decisões baseadas em múltiplos estados ou comandos.
  • O impacto de cada escolha no comportamento do firmware foi sempre ilustrado com exemplos reais usando STM32CubeIDE e a HAL da ST.

Próximos passos sugeridos:

Se você assimilou bem esses conceitos, o próximo passo natural é aprofundar-se em temas como:

  • Funções e modularização para organizar seu código embarcado.
  • Máquinas de estados finitos (FSM) para controlar comportamentos complexos.
  • Uso eficiente de interrupções (IRQ), timers e periféricos.
  • Gerenciamento de tempo, watchdog e baixo consumo de energia.

Você agora tem a base sólida para transformar lógica em controle físico. O conhecimento das estruturas de controle é seu passaporte para escrever firmwares robustos, eficientes e confiáveis — essenciais em qualquer aplicação embarcada, seja em automação industrial, dispositivos médicos, IoT ou robótica.

The post Introdução às Estruturas de Controle em C/C++ para Sistemas Embarcados first appeared on MCU & FPGA.

]]> 661 Como Estruturar um Projeto Profissional com CMake para o RP2040: Guia Didático Passo a Passo https://mcu.tec.br/linguagem/builds/como-estruturar-um-projeto-profissional-com-cmake-para-o-rp2040-guia-didatico-passo-a-passo/?utm_source=rss&utm_medium=rss&utm_campaign=como-estruturar-um-projeto-profissional-com-cmake-para-o-rp2040-guia-didatico-passo-a-passo Fri, 01 Aug 2025 01:06:42 +0000 https://mcu.tec.br/?p=635 Aprenda a estruturar corretamente um projeto para o microcontrolador RP2040 utilizando CMake. Este guia didático passo a passo explica cada linha do CMakeLists.txt, desde variáveis de ambiente até a geração do firmware .uf2, com foco em boas práticas e clareza para iniciantes.

The post Como Estruturar um Projeto Profissional com CMake para o RP2040: Guia Didático Passo a Passo first appeared on MCU & FPGA.

]]> No universo do desenvolvimento embarcado, a jornada do iniciante pode parecer repleta de barreiras invisíveis. Uma das mais frequentes – e subestimadas – está na estruturação correta do projeto, especialmente quando se trata de plataformas modernas como o RP2040, o microcontrolador da Raspberry Pi Foundation. Antes mesmo de escrever a primeira linha de código C, é essencial compreender como preparar o ambiente de compilação, como organizar os arquivos e como garantir que tudo esteja pronto para transformar ideias em firmware funcional.

Neste contexto, o sistema de build CMake se torna uma ferramenta central. Apesar de sua aparência intimidadora para quem está começando, o CMake é uma ponte poderosa entre o código-fonte e o binário que rodará no seu dispositivo. Ele permite organizar dependências, configurar variáveis, compilar múltiplos arquivos e até mesmo lidar com diferentes toolchains de forma automatizada. E quando combinamos o CMake com o ecossistema do RP2040, especialmente com o Pico SDK, temos um ambiente robusto, escalável e flexível — desde projetos educacionais até aplicações industriais.

Por isso, este artigo tem como objetivo guiar o leitor iniciante passo a passo pela análise de um projeto real baseado no RP2040, explicando detalhadamente cada trecho do arquivo CMakeLists.txt e os scripts auxiliares que compõem a infraestrutura de build. Vamos abordar o papel de cada linha, o porquê das decisões adotadas, e quais boas práticas estão sendo aplicadas — além de sugerir melhorias e comparações com abordagens de outras plataformas.

Este não é apenas um guia técnico: é também um convite à compreensão. Ao final desta leitura, você não apenas será capaz de compilar um projeto com confiança, mas também entenderá por que cada etapa é importante. Assim, poderá adaptar seus projetos futuros com segurança e domínio técnico, explorando todo o potencial do RP2040.

Prepare seu editor de texto e acompanhe cada seção com atenção — pois cada linha que vamos explorar é um pequeno degrau em direção à maestria no desenvolvimento embarcado moderno.

Para este artigo foi usado os seguintes arquivos CMakeLists.txt:

1. Configuração Inicial do CMake: Definindo Versão e Padrões do Projeto

Logo no início do arquivo CMakeLists.txt, temos um trecho essencial para garantir a compatibilidade e padronização do ambiente de compilação. Veja abaixo:

cmake_minimum_required(VERSION 3.13)

set(CMAKE_C_STANDARD 11)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

Explicação Didática

  1. cmake_minimum_required(VERSION 3.13)
    Esta linha define a versão mínima do CMake exigida para processar corretamente este projeto. O valor 3.13 é uma escolha segura para projetos com RP2040, pois é compatível com as versões mais estáveis do SDK da Raspberry Pi e da extensão para VSCode. Se o desenvolvedor tentar compilar o projeto com uma versão mais antiga do CMake, ele receberá uma mensagem de erro clara, evitando comportamento indefinido ou suporte incompleto a recursos.
  2. set(CMAKE_C_STANDARD 11)
    Define que o código C será compilado segundo o padrão C11, uma versão estável e moderna da linguagem C, que inclui melhorias importantes como atomics, static assertions e melhor suporte a multithreading.
  3. set(CMAKE_CXX_STANDARD 17)
    Determina que, caso o projeto inclua arquivos em C++, eles devem seguir o padrão C++17. Este padrão oferece recursos como structured bindings, if constexpr, e std::optional, que podem ser úteis em aplicações mais complexas.
  4. set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
    Esta opção gera o arquivo compile_commands.json, que descreve os comandos de compilação de cada fonte no projeto. Ele é extremamente útil para ferramentas externas como servidores de linguagem (LSPs), linters e analisadores estáticos, como o clangd.

Análise Crítica

  • A escolha de C11 e C++17 é apropriada: garante modernidade sem sacrificar a compatibilidade com a maioria dos toolchains usados no mundo embarcado.
  • A inclusão de CMAKE_EXPORT_COMPILE_COMMANDS mostra preocupação com a qualidade do desenvolvimento, pois favorece a integração com IDEs modernas e ferramentas de verificação de código.
  • Poderia ser interessante tornar os padrões configuráveis via variável de cache (CACHE STRING), permitindo ao usuário customizar sem alterar diretamente o CMakeLists.txt.

Observações Didáticas

  • 🔰 Para iniciantes: Pense nesta seção como o “acordo inicial” entre você e o compilador. Aqui você diz: “vamos trabalhar com a linguagem C moderna, C++ moderno e quero um ambiente que me ajude a detectar erros logo no começo”.
  • 🛠 Boas práticas: Sempre explicite o padrão da linguagem em projetos embarcados. Evita surpresas e garante consistência entre diferentes ambientes de build.
  • 🧠 Dica extra: O compile_commands.json pode ser usado por ferramentas como o clang-tidy ou cppcheck para inspeções profundas do seu código.

2. Configuração da Extensão VSCode e Inclusão do SDK

Após definir os padrões iniciais de compilação, o projeto introduz uma etapa importante para integração com o ambiente de desenvolvimento e o SDK do RP2040. Veja o trecho a seguir:

# == DO NOT EDIT THE FOLLOWING LINES for the Raspberry Pi Pico VS Code Extension to work ==
if(WIN32)
    set(USERHOME $ENV{USERPROFILE})
else()
    set(USERHOME $ENV{HOME})
endif()
set(sdkVersion 2.1.1)
set(toolchainVersion 14_2_Rel1)
set(picotoolVersion 2.1.1)
set(picoVscode ${USERHOME}/.pico-sdk/cmake/pico-vscode.cmake)
if (EXISTS ${picoVscode})
    include(${picoVscode})
endif()
# ====================================================================================

Explicação Didática

  1. Bloco condicional if(WIN32)…
    Aqui é verificado se o sistema operacional é Windows (WIN32). Se for, define a variável USERHOME como o caminho da variável de ambiente USERPROFILE. Caso contrário (Linux/macOS), usa HOME.
    Isso garante portabilidade do projeto entre sistemas operacionais, o que é essencial para ambientes colaborativos e didáticos.
  2. set(sdkVersion ...), toolchainVersion ..., picotoolVersion ...)
    Essas linhas servem como metadados informativos que descrevem as versões usadas no ambiente de desenvolvimento. Embora não sejam diretamente utilizadas pelo CMake nesta etapa, são úteis para documentação, scripts externos ou para controle de consistência do ambiente de build.
  3. set(picoVscode ...) e include(...)
    Essa etapa tenta localizar o arquivo pico-vscode.cmake, que é utilizado pela extensão oficial da Raspberry Pi no VSCode para configurar corretamente o ambiente.
    Se o arquivo existir, ele é incluído, permitindo que recursos como auto-complete, debug remoto, e templates automáticos funcionem adequadamente.

Análise Crítica

  • O uso de EXISTS para checar a presença do arquivo evita erros e torna o projeto mais robusto.
  • Esta seção é essencial para ambientes com suporte a IDEs modernas, mas pode ser omitida com segurança se o projeto for construído apenas via terminal.
  • A presença dos comentários DO NOT EDIT é uma prática comum para marcar blocos sensíveis que são exigidos por ferramentas externas.

Observações Didáticas

  • 🧰 Para iniciantes: Essa parte pode parecer obscura à primeira vista, mas pense nela como a “ponte” entre o CMake e o seu editor (VSCode). Se ela estiver funcionando, você terá suporte a atalhos, intellisense e debug facilitado.
  • 🌍 Dica de compatibilidade: Quando você compartilha seu projeto com colegas usando Windows e você usa Linux (ou vice-versa), esse bloco ajuda a manter tudo funcionando sem dor de cabeça.
  • 📦 Importante saber: Se o arquivo pico-vscode.cmake não estiver instalado, o build ainda funcionará — mas você perderá integração com o VSCode.

3. Parametrização por Ambiente: Importando o env.cmake

Este bloco mostra como carregar configurações externas e definir valores padrão para variáveis críticas de conexão, como Wi-Fi e MQTT. Veja o trecho abaixo:

if(EXISTS "${CMAKE_SOURCE_DIR}/env.cmake")
    include("${CMAKE_SOURCE_DIR}/env.cmake")
    message(STATUS "Arquivo env.cmake carregado com sucesso.")
else()
    message(FATAL_ERROR "Arquivo env.cmake não encontrado!")
endif()

Explicação Didática

  1. if(EXISTS "${CMAKE_SOURCE_DIR}/env.cmake")
    Verifica se o arquivo env.cmake existe no diretório raiz do projeto. Essa verificação é crucial para não interromper o processo de configuração se o arquivo estiver ausente ou mal posicionado.
  2. include(...)
    Se o arquivo existir, ele é carregado e suas variáveis passam a ser conhecidas no escopo do CMake. Isso permite separar a configuração sensível ou personalizada (como senhas e tópicos MQTT) do corpo principal do projeto.
  3. message(STATUS "...") e message(FATAL_ERROR "...")
    Usadas para informar claramente ao usuário o sucesso ou falha dessa etapa. Um erro fatal é gerado se o env.cmake estiver ausente, forçando o desenvolvedor a corrigi-lo antes de prosseguir — uma forma de evitar builds incompletos ou configurações erradas.

A seguir, são aplicadas validações adicionais:

if(NOT DEFINED ENV{WIFI_SSID})
    message(WARNING "Variável WIFI_SSID não definida no .env.")
    set(ENV{WIFI_SSID} "ArvoreDosSaberes")
endif()
# ... outros blocos semelhantes para WIFI_PASSWORD, MQTT_BROKER, etc.

Explicação Didática

Cada bloco verifica se uma variável de ambiente essencial está definida (ENV{VARIAVEL}). Se não estiver, ele:

  • Emite um aviso não fatal, alertando o usuário;
  • Define um valor padrão razoável para que o build continue.

Ao final, todas as variáveis são capturadas explicitamente para o escopo interno do CMake:

set(WIFI_SSID "$ENV{WIFI_SSID}")
set(WIFI_PASSWORD "$ENV{WIFI_PASSWORD}")
set(MQTT_BROKER "$ENV{MQTT_BROKER}")
set(MQTT_BASE_TOPIC "$ENV{MQTT_BASE_TOPIC}")
set(MQTT_RACK_NUMBER "$ENV{MQTT_RACK_NUMBER}")

Análise Crítica

  • O uso do env.cmake permite separar configuração de ambiente do código — uma excelente prática que segue os princípios da engenharia de software moderna.
  • Fornecer valores padrão facilita testes e uso didático, mas o ideal seria mover os valores sensíveis (como senhas) para fora do controle de versão (usando, por exemplo, .gitignore).
  • Poderia haver uma variável global ou opção no CMake para desativar temporariamente os erros fatais, facilitando builds rápidos durante o desenvolvimento.

Observações Didáticas

  • 🧪 Analogia simples: Pense no env.cmake como um “cartão de visita” que você entrega ao projeto, dizendo quem você é (SSID, senha, broker). Assim, ele sabe com quem falar e como se comportar.
  • 📁 Organização é tudo: Ao manter essas variáveis fora do CMakeLists.txt, você pode trocar de rede ou broker sem reconfigurar o projeto inteiro — basta editar ou substituir o env.cmake.
  • 🚫 Cuidado comum: Não deixar o env.cmake com credenciais sensíveis visíveis em repositórios públicos. Para isso, use .gitignore.

4. Inicialização do SDK e Definição do Executável

Com todas as variáveis e configurações preparadas, o próximo passo é estruturar o projeto de forma que o SDK da Raspberry Pi Pico possa ser utilizado corretamente, e o firmware final seja construído como um executável nomeado. O trecho em destaque é o seguinte:

# Pull in Raspberry Pi Pico SDK (must be before project)
include(pico_sdk_import.cmake)

project(firmware_client_mqtt C CXX ASM)

# Initialise the Raspberry Pi Pico SDK
pico_sdk_init()

Explicação Didática

  1. include(pico_sdk_import.cmake)
    Este comando inclui o script pico_sdk_import.cmake, normalmente localizado na raiz do SDK da Raspberry Pi. Ele é responsável por carregar as bibliotecas, drivers e configurações internas que fazem parte do Pico SDK.
    É essencial que esta linha venha antes do comando project(...), pois o SDK precisa estar carregado para que o CMake reconheça suas funções auxiliares como pico_sdk_init() ou pico_enable_stdio_usb().
  2. project(firmware_client_mqtt C CXX ASM)
    Define oficialmente o nome do projeto, bem como os tipos de código que ele conterá:
    • C: código C (linguagem base do projeto);
    • CXX: suporte a C++, mesmo que opcional;
    • ASM: suporte à linguagem Assembly, caso você deseje manipular diretamente registradores ou realizar otimizações de baixo nível.
  3. pico_sdk_init()
    Esta função é uma macro do Pico SDK que realiza a configuração padrão do ambiente, ativando funcionalidades como drivers de hardware (hardware_gpio, hardware_adc, etc.), bibliotecas utilitárias e integração com o sistema de build.

Em seguida, o projeto define o binário principal:

add_executable(firmware_client_mqtt
    firmware_client_mqtt.c
)

E depois configura nome e versão para fins de organização:

pico_set_program_name(firmware_client_mqtt "firmware_client_mqtt")
pico_set_program_version(firmware_client_mqtt "0.1")

Explicação Didática

  1. add_executable(...)
    Esta linha define o arquivo principal a ser compilado, neste caso, firmware_client_mqtt.c. O nome dado ao executável será usado como base para gerar o binário .uf2 (formato de firmware usado pelo RP2040).
    Também é possível incluir múltiplos arquivos .c, .cpp ou .s (Assembly) se o projeto for modularizado.
  2. pico_set_program_name e pico_set_program_version
    Estes comandos definem metadados do projeto, como nome e versão, que podem ser usados por ferramentas de depuração ou sistemas de versionamento. Embora opcionais, são úteis em ambientes colaborativos ou industriais.

Análise Crítica

  • Esta seção está tecnicamente correta e bem estruturada, seguindo as recomendações do Pico SDK.
  • O uso explícito de C, CXX e ASM torna o projeto mais versátil e pronto para escalar em complexidade.
  • O nome do projeto (firmware_client_mqtt) é repetido em vários pontos. Poderia ser definido via uma variável (set(PROJECT_NAME firmware_client_mqtt)) para facilitar manutenção futura.

Observações Didáticas

  • 🚀 Analogia prática: Essa parte é como “ligar a tomada” do seu projeto. Você diz ao sistema: “meu projeto se chama X, usa essas linguagens, e quero usar as bibliotecas do SDK da Raspberry Pi”.
  • 📦 Dica extra: Ao compilar, o CMake vai gerar automaticamente arquivos .elf, .bin e .uf2, prontos para serem gravados na flash do RP2040.
  • 🗃 Boas práticas: Sempre modularize seu código desde o começo. Mesmo que só tenha um arquivo .c, mantenha espaço para crescer (ex: src/, include/).

5. Ativando Entradas/Saídas e Ligando Bibliotecas Essenciais

Depois de declarar o executável e configurar seu nome e versão, o projeto define como o firmware irá se comunicar com o mundo externo — por portas seriais ou USB — e quais bibliotecas devem ser incluídas na hora da linkagem. Veja o trecho:

pico_enable_stdio_uart(firmware_client_mqtt 0)
pico_enable_stdio_usb(firmware_client_mqtt 1)

Explicação Didática

  1. pico_enable_stdio_uart(<target> <boolean>)
    Define se a UART (porta serial física) será usada como saída padrão (stdout) do programa. No exemplo acima, o valor 0 desativa a UART. Isso pode ser útil se o projeto não utilizar os pinos GPIO dedicados à UART, ou se estiver usando USB para comunicação com o PC.
  2. pico_enable_stdio_usb(<target> <boolean>)
    Ativa a comunicação serial via USB virtual (CDC). Com 1, o firmware pode imprimir mensagens no terminal conectado via cabo USB — muito útil para debug com ferramentas como minicom, PuTTY, Thonny ou o console do VSCode.

Em seguida, são declaradas as bibliotecas necessárias à aplicação:

target_link_libraries(firmware_client_mqtt
    pico_stdlib
    pico_cyw43_arch_lwip_threadsafe_background
    pico_lwip_mqtt
)

Explicação Didática

  1. target_link_libraries(...)
    Essa linha especifica quais bibliotecas serão ligadas (linkadas) ao firmware durante a compilação.
    • pico_stdlib: a biblioteca padrão do SDK, que fornece funções básicas como printf, controle de pinos, delays, etc.
    • pico_cyw43_arch_lwip_threadsafe_background: fornece acesso ao chip Wi-Fi CYW43 (usado no RP2040 W) em modo cooperativo com a pilha TCP/IP lwIP.
    • pico_lwip_mqtt: adiciona suporte ao protocolo MQTT com base na biblioteca lwIP, permitindo que o firmware se comunique com brokers MQTT como o Mosquitto, HiveMQ, etc.

Análise Crítica

  • Desativar UART e ativar apenas USB (como neste projeto) é uma escolha moderna e prática, já que a maioria dos computadores não possui porta serial física.
  • O uso de pico_lwip_mqtt demonstra um foco em conectividade IoT. Esta biblioteca ainda é pouco documentada fora dos exemplos oficiais, então usar os exemplos do SDK como base é uma boa prática.
  • Poderia ser interessante encapsular as bibliotecas adicionais em uma função auxiliar (add_custom_dependencies()), principalmente em projetos maiores.

Observações Didáticas

  • 🔌 Para iniciantes: Pense na UART e na USB como “canais de conversa” entre o RP2040 e o mundo externo. Você pode escolher usar um, ambos, ou nenhum.
  • 🧰 Boas práticas: Se for usar UART, lembre-se de configurar os pinos no firmware (gpio_set_function(...)). Se usar USB, não esqueça que a comunicação começa após a USB ser enumerada pelo host — o que leva alguns milissegundos após reset.
  • 🌐 Importante saber: A biblioteca pico_cyw43_arch_lwip_threadsafe_background executa tarefas de rede em segundo plano, sem precisar de um RTOS. Ideal para projetos simples mas que precisam de conectividade Wi-Fi confiável.

6. Inclusão de Diretórios e Definição de Macros de Conexão

Com a estrutura principal pronta e as bibliotecas já ligadas, o projeto agora configura o acesso aos diretórios de cabeçalhos e exporta as variáveis de ambiente para uso direto no código C:

target_include_directories(firmware_client_mqtt PRIVATE ${CMAKE_CURRENT_LIST_DIR})

Explicação Didática

  1. target_include_directories(...)
    Especifica para o compilador onde ele deve procurar os arquivos .h durante a compilação.
    • firmware_client_mqtt: é o alvo (o executável).
    • PRIVATE: significa que esses diretórios são usados apenas internamente para este alvo (e não propagados a outras dependências).
    • ${CMAKE_CURRENT_LIST_DIR}: refere-se ao diretório atual onde está o CMakeLists.txt. Isso permite que o main.c e outros arquivos no mesmo diretório acessem os headers locais diretamente.

Agora, as variáveis de ambiente definidas anteriormente são “injetadas” no código-fonte como macros com #define, utilizando o comando:

target_compile_definitions(firmware_client_mqtt PRIVATE 
    WIFI_SSID=\"${WIFI_SSID}\" 
    WIFI_PASSWORD=\"${WIFI_PASSWORD}\" 
    MQTT_BROKER=\"${MQTT_BROKER}\" 
    MQTT_BASE_TOPIC=\"${MQTT_BASE_TOPIC}\"
    MQTT_RACK_NUMBER=\"${MQTT_RACK_NUMBER}\"
)

Explicação Didática

  1. target_compile_definitions(...)
    Insere macros de pré-processador no projeto. Na prática, é como se o CMake escrevesse automaticamente estas linhas no seu código: #define WIFI_SSID "ArvoreDosSaberes" #define WIFI_PASSWORD "Arduino2022" #define MQTT_BROKER "mqtt.rapport.tec.br" #define MQTT_BASE_TOPIC "rack_inteligente" #define MQTT_RACK_NUMBER "3" Isso permite que o código-fonte seja genérico e portátil, pegando os dados do ambiente e não de strings fixas.

Análise Crítica

  • O uso de target_compile_definitions é altamente recomendável, pois centraliza a configuração no CMake em vez de espalhar definições pelo código-fonte.
  • A sintaxe de escape com \"...\" garante que as strings sejam corretamente interpretadas como literais no código C. Uma falha comum de iniciantes é esquecer essas aspas.
  • Em projetos maiores, pode-se usar arquivos .h autogerados a partir do CMake para organizar essas definições (ex: config.h.in com configure_file()).

Observações Didáticas

  • 🧠 Para iniciantes: Pense que você está mandando um bilhete do CMake para o seu código C. Esse bilhete diz: “ei, aqui está o nome da sua rede Wi-Fi e os dados do MQTT”.
  • ⚠ Erros comuns: Se você esquecer de escapar as aspas (\"), o compilador vai entender errado a definição e gerar erros como “expected identifier”.
  • 🛡 Boas práticas: Nunca inclua senhas reais ou dados sensíveis diretamente no main.c. Use sempre esse método de parametrização, ou proteja via arquivos ignorados no Git.

7. Geração dos Arquivos de Saída: pico_add_extra_outputs

No final do arquivo, encontramos a seguinte linha:

pico_add_extra_outputs(firmware_client_mqtt)

Explicação Didática

Este comando é uma macro fornecida pelo Pico SDK que automatiza a criação de diferentes formatos de saída do firmware. A partir do executável gerado (firmware_client_mqtt.elf), ela cuida de produzir também:

  • firmware_client_mqtt.bin: imagem binária “crua”, usada em alguns programadores.
  • firmware_client_mqtt.uf2: formato específico do RP2040, utilizado para arrastar e soltar o firmware diretamente na unidade USB visível quando o RP2040 está em modo de bootloader.
  • Arquivos .map, .hex, .dis ou .lst também podem ser gerados, dependendo das opções do CMake.

Tudo isso acontece de forma automática, dispensando a escrita manual de comandos extras.

Análise Crítica

  • O uso de pico_add_extra_outputs é obrigatório em projetos com RP2040 se você quiser gerar arquivos .uf2, que são os mais práticos para upload via USB.
  • Essa macro também facilita o debug, já que o .elf gerado pode ser carregado diretamente por ferramentas como GDB, OpenOCD ou o depurador do VSCode.
  • Poderia ser complementada com scripts de pós-build para, por exemplo, copiar o .uf2 para um diretório específico ou ativar gravação automática via picotool.

Observações Didáticas

  • 🧾 Para iniciantes: Essa etapa é como pedir ao compilador: “não me dê só o resultado final, me dê também outras versões do programa — uma para o bootloader, outra para depurar, outra para backup”.
  • 💾 Boas práticas: Após cada build, confira a pasta build/ — os arquivos .uf2, .elf e .bin estarão lá. O .uf2 é o que você deve arrastar e soltar no RP2040 quando ele estiver em modo boot (pressionando o botão BOOTSEL).
  • 🚦 Dica de produtividade: Se você estiver usando VSCode com a extensão oficial, essa macro garante que o botão “Build” funcione corretamente e gere o .uf2 automaticamente.

✅ Finalização da Análise Técnica

Com essa última linha, fechamos a análise completa e detalhada do arquivo CMakeLists.txt. Todas as etapas — desde configuração básica, carregamento do SDK, definição do executável, inclusão de bibliotecas, parâmetros de ambiente até a geração dos arquivos finais — foram explicadas com clareza e espírito didático.

Perfeito! Vamos então à conclusão geral do artigo, amarrando todo o conteúdo de forma coesa e didática.

Conclusão

Ao longo deste artigo, percorremos — linha por linha — a estrutura de um CMakeLists.txt real utilizado em um projeto baseado no microcontrolador RP2040, com foco em conectividade Wi-Fi e MQTT. O objetivo foi mais do que explicar comandos: buscamos desenvolver no leitor a compreensão do porquê de cada configuração, tornando-o capaz de analisar, adaptar e evoluir seus próprios projetos.

Iniciamos com a definição dos padrões de compilação e seguimos pela configuração do ambiente de desenvolvimento, mostrando como tornar o projeto compatível com ferramentas modernas como o VSCode. Depois, vimos como separar parâmetros de configuração em arquivos auxiliares (env.cmake) e como capturar variáveis de ambiente de forma segura e elegante. Em seguida, exploramos a inicialização do SDK, a declaração do executável, a ativação dos canais de comunicação via USB e UART, a ligação com bibliotecas críticas como pico_lwip_mqtt, e, por fim, a geração dos arquivos .uf2 e .elf prontos para gravação.

Além do conteúdo técnico, discutimos boas práticas como:

  • Separar configuração do código-fonte com env.cmake;
  • Utilizar target_compile_definitions para injetar parâmetros no pré-processador;
  • Escapar corretamente strings definidas no CMake;
  • Manter o projeto modular e escalável com target_include_directories e target_link_libraries;
  • Evitar hardcoding de dados sensíveis e trabalhar com variáveis de ambiente.

Esse conhecimento é fundamental para qualquer desenvolvedor embarcado que deseje usar o RP2040 de forma profissional e segura. A compreensão profunda da infraestrutura de build é o que separa um programador iniciante de um desenvolvedor capaz de integrar sistemas complexos, automatizar tarefas, e resolver problemas de forma elegante.

Próximos Passos

Se você chegou até aqui, parabéns! Seu próximo passo pode ser:

  • Explorar o conteúdo do arquivo env.cmake em detalhes;
  • Modularizar seu projeto criando subdiretórios como src/ e include/;
  • Automatizar tarefas de pós-build, como upload via picotool;
  • Adicionar testes unitários usando CMocka ou Unity em conjunto com CMake;
  • Criar templates de projetos reutilizáveis com base nessa estrutura.

Indicações de Leitura Complementar

The post Como Estruturar um Projeto Profissional com CMake para o RP2040: Guia Didático Passo a Passo first appeared on MCU & FPGA.

]]> 635 Operadores em C e C++: Guia Completo com Exemplos e Explicações Didáticas https://mcu.tec.br/linguagem/c/operadores-em-c-e-c-guia-completo-com-exemplos-e-explicacoes-didaticas/?utm_source=rss&utm_medium=rss&utm_campaign=operadores-em-c-e-c-guia-completo-com-exemplos-e-explicacoes-didaticas Thu, 17 Jul 2025 13:53:33 +0000 https://mcu.tec.br/?p=583 Aprenda todos os operadores da linguagem C e C++ com explicações claras, exemplos comentados e aplicação prática. Ideal para iniciantes e estudantes.

The post Operadores em C e C++: Guia Completo com Exemplos e Explicações Didáticas first appeared on MCU & FPGA.

]]> Em linguagens de programação como C e C++, operadores são símbolos que indicam ao compilador a execução de operações específicas sobre variáveis e valores. Eles são fundamentais para a construção de expressões e algoritmos, permitindo realizar desde simples atribuições e comparações até manipulações complexas de bits e ponteiros.

Os operadores podem ser classificados de acordo com a operação que realizam e o número de operandos que utilizam:

  • Unários: atuam sobre um único operando.
  • Binários: atuam sobre dois operandos.
  • Ternários: atuam sobre três operandos (caso único: operador condicional).

Cada operador possui uma precedência (prioridade de execução) e uma associatividade (ordem de avaliação quando há operadores com mesma precedência), o que influencia diretamente no resultado das expressões.

Vamos agora explorar os principais grupos de operadores utilizados em C e C++.

Operadores Aritméticos

Os operadores aritméticos são utilizados para realizar operações matemáticas básicas.

Operador + (adição)

Usado para somar dois valores.

int a = 5 + 3;  // a = 8

Operador - (subtração)

Subtrai o segundo operando do primeiro.

int b = 10 - 4;  // b = 6

Operador * (multiplicação)

Multiplica dois valores.

int c = 4 * 3;  // c = 12

Operador / (divisão)

Divide o primeiro operando pelo segundo. Em inteiros, o resultado é truncado.

int d = 10 / 3;  // d = 3

Operador % (módulo)

Retorna o resto da divisão inteira.

int e = 10 % 3;  // e = 1

Esses operadores funcionam tanto com tipos inteiros quanto com float ou double, com exceção do operador %, que é exclusivo para inteiros.

Operadores de Incremento e Decremento

Esses operadores modificam o valor de uma variável numérica adicionando ou subtraindo 1. Eles podem ser utilizados em forma prefixada ou pós-fixada, com efeitos distintos.

Operador ++ (incremento)

Incrementa o valor de uma variável em 1.

  • Prefixado (++x): incrementa antes de utilizar o valor.
  • Pós-fixado (x++): utiliza o valor atual, depois incrementa.
int x = 5;
int y = ++x;  // x = 6, y = 6 (incrementa antes)
int z = x++;  // x = 7, z = 6 (incrementa depois)

Operador -- (decremento)

Decrementa o valor de uma variável em 1.

  • Prefixado (--x): decrementa antes de usar o valor.
  • Pós-fixado (x--): usa o valor atual, depois decrementa.
int x = 5;
int y = --x;  // x = 4, y = 4
int z = x--;  // x = 3, z = 4

Esses operadores são muito utilizados em loops (for, while) e manipulações simples de contadores.

Operadores Relacionais (de Comparação)

Esses operadores são usados para comparar valores. O resultado é sempre um valor booleano: true (1) ou false (0).

Operador == (igualdade)

Verifica se dois valores são iguais.

int a = (5 == 5);  // a = 1 (true)

Operador != (diferença)

Verifica se dois valores são diferentes.

int b = (5 != 3);  // b = 1 (true)

Operador > (maior que)

Verifica se o valor à esquerda é maior que o da direita.

int c = (10 > 7);  // c = 1 (true)

Operador < (menor que)

Verifica se o valor à esquerda é menor que o da direita.

int d = (2 < 8);  // d = 1 (true)

Operador >= (maior ou igual)

Verifica se o valor à esquerda é maior ou igual ao da direita.

int e = (6 >= 6);  // e = 1 (true)

Operador <= (menor ou igual)

Verifica se o valor à esquerda é menor ou igual ao da direita.

int f = (4 <= 9);  // f = 1 (true)

Esses operadores são frequentemente usados em estruturas de decisão como if, while e for.

Operadores Lógicos

Os operadores lógicos operam sobre valores booleanos, ou seja, verdadeiros (true, em C representado por 1) ou falsos (false, representado por 0). São amplamente utilizados em estruturas de controle de fluxo, como if, while e for.

Operador && (E lógico – AND)

Retorna true se ambos os operandos forem verdadeiros.

int a = (5 > 3) && (2 < 4);  // a = 1 (true)

Se a primeira condição for falsa, a segunda não é avaliada (curto-circuito).

Operador || (OU lógico – OR)

Retorna true se pelo menos um dos operandos for verdadeiro.

int b = (5 < 3) || (2 < 4);  // b = 1 (true)

Se a primeira condição for verdadeira, a segunda não é avaliada.

Operador ! (negação lógica – NOT)

Inverte o valor lógico de uma expressão.

int c = !(5 > 3);  // c = 0 (false)

Esse operador é unário e muito útil para inverter condições ou validar estados.

Operadores de Atribuição

Esses operadores atribuem valores a variáveis. Alguns combinam atribuição com operações aritméticas ou bit a bit.

Operador = (atribuição simples)

Atribui o valor da direita à variável da esquerda.

int a = 10;

Operadores combinados:

Esses operadores realizam uma operação com o valor atual da variável e atribuem o resultado.

  • += → adição e atribuição a += 5; // equivalente a a = a + 5;
  • -= → subtração e atribuição a -= 2; // equivalente a a = a - 2;
  • *= → multiplicação e atribuição a *= 3; // equivalente a a = a * 3;
  • /= → divisão e atribuição a /= 2; // equivalente a a = a / 2;
  • %= → módulo e atribuição a %= 3; // equivalente a a = a % 3;

Esses operadores tornam o código mais conciso e são muito utilizados em contadores, somas acumuladas, e manipulações de variáveis dentro de loops.

Operadores Bit a Bit (Bitwise)

Diferente dos operadores lógicos, que atuam sobre valores booleanos, os operadores bit a bit operam diretamente sobre os bits de valores inteiros. Eles são essenciais para manipulação de registradores, flags, comunicação com hardware e otimizações.

Operador & (E bit a bit – AND)

Realiza uma operação E entre os bits correspondentes dos dois operandos.

int a = 5 & 3;  // 0101 & 0011 = 0001 → a = 1

Operador | (OU bit a bit – OR)

Realiza uma operação OU entre os bits correspondentes.

int b = 5 | 3;  // 0101 | 0011 = 0111 → b = 7

Operador ^ (OU exclusivo – XOR)

Retorna 1 se os bits comparados forem diferentes.

int c = 5 ^ 3;  // 0101 ^ 0011 = 0110 → c = 6

Operador ~ (negação bit a bit – NOT)

Inverte todos os bits do operando.

int d = ~5;     // ~00000101 = 11111010 → d depende do sistema (representação com sinal)

⚠ O resultado depende do tamanho do tipo (int, char, etc.) e se é com ou sem sinal.

Operador << (deslocamento à esquerda)

Desloca os bits para a esquerda, inserindo zeros à direita. Equivale a multiplicar por 2ⁿ.

int e = 3 << 1;  // 0011 << 1 = 0110 → e = 6

Operador >> (deslocamento à direita)

Desloca os bits para a direita. O preenchimento depende se o tipo é com ou sem sinal.

int f = 8 >> 2;  // 1000 >> 2 = 0010 → f = 2

Esses operadores são frequentemente usados em máscaras de bits, compressão de dados, criptografia e controle de periféricos.

Operador Condicional Ternário (?:)

O operador ternário é o único operador de três operandos em C e C++. Ele permite expressar uma condição de forma concisa, funcionando como uma estrutura if-else compacta.

Sintaxe

condição ? valor_se_verdadeiro : valor_se_falso;

Exemplo básico

int a = 10, b = 5;
int maior = (a > b) ? a : b;  // maior = 10

Neste exemplo:

  • Se a condição (a > b) for verdadeira, maior recebe o valor de a.
  • Caso contrário, maior recebe b.

Aplicação prática

Muito usado em expressões curtas, inicializações condicionais e retorno de valores em funções pequenas:

printf("O número é %s\n", (n % 2 == 0) ? "par" : "ímpar");

Esse operador melhora a legibilidade em casos simples, mas deve ser evitado quando as expressões envolvidas forem muito longas ou complexas, pois pode dificultar a manutenção do código.

Operadores de Ponteiros

C e C++ permitem acesso direto à memória por meio de ponteiros. Esses operadores facilitam tanto a obtenção de endereços quanto o acesso ao conteúdo da memória.

Operador & (endereço de)

Retorna o endereço da variável.

int x = 10;
int* p = &x;  // p recebe o endereço de x

Esse operador é usado para obter o ponteiro de uma variável.

Operador * (desreferenciação)

Acessa o valor armazenado no endereço de memória apontado por um ponteiro.

int y = *p;  // y recebe o valor armazenado no endereço apontado por p

⚠ Esse operador também é usado para declarar ponteiros:

int* p;  // declara um ponteiro para inteiro

Exemplo completo:

int a = 42;
int* ptr = &a;
printf("%d\n", *ptr);  // Imprime 42

Esses operadores são fundamentais para:

  • Passagem de parâmetros por referência
  • Manipulação de arrays e strings
  • Alocação dinâmica com malloc/free
  • Acesso a hardware em sistemas embarcados

Operadores de Acesso a Membros

Esses operadores permitem acessar membros (campos ou métodos) de estruturas (struct), uniões (union) ou classes (class em C++), tanto diretamente quanto via ponteiros.

Operador . (acesso direto a membro)

Usado quando se acessa o membro de uma estrutura diretamente por uma variável.

struct Ponto {
    int x, y;
};

struct Ponto p1 = {2, 3};
int valor = p1.x;  // valor = 2

Operador -> (acesso indireto a membro)

Usado para acessar membros de uma estrutura por meio de um ponteiro.

struct Ponto* ptr = &p1;
int valor = ptr->y;  // valor = 3

Esse operador é equivalente a (*ptr).y, mas é mais legível e conciso.

Operador sizeof

Operador sizeof (tamanho em bytes)

Retorna o número de bytes ocupado por uma variável ou tipo de dado.

int a;
size_t t = sizeof(a);        // tamanho de uma variável
size_t t2 = sizeof(double);  // tamanho de um tipo

Esse operador é resolvido em tempo de compilação e é amplamente usado em alocação dinâmica de memória, manipulação de buffers e escrita de funções portáveis.

Em C++, também pode ser usado com classes, objetos e templates.

Operadores de Conversão de Tipo (Type Cast)

Conversões de tipo são usadas para alterar explicitamente o tipo de uma variável ou expressão, seja para compatibilidade, otimização ou controle de precisão.

Conversão C-style (cast tradicional em C e C++)

Sintaxe tradicional entre parênteses:

float a = 5.75;
int b = (int)a;  // b = 5 (parte decimal é descartada)

Essa forma é permitida tanto em C quanto em C++ e pode ser usada com qualquer tipo primitivo.

Conversão em C++ (cast seguro e semântico)

O C++ introduz operadores de conversão mais seguros e explícitos:

static_cast

Para conversões seguras entre tipos compatíveis em tempo de compilação (como de int para float, ou entre classes relacionadas por herança).

int i = 10;
float f = static_cast<float>(i);
reinterpret_cast

Interpreta os bits de um tipo como se fossem de outro. Muito perigoso — usado para acesso direto de memória.

int* p = new int(42);
char* c = reinterpret_cast<char*>(p);
const_cast

Remove ou adiciona o qualificador const de um ponteiro ou referência.

const int* p = &i;
int* q = const_cast<int*>(p);
dynamic_cast

Usado para conversão segura em hierarquias de classes polimórficas. Verifica em tempo de execução.

Base* b = new Derived();
Derived* d = dynamic_cast<Derived*>(b);

⚠ Só funciona com classes que possuem métodos virtuais.

Esses operadores são importantes para garantir a legibilidade, segurança de tipos e controle de comportamento em sistemas complexos, especialmente em C++.

Operador de Vírgula (,)

O operador de vírgula permite avaliar múltiplas expressões em uma única linha, onde todas são avaliadas, mas apenas o valor da última é retornado como resultado da expressão.

Exemplo básico

int a, b;
a = (b = 3, b + 2);  // b = 3, a = 5

Neste exemplo:

  1. A primeira expressão b = 3 é avaliada e b recebe 3.
  2. A segunda expressão b + 2 é avaliada, resultando em 5.
  3. O valor de a será o resultado da última expressão: 5.

Aplicação prática

É comum usar esse operador em contextos como:

for (int i = 0, j = 10; i < j; i++, j--) {
    // código
}

Aqui, i++ e j-- são duas expressões separadas por vírgula, executadas a cada iteração do for.

⚠ Apesar de útil, o operador de vírgula pode reduzir a legibilidade se usado em excesso. Use com moderação e clareza.

Operadores Específicos de C++

C++ introduz diversos operadores adicionais que não existem em C, voltados especialmente para manipulação de objetos, alocação de memória e acesso a membros via ponteiros a funções ou dados.

Operadores new e delete

Responsáveis por alocação e desalocação dinâmica de memória para objetos.

int* p = new int;     // aloca um inteiro dinamicamente
*p = 10;

delete p;             // libera a memória alocada

Para arrays dinâmicos:

int* arr = new int[5];   // aloca um array de 5 inteiros
delete[] arr;            // libera o array

⚠ Sempre que usar new, use delete para evitar vazamentos de memória.

Operador :: (resolução de escopo)

Permite acessar membros definidos fora do escopo local, como namespaces, classes ou variáveis globais.

int valor = ::x;         // acessa variável global 'x'
std::cout << "Texto";    // acessa cout dentro do namespace std

Também é usado para definir métodos de uma classe fora do corpo da classe:

void MinhaClasse::metodo() {
    // definição do método
}

Operadores .* e ->* (ponteiro para membro)

Esses operadores permitem acessar membros de classe (variáveis ou funções) por meio de ponteiros para membros, algo mais avançado e pouco comum em aplicações simples.

class Teste {
public:
    int valor;
    void metodo() { std::cout << "Método chamado\n"; }
};

int Teste::* ptrValor = &Teste::valor;
void (Teste::*ptrMetodo)() = &Teste::metodo;

Teste obj;
obj.*ptrValor = 42;
(obj.*ptrMetodo)();  // chama o método via ponteiro

Para ponteiros a objetos:

Teste* p = new Teste();
p->*ptrValor = 99;
(p->*ptrMetodo)();

Esses operadores são particularmente úteis em implementações complexas como callbacks, sistemas baseados em reflexão manual, bibliotecas de template genérico, ou frameworks como Qt.

Conclusão

Exploramos todos os principais operadores da linguagem C e C++, explicando seu propósito, uso e dando exemplos práticos. Dominar esses operadores é essencial para escrever código eficiente, seguro e legível, seja em aplicações de baixo nível (C) ou orientadas a objetos (C++).

The post Operadores em C e C++: Guia Completo com Exemplos e Explicações Didáticas first appeared on MCU & FPGA.

]]> 583 Introdução aos Ponteiros em C e sua Relevância em Arquiteturas de Microcontroladores https://mcu.tec.br/linguagem/c/introducao-aos-ponteiros-em-c-e-sua-relevancia-em-arquiteturas-de-microcontroladores/?utm_source=rss&utm_medium=rss&utm_campaign=introducao-aos-ponteiros-em-c-e-sua-relevancia-em-arquiteturas-de-microcontroladores Mon, 14 Apr 2025 17:06:25 +0000 https://mcu.tec.br/?p=354 Aprenda de forma didática como funcionam os ponteiros em C no contexto de sistemas embarcados. Entenda aritmética de ponteiros, passagem por referência e as diferenças entre arquiteturas como AVR, ARM Cortex-M e ESP32.

The post Introdução aos Ponteiros em C e sua Relevância em Arquiteturas de Microcontroladores first appeared on MCU & FPGA.

]]>

A linguagem C é uma das mais utilizadas no desenvolvimento de sistemas embarcados por permitir acesso direto à memória e controle total sobre os recursos do hardware. Um dos recursos centrais de C, que torna isso possível, é o uso de ponteiros. Embora muitas vezes considerados desafiadores por iniciantes, os ponteiros são fundamentais para a manipulação eficiente de dados e periféricos em microcontroladores.

Neste artigo, exploraremos os conceitos fundamentais de ponteiros, abordando como funcionam, como são utilizados na prática e como se comportam em diferentes arquiteturas de microcontroladores: chips de 8 bits (como os da família AVR, como o ATmega328p), de 32 bits baseados em ARM Cortex-M (como o STM32), e os ESP da Espressif (baseados na arquitetura Xtensa). Faremos também uma análise aprofundada sobre passagem por referência e por cópia em structs, e como a aritmética de ponteiros interage com arrays e strings.

Nosso objetivo é fornecer um guia acessível, porém técnico e preciso, que auxilie estudantes, desenvolvedores e entusiastas de sistemas embarcados a dominar essa poderosa ferramenta da linguagem C, explorando tanto os fundamentos quanto as nuances específicas de cada plataforma.

Conceitos Fundamentais de Ponteiros em C

Um ponteiro é uma variável cujo valor é o endereço de outra variável. Em outras palavras, ponteiros “apontam” para locais da memória. Isso permite que o programador manipule diretamente valores armazenados em diferentes posições de memória, tornando possível, por exemplo, o controle de dispositivos periféricos, buffers e estruturas dinâmicas.

Declaração e uso básico

Em C, um ponteiro é declarado com o uso do operador *, que indica que aquela variável armazenará um endereço de memória:

int x = 10;
int *p;      // ponteiro para inteiro
p = &x;      // p recebe o endereço de x

Neste exemplo:

  • x é uma variável comum.
  • p é um ponteiro que armazena o endereço de x.
  • O operador & é usado para obter o endereço de x.
  • Podemos acessar o valor de x por meio de p usando *p, que é a desreferenciação do ponteiro.
printf("%d\n", *p);  // imprime 10

Representação na memória

Vamos imaginar que x está armazenado no endereço 0x2000:

EndereçoValor
0x200010
p (0x3000)0x2000
  • O ponteiro p em si também ocupa um espaço na memória e armazena o valor 0x2000, que é o endereço de x.

Essa estrutura de ponteiros é extremamente útil em situações onde há necessidade de manipular diretamente regiões de memória, como no acesso a registradores de hardware em microcontroladores.

Aritmética de ponteiros

Além da desreferenciação (*) e do uso do endereço (&), podemos realizar aritmética com ponteiros. Por exemplo, ao incrementar um ponteiro, estamos o movendo para o próximo endereço com base no tipo de dado:

int vetor[3] = {1, 2, 3};
int *ptr = vetor;

printf("%d\n", *(ptr));     // imprime 1
printf("%d\n", *(ptr + 1)); // imprime 2

Aqui, ptr + 1 não significa “somar 1 ao valor de ptr”, mas sim avançar o ponteiro pelo tamanho de um int (geralmente 4 bytes em sistemas de 32 bits). A unidade de incremento é o tamanho do tipo apontado.

Aritmética com ponteiros em dados maiores que a largura da arquitetura

Arquiteturas como AVR (8 bits), ARM Cortex-M (32 bits) ou ESP (Xtensa, geralmente 32 bits) operam com palavras de 8 ou 32 bits, mas podem manipular tipos de dados maiores, como double ou uint64_t, que têm 64 bits (8 bytes). Ao realizar aritmética com ponteiros desses tipos, o compilador cuida do incremento adequado com base no tamanho do tipo:

uint64_t valores[3] = {100, 200, 300};
uint64_t *ptr = valores;

printf("%llu\n", *(ptr));       // imprime 100
printf("%llu\n", *(ptr + 1));   // imprime 200

Mesmo em uma arquitetura de 8 ou 32 bits, ptr + 1 avança 8 bytes na memória, pois sizeof(uint64_t) ou sizeof(double) é 8. Isso é fundamental para o acesso correto a cada elemento do array.

Ou seja, mesmo que a arquitetura tenha barramentos de 8 ou 32 bits, o compilador organiza a leitura de valores maiores em múltiplas operações de leitura/escrita menores. O ponteiro, no entanto, se comporta de maneira consistente: ele pula o número de bytes correspondentes ao tipo de dado apontado.

Ponteiros e Arquiteturas de Microcontroladores: ATmega, Cortex-M e ESP

Cada arquitetura de microcontrolador possui características distintas de endereçamento, largura de dados e barramentos, que influenciam diretamente o uso de ponteiros. Nesta seção, vamos explorar como os ponteiros operam em três arquiteturas muito utilizadas: ATmega (AVR de 8 bits), ARM Cortex-M (32 bits) e ESP (Xtensa LX6/7, 32 bits).

Ponteiros em Arquiteturas de 8 bits (AVR / ATmega)

Microcontroladores AVR, como o ATmega328p, possuem registradores de 8 bits e endereçamento linear de 16 bits (o que permite acesso direto a até 64 kB de memória). Nesse contexto:

  • Um ponteiro simples (uint8_t*) ocupa 16 bits.
  • Tipos maiores que 8 bits, como uint16_t ou uint32_t, são acessados em múltiplos ciclos e com instruções específicas.
  • A manipulação de ponteiros para structs ou arrays deve considerar o alinhamento e a sobreposição de acessos.
uint16_t dado = 0x1234;
uint8_t *ptr = (uint8_t*)&dado;
printf("%x %x", ptr[0], ptr[1]); // Acesso byte a byte (little endian)

A aritmética de ponteiros funciona normalmente, mas os acessos são limitados pela largura do barramento de dados (8 bits) e devem ser tratados com cuidado ao acessar dados de múltiplos bytes.

Ponteiros em ARM Cortex-M (32 bits)

Cortex-M é uma arquitetura de 32 bits, o que significa que:

  • Um ponteiro ocupa 32 bits.
  • O acesso à memória é mais eficiente com tipos alinhados a 4 bytes.
  • A maioria dos registradores, barramentos e operações aritméticas são otimizadas para 32 bits.

Por padrão, ponteiros são usados extensivamente em firmware embarcado para:

  • Acessar periféricos via memory-mapped IO (endereços fixos).
  • Manipular buffers, filas e estruturas de controle em RTOS como o FreeRTOS.
#define GPIOA_BASE 0x40020000
#define GPIOA_MODER (*(volatile uint32_t *)(GPIOA_BASE + 0x00))

GPIOA_MODER |= (1 << 10); // Configura o pino PA5 como saída

Este exemplo demonstra o uso de ponteiros para acessar registradores. A aritmética sobre o endereço base é feita somando deslocamentos, e o resultado é desreferenciado para escrita/leitura.

Ponteiros em ESP (Xtensa LX6 / LX7)

A arquitetura Xtensa usada nos ESP32 também é de 32 bits, com ponteiros de 4 bytes. No entanto, há peculiaridades:

  • Alguns ponteiros precisam estar alinhados a 4 bytes para operações eficientes.
  • Ponteiros para regiões específicas (IRAM, DRAM, RTC) têm restrições e endereçamentos separados.
  • Existem modos de acesso mais rápidos para variáveis colocadas em IRAM_ATTR.

Além disso, o uso de ponteiros em drivers e manipulação direta de periféricos requer atenção, já que a divisão entre RAM e Flash é controlada via linker script e atributos específicos.

volatile uint32_t *gpio_out = (uint32_t *)0x3FF44004;
*gpio_out |= (1 << 2); // Seta pino GPIO2

Apesar de a operação ser similar à do Cortex-M, o mapa de memória do ESP é mais segmentado, e o uso de ponteiros para regiões incorretas pode levar a exceptions (como “LoadProhibited” ou “StoreProhibited”).

Transferência por Referência vs. Cópia de Objetos (Structs)

No contexto da linguagem C, e especialmente em sistemas embarcados, compreender a diferença entre passar um objeto por cópia ou por referência é crucial para otimizar o uso de memória, evitar sobrecarga de processamento e garantir integridade dos dados em tempo real.

Cópia de estruturas

Quando uma struct é passada como argumento de uma função sem o uso de ponteiros, o compilador cria uma cópia completa da estrutura em uma nova área da pilha. Isso significa:

  • Maior uso da stack (memória de execução).
  • Perda de modificações feitas à estrutura dentro da função.
  • Segurança de que o objeto original não será alterado.
typedef struct {
    int x, y;
} Ponto;

void mover(Ponto p) {
    p.x += 10;
    p.y += 5;
}

int main() {
    Ponto a = {1, 2};
    mover(a);
    // a continua como {1, 2}
}

Esse comportamento é seguro, mas pode se tornar problemático se a struct for grande (por exemplo, buffers de 512 bytes), pois sua cópia consome tempo e recursos.

Transferência por referência (ponteiros)

Ao passar uma estrutura por ponteiro, a função recebe o endereço da variável original, operando diretamente sobre ela:

void mover_ref(Ponto *p) {
    p->x += 10;
    p->y += 5;
}

int main() {
    Ponto a = {1, 2};
    mover_ref(&a);
    // agora a = {11, 7}
}

Vantagens do uso por referência:

  • Menor consumo de stack.
  • Evita cópia de dados pesados (como arrays internos).
  • Permite alterações diretas na variável original.

Desvantagens:

  • Exige atenção à integridade dos dados (evitar NULL ou ponteiros inválidos).
  • Pode causar efeitos colaterais indesejados se mal utilizado.

Considerações específicas em sistemas embarcados

Em microcontroladores, onde o uso da stack é limitado (especialmente em arquiteturas de 8 e 16 bits), a cópia de estruturas deve ser evitada sempre que possível:

  • Em AVR, a pilha é pequena (algumas centenas de bytes), e a cópia de uma estrutura de 32 bytes pode ser crítica.
  • Em ARM Cortex-M, a stack é maior, mas o uso excessivo dela pode afetar tarefas em tempo real (ex: preempção em RTOS).
  • No ESP32, apesar da arquitetura robusta, a stack de cada tarefa (em FreeRTOS) ainda tem limite — e structs grandes devem ser passadas por referência.

Por isso, o uso de ponteiros para passar estruturas é uma prática padrão, especialmente em drivers, comunicação via SPI/UART, controle de sensores, buffers de DMA, etc.

Aritmética de Ponteiros com Structs, Arrays e Strings

A aritmética de ponteiros em C é uma ferramenta poderosa e, quando aplicada a estruturas compostas como structs, arrays e strings, permite manipular dados com precisão e eficiência — algo especialmente valioso em sistemas embarcados. No entanto, seu uso exige atenção aos limites da memória, alinhamento e ao tipo apontado.

Ponteiros e Structs

Uma struct em C é composta por membros agrupados sequencialmente na memória. Um ponteiro para struct pode ser incrementado, mas é raro fazer isso diretamente. Em vez disso, usa-se aritmética com ponteiros para acessar vetores de structs:

typedef struct {
    uint8_t id;
    float temperatura;
} Sensor;

Sensor sensores[3] = {
    {1, 25.0},
    {2, 28.5},
    {3, 23.7}
};

Sensor *ptr = sensores;

printf("Sensor 2: %.1f°C\n", (ptr + 1)->temperatura);

Aqui, ptr + 1 avança na memória o equivalente ao tamanho de um Sensor, que no exemplo pode ser 5 ou 8 bytes, dependendo do alinhamento. A operação é feita automaticamente com sizeof(Sensor).

Em microcontroladores com alinhamento rígido (como Cortex-M), é importante garantir que os elementos do array estejam corretamente alinhados na memória para evitar penalidades de acesso.

Ponteiros e Arrays

Arrays em C são compatíveis com ponteiros. Um array int v[5] é interpretado como um ponteiro para int, e podemos acessar seus elementos com aritmética de ponteiros:

int v[5] = {10, 20, 30, 40, 50};
int *p = v;

printf("%d\n", *(p + 2));  // imprime 30

Essas expressões são equivalentes:

  • v[2]
  • *(v + 2)
  • *(p + 2)

Esse comportamento permite percorrer arrays com for usando ponteiros, reduzindo o overhead de indexação e facilitando a portabilidade de funções genéricas que operam sobre blocos de memória.

Ponteiros e Strings (char *)

Strings em C são arrays de caracteres terminados por nulo ('\0'). Quando usamos char*, estamos manipulando uma string como um ponteiro para seu primeiro caractere:

char *msg = "Hello";

while (*msg) {
    putchar(*msg);  // imprime caractere por caractere
    msg++;          // avança ponteiro
}

A aritmética de ponteiros aqui permite percorrer a string byte a byte. É muito comum manipular buffers de recepção UART ou SPI dessa forma em sistemas embarcados, especialmente ao usar funções como strlen, memcpy ou strcmp, que internamente usam ponteiros para acesso sequencial.

Cuidados ao usar aritmética de ponteiros

  • Overflow: ultrapassar os limites de um array pode causar falhas ou sobrescrever variáveis críticas.
  • Alinhamento: acessar dados desalinhados (por exemplo, um uint32_t com ponteiro não alinhado) pode ser problemático, especialmente em ARM ou Xtensa.
  • Volatilidade: em hardware, muitos registradores são volatile, e seu acesso por ponteiros exige cuidado extra para evitar otimizações indesejadas do compilador.

Conclusão e Aplicações Práticas em Sistemas Embarcados

O domínio dos ponteiros é uma habilidade essencial para qualquer programador de sistemas embarcados. Eles permitem um controle refinado sobre o hardware, facilitam o uso eficiente da memória e são fundamentais na construção de drivers, protocolos de comunicação e sistemas operacionais em tempo real.

Ao longo deste artigo, vimos que:

  • Ponteiros são variáveis que armazenam endereços de memória, e sua desreferenciação permite acessar diretamente os dados apontados.
  • A aritmética de ponteiros leva em consideração o tamanho do tipo apontado, seja ele uint8_t, int, double, uint64_t, ou mesmo structs.
  • Arquiteturas diferentes (AVR, ARM Cortex-M, ESP Xtensa) tratam ponteiros de maneiras distintas, especialmente em relação ao alinhamento, largura de dados e restrições de acesso à memória.
  • A passagem de structs por referência é preferível em sistemas embarcados, pois evita a cópia de grandes blocos de memória na stack e melhora o desempenho.
  • A manipulação eficiente de arrays e strings com ponteiros é uma técnica poderosa e comum em rotinas críticas de comunicação, parsing e controle de buffers.

Exemplos práticos no cotidiano embarcado

  • Drivers de periféricos (como ADC, GPIO, UART) usam ponteiros para mapear diretamente os registradores em memória (memory-mapped IO).
  • Protocolos de comunicação (como Modbus, CAN, SPI) frequentemente operam com buffers manipulados via ponteiros, permitindo copiar, comparar ou modificar dados com baixo overhead.
  • Sistemas com RTOS utilizam ponteiros para gerenciamento de tarefas, filas, semáforos e memória dinâmica.
  • DMA (Direct Memory Access) depende do uso preciso de ponteiros para endereçar buffers de origem e destino.

Em resumo, entender como ponteiros funcionam em diferentes contextos — da simples manipulação de arrays até o mapeamento direto de registradores — é o que transforma um programador C comum em um desenvolvedor embarcado eficaz.

The post Introdução aos Ponteiros em C e sua Relevância em Arquiteturas de Microcontroladores first appeared on MCU & FPGA.

]]> 354 Garbage Compactor Pattern https://mcu.tec.br/linguagem/c/garbage-compactor-pattern/?utm_source=rss&utm_medium=rss&utm_campaign=garbage-compactor-pattern Sat, 22 Feb 2025 22:47:51 +0000 https://mcu.tec.br/?p=106 O Garbage Compactor Pattern é um padrão de gerenciamento de memória que reorganiza dinamicamente a alocação de memória para reduzir a fragmentação e garantir blocos contíguos disponíveis para uso. Em sistemas embarcados, onde a memória é um recurso extremamente limitado, esse padrão se torna essencial para maximizar o aproveitamento da RAM e evitar falhas inesperadas devido à fragmentação excessiva.

The post Garbage Compactor Pattern first appeared on MCU & FPGA.

]]> 📖 Origem: Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems – Bruce Powel Douglass

Resumo (Abstract)

O Garbage Compactor Pattern é um padrão de gerenciamento de memória que reorganiza dinamicamente a alocação de memória para reduzir a fragmentação e garantir blocos contíguos disponíveis para uso. Em sistemas embarcados, onde a memória é um recurso extremamente limitado, esse padrão se torna essencial para maximizar o aproveitamento da RAM e evitar falhas inesperadas devido à fragmentação excessiva.

Problema a ser resolvido

Sistemas que fazem uso de alocação dinâmica de memória frequentemente sofrem com a fragmentação, onde blocos livres são dispersos na RAM, impossibilitando a alocação de grandes blocos de memória mesmo quando há espaço suficiente disponível. Esse problema é particularmente crítico em sistemas embarcados, onde a memória é limitada e cada falha na alocação pode levar a travamentos, reinicializações ou falhas de desempenho.

Além disso, a fragmentação pode tornar os tempos de resposta imprevisíveis, pois a busca por blocos de memória disponíveis se torna mais complexa. Sistemas de tempo real precisam de garantias de tempo de resposta determinístico, algo que pode ser comprometido caso a fragmentação cause variações no tempo de alocação. O Garbage Compactor Pattern resolve esse problema ao reorganizar periodicamente a memória, consolidando blocos livres em regiões contínuas e garantindo que grandes alocações possam ser feitas sem falhas.

Estrutura do Padrão

A estrutura desse padrão envolve um gerenciador de heap, que monitora a fragmentação da memória e decide quando realizar a compactação. A lista de blocos ocupados rastreia quais segmentos da RAM estão em uso, enquanto a lista de blocos livres gerencia os espaços disponíveis. Um mecanismo de realocação move os dados dos blocos alocados para consolidar as áreas livres, garantindo que a memória seja reorganizada sem impactar o funcionamento do sistema.

A compactação pode ser realizada em momentos estratégicos, como durante períodos de baixa atividade do sistema ou quando a fragmentação atinge um limite crítico. Esse processo pode ser implementado de forma assíncrona para minimizar impactos no desempenho.

Papéis de Colaboração (Collaborations Roles)

  • Gerenciador de Heap: Supervisiona a alocação, desalocação e reorganização dos blocos de memória.
  • Lista de Blocos Ocupados: Mantém um mapeamento dos blocos de memória em uso.
  • Lista de Blocos Livres: Armazena informações sobre os segmentos disponíveis para alocação.
  • Mecanismo de Realocação: Move os dados entre os blocos de memória para consolidar áreas livres.
  • Cliente: Solicita alocações e liberações de memória conforme necessário.
  • Segmento de Memória: Contém a memória real onde os blocos são armazenados e reorganizados.

Consequências

A aplicação do Garbage Compactor Pattern traz benefícios significativos para sistemas embarcados. Ele melhora a eficiência do uso da memória, garantindo que grandes blocos possam ser alocados sem falhas. Além disso, reduz os tempos de busca por espaço livre, melhorando a previsibilidade dos tempos de resposta, algo essencial em sistemas de tempo real.

Por outro lado, o processo de compactação pode ser custoso em termos de processamento, pois requer movimentação de dados na RAM. Se não for gerenciado corretamente, pode causar pausas no sistema que impactam a responsividade da aplicação. Outra consideração importante é que a movimentação dos blocos pode exigir a atualização de ponteiros e referências, o que pode ser complexo em algumas arquiteturas.

Estratégias de Implementação

A implementação do Garbage Compactor Pattern pode seguir diferentes abordagens, dependendo dos requisitos do sistema. Uma estratégia comum é a compactação periódica, onde a reorganização da memória ocorre em intervalos regulares ou quando a fragmentação atinge um limite predefinido. Esse método é útil em sistemas onde há momentos de baixa carga que podem ser aproveitados para a reorganização da memória.

Outra abordagem é a compactação sob demanda, onde a reorganização ocorre apenas quando uma tentativa de alocação falha devido à fragmentação. Essa estratégia minimiza o impacto no desempenho, pois a compactação é realizada apenas quando necessário. No entanto, pode causar atrasos inesperados no tempo de resposta quando a compactação precisa ser feita em um momento crítico.

Para garantir a integridade dos dados durante a realocação, é essencial utilizar mecanismos de proteção de ponteiros, garantindo que referências a blocos de memória sejam atualizadas corretamente. Outra técnica útil é a utilização de buffers temporários, permitindo que dados sejam copiados para uma área intermediária antes de serem reposicionados.

Padrões Relacionados

O Garbage Compactor Pattern está diretamente relacionado a outros padrões de gerenciamento de memória:

  • Pool Allocation Pattern: Ambos lidam com otimização do uso de memória, mas o Pool Allocation evita a fragmentação desde o início, enquanto o Garbage Compactor atua quando a fragmentação já ocorreu.
  • Fixed-Sized Buffer Pattern: Pode ser combinado com a compactação de memória para garantir um uso mais eficiente da RAM.
  • Priority Ceiling Pattern: Pode ser usado para garantir que o processo de compactação ocorra sem interrupções indesejadas em sistemas críticos.
  • Critical Section Pattern: Pode ser necessário para evitar acessos concorrentes durante a compactação.

Modelo de Amostragem (Exemplo de Código)

Segue um exemplo de implementação simplificada do Garbage Compactor Pattern em C:

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <stdbool.h>
#include <string.h>

#define HEAP_SIZE 1024  // Tamanho total do heap
#define BLOCK_SIZE 32    // Tamanho de cada bloco de memória
#define NUM_BLOCKS (HEAP_SIZE / BLOCK_SIZE)

typedef struct MemoryBlock {
    bool in_use;
    void *ptr;
    size_t size;
} MemoryBlock;

typedef struct Segment {
    MemoryBlock blocks[NUM_BLOCKS];
    uint8_t memory[HEAP_SIZE];
    struct Segment *next;
} Segment;

typedef struct BufferedPtr {
    void **ptr;
} BufferedPtr;

typedef struct GarbageCompactor {
    Segment *activeSegment;
    Segment *inactiveSegment;
} GarbageCompactor;

Segment segment1, segment2;
GarbageCompactor gc;

void init_segments() {
    memset(&segment1, 0, sizeof(Segment));
    memset(&segment2, 0, sizeof(Segment));
    gc.activeSegment = &segment1;
    gc.inactiveSegment = &segment2;
}

void *allocate_memory(size_t size) {
    Segment *seg = gc.activeSegment;
    for (int i = 0; i < NUM_BLOCKS; i++) {
        if (!seg->blocks[i].in

The post Garbage Compactor Pattern first appeared on MCU & FPGA.

]]> 106 Pool Allocation Pattern https://mcu.tec.br/linguagem/c/pool-allocation-pattern/?utm_source=rss&utm_medium=rss&utm_campaign=pool-allocation-pattern Sat, 22 Feb 2025 21:55:06 +0000 https://mcu.tec.br/?p=103 O Pool Allocation Pattern é um padrão que gerencia a memória de forma eficiente ao pré-alocar blocos de tamanho fixo para reutilização. Ele resolve problemas comuns da alocação dinâmica, como fragmentação e imprevisibilidade no tempo de acesso, tornando-se essencial para sistemas embarcados e de tempo real. Esse padrão melhora a eficiência do uso da RAM ao garantir que blocos de memória sejam reutilizados conforme necessário, sem necessidade de alocações dinâmicas constantes.

The post Pool Allocation Pattern first appeared on MCU & FPGA.

]]> 📖 Origem: Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems – Bruce Powel Douglass

Resumo

O Pool Allocation Pattern é um padrão que gerencia a memória de forma eficiente ao pré-alocar blocos de tamanho fixo para reutilização. Ele resolve problemas comuns da alocação dinâmica, como fragmentação e imprevisibilidade no tempo de acesso, tornando-se essencial para sistemas embarcados e de tempo real. Esse padrão melhora a eficiência do uso da RAM ao garantir que blocos de memória sejam reutilizados conforme necessário, sem necessidade de alocações dinâmicas constantes.

Problema a ser resolvido

A alocação dinâmica de memória (malloc() e free()) pode levar à fragmentação e latências imprevisíveis, o que é inaceitável para sistemas embarcados de tempo real. Além disso, quando a memória se esgota ou está altamente fragmentada, pode ocorrer falha na alocação de novos blocos, resultando em comportamento inesperado do sistema.

Outro problema comum é a sobrecarga de gerenciamento de memória, onde a alocação e desalocação frequente de pequenos blocos gera um overhead significativo. Isso reduz a eficiência do sistema e pode impactar o tempo de resposta em aplicações críticas. Em sistemas embarcados com recursos limitados, é crucial garantir que a memória seja usada de forma previsível e eficiente.

O Pool Allocation Pattern resolve esses problemas ao manter um conjunto fixo de blocos de memória pré-alocados, permitindo que o sistema reutilize esses blocos de maneira eficiente. Isso elimina a necessidade de alocação e desalocação dinâmica, garantindo tempos de resposta constantes e previsíveis.

Estrutura do Padrão

A estrutura desse padrão se baseia em um gerenciador de pool de memória, que mantém uma lista de blocos livres prontos para serem usados. Cada bloco tem um tamanho fixo e pode ser alocado rapidamente sem a necessidade de recorrer ao heap. A fábrica de objetos pode ser usada para criar e inicializar os blocos, enquanto um gerenciador de heap dimensionado garante que os blocos sejam usados de maneira eficiente.

Os dados são armazenados no segmento de memória, garantindo que a RAM seja utilizada de forma previsível. O acesso ao pool pode ser gerenciado por mecanismos como filas FIFO (First In, First Out) ou LIFO (Last In, First Out), dependendo das necessidades da aplicação.

Papéis de Colaboração

  • Cliente: Solicita e libera blocos de memória conforme necessário.
  • Lista de Blocos Livres: Mantém o controle dos blocos de memória disponíveis para reutilização.
  • Gerenciador de Pool: Supervisiona a alocação e liberação dos blocos, garantindo que a memória seja usada eficientemente.
  • Segmento de Memória: Armazena fisicamente os blocos alocados.
  • Fábrica de Objetos: Pode ser usada para criar instâncias de objetos que utilizam a alocação por pool.
  • Heap Dimensionado: Garante que os blocos tenham um tamanho fixo e que a memória seja utilizada de maneira eficiente.

Consequências

O Pool Allocation Pattern traz diversas vantagens para sistemas embarcados. Ele reduz drasticamente o tempo de alocação de memória, pois os blocos já estão pré-alocados e prontos para uso. Isso melhora o tempo de resposta do sistema e evita problemas de fragmentação. Além disso, ao reutilizar blocos já existentes, o padrão reduz a necessidade de operações de gerenciamento de heap, economizando processamento.

Entretanto, esse padrão pode levar ao desperdício de memória se o número de blocos pré-alocados for maior do que o necessário. Se a quantidade de blocos for insuficiente, pode ser necessário um mecanismo de fallback para lidar com situações onde não há memória disponível. Além disso, a implementação deve ser bem planejada para evitar vazamentos de memória devido a blocos que não são liberados corretamente.

Estratégias de Implementação

Para implementar o Pool Allocation Pattern, um array de blocos de memória é criado no momento da inicialização do sistema. Um gerenciador de pool mantém uma lista encadeada de blocos disponíveis, permitindo alocação e liberação rápidas. Em sistemas que exigem eficiência máxima, um buffer circular pode ser utilizado para gerenciar os blocos de forma ainda mais eficiente.

A implementação pode incluir verificações para evitar acessos indevidos a blocos não alocados. Além disso, em sistemas multitarefa, mutexes ou semáforos podem ser usados para garantir que múltiplas tarefas acessem o pool de maneira segura. Em casos onde há necessidade de realocação dinâmica, pode-se combinar esse padrão com o Fixed-Sized Buffer Pattern, garantindo que cada bloco tenha um tamanho fixo e previsível.

Padrões Relacionados

O Pool Allocation Pattern está diretamente relacionado a outros padrões de gerenciamento de memória e sincronização:

  • Fixed-Sized Buffer Pattern: Ambos evitam alocação dinâmica e melhoram a previsibilidade do uso da memória.
  • Message Queuing Pattern: Pode ser usado em conjunto para gerenciar filas de mensagens sem consumir memória excessiva.
  • Garbage Compactor Pattern: Pode ser útil quando há necessidade de reorganizar a memória para evitar fragmentação.
  • Critical Section Pattern: Pode ser necessário para evitar acesso concorrente a blocos do pool.

Modelo de Amostragem (Exemplo de Código)

Aqui está um exemplo de implementação do Pool Allocation Pattern em C:

#include <stdio.h>
#include <stdint.h>

#define POOL_SIZE 1000 // Número máximo de objetos TempData

// Estrutura de dados de temperatura
typedef struct {
    int id;
    float temperature;
} TempData;

// Estrutura para o Pool de Recursos
typedef struct {
    TempData pool[POOL_SIZE];  // Array de objetos
    uint8_t allocated[POOL_SIZE];  // Flags para indicar quais objetos estão em uso
} TempDataPool;

// Inicializa o pool de dados
void initPool(TempDataPool* pool) {
    for (int i = 0; i < POOL_SIZE; i++) {
        pool->allocated[i] = 0;  // Nenhum objeto está alocado inicialmente
    }
}

// Aloca um objeto TempData do pool
TempData* allocateTempData(TempDataPool* pool) {
    for (int i = 0; i < POOL_SIZE; i++) {
        if (!pool->allocated[i]) {  // Se não estiver em uso
            pool->allocated[i] = 1; // Marca como alocado
            return &pool->pool[i];
        }
    }
    return NULL; // Pool esgotado
}

// Libera um objeto TempData e o devolve ao pool
void releaseTempData(TempDataPool* pool, TempData* data) {
    int index = data - pool->pool;  // Calcula o índice do objeto
    if (index >= 0 && index < POOL_SIZE) {
        pool->allocated[index] = 0; // Marca como livre
    }
}

// Simulação de sensores e histórico
void simulateUsage() {
    TempDataPool tempPool;
    initPool(&tempPool);

    TempData* temp1 = allocateTempData(&tempPool);
    if (temp1) {
        temp1->id = 1;
        temp1->temperature = 23.5;
        printf("TempData %d alocado: %.2f°C\n", temp1->id, temp1->temperature);
    }

    TempData* temp2 = allocateTempData(&tempPool);
    if (temp2) {
        temp2->id = 2;
        temp2->temperature = 24.0;
        printf("TempData %d alocado: %.2f°C\n", temp2->id, temp2->temperature);
    }

    releaseTempData(&tempPool, temp1);
    printf("TempData %d liberado\n", temp1->id);

    TempData* temp3 = allocateTempData(&tempPool);
    if (temp3) {
        temp3->id = 3;
        temp3->temperature = 22.8;
        printf("TempData %d alocado: %.2f°C\n", temp3->id, temp3->temperature);
    }
}

int main() {
    simulateUsage();
    return 0;
}

Abaixo segue o diagrama Estrutural:

Diagrama Estrutural

A seguir o diagrama de sequência:

The post Pool Allocation Pattern first appeared on MCU & FPGA.

]]> 103