设备一多问题就来了——上一套边缘网关刚调通客户那边就提了需求参数不能丢、日志要能追溯、大容量的历史数据最好能导出分析。那块板子上同时挂着 STM32 和 FPGACPU 负责通信和业务逻辑FPGA 负责高速采集和实时控制数据往哪儿放、怎么放成了整个项目里最容易被低估的环节。我在这套硬件方案上折腾了好几轮最终确定的存储方案就是标题里那套分级存储EEPROM 存配置参数、NOR Flash 存系统日志和关键运行记录、SD 卡存大容量历史数据。这篇文章把整个选型思路、驱动实现、分工逻辑和踩坑过程完整拆一遍给正在做类似工业控制器项目的人一个可以照着走的参考。EEPROM、NOR Flash、SD 卡这三种介质我在不同项目里都单独用过但把它们组合成分级存储体系还是在这个项目里第一次正式落地。三者各有明显的技术边界选错介质或者把数据放错位置代价不只是存储容量不够更可能是掉电丢数据、写入周期过长挡住主流程、Flash 坏块导致系统无法启动这类硬伤。下面先从为什么要分级聊起再逐个拆介质特性、驱动实现和联调经验。1. 数据高低胖瘦各不同为什么工业控制器必须分级存储先看一个很典型的工程现实控制器里跑着的数据生命周期和写入频率差异非常大。设备参数设备编号、通信地址、校准系数、报警阈值可能一个月才改一次但改完之后得保证十年不掉运行日志每隔几十秒就要追加一条掉个几十条能忍但不能整段坏掉高速采集的波形数据、温度曲线、故障前后的原始采样可能每秒钟几千字节要存大容量、要方便导出分析。这三种数据如果全塞进同一种介质要么配置参数和日志互相抢占写寿命要么大容量数据把昂贵的高可靠 Flash 空间撑爆总之怎么算都不划算。在工业控制器里数据存储有一个常见的分层模型热数据、温数据、冷数据。热数据指 CPU 或 FPGA 里正在运算、处在缓存中的实时数据温数据是需要掉电保持但更新不频繁的关键参数以及短期内的运行状态记录冷数据是历史采样、故障记录、数据包镜像这类低频读取但总量持续增长的资料。分级存储的本质就是为这三类数据匹配不同特性的存储介质而不是找一块万能存储硬顶。我最初也犯过一片大容量 NOR Flash 全搞定的毛病后来发现根本扛不住。工业级的擦写寿命通常在 10 万次左右假设系统每 30 秒写一条日志一天就是 2880 次一块 NOR Flash 撑不到两个月就到寿命上限了而如果为了延长寿命改用大容量 SD 卡配置参数这种十年必须可靠的数据放进 SD 卡又完全不踏实——SD 卡的文件系统结构太复杂一个异常掉电可能导致目录项损坏参数直接读不出来。分级之后各司其职EEPROM 扛低频率高可靠写入NOR Flash 扛中频次日志和代码/启动镜像SD 卡扛大容量历史数据。这个各司其职是整个方案的核心价值也是本文后面所有讨论的基础。2. EEPROM、NOR Flash、SD 卡的分工逻辑与技术边界2.1 EEPROM小容量、高可靠、低频率写入的最佳归属EEPROM 在工业控制器里的定位非常清晰存小容量但绝对不能丢的关键数据。它的电擦除特性决定了可以按字节读写不需要像 Flash 那样必须先擦除整块/整扇区再写入这在工程上简化了很多逻辑。最常用的 I2C 接口 EEPROM 一片就是几百 KBit 以内比如 AT24C02 是 2Kbit也就是 256 字节容量不大但写寿命通常标称 100 万次。选型时我建议重点关注三个参数写周期时间tWR、页写大小、工作电压范围。写周期时间是指一次页写发起后到内部真正写完所需的时间常见芯片在 3-5ms 左右这直接决定了驱动里要不要等待/轮询页写大小决定了单次 I2C 事务最多能连续写多少字节超出页边界会回卷覆盖这是新手最容易踩的坑之一工作电压范围则跟系统供电设计强相关3.3V 系统选 1.8-5.5V 宽压的芯片会省很多麻烦。2.2 NOR Flash代码承载与中频日志的主力NOR Flash 和 NAND Flash 在工业场景里常常被混为一谈其实它们在电气特性和使用方式上差异极大。NOR Flash 的随机读取性能好、支持 XIP片上执行所以最常见的用途是存放 bootloader 和应用程序镜像——CPU 可以直接从 NOR Flash 映射地址取指执行不需要先拷到 RAM 再跑。工业级产品里STM32 倒不一定需要 XIP内部 Flash 就够用但外挂一片单独的逻辑代码或 FPGA 配置文件时NOR Flash 仍然是最合理的选择。接口上目前主流是 SPI / Dual SPI / Quad SPI 的 NOR Flash像 W25Q64、W25Q128 这类芯片非常常见。读写逻辑比 EEPROM 复杂一些写入之前必须先擦除擦除以扇区常见 4KB或块为单位写可以按页常见 256 字节进行。擦除操作耗时较长一个扇区擦除可能要几十到几百毫秒写驱动必须做状态轮询读状态寄存器判定 BUSY 位不能盲目延时。NOR Flash 的标称寿命通常也是 10 万次擦写比 EEPROM 低一个数量级这决定了它不适合做超高频的数据记录介质用于日志和代码存储则刚好。2.3 SD 卡大容量、低单价但需要做好人味管理SD 卡是三种介质里容量最大、单价最低的一张工业级 MicroSD 卡轻松做到 32GB 以上FAT32/exFAT 文件系统也方便 PC 端直接读取分析。但它的可靠性设计复杂度也最高文件系统的目录项、FAT 表、簇链结构在异常断电时都容易损坏所以工业场景下 SD 卡必须搭配缓存 周期落盘 掉电冲刷这类策略来用否则大概率会在某次非法断电后出现文件系统损坏数据全部读不出来。这里要特别提一下 SD 卡的两种工作模式SDIO 模式和 SPI 模式。STM32 平台通常优先用 SDIO吞吐量高但如果 SDIO 引脚被其他功能占用或者想降低接线复杂度也可以切换到 SPI 模式跑速度会明显下降通常只有几 MB/s对低频日志类应用够用。另外一个常见误区是直接把 SD 卡当无限大 EEPROM来使每来一条数据就 open/write/close 一次文件这种写法不仅磨损文件系统还会因为频繁创建文件导致目录项爆炸性能差且寿命短。正确做法是设计定长的记录文件先写满再轮转文件系统层面做缓冲批量写入。2.4 三介质横向对比什么时候选哪个一目了然说到这用一个对比表把三种介质的核心技术边界和选型建议列出来方便直接对照。维度EEPROMI2CNOR FlashSPISD 卡SDIO/SPI典型容量1KB ~ 256KB1MB ~ 128MB数百MB ~ 数TB接口复杂度低I2C2 线中SPI3-6 线较高SDIO 或 SPI带命令协议按字节写支持不支持需先擦扇区/块不支持按块/扇区写擦写寿命约 100 万次标称约 10 万次标称取决于卡品质工业级更高掉电可靠性高单字节原子性较好中高擦写中断可能损坏页内数据较低文件系统结构脆弱典型用途配置参数、标定系数代码镜像、FPGA 配置、系统日志历史数据、采样曲线、大文件导出选型建议数据量小、更新极低频、可靠性优先容量适中、需要频繁读、中等频次写大容量、结构化文件、需要 PC 分析这个表基本就是我在做方案评审时的一页纸结论。后续所有软件设计都是围绕这张表的边界展开的。3. STM32 侧存储驱动怎么落I2C 页写、SPI 擦除轮询与 FATFS 同步3.1 EEPROM 驱动页写边界和写周期时间是两个隐藏炸弹STM32 操作 EEPROM 的核心是 I2C 外设 页写逻辑。很多人第一次写 EEPROM 驱动时都以为write 几个字节就 i2c 发送几个字节但在页写模式下这是错的超出页边界的地址会回卷比如 AT24C02 的页大小是 8 字节如果从地址 0x05 连续写 8 个字节那么地址会从 0x05 写到 0x07然后回卷到 0x00-0x04把之前的数据覆盖掉。工程上最简单的规避方式就是写之前先判断从当前地址到页边界的剩余字节数拆分写入或者干脆每次写不超过一页。另一个关键点是写周期时间 tWR。EEPROM 接收到页写命令后I2C 总线事务已经结束但芯片内部还在进行实际的编程操作这时候如果立刻发起新的读写命令芯片要么不响应NACK要么数据出错。驱动里可以做一个 ACK 轮询发送设备地址 写命令如果收到 NACK 就继续重发直到 ACK 为止这比固定延时 5ms 更可靠也更快。我在项目里最终就用了 ACK 轮询方案实测在批量写配置参数时整体耗时比固定延时方案少了将近一半。EEPROM 驱动本身的接口可以做得非常简单核心就是eeprom_write_page/eeprom_read两个函数配合一个简单的地址换算。如果你用 HAL 库I2C 用阻塞模式或者中断模式都能跑但要注意在中断里做 I2C 事务要小心优先级冲突我习惯在裸机上用阻塞模式 短超时简单可控。3.2 NOR Flash 驱动状态寄存器轮询是效率关键NOR Flash 的驱动模型比 EEPROM 高一个复杂度。以 W25Q64 为例典型操作链是读 ID0x9F→ 写使能0x06→ 擦除扇区0x20→ 轮询状态寄存器0x05→ 页编程0x02→ 轮询完成。擦除和页编程都有一定的执行时间固件不能靠死等必须通过读状态寄存器 S0BUSY 位来判断操作是否结束。代码上我建议抽出一套SPI Flash 抽象层void spi_flash_wait_busy(void) { uint8_t status; do { spi_flash_cs_low(); spi_flash_transfer(0x05); // Read Status Register-1 status spi_flash_transfer(0xFF); spi_flash_cs_high(); } while (status 0x01); // BUSY bit } void spi_flash_erase_sector(uint32_t addr) { spi_flash_write_enable(); // 0x06 spi_flash_cs_low(); spi_flash_transfer(0x20); // Sector Erase spi_flash_transfer((addr 16) 0xFF); spi_flash_transfer((addr 8) 0xFF); spi_flash_transfer(addr 0xFF); spi_flash_cs_high(); spi_flash_wait_busy(); // 轮询直到完成 }这里有个小经验Dual SPI 或 Quad SPI 可以提高吞吐但在工业控制器里如果数据落盘速度要求不是极端高单线 SPI 轮询已经够稳。真正要关注的是写入前擦除、跨页编程拆分这类基础规则否则很容易出现写进去读出来是 0xFF”的诡异现象。如果你在调试时发现 NOR Flash 数据错乱十有八九是没管好写使能和状态轮询。3.3 SD 卡 FATFS挂载容易数据安全靠策略SD 卡这块我建议直接用 FatFs 文件系统库别自己去实现 SD 文件系统。STM32 上 SDIO 驱动 FatFs 的例程网上很多但真正决定工业化可用性的不是能不能挂载”而是掉电后文件系统会不会坏。围绕这个核心问题有几条我在实际项目里验证过的经验打开文件后不要频繁写字节先攒缓冲一次性f_write写完f_sync把缓存刷进物理介质。FatFs 的f_sync相当于业务层的一个落盘点。日志文件建议定长轮转比如log_001.dat写到 10MB 后切换到log_002.dat而不是让单个文件无限增长避免碎片化。挂载失败后要做格式化兜底。SD 卡在长期使用后目录区损坏很常见预留一个f_mkfs的恢复流程在明确提示用户的前提下自动重建文件系统远比现场人工处理好用。用 SPI 模式跑 SD 卡的时候初始化时序要严格按照 CMD0 → CMD8 → ACMD41 → CMD58 的顺序来中途不能乱加延时否则部分卡就是认不出来。如果你在调试里碰到卡能枚举但读扇区错误大概率是初始化时序或时钟分频没有按规范做。3.4 三种介质的驱动接口如何统一为了上层业务好写我在工程里给三种存储介质做了一套统一抽象接口typedef struct { int32_t (*init)(void); int32_t (*write)(uint32_t addr, const void *buf, uint32_t len); int32_t (*read)(uint32_t addr, void *buf, uint32_t len); int32_t (*sync)(void); int32_t (*erase)(uint32_t addr, uint32_t len); } storage_device_t;EEPROM、NOR Flash、SD 卡分别实现这套接口上层只管往哪个逻辑地址写多少字节不用关心介质细节。这看起来像废话但实际项目里写业务的人和有硬件经验的人往往是分离的接口统一后配置管理模块、日志模块、历史数据模块可以并行开发联调成本低很多。4. FPGA 在存储链路里到底该干什么并行采集、协议接管与 DMA 搬运4.1 什么时候必须让 FPGA 参与存储而不是让 STM32 硬扛很多人会问一个问题STM32 本身就带 SDIO 和 SPI为什么还要加 FPGA 来参与存储答案很简单当数据产生速率超过 STM32 单核处理能力的时候CPU 就不能既做采集又做落盘。以高速 AD 采集为例FPGA 并行采样的数据率可能到几十 MB/s 甚至上百 MB/s这时候如果让 STM32 用中断方式一条条读再写 SD 卡CPU 会完全被 I/O 打断业务逻辑全卡死。我在这个项目里的分工是FPGA 负责高速 ADC 数据的并行接收和 FIFO 缓冲先写到片内 BRAM再通过 DMA 或自定义总线把数据块搬到 STM32 的外部 SDRAM最后由 STM32 以块为单位落盘到 SD 卡。这个流程的关键是搬运粒度要足够大一次搬 8KB、16KB 的数据块让 CPU 的介入频率降到每秒几十次而不是每秒几千次系统才有余力干别的。基于 FPGA 的多端口 DDR 读写程序本质就是解决多路数据源向同一个存储体并发写入时的仲裁问题在这个场景里非常典型。4.2 FPGA 写 EEPROM 和 NOR Flash时序模拟的那些细节FPGA 不一定只做数据搬运。如果系统里有某些逻辑需要脱离 STM32 独立运行——比如上电早期就要记录状态或者 CPU 死机后还需要继续写故障日志——那么 FPGA 就必须自己会操作 EEPROM 或 NOR Flash。Verilog 写 I2C 控制器是基本功核心是 SCL 时钟产生、SDA 数据的正确采样/驱动、起始/停止条件、ACK 检测这几个状态机的状态跳转。用 FPGA 读 EEPROM 的代码我在仿真环境里跑过很多遍最需要注意的是时序对齐SDA 在 SCL 高电平期间必须保持稳定否则会把数据线状态误判为起始/停止条件。NOR Flash 在 FPGA 侧的访问也类似把 SPI 的时钟极性/相位配好常用 Mode 0 或 Mode 3发送命令字、地址、数据再轮询 BUSY 位。区别在于FPGA 侧做这些操作往往是在没有操作系统、没有 HAL 库的前提下真刀真枪地写状态机所以testbench的覆盖率就格外重要——我见过太多 FPGA 工程师在写存储控制器时从来不仿真 Flash 时序一上板就对着逻辑分析仪查为什么读回全 0xFF。4.3 双核协同时的总线与缓冲设计STM32 和 FPGA 之间如果用并行总线做数据交互最简单可靠的形式是FPGA 侧做双口 RAM/ FIFO 握手信号而不是让两边同时访问同一个存储颗粒。项目中我在 FPGA 内部实现了两个 4KB FIFO一个用于采集数据上行一个用于配置命令下行。STM32 通过中断知道FIFO 半满/满然后一次性读走。这样既避免了总线竞争也给两个处理器之间加了一层天然背压采集速率超过 STM32 落盘速度时FIFO 满后 FPGA 可以直接丢旧数据并置溢出标志业务层可以根据标志判断数据完整性受损比数据错乱好得多。5. 分级存储的数据流设计与掉电保护兜底5.1 一条数据从产生到落盘的完整链路实际项目中一条工业数据从产生到落盘要经过几个明确的阶段我用一个简单的链路来描述传感器/AD 采样 → FPGA 并行采集与 FIFO 缓冲 → STM32 DMA 读取 → 业务逻辑解析/压缩 → 存储中间层判断介质 → 对应介质驱动落盘。分级存储的分级发生在存储中间层根据数据类型的不同走不同的介质分支。比如设备参数走 EEPROM运行日志走 NOR Flash历史曲线走 SD 卡完全互不干扰。这套链路里最容易出问题的是压缩这一环。很多开发者以为 SD 卡空间大就无所谓直接裸存原始采样结果数据量指数级增长一张 32GB 卡几天就写满了。做一个轻量级压缩比如差值编码、死区剔除可以显著延长存储时间而且对工业波形数据效果很好压缩率通常能做到 5:1 以上几乎不影响实时性。5.2 关键参数写入 EEPROM 时的掉电窗口EEPROM 本身掉电数据不丢但在写入过程中掉电这个窗口内数据可能处于未知状态。工业控制器常用的做法是双备份 校验参数区准备两个槽位写入时先写槽位 A再写槽位 B读取时先读 A 校验失败再读 B。牺牲一点容量换可靠性在这个场景非常值得。我最初偷懒只存一份结果在客户现场遇到一次断电校准系数直接变 0整台设备要重新标定这个教训很深刻。另外初始化时我会在 EEPROM 里放一个魔数版本号比如 0x5A5A每次读写参数前先检查魔数避免把未初始化区域的数据当成有效参数。这个习惯在量产阶段尤其有用——新板子和返修板都可能出现什么都没写过的状态没有版本号保护读出来的随机数据当成参数写入寄存器后果可能很严重。5.3 NOR Flash 的日志磨损均衡与扇区管理NOR Flash 作为日志介质时最怕的就是每次都固定擦写同一个扇区。工业级控制器长时间运行后日志扇区的寿命会被迅速打满。解决思路是软件磨损均衡把日志区划分成多个扇区维护一个当前写扇区序号/偏移每次写完一个扇区就切到下一个循环使用同时在每个扇区的头部记录序列号上电时通过扫描最后一个有效扇区来恢复写位置。这种方式在裸机里实现并不复杂但能显著延长整片 Flash 的使用寿命。我在项目里实际用的日志区结构是日志头4 字节 日志体每条固定长度带 CRC 扇区末尾状态标志。每条日志写完后立即把扇区状态字更新到该扇区已写满。这样即使掉电丢失最后一条日志下一条开始位置也不会错误偏移。5.4 SD 卡掉电保护BUFFER 周期落盘 上电自动修复SD 卡的掉电保护是整个分级存储方案里最棘手的一环。我的实现是三层防护业务层做写缓冲数据先进内存队列达到一定量或固定周期后才调用f_write防止频繁小写然后是传输层用 FatFs 的f_sync确保物理落盘最后是系统层维护一个存储状态描述文件每次正常关机前更新状态异常掉电后上电检测到状态异常自动进入修复流程。工业级 SD 卡本身也有差别普通消费卡在频繁写入和高温环境下寿命会明显下降建议有条件就选工业级卡标称写入寿命更长且具备更强的掉电保护能力。另外 SD 卡是机电/协议一体化设备插拔接触不良比正常磨损更容易导致数据损坏所以板卡上 SD 卡座的质量、防震设计也都算在可靠性考虑范围内。6. 实测踩坑记录从地址冲突到 SD 卡镜像损坏的排查过程6.1 EEPROM 页写回卷导致的参数覆盖第一次联调 EEPROM 参数写入时我发现一个现象写完设备编号后报警阈值莫名其妙变成了设备编号的低字节。排查过程花了大半天最后定位在页写回卷上——AT24C02 页大小 8 字节我当时从地址 0x02 连续传了 10 个字节的配置结构体第 9、10 个字节直接写回了页首地址把之前的数据覆盖掉了。修复方式就是前面提到的按页边界拆分写入或者用结构体填充留白来保证不跨页。这个坑在很多教程里都有提到但实际踩到的时候依然很容易懵因为你对着逻辑分析仪看 I2C 波形发送的地址和数据全是对的就是结果不对。6.2 NOR Flash 写使能被忽略数据写不进去还以为是 SPI 时序问题另一个记忆深刻的坑是 NOR Flash 写不进数据。当时我把 W25Q64 的页编程命令发出去轮询 BUSY 位也正常结束但读回来的数据还是 0xFF。查到最后发现问题出在我漏发了 0x06 写使能命令——W25Q 系列芯片在每次写操作之前都必须先置 WELWrite Enable Latch位否则写命令根本不会生效。这个命令本身一眼就会但在状态机实现里如果写和擦除走的是不同分支很容易漏掉公共前置步骤。建议在驱动里把写使能封装成一个独立函数在擦除、写页之前强制调用一次并在测试中主动验证写使能状态位。6.3 SD 卡在 SPI 模式下初始化失败与镜像制作SD 卡的问题更多出现在初始化阶段。我项目里最初用 SDIO 模式后来为了给其他外设让引脚切换到 SPI 模式结果一开始连 CMD8 都过不了。排查发现两个原因一是 SPI 模式的初始化频率必须降到 400kHz 以下等卡完成初始化后再切换高速时钟二是我在 CMD0 之前没有先发送至少 74 个时钟周期的上电脉冲。这是 SD 卡协议里一个非常容易被忽视的细节网上能搜到很多资料但没人提醒的话光靠看波形确实很难定位。调试 SD 卡还有一个很实用的技巧用读卡器在 PC 上直接对 SD 卡做镜像再用winhex之类的工具查看卡的原始扇区内容。比如你怀疑某个文件系统的 FAT 表写坏了直接看 0 扇区、FAT1、FAT2 的差异就能印证。我在项目里用这个办法排查过好几次上电后文件系统损坏的问题比在板子上不停重新插拔卡高效得多。6.4 FPGA 与 STM32 抢占总线引发的偶发数据错位FPGA 参与存储后还出现过一次非常诡异的偶发数据错位。现象是日志里偶尔出现一条记录的时间戳和内容完全对不上但次数很少几天才一次。最后定位到根因是 FPGA 和 STM32 在共用同一组 SPI 总线访问 NOR Flash 时两个 Master 同时驱动 CS 和 SCLK导致时钟边沿被干扰数据传输错位。修复方案是引入总线仲裁信号在 FPGA 内部加一个 SPI 访问优先级控制器STM32 请求访问时拉高占用信号FPGA 检测到后延迟自己的访问确保同一时刻只有一个 Master 在控制 SPI 总线。这类问题如果没有在多主共线场景仔细设计往往要到现场才会暴露且重现困难排查成本极高。写在最后这套 STM32 FPGA 分级存储方案我从最初一片 Flash 包打天下的想法逐步迭代到 EEPROM、NOR Flash、SD 卡三种介质各司其职的架构中间踩过的坑远比我写出来的多。每次失败都在提醒我一件事存储方案不是能存就行而是要对着数据生命周期、掉电场景、写入频率和寿命预算做精确匹配。硬件篇写到这里下一篇文章我会继续整理 FPGA 和 STM32 之间的具体总线协议设计与数据流测试方法如果你也正在做类似方案可以把当前的数据量级、落盘频率和选型配置发在评论里我们可以一起对对参数。
