上一版控制器还在用 NTC 热敏电阻做温度采集，这次趁产品改版，我把本地和远程温度监测一起重做了一遍：本地侧用数字温度传感器 PJ85718DM 直接采送风、回风温度，远端用 R7FA6E2BB3CFM 微控制器把采集结果通过通信口定时上送，嵌入式 HVAC 场景里常见的温度读数漂移、干扰跳变、远程上报延迟问题，这版基本都解决了。如果你正在做空调箱、新风机组、冷库控制器，或者任何需要"现场看温度 + 后台看温度"的设备，这篇就把我的选型思路、硬件布局、软件写法和踩坑记录一次说清楚。

1. 先把需求拆开：本地温度与远程温度不是一回事

1.1 HVAC 现场到底要测哪些温度点

做暖通空调控制器的人，第一反应是"测温度嘛，随便一个传感器就行"。真正上手才会发现，HVAC 现场的温度点少则三五个，多则十几个，而且每个点的监测目的完全不一样。

我这次改版的项目是一台组合式空调箱的控制器，需要测风管内送风温度、机组回风温度、盘管进出口温度，另外还要预留两个扩展口给冷水/热水管表面温度。送风温度直接参与 PID 调节，要求响应快、抖动小；回风温度用于判断室内负荷，更新慢一点没关系，但长期稳定性必须好；盘管温度要能扛住低温环境，传感器本身的测量范围得足够宽。

除了本地这些点位，甲方还要求每台机组能在远程监控室看到实时温度曲线，超过阈值要弹告警。所以这个系统天然分两层：本地温度用于实时控制，远程温度用于运行监视。两者对数据的要求完全不同，这在方案设计一开始就要分清。

1.2 为什么不能拿一套流程同时处理本地和远程数据

不少人在做这类项目时，习惯把所有温度数据统一打包，然后一股脑往上送。这会导致两个问题：一是控制周期变慢，本地 PID 需要几十毫秒到一两秒更新一次，如果每次都等远程链路确认，风阀和变频器早就抖成筛子了；二是通信中断时本地控制跟着瘫痪，这是现场绝对不允许的。

我采用的思路是：本地控制和远程监视为两条独立数据路径。PJ85718DM 传感器通过 I2C 接到 R7FA6E2BB3CFM，MCU 内部维护一份"当前实时温度"状态；本地控制逻辑直接从这份状态里拿数据，以最快周期运行；远程监控模块则按自己的节奏把同一份数据序列化后往外发，发送失败就缓存重试，绝不反过来影响本地控制。这样哪怕远程链路断了，本地风机、阀门、压缩机的联动逻辑照样稳稳运行。

这个"一份数据、两条路径"的模式，是我在整个项目里最满意的一个设计决策，后面所有软件结构都是围绕它展开的。

2. 器件选型复盘：PJ85718DM 和 R7FA6E2BB3CFM 搭配的底气在哪

2.1 温度传感器选型对比：数字 I2C 方案赢在哪

项目立项时先做了一轮传感器选型，候选方案有四类：热敏电阻、PT100 铂电阻、消费级数字温湿度传感器、精密数字温度传感器。下面这个表是我在实际项目里会用到的对比维度：

选 PJ85718DM 而不是 NTC 最直接的原因，是 I2C 数字接口省掉了大量校准工作。NTC 看起来便宜，但每个测点都要独立分压电路、独立 ADC 通道、软件还要做 Steinhart-Hart 方程标定，批量生产时每块板的电阻误差和 ADC 零漂都会吃掉精度，最后省下的 1 毛钱全在人工校准里还回去了。PJ85718DM 这类传感器出厂时已经把内部 ADC、基准源和温漂校准逻辑都做好了，我这边读寄存器就是温度，连续测温的一致性立刻上一个台阶。

2.2 主控 R7FA6E2BB3CFM 为什么够用且合适

主控选择上，我没有继续用以前习惯的老型号 8 位单片机，而是选了 R7FA6E2BB3CFM 这颗基于 Arm Cortex-M33 内核的微控制器。选它有几个现实考虑。

第一是温度监测本身的数学需求。本地温度数据要做滤波、迟滞比较、PID 运算，8 位机虽然也能跑，但内存和定时器资源经常捉襟见肘。Cortex-M33 内核带 DSP 扩展，跑一阶滤波和 PID 指令执行快得多，调试时用调试器看浮点变量也更直接。

第二是外设资源对接 I2C 和远程通信很顺。PJ85718DM 走 I2C 接口，正好用 MCU 的硬件 I2C 控制器，省 CPU 时间；远程上送数据则根据甲方现场条件选 RS485 串口或者以太网，这颗芯片在串口和通信外设上的配置灵活性足够覆盖两种现场。加上休眠功耗和运行功耗的平衡，对户外的风柜控制柜来说也友好。

我还考虑过用更便宜的 MCU 加模拟传感器来压成本，但算上开发时间、维护成本、现场校准时的人工成本，性价比反而不如这套组合。选型的本质不是选最便宜的器件，而是选总拥有成本最低的方案。

2.3 传感器与主控的接口匹配检查

这里有一个容易被新手忽略的点：I2C 总线上的地址空间和信号电平。PJ85718DM 的 I2C 地址一部分是固定地址，还会留一两个引脚用来扩展地址。多路传感器共用总线时，必须确认每颗传感器能配出唯一地址。

电平方面，PJ85718DM 的工作电压范围与 R7FA6E2BB3CFM 的 VCC 域要一致，避免 I2C 引脚直接接在不同电平造成闩锁。我在这块板上统一用 3.3V 供电，传感器和 MCU 共地，上拉电阻各接一颗到 3.3V，接口电平的坑从源头避开。

3. 硬件设计细节：I2C 总线抗干扰才是这单活儿的真正难点

3.1 传感器安装位置与 PCB 布局的经验

硬件上第一件事不是画原理图，而是定传感器的物理安装位置。一开始我犯过一个错误——把第一颗 PJ85718DM 摆在 MCU 旁边，心想走线短、信号好。结果实测发现 MCU 自身发热会把 PCB 局部温度抬上去，传感器读数比风管实际温度高了两三度。这是很多嵌入式温度监测项目都会踩的通病。

正确做法是让传感器尽量靠到测温点一侧，比如风管内测温的探头通过延长线引出，PCB 上的传感器则布置在远离功率器件、变压器、MCU 散热区的位置。如果一定要板载安装，PCB 上要在传感器周围做热隔离，把传感器下方的铜皮尽量镂空，减少地平面热传导。

传感器封装方向也要注意，读到的温度实际上是器件自身引脚和封装温度，和空气接触的面积越大、热阻越低，响应越快。有条件时优先选用带引脚的插装形式做风管测温，板载贴片传感器只用于测控制柜环境温度——这两类用途要区分开，混用会导致响应时间严重失真。

3.2 I2C 上拉电阻与总线长度怎么定

I2C 总线是漏极开路结构，必须有上拉电阻，阻值不是随便抄一个 4.7k 就完事。阻值太小，灌电流变大，传感器和 MCU 的 I/O 驱动能力可能不足；阻值太大，总线上升沿变慢，高速模式下波形失真。常规 3.3V 系统、总线上挂 2~4 个器件、走线长度在 10~20 cm 时，上拉电阻选 4.7k 比较稳妥；如果传感器通过延长线拉到几十厘米外，总电容变大，就要降到 2.2k 甚至 1.8k，否则时序会出错。

我这次在板上有两颗 PJ85718DM，总线总长约 15 cm，选了 3.3k 上拉，实测波形上升沿干净，通信零错误。如果总线要跨接器连接器再接延长线，建议在连接器两端的板子上各放一组上拉电阻，但要注意等效阻值会并联，计算时按并联后的总阻值评估。

3.3 HVAC 环境里的干扰源与防护手段

HVAC 控制柜内部的电磁环境远比普通消费电子产品恶劣。继电器吸合、变频器驱动风机、感性负载通断都会在电源线、地线上灌入尖峰噪声，I2C 这种共享总线一旦被干扰，典型表现是读到的温度值偶尔变成全 1 或全 0，或者总线直接锁死。

这次在硬件上做了四层防护。第一，I2C 两根线串联 33Ω 电阻，靠近 MCU 端放置，限制振铃电流；第二，SCL/SDA 对地各并一个 100pF 滤波电容，把高频噪声滤掉，前提是线上拉阻足够小、容性负载还能接受；第三，PJ85718DM 供电脚加 100nF+10µF 两级去耦电容，防止电源轨上的噪声通过 VCC 串进传感器；第四，I2C 布线尽量短且远离继电器驱动线路和开关电源走线，如果必须平行走线，用地线隔开。

做完这些处理后，我在现场用继电器反复通断负载做测试，温度读取错误率从千分之一量级降到完全可忽略。这里也建议大家在打样后专门做一次传导干扰测试，这个环节省钱不得。

3.4 多传感器组网的接线方式

HVAC 系统温度测点多，我用了"一条 I2C 总线带多个 PJ85718DM"的方式组网。每个传感器通过 ADDR 引脚配置出唯一地址，尽量减少总线上重复地址的概率。原理图连线就是标准 I2C：SCL、SDA、VCC、GND 四根线并接，两根信号线上各接一颗上拉电阻到电源。

如果需要测点的物理距离非常远，比如超过一两米，I2C 就不合适了。这种场景我的建议是每个远程测点放一片独立的 MCU 接传感器，转换成 RS485 总线再汇聚到主控板。这个方案虽然多几颗芯片，但抗干扰能力和布线距离都大大提升，更适合真正的"远程温度"需求。

4. 软件实现：一边喂实时控制，一边走远程上报

4.1 驱动层：把 PJ85718DM 的寄存器读写封装成稳定接口

软件第一层是传感器驱动。要封装的功能不多：初始化、读温度、读错误状态。初始化里最关键是确认器件地址并写一下配置寄存器，把转换分辨率调到项目需要的档位，同时设置转换模式。HVAC 场景里不需要一路全速转换，设置成普通模式或者按需单次转换就足够了，既能省电，又能减少总线上不必要的数据流。

读温度的流程是发起一次寄存器读取，把返回的原始值拼接成 16 位数据，再换算成有符号温度值。下面这段是我在 C 语言里写的最小可用的读温度函数：

#define PJ85_I2C_ADDR 0x48 #define PJ85_REG_TEMP 0x00 float pj85_read_temp(void) { uint8_t buf[2]; int16_t raw; float temp_c; if (i2c_read_regs(PJ85_I2C_ADDR, PJ85_REG_TEMP, buf, 2) != 0) { return -1000.0f; /* 返回非法值，上层自行处理 */ } raw = (int16_t)((buf[0] << 8) | buf[1]); temp_c = (float)raw * 0.0078f; return temp_c; }

换算系数依据芯片数据手册的典型分辨率来定，具体以手册为准。返回 -1000 表示读取失败的约定很重要，上层逻辑只要发现非法值就直接用上一次有效值，避免把异常数据写进控制链路。

4.2 本地实时温度：移动平均滤波加迟滞比较

读取到的原始温度不能直接喂给控制器，传感器虽然已经内部处理过，但在电磁环境复杂的现场，总会冒出个别异常跳变。我在软件里加了两级处理：第一级是递推平均滤波，取最近 8 次采样做平均，能有效削平单个毛刺；第二级是变化率钳制，单次采样与上一次有效值的差值超过每周期 2°C 就丢弃该样本，重新采样。

实际效果很直观。现场测试时用热风枪短暂烘一下传感器，滤波前的值瞬间上蹿好几度，滤波后的曲线依旧平滑上升。对于 HVAC 这种惯性大的对象，这个响应速度完全足够。如果某些测点要求响应很快，可以把平均窗缩短到 4 次，或者改成滑动中值滤波，用排序代替平均，能进一步抗脉冲干扰。

对风机、电加热等设备的启停控制，还专门做了迟滞比较。比如设定 8°C 开启电加热、6°C 停止，如果只设一个 8°C 阈值，继电器会在临界点反复通断。迟滞设计是 HVAC 温控的基本功，在软件里实现也非常简单，逻辑如下：

#define HYST_ON_TEMP 8.0f #define HYST_OFF_TEMP 6.0f if (temp_c <= HYST_ON_TEMP && !heater_on) { heater_on = 1; gpio_heater_set(1); } else if (temp_c >= HYST_OFF_TEMP && heater_on) { heater_on = 0; gpio_heater_set(0); }

4.3 远程上送：周期上报与告警事件分流

远程上报我区分成两类：周期数据和告警事件。周期数据每 5 秒通过 RS485/以太网发送一次，内容包含设备号、通道号、温度值、时间戳；告警事件则由本地阈值触发，温度越限后立即主动推送，不再等下一个周期。这样远程监控室既能看趋势曲线，又能在异常时秒级收到通知。

通信协议上做了最简单的帧格式：帧头、长度、命令字、通道、温度值、校验、帧尾。校验用 CRC16。这套协议比直接裸发二进制可调试性好，也比 XML/JSON 在 MCU 上占用资源少。如果甲方要求接入标准监控系统，我会在协议适配层把数据转成 Modbus 保持寄存器，或者改成 MQTT 上云，但内部测温逻辑完全不用动。

远程发送的串口任务按固定周期处理，发送缓冲区满时直接丢弃最旧的待发帧，保住最新数据。这个取舍很重要，实时监控场景里最旧的数据已经没有价值，不值得为了它阻塞本地控制线程。

4.4 断线与异常处理：远程链路"软降级"

在真实项目里，RS485 线松动、交换机掉电、云平台暂时不可用都是家常便饭。我在远程模块里做了一个状态机：链路正常时周期发送并等待应答，超时未应答则进入重试，连续重试失败后标记为"离线"并停止发送。离线时所有温度数据继续存在本地的环形缓冲里，最多保留最近 100 条，链路恢复后先把缓存冲完，再回到周期上报。

这个设计保证了两点：远程断线不会拖垮本地控制；恢复后后台能补到一部分缺失的历史数据，不至于断档。经过几次现场维护后我体会到，远程模块的代码核心不是"能发数据"，而是"在各种异常下依然不让主流程难受"。

5. 调试与踩坑：三个印象最深的现场问题

5.1 回流焊后读到的温度整体偏高 1.5°C？

第一版 PCBA 回来后，发现板载传感器读数比标准温度计高 1.5°C 左右，而且每块板的偏移量还不完全一样。一开始怀疑是软件换算系数错了，反复核对计算没有问题；又怀疑 PCB 铜皮导热，但已经在传感器下方做了热隔离。最后用热成像重点查看，发现传感器靠近 PCB 的地层有很宽的铺铜，焊接时的大面积铜箔把热量传导到传感器封装内部，破坏了出厂校准时的热平衡。

这也说明对精度敏感的测温应用，传感器周围焊盘和连铜必须"瘦身"，最好只保留必要的引脚焊盘，底层地铜挖空，实测偏移从 1.5°C 降到 0.2°C 以内。如果产品对精度有硬性标定要求，也可以在生产测试阶段做两点校准，把偏移和斜率写进 Flash，运行时自动补偿。

5.2 继电器一动作，温度读数就跳到 FFFF

第一轮现场测试时发现一个规律：风机接触器一吸合，远程监控上就出现一条巨高的假温度。上位机解析出 0xFFFF，一度以为是传感器坏了。排查链路是这样的：先看软件滤波，发现毛刺直接穿过了 8 次平均——说明噪声不是单点，而是一串；再用示波器抓 SCL/SDA 线，果然在继电器动作瞬间出现大幅振铃；最后回到硬件，确定是 I2C 走线贴着继电器驱动线走了 3 cm，噪声耦合进来。

解决方法是改板：I2C 走线重新绕开驱动线，并加串阻和滤波电容。改板后同样操作再测，波形干干净净。这个问题的教训是，软件滤波能处理偶发毛刺，但处理不了持续一段时间的强耦合噪声，硬件上的隔离必须优先做，软件只是兜底。

5.3 传感器地址冲突导致总线上"双人发言"

第二路传感器到手后，我把两颗 PJ85718DM 都接到一根 I2C 总线上，结果 20% 的概率读回乱数据。排查后发现因为硬件的 ADDR 引脚配置方式看反了，两片传感器地址相同。同地址器件在总线上同时应答，数据线被拉成什么值完全不可预期。

解决办法是确认 ADDR 引脚的电平网络设计，使两颗传感器地址分别落在 0x48 和 0x49，然后驱动里改为按探测到的地址自动枚举。排查速度快的秘诀是在读失败时打印出地址和 SDA 波形，而不是盲目改代码。这个问题也提醒我，多传感器项目里硬件地址分配是原理图审查阶段就要检查一遍的事，别等到贴片测试才发现。

5.4 校准与一致性：批量板卡的零点调校

HVAC 现场往往有多台机组，后台要把所有机组的温度放在一张曲线图上对比。如果每台机组的传感器偏零点不同，曲线会出现阶梯状跳变，甲方第一反应就是"你们的温度不准"。

所以批量阶段我增加了产线校准步骤：所有板卡在恒温槽里统一采集 0°C 和 50°C 两个温区的读数，把每片板的偏移量和增益误差存进 MCU 的 DataFlash，运行时读取校准值补偿。做完之后多台机组曲线一致性明显提升，后台对比温度差值能稳定在 ±0.2°C 以内。这一步虽然增加了产线工时，但这正是从"能运行"迈到"能被客户信任"的一个关键环节。

6. 从样机到产品：这套方案还能往哪些方向扩展

6.1 远程节点组网：从单机温度采集到多机组联动

单个控制器的温度监测做完之后，甲方很自然提出新需求：能不能把每台机组的实时温度汇总到一起，做能耗分析和设备健康度判断。这就要把 RS485 总线上的多台控制器组网，选一台做主站，定期轮询各从站的温度数据，再统一封装上云。

这个扩展的软件成本比想象中低，因为从站只需把已经做好的远程上报函数从"主动周期发"改成"响应主站轮询"，内部测温逻辑完全不动。硬件上，主站选用带以太网接口的板卡即可，轮询频率控制在每台机组 2 秒一次，现场实测 CPU 占用几乎没有压力。

6.2 温度数据参与联动控制：不只是"看"，还要"动"

温度监测的终点不是屏幕上的数字，而是让设备自动调整运行状态。我在这版固件里加了联动配置：送风温度高于设定值时，自动加大风机转速；盘管温度过低时，关闭表冷器水阀，防止盘管冻裂。这些都是直接在本地控制器完成的，不依赖远程链路。

联动逻辑在代码里做成一张简单的规则表，现场调试时改阈值只需要通过串口命令下发，不用重新烧录固件。对工程售后来说，这比每次改参数都带下载器去现场省心得多。

6.3 固件远程升级与日志回捞

产品一旦铺开，固件升级是必须考虑的事。我把温度采集模块和通信模块做了分区管理，远程链路可以下发新的固件包，先写入备份区，校验通过后再切换启动。升级过程中温度采集不受影响，控制逻辑也继续运行，只有切换瞬间有几十毫秒的不连续。

同时把设备运行日志（温度越限记录、掉线记录、电源上下电时间）保存在 Flash，远程统一回捞。这些日志在排查现场问题时价值巨大——很多时候设备当时发生了什么，客户说不清，远程日志比电话沟通快得多。

6.4 关于这套组合的长期可靠性思考

HVAC 设备工作年限通常十年起步，温度监测方案最怕两类老化问题：传感器长期漂移和 I2C 接插件氧化。传感器漂移可以通过软件周期性自检来感知，比如在板上留一个高精度参考电阻和基准源，定期自校；接插件问题则要在选型阶段就选择镀金触点，并做防振动处理。

从整个项目来看，PJ85718DM 这类数字传感器和 R7FA6E2BB3CFM 这类高性能 MCU 组合，优势恰恰在于把复杂问题前置固化到器件里，应用层软件反而简单干净。我在后续几个项目里已经把这套"本地实时控制 + 远程周期上报"的架构复制到了冷库和热泵控制器上，改动量主要集中在外围配置和通信协议，核心测温链路几乎原样复用。

如果让我给正准备做类似项目的人一个建议，就是先把硬件抗干扰和软件异常分支做扎实。温度传感器本身不会难倒人，难的是现场各种稀奇古怪的干扰和断线场景。把这些边界情况处理好了，项目就很稳了。关于 PJ85718DM 的详细寄存器配置，我后面还会单独写一篇，有兴趣的可以收藏留意。