从立项到今天正式进入量产这个 BC26 NB 室温采集插座终于让我有底气写点东西了。项目本身不复杂但涉及的链路很长温度采集、NB 模组控制、低功耗调度、云端通信、产测校准每一环都会在量产阶段变成新的麻烦。今天不聊市场也不聊外壳专门讲讲这套固件的源代码是怎么组织的以及开发过程中那些差点让我放弃的插曲。这篇内容适合正在做 NB-IoT 产品、准备量产、或者想了解 BC26 模组实际工程用法的朋友。我会把代码设计思路、关键实现、踩坑记录都摊开来说尽量少用行业黑话遇到必要概念我会解释到能直接上手为止。1. 固件整体架构把插座拆成“会睡觉的采集终端”来设计1.1 这个插座本质上是什么你可以把 BC26 NB 室温采集插座理解成三样东西的组合一个能通断电路的继电器模块、一个高精度温度传感器、以及一个能定时把温度数据送到云端的 NB 通信模组。当时我们定的功能基线很简单插座每 30 分钟上报一次室温支持远程通断电空闲时进入低功耗状态电池供电情况下能撑一年以上。这个目标直接决定了软件架构的写法——一切都围绕“活下来、按时醒、说清楚”展开。在业务逻辑上固件采用的是“唤醒-采集-上报-休眠”循环模型。正常工作时长只占几秒其余时间处理器和 BC26 模组都必须处于低功耗状态。源代码里最核心的就是管理这个状态迁移的调度器。1.2 状态机让不可控的网络变成可控的程序流程NB-IoT 网络最大的特点就是不可控。信号可能时好时坏基站可能暂时拒绝附着核心网可能在半夜升级这些都会导致指令卡死。如果代码是顺序执行的一条 AT 指令等了 20 秒没回复整个设备就废了。所以我第一件事就是把固件写成状态机核心状态只有四个INIT、WAKE、JOIN、SLEEP外加一个ERROR兜底。typedef enum { STATE_INIT 0, STATE_WAKE, STATE_JOIN, STATE_SLEEP, STATE_ERROR } system_state_t;一开始可能觉得没必要一个插座而已干嘛搞这么复杂但当你发现设备部署后经常失联回来查日志才发现程序死等一条 AT 指令时就会后悔没早点上状态机。状态机的价值在于每一个等待都有超时每一个超时都有去处。这比任何调试技巧都重要。1.3 目录结构量产固件需要“可维护”而不是“能跑”很多工程师在原型阶段喜欢把所有代码堆在一个 main.c 里几百行函数上下翻开发确实很快。但我们这套固件从第一天起就按功能分目录原因很简单到量产阶段你会面临产测改代码、客户定制改代码、测试反馈改代码一个人维护一堆 3000 行的 C 文件是灾难。我们的源码结构大致如下app/ ├── main.c ├── state_machine.c ├── business/ │ ├── measure.c │ └── report.c └── drivers/ ├── bc26_uart.c ├── bc26_at.c ├── ntc_adc.c └── flash_param.cbusiness层放业务逻辑比如多久采一次温、数据怎么拼包drivers层放外设驱动比如 BC26 的 AT 指令交互、ADC 读取。业务不直接操作寄存器驱动也不管业务逻辑。这样改上报协议时不必碰传感器代码换传感器时不会动 NB 通信。实测下来分工清楚以后 Bug 定位速度快了不止一倍。2. BC26 通信模块源码一条温度数据从设备到云端的完整链路2.1 BC26 的初始化与网络附着流程BC26 是移远的 NB-IoT 模组采用 AT 指令控制。固件上电后第一件事不是立刻上报而是要给模组留出启动时间然后开始初始化流程。实际工程中我封装了一个bc26_at_send()核心函数所有指令都走它发送数据、等待应答、超时重试。int bc26_at_send(const char *cmd, const char *expect, uint32_t timeout_ms) { char buf[256] {0}; uint32_t elapsed 0; uart_flush_rx(); uart_send_str(cmd); while (elapsed timeout_ms) { if (uart_rx_line(buf, sizeof(buf)) 0) { if (strstr(buf, expect) ! NULL) return 0; } delay_ms(10); elapsed 10; } return -1; }这里有个关键点不能傻等一条指令发完再发下一条而是每发一条就要确认回复符合预期。例如初始化流程我们用的指令序列如下步骤AT 指令预期应答说明1ATOK通信握手2ATCFUN1OK打开射频功能3ATCGATT?CGATT:1查询是否附着网络4ATCEREG?CEREG:1查询是否注册成功5ATCSQCSQ:xx查询信号强度6ATCOPS?COPS:0确认运营商网络BC26 的启动和附着不是瞬间完成的尤其在地下室或者弱信号环境里附着可能耗时十几秒。所以初始化必须有耐心失败就把状态机踢回到重试通道重试次数超过设定值再进入ERROR状态。2.2 数据上报为什么用 UDP 而不是 TCPNB-IoT 传数据的方式有很多种但我们最终选的是 UDP CoAP 格式BC26 内部本身有 CoAP 协议栈直接用指令ATNMGR和ATNQMGR等管理数据比较省电。要知道 TCP 在高延迟的 NB 网络里建立连接太昂贵每次上报几秒钟的功耗都比传感器采集大得多非必要不要用 TCP。实际代码里我们做了一个简洁的报文封装统一上报温湿度、电量、信号值、设备状态。每条 payload 只有 20 字节左右。typedef struct { uint8_t cmd; uint32_t temperature_x100; uint32_t voltage_mv; int8_t signal_rsrp; uint8_t flags; } report_t;拼包时有个值得分享的教训NB-IoT 网络传输速度慢、单位流量贵所以字段能压缩就压缩。温度保留两位小数我们直接存temperature_x100用整数 2501 表示 25.01℃省掉了浮点数传输。这条看起来土气的优化让整个模块的报文长度缩短了 30%低功耗效果显著。2.3 掉网重连藏在源代码里最耗费精力的部分量产之后你会发现插座安装位置的信号千差万别有的在弱电箱里有的在铁皮电表箱后面。BC26 偶尔会掉网这时如果不去查模块状态数据就一直静默。我们为了让系统够健壮每次上报前都会先检查状态if (bc26_check_registration() ! 0) { state_machine_set(STATE_JOIN); return; }然后在STATE_JOIN状态里反复执行ATCGATT1并设置重试上限。这样做之后设备基本做到“只要网络恢复两分钟内必定自动回网并补报数据”。我见过不少项目死在这上面模组掉网后不复位、重连产品就直接变砖这也是量产设备的常见死法。3. 室温采集代码不是读个 ADC 这么简单3.1 热敏电阻采样与查表法我们这个插座用的是 NTC 热敏电阻做温度采集因为它便宜、稳定、够用。电路上就是一个 NTC 跟 10kΩ 精密电阻分压然后进 MCU 的 ADC。ADC 采样值首先换算成电压然后反推 NTC 电阻阻值再通过温度阻值表查温度。NTC 的阻值和温度不是线性关系所以我提前做了一张 0℃ 到 60℃ 的电阻-温度对照表。代码不用算数学公式直接线性插值float ntc_to_temperature(uint16_t adc_value) { uint32_t rntc resistance_from_adc(adc_value); // 查表并做线性插值返回温度单位 ℃ return table_lookup(rntc); }有一个细节要注意NTC 的供电最好用 MCU 引脚控制只有采集时才给传感器供电采完立刻断电。这样避免了传感器持续耗电。代码里就是一组 GPIO 操作但省下的电量非常可观。3.2 软件滤波与多点多批校准室温不是恒定不变的空调开一下温度波动半度都很正常。但云端如果看到数据一直在 25.12℃、25.13℃、25.09℃ 这样跳用户体验会很差。我们做了两个处理连续采 5 次去掉最大值和最小值取中间 3 次的平均值叠加一阶低通滤波让温度变化曲线平滑。代码上大概是这个模式float smooth_temp 0.0f; #define ALPHA 0.3f smooth_temp ALPHA * current_temp (1 - ALPHA) * smooth_temp;滤波会让响应变慢但室温本身就属于慢变量慢一点反而更真实。真正需要看重量的还是产测校准我们的做法是产线用恒温槽设置 25.0℃读取采集读数生成两个校准系数存进 Flash。量产设备全部过一遍才能保证“每台设备温度差都在 ±0.5℃ 以内”。3.3 把插座自身发热从数据里抠掉这是开发中最开始没料到的坑。插座通电后继电器线圈、电源模块、甚至 MCU 自身都会发热。如果传感器离这些发热源太近采集到的温度可能比真实室温高两三度。解决思路有两个硬件上尽量把 NTC 放到插座边缘远离继电器软件上做“待机补偿校准”在不通电情况下采一批基线数据并测试通电后的温度偏差写进算法里。这个没办法给通用公式因为外壳、结构、布局都影响热阻但我建议每个项目都用实测数据建一次热补偿模型。我们到最后测下来通电 2 小时后的热偏差能被补偿到 0.3℃ 以内。4. 量产固件里的那些“看不见的细节”低功耗、Flash 存储与看门狗4.1 低功耗的矛盾BC26 待机电流与 PSM 模式BC26 模组本身支持 PSMPower Saving Mode省电模式和 eDRX扩展非连续接收。PSM 模式下模组几乎“假死”电流降到微安级别但代价是云端无法随时下行控制它。我们的插座本来就不是强交互设备所以大胆开了 PSM。固件里设置 PSM 的指令类似ATCPSMS1, , , 00100001, 00000011含义是允许 PSM并且设置了 T3324 定时器。不熟悉 AT 指令的朋友先不用背参数重点是知道原理PSM 模式下模组仍然附着网络但进入休眠只在 TAU跟踪区更新时间到才醒一下。这里最怕的是云端的“远程控制”需求。如果你要做实时响应的智能插座PSM 会害死你因为下行数据根本推不进来。我们的解决方式是上报间隔刚好是 30 分钟用户远程控制时设备会在下一次上报后执行动作实时性要求高的功能全部砍掉。4.2 Flash 存储固件如何记住自己的“身份”量产固件必须处理掉电保存。设备重启后要记得自己是哪个型号、批次号是多少、上报过哪些数据。这些数据和普通变量不一样必须写进 Flash。我用 Flash 分了两块区域区域存储内容参数区设备 ID、批次号、校准系数、上报间隔日志区最近 10 次运行状态、错误码、信号值Flash 写入次数有限制所以不能每次上报都写日志。我们的策略是只在状态异常时写日志正常运行最多 2 小时写一次参数。这样做既保留了现场信息又不会把 Flash 写穿。4.3 看门狗量产设备最后的保命符开发时你可能觉得主频高、逻辑简单死循环不至于。量产之后各种极限情况就来了弱信号导致模组频繁重连UART 缓冲区溢出甚至一次静电干扰让 MCU 跑飞。没有看门狗的设备出问题后只能断电恢复这绝对不行。我强烈推荐双保险内部看门狗IWDG负责 MCU 级死循环外部看门狗如果有负责模组级异常。在源代码里喂狗的位置也很讲究不能在主循环随意喂最好在“完成一轮正常调度”后喂。如果状态机卡在某个状态狗就会超时复位让设备重新初始化。4.4 软件升级预留哪怕现在用不上量产固件上通常都有 OTA 的影子。也许你现在觉得没必要但设备卖出去后如果发现传感器校准算法有 Bug总不能全量召回。BC26 模组本身支持通过 NB 网络下载固件但通道带宽很窄所以我们把方案简化为“双区备份 差分升级”固件运行时存在 A 区升级包写入 B 区校验通过后切换启动。代价是 Flash 占用翻倍但可靠性和可维护性值回票价。源代码里预留了一个fota.c的空实现以后接平台时可以快速填坑。5. 开发小插曲从熬夜到量产那些差点让人崩溃的 Bug5.1 插曲一PSM 唤醒后 UART 丢数据设备进入 PSM 后BC26 的串口不再主动发数据。醒来后如果 MCU 立刻发 AT 指令模组可能还没来得及把串口唤醒导致发送的数据丢失。我们第一次遇到时设备表现为“上报成功率只有 70%”但手动调试时一切都正常。后来定位到正是唤醒瞬间串口时钟未稳发送太快。修复方法很简单模组唤醒后加 50ms 延时再发第一条指令。代码里就是这个改动让成功率一下子回到 99.9%。这个小问题提醒我模组与 MCU 的时序也是代码的一部分不能只看逻辑还要看信号时序。5.2 插曲二批量部署时一半设备不上报小批量验证时一切正常但第一批 500 个设备装出去后台发现约一半没上报。查日志发现这些设备信号强度很差有的根本没附着网络。最初我们以为这是信号覆盖问题让运营商的工程师跑了几趟基站后来才发现问题出在出厂程序上产测时模组附着网络成功一次后固件把网络状态存进 Flash用户使用时直接读取“已附着”状态导致真正的初始化流程被跳过。这样只要设备挪了地方、网络参数变了它就用错误的状态去上报。解法也直接每次上电都强制重新附着不信任任何存储下来的网络状态。这个经验也许不算高级但它挽救了一大批设备。5.3 插曲三一个 printf 引发的功耗灾难原型开发时为了调试方便我们在代码里加了很多串口打印。一切正常直到测功耗时傻眼设备电流比预想高了十几倍。原因是改造之后打印模块忘了关掉MCU 每次上报都在通过串口输出几百字节日志长时间占用 UART 和 Flash导致睡眠状态也无法进入。解决办法是加了一个调试宏#ifdef DEBUG_ENABLE printf([TEMP] %d.%02d ℃\n, ...); #endif量产固件编译时直接关掉DEBUG_ENABLE。这是老生常谈但越是赶进度越容易忘。5.4 插曲四云端收到的“重复数据”与设备时间最后说说数据幂等的问题。NB 网络不稳定时我们的 CoAP 报文可能重发云端会收到重复数据。要解决这个问题上报报文里必须带一个递增的序列号或者时间戳云端按“设备ID序列号”去重。设备本身没有 RTC或者 RTC 不准怎么办我们的做法是每次上报成功后从云端回复里获取服务器时间校准本地 RTC。代码里就是一条ATNTP指令的事但很多小项目会忘记做结果数据时间错乱后台图表惨不忍睹。6. 尾声量产源代码的取舍之道如果你问我这套源码最值得分享的是什么我会说是“克制”。量产代码不追求炫技它追求的是可预测每个函数都有明确的输入输出每个状态都有超时退出每个外设都有错误的兜底。开发阶段多花点时间把状态机设计清楚把打印口控制住把 Flash 读写策略理顺量产后你的命会好很多。BC26 这款模组本身能力有限但配合 NB 网络做低功耗、小流量、低频率的采集场景非常合适。室温采集插座只是其中一个例子同样的代码骨架你换成水浸传感器、烟感、地磁检测器只需要改业务层即可。最后再给一个很实用的小建议量产固件在合入代码前一定要留出至少一周的“老化测试时间”在弱信号环境、高温环境、电压波动环境下持续跑所有日志都保留。你真不知道哪一天某个莫名其妙的掉线 bug会靠这一周的老化数据才暴露出来。祝大家的量产路都比我们顺利。