4. Flash芯片选型：SPI NOR/NAND Flash、Parallel NOR Flash、eMMC特性对比
做嵌入式这么多年，Flash选型这事儿，我踩过的坑真不少。很多人觉得不就是个存储芯片嘛，随便挑一个容量够的就行。但等你真正开始调JTAG烧录脚本，或者遇到量产时批量性烧录失败，你就会明白——选型选不对，后面全是泪。
今天咱们就把主流的几种Flash掰开揉碎聊清楚。SPI NOR、SPI NAND、Parallel NOR、eMMC，这四兄弟到底有啥区别？什么时候该用谁？
核心结论先放这：没有最好的Flash，只有最合适的。选型取决于你的启动方式、代码执行模型、容量需求和成本预算。
4.1 先看一张总览对比表
我习惯先把关键参数拉一张表，这样心里有个底。你想想看，下面这几个维度，基本决定了你的硬件设计和软件策略。
| 特性 | SPI NOR Flash | SPI NAND Flash | Parallel NOR Flash | eMMC |
|---|---|---|---|---|
| 接口 | SPI (1/2/4线) | SPI (1/2/4线) | 并行地址/数据总线 | MMC/SD协议 (8线) |
| 读取方式 | XIP (就地执行) | 非XIP，需拷贝到RAM | XIP (就地执行) | 非XIP，需通过MMC控制器 |
| 存储单元 | NOR单元 | NAND单元 | NOR单元 | 内部含NAND + 控制器 |
| 容量范围 | 512KB ~ 256MB | 128MB ~ 8GB | 1MB ~ 128MB | 4GB ~ 256GB |
| 坏块管理 | 无坏块问题 | 需要坏块管理 | 无坏块问题 | 内部控制器处理 |
| 擦除粒度 | 扇区 (4KB~64KB) | 块 (128KB~512KB) | 扇区 (64KB~128KB) | 擦除块 (以分区为单位) |
| 引脚数 | 6~8个 | 6~8个 | 32~56个 | 13~15个 |
| 典型应用 | Bootloader、代码存储 | 文件系统、大容量数据 | 老旧系统、快速随机访问 | Android系统、大容量存储 |
4.2 SPI NOR Flash——最常用的代码存储方案
SPI NOR是我个人用得最多的Flash类型。为什么？因为它支持XIP（eXecute In Place），也就是CPU可以直接从Flash里面取指令执行，不需要先把代码拷贝到RAM里。
我记得有一次做一款工业控制器，MCU内部RAM只有64KB，但固件有512KB。如果不用SPI NOR，我根本没法跑这个系统。代码直接在Flash上跑，RAM只放堆栈和变量，完美解决。
我的经验：SPI NOR的读速度其实不慢。Quad SPI模式下，时钟跑到104MHz，读吞吐能到50MB/s以上。对于大多数MCU应用，这个速度足够了。
但SPI NOR也有短板——写入和擦除慢。擦除一个64KB的扇区，通常要几百毫秒到几秒。所以它不适合频繁写数据的场景。
选型要点：
- 确认MCU是否支持Quad SPI或Dual SPI，这直接影响读性能
- 注意擦除时间参数，有些廉价Flash擦除时间能差3倍
- 如果做OTA升级，要选支持4KB小扇区擦除的型号，方便增量更新
4.3 SPI NAND Flash——大容量低成本的选择
当你的固件超过16MB，或者需要存文件系统、图片、日志数据时，SPI NAND就登场了。
SPI NAND的存储密度比NOR高得多，同样封装尺寸下，容量能大10倍以上。但代价是——它不能XIP。CPU必须先把代码从NAND读到RAM里，再从RAM执行。
这里有个坑，我踩过。有一次选了一颗SPI NAND做启动Flash，结果发现MCU的BootROM不支持从SPI NAND启动。最后不得不在前面加一颗小容量的SPI NOR做一级bootloader，再由它去初始化NAND并加载主固件。
注意：SPI NAND天生有坏块。出厂时就有0~2%的坏块率，使用过程中还会产生新的坏块。你的软件必须实现坏块管理（BBM）和ECC纠错。别指望硬件帮你做，SPI NAND的控制器通常只提供原始NAND接口。
什么时候用SPI NAND？
- 固件大于16MB，且MCU有足够RAM做代码拷贝
- 需要存储大量日志或媒体文件
- 成本敏感，NOR Flash太贵
4.4 Parallel NOR Flash——老将的坚守
Parallel NOR Flash，说白了就是传统意义上的NOR Flash，带并行地址总线和数据总线。现在新设计里用得少了，但在一些特定领域它还是不可替代的。
它的最大优势是随机访问速度极快。地址线直接映射到CPU的地址空间，读一个字节只需要几十纳秒。相比之下，SPI NOR要先发命令、地址，再等数据回来，延迟大得多。
我几年前维护过一个通信基站的控制板，用的就是Parallel NOR Flash。那板子对启动时间要求极其苛刻——上电后必须在50ms内完成自检并开始运行。SPI NOR的延迟根本满足不了，只能用Parallel NOR。
Parallel NOR的硬伤：
- 引脚太多，占PCB面积大
- 容量做不大，超过128MB就非常贵
- 新MCU很多已经不支持并行总线接口了
一句话总结：除非你的项目对启动时间有极端要求，或者你在维护老产品，否则新设计不建议上Parallel NOR。SPI NOR在绝大多数场景下可以替代它。
4.5 eMMC——大容量存储的集成方案
eMMC本质上是一个NAND Flash颗粒加上一个MMC控制器，封装在一起。控制器帮你处理了坏块管理、ECC、磨损均衡、垃圾回收这些脏活累活。
对于跑Linux或Android的系统，eMMC几乎是标配。容量从4GB起步，上到256GB都很常见。接口是标准的MMC/SD协议，8线并行，读写速度能到400MB/s以上。
但eMMC也有它的问题。最让我头疼的是——它内部有固件。不同厂商、不同批次的eMMC，内部行为可能有差异。我遇到过一批eMMC在高温下写入延迟突然增大，导致系统卡死。查了两个月，最后发现是eMMC内部在做垃圾回收。
我的建议：用eMMC时，一定要在系统层面做好超时处理和掉电保护。别指望eMMC的控制器能解决所有问题。另外，eMMC的启动流程比NOR复杂，需要MCU或SoC的BootROM支持MMC协议。
eMMC vs SPI NAND：
- eMMC省心，但贵，且受制于厂商固件
- SPI NAND便宜，但软件工作量翻倍
- 容量超过8GB，基本只能选eMMC
4.6 知识结构图：Flash选型决策流程
下面这张图是我自己总结的选型决策流程。每次做新项目，我都会走一遍这个逻辑。
4.7 实战中的选型建议
说了这么多，最后给几条实在的建议。这些是我在项目里反复验证过的。
我的推荐组合：
- MCU项目（固件 < 16MB）： SPI NOR Flash，首选Quad SPI型号。启动快，电路简单，调试方便。
- MCU项目（固件 > 16MB，有RAM）： SPI NOR做boot + SPI NAND做数据存储。两级方案，成本可控。
- Linux/Android项目： eMMC + SPI NOR（或SD卡）。eMMC跑系统，SPI NOR存bootloader。
- 极端可靠性要求： Parallel NOR或SPI NOR。没有坏块问题，不用操心ECC。
避坑指南：我曾经在一个项目里选了某品牌的SPI NAND，结果发现它的内部页大小是2KB+64B OOB，而我的文件系统只支持2KB页。虽然能用，但ECC校验位放不下，最后不得不改文件系统驱动。所以选NAND时，一定要确认页大小和OOB区域尺寸是否匹配你的软件栈。
嗯，Flash选型这块，说到底就是搞清楚你的系统到底需要什么。别盲目追新，也别死守老方案。把今天讲的这几个维度和决策流程走一遍，基本不会出大错。