2. 嵌入式实时系统基础
做嵌入式实时系统，说白了就是在跟“时间”和“空间”这两件事较劲。你代码写得再漂亮，如果内存架构没吃透，该卡顿的时候照样卡顿，该丢数据的时候照样丢数据。这一章，咱们就把嵌入式系统里那几块常见的内存——SRAM、DRAM、Flash、Cache——掰开揉碎了讲清楚。
1. 内存层次结构：为什么不能只用一种内存？
你想想看，如果有一种内存又大、又快、又便宜、还掉电不丢数据，那其他内存早该被淘汰了。但现实是，这四样东西不可能同时满足。所以嵌入式系统里，我们搞了一个“金字塔”结构。
核心原则：越靠近CPU的内存，速度越快、容量越小、成本越高。越远离CPU的内存，速度越慢、容量越大、成本越低。
我刚开始做项目时，总觉得内存嘛，能存数据就行。直到有一次，一个电机控制算法在SRAM里跑得飞快，换成DRAM后直接超时——我才真正体会到“访问延迟”这四个字的分量。
2. SRAM：实时系统的“黄金内存”
SRAM，静态随机存取存储器。它不需要刷新，只要通电就能保持数据。访问速度极快，通常能做到1~2个CPU时钟周期。
我个人的习惯是：但凡对实时性要求苛刻的中断服务程序、高频控制循环、任务切换上下文，我都会优先考虑放在SRAM里跑。
| 特性 | SRAM | DRAM |
|---|---|---|
| 存储单元结构 | 6个晶体管/bit | 1个晶体管+1个电容/bit |
| 是否需要刷新 | 不需要 | 需要（约64ms刷新一次） |
| 典型访问延迟 | 1~2个时钟周期 | 10~50个时钟周期 |
| 典型容量 | KB ~ 几MB | MB ~ GB |
| 典型应用 | Cache、片内RAM、实时数据缓冲区 | 主存、大容量数据存储 |
避坑指南：我曾经在一个项目中，把一个大数组定义在SRAM里，结果链接脚本没配好，数组被放到了DRAM里。程序跑起来后，中断响应时间直接翻了三倍。排查了两天才找到原因——从那以后，我每次都会在链接脚本里显式指定哪些段必须放在SRAM。
3. DRAM：大容量但“慢半拍”
DRAM，动态随机存取存储器。它的密度高、成本低，所以适合做大容量主存。但问题在于，它需要周期性刷新，而且访问延迟比SRAM高一个数量级。
为什么会这样？因为DRAM的存储单元是电容，电荷会慢慢漏掉，所以必须定期“充电”刷新。这个刷新操作会占用总线时间，导致访问延迟不稳定。
我记得有一次做视频缓冲处理，数据量太大，SRAM放不下，只能上DRAM。结果发现，DRAM的刷新周期刚好跟视频帧同步信号冲突了，导致画面出现撕裂。后来我调整了刷新时机，才把问题解决。
注意：在实时系统中使用DRAM时，一定要考虑刷新延迟的抖动。如果系统对确定性要求极高（比如飞行控制器），建议把关键数据放在SRAM里，DRAM只做非实时的大块数据缓冲。
4. Flash：掉电不丢，但写入慢
Flash存储器，分为NOR Flash和NAND Flash两种。NOR Flash支持随机访问，可以直接执行代码（XIP，eXecute In Place）。NAND Flash密度更高，但只能按页读取，适合做文件系统和大容量存储。
Flash的读取速度还可以，但写入和擦除就慢得多了。而且Flash有擦写寿命限制，通常NOR Flash能擦写10万次，NAND Flash只有几千到几万次。
- NOR Flash：读取快，支持XIP，适合存代码。但写入慢，擦除粒度大（通常64KB~128KB一块）。
- NAND Flash：密度高，成本低，适合存数据。但读取需要按页（通常2KB~16KB），不能直接执行代码。
实战经验：我建议把启动代码和关键配置参数放在NOR Flash里，这样上电就能直接跑。而日志、文件系统、固件升级包这些，放在NAND Flash里更划算。
5. Cache：看不见的“性能加速器”
Cache，说白了就是CPU和主存之间的一层小容量高速缓冲。它利用“时间局部性”和“空间局部性”这两个原理，把CPU即将用到的数据提前从DRAM搬到SRAM里。
但Cache在实时系统里是个双刃剑。它能让平均性能提升不少，但也会引入不可预测的延迟抖动——Cache Miss的时候，CPU得等几十个时钟周期去主存拿数据。
我遇到过最头疼的问题：一个实时控制算法，在调试阶段跑得好好的，一上生产环境就偶尔超时。后来发现是Cache Miss导致的。因为生产环境的数据分布跟调试环境不一样，Cache命中率下降了。
我的建议：对于硬实时任务，可以考虑以下策略：
- 使用Cache锁定（Cache Locking），把关键代码和数据固定在Cache里。
- 或者干脆关闭Cache，用SRAM直接跑实时任务。
- 再或者，使用TCM（Tightly Coupled Memory），它跟CPU直连，延迟固定，没有Cache Miss的问题。
6. 访问延迟对比：一张表说清楚
| 存储器类型 | 典型访问延迟 | 相对速度（以SRAM为1） | 典型容量 |
|---|---|---|---|
| CPU寄存器 | 0.3~0.5 ns | 0.1x | 几十字节 |
| SRAM（片内） | 1~3 ns | 1x | KB ~ MB |
| Cache（SRAM实现） | 1~3 ns（命中时） | 1x | KB ~ 几MB |
| DRAM（SDRAM/DDR） | 10~50 ns | 10~20x | MB ~ GB |
| NOR Flash（读取） | 50~100 ns | 30~50x | MB ~ 几十MB |
| NAND Flash（读取） | 10~50 μs（页读取） | 10000x+ | GB ~ TB |
嗯，看到这个表，你应该明白了——为什么实时系统里，关键代码一定要放在SRAM或Cache里。一个DRAM访问延迟是SRAM的10~20倍，如果频繁访问，性能差距是肉眼可见的。
7. 实战：如何为实时任务分配内存？
我总结了一套自己的分配原则，分享给你参考：
- 中断服务程序（ISR）：必须放在SRAM里，或者锁定在Cache中。ISR的响应时间必须确定，不能有Cache Miss的抖动。
- 实时控制循环：同样建议放在SRAM或TCM里。如果代码量太大，至少把最频繁执行的热点函数放进去。
- 任务栈：每个实时任务的栈，最好也放在SRAM里。栈溢出检查、任务切换这些操作，延迟越短越好。
- 大块数据缓冲：比如网络包缓冲、音频/视频帧缓冲，可以放在DRAM里。这些数据量大，对延迟的确定性要求没那么高。
- 配置参数和固件：放在NOR Flash里，上电就能用。运行时如果需要修改，先拷贝到SRAM里操作。
- 日志和文件系统：放在NAND Flash里，容量大、成本低。
再次提醒：我曾经在一个项目中，把实时任务的栈放在了DRAM里，结果任务切换时频繁访问DRAM，导致切换时间从预期的5μs变成了50μs。整个系统的实时性直接崩了。后来我把栈挪到SRAM里，问题才解决。