MCU内存基础：掌握Flash、SRAM、寄存器、堆栈等内存类型的特点、容量限制与访问速度差异

TinyML 模型在 MCU 上部署时，最先遇到的硬约束往往不是算力，而是内存。一个 300KB 的模型文件，可能因为目标开发板仅有 256KB Flash 而无法烧录；一个需要 80KB 激活缓冲区的推理引擎，可能因为 SRAM 只有 64KB 而频繁触发 HardFault。理解 MCU 内存的物理本质、容量边界与访问特性，是进行后续所有优化工作的前提。本章将系统拆解 Flash、SRAM、寄存器与堆栈四大内存区域，从硬件原理到工程实践，帮助你建立一张清晰的内存认知地图。

上图展示了 MCU 内存体系的整体架构。CPU 核心通过总线矩阵与三类存储资源交互：寄存器堆位于 CPU 内部，访问速度最快；SRAM 与 Flash 通过总线连接，容量与速度各有取舍；外设寄存器则映射到特定的地址空间。理解这张图，就掌握了 MCU 内存优化的总纲。

2.1 核心原理：四大内存区域的本质与分工

MCU 的内存体系可以划分为四个层次，每一层都有其不可替代的物理角色。理解这些角色的本质，是优化内存占用的第一性原理。

2.1.1 Flash：代码与常量的永久居所

Flash（闪存）是一种非易失性存储器，断电后数据不丢失。在 MCU 中，Flash 主要存放编译后的机器码（.text 段）、只读常量（.rodata 段）以及初始化数据副本。其物理结构基于浮栅晶体管，写入时需要施加高压脉冲，因此写入速度远慢于读取速度（典型值：读 50-100ns，写 3-10ms/页）。

容量方面，主流 TinyML 开发板的 Flash 范围从 64KB（如 STM32F103C8T6）到 2MB（如 nRF5340）不等。对于 TinyML 场景，Flash 的主要压力来自模型权重：一个 100KB 的量化模型，加上 50KB 的运行时库，就会占据 150KB 空间。Flash 的读取速度受限于 MCU 的指令预取机制，现代 MCU 通常配备 Flash 缓存（如 STM32 的 ART 加速器），使得顺序执行代码时可以达到零等待状态。

2.1.2 SRAM：运行时数据的临时舞台

SRAM（静态随机存取存储器）是易失性存储器，断电即失。它由六个晶体管构成一个存储单元，不需要刷新，访问速度极快（1-2 个时钟周期）。SRAM 在 MCU 中承担四个关键角色：全局变量（.data 段）、未初始化变量（.bss 段）、堆（Heap）和栈（Stack）。

容量限制是 SRAM 最突出的痛点。以 STM32F4 系列为例，SRAM 通常只有 128KB-192KB，而一个浮点型的中间特征图就可能消耗 50KB 以上。更关键的是，SRAM 的访问速度直接影响推理延迟——每次从 SRAM 读取数据都需要 2-4 个周期，如果频繁访问大数组，性能会显著下降。

2.1.3 寄存器：CPU 的贴身工作台

寄存器是 CPU 内部的高速存储单元，访问速度最快（1 个周期内完成读写）。在 ARM Cortex-M 系列中，通用寄存器 R0-R12、堆栈指针 SP（R13）、链接寄存器 LR（R14）和程序计数器 PC（R15）构成了核心寄存器组。此外，还有状态寄存器 xPSR 和特殊寄存器（如 PRIMASK、CONTROL）。

寄存器数量极其有限（通常 16-32 个），但编译器会通过寄存器分配算法最大化利用它们。在 TinyML 推理中，寄存器主要用于：循环计数器、临时计算结果、函数调用参数传递（前 4 个参数通过 R0-R3 传递）。优化寄存器使用，本质上就是减少内存访问次数。

2.1.4 堆栈：函数调用的临时记忆

栈（Stack）是 SRAM 中一块向下生长的区域，由 SP 指针管理。每次函数调用，CPU 将返回地址、寄存器现场压栈；每次局部变量分配，也在栈上预留空间。堆（Heap）则向上生长，用于动态内存分配（malloc/free）。

栈的大小在链接脚本中静态定义（典型值 1KB-8KB），堆的大小同样静态配置。在 TinyML 中，栈溢出是常见故障——递归调用或大型局部数组（如 4KB 的局部缓冲区）会迅速耗尽栈空间。堆则容易产生碎片，频繁的 malloc/free 会导致内存碎片化，最终分配失败。

2.2 判断方法：如何精确测量内存占用

在优化之前，必须准确知道当前的内存使用情况。以下是三种工程上最实用的测量方法。

2.2.1 编译器 Map 文件分析

编译完成后，链接器会生成 .map 文件，其中详细列出了每个段（Section）的起始地址、大小和所属目标文件。这是最精确的内存使用报告。

// 典型的 .map 文件片段
Memory Configuration
  FLASH  : ORIGIN = 0x08000000, LENGTH = 512K
  SRAM   : ORIGIN = 0x20000000, LENGTH = 128K

Linker script and memory map
  .text          0x08000000     0x1a4f8
                 0x08000000                startup_stm32f407xx.o
                 0x08000000                .isr_vector
                 0x08000004                .text
  .rodata        0x0801a4f8      0x3a20
  .data          0x20000000      0x1a00
  .bss           0x20001a00      0x4c80
  .heap          0x20006680      0x400
  .stack         0x20006a80      0x800

通过分析 .map 文件，可以精确得知：Flash 占用 = .text + .rodata + .data（初始值副本）；SRAM 占用 = .data + .bss + .heap + .stack。重点关注 .bss 段——它往往占据 SRAM 的大头，因为未初始化的全局数组（如神经网络激活缓冲区）都放在这里。

2.2.2 运行时动态监测

对于栈使用情况，静态分析难以覆盖所有执行路径。可以在运行时通过“栈水位标记”方法测量：在栈底填充特定模式（如 0xAA），程序运行一段时间后检查被覆盖的边界，即可估算最大栈深度。

// 栈水位标记示例
#define STACK_PATTERN 0xAAAAAAAA
extern uint32_t _estack;  // 栈顶地址
extern uint32_t _sstack;  // 栈底地址

void stack_watermark_init(void) {
    uint32_t *p = &_sstack;
    while (p < &_estack) {
        *p++ = STACK_PATTERN;
    }
}

uint32_t stack_watermark_check(void) {
    uint32_t *p = &_sstack;
    uint32_t used = 0;
    while (*p == STACK_PATTERN && p < &_estack) {
        p++;
        used++;
    }
    return (&_estack - &_sstack) - used;  // 返回已用字节数
}

2.2.3 链接脚本约束法

在链接脚本中设置内存区域的硬上限，如果链接失败则说明超限。这是一种“强制约束”手段，适合在 CI/CD 流程中自动检查。

/* 链接脚本中设置 SRAM 使用上限 */
MEMORY
{
  FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 512K
  SRAM (rwx)  : ORIGIN = 0x20000000, LENGTH = 120K  /* 预留 8KB 给系统 */
}

2.3 案例拆解：STM32F407 上的 TinyML 内存瓶颈分析

下面通过一个真实案例，展示如何系统性地分析 MCU 内存问题。

2.3.1 项目背景与初始现象

某工业预测性维护项目，需要在 STM32F407VG（Cortex-M4F，192KB SRAM，1MB Flash）上部署一个振动信号分类模型。模型采用 TensorFlow Lite Micro 框架，量化后权重为 180KB。初始编译后，链接器报告 Flash 占用 320KB，SRAM 占用 168KB。系统运行后，在推理过程中频繁进入 HardFault 异常。

2.3.2 分析过程

首先通过 .map 文件定位 SRAM 占用分布：

• .bss 段： 92KB —— 其中 80KB 是 TensorFlow Lite Micro 的 arena（推理缓冲区）
• .data 段： 12KB —— 全局变量和初始化数据
• .stack： 4KB —— 默认配置
• .heap： 2KB —— 动态分配

HardFault 的根因是栈溢出。TensorFlow Lite Micro 的推理过程中，某些算子（如深度可分离卷积）会创建较大的局部数组，加上嵌套函数调用的栈帧，4KB 栈空间在峰值时被耗尽。

2.3.3 优化措施与结果

采取三步优化策略：

1. 调整 arena 大小： 将 TensorFlow Lite Micro 的 arena 从 80KB 缩减到 64KB，通过设置 tensor_arena_size 参数。模型实际峰值激活需求为 58KB，预留 6KB 余量。
2. 栈空间扩展： 将栈从 4KB 增加到 8KB，同时将堆从 2KB 缩减到 1KB（项目未使用动态分配）。
3. 局部数组静态化： 将推理函数中一个 2KB 的局部缓冲区改为静态全局变量，避免栈压力。

优化后，SRAM 占用降至 152KB，栈峰值使用约 5.2KB，系统稳定运行。Flash 方面，通过启用 -Os 优化选项，代码段从 140KB 降至 118KB，总 Flash 占用 298KB。

2.3.4 复盘与经验

这个案例揭示了三个关键教训：第一，TensorFlow Lite Micro 的 arena 默认值往往偏大，需要根据实际模型需求精确配置；第二，栈空间不足是 TinyML 推理的隐形杀手，建议在开发初期就设置 8KB 以上的栈；第三，-Os 优化对 Flash 占用有显著改善，但需要验证推理延迟是否受影响（本案例中延迟仅增加 3%）。

2.4 常见误区与总结复盘

在 MCU 内存优化的实践中，开发者经常陷入以下误区，需要特别警惕。

2.4.1 误区一：混淆 Flash 与 SRAM 的优化策略

Flash 优化的核心是减少代码体积和模型大小，手段包括量化、权重共享、代码裁剪。SRAM 优化的核心是减少运行时数据占用，手段包括缓冲区复用、内存池、静态分配。两者不能混为一谈——试图通过压缩 Flash 来节省 SRAM 是无效的，反之亦然。

2.4.2 误区二：忽视内存对齐的影响

Cortex-M 系列要求 32 位数据按 4 字节对齐访问，否则会触发总线错误。结构体中的字段排列如果不注意对齐，会产生大量填充字节。例如，一个包含 char 和 uint32_t 的结构体，如果顺序不当，可能从 5 字节膨胀到 8 字节。使用 __attribute__((packed)) 可以消除填充，但会降低访问速度。

2.4.3 误区三：忽略链接脚本的默认配置

许多开发者使用 IDE 默认的链接脚本，其中堆和栈的大小往往不适合 TinyML 场景。默认的堆大小（如 512 字节）可能不够，而栈大小（如 2KB）可能太小。建议在项目初期就根据实际需求定制链接脚本。

2.4.4 总结：内存优化的优先级排序

根据工程实践，MCU 内存优化的优先级应为：

1. 消除浪费： 检查是否有未使用的全局变量、过大的缓冲区、重复的常量定义。
2. 复用缓冲区： 在推理的不同阶段复用同一块内存（如输入缓冲区与中间特征图共享）。
3. 调整分配策略： 将动态分配改为静态分配，将大数组从栈移到 .bss 段。
4. 压缩模型： 量化、剪枝、权重聚类，这是 Flash 优化的核心手段。
5. 编译器优化： 使用 -Os 或 -Oz 选项，但需验证性能影响。