在 KB 级 RAM 的 MCU 上构建可靠系统

qq_42431428

1664人浏览 · 2026-06-28 08:57:10

qq_42431428 · 2026-06-28 08:57:10 发布

在 KB 级 RAM 的 MCU 上构建可靠系统

cover

一、20KB RAM 的真实压力

STM32F103C8T6 是许多项目的入门选择，但它的 20KB RAM 和 64KB Flash 在实际开发中往往捉襟见肘。要在这么小的空间里塞进通信协议栈、传感器采集、数据滤波和业务逻辑，栈溢出或堆碎片化几乎是绕不开的坑，一旦触发 HardFault，排查起来非常耗时。

更现实的情况是 LoRa 远传节点。在 STM32L4 的 32KB RAM 里，LoRaWAN 协议栈就要吃掉 8KB，传感器驱动 2KB，数据缓冲队列 4KB，再加上 OTA 升级预留的 6KB，留给业务逻辑的只剩下 12KB。这时候一个随意的 malloc(1024)，可能在系统运行 72 小时后因为堆碎片化导致分配失败，而这时候你根本没法重启设备。

在资源受限的嵌入式环境里，内存管理从来不是“优化项”，而是架构设计的硬约束。

二、内存布局与分配机制

ARM Cortex-M 的内存空间由链接脚本（Linker Script）控制。理解段布局是内存优化的前提。

graph TD
    subgraph "Flash 布局 0x08000000"
        A[.isr_vector - 中断向量表] --> B[.text - 代码段]
        B --> C[.rodata - 只读常量]
        C --> D[.ARM.extab - 异常表]
        D --> E[.data LMA - .data 的 Flash 副本]
    end

    subgraph "RAM 布局 0x20000000"
        F[.data VMA - 已初始化全局变量] --> G[.bss - 未初始化全局变量]
        G --> H[Heap - 堆区]
        H --> I[Stack - 栈区 从高地址向低地址增长]
    end

    E -. "启动时复制到 RAM" .-> F
    I -. "栈底 = RAM 末尾" .-> I

    style I fill:#ff6b6b,stroke:#333
    style H fill:#ffd93d,stroke:#333

几个需要特别注意的机制：

.data 段的双重占用：已初始化的全局变量在 Flash 和 RAM 中各占一份空间。启动代码（Reset_Handler）负责把 Flash 里的副本拷贝到 RAM。每多声明一个带初始值的全局变量，Flash 和 RAM 的负担都会增加。
栈溢出没有硬件保护：Cortex-M 的栈从 RAM 末尾向低地址增长。如果栈指针（MSP）和堆区重叠，除非启用了 MPU，否则不会触发异常，而是直接导致数据损坏，这种 bug 最难排查。
堆碎片化的根源：malloc/free 在 .bss 之后的连续空间上管理空闲链表。频繁分配释放不同大小的块，会在堆中产生无法合并的碎片。在 20KB RAM 上，即使总空闲内存有 5KB，也可能因为碎片化无法分配一个连续的 2KB 块。

三、静态内存池的实现

在资源受限的 MCU 上，最稳妥的做法是彻底禁用动态内存分配，改用编译期确定的静态内存池。

// mem_pool.h - 静态内存池管理器
// 设计原则：编译期确定所有内存需求，运行时零碎片，分配/释放 O(1)
#pragma once
#include <stdint.h>
#include <stdbool.h>
#include <string.h>

typedef struct {
    uint8_t* pool_base;       // 池起始地址
    uint16_t block_size;      // 单块大小（字节）
    uint16_t block_count;     // 总块数
    uint16_t free_count;      // 空闲块数
    uint16_t free_head;       // 空闲链表头索引
    uint16_t* next_free;      // 空闲链表数组
} MemPool;

// 初始化内存池
// next_free 数组由调用方提供，避免结构体内嵌变长数组
// 使用 16 位索引而非 32 位指针，节省 50% 链表存储空间
bool mem_pool_init(MemPool* pool, uint8_t* buffer, uint16_t buffer_size,
                   uint16_t block_size, uint16_t* next_free_arr) {
    if (!pool || !buffer || !next_free_arr) return false;
    if (block_size == 0) return false;

    uint16_t block_count = buffer_size / block_size;
    if (block_count == 0) return false;

    pool->pool_base = buffer;
    pool->block_size = block_size;
    pool->block_count = block_count;
    pool->free_count = block_count;
    pool->free_head = 0;
    pool->next_free = next_free_arr;

    // 构建空闲链表：0->1->2->...->(N-1)->0xFFFF(哨兵)
    for (uint16_t i = 0; i < block_count - 1; ++i) {
        pool->next_free[i] = i + 1;
    }
    pool->next_free[block_count - 1] = 0xFFFF;
    return true;
}

// 分配一个块，O(1) 时间复杂度
void* mem_pool_alloc(MemPool* pool) {
    if (!pool || pool->free_count == 0) return NULL;

    uint16_t idx = pool->free_head;
    pool->free_head = pool->next_free[idx];
    pool->free_count--;

    void* block = pool->pool_base + (idx * pool->block_size);
    memset(block, 0, pool->block_size); // 安全清零
    return block;
}

// 释放块回池中，O(1) 时间复杂度
// 释放时插回链表头部，避免反复 alloc/free 同一块导致链表遍历
void mem_pool_free(MemPool* pool, void* block) {
    if (!pool || !block) return;

    uint32_t offset = (uint8_t*)block - pool->pool_base;
    if (offset % pool->block_size != 0) return;

    uint16_t idx = offset / pool->block_size;
    if (idx >= pool->block_count) return;

    pool->next_free[idx] = pool->free_head;
    pool->free_head = idx;
    pool->free_count++;
}

// 获取池的空闲率，用于运行时监控
uint8_t mem_pool_usage_percent(const MemPool* pool) {
    if (!pool || pool->block_count == 0) return 100;
    return ((pool->block_count - pool->free_count) * 100) / pool->block_count;
}

实际使用时，可以为不同功能模块分配独立的内存池：

// app_memory.c - 业务内存规划
// 每个模块的内存需求在编译期确定，运行时互不干扰

// 传感器数据缓冲池：8 块 x 64 字节 = 512 字节
static uint8_t sensor_buf[512];
static uint16_t sensor_next[8];
static MemPool sensor_pool;

// LoRa 帧缓存池：4 块 x 256 字节 = 1024 字节
static uint8_t lora_buf[1024];
static uint16_t lora_next[4];
static MemPool lora_pool;

void app_memory_init(void) {
    mem_pool_init(&sensor_pool, sensor_buf, sizeof(sensor_buf), 64, sensor_next);
    mem_pool_init(&lora_pool, lora_buf, sizeof(lora_buf), 256, lora_next);
}

void sensor_task(void) {
    SensorData* data = (SensorData*)mem_pool_alloc(&sensor_pool);
    if (!data) {
        error_log(ERR_SENSOR_POOL_EXHAUSTED);
        return;
    }
    sensor_read(data);
    filter_apply(data);
    lora_send_queue(data);

    // 注意：lora_send_queue 是异步的，data 的所有权转移给发送任务
    // 由发送任务在完成后释放，此处不能立即 free
}

四、静态分配的代价

静态内存池方案不是银弹，它带来了几个必须正视的代价：

编译期绑定导致内存无法复用。每个模块的内存池大小在编译期固定，即使某个池当前空闲，其他模块也无法借用。在 20KB RAM 上，如果传感器池分配了 512 字节但当前只用了 128 字节，剩余 384 字节就是死空间。缓解方案是对使用时序互斥的模块共享同一块物理 RAM（通过 Overlay 技术），但这增加了链接脚本的复杂度。

块大小对齐造成的内部碎片。内存池的块大小必须取所有使用场景的最大值。如果传感器数据包 90% 是 32 字节、10% 是 64 字节，块大小必须设为 64 字节，90% 的分配会浪费 50% 空间。多级池（32 字节池 + 64 字节池）可以缓解，但增加了管理开销。

无法应对不可预测的内存需求。如果业务逻辑需要根据运行时输入动态调整缓冲区大小（如接收可变长度的 JSON 配置），静态池无法满足。此时只能预留最大可能的空间，进一步压缩其他模块的可用内存。

适用边界：