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
}

{
  "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
}

{
  "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
}

{
  "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.

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

#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)

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();

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);

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>

#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;

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;
}

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

#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);
    }
}

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");

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);
}

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;
}

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);
}

// 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*

ls /dev/ttyACM*

ou observe mensagens do dmesg:

dmesg | tail

dmesg | tail

Normalmente será:

• /dev/ttyACM0
• /dev/ttyACM1

No macOS

Em geral:

ls /dev/tty.usbmodem*

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

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");

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

Você deverá ver no terminal:

Sistema iniciado!

Sistema iniciado!

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

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

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

Você verá:

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

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);
}

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
...

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);

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

#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);

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.

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.

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.

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:

• 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.

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.

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;
}