• Portabilidade no FreeRTOS e por que o “heap” é parte do contrato do kernel
  • Onde isso aparece na prática no seu projeto
  • Uma visão rápida do que cada heap “promete”
  • Fórmulas práticas para estimar configTOTAL_HEAP_SIZE
  • Exemplo mínimo (didático) de “contabilidade” do heap
• heap_1, heap_2 e heap_3: algoritmos simples, trade-offs claros
  • 2.1 heap_1 — alocação linear, determinística e sem retorno
    • Estrutura interna
    • Algoritmo de alocação (pvPortMalloc)
    • O que não existe no heap_1
    • Propriedades de tempo real
    • Quando usar
    • Quando evitar
  • 2.2 heap_2 — lista de blocos livres, mas sem coalescência
    • Estrutura interna
    • Alocação (pvPortMalloc)
    • Liberação (vPortFree)
    • Propriedades de tempo real
    • Quando usar
    • Quando evitar (muito importante)
  • 2.3 heap_3 — wrapper direto para malloc() e free()
    • Estrutura interna
    • Implicações importantes
    • Quando usar
    • Quando evitar
  • Comparativo direto (heap_1 a heap_3)
• heap_4: lista livre com coalescência e envelhecimento controlado
  • 3.1 Estrutura interna do heap_4
  • 3.2 Alocação (pvPortMalloc) no heap_4
    • Complexidade temporal
  • 3.3 Liberação (vPortFree) com coalescência
  • 3.4 Por que a coalescência muda tudo?
  • 3.5 Overhead e alinhamento no heap_4
  • 3.6 Monitoramento do heap_4
  • 3.7 Quando escolher heap_4
• heap_5: múltiplas regiões de memória sob um único alocador
  • 4.1 Motivação real para o heap_5
  • 4.2 Estrutura interna do heap_5
  • 4.3 Inicialização do heap_5 (vPortDefineHeapRegions)
  • 4.4 Alocação e liberação no heap_5
  • 4.5 Propriedades temporais e fragmentação
  • 4.6 Estratégias práticas de uso do heap_5
    • Estratégia 1 — Heap “rápido” + heap “grande”
  • 4.7 Quando escolher heap_5
  • Comparativo final (heap_1 a heap_5)
• Fechamento: portabilidade, heap e boas práticas de engenharia em FreeRTOS
  • 5.1 Portabilidade do FreeRTOS: por que o heap é parte do port
  • 5.2 Heap e padrões de projeto em sistemas embarcados
    • Object Pool (pool de objetos)
    • Static Allocation (alocação estática)
    • Message Buffers e Stream Buffers
  • 5.3 Erros comuns no uso do heap do FreeRTOS
  • 5.4 Checklist prático para escolher o heap
  • 5.5 Como fechar o dimensionamento do heap (método engenheirado)
  • 5.6 Conclusão técnica

Portabilidade no FreeRTOS e por que o “heap” é parte do contrato do kernel

Quando a gente fala que o FreeRTOS é “portável”, isso não é marketing: é uma decisão de arquitetura. O kernel (scheduler, listas de tarefas, filas, timers, notificações etc.) é quase todo “C puro” e tenta depender do mínimo possível do hardware. O que muda de microcontrolador para microcontrolador (ou de compilador para compilador) fica isolado numa camada de portabilidade (os ports). Essa camada é a responsável por dizer ao kernel como: trocar contexto, configurar o tick, entrar/sair de regiões críticas, lidar com alinhamento de memória, e — importante aqui — como o heap do kernel será gerenciado.

A parte “heap” do FreeRTOS é, na prática, um conjunto de backends alternativos para as funções pvPortMalloc() e vPortFree(). Ou seja: o kernel e as bibliotecas do FreeRTOS (e até o seu app, se você quiser) pedem memória sempre via pvPortMalloc() e devolvem via vPortFree(). Quem decide o algoritmo real por trás disso é o arquivo que você escolhe em portable/MemMang/: heap_1.c, heap_2.c, heap_3.c, heap_4.c ou heap_5.c.

Isso existe porque, em sistemas embarcados e de tempo real, alocação dinâmica tem duas dores clássicas: (1) tempo não determinístico para alocar/desalocar e (2) fragmentação. O problema da fragmentação, em particular, tende a piorar com o tempo até causar falha mesmo havendo memória total livre, porque pode não existir um bloco contíguo grande o suficiente.

A sacada do FreeRTOS é: “você escolhe o trade-off”. Quer algo ultra simples e previsível (mas limitado)? heap_1. Quer reaproveitar malloc/free da libc? heap_3. Quer minimizar fragmentação com coalescência e ter estatísticas? heap_4. Quer juntar múltiplas regiões físicas (por exemplo SRAM + CCM + SDRAM)? heap_5.

Onde isso aparece na prática no seu projeto

1. FreeRTOSConfig.h define o tamanho do heap (ex.: configTOTAL_HEAP_SIZE) e opções de monitoramento (ex.: configUSE_MALLOC_FAILED_HOOK).
2. portable/MemMang/heap_x.c implementa o algoritmo. Você compila apenas um deles.
3. O port (Cortex-M, RISC-V, etc.) define detalhes como alinhamento (portBYTE_ALIGNMENT) e macros de região crítica, que influenciam diretamente a segurança do heap em ambiente preemptivo.

Uma visão rápida do que cada heap “promete”

• heap_1: só aloca, não libera. Determinístico e perfeito para “alocar tudo no boot”.
• heap_2: aloca e libera, mas não faz coalescência de blocos adjacentes ⇒ fragmentação pode crescer.
• heap_3: wrapper para malloc()/free() da libc ⇒ facilidade máxima, controle mínimo (e determinismo depende da libc).
• heap_4: lista encadeada + coalescência (junta blocos livres adjacentes) ⇒ melhor contra fragmentação.
• heap_5: mesma ideia do heap_4, mas com múltiplas regiões (útil em MCUs com memórias separadas).

Fórmulas práticas para estimar configTOTAL_HEAP_SIZE

A forma correta (engenharia) é somar o pior caso de tudo que pode ser alocado do heap do FreeRTOS, adicionando overhead e folga:

(1) Heaps consumidos por tarefas (stack + TCB)
Se S_i é o stack depth da tarefa i em words (como normalmente é definido no FreeRTOS), e W é o tamanho da word (4 bytes em Cortex-M 32-bit), então:

\[
M_{stack}=\sum_{i=1}^{N}(S_i \cdot W)
\]

Além disso existe o TCB (Task Control Block) de cada tarefa, que consome memória de heap quando a tarefa é criada dinamicamente (xTaskCreate). Como o tamanho do TCB depende de configuração/porta, você trata como:

\[
M_{tcb} \approx N \cdot (TCB_{bytes})
\]

(2) Filas, semáforos, mutexes, timers, event groups, stream buffers
Cada objeto desses tem: bloco de controle + (às vezes) buffer de dados. Exemplo para uma fila:

\[
M_{queue} \approx QCB_{bytes} + (len \cdot itemSize)
\]

(3) Overhead do alocador + alinhamento + fragmentação esperada
Em heap_4/heap_5 existe overhead por bloco e alinhamento. Uma regra prática conservadora:

\[
configTOTAL_HEAP_SIZE \ge M_{stack}+M_{tcb}+M_{objs} + M_{overhead} + M_{folga}
\]

onde M_folga costuma ser 10% a 30% no protótipo (e reduz depois de medir).

O ponto crítico: se você usa heap_2, a folga precisa ser maior porque ele não cola blocos livres adjacentes; com o tempo, a fragmentação pode vencer você. Já heap_4/5 tendem a envelhecer melhor porque fazem coalescência (mesma motivação dos padrões “fragmentation-free”, como pools e blocos fixos).

Exemplo mínimo (didático) de “contabilidade” do heap

Suponha (Cortex-M, word=4 bytes):

• 6 tarefas com stacks: 512, 512, 384, 384, 256, 256 words
• 3 filas:
  • Q1: len=20 item=16 bytes
  • Q2: len=10 item=64 bytes
  • Q3: len=50 item=4 bytes
• 1 event group, 2 mutexes, 4 timers

Você estimaria:

• \(M_{stack} = (512+512+384+384+256+256)\cdot 4 = 2304\cdot 4 = 9216\) bytes
• Objetos: somar buffers das filas (sem ainda contar overhead):
  • Q1: 20·16=320
  • Q2: 10·64=640
  • Q3: 50·4=200
    Total buffers = 1160 bytes
• Soma parcial ≈ 10376 bytes, e então acrescenta TCBs + overhead do heap + folga. Um configTOTAL_HEAP_SIZE de 16 KB pode funcionar, mas você só “fecha” isso de verdade quando começar a medir com xPortGetFreeHeapSize() e (se habilitar) xPortGetMinimumEverFreeHeapSize().

heap_1, heap_2 e heap_3: algoritmos simples, trade-offs claros

Nesta seção vamos abrir o código conceitualmente, quase linha a linha, para entender como funcionam os heaps mais simples do FreeRTOS. A ideia é que você consiga olhar o heap_x.c e reconhecer exatamente o que está acontecendo — e, mais importante, quando usar e quando evitar cada um.

2.1 heap_1 — alocação linear, determinística e sem retorno

O heap_1 é o alocador mais simples possível. Ele existe para um cenário muito específico:

“Eu aloco tudo no boot e nunca mais libero nada.”

Estrutura interna

Internamente, o heap_1 mantém apenas:

• Um array estático de bytes (o heap em si)
• Um ponteiro de topo que avança a cada alocação

Algo conceitualmente assim:

static uint8_t ucHeap[ configTOTAL_HEAP_SIZE ];
static size_t xNextFreeByte = 0;

static uint8_t ucHeap[ configTOTAL_HEAP_SIZE ];
static size_t xNextFreeByte = 0;

Não existe lista encadeada, não existe metadado por bloco, não existe informação de “livre” ou “ocupado”. Existe apenas um ponteiro que anda para frente.

Algoritmo de alocação (pvPortMalloc)

O algoritmo pode ser descrito assim:

1. Ajusta o tamanho pedido para respeitar alinhamento (portBYTE_ALIGNMENT)
2. Verifica se ainda cabe no heap:
   \[
   xNextFreeByte + xWantedSize \le configTOTAL_HEAP_SIZE
   \]
3. Retorna o endereço atual
4. Incrementa xNextFreeByte

Pseudo-código:

void *pvPortMalloc(size_t xSize)
{
    size_t alignedSize = align(xSize);

    if ((xNextFreeByte + alignedSize) > configTOTAL_HEAP_SIZE)
        return NULL;

    void *pvReturn = &ucHeap[xNextFreeByte];
    xNextFreeByte += alignedSize;

    return pvReturn;
}

void *pvPortMalloc(size_t xSize)
{
    size_t alignedSize = align(xSize);

    if ((xNextFreeByte + alignedSize) > configTOTAL_HEAP_SIZE)
        return NULL;

    void *pvReturn = &ucHeap[xNextFreeByte];
    xNextFreeByte += alignedSize;

    return pvReturn;
}

O que não existe no heap_1

• vPortFree() não faz nada (ou nem existe)
• Não há fragmentação (porque não há liberação)
• Não há reutilização de memória
• Não há envelhecimento do heap

Propriedades de tempo real

• Tempo de alocação: O(1), constante
• Tempo de liberação: inexistente
• Determinismo: absoluto

Por isso o heap_1 é extremamente comum em sistemas safety-critical ou certificáveis, onde toda a alocação é feita na inicialização e o sistema entra em regime permanente.

Quando usar

• Sistemas que criam todas as tarefas, filas e semáforos no boot
• Aplicações com topologia fixa
• Sistemas que não podem aceitar fragmentação sob nenhuma hipótese

Quando evitar

• Qualquer sistema que cria/destroi tarefas dinamicamente
• Protocolos, stacks ou middleware que alocam e liberam buffers em runtime

2.2 heap_2 — lista de blocos livres, mas sem coalescência

O heap_2 já permite free(), mas faz isso de forma limitada. Ele é baseado em uma lista encadeada de blocos livres, porém não junta blocos adjacentes quando eles são liberados.

Isso é um detalhe crítico.

Estrutura interna

Cada bloco livre tem um pequeno cabeçalho (metadado):

typedef struct BlockLink {
    struct BlockLink *pxNextFreeBlock;
    size_t xBlockSize;
} BlockLink_t;

typedef struct BlockLink {
    struct BlockLink *pxNextFreeBlock;
    size_t xBlockSize;
} BlockLink_t;

O heap é visto como uma lista ordenada de blocos livres, do menor endereço para o maior.

Existe um bloco sentinela no início da lista.

Alocação (pvPortMalloc)

O algoritmo segue a lógica first-fit:

1. Ajusta tamanho para alinhamento
2. Percorre a lista de blocos livres
3. Encontra o primeiro bloco grande o suficiente
4. Remove (ou divide) o bloco
5. Retorna o endereço ao usuário

Pseudo-código conceitual:

for (block = freeList; block != NULL; block = block->next) {
    if (block->size >= wantedSize) {
        if (block->size > wantedSize + headerSize) {
            splitBlock(block);
        }
        removeFromFreeList(block);
        return userPointer(block);
    }
}
return NULL;

for (block = freeList; block != NULL; block = block->next) {
    if (block->size >= wantedSize) {
        if (block->size > wantedSize + headerSize) {
            splitBlock(block);
        }
        removeFromFreeList(block);
        return userPointer(block);
    }
}
return NULL;

Liberação (vPortFree)

Aqui está o ponto fraco do heap_2:

• O bloco liberado é inserido de volta na lista
• Não há verificação se o bloco é adjacente a outro bloco livre
• Não há fusão (coalescência)

Resultado: com o tempo, o heap pode virar um “colar de miçangas” — muitos blocos pequenos livres, mas nenhum grande o suficiente para atender uma alocação maior.

Propriedades de tempo real

• Alocação: O(n), depende do tamanho da lista
• Liberação: O(1)
• Fragmentação: cresce com o tempo

Quando usar

• Sistemas simples
• Poucas alocações/liberações
• Onde o tamanho das alocações é relativamente uniforme

Quando evitar (muito importante)

• Sistemas que rodam por longos períodos
• Sistemas de comunicação (buffers variáveis)
• Sistemas onde falhar por fragmentação é inaceitável

Na prática, o heap_2 hoje é mais didático do que recomendado para projetos novos.

2.3 heap_3 — wrapper direto para malloc() e free()

O heap_3 é quase uma provocação arquitetural:

“Quer usar a libc? Então use — mas saiba o preço.”

Ele simplesmente encapsula o malloc() e free() da biblioteca C.

Estrutura interna

Não existe heap do FreeRTOS de verdade aqui. O código é algo como:

void *pvPortMalloc(size_t xSize)
{
    vTaskSuspendAll();
    void *p = malloc(xSize);
    xTaskResumeAll();
    return p;
}

void vPortFree(void *pv)
{
    vTaskSuspendAll();
    free(pv);
    xTaskResumeAll();
}

void *pvPortMalloc(size_t xSize)
{
    vTaskSuspendAll();
    void *p = malloc(xSize);
    xTaskResumeAll();
    return p;
}

void vPortFree(void *pv)
{
    vTaskSuspendAll();
    free(pv);
    xTaskResumeAll();
}

O FreeRTOS apenas protege a chamada contra concorrência, suspendendo o scheduler.

Implicações importantes

• O algoritmo real depende da libc (newlib, picolibc, etc.)
• O tempo de execução é não determinístico
• Fragmentação depende da libc
• Estatísticas do heap do FreeRTOS deixam de fazer sentido

Em microcontroladores, a libc geralmente não foi projetada com hard real-time em mente.

Quando usar

• Portabilidade rápida
• Prototipação
• Sistemas sem requisitos temporais rígidos
• Quando você confia plenamente na libc

Quando evitar

• Sistemas de tempo real estrito
• Sistemas safety-critical
• Ambientes com pouca RAM e longa vida útil

Comparativo direto (heap_1 a heap_3)

Heap	Free	Fragmentação	Determinismo	Complexidade
heap_1			Excelente	Muito baixa
heap_2			Média	Baixa
heap_3		Depende da libc	Ruim	Depende da libc

heap_4: lista livre com coalescência e envelhecimento controlado

O heap_4 é, na prática, o alocador “padrão de fato” do FreeRTOS para aplicações reais. Ele resolve exatamente o maior problema do heap_2: fragmentação progressiva. A diferença conceitual central é simples, mas poderosa:

blocos livres adjacentes são fundidos (coalescidos) quando uma liberação ocorre.

Isso muda completamente o comportamento do heap ao longo do tempo.

3.1 Estrutura interna do heap_4

O heap_4 também é baseado em uma lista encadeada de blocos livres, mas com regras mais rígidas:

• A lista é ordenada por endereço
• Cada bloco contém:
  • tamanho total do bloco
  • ponteiro para o próximo bloco livre
• Existe um bloco sentinela no início

Estrutura conceitual:

typedef struct BlockLink {
    struct BlockLink *pxNextFreeBlock;
    size_t xBlockSize;
} BlockLink_t;

typedef struct BlockLink {
    struct BlockLink *pxNextFreeBlock;
    size_t xBlockSize;
} BlockLink_t;

O heap inteiro é um único bloco livre no início da execução.

Além disso, o heap_4 usa um bit no MSB do tamanho (xBlockSize) para marcar se o bloco está alocado ou livre — evitando estruturas extras.

3.2 Alocação (pvPortMalloc) no heap_4

O processo de alocação segue a lógica first-fit, com divisão de blocos:

1. Ajusta o tamanho solicitado para alinhamento
2. Soma o overhead do cabeçalho
3. Percorre a lista livre até achar um bloco grande o suficiente
4. Se o bloco for muito maior que o pedido:
   • Divide em dois:
     • parte alocada
     • parte livre residual
5. Remove o bloco alocado da lista
6. Retorna o endereço ao usuário

Pseudo-código simplificado:

wanted = align(size) + headerSize;

for (block = freeList; block != NULL; block = block->next) {
    if (block->size >= wanted) {
        if (block->size - wanted > MIN_BLOCK_SIZE) {
            split(block, wanted);
        }
        remove(block);
        markAllocated(block);
        return userPtr(block);
    }
}
return NULL;

wanted = align(size) + headerSize;

for (block = freeList; block != NULL; block = block->next) {
    if (block->size >= wanted) {
        if (block->size - wanted > MIN_BLOCK_SIZE) {
            split(block, wanted);
        }
        remove(block);
        markAllocated(block);
        return userPtr(block);
    }
}
return NULL;

Complexidade temporal

• Alocação: O(n), onde n é o número de blocos livres
• Determinismo: razoável, mas não absoluto

Em sistemas bem projetados, o número de blocos livres tende a permanecer pequeno.

3.3 Liberação (vPortFree) com coalescência

Aqui está o coração do heap_4.

Quando um bloco é liberado:

1. O bloco é marcado como livre
2. Ele é inserido na lista na posição correta por endereço
3. O algoritmo verifica:
   • Se o bloco anterior é adjacente → fundir
   • Se o bloco seguinte é adjacente → fundir
4. O resultado pode ser um único bloco grande

Pseudo-código conceitual:

insertSorted(freeList, block);

if (prevBlock is adjacent to block) {
    merge(prevBlock, block);
    block = prevBlock;
}

if (block is adjacent to nextBlock) {
    merge(block, nextBlock);
}

insertSorted(freeList, block);

if (prevBlock is adjacent to block) {
    merge(prevBlock, block);
    block = prevBlock;
}

if (block is adjacent to nextBlock) {
    merge(block, nextBlock);
}

Essa fusão garante que o heap tente sempre manter o maior bloco contíguo possível.

3.4 Por que a coalescência muda tudo?

Sem coalescência (heap_2), a fragmentação cresce monotonicamente.
Com coalescência (heap_4):

• Fragmentação oscila, mas tende a se autocorrigir
• Alocações grandes continuam possíveis mesmo após muitas liberações
• O heap envelhece de forma estável

Esse comportamento é crucial em:

• Stacks de comunicação
• Protocolos de rede (lwIP, MQTT, HTTP)
• Sistemas que criam buffers temporários

3.5 Overhead e alinhamento no heap_4

Cada bloco possui:

• Cabeçalho (BlockLink_t)
• Alinhamento para portBYTE_ALIGNMENT

Se:

• A = alinhamento (ex.: 8 bytes)
• H = tamanho do cabeçalho
• S = tamanho solicitado

Então o tamanho real consumido no heap é:

\[
S_{real} = \lceil \frac{S + H}{A} \rceil \cdot A
\]

Essa fórmula é essencial para dimensionar corretamente o heap.

3.6 Monitoramento do heap_4

O heap_4 permite métricas valiosas:

• xPortGetFreeHeapSize() — memória livre atual
• xPortGetMinimumEverFreeHeapSize() — pior caso histórico
• vApplicationMallocFailedHook() — diagnóstico de falha

Essas métricas são fundamentais para fechar o projeto e reduzir o heap com segurança.

3.7 Quando escolher heap_4

• Sistemas embarcados reais
• Comunicação dinâmica
• Longa vida útil
• RAM limitada
• Necessidade de previsibilidade razoável sem abrir mão de flexibilidade

Na prática: se você não tem um motivo muito forte para não usar, use heap_4.

heap_5: múltiplas regiões de memória sob um único alocador

O heap_5 é, conceitualmente, uma extensão direta do heap_4. Ele mantém exatamente o mesmo algoritmo de alocação, liberação e coalescência, mas adiciona uma capacidade crucial para microcontroladores modernos:

usar várias regiões físicas de memória como se fossem um único heap lógico.

Isso é extremamente relevante em MCUs como STM32F4/F7/H7, que podem ter SRAM principal, CCM (Core Coupled Memory), SRAM DTCM/ITCM, e até SDRAM externa, todas com características diferentes de latência, largura de barramento e acesso por DMA.

4.1 Motivação real para o heap_5

Em muitos microcontroladores:

• Nem toda memória é:
  • acessível por DMA
  • cacheável
  • rápida
• Algumas regiões são ideais para:
  • stacks de tarefas críticas
  • buffers temporários
• Outras são melhores para:
  • grandes buffers (lwIP, vídeo, áudio, arquivos)

O problema: heap_4 só trabalha com uma região contígua.
O heap_5 resolve isso permitindo várias regiões independentes, tratadas como um conjunto de heaps que cooperam.

4.2 Estrutura interna do heap_5

O heap_5 reutiliza a mesma estrutura BlockLink_t do heap_4:

typedef struct BlockLink {
    struct BlockLink *pxNextFreeBlock;
    size_t xBlockSize;
} BlockLink_t;

typedef struct BlockLink {
    struct BlockLink *pxNextFreeBlock;
    size_t xBlockSize;
} BlockLink_t;

A diferença está na inicialização. Em vez de um único bloco livre inicial, o heap_5 recebe um array de regiões:

typedef struct HeapRegion {
    uint8_t *pucStartAddress;
    size_t xSizeInBytes;
} HeapRegion_t;

typedef struct HeapRegion {
    uint8_t *pucStartAddress;
    size_t xSizeInBytes;
} HeapRegion_t;

Cada região é alinhada, ajustada e inserida na mesma lista global de blocos livres, respeitando a ordenação por endereço.

4.3 Inicialização do heap_5 (vPortDefineHeapRegions)

Ao usar heap_5, você não define configTOTAL_HEAP_SIZE.

Em vez disso, você define explicitamente as regiões:

static uint8_t ucHeap1[ 20 * 1024 ];  // SRAM
static uint8_t ucHeap2[ 64 * 1024 ];  // SDRAM

const HeapRegion_t xHeapRegions[] =
{
    { ucHeap1, sizeof(ucHeap1) },
    { ucHeap2, sizeof(ucHeap2) },
    { NULL, 0 } // terminador obrigatório
};

vPortDefineHeapRegions(xHeapRegions);

static uint8_t ucHeap1[ 20 * 1024 ];  // SRAM
static uint8_t ucHeap2[ 64 * 1024 ];  // SDRAM

const HeapRegion_t xHeapRegions[] =
{
    { ucHeap1, sizeof(ucHeap1) },
    { ucHeap2, sizeof(ucHeap2) },
    { NULL, 0 } // terminador obrigatório
};

vPortDefineHeapRegions(xHeapRegions);

O FreeRTOS então:

1. Alinha cada região
2. Cria um bloco livre inicial para cada uma
3. Insere todos na lista global de blocos livres
4. A partir daí, o algoritmo é idêntico ao heap_4

4.4 Alocação e liberação no heap_5

O algoritmo de pvPortMalloc():

• Percorre a lista global de blocos livres
• Pode retornar memória de qualquer região
• Usa first-fit, como no heap_4

A liberação (vPortFree()):

• Insere o bloco na lista ordenada
• Só faz coalescência dentro da mesma região física
• Nunca tenta fundir blocos que pertencem a regiões distintas

Isso garante segurança e coerência.

4.5 Propriedades temporais e fragmentação

As propriedades são praticamente as mesmas do heap_4:

• Fragmentação: controlada por coalescência
• Alocação: O(n)
• Liberação: O(n) (por causa da inserção ordenada)
• Determinismo: bom para sistemas embarcados, mas não hard real-time absoluto

O cuidado adicional é onde cada tipo de dado pode cair.

4.6 Estratégias práticas de uso do heap_5

Aqui entra engenharia de sistema.

Estratégia 1 — Heap “rápido” + heap “grande”

• Região 1 (SRAM rápida):
  • stacks de tarefas
  • objetos pequenos e frequentes
• Região 2 (SDRAM):
  • buffers grandes
  • payloads de rede
  • filas grandes

Você pode influenciar isso criando wrappers específicos:

void *pvPortMallocFast(size_t size);
void *pvPortMallocLarge(size_t size);

void *pvPortMallocFast(size_t size);
void *pvPortMallocLarge(size_t size);

Ou ainda, alocando manualmente certos buffers fora do heap do FreeRTOS.

4.7 Quando escolher heap_5

• MCUs com múltiplas regiões de RAM
• Uso de SDRAM externa
• Sistemas de comunicação complexos
• Aplicações multimídia
• Quando configTOTAL_HEAP_SIZE é conceitualmente insuficiente

Em projetos STM32H7 com Ethernet + lwIP, o heap_5 costuma ser a única escolha viável.

Comparativo final (heap_1 a heap_5)

Heap	Free	Coalescência	Múltiplas Regiões	Uso típico
1				Boot fixo
2				Didático
3		Depende da libc		Protótipo
4				Produção
5				Sistemas complexos

Fechamento: portabilidade, heap e boas práticas de engenharia em FreeRTOS

Nesta seção final, vamos amarrar tudo: portabilidade do FreeRTOS, escolhas de heap, impacto em tempo real e boas práticas de projeto. Aqui o foco não é mais “como o código funciona”, mas como um engenheiro decide.

5.1 Portabilidade do FreeRTOS: por que o heap é parte do port

A portabilidade do FreeRTOS não é apenas “rodar em vários MCUs”. Ela envolve preservar propriedades temporais ao migrar entre arquiteturas. Por isso:

• O kernel não assume um modelo de memória específico
• O heap não é fixo: é uma política, não uma obrigação
• A camada de port define:
  • alinhamento (portBYTE_ALIGNMENT)
  • região crítica
  • atomicidade de acesso
  • impacto direto no heap

Quando você muda de:

• Cortex-M0 → Cortex-M7
• Sem FPU → com FPU
• SRAM única → SRAM + SDRAM

…o algoritmo de heap escolhido passa a ser uma decisão arquitetural, não apenas de conveniência.

5.2 Heap e padrões de projeto em sistemas embarcados

Na prática, projetos robustos não dependem exclusivamente do heap genérico. Eles combinam o heap do FreeRTOS com padrões clássicos.

Object Pool (pool de objetos)

• Pré-aloca N estruturas fixas
• Não fragmenta
• Tempo determinístico

Ideal para:

• buffers de comunicação
• estruturas de protocolo
• mensagens recorrentes

Static Allocation (alocação estática)

Com:

xTaskCreateStatic(...)
xQueueCreateStatic(...)

xTaskCreateStatic(...)
xQueueCreateStatic(...)

• Elimina uso do heap
• Ideal para safety e certificação
• Menos flexível

Message Buffers e Stream Buffers

• Alocam memória uma única vez
• Depois operam sem fragmentar
• Excelente combinação com heap_4

5.3 Erros comuns no uso do heap do FreeRTOS

Aqui entra experiência prática:

1. Superdimensionar o heap “no escuro”
   → mascara problemas de arquitetura
2. Usar heap_2 em sistemas long-lived
   → falhas tardias e difíceis de depurar
3. Misturar malloc/free da libc com pvPortMalloc
   → corrupção silenciosa
4. Ignorar xPortGetMinimumEverFreeHeapSize()
   → perder o melhor indicador de margem real
5. Criar tarefas dinamicamente em runtime sem controle
   → fragmentação + jitter temporal

5.4 Checklist prático para escolher o heap

Use isto como regra de bolso:

• Sistema com topologia fixa?
  → heap_1 ou alocação estática
• Sistema simples, vida curta, sem requisitos rígidos?
  → heap_3 (com cautela)
• Sistema real, produção, comunicação, longa vida?
  → heap_4
• MCU com múltiplas RAMs / SDRAM externa?
  → heap_5

E sempre pergunte:

“O que acontece com meu heap após 10 horas? 10 dias? 1 ano?”

5.5 Como fechar o dimensionamento do heap (método engenheirado)

1. Comece com estimativa conservadora
2. Instrumente:
   • xPortGetFreeHeapSize()
   • xPortGetMinimumEverFreeHeapSize()
3. Rode o sistema no pior cenário
4. Observe a mínima histórica
5. Reduza o heap até restar uma folga segura (10–20%)

Esse método é repetível, mensurável e defensável tecnicamente.

5.6 Conclusão técnica

O sistema de heap do FreeRTOS não é um detalhe de implementação — é parte central da portabilidade, da previsibilidade temporal e da confiabilidade do sistema.

• heap_1 ensina disciplina
• heap_2 ensina fragmentação
• heap_3 ensina por que libc nem sempre é sua amiga
• heap_4 resolve 90% dos projetos reais
• heap_5 habilita arquiteturas modernas e complexas

Um projeto FreeRTOS maduro não escolhe o heap “porque funcionou”, mas porque faz sentido arquiteturalmente.

The post Portabilidade do FreeRTOS e Gerenciamento de Heap: Entendendo heap_1 a heap_5 em Sistemas Embarcados first appeared on MCU & FPGA.