2、内存管理基础：内存层次结构（Cache、RAM、ROM）、地址空间与映射
各位同学，咱们今天聊聊嵌入式系统里最基础、也最容易被忽视的东西——内存。说实话，我见过太多工程师在项目后期被内存问题搞得焦头烂额。代码写得好好的，一上硬件就崩，查来查去，最后发现是内存访问越界或者Cache没刷干净。嗯，咱们今天就把这块地基打牢。
2.1 内存层次结构：为什么要有这么多层？
你想想看，一个嵌入式系统里，CPU跑得飞快，动不动几百兆甚至上GHz。但外设和存储呢？慢得像蜗牛。如果CPU直接去读外部Flash或者SDRAM，那大部分时间都在等数据，性能直接拉胯。
所以，硬件工程师们搞了个分层结构。说白了，就是用速度最快、容量最小的存储器给CPU当“贴身秘书”，把最常用的数据放它那儿。速度慢、容量大的存储器放远处，当“仓库”。
我个人习惯把内存层次比作一个办公室：
- 寄存器：就是你手边的笔，随拿随用，但就那么几支。
- Cache：是你办公桌上的文件架，常用的资料放这儿，一伸手就够到。
- RAM：是你身后的文件柜，东西多，但得转身去拿。
- ROM/Flash：是公司档案室，存着所有历史资料，但得走几步路去调阅。
这个层次结构，从上到下，速度越来越慢，容量越来越大，成本越来越低。咱们做嵌入式，就是要学会怎么用好这个结构。
2.2 Cache：CPU的“高速缓存”
Cache这东西，我刚开始做项目时总觉得它很神秘。其实说白了，它就是一块SRAM，比主存快得多，但容量小。CPU要读数据，先问Cache有没有。有，叫“命中”，直接拿；没有，叫“未命中”，得去主存搬，顺便把附近的数据也搬进来——这叫“空间局部性”。
我在项目中遇到过一个问题：一个实时控制算法，每次运行时间都抖动得很厉害。查了半天，发现是Cache命中率不稳定。数据量刚好超过Cache大小，导致频繁的“Cache Thrashing”（缓存颠簸）。后来我把数据重新排了排，把热点数据对齐到Cache Line，问题就解决了。
关键概念：
- Cache Line：Cache的最小操作单位，通常是32或64字节。一次读入一整行。
- 命中率：CPU访问Cache成功的概率。命中率越高，性能越好。
- 写策略：写命中时，有“写直达”（同时写Cache和主存）和“写回”（只写Cache，标记脏位，等替换时再写回主存）。
我的小技巧：在实时系统中，如果某个中断服务程序对时间要求极严，我会把它的代码和关键数据“锁定”在Cache里。很多芯片支持Cache Lockdown功能，这样就不会被其他代码挤出去。代价是Cache可用容量变小，但确定性大大提升。
2.3 RAM：程序的主战场
RAM分两种：SRAM和DRAM。SRAM快，但贵，容量小，一般做Cache或片内RAM。DRAM慢一些，但便宜，容量大，就是我们常说的内存条。
在嵌入式里，RAM主要放这些东西：
- 栈（Stack）：局部变量、函数调用返回地址。我见过最惨的bug就是栈溢出，程序跑着跑着就飞了。建议你给每个任务分配栈时，多留30%的余量。
- 堆（Heap）：动态分配的内存。嗯，这里我要多说一句：在实时系统里，我尽量不用动态分配。malloc/free的耗时不确定，而且容易产生碎片。实在要用，就用固定大小的内存池。
- 全局/静态区：全局变量、static变量。这部分在程序启动时就分配好了，大小固定。
我曾经踩过的坑：在一个ARM Cortex-M3的项目里，我用了大量局部数组，每个数组几百字节。结果栈空间不够，程序在函数返回时直接跑飞。后来用静态数组代替，问题解决。记住：嵌入式里，栈空间是宝贵的，别把大数组放栈上。
2.4 ROM/Flash：代码的归宿
ROM（只读存储器）和Flash，是存放程序代码和固定数据的地方。掉电不丢失。现在主流是Flash，可以擦写，但速度慢，而且有擦写寿命限制。
这里有个常见的误解：很多人以为代码直接在Flash里运行。其实不是。大多数嵌入式系统会把代码从Flash拷贝到RAM里再执行，这叫“代码重定位”。为什么？因为Flash太慢了，CPU跑起来要等它。拷贝到RAM里，速度能快好几倍。
当然，也有例外。有些低功耗MCU，Flash速度够快，或者对功耗要求极严，就直接在Flash里执行（XIP，Execute In Place）。
| 存储器类型 | 速度 | 容量 | 掉电保持 | 典型用途 |
|---|---|---|---|---|
| 寄存器 | 1个时钟周期 | 几十字节 | 否 | CPU内部操作 |
| Cache (SRAM) | 2-10个时钟周期 | 几KB~几MB | 否 | 数据/指令缓存 |
| SRAM | 10-50个时钟周期 | 几KB~几十MB | 否 | 片内RAM、实时数据 |
| DRAM (SDRAM/DDR) | 50-200个时钟周期 | 几十MB~几GB | 否 | 主存、大缓冲区 |
| Flash | 几十~几百ns | 几KB~几GB | 是 | 代码存储、固件 |
2.5 地址空间与映射：CPU眼中的世界
CPU看内存，就像我们看一张地图。每个地址对应一个字节。但硬件上，这些地址可能映射到不同的物理设备上。比如，地址0x0000_0000到0x0000_FFFF是Flash，0x2000_0000到0x2000_FFFF是SRAM，0x4000_0000开始是外设寄存器。
这个映射关系，由芯片的“内存映射”决定，是固定的。你写代码时，直接操作这些地址就行。比如：
// 假设某个外设寄存器在地址 0x4000_1000
#define GPIOA_ODR (*(volatile uint32_t *)0x40001000)
// 写数据
GPIOA_ODR = 0x01;这里有个坑：volatile关键字不能少。它告诉编译器，这个地址的值可能被硬件改变，别优化掉。我见过有人忘了加，结果调试时发现写寄存器没反应，其实是编译器把写操作优化掉了。
在带MMU（内存管理单元）的系统里，比如Linux，还有一层“虚拟地址”映射。CPU看到的是虚拟地址，MMU把它转成物理地址。这样每个进程都有自己的地址空间，互不干扰。但在裸机或RTOS里，我们通常直接操作物理地址。
地址空间划分的要点：
- 代码区：通常映射到Flash或RAM（如果代码重定位）。只读。
- 数据区：映射到RAM。可读写。
- 外设区：映射到外设寄存器。操作时要小心，别乱写。
- 保留区：未使用的地址空间，访问会触发异常。
2.6 实际项目中的内存布局
我习惯在项目一开始，就画一张内存布局图。比如一个典型的STM32项目：
/* 链接脚本中的内存布局示意 */
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}
SECTIONS
{
.text : { *(.text*) } > FLASH /* 代码 */
.rodata : { *(.rodata*) } > FLASH /* 常量 */
.data : { *(.data*) } > RAM AT> FLASH /* 初始化数据，运行时在RAM */
.bss : { *(.bss*) } > RAM /* 未初始化数据 */
.stack : { . = . + 4K; } > RAM /* 栈空间 */
}你看，.data段在Flash里存着初始值，但运行时被拷贝到RAM里。.bss段在RAM里，启动时清零。栈放在RAM末尾，防止溢出时覆盖其他数据。
我的建议：在链接脚本里，把栈放在RAM的最高地址，这样栈溢出时，会先访问到未使用的地址，触发硬件异常，而不是悄悄覆盖全局变量。我吃过这个亏，后来一直这么干。
2.7 避坑指南：内存相关的常见问题
最后，我总结几个我亲身经历过的坑，你遇到了可以少走弯路：
- Cache一致性问题：DMA和CPU共享数据时，如果Cache没刷，CPU看到的是旧数据。我曾经在音频处理项目里，DMA搬完数据，CPU读到的还是Cache里的旧值，声音断断续续。解决办法：在DMA传输前后，手动刷Cache。
- 地址对齐：有些CPU访问未对齐地址会触发异常。比如，一个32位整数，地址必须是4的倍数。我建议你结构体里加#pragma pack，或者手动填充字节。
- 内存碎片：频繁malloc/free，堆会碎成一片片。我见过一个项目跑了三天，malloc返回NULL，系统直接挂掉。解决方案：用固定大小的内存池，或者干脆不用动态分配。
- 栈溢出检测：在栈底放一个“哨兵值”，定时检查它有没有被改写。很多RTOS自带这个功能，记得打开。
好了，这一章的内容就到这儿。内存管理是嵌入式系统的基石，你把它搞透了，后面调实时性、调性能，都会顺手很多。下一章咱们聊聊“内存分配策略”，看看怎么在有限的内存里，做出高效的分配方案。