嵌入式内存基础：区分Flash、RAM、堆与栈，理解静态内存与动态内存的差异及在MCU上的限制
在深入TFLite Micro的Arena分配机制之前，必须先建立对嵌入式系统内存布局的清晰认知。MCU（微控制器）与桌面CPU在内存管理上存在本质差异：没有MMU（内存管理单元）、没有虚拟内存、没有操作系统级别的进程隔离。所有代码、变量、堆栈都挤在有限的物理存储空间中。理解Flash、RAM、堆、栈的角色与边界，是后续分析Arena为何存在、为何高效、以及如何规避内存碎片问题的前提。本章将从硬件存储介质出发，逐步拆解静态内存与动态内存的差异，并给出在MCU上安全使用内存的工程准则。
核心原理：MCU存储介质的物理特性与逻辑角色
嵌入式MCU的存储系统由两种物理介质构成：Flash（闪存）和RAM（随机存取存储器）。Flash是非易失性的，断电后数据不丢失，用于存放程序代码（.text段）、只读常量（.rodata段）以及需要掉电保存的配置数据。RAM是易失性的，断电即清零，用于存放可读写的变量、堆栈以及运行时数据。两者的容量差距悬殊——以STM32F4系列为例，典型配置为1MB Flash搭配192KB RAM，而更小型的Cortex-M0+ MCU可能只有64KB Flash和8KB RAM。这种"大存储、小内存"的格局决定了嵌入式开发的核心矛盾：代码和模型可以很大，但运行时的工作集必须精打细算。
在RAM内部，逻辑上又划分为四个区域：.data段（已初始化全局变量）、.bss段（零初始化全局变量）、堆（Heap）和栈（Stack）。.data和.bss在编译链接时地址已固定，属于静态内存；堆和栈的地址在运行时动态变化，属于动态内存。MCU的RAM总量通常只有几十到几百KB，这意味着所有区域共享同一物理空间，任何区域的过度增长都会挤压其他区域。特别需要注意的是，堆和栈相向生长——堆从低地址向上增长，栈从高地址向下增长，两者之间没有硬件隔离机制。一旦堆溢出向下越过栈底，或栈溢出向上侵入堆区，系统不会立即崩溃，而是静默地产生数据错乱，这种故障极难排查。
判断方法：静态内存与动态内存的识别与度量
在工程实践中，准确区分静态内存与动态内存是优化内存占用的第一步。以下是判断方法和度量手段：
| 维度 | 静态内存（.data/.bss） | 动态内存（堆/栈） |
|---|---|---|
| 分配时机 | 编译链接期确定地址 | 运行时分配/释放 |
| 生命周期 | 程序整个运行期间 | 从malloc到free，或函数调用到返回 |
| 碎片风险 | 无碎片 | 堆碎片是主要风险 |
| 访问速度 | 直接寻址，最快 | 堆需指针间接访问，栈访问极快 |
| 溢出后果 | 编译时报错（链接器检查） | 静默覆盖相邻区域，运行时崩溃 |
| 典型用途 | 全局配置、常量表、固定缓冲区 | 临时对象、变长数据、函数局部变量 |
在编译工程时，可以通过链接器生成的.map文件查看静态内存的精确占用。例如，在GCC工具链中，使用arm-none-eabi-size命令可以快速获得各段大小：
arm-none-eabi-size build/firmware.elf
text data bss dec hex filename
45232 1236 8912 55380 d854 build/firmware.elf其中data和bss之和即为静态RAM占用（约10KB），text为Flash中的代码量。对于栈的使用量，可以通过在启动文件中将栈区域填充为特定模式（如0xAA），运行一段时间后检查被覆盖的字节数来估算。堆的使用量则可以通过封装malloc/free统计峰值分配量。在TFLite Micro场景中，Arena本质上是一种静态化的动态内存管理——它在.bss段中划出一块固定大小的数组，然后在运行时由TFLite Micro的分配器（如MicroAllocator）管理，既避免了堆碎片，又保留了动态分配的灵活性。
案例拆解：一个典型的MCU内存布局与栈溢出排查
假设我们使用STM32L476（1MB Flash, 128KB RAM）部署一个关键词唤醒模型，TFLite Micro模型占用约300KB Flash（权重+算子），运行时需要约40KB的RAM用于中间张量。初始设计如下：
- .data + .bss：全局变量、音频缓冲区（16KB）、Arena数组（32KB），共约50KB
- 堆：预留8KB，用于日志字符串格式化等
- 栈：默认配置4KB
系统运行后，发现偶发性的HardFault，且故障无固定规律。通过调试器查看，发现栈指针（SP）已经越过栈底边界，进入了堆区域。进一步分析调用栈，发现中断服务函数（ISR）中调用了printf，而printf内部使用了约1.2KB的栈空间。同时，主循环中的音频处理函数嵌套调用深度达到6层，每层消耗约300字节。两者叠加，峰值栈需求达到5.8KB，远超4KB的配置。
排查与修复过程如下：
- 测量实际栈使用：在启动文件中将栈区域全部填充为0xAA，运行24小时后检查0xAA被覆盖的边界，确认峰值栈使用为5.6KB。
- 优化栈配置：将栈大小调整为8KB，同时将
printf替换为轻量级的snprintf到固定缓冲区，减少栈占用。 - 调整堆与栈的边界：由于堆仅使用了约2KB，将堆缩小至4KB，释放4KB给栈，最终栈配置为12KB，堆为4KB。
- 验证：重新运行72小时，未再出现HardFault，且通过
__builtin_return_address检查栈边界，余量充足。
这个案例揭示了MCU内存管理的核心教训：栈溢出是静默的、累积的、与中断上下文强相关的。在TFLite Micro的推理过程中，如果回调函数（如音频采集回调）中使用了大量局部变量，或者启用了FPU（浮点单元）导致上下文保存开销增大，栈压力会显著上升。因此，在部署TFLite Micro时，建议将栈配置为至少8KB，并避免在中断中调用复杂函数。
常见误区与总结复盘
在嵌入式内存管理中，以下误区最为常见：
malloc/free会导致堆碎片化。例如，先分配3KB、释放2KB、再分配3KB，可能因为碎片导致分配失败。TFLite Micro选择Arena机制正是为了避免这个问题——Arena一次性分配大块内存，内部通过偏移量管理，不产生碎片。