1. XIP 技术概述：什么是 eXecute In Place，历史背景与优势
1.1 从“拷贝到 RAM 再执行”说起
做嵌入式久了，你会发现一个很普遍的现象：大多数 MCU 启动时，代码其实放在 Flash 里，但 CPU 先把它搬到 RAM，再从 RAM 里取指令执行。为什么绕这么大一圈？因为 RAM 快，Flash 慢。早期的 Flash 读取延迟动辄几十个时钟周期，CPU 根本等不起。
这种传统方式有个明显的缺点——RAM 很贵啊。我手头做过一个无线传感器节点，Flash 有 2MB，RAM 只有 128KB，结果编译出来的固件 180KB，硬是塞不进 RAM。没办法，只能把最常用的中断服务例程放到 RAM，其他代码继续在 Flash 里别扭地跑。你想想看，如果能把超过 RAM 大小的固件直接原地执行，是不是就能省掉这份纠结？这就是 XIP 的初衷。
1.2 XIP 的核心思想：直接在 Flash 上执行
XIP，全称 eXecute In Place，意思是“原地执行”。说白了，就是让 CPU 从 Flash 存储器的地址空间里直接取指令、读数据，不需要把代码先拷贝到 RAM。为了实现这个效果，Flash 必须支持随机读取，而且得挂载到 CPU 的地址映射总线上。
举个例子，Cortex-M 系列的 MCU，你只要把 QSPI Flash 映射到 0x90000000 开始的地址域，CPU 的取指单元就能像访问内部 SRAM 一样去读那个地址。当然，速度是个问题——好在现代 Flash 和 QSPI 接口已经快了很多。
— Flash 必须能随机读取（NOR 型或支持内存映射的 NAND 型）
— 控制器必须提供连续地址空间的映射窗口
— 总线时钟要匹配 Flash 的读取时序
1.3 历史背景：为什么 XIP 过去不普及？
我刚开始做嵌入式的时候，大家聊起 XIP 都觉得是“高端玩法”。仔细想想，原因无非三条。
| 瓶颈 | 早期状态 | 结果 |
|---|---|---|
| Flash 读取速度 | 70~120ns，主频 100MHz 时需等 7~12 个等待周期 | CPU 空等，性能断崖式下降 |
| Flash 接口并行性 | 8/16 位并行接口，占用大量 GPIO | 大封装、高功耗，不适合小模块 |
| 内存映射控制器 | 无内置 XIP 控制器，需外部 FPGA 桥接 | 成本高，调试复杂 |
你想想，在那个年代搞 XIP，要么是军用级的高端处理器，要么得加一片 FPGA 来实现地址转换——普通项目根本用不起。我还记得 2010 年以前，很多工程师宁愿把代码压缩后解压到 RAM，也不去碰 XIP，因为实在太折腾了。
1.4 现代 QSPI Flash 如何让 XIP 成为现实？
真正的转折点出现在 QSPI（Quad SPI）Flash 普及之后。QSPI 接口有四个数据线，配合 DDR 模式，读带宽能做到 400Mbps 甚至更高。更重要的是，很多 MCU 内置了 QSPI 内存映射控制器，只要配置好基地址和时序，Flash 就像一块普通的内存一样出现在 map 里。
个人习惯上，我会优先选择支持“连续读取”（Continuous Read Mode）的 Flash，这样地址递增时不用每次发送命令头，能省下不少时钟开支。另外注意一点：QSPI 通常工作在 80~120MHz，一个等待周期是 8~12ns，配合流水线预取，CPU 的实际等待次数可以降到 0~3 次。嗯，这个数字在绝大多数场景下是可以接受的。
1.5 XIP 的核心优势
说了这么多，归结起来就是这几点好处：
- 节省 RAM 开销 —— 代码不需要常驻 RAM，RAM 可以全部分给堆栈、数据缓冲区和实时变量。我有个项目原本需要 512KB RAM，改用 XIP 后 256KB 就够，成本直降 30%。
- 启动速度极快 —— 复位后直接从 Flash 执行，不用等 RAM 初始化完毕再搬运。很多工业模块要求上电 50ms 内响应，传统方式做不到，XIP 轻松满足。
- 系统复杂度降低 —— 省掉 Bootloader 中的拷贝逻辑，也省掉怀疑“拷贝是否完整”的校验代码。代码越少，bug 越少。
- 低功耗 —— RAM 不需要持续自刷新（尤其对于 SRAM），Flash 读操作本身功耗比 RAM 刷新低。不过要注意 XIP 时 Flash 不能断电，否则会跑飞。
- 升级更灵活 —— 通过双 Bank 切换，可以一边运行现有固件，一边擦写另一个 Bank 的新固件。升级完直接跳转地址，零拷贝。
1.6 避坑指南与个人经验
XIP 用好了很舒服，但用砸了也很要命。我在这上面栽过几次跟头，挑几个典型的说说。
- 某次选了一款声称支持 XIP 的 NAND Flash，结果发现 NAND 的坏块管理和页读取模式根本没法直接被 CPU 随机寻址。后来换回 NOR 方案才解决。
- 地址映射对齐问题。QSPI 映射窗口通常要求 4KB 或 1MB 对齐，我把 .text 段放在一个非对齐的地址上，结果 CPU 就直接 HardFault 了。记得检查链接脚本里的
QSPI_BASE对齐。 - 缓存一致性。某些 Cortex-M7 有 L1 Cache，当 DMA 写 Flash 而 CPU 已经 Cache 了旧数据时，你需要显式 invalidate 或配置 MPU 区域为 Non-Cacheable。我那个项目就是因为没 invalidate，查了两天死机问题。
最后分享一个实际项目的配置片段。我用的是 STM32H750 + W25Q64JV（QSPI NOR Flash），在 CubeMX 里配置 Memory Mapped 模式：
// 简化的初始化流程（伪代码）
qspi_handle.Instance = QUADSPI;
qspi_handle.Init.ClockPrescaler = 1; // 120MHz / 2 = 60MHz
qspi_handle.Init.FlashID = QSPI_FLASH_ID_1;
qspi_handle.Init.MemoryMapped = QSPI_MEMORY_MAPPED_ENABLE;
// 时序参数按 Flash 手册设置
HAL_QSPI_Init(&qspi_handle);
// 链接脚本中，将 .text 段放到 QSPI 地址范围
// QSPI_BASE = 0x90000000;
// .text : { *(.text*) } > QSPI_REGION这段代码跑起来后，通过调试器查看 PC 指针，确实指向 0x9000xxxx 地址。验证 XIP 是否生效，最简单的办法就是关掉 RAM 供电，如果芯片还能正常运行，那就是真的 XIP 了。
当然，实际项目中没人会去拔电源线。我更推荐用 System Tick 统计循环执行时间，对比代码在 RAM 和 Flash 上的速度差异。一般情况下，只要等待周期不超过 2，差异完全可以接受。
这张图很直观：左边传统方式多了一条“代码搬运”的路径，消耗 RAM 空间和拷贝时间；右边 XIP 直接连接 CPU 到 Flash，干净利落。实际项目中，当你遇到 RAM 不足或启动时间严峻的挑战时，XIP 往往是性价比最高的解决方案之一。