尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
SD NAND为何内置NAND Flash?NOR与NAND选型核心解析
有次评审新来的存储选型方案A同学指着板子上的SD NAND问我这里面的die是NAND Flash而不是NOR Flash为什么我当时一愣因为这问题看似基础其实已经摸到了嵌入式存储选型最核心的门槛。他自己又补了一句网上说NOR能字节随机读还能直接执行代码是不是更可靠我当时没有直接给答案而是让他把NAND和NOR从物理结构到接口协议各自捋了一遍后面整整聊了一个小时。这篇文章就是那次讨论的完整梳理适合刚接触嵌入式存储、总在NOR和NAND之间纠结的初级工程师。读完你至少能搞明白三件事SD NAND为什么天然应该装NANDNOR的强项到底是什么以及以后选型时从哪几个问题入手才不会拍脑袋。1. 名字里藏着答案SD和NAND是两回事1.1 从一颗焊在板子上的存储芯片说起先拆名字。SD NAND严格说是一个封装好的存储系统一颗NAND Flash die负责数据存储一颗控制器die负责协议解析、坏块管理和数据纠错两者合封在一个很小的贴片封装里常见的有WSON-8、LGA-8这类外形。它对外只暴露SDIO或者SPI接口主控芯片不需要知道NAND内部复杂的操作细节发几条标准SD命令就能像操作SD卡一样读写。很多初级工程师的第一反应是SD NAND就是把TF卡去掉外壳焊在PCB上这个说法方向对但不完全准确。SD卡是一个可插拔的模块里面有卡控制器、NAND die、连接器还要考虑插拔和机械强度SD NAND没有连接器直接贴装在PCB上面积更小、抗震动更好容量的跨度也可以很大从百兆级别到几十GB都有。它的目标场景非常明确主控MCU需要大容量非易失存储但板子上不想放一个SD卡座也不想自己写NAND控制器的底层驱动。这个概念先建立起来后面很多问题都好解释。因为当一颗芯片内部同时存在存储介质和控制器时介质选NAND还是NOR就不再是单纯比较两种Flash芯片的性能而是要看这个形态最终要扮演什么角色。SD NAND的角色是数据块设备这个定位几乎决定了介质只能选NAND。1.2 初级工程师最常问的两个问题我在带人过程中这两个问题出现频率最高。第一个NOR Flash能字节随机读还能在片上直接执行代码为什么SD NAND里偏偏不用NOR市面上又不是没有SPI NOR这种便宜好用的东西。第二个NAND不是有坏块、要ECC纠错、寿命还短吗把数据放在这里面靠谱吗这两个问题的共同根源是把存储介质的能力和产品形态需要的能力混在了一起。NOR确实是优秀的存储介质但它优秀的方向是小容量、随机读、代码执行这些能力在SD NAND这个产品形态里几乎用不上。NAND确实有一堆需要管理的麻烦事但SD NAND内部那颗控制器存在的意义就是把这些麻烦事全部挡在芯片内部让外面的MCU只看到一个又大又便宜、按扇区读写的块设备。所以与其问为什么不用NOR不如换个角度问一个需要大容量、频繁写、带文件系统的数据存储场景最适合的介质是什么答案基本只有NAND。后续章节我会把物理结构、控制器职责、接口约束三条线分别展开最后你会得到一套完整的判断链。1.3 别再把接口和介质混为一谈还有一个容易踩的认知误区就是把SD NAND理解成NAND的一种新封装好像它和NAND是同类东西。其实SD NAND是接口形态和控制器层面的整合介质层才是NAND。打个比方一个USB移动硬盘外壳上写着USB 3.0里面装的是机械盘还是固态盘完全取决于产品定位USB接口本身并不关心盘片种类。SD NAND同理SD是协议层负责和主控对话NAND是介质层负责真正存数据控制器则是中间的翻译官。既然SD NAND对外是块设备协议它就需要一种适合块设备场景的介质。NAND那种按页读写、按块擦除、顺序带宽高、单bit成本低的特性和块设备简直是绝配。NOR如果硬要套SD协议等于让一个擅长查字典的人去当搬运工不是不能干但一定干得又慢又贵。接口和介质拆开看很多选型争议立刻变清晰。2. 存储单元的物理结构NAND和NOR的性价比分水岭2.1 并联与串联一字之差天壤之别NOR这个名字来自Not OR的缩写它的存储单元阵列在电气上更像一种并联结构。每个单元的源极和漏极直接挂在位线与地之间译码电路选中某条字线后对应单元的状态能很快反映到位线上。所以NOR支持按字节随机读取读一个地址的速度非常快这也是当年BIOS、片外程序能用NOR直接执行的根本原因——CPU可以像访问普通存储器那样去NOR里取指令。NAND则是另一种玩法几十个存储单元串联成一串串的两端通过选择管接到位线上整体更像串联电路。想读取其中某一个cell必须让同一串里的其他cell都处于导通状态最终把目标cell的状态串出来。这样一来NAND就很难做到字节级随机读。它的数据访问天然按页进行读一页、写一页擦除则要按更大的块来操作。一句话记忆NOR的每个cell都有独立通道通向位线像每家每户都有独立门牌号NAND的cell们手拉手排成一队要检查第N个人的状态必须让前面所有人都保持配合。这个物理结构上的差异从根上决定了两种Flash完全不同的性格。比较项目NOR FlashNAND Flash读取粒度可按字节/字随机读按页读常见2KB、4KB、16KB等随机读取延迟较低接近内存寻址风格较高必须先把整个页读入缓存写入粒度字节/字级编程覆盖前要擦除页编程擦除粒度块擦除常见64KB~128KB块擦除块的体积通常更大顺序写带宽低写入慢高适合批量写入容量天花板小容量为主大容量很贵大容量且单位成本低管理复杂度低基本不需要FTL高需要坏块管理、ECC、FTL2.2 写入和擦除为什么差这么多NOR和NAND在写入速度上的差距直接来自编程物理机制的不同。NOR编程主要靠沟道热电子注入漏极加较高电压让电子获得足够能量后挤进浮栅这个过程电流大、功耗高速度自然慢。NAND编程靠FN隧穿电子在强电场作用下以隧穿方式穿过氧化层进入浮栅功耗低而且适合整页整页批量编程所以NAND的写入带宽通常远高于NOR。擦除同样差很多。两者擦除都依赖隧穿效应但NOR因为单元结构和译码电路更复杂擦除一块需要的时间往往到百毫秒甚至秒级NAND的块结构更规整擦除速度相对快而且控制器可以通过FTL层把擦除操作分散到后台用户不太容易感知到必须先擦除再写的过程。这里要特别提醒初级工程师无论NOR还是NAND都不能像SRAM那样随意覆盖写。NOR的编程只能把bit从1写成0想恢复成1就必须擦除NAND的页编程也一样覆盖写之前必须保证页所在的块是干净状态否则要先把有用数据搬出来再擦除再写回。所以裸NAND用起来非常别扭这也是为什么它必须搭配控制器的另一个重要原因。2.3 容量和成本这盘账NOR在容量和成本上真的很吃亏。因为每个单元占用的面积比NAND大阵列的译码开销也大同样做到1GbitNOR的die面积可能是NAND的数倍价格差距以倍数计。市面上NOR Flash的主流容量基本集中在64Mbit到256Mbit做到512Mbit以上的型号已经不多NAND则是1Gbit起步往上走SD NAND动辄4GB、8GB甚至更大。容量和成本的差异在嵌入式产品里往往是第一决定因素。一个设备要存语音提示、图片字库、传感器日志或者做OTA升级包暂存NOR的容量根本接不住强行用就得堆好几颗芯片面积、成本、BOM复杂度全部爆炸。NAND能做到一颗小芯片解决大容量存储这种单位bit成本优势让NOR在大数据量场景面前几乎没有还手之力。很多初级工程师喜欢单纯比谁快、谁寿命长却忽略了真实产品里容量和成本才是每天都要面对的紧约束。一颗256Mbit的NOR可能比一颗8GB的SD NAND还贵你说项目怎么选2.4 寿命焦虑和磨损均衡再聊聊寿命。NOR擦写寿命常见是十万次级别SLC NAND也在几万到十万次级别而MLC/TLC NAND只有几千到几百次。单看这个数字初级工程师很容易被吓到觉得NAND不靠谱。但实际产品寿命不能只看单die擦写次数还要看容量、写入模式和控制器策略。NAND虽然单次擦写寿命标称不如NOR但容量大很多总可写数据量反而可能远超小容量NOR。再加上SD NAND内部有磨损均衡会把写操作尽量均匀地分到各个block避免某几个块被反复写穿。举个例子一颗4GB的NAND即便保守按TLC擦写寿命算全盘均匀写一遍也有几TB的写入量。一个每天只写几十MB日志的设备按年算写入量也就几十GB寿命完全够用。反倒是小容量NOR可能因为容量两天就写满了频繁擦除重写先被耗尽的是容量空间而不是擦写次数。所以寿命焦虑要放到具体写入模型里去算不能盯着标称值吓自己。3. SD控制器补的坑恰好是NAND最大的短板3.1 NAND裸die为什么必须被管理NAND Flash出厂就不完美。晶圆工艺再先进也会在出厂检测时留下一些坏块这些坏块会通过特定标记告知使用者而在使用过程中因为编程、擦除的累积磨损还会不断产生新坏块。与此同时NAND的比特翻转比NOR更常见读写过程中偶发的位反转需要靠ECC来纠错。更麻烦的是NAND页编程、块擦除的覆盖规则。你想覆盖一个已经写过数据的页光写这个页是不行的必须把它所在整块擦除干净。可这个块里可能还住着别的页的有效数据所以你得先读出整个块、改掉目标页、擦除块、再写回整块。如果没有一层逻辑映射来帮你处理这些主控MCU直接面对裸NAND开发量会大得吓人。NOR就没这么多规矩。它支持字节随机读出厂坏块率极低没有像NAND那样把坏块当常态来管理擦除块虽然也不小但至少可以用简单的读-改-擦-写软件流程硬扛。这也是为什么MCU项目里NOR常常可以直接裸连NAND却几乎都要配控制器或者专用NAND控制器接口。3.2 SD控制器把哪些脏活累活包了SD NAND的灵魂就是内置控制器。它最重要的工作是让外面的主控把NAND当成一个会掉电保留数据的普通块设备来用。用我不太严谨但好理解的话说SD NAND就是你MCU身边一个不需要你操心内部结构的小型SSD。控制器至少干了这些活协议解析解析SDIO或SPI命令处理读扇区、写扇区、擦除等命令负责命令和数据的CRC校验。ECC纠错对每个数据页做纠错编码读出来的时候自动校验把NAND常见的比特翻转问题挡在外面。坏块管理出厂坏块进黑名单使用中出现的坏块自动隔离把逻辑地址重映射到备用块。磨损均衡把反复写入的数据分散到不同block避免某些块过早老化。FTL逻辑映射把主控看到的逻辑扇区号翻译成NAND物理页和物理块掩盖覆盖写要先擦块的物理限制。有了这套东西MCU的开发体验就完全不一样了。你不需要写NAND驱动、不需要维护坏块表、不需要自己实现ECC只要会用SD协议读写扇区就能在这个芯片上建FAT文件系统、存文件、写日志。这点对量产项目尤其重要能把底层存储的风险收口到一颗成熟的芯片里。3.3 让NOR走SD协议的反面教材既然SD NAND可以有控制器那理论上也可以做一颗SD NOR——把NOR介质和SD控制器封在一起对外还是SD协议。技术上不是不能实现但产品上几乎没有意义原因有三条。第一NOR容量天花板低。控制器本身有成本如果介质只有几十Mbit到几百Mbit控制器成本摊到每一颗芯片上单位成本会高得离谱完全没有市场竞争力。第二NOR的字节随机读优势在SD协议下直接归零。SD协议的最小访问单位通常是512B扇区主控想读一个字节也要先读整个扇区NOR那种按地址准确定位的能力根本没有发挥空间。第三NOR写入本来就慢擦除块也大如果把它当数据盘写日志你会同时忍受容量小和速度慢这两个缺点。所以SD NAND这个产品形态从一开始就是围着NAND的特点设计的。谁适合做大容量、频繁写、文件系统友好的块设备答案是NAND。NOR的DNA在于代码原地执行和小容量随机读强行塞进SD协议的盒子里只会双输。这不是NOR不好是赛道不对。4. 为什么不能简单说NOR更快所以更好XIP是个双刃剑4.1 什么是XIP它为什么好看不经用XIP全称Execute in Place意思是原地执行。把代码放在NOR Flash里CPU通过内存映射区直接从NOR取指令不需要先把代码复制到RAM再跳转。NOR之所以能承担这个任务就是因为它支持字节随机读、读延迟低可以跟CPU的取指总线配合。经典的XIP场景很多PC早期的BIOS、很多MCU外部扩展的固件存储、嵌入式设备的bootloader。好处是上电即用、RAM省、不怕掉电丢代码。很多工程师一听说XIP就觉得高级但这东西其实有隐性成本。第一个成本是硬件支持门槛。MCU必须支持把外部NOR映射到自己的地址空间很多低成本的MCU根本做不到只能用普通SPI一字节一字节把代码读回来这时候NOR的执行优势完全用不上。第二个成本是性能瓶颈。代码频繁取指的时候NOR的总线频率就是天花板复杂应用跑起来反而比从RAM执行慢。第三个成本更隐蔽XIP只适合只读代码一旦你在这个NOR区域里频繁写日志、写参数NOR的慢写入和块擦除机制会很快暴露成性能灾难。所以讲究的系统里XIP只是用来放启动代码和关键小程序不会把整个应用都放上去。4.2 SD NAND形态下NOR的强项被接口卡住SD NAND走的是SDIO或SPI接口这两种接口本质上是命令-响应式的块设备协议主控CPU无法把某个地址直接映射到SD NAND的物理地址上取指。你想执行SD NAND里存储的代码只能先按扇区把它读出来搬到RAM或内部Flash再跳转过去执行。这种复制后执行的流程让NOR的XIP优势在SD NAND形态下完全没有用武之地。反过来看SD协议本身它天生就是为顺序或批量读写设计的。连续读多个扇区、连续写日志效率最高随机小IO反而要付出不少额外开销。而NAND的架构恰恰匹配这种整页读写、顺序吞吐模式。换句话说当你选择SD NAND时你已经站到了块设备NAND这条技术路径上。这时候再往里面硬塞NOR就像让一个短跑运动员去跑马拉松还要求他全程背着沙袋。NOR最擅长的随机读取和字节寻址能力在SD协议模式下根本露不出来它的弱项——写入慢、容量贵、擦除麻烦——反而被放大了。所以从接口约束的角度看SD NAND里面选NAND几乎是被协议锁定的必然结果。4.3 哪些场景里NOR才是正确答案那是不是所有存储都要换成SD NAND当然不是。NOR在很多场景里依然是更优解我给你列几个典型的。启动引导区bootloader、二级引导程序放在NOR里上电之后主控立刻能读不需要等待SD卡初始化、不需要处理文件系统挂载启动时间可以压得非常短。小容量参数存储配置参数只有几KB一年也改不了几次NOR完全胜任而且读取随机地址很快代码写起来也简单。需要XIP的老平台MCU支持外部NOR内存映射项目又对启动速度和RAM占用敏感用NOR直接执行关键代码是很成熟的方案。系统可靠性兜底NOR结构简单没有复杂的坏块表和FTL依赖在某些认证严苛、故障模式要求简单的场合反而容易做安全分析和可靠性评估。所以更准确的说法是NOR在代码执行和小容量随机读赛道继续统治NAND在大容量数据记录和块设备赛道统治。SD NAND只是把NAND的优点通过SD协议释放出来并没有要消灭NOR。真正复杂的产品里两者常常共存。5. 给初级工程师的一套选型判断方法可以直接抄5.1 先问四个问题决定用NOR还是SD NAND千万别上来就说网上说NOR更可靠或者NAND容量大肯定更好。我给自己团队定了一个规矩先问四个问题问完再谈选型。问题一这份数据是拿来执行还是拿来存储如果是代码且MCU支持memory mapNOR更有优势如果是文件和日志SD NAND更合适。问题二写入频率高不高低频率的参数存储NOR完全够用高频率的数据采集和日志记录老老实实上SD NAND。问题三需要的容量多大256Mbit以内NOR还有竞争力超过1Gbit基本只能选NAND/SD NANDNOR的容量价格比扛不住。问题四系统里有没有文件系统需求要挂FATFSSD NAND这类块设备最自然NOR上挂文件系统不是不行但空间管理、坏块管理和擦写均衡都要自己造轮子。这四个问题走完80%的选型争议都会消失。剩下的20%多半是特殊可靠性要求、成本敏感或历史兼容性约束可以单独讨论。5.2 一个可以直接照抄的决策表我把常见场景整理成一张表初级工程师可以直接拿去和硬件同事讨论需求比空对空争论NAND好还是NOR好有效率得多。应用场景推荐方案理由启动代码/BIOS小容量NOR上电即执行支持XIP数据日志采集大容量SD NAND顺序写入带宽高文件系统友好几百字节配置参数小容量NOR或EEPROM低频写随机读取简单语音/图片/字库大容量SD NAND容量大顺序读取流畅固件升级包暂存大容量SD NAND升级包体积大先下载后搬移高实时随机访问NOR随机读延迟低确定性好大数据量离线分析SD NAND容量和单位成本优势明显这张表不是金科玉律但它能帮你看清楚选型先看场景再看容量最后才看速度标称值。绝大多数项目把场景和容量一摆答案基本就浮出水面了。5.3 三个踩过的坑务必看完第一个坑只看数据手册的峰值写速度。SD NAND的顺序写速度很漂亮但实际文件系统里大量操作是512B或4KB的小块写入真正决定体验的是随机小IO的延迟和IOPS不是峰值。我见过一个项目单看芯片顺序写速度高得惊人结果在FATFS上连续记日志却频繁卡顿后来排查发现是频繁擦除、垃圾回收和坏块重映射叠加导致的。评估时一定要用真实数据流跑测试不能只看标称值。第二个坑把NOR当EEPROM用。有人贪图NOR便宜用它存频繁变化的参数程序反复改同一个地址擦写寿命很快就被耗光。正确做法是常变参数用EEPROM或FRAM如果坚持用NOR就必须自己做磨损均衡把写地址轮换如果参数和数据量都大干脆用SD NAND。第三个坑忽略掉电场景。SD NAND虽然内部有控制器但主控侧如果文件系统没做掉电保护突然断电瞬间可能写坏目录区导致文件系统无法识别甚至需要格式化。我自己的项目经验是所有带掉电风险的产品都要做双镜像和原子操作然后反复用随机断电脚本轰炸测试才能把边界情况暴露出来。5.4 我亲自验证过的两个组合第一个组合是连续采集数据的设备。当时方案要存30天传感器数据每秒一条512B记录30天算下来大概1.3GB。有人坚持用NOR算完账发现128Mbit的NOR容量远远不够按每天几万次写入估算擦写寿命也就撑几个月。换成4GB SD NAND之后容量冗余充足磨损均衡也不用怕频繁写入问题直接解决。事后想想这个场景如果用NOR不是速度问题是容量和寿命的数学题根本做不出来。第二个组合是OTA升级。系统里同时放了64Mbit NOR和SD NANDNOR放bootloader和备份固件SD NAND放新固件包和业务数据。升级流程是先下载固件到SD NAND校验通过再搬运到NOR的备份分区最后从NOR引导新固件。这套组合既保留了NOR的启动可靠性又享受了NAND的大容量和快速写入是我比较推荐的产品架构。初级工程师如果拿不准可以先从这个组合开始把两个介质各自最擅长的部分用起来。5.5 一句大实话收尾选NOR还是选SD NAND本质不是比参数而是想清楚手里这个产品到底要解决什么问题。NOR像一本印刷精美的应急手册内容不多但随手翻开就能看SD NAND像一个装满档案的文件柜容量大、读写快但必须有个好管家来维护索引和清理废弃文件这个管家就是控制器。初级工程师阶段最容易犯的错就是把一个场景的结论生搬硬套到另一个场景然后去和硬件同事吵得不可开交。下次再碰到选型把第5节那四个问题过一遍你会发现答案其实早就写在使用场景里了。
RELATED

相关推荐

【ESP32入门】Windows 下 ESP-IDF V6.1 示例运行(下):hello_world 创建、编译烧录、串口监视 + FAQ

【ESP32入门】Windows 下 ESP-IDF V6.1 示例运行(下):hello_world 创建、编译烧录、串口监视 + FAQ

本文是下篇,上篇主要介绍 ESP-IDF 环境搭建与 VS Code 配置,还没配置环境的读者可以先看:上篇链接。 1. 运行示例 现在,可以准备首次运行ESP32应用程序了。可以从 ESP-IDF 中 examples 目录下的 get-started/hello_world 项目开…

📅 2026/10/14 16:39:40
TC275 Flash驱动RAM加载实战:解决擦写时自执行冲突

TC275 Flash驱动RAM加载实战:解决擦写时自执行冲突

1. 项目概述:为什么非得把Flash驱动搬到RAM里跑?“TC275 Flash驱动RAM加载”——光看这个标题,老司机一眼就明白:这不是在玩花活,是在啃硬骨头。TC275是英飞凌AURIX系列中定位中高端的三核安全MCU,常用于汽…

📅 2026/10/14 16:39:40
ISO 26262功能安全落地:从ASIL定级到安全机制设计全链路解析

ISO 26262功能安全落地:从ASIL定级到安全机制设计全链路解析

1. 为什么“功能安全”不是加个看门狗就能糊弄过去?ISO 26262 这个词,现在在汽车电子圈里几乎成了口头禅。你去任何一家 Tier 1 供应商的会议室,墙上贴着的流程图里准有它;招聘 JD 里写“熟悉 ISO 26262 开发流程”,薪…

📅 2026/10/14 16:39:40
MORE NEWS

更多资讯

📰

数据结构与算法分析Java版习题答案详解:从链表到图的备考攻略

简介:《数据结构与算法分析(Java语言描述)》(第三版)的配套习题答案文档,面向正在学习数据结构、Java 版算法分析与计算理论基础的本科学生及自学者。全文共 1 个 docx 文件,压缩包约 1.52MB&am…

📰

AR开发避坑指南:图像处理、位姿估计与SLAM如何撑起增强现实

拿着一张手机拍的照片,你想把一个3D咖啡杯放到桌面上。听起来只是“放上去”一个动作,但如果你真从零实现一次,会发现整个AR系统至少有八成时间在处理图像:找桌面、估计相机角度、算虚拟物体的透视关系、判断要不要让杯子被手挡住…

📰

GrantForge 2026.1.0 正式发布:开源统一权限管理平台,新增 HDFS、ZooKeeper、MySQL 权限控制与数据脱敏!

最近一直在持续开发和完善 GrantForge,今天正式发布 2026.1.0 版本! GrantForge 是一款基于 Spring Boot、Spring Security 和 Vue 3 构建的开源权限管理平台。 项目最初主要围绕 RBAC(基于角色的访问控制)展开,希望提…

📰

STM32F4 SPI+DMA+FATFS嵌入式SD卡稳定写入方案

简介:本资源是面向嵌入式开发初学者与进阶工程师的STM32F4平台SD卡文件系统实战项目,聚焦SPIDMA高效驱动MicroSD卡并集成FatFS实现标准文件操作,解决嵌入式设备中大容量、可靠存储与读写管理的核心痛点,适用于智能仪表、数据记录仪…

📰

rizzo-pii训练配方全公开:mmBERT微调74.5万行数据,单卡16GB两小时跑通0.3B PII检测模型

【免费下载链接】rizzo-pii Local-first privacy guard: anonymize your documents before sharing with LLMs. 项目地址: https://gitcode.com/gh_mirrors/ri/rizzo-pii 点击查看 免费下载 做本地隐私保护的 rizzo-pii 把它的 PII 检测模型训练配方完整公开了&…

📰

SQL窗口函数速查表:从排名到累计的实战避坑指南

简介:这份《SQL窗口函数速查表》PDF面向数据库管理员、数据分析师、数据科学家及开发人员,尤其适合希望提升复杂数据集查询能力的技术人员。内容按功能与用途分类,系统梳理窗口函数的基本概念、语法结构与参数说明,涵盖ROW_NUMBER…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬