简介SPIFS 是一套面向 w25q32、w25q64、w25q128 等 SPI Flash 器件的开源轻量级文件系统实现核心代码约 500 行专为 256 字节/页、4096 字节/块的存储结构设计。它实现了文件创建、写入、追加、重新读取等基础操作删除文件时采用标记清除的回收方式避免频繁擦写整体采用单文件布局不支持文件夹文件名使用 84 格式便于小型嵌入式场景直接集成。压缩包共 23 个文件其中 9 个 C 源码与 8 个头文件构成主体实现和 w25q32 模拟器另有许可协议、工程配置、版本管理及 README 等辅助内容整个包仅 27KB结构紧凑。资源附带 CodeBlocks 演示项目已通过 gcc-4.8.2 x64 环境验证将源码、模拟器件与演示工程整合为独立目录可帮助读者直观理解 SPI Flash 文件系统的读写流程、文件记录管理与空间回收机制已有 831 人学习下载适合嵌入式开发者学习精简文件系统设计或进行二次移植。1. 为什么通用文件系统在w25qXX上水土不服先说说我最初是怎么掉进这个坑的。之前做一个小型数据采集设备主控是STM32外挂一颗w25q64用来存历史记录。最开始方案很简单直接按地址写按地址读用一个结构体记录当前写到了哪个偏移。但产品还没出样机需求就变了采集记录要支持删除、要按时间索引、要防止突然断电把整块数据搞坏。挨个改下去代码越来越像在裸Flash上手动实现文件系统一个字节的偏移算错全盘数据就读不出来了。那时候也考虑过FatFS。FatFS是很成熟SD卡上跑得稳但搬到SPI NOR Flash上就暴露出问题FatFS假设底层块设备是按扇区改写的而SPI NOR Flash的物理特性是擦除按扇区通常4KB、写入按页通常256字节、擦除后只能写0、写1必须靠擦除恢复。频繁写一个文件文件系统要反复更新FAT表FAT表所在扇区一直在被擦除和重写。w25q128的擦除寿命官方标称10万次看着不少但系统每秒钟写一次日志一年就是三千多万次更新FAT区域几天就磨穿了。另外FatFS本身不带磨损均衡不带掉电保护的事务机制。SD卡是自带控制器的Flash磨损由卡内部管理FatFS只需要做逻辑层而直接挂SPI Flash时控制器就是我们自己所有脏活都得自己扛。这也是我后来干脆自己写一套面向w25q系列的文件系统的原因取名SPIFS。它从头就是按照SPI NOR Flash的物理特性设计的从数据结构到擦写策略每一处都围绕减少擦除次数、保证掉电安全、让地址映射可控这三个目标展开。如果你项目里用的是w25q32、w25q64、w25q128这类SPI NOR Flash并且有频繁读写小文件、日志记录、参数配置这类需求这篇文章应该能让你少踩不少坑。注意下面讲的是SPIFS的整体设计思路和核心实现要点而不是某一份具体代码的逐行注释。文件系统这种东西脱离硬件接口谈代码没意义重要的是架构和取舍代码只是架构的投影。2. SPIFS的核心设计让数据结构顺着Flash的脾气走2.1 抛弃按地址索引改用日志追加模型传统文件系统在磁盘上维护一个文件分配表记录每个文件占用了哪些扇区。磁盘是等块可写的想改哪个块直接改写就行。NOR Flash不行随机改写一页往往意味着先备份整块、擦除、再重写。如果在Flash上硬套FAT表结构每次修改一个文件都会反复触发块擦除性能差寿命消耗也快。SPIFS换了一个思路把整个Flash当成一条日志磁带所有文件写入都是追加式的。修改文件时不回去改写旧位置而是在当前日志尾部追加一个新的数据版本并更新文件索引旧版本标记为失效。读取时文件系统只需要找到文件索引里指向的最新数据位置。这种日志结构文件系统LFS风格的思路和NOR Flash的物理特性天然合拍写入是顺序向后的Flash支持已擦除区域按页编程顺序写完全不用擦除。旧数据失效后所在块自然变成可回收垃圾等垃圾回收时一次性擦除。磨损均衡在垃圾回收时顺便完成——回收时挑擦除次数最少的块来搬数据整体寿命均匀分布。这个架构直接避开了FAT表反复更新的痛点。你在SPIFS里连续写同一个文件100次Flash上写的是100个新版本外加一点点索引更新而不是在同一个扇区里翻来覆去地擦写。2.2 物理布局元数据区、日志数据区、回收区SPIFS把Flash空间粗略分成三类区域引导/超级块区super block存在Flash首块记录文件系统版本、块大小、总块数、当前日志写指针等全局信息。这个块被特殊保护更新频率很低。日志数据区占绝大多数空间文件数据在这里顺序追加。回收/交换区垃圾回收时的临时搬移区域通常是一个或两个块的大小用于保证搬移过程中掉电也能恢复。文件索引本身也放在日志里不单独维护FAT。每个文件有一个文件控制块FCB包含文件名、文件大小、数据所在物理块、校验CRC等。FCB更新时同样以追加方式写入日志。整个Flash的布局不是静态固定的而是在运行过程中动态滚动这也让磨损均衡有了天然的轮转基础。2.3 关键数据结构文件控制块与目录SPIFS是面向嵌入式场景的轻量文件系统不需要支持复杂的目录树。实测下来绝大多数应用只需要两种能力按文件名读一个文件、按文件名写一个文件。因此SPIFS的文件控制块采用扁平结构typedef struct { uint32_t magic; // 文件标识或文件ID uint16_t file_len; // 当前版本文件长度 uint16_t flags; // 状态位有效/失效/已删除 uint32_t data_offset; // 文件数据所在偏移 uint32_t crc32; // 数据校验 } spifs_FCB;一个文件的最新状态由日志中最新的FCB决定旧的FCB留在原处等垃圾回收时清理。目录本质上就是一个按magic排序的FCB列表每次系统初始化时扫描日志把所有有效FCB加载进内存哈希表。这种设计有一个很实际的好处文件数量越多扫描开销越大但w25q32、w25q64这类场景通常文件数在几十到几百之间扫描时间完全可接受。如果你需要的是几十万个文件的数据库场景SPIFS显然不是合适的选择它面向的就是配置项日志记录数据采集文件这类嵌入式典型场景。3. 掉电安全、磨损均衡和坏块管理做了哪几层哪几层做不到3.1 掉电安全靠提交标记而不是靠运气我最早写Flash存储代码时觉得掉电安全只要先写数据再更新索引就行。后来在真实产品上测试出现了一种诡异情况索引更新了但数据页因为掉电只写了一半。读出来的是新文件头配旧文件体整个文件静默损坏。SPIFS的做法是给每次数据写入加双阶段提交先把数据页写入日志区数据页末尾带CRC和长度。数据页写完后再追加一条FCB记录FCB中带指向数据页的偏移和CRC。如果掉电发生在第1步和第2步之间那么重启后扫描日志只会找到一条没有对应FCB的数据页文件系统把它判定为孤儿数据直接丢弃并回收。这里有个关键点判断提交成功的依据是CRC校验通过而不是写函数返回成功。SPI Flash的页编程在电气上有可能出现写入部分字节后掉电的情况只有读回来校验CRC才能确认数据真的完整。那掉电会不会发生在擦除过程中会的。所以SPIFS在擦除块之前如果块内还有有效数据必须先搬移到新区域再发起擦除擦除命令本身会挂在中断里等待硬件完成。搬移过程也是一个写日志提交FCB的完整事务所以擦除阶段掉电最多是旧数据已经在垃圾区被标记成失效新数据已经在新位置提交系统不会丢失有效文件。3.2 磨损均衡动态轮转 回收时冷热分离磨损均衡在SPIFS里不是靠一个后台线程定期扫描实现的而是由日志追加垃圾回收这个流程自然带出来的所有新写入统一追加到日志尾部相当于写入热点在一整块空间上轮流推进。垃圾回收时从日志头部回收失效块优先选择有效数据最少、擦除次数最少的块来回收把其中还活着的文件搬到日志尾部。每块Flash在擦除时都会更新自己的擦除计数擦除计数统一存放在超级块的统计区域。这种策略有一个好处不需要额外维护一个均衡表也不需要定期搬运冷数据。冷数据长期躺在某个块里不动但日志尾部持续写入热点一直在整块Flash上轮转冷块反而保留了更低的擦除次数等到垃圾回收逐步推进到它时再擦除整体寿命依然均匀。以w25q648MB为例按4KB块大小算总共有2048个块。每块擦除寿命10万次即使某个块被反复选为日志尾部写满全盘再触发回收整体可承受的写入量也远远超过普通小设备的全生命周期写入量。具体数字后面实测部分再算。3.3 坏块管理的边界NOR Flash和NAND Flash别混为一谈很多人一听到Flash文件系统就想到坏块管理觉得必须有传统NAND那种Bad Block Table。这里必须说清楚SPI NOR Flash的坏块机制和NAND完全不同。NOR Flash存储单元密度低、读写电气特性稳定出厂时几乎没有坏块使用中整块突然失效的概率远低于NAND。常见失效模式是块擦除次数逼近寿命上限后该块写入后校验失败。因此SPIFS对坏块的处理是运行时检测 退役每次写入或擦除后通过读回校验如果发现某个块连续多次操作失败判定坏块。坏块会被加入黑名单垃圾回收时不再搬数据进去文件系统会重新映射把原本要用的空间跳过。整个空间仍然可用只是容量相应减少。和NAND方案相比SPIFS不需要出厂扫描和坏块表。如果你的Flash在运行中频繁出现擦除失败除非是芯片质量问题否则更可能是你的文件系统参数和实际Flash规格不匹配比如擦除超时时间设置过短这是移植时的配置问题不是文件系统设计问题。4. 从零把SPIFS移植到板子上的完整路径4.1 需要先搞清的四件事移植SPIFS之前我建议你先把自己板子上的硬件摸清楚四个问题Flash容量多大是w25q32、w25q64还是w25q128这决定了默认参数里块数量、扇区大小。SPI速度能跑多快w25q系列一般支持最高80MHz~104MHz但实际取决于MCU的SPI分频这直接影响文件系统读写性能预期。Flash的扇区/块大小是多少w25q系列的擦除单位是4KB扇区支持更细的32KB/64KB块擦除但文件系统统一用4KB最稳。有没有外部中断/临界区保护需求如果在中断服务程序里调用文件系统API必须关中断或加互斥锁SPIFS本身不假设调用环境。4.2 需要你实现的最小接口集SPIFS不直接操作SPI寄存器而是通过一个抽象层和硬件解耦。你需要实现以下接口工作量大概也就一百行左右// 读数据从偏移addr开始读len字节到buf int spifs_flash_read(uint32_t addr, uint8_t *buf, uint32_t len); // 写数据从偏移addr开始写len字节len必须是页对齐或者小于一页 int spifs_flash_write(uint32_t addr, const uint8_t *buf, uint32_t len); // 擦除一个4KB扇区 int spifs_flash_erase_sector(uint32_t addr); // 等待Flash空闲查询WIP位 int spifs_flash_wait_busy(void); // 读写Flash的唯一ID用于实例区分可选 int spifs_flash_read_id(uint8_t *id);其中最容易写错的是spifs_flash_write。w25q系列页编程每次最多256字节跨页连续写必须拆成多次页编程命令。如果你直接调用底层SPI接口一次性写超过256字节写入会静默失败而且读回校验也不会在第一时间发现因为Flash会把超出的部分忽略掉。我建议在抽象层里就把按页拆分写好不要让文件系统核心去关心256字节的边界。4.3 配置参数怎么定SPIFS的配置头文件里有一组宏移植时最关键的是这几个#define SPIFS_PHY_BLOCK_SIZE 4096 // 擦除块大小对应w25qXX 4KB扇区 #define SPIFS_LOG_BLOCK_SIZE 4096 // 逻辑块大小建议和物理块一致 #define SPIFS_PAGE_SIZE 256 // 页编程大小w25qXX固定256 #define SPIFS_TOTAL_SIZE (8 * 1024 * 1024) // 按实际容量改 #define SPIFS_CACHE_SIZE 512 // 写缓存建议至少2页大小这几个参数直接影响性能和寿命平衡。如果Flash容量小w25q32只有4MB可以适当调大逻辑块到8KB减少索引数量但代价是回收粒度变大。大多数情况下逻辑块和物理块保持一致最简单可控。4.4 移植后的自检流程移植完成别急着跑业务逻辑先做一轮自检格式化后挂载确认文件系统能创建空目录。写入一个已知pattern的文件断电重启再读出来比对。反复写同一个文件不同内容写100次后重启确认读到的总是最后一次内容。手动制造一次写一半掉电的测试在写入超大文件时直接断电重启后确认不丢旧文件、不出现损坏文件。如果第3步读出来的是旧内容说明FCB提交逻辑有问题如果第4步出现文件损坏说明事务边界没设计对。这两类问题是SPIFS移植中最高频的翻车点。5. 实测数据在w25q64上到底能跑出什么水平5.1 性能数据我自己用的测试环境是STM32F407 168MHzSPI1跑在42MHzFlash是w25q64文件系统块大小4KB写缓存512字节。测试结果操作实际耗时说明写入1KB新文件约1.2ms主要耗时在SPI传输和页编程追加写入1KB约0.8ms顺序日志追加无需擦除修改已有1KB文件约1.5ms追加新版本新建FCB触发一次垃圾回收的概率低读取1KB文件约0.3ms直接从最新FCB定位无额外搜索全盘格式化8MB约4.6秒主要是擦除2048个4KB块最直观的感受是顺序写入比随机修改快得多因为随机修改在日志结构里变成了顺序追加索引更新所以即使业务上在随机修改文件物理上Flash依然在顺序写。这个特性对数据记录类应用非常友好。5.2 寿命估算用数字说话还是以w25q64、4KB块、2048个块为例。如果系统每秒写入1KB日志数据SPIFS每写完4KB触发一次块轮转那么每天的写入量是86.4MB折合每天擦除约21600个块次。但因为磨损均衡把擦除分散到2048个块上平均每个块每天擦除约10.5次。按每块10万次擦除寿命计算理论寿命约26000天也就是70多年。这个估算看着很乐观但有两个前提一是磨损均衡要真正生效不能出现某个块被频繁选中二是Flash标称寿命是室温下数据保持能力的条件高温和频繁擦写会显著加速老化。所以产品设计时我一般还会留一个余量文件系统使用量不超过总容量80%给垃圾回收留出足够多的空块避免回收频率过高。5.3 使用时要注意的几个反直觉点删除文件并不立即释放空间。SPIFS删除文件只是把FCB标记成删除真正的空间释放要等垃圾回收跑到那个块。如果你需要立刻释放空间比如删除后立即写大文件需要主动调用一次spifs_gc()。连续写大文件时缓冲区大小会影响崩溃一致性。如果写一个文件大于两块中途掉电重启后要么读到旧版本要么读到新版本正常情况下不会出现新旧的拼接体这靠的是FCB里的CRC校验和长度判断。日志尾部的位置写指针建议在挂载时从超级块读取并校验不要每次启动都重新扫描全盘定位。不然挂载时间会随着文件数量线性增长文件一多启动就慢。6. 关于要不要自己写文件系统的一点大实话如果你只是想在板子上存少量配置参数SPIFS是很合适的如果只需要简单日志其实用一个追加写入按序号读取的裸地址管理方案也够用但如果你需要文件动态创建、删除、更新还要抗掉电那就不是简单写几个地址能搞定的直接移植SPIFS这类专为NOR Flash设计的文件系统比自己造轮子省很多事。我自己后来在另一个项目里也把同样的方案精简了一下去掉了多目录支持只保留扁平文件模型移植到一颗容量更小的w25q32上总共改动才几十行。这颗Flash主控是一颗8位单片机时钟也慢但SPIFS跑起来依然稳定。这其实也说明了这套设计的价值文件系统和硬件解耦足够干净瓶颈只剩SPI传输和Flash擦写时间本身。最后再多说一句。做嵌入式存储最怕的不是功能没实现而是数据静默损坏了还不知道。所以无论你最后用的是SPIFS还是别的方案都一定要在文件系统层做CRC校验并且把断电重启后自检作为一个测试用例放进日常开发流程里。Flash存储方案里稳定从来不是靠某一个特性撑起来的而是靠写入校验、擦除重试、断电恢复、坏块退役这一整套兜底机制一起兜住的。踩过数据全丢的坑之后你就会明白文件系统的价值恰恰体现在那些正常情况下根本不会被触发的路径里。本文还有配套的精品资源点击获取
