嵌入式温度采集实战：PJ85718DM与R7FA4E2B93CFM在楼宇自控中的应用

去年年底接了一个楼宇自控的小项目，客户要的东西其实不复杂：把分布在三个配电间、两条空调风道里的温度点统一收回来，既要在现场触摸屏上实时看到，又要通过局域网汇总到监控后台。真正麻烦的是，这些点位有的在弱电井，有的在风机盘管旁边，环境复杂，干扰不少，选型和通信方案就不能拍脑袋定。翻了一圈手头的芯片和传感器库存，最后定了 PJ85718DM 加 R7FA4E2B93CFM 的组合。这个方案做下来，本地采集和远程上报两条链路都跑通了，也踩了不少坑，今天把整个思路和实操过程整理出来，给正在做嵌入式温度采集或者 HVAC 监控的朋友一个参考。

先说下这套方案适合谁。如果你手头要做的是多点温度采集、需要本地显示加远程上报，又受限于成本不能上太贵的工业采集模块，那 PJ85718DM 作为温度采集前端、R7FA4E2B93CFM 作为主控的思路就有直接参考价值。如果你已经在用别的单片机做类似项目，这篇文章里的采集滤波、标定流程、远程协议设计思路也是通用的，未必非要换芯片。

1. 为什么最后选了 PJ85718DM 和 R7FA4E2B93CFM 这套组合

1.1 温度采集在嵌入式场景里的真实痛点

很多人觉得测温度嘛，一个热敏电阻加一个 ADC 就搞定了，但真正拿到嵌入式或者 HVAC 场景里做，问题就冒出来了。

嵌入式设备里最常见的测温需求是板级监测：主控芯片温度、功率器件温度、电源模块温度。这类测温点的特点是离发热源近，温度变化快，需要响应及时，同时精度不用特别高，正负一两度就能接受。但 HVAC 场景完全反过来，测的是风道温度、回风温度、水管温度，点位分散、距离长，传感器线缆动不动就要拉几米甚至几十米，而且环境里还有强电干扰，对精度和长期稳定性的要求更高，很多系统要求正负 0.3 度以内的重复精度。

这两个场景的测温需求放一起，单一方案根本没法兼顾。板级测温用热敏电阻成本低但一致性差，HVAC 用 PT100 加变送器精度高但成本翻好几倍，维护还麻烦。PJ85718DM 在这两者之间取了个平衡：它本身是带数字接口的温度传感器芯片，测量分辨率能做到比较精细，数据是直接通过数字总线读回来的，不像热敏电阻那样依赖 ADC 参考电压的稳定性，所以长线传输的抗干扰能力明显更好。用它做采集前端，搭配一颗主控做汇总和通信，就能同时覆盖两种场景的测温需求。

1.2 主控选型不是越贵越好，R7FA4E2B93CFM 的取舍

主控选型上我一开始考虑过很多方案，包括几款带以太网 MAC 的芯片，想省掉外部网口的成本。但仔细算了一笔账：带以太网 MAC 的芯片往往封装大、引脚多，四层板的布线压力也大，整体成本反而更高。R7FA4E2B93CFM 吸引我的是它在性能和外围集成度之间卡得比较准。

这颗芯片是 Arm Cortex-M33 内核，主频跑 100MHz 左右，在这个量级的采集项目里性能完全够用，而且空余算力还能做软件滤波和协议处理。更重要的是它的外设配得挺全：多路 I2C、SPI、UART、CAN FD 都有。PJ85718DM 通过 I2C 挂上去，本地屏幕用 SPI 驱动，远程上报走 UART 接一个串口转以太网模块，或者直接上 Modbus 协议，一套外设全部覆盖，不需要额外加桥接芯片。工作温度范围也让我放心，HVAC 项目里有几个传感器点在风机盘管旁边，夏天温度不低，R7FA4E2B93CFM 的结温范围能扛住这种环境。

选型阶段我专门对比过几组方案，整理成了一张表给客户看：

做项目不能只盯着一颗芯片的单价，系统级的布线成本、调试成本、维护成本都要算进去。这套组合的单颗物料成本比热敏电阻方案高，但省掉的标定时间和调试时间早就赚回来了。

1.3 组合的分工逻辑：采集前端和协议处理分离

这个方案里，PJ85718DM 和 R7FA4E2B93CFM 的分工很明确。PJ85718DM 负责把物理温度转成数字量，而且是现场就近转换，不是把模拟量拉长线到主控再转换，这个细节非常关键。模拟信号长距离传输的时候，线缆电阻、接触电阻、空间电磁干扰都会叠加进去，等到主控 ADC 采集的时候已经不知道混了多少噪声了。PJ85718DM 这类的芯片把数字转换放在传感器端，输出的是数字脉冲信号，抗干扰能力天然强很多。

R7FA4E2B93CFM 则负责更上层的活：轮询各个 PJ85718DM 节点，做数据滤波和异常判断，把结果推给本地显示，同时处理远程通信协议。相当于传感器负责"感知"，主控负责"思考"和"说话"，各干各的，互不干扰。

2. 硬件搭建：从最小系统到完整测温采集板

2.1 一个可靠的 R7FA4E2B93CFM 最小系统要管好哪几件事

很多人从评估板跳到自己做板子的时候，最容易在最小系统上翻车。R7FA4E2B93CFM 这颗芯片要稳定跑起来，电源、时钟、调试接口这三个地方必须处理干净。

电源方面，我用了外部 LDO 单独给 MCU 供电，没有直接拿系统的 5V 电源进芯片。原因很简单，这个板子在现场要跟风机盘管控制器共用一个电源箱，电机启停的瞬间电压跌落和毛刺非常明显，LDO 能把这些干扰滤掉不少。芯片的内核电压是内部 LDO 产生的，外部供电纹波控制好，ADC 和 I2C 的稳定性才有保障。

时钟方面，外部晶振我选了带负载电容的 24MHz 晶振，配合芯片内部 PLL 倍频到主频。这里有个容易忽略的细节：晶振的两个负载电容不是随便选的，要看晶振的规格书。选小了起振困难，选大了温漂变大。R7FA4E2B93CFM 的 OSC 引脚对负载电容比较敏感，我最后用的 12pF 电容，实测起振很干脆，PLL 锁定也稳。

调试接口一定要留 SWD，而且 SWDIO 和 SWCLK 上要接上拉电阻。这个电阻别省，否则现场调试的时候下载器经常识别不到芯片，尤其在板子供电不稳的情况下，宁可多放两颗电阻。

2.2 PJ85718DM 的接入：I2C 总线的接法有讲究

PJ85718DM 的接口形式上走的是 I2C 或类似的两线数字接口，接线不复杂但我建议严格处理几个点。

第一，所有 PJ85718DM 的地址引脚要根据板上的拨码设置好。多路传感器挂同一条总线上，每个节点的地址必须唯一，否则地址冲突之后读回来的数据全是乱的。我在板上留了四位拨码开关，最多支持 16 个节点，足够覆盖这个项目的 12 个测温点。

第二，上拉电阻不能省。I2C 总线的 SDA 和 SCL 线必须接上拉电阻到 VCC，阻值我用了 4.7k。总线长度短、节点数量少的时候，4.7k 没问题；如果后面要拉长线，把阻值降到 2.2k 能提高沿的陡峭程度，降低误码率。

第三，长线布局要避免环形走线。I2C 总线从主控出来，串行经过每个传感器节点，不要接成星形再汇聚。星形拓扑在 I2C 上会产生反射信号，实测中总线稍长一点就经常出现 CRC 校验失败。

2.3 传感器节点的供电与长线传输设计

测温点分散在现场各个角落，给 PJ85718DM 供电也是要专门考虑的。我没有给每个节点单独拉电源，而是用了 24V 直流总线集中供电，每个节点板上放一颗 DC-DC 降压到 3.3V 给传感器和总线收发器用。

这样做的好处有三个：一是现场取电方便，24V 在现场是最常见的控制电压；二是共地之后 I2C 信号的参考电平一致，不会出现地电位差把总线电平顶掉的问题；三是集中供电方便在总配电端加一个大容量的电解电容，能吸收掉不少电源线上的脉冲干扰。

传感器节点板和主控板之间的 I2C 线缆，我选的是带屏蔽层的双绞线，屏蔽层单端接地。这里有个经验之谈：屏蔽层最好是接在主控端的系统地，不要两头都接地，两头接地在存在地电位差的时候会形成地环路，反而引入更大的干扰。

2.4 PCB 布线的几个注意事项

这几块板子的 PCB 都不复杂，但布线时我还是犯了几个错误，改版之后才解决。

第一，主控的退耦电容要尽量靠近电源引脚。第一版我把电容放得远了点，结果芯片在全速跑 I2C 和 UART 的时候，供电引脚上的电压纹波接近 100mV，直接导致个别传感器读数跳动。第二版把 100nF 电容贴到电源引脚旁边，纹波降到了 30mV 以内。

第二，I2C 总线的走线不要从变压器或者电感底下穿过。板上有 DC-DC 电感，第一版的 I2C 走线正好从电感正下方经过，结果总线上的噪声大得离谱，后来改走线绕开才恢复正常。

第三，传感器节点的 PCB 面积尽量做小。HVAC 现场要塞进风道检测口里，太大的板子根本装不进去。我做的传感器节点板子是 25mm 乘 20mm 的大小，两头留了螺丝孔，方便固定在风道法兰上。

3. 本地温度监测的实现：从轮询到滤波的完整逻辑

3.1 多节点轮询策略与地址管理

主控读温度数据，最直接的做法就是 while 循环里挨个地址轮询：给地址 1 发读命令，等数据回来，存进数组，再发地址 2，如此循环。但在实际项目里，我建议加一点变化。

PJ85718DM 这类芯片每次读取需要一点转换时间，在转换结束之前去读，读回来的要么是旧值，要么是错误标志。所以轮询循环里每个节点读取之后，延时一段时间再继续，我用的延时在 30 到 50 毫秒之间。12 个节点全部轮询一遍，耗时大概 0.5 秒左右，对温度这个慢变量来说完全够用。

地址管理上用一张映射表，把物理位置和总线地址对应起来。比如地址 1 对应配电间 A 的进风温度，地址 2 对应配电间 A 的回风温度。这样后面做远程上报的时候，提数据直接查表就行。映射表放到 Flash 里，现场要用上位机工具修改，不要在代码里写死。

3.2 软件滤波：滑动平均和中值滤波怎么配合

温度数据进来之后不能直接就用。我观察过，即使硬件上已经做了不少抗干扰处理，读回来的数据偶尔还是会出现个别毛刺，比如某一次读数比前后值差了五六度。这种毛刺如果直接显示或者上报，后台的告警系统就会误报。所以软件滤波这层必须做。

我用了两层滤波配合。第一层是中值滤波，每次连续读同一个节点三次，取中间值作为本次有效数据。处理掉随机毛刺。第二层是滑动平均，把最近五次的中间值存进环形缓冲区，求平均后作为最终显示和上报的值。滑动平均能抑制周期性的小幅波动，让温度曲线变得平滑。

两层滤波加在一起，单个节点的有效数据更新周期大概是两秒左右。有人可能会觉得这个响应速度太慢，但温度本身变化就慢，风道里的温度一分钟能变一度已经很剧烈了，两秒更新一次完全不会影响监控效果。

3.3 自发热效应对精度的影响与对策

嵌入式测温最容易忽视的坑就是芯片自发热。PJ85718DM 芯片本身在工作的时候会有微弱功耗，如果 PCB 布局不合理，器件离主控或 DC-DC 太近，热量传导过去，读出来的温度会比环境温度高一截。

我在实际测量中发现，传感器节点板如果跟 DC-DC 电感距离小于 5 毫米，读数会偏高 0.5 到 0.8 度。处理办法有两种：一是布局上强制拉开距离，二是软件里做一个静态偏移修正，标定的时候记录实际温度和读数的差值，作为修正项存进 Flash。

在 HVAC 场景里，我建议这两种一起用。硬件间距拉开之后，自发热的影响已经小了，软件修正再补一点，精度就能稳定在正负 0.3 度以内，满足大多数楼宇自控的要求。

3.4 标定流程：两点标定到多点标定的实践

PJ85718DM 出厂前是有校准的，但换了 PCB、引线变长之后，系统级误差还是会有一些，所以项目落地前最好做一次系统级标定。

最简单的做法是两点标定。把传感器探头放进恒温槽，分别在 15 度和 35 度两个设定点记录实际读数和标准温度计的差值。得到两个修正点之后，中间值按线性插值修正。这个方法对 HVAC 场景够用，因为风道温度常年就在 10 到 40 度之间，线性插值误差很小。

如果是给嵌入式的板级测温做标定，我建议用三点标定甚至更多点，因为板级测温的温度跨度可能从零下到八十度，线性插值不一定够。多存几个修正点，做成查表加插值的修正算法，精度会好很多。

标定数据一定要写到 Flash 里保存，而且最好设计成上位机可回读。我一直保留了一组标准表具，每块新板子出厂前都要过一遍两分钟的快测流程，不合格的直接打回，这个习惯帮我挡掉了不少批次性的器件问题。

4. 远程温度监测链路：从现场到监控后台的完整设计

4.1 远程方案选型：Modbus 优先还是 MQTT 优先

远程上报的方案设计是整个项目里最需要想清楚的部分。客户后台的需求是既要实时看数据，也要历史曲线和告警推送。我对比了两种主流的远程上报方案。

第一种是 Modbus RTU 走串口转以太网网关，乹Modbus TCP 和后台对接。这种方案胜在协议简单、透明。后台做组态软件的基本都支持 Modbus TCP，兼容性最好。主控作为 Modbus 从站，把各个温度点映射到保持寄存器里，后台定时轮询就行。我最终就采用了这个方案，因为客户的监控后台用的是常见的组态软件，Modbus TCP 是它天然支持的协议。

第二种是 MQTT 上报，主控通过以太网模块连接本地 MQTT Broker，按主题发布温度数据。这个方案的优点是实时推送效率高，后台如果有物联网平台，做告警和可视化都方便。缺点是协议栈和平台要自己搭，对纯做硬件的老哥来说门槛高一些。

选型的时候我给客户画了一条很简单的判断线：如果后台是传统组态软件，就用 Modbus TCP；如果后台是自研平台或者云平台，就用 MQTT。没有绝对的好坏，只有匹配不匹配。

4.2 寄存器映射设计：地址规划要留余量

用 Modbus TCP 上报的话，寄存器映射表的设计决定了后面后台工程师对接的难易程度。这个环节做得乱，现场调试的时候能坑死人。

我的做法是每个温度点分配连续的两个寄存器：一个存整数值，单位是 0.1 摄氏度，这样 25.3 度就存成 253；另一个存状态字，用位标志表示传感器在线还是掉线、数据是否有效。状态字看着多占了一个寄存器，但好处是后台不用自己去猜一个 -9999 是不是无符号的负数，直接读状态字就知道当前数据可不可信。

寄存器地址从 0 开始，预留 100 个点的空间，就算后面项目扩容，地址不用重排。另外我把设备参数也暴露出去了，比如固件版本、设备编号存在高端口地址，后台巡检的时候能顺便发现固件版本不一致的现场设备。

4.3 数据上报逻辑：周期推送加变化上报

远程上报不能纯粹按固定周期傻推。固定周期一分钟推一次，如果数据根本没变化，浪费带宽不说，后台还要处理大量重复数据。我用的策略是变化上报加心跳上报结合。

温度变化超过 0.2 度就主动上报，这是变化上报；如果五分钟内没有任何变化，就发一次心跳包，告诉后台这个点还活着。心跳包的数据里带一个简单的序列号，后台发现序列号跳变，就知道中间有数据丢包，能触发重连或者补报请求。

这个机制的工程量不大，收益却很明显。后台的数据库压力小了，告警响应也快。实验室环境里测试，从温度跳变到后台显示告警，链路延迟基本控制在一秒以内。

4.4 断网缓存与重连补报

现场网络不是永远稳定的，交换机重启、网线松了，都会导致链路断开。主控必须能处理这种情况，不能断了网就把数据丢了。

我在主控上开了一块环形缓存区，容量可以存一天的温湿度数据。链路断开的时候，数据照常写入缓存区。网络恢复之后，主控先上报最近一条数据，再把缓存区里的数据按时间顺序补报上去。后台收到补报数据，按时间戳归档就行，不需要额外处理。

实测下来这个机制效果很好。一次现场交换机半夜重启了四十分钟，恢复之后后台自动补上了这段时间的完整温度曲线，客户完全没感知到断网这件事。

5. HVAC 场景特有的工程化问题

5.1 传感器探头的位置选择与安装细节

同一个传感器装在不同位置，读数能差好几度，这个在 HVAC 项目里特别明显。回风温度探头如果装在回风口正下方，容易受到局部气流影响，读数波动大。进风温度探头装在风道弯头附近也不行，气流在这个位置有涡流，温度分布不均匀。

我的经验是：风道测温点要选在直管段，距离弯头、阀门至少五倍管径的位置。这个位置气流最稳定，测出来的温度最有代表性。安装的时候探头要伸入风道内部深度的三分之一到二分之一处，不要贴着管壁，管壁温度跟空气温度差不少。

细管径的风道装探头还有个窍门：用带密封圈的安装底座，把探头插进去后再锁紧。这样既固定了位置，也防止漏风。漏风不只是影响温度读数，还会破坏风道的气流平衡，严重的会让空调系统的压差传感器误动作。

5.2 EMC 干扰对温度读数的影响和硬抗措施

HVAC 现场最不缺的就是干扰源。变频器、风机电机、水泵启动的瞬间，都会在电源线和信号线上感应出很高的尖峰电压。温度传感器节点如果抗不住这些干扰，读数就会周期性跳动。

硬件上我做了三件事来硬抗 EMC。第一，传感器节点和主控之间的 I2C 线缆用屏蔽双绞线，屏蔽层单端接地。第二，节点的供电入口处加 TVS 管和共模电感，TVS 管能吸收浪涌尖峰，共模电感能抑制共模干扰。第三，主控板的外壳接地端子和现场接地网连接，保证整个系统有一个干净的参考地。

这些措施加完之后，又在现场做了几次对比测试。把变频器开到最大输出，近距离观察传感器读数，再也没有出现过之前的剧烈跳变。

5.3 与楼宇 BA 系统的对接实践

很多 HVAC 项目到最后要接楼宇 BA 系统，也就是建筑自动化系统。BA 系统对数据的格式和时间戳要求很严格，直接对接的过程最容易出问题。

BA 系统收集温度点通常用 BACnet 或者 Modbus 协议。客户的 BA 系统用的是 Modbus TCP，所以主控侧做好从站功能就行。真正的坑在于数据格式。BA 系统的大工程师习惯用 IEEE 754 浮点数，而我一开始寄存器里存的是整数加状态字。两边对不上，后台显示的数值跟现场差了好几倍。

解决办法是在主控固件里加了一个数据格式配置位，可以切换整数和浮点两种格式，按 BA 系统的要求调整。这个功能看着不起眼，但帮我在后续两个项目的对接中省了大把时间，基本就是改个配置位的事。

5.4 实际运行效果：一组完整的数据表现

整套系统装完到现在运行了大概四个月，我拉了一组典型数据供参考。配电间 A 的回风温度设定为 24 度，实际读数稳定在 23.8 到 24.2 度之间小幅波动，PLC 记录的温差变化曲线非常平滑。远程上报的链路稳定性也不错，四个月里断网补报发生过两次，每次都在网络恢复后几分钟内自动补齐了数据。

温控精度方面，把读数与现场用的标准温度计对比，最大偏差 0.4 度，多数时间在 0.2 度以内。对于楼宇自动化的温控逻辑来说，这个精度已经能给设备启停提供稳定的判断依据了。

6. 踩坑实录与优化心得

6.1 坑一：I2C 总线上拉电阻和线缆电容的经典矛盾

项目做到一半，有个测温点开始频繁出现读不到数据的故障。排查了半天，发现是总线线缆太长，分布电容太大，4.7k 上拉电阻的上升沿跟不上信号的翻转速度。解决办法是在主控端把上拉电阻改成 2.2k，并且软件里降低了 I2C 的通信速率，从标准模式降到低速模式。改完之后连续跑了一周再没出现过读不到数据的问题。

这个坑提醒我一个道理：I2C 用在板内短总线是一回事，拉出去几米长线是另一回事。速率和上拉电阻要根据实际线缆长度重新匹配，不能直接照抄板级设计的参数。

6.2 坑二：滤波参数太激进导致温度响应迟钝

一开始我把滑动平均窗口设得很大，用了二十次平均，结果显示的温度数据确实平滑到纹丝不动，但温度变化的响应也迟钝了太多，风道里温度实际已经升了两度，显示值还在慢慢爬。这种反应速度在空调控制里非常危险，设备可能会因为反馈滞后而过度调节。

后面我把窗口砍到五次平均，同时加了变化率判断，如果连续两次原始读数之差超过 0.5 度，就直接跳过滤波输出，保证快速响应的同时还能抑制毛刺。

6.3 坑三：Modbus 地址规划没预留空间，扩容时全部重排

第一次设计寄存器表的时候没有预留足够的空间，后来客户要加温度点，发现地址不够用了，只能把所有寄存器重新映射一遍。后台组态软件的数据库全部要跟着改，工作量翻了好几倍。

后来我定了个规矩：寄存器映射要按 100 个测点起步来设计，哪怕现在只有 12 个点也要把地址空间留够。这块吃过的亏，后面所有项目都受益。

6.4 优化的完整过程：从发现问题到回归测试

每次踩坑之后我都会走一遍完整的优化流程：先复现问题，定位根因，修改代码或硬件，再做回归测试。以 I2C 读不到数据的问题为例，整个排查过程大概用了三个小时，但是把上拉电阻和通信速率这个问题记进了项目的设计清单之后，后续所有板子的生产都遵守了这套参数，再没复发过。

做项目就是这样，踩坑不可怕，可怕的是踩了坑不长记性。每解决一个问题，把结论固化到设计规范和检查清单里，才是长期效率的来源。

最后分享一个小技巧：PJ85718DM 和 R7FA4E2B93CFM 这套组合，在设计的时候就把串口打印调试信息的功能预留好，调试时能看到每个节点的实时读数，这个比一切示波器和仿真器都直观。预留调试串口只需要占用一个 UART 引脚，换来的排查效率提升是巨大的。