4. 数据采集设备存储需求分析
做数据采集设备这么多年，我最大的体会就是：存储分区没规划好，后面全是坑。你想想看，一台设备在野外跑几个月，突然日志把 Flash 撑爆了，固件升级失败变砖头，或者关键配置数据丢了——这些我都遇到过。
所以这一章，咱们把存储需求掰开揉碎了讲。说白了，就是搞清楚每种数据该放哪、该给多大空间、该怎么保护。
4.1 四大存储角色
数据采集设备里，存储需求可以归为四类。我习惯用一张图来理清它们的关系：
核心观点：日志、配置、固件、缓存，这四类数据的生命周期、访问频率、可靠性要求完全不同。分区规划必须「因材施教」。
4.2 日志存储：循环覆盖的艺术
日志这东西，说重要也重要，说不重要也真不重要。我见过有人给日志分了 64MB，结果三天就写满了，设备直接卡死。也见过只给 256KB，啥都查不到。
关键需求：
- 循环写入：日志必须支持环形缓冲区，写满自动覆盖最旧的数据
- 可靠性中等：丢几条日志不会死机，但不能因为写日志把系统拖垮
- 实时性要求低：可以攒一批再写，减少擦写次数
我的经验：日志分区大小 = 日均日志量 × 保留天数 × 1.5。比如一天产生 512KB 日志，想保留 7 天，那就分 5.5MB 左右。别抠门，留点余量。
分区建议：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| 分区大小 | 4MB ~ 16MB | 取决于日志级别和采样频率 |
| 文件系统 | FAT16 / LittleFS | 轻量级，支持循环写入 |
| 写入策略 | 批量写入（每 10 秒或 1KB） | 减少 Flash 擦写次数 |
| 保护机制 | 写满自动覆盖 | 永不阻塞主流程 |
⚠️ 我曾经踩过的坑：有一次日志分区用了同步写入，每条日志都直接刷盘。结果设备在高频采样时，CPU 有 30% 的时间都在等 Flash 写入。后来改成异步批量写入，CPU 占用直接降到 2%。记住：日志不能拖累主业务。
4.3 配置存储：丢了就完蛋
配置数据不一样。设备校准参数、网络配置、用户设置——这些东西丢了，设备就得返厂重新标定。我有个客户，就因为配置分区掉电损坏，200 多台设备全部需要现场维护，那叫一个惨。
关键需求：
- 高可靠性：必须支持掉电保护，写入过程中断电不丢数据
- 原子更新：要么全部写成功，要么回滚到上一个有效版本
- 频繁度低：配置一般几个月才改一次，不用考虑磨损均衡
我的做法：配置分区用双备份方案。A 区存当前配置，B 区存上一次有效配置。每次写入先写 B 区，校验通过后再更新 A 区。如果写入 B 区时断电，下次启动自动从 A 区恢复。
分区建议：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| 分区大小 | 64KB ~ 256KB | 配置数据通常很小 |
| 文件系统 | Raw / 专用配置管理 | 不需要通用文件系统 |
| 备份策略 | 双备份 + CRC 校验 | 确保数据完整性 |
| 保护机制 | 掉电保护 + 原子写入 | 硬件层面保证 |
小技巧：配置分区最好放在 Flash 的独立扇区，不要和日志、缓存混在一起。这样即使日志分区写坏了，配置还能完好无损。
4.4 固件存储：安全升级是底线
固件分区，说白了就是设备的「系统盘」。我见过太多设备因为固件升级失败变砖头了。原因无非就两种：升级过程中断电，或者新固件有 bug 启动不了。
关键需求：
- 双备份：至少保留两个固件版本，一个运行，一个备用
- 安全升级：升级过程中断电，还能从备份区启动
- 完整性校验：每次启动都要检查固件 CRC，不对就回滚
分区建议：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| 分区大小 | 固件大小 × 2 + 256KB | 双备份 + 升级临时区 |
| 文件系统 | Raw 分区 | 直接寻址，启动加载器直接读取 |
| 备份策略 | A/B 双区 + 回滚机制 | 确保永不 brick |
| 保护机制 | 写保护 + CRC 校验 | 防止误写入 |
⚠️ 血的教训：有一次我图省事，固件只分了单区。远程升级到一半，网络断了，设备重启后直接变砖。后来花了三天时间挨个拆机烧录。从那以后，我所有项目都强制要求双备份，谁劝都不好使。
4.5 数据缓存：大容量与磨损均衡的博弈
数据缓存是采集设备的核心。传感器数据、采集结果、待上传的数据——这些都在缓存区里。这块分区最头疼的问题就是：写得太频繁，Flash 寿命扛不住。
关键需求：
- 大容量：至少要能缓存几天的数据，防止网络中断时丢数据
- 磨损均衡：频繁写入必须均匀分布到所有存储块
- 掉电保护：写入过程中断电，不能丢已有数据
分区建议：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| 分区大小 | 32MB ~ 256MB | 取决于采样率和上传频率 |
| 文件系统 | FAT32 / SPIFFS / LittleFS | 支持磨损均衡 |
| 写入策略 | DMA + 缓存对齐 | 提高写入效率 |
| 保护机制 | 日志结构写入 + 掉电恢复 | 保证数据一致性 |
核心算法：缓存分区建议使用「日志结构文件系统」（LFS）。每次写入都追加到新位置，而不是覆盖旧数据。这样既实现了磨损均衡，又天然支持掉电恢复。我自己的项目里，用 LFS 后 Flash 寿命从 2 年延长到了 8 年以上。
4.6 分区大小估算：一个实际案例
光说理论不够，咱们来个实际的。假设一台环境监测设备，配置如下：
- 采样频率：1 次/秒，每次 512 字节
- 日志级别：INFO，日均 1MB
- 固件大小：2MB
- 配置数据：8KB
- 网络上传：每 6 小时一次
分区规划：
| 分区 | 大小 | 计算依据 |
|---|---|---|
| 日志 | 8MB | 日均 1MB × 保留 5 天 × 1.5 余量 |
| 配置 | 128KB | 双备份 + 预留扩展 |
| 固件 A | 2.5MB | 固件 2MB + 头部/校验 |
| 固件 B | 2.5MB | 备份区 |
| 缓存 | 64MB | 6 小时数据约 10MB，留 6 倍余量 |
| 总计 | ~77.6MB | 选 128MB Flash 芯片 |
我的习惯：算完理论值后，再乘以 1.5。因为产品迭代过程中，日志量、固件大小只会涨不会跌。留够余量，后面少改版。
4.7 分区布局的物理约束
最后说点硬件层面的东西。Flash 芯片不是随便怎么分都行的。有几个硬约束你必须知道：
- 擦除块大小：NOR Flash 通常是 4KB 或 64KB，NAND Flash 是 128KB 或 256KB。分区边界必须对齐擦除块。
- 写入寿命：NOR 约 10 万次，NAND 约 1 万次。缓存分区必须考虑磨损均衡。
- 读取速度：固件分区建议放在 NOR Flash 上，支持 XIP（原地执行），启动更快。
⚠️ 硬件选型建议：如果预算允许，我强烈建议用双 Flash 方案：一片小容量 NOR（4MB~8MB）放固件和配置，一片大容量 NAND（128MB~1GB）放缓存和日志。这样固件启动快，缓存容量大，各取所长。