自助加注设备主控：
四种流量、三层存储与一套计费逻辑

一、这台设备要做什么

需求本身可以一句话说清：把原液配成成品液，再按升卖给用户。 但把它拆成固件要做的事，就变成四件事同时活着——配液流程、加注计量、收钱记账、联网上报。 任何一件单独看都不难，难的是它们共用同一台设备、同一块屏幕、同一颗 MCU， 而且用户随时可能按取消、拔卡、断电。

我把这台设备的工作拆成下面几块：

• 多路加注：一共四路流量计输入，分属两条售卖区（洗车液区和玻璃水区）。每路一个脉冲计量通道，对应一组加注阀与泵。
• 制液（生产）：把原液、纯水、防冻液、乳化液按流程依次送进混合与储存环节，有自动和手动两种模式；自动模式下一段流程走完才允许进入下一段。
• 按量计费：单价由现场设定，金额由加注量换算得到，再按最小货币单位取整。加注可以是自由加注，也可以是“先设定要加多少”的预置加注。
• 多种支付方式：IC 卡、电子卡、两种扫码支付，以及由平台下发的启动指令。启动方式也分按键、提枪、自动、网络几类。
• 无人值守：每一笔加注都必须有明确的开始与结束，并且记录“为什么停”。我把停止原因分成几大类：正常到量、被限制拦住、用户中断、被异常打断。
• 对外呈现：大面积段码方屏显示价格与升数、语音播报提示、按键与提示音；再通过 4G 把数据报到平台，接收平台下发的指令与升级包。

这台设备里没有复杂算法。它真正的复杂度在“四件事同时活着”： 加注过程中要能显示、要能上报、要能响应按键、要能随时把那笔账记下来。 所以我在这个项目上花时间最多的不是某一项功能，而是决定哪些事可以等、哪些事不能等—— 这件事直接决定了后面的任务划分和存储方案。

二、硬件构成：主控、显示驱动、继电器阵列、键盘扩展、存储、时钟、无线

主控选的是带 FPU 的 Cortex-M4，200 MHz 档，片内 256 KB Flash、192 KB SRAM。 选它的原因不复杂：任务多、缓冲多、显示数据量大，SRAM 小了会很局促； 而这个项目里没有需要 DSP 的运算，FPU 更多是“顺手有”。 下面是这块板子上的主要接口与器件——比起“用了什么芯片”， 我更想说明每个接口在系统里承担什么角色。

有两个设计选择我想单独说一下。第一个是继电器用位掩码而不是逐路开关： 24 路输出打包成几个字节，一次把整帧移出去，这样任何时刻继电器阵列的状态都是自洽的， 不会出现“改到一半被打断、一半新一半旧”的中间态。第二个是 显示和键盘用不同的芯片分开：方屏要的是面积和刷新速度， 小屏加按键要的是省事，两者的诉求不一样，硬凑成一颗芯片反而两头都不合适。

三、计量与计费：从脉冲到一次结算

这是整台设备里我最在意的一段，因为它直接对应钱。 我在这段链路上一共改过三次，最后固定成五步，每一步都只做一件事：

1. 计数：流量计输出的脉冲进 GPIO，累计的只是“脉冲个数”。 这一步不换单位、不乘系数——因为它是唯一不能丢的数据，越简单越好。
2. 换算：按本路标定得到的系数，把脉冲数换成最小体积单位的整数。 每个加注口的系数是各自标定出来的，属于现场标定值，本文不列出。 我在这里坚持用整数最小单位，不用浮点：加注过程是“每来一批脉冲就累加一次”， 浮点误差会随着加注量慢慢积累，而整数不会。
3. 计价：单价由现场设定，金额 = 量 × 单价，同样全程整数运算。 单价是设置项，不是常量。
4. 取整：按最小货币单位取整，整条链路上只做一次， 而且固定放在最末端。这一步的位置是踩过坑之后才定下来的，原因见第七节。
5. 结算：写明细、更新日累/班累/月累、上报平台、语音播报， 最后统一落盘。落盘成功之后这笔交易才算结束。

把链路切干净之后，再看“预置加注”就简单了：预置只是把第 3 步的输入从“用户按停”换成 “达到预置量”。同样地，“大阀提前关”也只是在第 2 步和第 3 步之间插一个比较—— 剩余量还差多少时先关大阀、用小说阀收尾。这里有个必须守住的前提： 提前量、预置量、当前量必须在同一个单位下比较， 否则量一大就会差出一个提前量的误差，这个坑我踩过。

取整我从来不用浮点，也不用 round()。做法是整数版的四舍五入： 先放大到更小的单位，加上半个单位，再整除回来。 这个写法本身是通用惯用法，可以直接给出来；但放大倍数和实际单价取决于标定与现场设定， 下面这段只保留形状，不含本项目的任何数值：

/* 整数四舍五入的通用骨架（按个人理解重写的最小片段）。
   放大倍数 SCALE 与实际单价都由标定和现场设定决定，这里只保留形状。 */
static uint32_t round_div(uint64_t value, uint32_t scale)
{
    uint64_t scaled = value * scale;   /* 放大：把要保留的那几位小数提上来 */
    scaled += scale / 2;               /* 加上半个单位：这一项就是"四舍五入"的那一半 */
    return (uint32_t)(scaled / scale); /* 再整除回来，小数部分自然被舍掉 */
}

为什么值得为一个取整单独写一段代码？因为取整是唯一会让“设备算出来的钱” 和“用户算出来的钱”不一致的地方。把它写成一个纯函数、只有一个入口、只调一次， 出问题时才能一眼看出是哪一步偏了一个最小单位。

四、三层存储与参数体系

这台设备要保存的数据分三类，它们的写入频率和“丢了会怎样”完全不同， 所以我从一开始就没有放在一个地方：

三层存储的分区方式、环形索引怎么算、写坏了怎么发现， 我在《嵌入式存储的三层分工：片上 Flash、EEPROM 与外挂 Flash》 里做了完整整理，这里只说两个当时吃了亏的决定。

不做对半划分，就要接受“偏移量靠人维护”

这块板子的分区没有做对半划分，也没有统一的分区表： 每一类数据各自从一个固定基址开始，基址写在头文件里，注释里还留着一句提醒我 “注意偏移量”的话。好处是简单、直观、一看就懂； 代价是每加一类数据，都要人工挑一个不会撞车的基址，改一处要连带核对好几处。 我在这个结构上犯过一次错，从此把它列为必须返工的项目之一（见第八节）。

环形索引与首次上电判定

明细、日累、月累、班累都是环形存储：各自对“本区能放多少条”取余， 容量是按“要保留多久”反推出来的，具体条数属于工程规划，本文不列。 索引统一用 32 位无符号整数保存——这样就不用再考虑回绕溢出的边界， 代价只是多占几个字节，非常划算。

首次上电的判定我用的是最朴素的一种：读一个约定单元，如果不等于“已初始化”标记， 就遍历把全部出厂值写一遍，最后再把标记写回去。 这个做法和出厂状态判定、参数版本一起，我在 《从样机走到量产，真正缺的是什么》 里写过更完整的取舍，这里不重复。

参数表的四元组

所有设置项放在一张表里，每项四个字段：最小值、最大值、出厂值、类型。 “类型”里同时编码了两件事——这一项保留几位小数，以及改它需要哪一级权限。 这样一来，范围校验、显示格式化、恢复出厂、权限分级这四件事都不需要额外的代码， 全部由这张表推出来。参数表怎么设计、哪些东西不该放进去，我在 《参数表设计：用一张四元组表撑起校验、格式化与权限》 里单独写了一篇，这里只强调一句：参数表里最值钱的不是值，是“这一项归谁管”。

异步存储服务

EEPROM 和 Flash 各有一个存储服务任务，每个任务配一个浅队列， 队列元素就是“地址 + 长度 + 数据”。业务任务只负责投递，不等待写入完成。 这么做是被迫的：EEPROM 跨页写要按页对齐切分，页与页之间必须留出器件写周期所需的时间， 如果在加注流程里直接写，加注会被硬生生卡住。 把“慢介质”包成服务，是这块板子上我最满意的一个结构决定。 具体的页大小和间隔时间按器件手册与实测确定，本文不列。

五、任务划分与实时性

系统跑 FreeRTOS，节拍 1 kHz。任务不是按“模块”分的，而是按 “这件事被谁挡住、挡多久可以接受”分的。下面这张表是分工， 其中优先级与栈深度属于工程整定值，本文不列出数值：

关于实时性，我想说清楚一件事：这台设备没有硬实时要求。 它没有微秒级的控制环，最“急”的事情只有一个——脉冲不能丢。 所以我把脉冲计量放在最靠硬件的一层，业务层按几十毫秒的节奏跑完全够用； 显示慢一帧、上报晚一秒，用户都感觉不到。 真正需要小心的反而是相反的方向：别让某件事把别的都挡住， 这也是存储要做成任务加队列、AT 指令要做成状态机的原因—— 它们都很慢，但都不能阻塞别人。

加注过程中还有一个“无脉冲保护”，用的是软件定时器封装出来的倒计时： 只要加注量有变化就复位，长时间没有新脉冲就判定异常并停机。 这里有一个 FreeRTOS 的坑值得记一笔：定时器创建时的周期不能为 0， 所以只能先给一个占位周期，真正运行前再用修改周期的方式改成实际值。 我第一次写的时候想“创建时先不给周期、用的时候再说”，结果直接创建失败。

排查实时性问题，我在这块板子上最常用的工具不是示波器，而是 FreeRTOS 的栈高水位：它能把每个任务“历史上最少剩下多少栈”打出来。 这个工具是踩了第七节第一条那个坑之后才配上的，装上之后就成了常备手段。

六、升级与版本：为什么镜像要分“主程序版”和“加密版”

这个项目从第一天起就编两个镜像：主程序版和加密版。 一开始我以为这只是“发布前多一步”，后来才明白它们解决的是两个不同的问题。

• 主程序版：用来开发、调试和产线验证。保留高速率打印口， 保留各种可以单独打开的调试开关，参数可以随便改，出问题能看见。
• 加密版：用来发布。打开芯片保护，关掉打印与调试口， 参数与授权校验生效。它的目标不是“跑得更快”，而是 让“读出内部状态”这件事变成一个需要授权的动作。

为什么必须分开，而不是“编一个版本、发之前记得关掉打印”？ 因为人会忘。留一个调试口在现场，除了占资源，更实际的风险是 任何人接上串口就能看到设备的内部状态。 分成两个镜像之后，“发的是哪一版”变成了一个不会靠记忆保证的事实。 这件事的完整清单——版本号要能被读出来、出厂状态怎么判、参数要保证设备永远能开机、 看门狗为什么总排到最后——我写在 《从样机走到量产，真正缺的是什么》 里，这里不再展开。

还有一条经验：软件版本必须能通过显示或通信读出来。 现场那台设备究竟烧的哪一版，如果只能拆机看，那么“版本管理”实际上等于没有。 版本号本身属于工程记录，本文不列具体取值。

七、问题与解决

下面六条是这台设备上我确实踩过的坑，按“现象 → 原因 → 办法”记。 它们有一个共同点：现象看起来都像别的问题。

另外还有三条小一些、但同样值得记的：

• EEPROM 连续写必须留间隔。跨页写时，如果一页接一页地写下去， 后面那些页会写失败。原因是器件的内部写周期还没结束就不再响应。 我的做法是按页对齐切分，页与页之间、整笔写完之后都留出间隔 （具体时长按器件手册与实测定），并在存储服务里用阻塞延时兜底。
• 语音播报和平台数据会抢同一路串口。这个问题我至今没根治， 只是用一个小的播放请求队列做了缓解（见第八节）。
• 看门狗一直没有真正启用。喂狗调用是存在的，但被注释掉了， 所以掉电或死机时的保护实际上依赖“记录停止原因”，而不是硬件复位。 这是一件我知道该做、但必须先把所有长耗时路径都理一遍才敢做的事。

八、局限与还没做完的部分

功能是实现了，但我不认为它到了“可以放心交给别人用”的程度。 下面每一条都是我知道问题在哪、只是还没动手改的：

把“没做完”写出来并不舒服，但我觉得这比含糊地说一句“运行稳定”要诚实得多。 如果只能先解决一件，我会选看门狗：它不优雅，但它决定了设备在异常时 能不能自己回来，而这比存储分区是否规整重要得多。

参考资料与说明

• FreeRTOS 官方文档中关于任务、软件定时器、栈溢出检测与栈高水位的章节，用于确认任务划分与排查手段。
• 所用 MCU 的公开用户手册（时钟、USART、SPI、I2C、AES 章节），用于确认外设配置与外设资源。
• 24C 系列 I2C EEPROM 与 GD25Qxx 类 SPI Flash 的公开数据手册，用于确认页大小与器件写周期。
• 74HC595 / 74HC165 公开数据手册，用于确认串行级联与并转串的时序。
• PCF8563 类实时时钟芯片的公开数据手册，用于确认 I2C 读写方式。
• 4G 模组的公开 AT 指令手册（TCP/MQTT 与语音播报相关命令），用于确认状态机中每一条指令的应答格式。
• 文中出现的芯片内核与器件类别仅用于说明技术方案，与相关厂商无隶属或授权关系。
• 示例代码为按个人理解重写的最小片段，不代表任何产品或交付代码； 其中单价、标定系数、时间参数、权限密码、分区基址均不在本文范围内。
• 出于对个人项目实现细节的保护，本文只公开方法与思路； 涉及核心实现的部分以步骤与字段说明代替代码，示例代码为按个人理解重写的通用片段。