NOR Flash与NAND Flash怎么选？从底层原理到选型实战全解析-北京尧图网络

聊存储选型的时候总绕不开一个问题NOR Flash和NAND Flash到底怎么选说实话我在刚入行那年也被这两个名字搞得头大光看规格书觉得都挺像都是掉电不丢数据的存储芯片结果一上手画板子、调驱动才发现两者从底子上就是两条完全不同的技术路线。这篇文章不打算复读芯片手册就用做项目时的实际视角把这两种Flash的底层原理、性能差异、选型逻辑和踩坑经历一次讲透。1. 先说清楚根本差异存储单元的“串并联”之分很多人上来就背参数表什么NOR读快、NAND写快、NOR容量小、NAND容量大但搞不清为什么会有这些差异。其实根源就一句话存储单元的连接方式完全不同。1.1 NOR的“并联”结构每个单元独立引出NOR Flash的每个存储单元都有一根独立的位线Bit Line连接到地线相当于每个单元都“并联”在电路里。这样的直接好处是CPU可以通过地址总线直接寻址到任意一个字节按字节读取所以NOR Flash支持XIP片上执行代码可以直接在Flash里面跑不用先把程序拷到RAM里再执行。打个比方NOR Flash就像一排独立的小邮箱每个邮箱都有自己单独的门牌号邮递员CPU想取哪封信直接走到对应编号的邮箱前就行不用把整排邮箱都翻一遍。1.2 NAND的“串联”结构单元排成一队NAND Flash则相反存储单元是“串联”连接成一个串String通常32个或64个单元串成一组共享位线。要读取其中某个单元的数据必须先给串上其他单元的控制栅加上高电压让它们全部导通剩下目标单元的导通状态才能被检测出来。这就是为什么NAND不能按字节随机读取只能按页Page读取——因为串的结构决定了你没法单独“点名”某一个单元。同样打个比方NAND Flash像一栋只有一个楼梯的老式公寓楼你要去某一家必须顺着楼梯一层一层经过其他住户门口没法直接跳过去。结构上的差异直接决定了两者的命运NOR走的是“随机读取快、直接寻址”的路线NAND走的是“密度高、成本低、顺序读写强”的路线。1.3 浮栅晶体管的共通底层虽然连接方式不同但两种Flash的单个存储单元都是基于浮栅晶体管Floating Gate Transistor或者电荷俘获结构Charge Trap做的。写数据就是让电子穿过隧氧化层注入浮栅擦除就是让电子被拉出浮栅。这个过程涉及“FN隧穿”效应一个字概括就是慢。因为要控制电荷一点点穿过氧化层所以Flash的擦写速度天然就比读慢得多。这个底层机制解释了为什么两种Flash的寿命都是以“擦写次数P/E Cycle”来衡量的——每次隧穿都会对氧化层造成细微损伤损伤积累多了单元就存不住电荷了。2. 读、写、擦三条路性能差异的实测感知2.1 读取速度NOR赢在延迟NAND赢在带宽NOR Flash的读取延迟极低通常能做到几十纳秒级别可以直接挂在CPU的并行总线上就像扩展ROM一样用。MCU上电后直接从NOR Flash取指令执行整个过程完全不需要额外的初始化步骤。这种特性在工业控制、汽车电子、通信设备里至关重要因为系统一上电就需要立刻执行代码等不起。NAND Flash的读取延迟一般在几十微秒级别比NOR慢了差不多两个数量级但它有个杀手锏按页突发读取。一页通常是2KB或4KB顺序读满整页数据的带宽可以做到几百MB/s甚至更高配合双倍速率接口。换句话说如果只需要读一个小地方NAND完败如果是连续搬一大堆数据NAND可以碾压NOR。实测中对比非常直观。几年前我在一个图像采集项目里一边用NOR存启动代码一边用NAND存图像原始数据。启动的时候NOR把系统拉起来只用了几百毫秒海量图像数据的写入靠的是NAND的页编程吞吐能力一块普通的SLC NAND就能跑到几十MB/s的写入速度。两块芯片各干各的相安无事。2.2 写入速度擦除粒度决定效率NOR Flash的写入编程是逐字节或逐字进行的速度相对较慢。更麻烦的是NOR擦除的最小单位是扇区Sector通常是4KB或64KB。你想修改某个扇区里的一个字节必须先把这个扇区整个擦掉擦除操作需要几百毫秒再重新把有效数据写回去。这在做数据日志、配置参数频繁更新时效率简直惨不忍睹。NAND Flash的编程以页为单位一页2KB/4KB一次编程操作大约几百微秒配合多平面并行Multi-Plane和交错写入Interleave持续写入速度能做得很高。NAND的最小擦除单位是块Block一块通常包含64页或128页容量是128KB到几MB之间。指向非常明确NOR适合代码存储和少量参数NAND适合大量数据的顺序写入和存储。如果你的应用有频繁的配置更新且不想动不动就整扇区擦写选NOR就得认真做好磨损均衡和备份策略否则写不了多久就挂了。这里顺带提一个很多人忽略的细节写之前必须先擦这是所有Flash共有的铁律。擦除操作比编程操作慢得多NAND擦一块可能就需要几毫秒NOR擦一个扇区更慢常常到几百毫秒甚至秒级。所以设计时一定要算好“擦除密集型操作”的时间预算别在关键路径上做整扇区擦除。2.3 擦写寿命SLC/MLC/TLC的差距放大器同样叫FlashSLC单层单元、MLC双层单元、TLC三层单元的寿命天差地别。NOR Flash基本上以SLC为主标称擦写次数通常在10万次到100万次之间NAND Flash则覆盖SLC、MLC、TLC、QLC全谱系寿命从SLC的10万次到TLC的3000-5000次不等。Q既然MLC/TLC寿命这么低为什么还用A因为容量和成本的诱惑力太大了。一个MLC单元能存2bit数据TLC能存3bit同样一片晶圆切出来的容量直接翻倍或三倍。对消费级存储来说寿命够用就行对工业级而言选SLC NAND或者做好强大的坏块管理和ECC才是正解。实际项目中如果对寿命有明确要求比如每天写满一次要求用10年就得老老实实做计算假设选择一块256MB的SLC NAND标称擦写10万次如果你每天写入128MB数据用双缓冲区方案每天对同一区域擦写的次数按2次算连续工作10年需要擦写约7300次远低于10万次理论上很安全但反过来如果用了TLC NAND额定寿命只有3000次7300次就已经超了两倍多很快就会撞上坏块墙。寿命就是设计之初必须敲定的事别等项目做完了再换Flash型号那意味着整块板子都可能要重新布局。3. 接口和封装两种芯片在电路设计上的不同玩法3.1 NOR常用并行接口和SPI接口经典的NOR Flash有完整的并行地址线和数据线可以直接映射到CPU的地址空间上电即用。这种接口在DSP、MCU、FPGA设计里非常常见连线多但速度快、延迟低。近些年为了节省引脚和PCB面积SPI NOR Flash串行NOR Flash大行其道。SPI NOR容量从512KB到256MB不等接口简单MCU上留几个GPIO就能接频率做到几十MHz到上百MHz配合Quad/Dual SPI模式读取速度也能跑到几十MB/s。比如我之前做一个音频播放器项目程序固件放在一颗16MB的SPI NOR里用Quad SPI的XIP模式直接运行响应速度完全满足要求而且整个存储方案的成本和面积都非常低。3.2 NAND主流接口是并行和Toggle/ONFINAND Flash传统上使用8位或16位并行接口但没有地址线地址信息是分时复用在数据线上的——先发命令再发地址然后才读写数据。它不能像NOR那样线性寻址CPU不能直接执行里面的代码。所以在NAND上跑程序典型流程是Boot阶段先把NAND里的代码搬到RAM然后跳转到RAM执行。现代的NAND Flash一般遵循ONFI或Toggle接口标准采用DDR双沿采样技术把接口频率拉高到200MT/s、400MT/s甚至更高。封装方面NAND常见的是TSOP48、BGA、甚至是贴片式的eMMCeMMC内部其实是NAND加了一个eMMC控制器对外提供MMC协议接口。Q为什么感觉很多开发板都是eMMC而不是裸NANDA因为纯NAND需要设计者自己处理坏块管理、ECC校验、磨损均衡复杂度很高。eMMC把控制器和NAND打包对外屏蔽了这些底层细节使用体验接近普通块设备非常适合Linux系统的存储。3.3 引脚连线与布板注意点NOR的并行接口引脚数量多如果你用的MCU引脚紧张就非常痛苦。SPI NOR的连线极少非常适合小而美的设计。NAND的TSOP48封装在PCB布局上要注意信号完整性——数据线、控制线尽量等长匹配好走线阻抗避免在高速读写时出现数据出错。我第一次画NAND的板子就吃过亏数据线绕了远路结果在高速模式下读出来的数据隔三差五就有坏块误报排查了老半天。4. 实际项目里怎么选型一张决策表帮你拍板在项目选型时我习惯先把应用的需求量化成几个维度再对照下面这张表拍板。对比维度NOR FlashNAND Flash典型容量1Mb ~ 2Gb1Gb ~ 8Tb读取方式按字节/按字随机读取支持XIP按页读取不支持直接执行读取延迟低约几十纳秒高约几十微秒顺序读取带宽中等几十MB/s封顶高可达数百MB/s写入单位字节/字但需要按扇区擦除页2KB/4KB等擦除单位扇区4KB/64KB等块128KB/数MB写入速度较慢通过并行接口有所改善较快页编程为毫秒级擦写寿命通常10万次以上SLC 10万次 / MLC 1万次 / TLC 3千次接口并行总线 / SPI并行8/16bit / ONFI / Toggle坏块管理出厂无坏块无需管理出厂可能有坏块必须管理ECC要求要求低要求高BCH/LDPC成本每MB成本较高每MB成本显著更低典型场景固件存储、配置参数、启动代码文件系统、音视频存储、大数据量日志4.1 哪些场景继续选NOR系统固件、Bootloader存储需要上电立即执行配置参数、校准数据存储数据量小更新不频繁对随机读取延迟极其敏感的实时系统工业控制、汽车ECU对可靠性要求极高希望简化ECC和坏块处理逻辑的项目容量需求不大通常在64MB以内的成本敏感型小系统4.2 哪些场景直接上NANDLinux/RTOS嵌入式系统的根文件系统、应用程序存储音视频录制、图像序列存储要的是顺序写吞吐大量日志、工业数据采集动辄几百MB到几TB消费级设备、可移动存储追求单位比特成本最低存储需求超过512MB且架构上能接受RAM启动方案4.3 我自己的选型心法把应用场景分成三类来思考第一类是“必须上电就能跑”Bootloader、RTOS内核、关键配置文件。这种场景闭眼选NOR容量小点没事稳定性最重要。第二类是“数据可以等但不能错”比如设备固件升级包、版本备份、用户配置文件。这种场景NOR或NAND都能用优先看容量和价格容量小时选NOR省心容量大时上NAND划算。第三类是“大块数据流”图像、音视频、日志文件、数据库。这种场景无脑NAND或者用eMMC、SD NAND封装顺序读写性能、存储密度和成本全都要靠NAND满足。还有一条经验除非你有充分的坏块管理和ECC设计能力否则在MCU项目里尽量别直接挂裸NAND。可以考虑用带有控制器的eMMC、SD NAND这类“集成方案”把底层复杂操作交给芯片内部控制器处理软件集成速度能快很多。5. 常见误区与踩坑实录5.1 “NAND那么快为什么我的板子跑不起来系统”不少新手选NAND是冲着大容量、低成本去的结果一开电代码执行不了——因为CPU没法从NAND直接取指。必须先在片内ROM内部BootROM里运行一小段引导程序通过UART、USB、SD或SPI等方式把NAND里的固件搬到RAM里再跳转执行。我在一个项目里因为没仔细看MCU的Boot ROM支持列表默认选了一颗NAND做启动介质结果MCU内置的Boot ROM只支持NOR和SD卡启动最后被迫改方案白白多花了一周时间。实操建议选型之前第一件事是查你所用主控的启动模式列表那个表极大决定该用NOR还是NAND。5.2 “NAND的坏块是不是跟机械硬盘的坏道一样无所谓”完全不一样。机械硬盘的坏道可以重映射内部还能继续用NAND的坏块只能靠控制器层的坏块表动态跳过。问题是裸NAND出厂时允许存在一定的坏块使用过程中还会产生新坏块。如果不做管理读写到坏块上时数据就直接丢了而且无任何报错。正确的做法是出厂时扫描所有块建立初始坏块表每次擦除/编程后检查状态寄存器识别新坏块在软件层面做坏块替换和磨损均衡搭配强力的ECC算法如BCH或LDPC纠正NAND天然存在的比特翻转我在一个数据记录仪项目里吃过一次大亏图省事绕过了坏块管理结果设备连续运行半个月后日志文件翻车了——数据读到一半全是乱码。从那以后但凡上裸NAND我必然先把坏块表、磨损均衡、掉电保护这三件事设计得明明白白。5.3 “NOR Flash的‘1-0’和‘0-1’是不是一回事”不少设计者默认写数据就是把bit写成0擦数据就是把bit恢复成1。但实际操作中有一个坑NOR编程只能把1变成0逻辑上不能反过来把0变成1。要想把某个bit从0恢复成1只能整扇区擦除。这就导致了一个问题如果你在NOR里维护一个循环缓冲区用来记录运行日志每次写一条新的日志如果恰好写在一个已经写过数据的扇区里但空间不够或者指针需要回卷你就必须把整个扇区读出来、擦掉、改好再写回去。如果日志大小小于扇区大小这个操作会非常频繁。解决办法是在软件上做日志分块管理每块日志写到独立扇区满了再擦一个扇区避免最笨的“每次都整扇擦”的操作。很多NOR Flash厂商的驱动库里都提供了类似的循环写入接口用之前务必搞懂它内部是怎么处理擦写边界的。5.4 “ECC只要纠错就行不用管校验强度吧”这是MLC/TLC NAND领域的一大坑。早期SLC NAND对ECC要求不高每512字节纠正几十个bit就够到了MLC/TLC时代每1024字节需要纠正数百个bit如果用的是软件ECC或者弱校验算法根本无法保证数据完整性。选型时要注意匹配主控的硬件ECC能力。我遇到过一颗TLC NAND在非常规温度环境下比特翻转率骤增主控ECC勉强能纠但性能掉到只有标称的六成。后来换了一颗更稳的SLC NAND问题才彻底解决。工业级应用还是要留足ECC余量别在边缘上试探。5.5 “Flash掉电是不是不会丢数据”这个说法只对了一半。虽然掉电后数据能保持但在写入过程中意外掉电可能出现“半个页/半个扇区被编程成功、另一半是旧数据”这种不一致状态。更麻烦的是NAND在编程中掉电还可能把块标记成坏块或者留下一部分“伪坏块”状态。要做到掉电安全有几个常用招使用日志化写入方式先写临时区再提交标志位关键数据存双份或多份副本用序号判断最新版本写入关键结构如坏块表、文件系统元数据时先写备份再更新主表使用带有掉电保护的核心板或者加一个超级电容保证完成最后的刷盘动作我从一个工控项目中吸取的教训是上电瞬间和掉电瞬间Flash控制器状态最不稳定所有关键操作必须加临界区保护并且配合硬件电压检测BOD来主动降级到安全模式。6. 从数据手册到产品落地我整理的三板斧最后分享一点方法论。别看NOR和NAND的手册有几百页有价值的核心信息其实就那么几栏。我总结成一个三张表检查法第一张表是时序表。读NOR的手册重点看随机读取时间和连续读取频率读NAND的手册重点看页读取时间、页编程时间、块擦除时间。把这三个时间填到你的系统时间轴里能立刻看出瓶颈在哪。第二张表是电气参数表。重点看工作电压范围、待机功耗、读写峰值电流。NAND的写峰值电流一般比NOR大不少在设计电源时一定要保证足够的电流裕量否则高压写的时候电压跌落轻则写入失败重则把Flash干出坏块。第三张表是可靠性参数表。重点看数据保持时间Data Retention、擦写寿命、工作温度范围。数据保持时间和擦写寿命是相互牵制的擦写次数越多保持时间越短。如果产品要服役十年就得认真核查“10万次擦写 105℃高温 10年保持”是否能同时满足很多低端Flash在高温下的保持时间会急剧缩短。我个人现在的习惯是不管项目多小先画一张“上电时序图”把CPU从Flash取代码、初始化RAM、加载数据、运行主流程这四件事按时间排列起来然后再决定用NOR还是NAND。说穿了就是一句话——别先定芯片先定数据流让数据流替你选Flash。如果你正卡在选型上可以拿这个思路推一遍自己的项目代码能不能等数据量大不大更新频不频繁需不需要断电保存这四个问题过滤完答案基本就已经浮出水面了。

NOR Flash与NAND Flash怎么选？从底层原理到选型实战全解析

相关推荐

NOR Flash和NAND Flash到底有啥区别？一文讲透原理与选型

Triton-TLE布局引擎：AI芯片算子性能优化实战解析

AI写Rust代码为何频繁翻车：所有权与生命周期难题解析

更多资讯

第7讲：并查集

Django+Vue宠物商店实战：库存原子扣减、订单状态机与RBAC权限落地

零基础本地部署DeepSeek-R1：Ollama三步跑通与强化学习原理解析

交通标志检测实战：YOLO数据体检与训练避坑指南

用C/C++写一份“无毒”表白代码：从控制台动画到Windows图形窗口

Codex安装纯教程

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？