做穿戴设备的朋友应该都有这种感觉：选一颗存储芯片，比选主控还纠结。内部Flash只有那么几MB，固件一膨胀、日志一累积、OTA包一下来，马上见底。翻来覆去就是NOR、SD卡、eMMC三选一，各有各的憋屈。看到Winbond（华邦）放出1Gb QspiNAND的消息，我第一反应是：这个容量和接口的组合，正好卡在可穿戴和低功耗IoT设备最缺的那一档。这颗料到底解决了什么问题，和老的NOR Flash方案差在哪，量产时有哪些坑要提前填，我用一篇完整的选型笔记讲清楚。
1. 可穿戴与低功耗IoT的存储困局：一颗料卡住整个产品
1.1 小设备为什么比手机更难选存储
手机选存储很简单：上UFS、上eMMC，容量越大越好在，主控和PCB都扛得住。但可穿戴设备完全不是这个逻辑。手环、智能手表、血氧仪、温湿度传感器、资产追踪标签，这些产品的PCB可能只有指甲盖大小，电池容量几百毫安时，主控往往是Cortex-M系列或者低端SoC，根本没有SD/MMC控制器，也不方便外挂eMMC。
更麻烦的是，小设备的固件和资源需求却在肉眼可见地膨胀。一个带图形界面的彩屏手环，字库、图标资源、蓝牙协议栈、传感器算法库，随随便便就吃掉几MB；如果再叠加一个轻量级AI模型做心率或睡眠分析，那几十MB也不够塞。早期那种"内部Flash 512KB就够用"的时代已经过去了。
这时候就出现了一个尴尬的断层：小容量NOR便宜，但超过16MB、32MB之后价格直线上升；大容量eMMC性能和容量都够，但接口重、初始化慢、对低端主控不友好；SD卡体积大、连接器不可靠、供电要求高，放在穿戴设备里就是找罪受。这个断层，正好是SPI接口的NAND Flash可以填补的位置。
1.2 从"能跑就行"到"能OTA升级"的需求演进
前几年大家做IoT设备，存储方案很简单：程序放内部Flash，数据能不存就不存，实在要存就外挂一颗几Mbit的EEPROM。但现在用户对设备的要求变了，存储需求也跟着涨：
- 离线数据采集：环境监测设备每隔几秒就要存一条带时间戳的记录，一天能产生几十到几百KB数据，跨越多天就需要MB级空间。
- 固件OTA升级：哪怕固件只有2MB，升级时为了稳妥，往往需要下载完整镜像到独立分区，预留空间就要翻倍。
- 日志与故障诊断：设备出问题后，厂商希望拿到运行日志，这需要循环覆盖的日志分区。
- 资源热更新：彩屏设备的主题、字体、语音包，经常需要从云端下发替换，不能每次都用整包固件带着走。
这些需求叠加在一起，内部Flash根本扛不住。另一个关键是OTA策略：现在主流做法是A/B分区或者下载区+解压区。无论哪种，设备端都需要一块比固件本体大得多的存储空间。我见过不少项目因为存储容量不够，OTA只能设计成"先擦后写"，一旦升级中途掉电或网络异常，设备直接变砖。这是典型的省小钱花大钱。
1.3 现有方案的尴尬：不是不能用，是别扭
先说NOR Flash。Winbond的W25Q系列在行业里用得非常广，8MB、16MB、32MB的SPI NOR在MCU项目里几乎是标配。NOR的优势是支持XIP（片上执行）、随机读取快、可靠性高，坏块管理都省了。但到64MB以上，NOR的价格就很不好看，而且大容量NOR的写入速度并不快，反复擦写寿命也有限。对"要大容量存数据"的需求，NOR属于能用但性价比差。
再说eMMC。它自带FTL（闪存转换层），有坏块管理、磨损均衡，容量从4GB起步，对应用层非常友好。但低功耗可穿戴设备的主控大概率没有eMMC控制器，要用SDIO/MMC接口就得额外加芯片或选更贵的主控，功耗和体积也不划算。eMMC的启动流程对MCU项目来说也太重。
SD卡就更不用说了，连接器+电平转换+供电管理，折腾半天还不如直接在PCB上焊一颗Flash省心。
所以市场其实一直缺一类产品：容量在64MB到256MB之间、接口轻量、功耗低、价格适中，开发难度又不会像裸调NAND那么高。Winbond的1Gb QspiNAND，瞄的正是这个档位。
2. QspiNAND到底是什么：接口、颗粒结构和我为什么先看它
2.1 名字拆解：QSPI是接口，NAND是本质
先把这个名字拆开看。NAND是闪存颗粒的存储结构，特点是按页写入、按块擦除、存在坏块、需要ECC（纠错编码）；QSPI是Quad SPI的缩写，也就是四线串行接口。合起来就是用四线SPI接口访问的NAND Flash，注意，它还是Flash，不是带控制器的存储卡。
很多人一看到NAND就发怵，觉得要处理坏块、要算ECC、要搞磨损均衡，太复杂。但QspiNAND这类产品的思路是：把一部分管理功能尽量在颗粒内部做掉，或者用更成熟的软件方案兜底，把接口复杂度控制在MCU能接受的范围。这和直接贴一片BGA封装的大容量NAND完全不是一个量级的工作量。
Winbond做QSPI接口存储是有积累的，W25Q系列的NOR铺货量非常大，生态很成熟。现在推出QspiNAND，可以复用很多QSPI控制器的已有资源，主控侧的命令格式和传输时序跟NOR有不少相似的地方，这对嵌入式工程师来说学习成本会低很多。
2.2 内部结构：从Die到Page/Block，把1Gb拆开看
NAND的基本组织结构是：一片Die，Die里分多个Plane，Plane里分多个Block，Block里分多个Page。Page是读写的最小单位，Block是擦除的最小单位。以常见的SPI NAND为例，Page大小一般是2KB或4KB，Block通常包含64到128个Page。
用1Gb来算一笔账：1Gb等于128MB，按4KB Page计算，总共有32768个Page；如果按每个Block 128个Page算，就有256个Block。按2KB Page、64Page/Block算，就是65536个Page、1024个Block。这个数量级是什么意思？意味着单个Block坏了，对整个容量影响非常小，坏块替换策略不需要太复杂。
但要注意，NAND的Page不是随机访问的，只能按顺序写入。比如一个4KB Page已经写了部分数据，想再往同一个Page剩余位置塞数据，多数颗粒不支持，必须先擦除整个Block再重写。这在文件系统或FTL设计上是个关键约束。很多从NOR转过来的人在这里栽过跟头：以为像操作EEPROM一样，读改写同一个地址就行，结果读出来全是FF，写也写不进去。
2.3 为什么不用NOR硬扛：容量和写入速度的物理差距
NOR和NAND的差异不是简单的"容量不同"，而是底层存储单元的电气特性不同。NOR单元的读取速度快、支持随机访问，但写入和擦除慢；NAND单元的写入密度高、擦写快，但读取速度相对NOR要慢一些，而且不支持XIP。
在可穿戴设备里，代码执行通常放在内部Flash或外挂NOR里，因为MCU可以XIP直接从NOR取指，省掉"先拷贝到RAM再执行"这一步。但资源文件、日志、OTA包这类数据不需要XIP，它们更适合放到NAND里，NAND的顺序读写吞吐能力反而比NOR强，大块数据搬运效率更高。
所以一个很常见的合理架构是：小容量NOR放Bootloader和关键代码，QspiNAND放文件系统、日志、OTA镜像、资源包。NOR管代码执行，NAND管数据存储，各干各的活。不要指望用一颗QspiNAND替代NOR，也不要指望NOR去承担大容量数据存储，物理特性决定了这种分工。
3. 1Gb容量能装什么：从固件、日志到OTA镜像的容量账
3.1 先把128MB拆开看
1Gb听着不大，但在可穿戴和IoT设备里已经不算小了。128MB做分区规划，可以覆盖很多典型场景。我按一个带彩屏、有蓝牙、支持OTA的手环产品做示意：
| 分区用途 | 容量 | 说明 |
|---|---|---|
| Bootloader | 0.5MB | 启动入口，尽量不更新 |
| 固件A（当前运行） | 8MB | 包含RTOS、GUI、协议栈、算法 |
| 固件B（OTA备份） | 8MB | A/B升级用的双备份 |
| 资源区 | 32MB | 字库、图标、主题、语音 |
| 日志区 | 16MB | 循环覆盖的系统日志 |
| 用户数据区 | 32MB | 运动记录、健康数据、配置 |
| OTA下载缓冲 | 16MB | 临时放下载的升级包 |
| 文件系统元数据+坏块替换区 | 12.5MB | 预留损耗和FTL开销 |
| 总占用 | 125MB | 接近128MB |
这只是个示例布局，实际产品未必需要A/B分区，但可以看到，128MB做资源热更新、日志回传和OTA冗余是足够从容的。如果只想要一块"能塞固件+日志"的存储，那64MB甚至32MB也够用，但1Gb给我们留了余量。
3.2 OTA升级容量怎么算
OTA是最容易忽略容量的场景，我来详细算一笔账。假设当前固件镜像为10MB，云端下发的是压缩包，假设压缩后8MB。
如果做A/B分区，需要两个固件分区各10MB，加上下载缓冲8MB，至少要28MB。如果只做单分区，最简单的做法是：先把压缩包下载到下载区，校验成功后擦除固件区，再把压缩包解压写入固件区。那也需要下载区8MB+固件区10MB，但中间擦除和写入过程中设备不能断电，否则现场变砖。
更稳妥的单分区做法是：下载区8MB，再加一个解压暂存区10MB，解压并校验完整后再一次性写入固件区。这样中间任何一步失败，固件区还是旧的，可以回滚。这个方案需要28MB。和A/B方案所需的28MB其实很接近，只是少一份运行固件的空间占用。
128MB的QspiNAND做上面的OTA方案完全没压力。如果固件膨胀到20MB甚至30MB，128MB依然够用。这也是我推荐把1Gb作为甜点容量的原因：它既能覆盖今天的固件规模，也留了未来两三个大版本的空间。
3.3 日志和采集数据怎么攒
对物联网数据采集场景来说，存储容量直接决定了"采集频率-回传周期"这条曲线。拿一个环境监测设备举例：传感器每10秒存一条32字节的记录，一天产生约276KB。如果回传周期是一周，一周就是1.93MB；如果回传周期是一个月，约8.3MB。
如果设备本地缓冲是64MB，可以存约7个月的周报数据，或者2个月的日报数据，这个量级对很多LoRa、NB-IoT设备来说非常舒服，因为可以降低回传频率、省电、省流量。如果设备本地缓冲只有4MB，那就得频繁回传，还要在弱网情况下反复重传，功耗和流量成本反而更高。
但要注意：NAND适合顺序写入，日志系统最好设计成"追加写模式"，不要频繁随机改写小区域，否则磨损均衡做不好，某些Block会提前报废。
4. 功耗、抗掉电和寿命：这颗料真正要过的三道坎
4.1 低功耗场景下的电流怎么看
QspiNAND的静态电流一般能做到很低，但真正的功耗大头在读和写时。以主流SPI NAND颗粒为参考，读操作电流可能在几十毫安级别，写/擦除电流可能到几十甚至上百毫安。这个数字看起来吓人，但实际运行中是脉冲式的，持续时间短，平均功耗完全可以控制。
在低功耗系统里，关键是"平时让它睡眠，用时快速唤醒"。选择QspiNAND时要关注几个参数：待机电流、深度掉电电流、从掉电模式唤醒的时间。如果主控经常进入sleep，Flash也应该进入standby或deep power-down，而不是一直保持active状态。有些颗粒支持深掉电模式，电流可以降到个位数微安，对年抛型纽扣电池设备很关键。
另外要注意QSPI接口本身在高速翻转时也会有动态功耗。如果设备大多数时间处于睡眠状态，偶尔被唤醒做一次数据记录，那接口频率其实不用拉太高，中等速率反而有利于降低功耗。对功耗敏感的产品，可以欠压或者降低时钟频率来换功耗，但要在性能和数据完整性之间找平衡。
4.2 掉电保护：NAND最容易被低估的软肋
NAND写Page是一个"编程"动作，时间相对长，如果编程过程中掉电，这个Page可能处于不确定状态，轻则数据错，重则损坏。很多开发者在实验室里发现不了这个问题，因为电源稳定；一到客户现场，电池供电、触点接触不良、用户直接抠电池，问题就全出来了。
应对思路有几种，我在产品里一般会组合使用：
- 硬件掉电检测：MCU通过ADC或比较器检测电源跌落，在电压低于阈值时立刻停止Flash操作，并给关键的元数据区做标志。
- 双备份关键区：Bootloader、分区表、文件系统超级块这些关键区域做两份，写入时先写备份再写主拷贝，启动时校验主拷贝，无效就回退。
- 脏标志与日志：在擦除/写入前先写一个"操作中"标志，启动时看到这个标志就知道上次操作没完成，做恢复流程。
这些策略会让固件复杂不少，但QspiNAND这类产品本来就是给有一定软件能力的团队用的。如果不想处理这些，那大概率还是得回到NOR Flash的舒适区，接受容量和价格的上限。
4.3 寿命和ECC：能用多久要会算
NAND Flash有擦写寿命上限。SLC颗粒一般标称5万到10万次擦写，MLC只有几千到一两万次。1Gb QspiNAND作为工业向产品，大概率是SLC或等效SLC设计，寿命相对乐观，但也不能浪费。
算一下寿命预期：假设一台设备每天写入50MB日志，128MB分区可用约80MB（扣除文件系统开销和坏块预留）。用简单的循环覆盖方式，每天写约半个分区，那每天的擦写次数在0.5到1次P/E之间。按5万次P/E算，可以用50000天，远超产品生命周期。
但现实不会这么理想。如果应用频繁修改小文件，比如每几秒就更新一下传感器当前值，每次都要擦写同一个Block，磨损就会集中。解决办法是使用带磨损均衡的文件系统或FTL层，让写入均匀分布到所有Block。
ECC是另一个绕不开的话题。NAND出厂就有坏块，使用中还会产生新坏块，所以读取时要做ECC纠错。有些SPI NAND颗粒内置了ECC，主控只需读取状态寄存器判断是否发生不可纠错错误；有些则需要主控自己做ECC。选型时一定要确认这一点，否则后面驱动工作量会大很多。我的建议是优先选内置ECC的颗粒，至少能省掉MCU侧大量运算开销，也减少固件出bug的概率。
5. 从选型到量产的坑：驱动适配、坏块管理与PCB布局
5.1 先确认主控QSPI控制器的能力，别被"支持QSPI"骗了
很多MCU宣传自己带QSPI接口，但它到底支持什么命令、支持多大频率、有没有DMA、能不能双bank连续访问，都得仔细看参考手册。我见过一个项目，主控说支持QSPI，结果只有单线SPI模式可用，Quad模式压根没接线；还有的主控对QSPI NAND的Page Program命令支持不完整，只能通过普通SPI模式写，速度直接掉回单线。
所以在选型阶段，第一步不是看Flash datasheet，而是确认主控侧的QSPI控制器支持哪些命令序列，支不支持读状态寄存器、写使能、页编程、块擦除、读ID这些基本操作。还可以做一个小测试板，用逻辑分析仪抓一遍读ID和擦写命令，确认时序没问题再继续。
如果主控的QSPI控制器实在太弱，也可以退一步用普通SPI模式跑QspiNAND，只是吞吐会低一些。可穿戴设备的数据量通常不大，不是所有场景都需要Quad模式跑满，这个折中是可以接受的。
5.2 坏块管理和磨损均衡到底谁来干
这是QspiNAND项目里最大的分水岭。有的团队只用它存"一次性写入"的资源包，坏块管理都不做，擦写一次就不动了，那确实简单；但只要涉及动态写入和擦除，就必须有坏块管理和磨损均衡。
常见做法有三种：
- 方案A：裸驱动+自己做简单坏块表。出厂时扫描所有Block，标记坏块，维护一张表；写入时跳过坏块。磨损均衡可能只做简单的"轮询写"，适合日志类顺序写入场景。
- 方案B：使用带FTL的SPI NAND方案。部分颗粒内部会实现地址映射、坏块管理、磨损均衡，对外提供类似"逻辑扇区读写"接口，主控侧简单很多。Winbond在NOR上的W25Q生态很成熟，NAND产品线也在往"降低开发门槛"方向走。如果有内置FTL的产品，对中小团队非常友好。
- 方案C：使用文件系统组件，比如LittleFS、SPIFFS，或一些专门支持NAND的嵌入式文件系统。LittleFS自带磨损均衡和掉电保护，但对NAND的坏块管理支持需要权衡；很多文件系统是为NOR设计的，对NAND的"只能按页写、按块擦"约束适配得并不好。
我的经验是：如果是资源包+日志类的项目，方案A够用且代码透明；如果涉及文件管理、多目录、频繁增删，那么方案C更合适；如果想要开发速度快、又不想自己处理坏块，那就找方案B的颗粒或者模块。
5.3 硬件布局和电源：小设备上的隐形坑
存储芯片本身不大，但在可穿戴设备的狭小PCB上，摆放位置和电源滤波会影响整机稳定性。说几个我踩过的和见过的问题：
- 去耦电容不能省：Flash在页编程时会有电流尖峰，如果电源纹波太大，可能导致写入错误。0.1uF和1uF的组合电容尽量靠近VCC引脚。
- QSPI走线要等长：Quad模式下四根IO线最好保持等长，避免高速翻转时信号偏移。对低主频应用影响不大，但只要跑高频，这点就要注意。
- 远离天线区域：Flash的走线和封装可能引入噪声，干扰蓝牙或WiFi天线。布局时尽量把Flash放在天线辐射区之外，中间加地过孔隔离。
- 温度测试别省：穿戴设备贴近皮肤，温度可能到40多度；户外设备可能在零下工作。NAND在不同温度下的读写行为和漏电率有差异，量产前要做高低温读写测试。
还有一个很多人忽略的点：烧录。如果是小批量打样，用编程器直接烧录没问题；但量产时，最好在产线上通过主控的烧录接口先把Bootloader和分区表写进去，再让设备自己从云端拉取资源包和固件。这样能避免编程器座子在批量过程中带来的接触不良，也方便生产后在线升级。
6. 是不是所有低功耗设备都该换QspiNAND：和NOR、eMMC的取舍
6.1 三类方案的边界到底在哪
先做一张对照表，方便决策时一眼看清：
| 维度 | SPI NOR | QspiNAND | eMMC |
|---|---|---|---|
| 典型容量 | 1MB~128MB | 64MB~1Gb | 4GB~128GB |
| XIP执行 | 支持 | 不支持 | 不支持 |
| 读随机访问 | 快 | 相对慢 | 相对慢 |
| 连续写吞吐 | 中 | 快 | 快 |
| 坏块管理 | 不需要 | 需要 | 芯片内部已做 |
| 磨损均衡 | 一般不关注 | 需要软件策略 | 芯片内部已做 |
| 接口复杂度 | 低 | 中 | 高（MMC/SDIO） |
| 主控要求 | 极低 | 需要QSPI/SPI | 需要SD/MMC控制器 |
| 典型成本 | 中小容量便宜 | 甜点容量性价比高 | 大容量便宜但门槛高 |
| 适合场景 | 代码执行、小数据量 | 日志、OTA、资源存储 | 视频、大文件系统、Linux启动 |
这张表最关键的是"接口复杂度"和"主控要求"这两行。如果你的主控根本没有SD/MMC控制器，那eMMC直接出局；如果你的固件需要XIP，那NOR依然是刚需，只是可以和大容量NAND共存。
6.2 什么时候继续用NOR，什么时候换QspiNAND
我自己的判断逻辑是：
- 如果整个固件加资源不超过16MB，且没有什么动态数据要存，继续用NOR，省事。
- 如果固件超过16MB，或者需要本地存几十MB的日志、资源包、OTA包，那就认真考虑QspiNAND。
- 如果要做Linux或RT-Thread + 文件系统 + 本地数据库，需要几百MB甚至几GB空间，那直接上eMMC或SD NAND。
所以QspiNAND不是万能的，它是填补"NOR容量不够、eMMC过重"这个中间档位的产品。对可穿戴和低功耗IoT这种"主控不强、空间不大、又要存不少数据"的场景，它的优势很明显。
6.3 选型决策清单：动手前先回答这10个问题
在把QspiNAND放进BOM之前，我会建议团队把这几个问题过一遍：
- 主控有没有可用的QSPI控制器，支持哪些命令？
- 是否必须支持XIP？如果是，NOR不能完全替代。
- 有没有掉电保护机制，是否需要掉电标志和恢复流程？
- 数据写入模式是大块顺序写还是频繁小文件随机写？
- 有没有文件系统需求，文件系统对NAND的适配是否成熟？
- 是否需要ECC，颗粒内置还是主控算？
- 有没有多分区、A/B升级的需求？
- 产品工作温度范围是什么，Flash是否满足？
- BOM成本目标是多少，同容量NOR和NAND价差是否能接受？
- 团队有没有FTL/坏块管理的开发经验？
这些问题不答完，就不要急着画原理图。存储选型看似简单，但它涉及固件架构、OTA策略、量产测试和售后运维，是一家公司产品成熟度的分水岭。我见过不少团队前期低估这个决策的复杂度，等到量产前才发现存储方案不可靠，被迫返工，那代价不是省下的几块钱芯片差价能补回来的。
最后分享一个我自己的小习惯：拿到任何一颗新Flash，我不会先看datasheet里的性能表，而是先写一个最简单的"读ID+擦除+写入+读回"的裸机测试程序，在最小系统板上跑一遍，用示波器或者逻辑分析仪把时序抓下来，确认主控和颗粒的握手没问题，再开始设计产品功能。这一步能提前暴露绝大多数接口兼容性问题，比任何仿真都管用。QspiNAND这种处在NOR和eMMC之间的"中间派"芯片，尤其需要这种谨慎验证。如果验证通过，它会是可穿戴和低功耗IoT设备里非常能打的一颗存储主力。
