刚入行时我第一次在原理图里看到“SD NAND”这个小封装第一反应是这不就是一颗能焊在板子上的 SD 卡吗可紧接着脑子里冒出一个很天真的问题——SD NAND 里面装的为什么是 NAND而不是 NOR这个疑问一点都不丢人我甚至觉得能问出这句话的初级工程师已经比那些拿到芯片就跑 demo 的人强了。因为这个问题背后藏着嵌入式存储选型最核心的一套逻辑接口协议怎么选介质、容量成本怎么限制方案、控制器到底在替谁干活。这篇文章就沿着这个问题往下挖把 NAND、NOR、SD 协议和控制器之间的角色关系一次讲透不讲厂商、不扯玄学只说原理和选择依据。1. 为什么初级工程师先认识 NOR反而觉得 NAND 陌生1.1 NOR 是很多 MCU 的“第一片 Flash”很多人的嵌入式启蒙板MCU 内部都集成了一小块 Flash用来存程序、存常量。这块内部 Flash 的本质就是 NOR 结构。为什么选 NOR因为 MCU 上电后需要直接取指执行NOR 支持随机字节访问低延迟可以被直接映射到 CPU 的地址空间里程序坐在 Flash 上就能跑起来这在行业里叫 XIP片上执行。后来板子上的代码不够放了外扩一颗 SPI NOR用四根线就能读写指令也直白发一个读命令、给个地址数据就从 MISO 上冒出来。对刚接触嵌入式的工程师来说NOR 实在是太“顺手”了。于是脑子里就形成了一个定势Flash 嘛就该是 NOR 这样的——能直接读、能放代码、擦写放心。1.2 NAND 给人的第一印象反而不太好NAND 在初级工程师的认知里往往是带着“负面标签”出场的不能按字节读、坏块要管理、写之前要先擦、还要做纠错。听着就麻烦。所以当有人推荐“用 SD NAND 存日志吧”很多人第一反应就是为什么不用 NORNOR 又稳定又简单NAND 一堆毛病。但现实很快打脸数据记录需要 128MB 容量NOR 能做到但价格和面积都高得离谱而且日志要持续写入NOR 的擦除时间长得让人崩溃。真正的问题不是“NAND 比 NOR 高级”而是 SD NAND 这个产品的本质决定了它必须用 NAND 而不是 NOR。要理解这一点得从存储单元的物理结构讲起。2. 并联和串联决定了命运NOR 随机读NAND 整页扛2.1 NOR 的每个存储单元都像一户单独开门的人家NOR 的存储阵列是把每一个存储单元并联在位线上。每个单元都有自己的接触孔字线负责选行位线直接连到每一列的单元上。读数据时选中一条字线这一行的所有单元同时和位线接通感应放大器立刻判断每个单元是导通还是截止从而读出“1”或“0”。这种结构带来一个天然优势可以随机访问任意字节。因为每一户人家门前都单独修了一条路你想敲哪家门直接过去就行不用惊动整条街。这也是 NOR 能 XIP 的物理基础——CPU 给一个地址存储器就能直接把对应位置的字节交出来。代价也很明显每个单元都要留出接触孔、拉开间距导致单元面积很大同工艺下单位面积能存的数据量比 NAND 少得多。NOR 的很多容量标称到现在还是 Mb 级别不是厂商不想做大是硬件结构撑不起大容量的成本和良率。2.2 NAND 的串型队列把密度做上去了NAND 的结构存储单元是一个接一个串在一根线上整串只有首尾两个选择晶体管分别连接位线和源线。你没法把串中间某个单元的“门”单独打开必须给整串加上电压然后通过感应一整页的电流状态来读出数据。换句话说NAND 的数据进出天然是以“页”为单位的常见一页 4KB 到 16KB 甚至更大。读一页先整页搬进芯片内部的页缓冲器再从缓冲器按顺序吐出来。写也是一样一次只能编程一整页而且写之前还得先把所在的块擦除干净。打个比方NOR 是每家一条独立电线NAND 是一整串彩灯你要查某一盏灯的亮度得把整串灯一起点亮再看。好处是省线、省空间坏处就是没法精准操作单个单元。但省下的空间换来了极高的存储密度大容量存储市场几乎全被 NAND 家族占据。2.3 一张表看清两个存储家族的底细对比项NORNAND单元连接方式并联串联最小读粒度字节/字可随机访问页通常 4KB 起最小写粒度字节/字但写前需擦除页最小擦除粒度扇区/块通常 4KB 以上块通常包含几十到几百页擦除时间典型几十毫秒到上百毫秒典型几毫秒量级单元密度低同工艺下面积大高适合大容量是否支持 XIP支持可直接执行代码不支持需要 ECC 强度低高常见容量1Mb 到 512Mb 为主128Mb 到数 Tb很多初级工程师纠结于“NOR 寿命长、NAND 寿命短”但这只是其中一个维度。更关键的是闪存控制器可以通过磨损均衡把 NAND 的寿命摊到全部块上而 NOR 的大扇区擦除在频繁写小数据的场景里反而很吃亏。寿命之外擦除速度、写吞吐和成本才是 SD 这种场景真正看重的指标。3. SD 协议天生是“块设备协议”不是字节总线协议3.1 SD 命令集里压根没有“读某个字节”这种操作理解 SD NAND 为什么装 NAND必须先搞明白 SD 协议本身是什么样的。SD 协议从设计之初就是块设备协议主机发一条读命令带上块号卡返回一整块数据发一条写命令主机把一整块数据交给卡。这个“块”通常是 512 字节对应 SD 规范里的标准扇区大小。如果看具体命令读单个块用 CMD17读多个块用 CMD18写单个块用 CMD24写多个块用 CMD25。这里面的地址指的是“第几个块”而不是“第几个字节”。主机从来没有机会从 SD 卡里读一个字节——即使它只想看一个字节也得先拿到整块 512 字节的数据再从内存里取那一位。这意味着什么意味着 SD 协议对介质的要求是“能按块高效读写”而不是“能按字节随机访问”。NAND 的页读写特性跟 SD 协议的块操作天然匹配而 NOR 最引以为傲的随机字节读能力在 SD 协议这层根本接不上电。3.2 控制器把逻辑块映射进 NAND 页用户完全无感SD NAND 内部其实有两部分一颗 NAND 闪存die一个控制器。控制器对外提供 SD 协议接口对内负责把主机的逻辑块号翻译成 NAND 的物理页号。主机发“写第 100 块”控制器查一层逻辑到物理的映射表找到对应物理页然后执行 NAND 的页编程操作。这套流程之所以能跑得顺靠的就是 NAND 的页大小和 SD 块读写粒度能互相折算。虽然 SD 的一块是 512 字节NAND 一页是好几 KB但控制器可以把一个逻辑块簇攒够之后再写进一页也能在做读操作时把整页读出来再按块返回给主机。整个过程中用户看到的只是“能按块读写的卡”NAND 的擦除、页缓冲、坏块替换全是幕后工作。把这个映射逻辑反向应用到 NOR 上就成了一个笑话NOR 明明支持字节随机读可 SD 协议不会把“随机读字节”的指令传下去主机只会按块读。NOR 的随机访问优势被 SD 协议这堵墙完全挡在外面用户花了大价钱买的“随机读能力”在 SD 场景里根本用不上。3.3 “能启动”不等于 XIP说明 NOR 的看家本领在这里无处施展也有工程师问SD NAND 不是也能做启动吗那它是不是也得像 NOR 一样能被 CPU 直接执行这里有一个常见误解。SD 卡启动的流程通常是这样的芯片内部的 boot ROM 先通过 SD 协议按块读取启动代码放到芯片内部的 SRAM 或 DDR 里然后 CPU 从 RAM 开始执行。后续的应用代码也是由这段引导程序从卡里搬进内存再跳转运行。整个过程CPU 始终没有从 SD 卡里直接取指。原因很简单SD 协议本身就没有把存储介质映射进 CPU 地址总线的机制它对外只提供块读写命令。即使 SD 卡里面装的是一颗 NOR除非卡内部控制器专门做一个“把随机读翻译成块地址再读出来”的转换否则 CPU 也无法直接在卡里执行代码。更关键的是真的把 NOR 塞进去为了获得 SD 接口还得再经过控制器绕一大圈后 XIP 依然不成立NOR 最后一块遮羞布也没了。4. 容量、成本、写速度算完账就明白没人做“NOR 型 SD 卡”4.1 同容量下 die 面积差距是绕不开的成本墙存储芯片的价格很大程度由 die 面积决定。同样一片晶圆能切出多少颗合格芯片直接决定每颗芯片的边际成本。NOR 因为每个单元都要独立接触孔单元间距大同样容量下 die 面积可能比 NAND 大好几倍。放到大容量时这个差距会被进一步放大。举个例子做一颗 256MB 的 NOR 和一颗 256MB 的 NAND前者在工艺、面积、良率上全面吃亏成本可能差出数倍甚至一个数量级。这也是为什么市面上大容量 NOR 屈指可数、价格高得离谱而 NAND 可以轻松做到几十 GB、上百 GB 还保持低单价。SD 卡这个产品类别的容量基线是多少照片、视频、日志文件随便就是 GB 级。哪怕是最“抠搜”的 SD NAND 方案容量也常在 64MB 到 128MB 起步。用 NOR 去满足这样的容量需求成本和面积直接劝退方案根本立不起来。4.2 写日志场景的实测对比擦除等待最要命我调过一个数据记录仪要求每秒钟追加写几 KB 数据写到一张“SD 卡”里。如果这块存储是 NOR每次写入前的擦除是大麻烦。NOR 不能原地把某一位从“1”改成“0”得先把整个擦除块恢复成“1”然后再向该改的位置写入“0”。擦除一块要几十毫秒到上百毫秒是常态频繁小写入会让系统反复卡在擦除等待上实时性根本保不住。换到 SD NAND 后情况完全不同。NAND 内部也是先擦后写但擦除一个块的时间通常在毫秒量级而且页编程一顿操作猛如虎连续多块写起来吞吐量能到几十 MB/s。日志系统用文件系统组件直接 f_write无需关心擦除对齐控制器内部自己拆页、自己擦块、自己做坏块替换。实测下来同样数据量的日志写入SD NAND 的耗时是 NOR 方案的零头。读方向当然也要提一句NOR 的随机读延迟确实低但 SD 应用里主机读文件往往是成块地读NAND 把整页读进缓冲后再流水线输出顺序读吞吐反而更高。反正 SD 协议拿到的是块用户关心的也是“一次读多少数据”不是“第一个字节多快出来”。4.3 真的有人做过“NOR 型 SD 卡”吗两头不讨好理论上当然可以做把 NOR 封装成 SD 卡的样子控制器负责把块读写转换成 NOR 的字节随机读写。但这个产品会同时踩中两个坑。容量做小了用户直接用 SPI NOR 更便宜、更简单不需要 SD 接口绕路容量做大NOR 的成本和面积又撑不住。SD 接口增加的控制器、协议开销、电源管理对 NOR 来说全是额外负担。所以现实世界里你会发现 SD 卡、SD NAND、eMMC 这些块存储设备介质清一色全是 NAND。这不是偶然是成本、容量、协议匹配度共同逼出来的必然选择。一个问题想明白就够了SD 生态从诞生起就是围绕“能按块快速读写的大容量介质”设计的而 NAND 就是那个介质。5. SD NAND 真正的核心是控制器NAND 是它最合理的“供应商”5.1 控制器替主控扛走了坏块、纠错和磨损均衡很多初级工程师以为 SD NAND 就是一个 SD 接口的 NAND其实不对。SD NAND 应该理解成“NAND die 管理控制器”的复合体NAND 只是肚子里装的货控制器才是真正干活的。NAND 天生不完美有瑕疵坏块、会位翻转、擦写多了会磨损、掉电可能丢页。这些问题如果裸着用全要主控承担。但 SD NAND 的控制器把这些都包了上电扫描坏块、维护坏块表、写数据做 ECC 校验、读数据纠错、动态加静态磨损均衡、掉电时保存映射表。用户往文件系统里 f_write 一个文件控制器在后面默默完成了不知道多少操作。这正好回答了一个更深层的问题为什么 SD 控制器更喜欢配 NAND因为 NAND 到处都是需要管理的地方控制器的价值才能最大化。如果用 NOR坏块管理几乎不用做、ECC 强度要求低、磨损压力也小控制器反而变成了一身本领没处使的摆设还得赔上接口转换的损耗。5.2 代码量对比裸 NAND 写 FTLSD NAND 直接开文件我最喜欢用代码量来给初级工程师直观感受这二者差别。如果用一颗裸 NAND 存数据主控这边要做的有写 NAND 驱动、扫坏块、维护坏块映射表、实现地址转换把文件系统的逻辑块映射到物理页、处理擦写均衡、嵌入 ECC 计算与校验。这一套自己从零写没有几个月调不顺手中间踩的坑一个接一个。换成 SD NAND主控只需要 SD 协议层的驱动——SDIO 或 SPI 模式都行——然后直接挂一个现成的 FAT 文件系统。打开文件、写数据、关闭文件整套流程跟操作电脑上的 U 盘没什么区别。坏块、磨损、ECC 全部封装在芯片里主控代码量少得可怜。如果你正在一个 MCU 项目里纠结“要不要用 SD NAND”先想想自己手里有没有写 FTL 的人力。没有的话SD NAND 几乎是把 NAND 用起来的唯一省心方式因为控制器已经在里面替你把最苦的活干完了。5.3 选型判断速成方法问两个问题就够那是不是意味着 NOR 就该彻底淘汰了当然不是。给大家一个特别实在的选择标准第一个问题你的代码需不需要从这块存储里直接执行、上电就拿 PC 指针去取指如果是选 NOR或者干脆用 MCU 内部 Flash这是 NAND 和 SD NAND 都给不了的。第二个问题你的数据容量是不是明显超过 32MB、需要文件系统、还需要持续写入日志或固件升级文件如果是就别折腾 NOR 了SD NAND 或者同类的 eMMC 才是正路。SD NAND 的优势是引脚少、走 SDIO/SPI、适合低引脚 MCUeMMC 容量更大、并行接口但引脚和主机要求也更高。还想再补一句选 SD NAND 的时候也别拿烧 NOR 的心态去测它。它不是“NAND 的一种”而是“插在板子上的小硬盘”评价它要看连续读写、磨损均衡、掉电保护这些指标而不是拿字节随机读的眼镜去挑毛病。最后聊点实际体感。我后来做某数据记录仪项目的存储升级时就是把日志从 SPI NOR 迁到了 SD NAND主控代码只换了 SD 驱动那一层上层文件操作几乎原样保留容量却从 16MB 跳到了 128MB写日志再也不被擦除时间卡脖子。在这个项目里我彻底想明白了一件事SD NAND 装 NAND 不装 NOR不是因为 NAND 更“高级”而是 SD 协议的块接口、大容量需求、写吞吐预期和 NAND 的物理特性刚好严丝合缝。NOR 呢在启动、随机读、低容量这些主场里依然是不可替代的角色。技术选型从来没有“谁取代谁”只有把合适的介质放到合适的接口后面。 
长河君 · 2026/10/13 1:01:13 · 阅读 1.2k SD NAND为什么用NAND而不用NOR？从原理到选型一次讲透
刚入行时我第一次在原理图里看到“SD NAND”这个小封装第一反应是这不就是一颗能焊在板子上的 SD 卡吗可紧接着脑子里冒出一个很天真的问题——SD NAND 里面装的为什么是 NAND而不是 NOR这个疑问一点都不丢人我甚至觉得能问出这句话的初级工程师已经比那些拿到芯片就跑 demo 的人强了。因为这个问题背后藏着嵌入式存储选型最核心的一套逻辑接口协议怎么选介质、容量成本怎么限制方案、控制器到底在替谁干活。这篇文章就沿着这个问题往下挖把 NAND、NOR、SD 协议和控制器之间的角色关系一次讲透不讲厂商、不扯玄学只说原理和选择依据。1. 为什么初级工程师先认识 NOR反而觉得 NAND 陌生1.1 NOR 是很多 MCU 的“第一片 Flash”很多人的嵌入式启蒙板MCU 内部都集成了一小块 Flash用来存程序、存常量。这块内部 Flash 的本质就是 NOR 结构。为什么选 NOR因为 MCU 上电后需要直接取指执行NOR 支持随机字节访问低延迟可以被直接映射到 CPU 的地址空间里程序坐在 Flash 上就能跑起来这在行业里叫 XIP片上执行。后来板子上的代码不够放了外扩一颗 SPI NOR用四根线就能读写指令也直白发一个读命令、给个地址数据就从 MISO 上冒出来。对刚接触嵌入式的工程师来说NOR 实在是太“顺手”了。于是脑子里就形成了一个定势Flash 嘛就该是 NOR 这样的——能直接读、能放代码、擦写放心。1.2 NAND 给人的第一印象反而不太好NAND 在初级工程师的认知里往往是带着“负面标签”出场的不能按字节读、坏块要管理、写之前要先擦、还要做纠错。听着就麻烦。所以当有人推荐“用 SD NAND 存日志吧”很多人第一反应就是为什么不用 NORNOR 又稳定又简单NAND 一堆毛病。但现实很快打脸数据记录需要 128MB 容量NOR 能做到但价格和面积都高得离谱而且日志要持续写入NOR 的擦除时间长得让人崩溃。真正的问题不是“NAND 比 NOR 高级”而是 SD NAND 这个产品的本质决定了它必须用 NAND 而不是 NOR。要理解这一点得从存储单元的物理结构讲起。2. 并联和串联决定了命运NOR 随机读NAND 整页扛2.1 NOR 的每个存储单元都像一户单独开门的人家NOR 的存储阵列是把每一个存储单元并联在位线上。每个单元都有自己的接触孔字线负责选行位线直接连到每一列的单元上。读数据时选中一条字线这一行的所有单元同时和位线接通感应放大器立刻判断每个单元是导通还是截止从而读出“1”或“0”。这种结构带来一个天然优势可以随机访问任意字节。因为每一户人家门前都单独修了一条路你想敲哪家门直接过去就行不用惊动整条街。这也是 NOR 能 XIP 的物理基础——CPU 给一个地址存储器就能直接把对应位置的字节交出来。代价也很明显每个单元都要留出接触孔、拉开间距导致单元面积很大同工艺下单位面积能存的数据量比 NAND 少得多。NOR 的很多容量标称到现在还是 Mb 级别不是厂商不想做大是硬件结构撑不起大容量的成本和良率。2.2 NAND 的串型队列把密度做上去了NAND 的结构存储单元是一个接一个串在一根线上整串只有首尾两个选择晶体管分别连接位线和源线。你没法把串中间某个单元的“门”单独打开必须给整串加上电压然后通过感应一整页的电流状态来读出数据。换句话说NAND 的数据进出天然是以“页”为单位的常见一页 4KB 到 16KB 甚至更大。读一页先整页搬进芯片内部的页缓冲器再从缓冲器按顺序吐出来。写也是一样一次只能编程一整页而且写之前还得先把所在的块擦除干净。打个比方NOR 是每家一条独立电线NAND 是一整串彩灯你要查某一盏灯的亮度得把整串灯一起点亮再看。好处是省线、省空间坏处就是没法精准操作单个单元。但省下的空间换来了极高的存储密度大容量存储市场几乎全被 NAND 家族占据。2.3 一张表看清两个存储家族的底细对比项NORNAND单元连接方式并联串联最小读粒度字节/字可随机访问页通常 4KB 起最小写粒度字节/字但写前需擦除页最小擦除粒度扇区/块通常 4KB 以上块通常包含几十到几百页擦除时间典型几十毫秒到上百毫秒典型几毫秒量级单元密度低同工艺下面积大高适合大容量是否支持 XIP支持可直接执行代码不支持需要 ECC 强度低高常见容量1Mb 到 512Mb 为主128Mb 到数 Tb很多初级工程师纠结于“NOR 寿命长、NAND 寿命短”但这只是其中一个维度。更关键的是闪存控制器可以通过磨损均衡把 NAND 的寿命摊到全部块上而 NOR 的大扇区擦除在频繁写小数据的场景里反而很吃亏。寿命之外擦除速度、写吞吐和成本才是 SD 这种场景真正看重的指标。3. SD 协议天生是“块设备协议”不是字节总线协议3.1 SD 命令集里压根没有“读某个字节”这种操作理解 SD NAND 为什么装 NAND必须先搞明白 SD 协议本身是什么样的。SD 协议从设计之初就是块设备协议主机发一条读命令带上块号卡返回一整块数据发一条写命令主机把一整块数据交给卡。这个“块”通常是 512 字节对应 SD 规范里的标准扇区大小。如果看具体命令读单个块用 CMD17读多个块用 CMD18写单个块用 CMD24写多个块用 CMD25。这里面的地址指的是“第几个块”而不是“第几个字节”。主机从来没有机会从 SD 卡里读一个字节——即使它只想看一个字节也得先拿到整块 512 字节的数据再从内存里取那一位。这意味着什么意味着 SD 协议对介质的要求是“能按块高效读写”而不是“能按字节随机访问”。NAND 的页读写特性跟 SD 协议的块操作天然匹配而 NOR 最引以为傲的随机字节读能力在 SD 协议这层根本接不上电。3.2 控制器把逻辑块映射进 NAND 页用户完全无感SD NAND 内部其实有两部分一颗 NAND 闪存die一个控制器。控制器对外提供 SD 协议接口对内负责把主机的逻辑块号翻译成 NAND 的物理页号。主机发“写第 100 块”控制器查一层逻辑到物理的映射表找到对应物理页然后执行 NAND 的页编程操作。这套流程之所以能跑得顺靠的就是 NAND 的页大小和 SD 块读写粒度能互相折算。虽然 SD 的一块是 512 字节NAND 一页是好几 KB但控制器可以把一个逻辑块簇攒够之后再写进一页也能在做读操作时把整页读出来再按块返回给主机。整个过程中用户看到的只是“能按块读写的卡”NAND 的擦除、页缓冲、坏块替换全是幕后工作。把这个映射逻辑反向应用到 NOR 上就成了一个笑话NOR 明明支持字节随机读可 SD 协议不会把“随机读字节”的指令传下去主机只会按块读。NOR 的随机访问优势被 SD 协议这堵墙完全挡在外面用户花了大价钱买的“随机读能力”在 SD 场景里根本用不上。3.3 “能启动”不等于 XIP说明 NOR 的看家本领在这里无处施展也有工程师问SD NAND 不是也能做启动吗那它是不是也得像 NOR 一样能被 CPU 直接执行这里有一个常见误解。SD 卡启动的流程通常是这样的芯片内部的 boot ROM 先通过 SD 协议按块读取启动代码放到芯片内部的 SRAM 或 DDR 里然后 CPU 从 RAM 开始执行。后续的应用代码也是由这段引导程序从卡里搬进内存再跳转运行。整个过程CPU 始终没有从 SD 卡里直接取指。原因很简单SD 协议本身就没有把存储介质映射进 CPU 地址总线的机制它对外只提供块读写命令。即使 SD 卡里面装的是一颗 NOR除非卡内部控制器专门做一个“把随机读翻译成块地址再读出来”的转换否则 CPU 也无法直接在卡里执行代码。更关键的是真的把 NOR 塞进去为了获得 SD 接口还得再经过控制器绕一大圈后 XIP 依然不成立NOR 最后一块遮羞布也没了。4. 容量、成本、写速度算完账就明白没人做“NOR 型 SD 卡”4.1 同容量下 die 面积差距是绕不开的成本墙存储芯片的价格很大程度由 die 面积决定。同样一片晶圆能切出多少颗合格芯片直接决定每颗芯片的边际成本。NOR 因为每个单元都要独立接触孔单元间距大同样容量下 die 面积可能比 NAND 大好几倍。放到大容量时这个差距会被进一步放大。举个例子做一颗 256MB 的 NOR 和一颗 256MB 的 NAND前者在工艺、面积、良率上全面吃亏成本可能差出数倍甚至一个数量级。这也是为什么市面上大容量 NOR 屈指可数、价格高得离谱而 NAND 可以轻松做到几十 GB、上百 GB 还保持低单价。SD 卡这个产品类别的容量基线是多少照片、视频、日志文件随便就是 GB 级。哪怕是最“抠搜”的 SD NAND 方案容量也常在 64MB 到 128MB 起步。用 NOR 去满足这样的容量需求成本和面积直接劝退方案根本立不起来。4.2 写日志场景的实测对比擦除等待最要命我调过一个数据记录仪要求每秒钟追加写几 KB 数据写到一张“SD 卡”里。如果这块存储是 NOR每次写入前的擦除是大麻烦。NOR 不能原地把某一位从“1”改成“0”得先把整个擦除块恢复成“1”然后再向该改的位置写入“0”。擦除一块要几十毫秒到上百毫秒是常态频繁小写入会让系统反复卡在擦除等待上实时性根本保不住。换到 SD NAND 后情况完全不同。NAND 内部也是先擦后写但擦除一个块的时间通常在毫秒量级而且页编程一顿操作猛如虎连续多块写起来吞吐量能到几十 MB/s。日志系统用文件系统组件直接 f_write无需关心擦除对齐控制器内部自己拆页、自己擦块、自己做坏块替换。实测下来同样数据量的日志写入SD NAND 的耗时是 NOR 方案的零头。读方向当然也要提一句NOR 的随机读延迟确实低但 SD 应用里主机读文件往往是成块地读NAND 把整页读进缓冲后再流水线输出顺序读吞吐反而更高。反正 SD 协议拿到的是块用户关心的也是“一次读多少数据”不是“第一个字节多快出来”。4.3 真的有人做过“NOR 型 SD 卡”吗两头不讨好理论上当然可以做把 NOR 封装成 SD 卡的样子控制器负责把块读写转换成 NOR 的字节随机读写。但这个产品会同时踩中两个坑。容量做小了用户直接用 SPI NOR 更便宜、更简单不需要 SD 接口绕路容量做大NOR 的成本和面积又撑不住。SD 接口增加的控制器、协议开销、电源管理对 NOR 来说全是额外负担。所以现实世界里你会发现 SD 卡、SD NAND、eMMC 这些块存储设备介质清一色全是 NAND。这不是偶然是成本、容量、协议匹配度共同逼出来的必然选择。一个问题想明白就够了SD 生态从诞生起就是围绕“能按块快速读写的大容量介质”设计的而 NAND 就是那个介质。5. SD NAND 真正的核心是控制器NAND 是它最合理的“供应商”5.1 控制器替主控扛走了坏块、纠错和磨损均衡很多初级工程师以为 SD NAND 就是一个 SD 接口的 NAND其实不对。SD NAND 应该理解成“NAND die 管理控制器”的复合体NAND 只是肚子里装的货控制器才是真正干活的。NAND 天生不完美有瑕疵坏块、会位翻转、擦写多了会磨损、掉电可能丢页。这些问题如果裸着用全要主控承担。但 SD NAND 的控制器把这些都包了上电扫描坏块、维护坏块表、写数据做 ECC 校验、读数据纠错、动态加静态磨损均衡、掉电时保存映射表。用户往文件系统里 f_write 一个文件控制器在后面默默完成了不知道多少操作。这正好回答了一个更深层的问题为什么 SD 控制器更喜欢配 NAND因为 NAND 到处都是需要管理的地方控制器的价值才能最大化。如果用 NOR坏块管理几乎不用做、ECC 强度要求低、磨损压力也小控制器反而变成了一身本领没处使的摆设还得赔上接口转换的损耗。5.2 代码量对比裸 NAND 写 FTLSD NAND 直接开文件我最喜欢用代码量来给初级工程师直观感受这二者差别。如果用一颗裸 NAND 存数据主控这边要做的有写 NAND 驱动、扫坏块、维护坏块映射表、实现地址转换把文件系统的逻辑块映射到物理页、处理擦写均衡、嵌入 ECC 计算与校验。这一套自己从零写没有几个月调不顺手中间踩的坑一个接一个。换成 SD NAND主控只需要 SD 协议层的驱动——SDIO 或 SPI 模式都行——然后直接挂一个现成的 FAT 文件系统。打开文件、写数据、关闭文件整套流程跟操作电脑上的 U 盘没什么区别。坏块、磨损、ECC 全部封装在芯片里主控代码量少得可怜。如果你正在一个 MCU 项目里纠结“要不要用 SD NAND”先想想自己手里有没有写 FTL 的人力。没有的话SD NAND 几乎是把 NAND 用起来的唯一省心方式因为控制器已经在里面替你把最苦的活干完了。5.3 选型判断速成方法问两个问题就够那是不是意味着 NOR 就该彻底淘汰了当然不是。给大家一个特别实在的选择标准第一个问题你的代码需不需要从这块存储里直接执行、上电就拿 PC 指针去取指如果是选 NOR或者干脆用 MCU 内部 Flash这是 NAND 和 SD NAND 都给不了的。第二个问题你的数据容量是不是明显超过 32MB、需要文件系统、还需要持续写入日志或固件升级文件如果是就别折腾 NOR 了SD NAND 或者同类的 eMMC 才是正路。SD NAND 的优势是引脚少、走 SDIO/SPI、适合低引脚 MCUeMMC 容量更大、并行接口但引脚和主机要求也更高。还想再补一句选 SD NAND 的时候也别拿烧 NOR 的心态去测它。它不是“NAND 的一种”而是“插在板子上的小硬盘”评价它要看连续读写、磨损均衡、掉电保护这些指标而不是拿字节随机读的眼镜去挑毛病。最后聊点实际体感。我后来做某数据记录仪项目的存储升级时就是把日志从 SPI NOR 迁到了 SD NAND主控代码只换了 SD 驱动那一层上层文件操作几乎原样保留容量却从 16MB 跳到了 128MB写日志再也不被擦除时间卡脖子。在这个项目里我彻底想明白了一件事SD NAND 装 NAND 不装 NOR不是因为 NAND 更“高级”而是 SD 协议的块接口、大容量需求、写吞吐预期和 NAND 的物理特性刚好严丝合缝。NOR 呢在启动、随机读、低容量这些主场里依然是不可替代的角色。技术选型从来没有“谁取代谁”只有把合适的介质放到合适的接口后面。