同样都是NAND，为什么有些要写驱动、有些SDNAND不用？

做嵌入式开发的工程师应该都遇到过这种事：项目里要用一颗NAND Flash，结果翻开数据手册一看，不仅要写SPI驱动，还得自己搞定坏块管理、ECC纠错、磨损均衡……一套搞下来，少说两周，多则两三个月。

但有的项目就不一样。直接拿主控芯片自带的SD卡驱动，两天就跑通了。

都是NAND闪存，差别怎么这么大？

问题出在“谁来做管理”

NAND闪存这东西有个特点——它会坏。出厂时就可能有坏块，用着用着还会产生新的。写入的时候电子会跑偏，读出来的数据可能有错。有些区域被反复擦写，老得快；有些长期不用，相对年轻。

这些问题都得有人来处理。谁来处理？有两种思路。

第一种是芯片自己管。坏块管理、ECC纠错、磨损均衡这些复杂工作，全部交给芯片内部的控制器。主控只需要发简单的读写命令，剩下的不用操心。

第二种是主控来管。芯片只提供最基本的读写接口，所有管理逻辑都由主控MCU的软件来实现。主控得记住哪个块是好的、哪个块坏了，得自己算ECC，自己均衡擦写次数。

SD NAND和SPI NAND的区别，说白了就是这里。

SD NAND：芯片自带“管家”

SD NAND内部集成了一个完整的控制器。你可以把它理解成芯片自带的“管家”。

这个管家管的事情不少：

坏块管理：出厂时的坏块、使用中产生的新坏块，管家自己标记、自己绕过去，主控完全不用知道。

ECC纠错：数据写入时自动生成校验码，读取时自动检查纠错，主控只管发命令。

磨损均衡：自动把写入操作分散到各个存储块，让所有块用得差不多久。

地址映射：主控用逻辑地址访问，管家把它转成物理地址。

对外提供的是标准SD接口，主控芯片本来就带SD卡驱动。所以拿到SD NAND，直接调现成的驱动就能用，跟操作TF卡一样简单。

米客方德的客户里，用STM32、GD32、NXP这些主控的，直接用HAL库的SDIO驱动，配一下引脚和时钟，挂上FATFS文件系统，两天就搞定了。不用写任何NAND底层代码。

SPI NAND：芯片给的是“工具箱”

SPI NAND走的是另一条路。它内部也有控制器，但功能相对基础——主要负责把SPI协议转成NAND操作指令，同时提供硬件级的ECC加速。坏块管理、磨损均衡这些更上层的逻辑，留给主控自己决定怎么实现。

这种设计也有它的道理。对于跑Linux系统的设备，内核里已经有成熟的MTD（Memory Technology Device）子系统，专门用来管理NAND闪存。坏块管理、磨损均衡这些功能，MTD层都帮你做好了。工程师只需要把底层的SPI驱动调通，上层用UBIFS这类文件系统就行。

所以SPI NAND更适合那些主控性能强、跑Linux/RTOS、开发团队有存储经验的项目。这类团队往往希望把存储管理的控制权掌握在自己手里，可以根据具体应用场景灵活调整算法参数。

从成本角度看，SPI NAND的芯片单价确实更低。对于那些年产量大、对BOM成本敏感的产品，这笔差价会很明显。

两种方案怎么选？

回到开头的问题：都是NAND，为什么有的要写驱动、有的不用？

答案已经清楚了。SD NAND把复杂的管理工作封装在芯片内部，用硬件替你做了。SPI NAND把部分管理工作留给主控，让有经验的团队自己把控。

两种方案各有各的适用场景：

SD NAND更适合这些情况：

MCU资源有限（单片机、Cortex-M系列）

项目周期紧，不想在存储驱动上花太多时间

团队没有专门的存储工程师

希望像用TF卡一样简单省心

米客方德的客户里，很多是做工业HMI、车载T-BOX、智能穿戴的，他们选SD NAND的原因很简单：不想在存储这件事上折腾，把精力留给产品本身。

SPI NAND更适合这些情况：

系统跑Linux/RTOS，有成熟的NAND管理框架

团队有存储底层开发经验

对BOM成本非常敏感，愿意用软件工作量换硬件成本

需要灵活控制存储管理策略

两种方案没有绝对的好坏，关键看项目情况。SD NAND省心省力，SPI NAND灵活可控。选哪个，取决于你的团队、项目周期和成本结构。

审核编辑 黄宇