做HVAC控制器的人应该都有过这种体会本地温度读得好好的拉到远端就漂或者两个温度探头的数据各说各话PID都不知道该听谁的。我最近在调一套嵌入式恒温柜控制器主控用 PIC18F86J55本地端接 PJ85718DM远程端挂了一串 RS485 温度节点专门解决嵌入式和 HVAC 场景里本地与远程温度同时监测的问题。这篇文章把方案从硬件到固件到调试完整展开正在做暖通控制、机房环境监测、嵌入式温控采集的同学可以直接抄作业。先说结论这套方案的思路不复杂就是“本地用数字温度传感前端远程用总线轮询从站”但真正干活的时候坑全藏在接口时序、总线超时、供电纹波这些细节里。我会按自己实际调试的顺序来讲不绕弯子。1. 方案拆解一台 MCU 怎么同时盯住本地和远程两路温度1.1 系统里的温度点分两类处理方式完全不一样很多初学者最困惑的地方是既然都叫温度采集为什么不能一套电路全搞定真实项目里不能这么干原因在于两类温度点的物理位置和信号性质不一样。本地温度指的是主控板附近的温度比如柜内空气温度、PCB 板温、风道入口温度。这类温度点离 MCU 近线缆短干扰小要求响应快、精度相对高。PJ85718DM 这类数字温度传感前端就适合干这个测温单元和 ADC 集成在一起直接输出数字量不需要外置调理电路也不会被模拟走线引入乱七八糟的噪声。远程温度是分布在设备各个角落甚至设备外部的温度点比如冷凝器出口温度、远端风管温度、室外环境温度。这类温度点离主控可能几十米甚至上百米如果用模拟量信号直连线缆压降和电磁干扰会把你折磨到怀疑人生。所以远程温度必须走总线每个远端位置放一个小采集节点节点通过 RS485 接回主控主控用 Modbus RTU 轮询所有节点。这样布线简单、抗干扰强、扩展节点也方便。从主控的角度看PJ85718DM 对应的是“本地温度通道”RS485 总线对应的是“远程温度通道”两条链路互相独立最后在 PIC18F86J55 内部统一做滤波、换算和逻辑判断。1.2 选型不是选最强芯片而是选最顺手的组合我为什么在主控上坚持用 PIC18F86J55而不是随手拿个主流 32 位 MCU因为在这个场景里PIC18F86J55 的外设匹配度确实很舒服。它自带多个 UART、两个 I2C/SPI、12 位 ADC还有 CAN 和 USB 模块意味着本地接数字传感器、远程挂 RS485、想留一个 USB 口做调试和参数导出全都靠这一颗芯片就能完成不需要额外挂转接芯片。PJ85718DM 这个数字温度传感前端最大的吸引力是它把温度采集的脏活累活都干完了。内部集成了精度校准逻辑直接把温度值映射到寄存器MCU 只要通过 I2C 读寄存器就行。比起传统的 NTCADC 方案省掉了查表、非线性修正、批量标定这些工作量。当然代价是单颗成本比 NTC 高电路板 BOM 成本会涨一点但换来的是生产一致性和调试效率尤其是交货期紧的时候这个交换很值。选型时还有一点容易被忽略HVAC 设备运行环境往往有接触器吸合、变频器启停温度采集方案的抗干扰能力比精度更重要。数字传感器对干扰的容忍度比模拟小信号高一个量级这也是我把本地温度交给 PJ85718DM 的直接理由。2. 硬件对接PJ85718DM 本地探头与 PIC18F86J55 的连接细节2.1 PJ85718DM 接线别在小信号线上省事PJ85718DM 的接口很简单典型用法就是 I2C 接口加两根电源线。我按数据手册上的推荐电路来搭VDD 接 3.3V对地放一个 104 去耦电容而且这个电容要尽量靠近芯片的电源引脚这是数字传感器稳定工作的第一道保障。SCL 和 SDA 分别接 4.7k 欧姆上拉电阻到 3.3V上拉电阻不能省否则 I2C 时序边沿会很烂轻则通信不稳定重则直接读不到数据。信号脚接到 PIC18F86J55 的 MSSP 模块对应引脚SCL 和 SDA 不要跳线跳得到处都是尽量用短走线直连。如果主控板 IO 电平不完全匹配稳妥的做法是串一个 330 欧姆的电阻再加一个钳位二极管实际项目里我这么处理过效果很稳。PJ85718DM 如果有地址配置引脚一般是通过 A0/A1 的电平组合来改 I2C 地址。单颗使用时我习惯把两个配置引脚都接地用默认地址省得后面换芯片还要改固件。需要特别注意探头放置位置如果是测风道温度探头要伸进风道但不能贴在加热丝或散热片上如果是测板温要加导热介质让探头和被测面贴合紧密否则读出来的就是探头自己的空气温度不是你要测的温度。这里有个实操经验探头引线不要跟继电器控制线、220V 动力线走同一个线槽。我见过一个项目远程温度节点装得好好的就是本地温度偶尔跳一下排查到最后发现是 PJ85718DM 的引线和接触器线圈线绑在一起接触器一吸合就跳变。后来把引线单独走问题立刻消失。2.2 远程温度节点RS485 总线怎么组、节点怎么挂远程温度这块我用 RS485 总线挂多个采集从站。每个远程从站的结构类似一颗小 MCU或者专用采集芯片 温度探头 RS485 收发器。主站这边PIC18F86J55 的一个 UART 通过 RS485 收发器接到总线上用 Modbus RTU 协议轮询所有从站。从站地址自己设定一般 1 到 247 都可以但我会给每个节点固定拨码地址防止上电后地址冲突。总线拓扑推荐手拉手菊花链不要在中间分支太多分支线越短越好。总线两端各放一个 120 欧姆终端电阻这是 RS485 的基本功不放终端电阻在长线上容易出现信号反射表现为偶发通信失败。波特率我固定用 9600 或 19200HVAC 场景里总线距离通常几十到一两百米这个波特率够用而且抗干扰好。追求速度把波特率提到 115200在环境安静的实验室没问题搬到现场大概率会被教做人。温湿度采集从站如果挂的是 NTC 或 PT1000需要在从站板上做模拟前端和标定如果直接用支持 Modbus 的成品温度模块那就更省事主控只需要关心寄存器地址和数据类型。这里的关键是统一数据格式我规定所有远程从站返回的寄存器值都换算成带一位小数的温度值比如 25.3℃ 就返回 253主控侧不用为不同从站的单位差异写一堆特判。2.3 供电与干扰HVAC 现场最容易踩的坑在这个环节HVAC 现场和实验室最大的区别就是干扰源多。接触器一吸合感性负载会产生很强的反向电动势变频器一启动整个电源线上都是毛刺。如果系统供电不做处理温度数据就会跟着一起抖。我的做法是分三级处理第一级主控板电源入口放 TVS 管加共模电感把外部浪涌挡在第一道关卡第二级给 RS485 收发器的 A/B 线上加 TVS 管和偏置电阻防止总线空闲时电平不确定第三级PJ85718DM 和远程从站的供电单独滤波用磁珠加电容做 π 型滤波把 DC-DC 的高频纹波压下去。一个常见的认知误区是温度采集是低速信号不需要太在意电源质量。实际上温度芯片对供电纹波非常敏感尤其是内部 ADC 的参考电压直接来自 VDD 时纹波会直接叠加到读数里。我之前遇到 PJ85718DM 温度值在某个区间反复跳 0.5℃就是供电纹波超标导致的在芯片电源引脚附近补了一个 100uF 电解电容和一个 104 瓷片电容后彻底解决。3. 固件实现从底层寄存器读到温度换算滤波3.1 PJ85718DM 的 I2C 读取流程与代码PIC18F86J55 的 MSSP 模块配置成 I2C 主模式时钟 400kHz这组配置代码每次都差不多。关键点是 PJ85718DM 完成一次温度转换需要一定的转换时间典型值在 10 到 20 毫秒所以我每次读取前都会先延时然后再从温度寄存器取数。下面这段代码是我基于 XC8 编译器写的读取流程可以直接参考。初始化部分配置 MSSP 为主模式设置 SSPADD 来产生 400kHz 的 SCL 时钟读取部分先发器件地址加写位再发送温度寄存器地址最后发起读操作连续读两个字节。// I2C 主模式初始化400kHz假设 Fosc16MHz void i2c_init(void) { SSPCON1 0x08; // 主模式时钟由 SSPADD 控制 SSPCON2 0x00; SSPADD 9; // 16MHz / (4 * (91)) 400kHz SSPSTAT 0x00; TRISBbits.TRISB0 1; // SCL 设为输入开源引脚 TRISBbits.TRISB1 1; // SDA 设为输入 } // 读取 PJ85718DM 温度寄存器返回无符号 12 位原始值 unsigned int read_local_temp(void) { unsigned char high, low; unsigned int raw; __delay_ms(20); // 等转换完成实测 20ms 比较稳 // 起始条件 器件写地址默认地址为 0x48 SSPCON2bits.SEN 1; while(!SSPSTATbits.R_nW !SSPCON2bits.SEN); SSPBUF 0x90; // 0x48 1 0x90 while(!SSPSTATbits.BF); // 发送温度寄存器地址 0x00 SSPBUF 0x00; while(!SSPSTATbits.BF); // 重复起始 器件读地址 SSPCON2bits.RSEN 1; while(!SSPCON2bits.RSEN); SSPBUF 0x91; // 0x48 1 | 1 while(!SSPSTATbits.BF); // 读高字节然后读低字节最后发 NACK 停止 SSPCON2bits.RCEN 1; while(!SSPSTATbits.BF); high SSPBUF; SSPCON2bits.RCEN 1; while(!SSPSTATbits.BF); low SSPBUF; SSPCON2bits.ACKDT 1; SSPCON2bits.ACKEN 1; SSPCON2bits.PEN 1; while(!SSPCON2bits.PEN); raw ((unsigned int)high 8) | low; return raw; }拿到 raw 值之后还需要按纸面定义的位权换算成摄氏度。一般这类数字温度传感前端高位是符号位和整数位低位是小数位具体换算因子我建议在调试时用一个已知温度校准一下避免对数据手册理解偏差导致整段数据整体偏移。3.2 远程 Modbus 轮询超时、重试、CRC 一个都不能少远程温度通道我用 Modbus RTU 轮询。主站定时遍历所有从站地址读保持寄存器功能码 03数据部分两个寄存器代表温度值。帧格式是标准的从站地址、功能码、寄存器起始地址、寄存器数量和 CRC16。下面是我常用的 CRC16 计算函数Modbus 的 CRC 是查表法或按位计算都行按位计算更省 Flash 空间。// Modbus CRC16多项式 0xA001 unsigned short modbus_crc(unsigned char *buf, unsigned char len) { unsigned short crc 0xFFFF; unsigned char i, j; for (i 0; i len; i) { crc ^ buf[i]; for (j 0; j 8; j) { if (crc 0x0001) { crc (crc 1) ^ 0xA001; } else { crc 1; } } } return crc; }轮询逻辑里最核心的是超时和重试机制。我一开始把接收超时设成 50ms想着现场也就挂五个节点轮询一圈很快。结果在实际运行中偶尔出现节点无应答看一眼是超时太短从站还没来得及把帧发完。后来把超时放宽到 200ms并且对无应答的重试两次连续两次超时才判定节点离线丢帧率明显下降。还有一个细节是总线空闲判断。RS485 是半双工主站发完请求帧后要等从站响应但如果主站刚发完就立刻切换接收模式总线上的最后一位可能还没完全发送完会截断导致第一帧响应错乱。正确的做法是发完帧后延时 3 到 5 个字节时间再切到接收状态或者直接靠收发器芯片的自动方向控制。实测下来多加这几十毫秒的延时通信可靠性提升非常明显。// 发送 Modbus 请求帧读从站地址为 addr 的保持寄存器 1 个 void modbus_read_temp(unsigned char addr) { unsigned char frame[8]; unsigned short crc; frame[0] addr; frame[1] 0x03; frame[2] 0x00; // 寄存器高字节 frame[3] 0x00; // 寄存器低字节 frame[4] 0x00; frame[5] 0x01; crc modbus_crc(frame, 6); frame[6] crc 0xFF; frame[7] (crc 8) 0xFF; // 清空接收缓冲发送帧切换方向 uart_send_buffer(frame, 8); }从站返回的帧是地址、功能码、字节数、数据、CRC。主控收到后先校验 CRC再取数据区前两个字节合成温度值。如果 CRC 不对我直接丢弃这一帧不更新温度值而不是把错误数据用进来。3.3 温度滤波与断线处理数据不是读完就能用无论是本地还是远程温度拿到原始值之后都别直接往里送控制逻辑。温度信号本身是缓变信号我习惯在固件里做一阶低通滤波公式是new_value old_value alpha * (raw_value - old_value)。alpha 取 0.2 到 0.4 之间太小会导致响应迟钝太大会把噪声保留。这个参数要靠实际调试感受没有标准答案。断线和异常值的处理更重要。PJ85718DM 如果读到寄存器值全为 0xFFFF 或者超过合理温度区间我判断为传感器异常远程从站连续三次超时我判断为节点离线。无论哪种情况都不能直接把异常值传给上层否则控制器会以为温度 300℃ 然后疯狂降功率或者以为温度 -40℃ 然后拼命加热这在实际设备里是很危险的。我的策略是温度异常时置一个状态位同时保持上一次正常值参与控制并上报故障。这样即使传感器坏了设备还能按最后的安全值运行一段时间不会立刻产生剧烈动作。等故障持续超过设定时间再进入保护停机逻辑。这个思路很朴素但在 HAVC 控制器里非常实用因为用户不会希望因为一个传感器失灵导致整个机组停摆。4. 调试实录本地跳变与远程丢帧的排查过程4.1 本地读数上下跳 0.5℃问题出在供电纹波讲一个我实际踩过的坑。第一次把 PJ85718DM 接到板子上室温下读到的温度值在 25.0℃ 到 25.6℃ 之间来回跳而且是随机跳非常烦人。一开始我怀疑是 I2C 时序问题把时钟降到 100kHz跳变依然存在。后来用示波器看芯片 VDD 引脚发现纹波峰峰值到了 80mV 左右这明显不正常。顺着供电链路查发现 PJ85718DM 的电源是从主控板 3.3V 网络直接拉过来的而这个 3.3V 来自一颗 DC-DC没有做后级 LDO开关纹波直接灌进了传感器。处理办法是给 PJ85718DM 单独加了一路 LDO 滤波并在芯片电源引脚处放 100uF 电解和 104 瓷片电容并联。处理后纹波降到 10mV 以内读数稳定在 25.3℃ 不变。这个案例提醒我数字温度传感器虽然抗干扰比模拟方案强但供电质量依然是硬指标。设计阶段就要留出滤波电容的位置不然样机阶段再来补会很被动。4.2 远程节点回答“忽快忽慢”超时和总线偏置另一个典型问题远程从站单个节点用电脑 USB 转 485 调试一切正常一接到 PIC18F86J55 主控上就出现偶发无应答尤其是总线空闲一会儿再发请求时概率更高。排查后定位到两个原因。第一个原因是上面提过的超时设置太短主站请求帧发出后立刻切接收从站响应帧的前几个字节被截断主站收到的第一帧永远是残缺的。第二个原因是总线空闲时的电平不稳定RS485 在空闲状态时 A/B 之间的压差必须大于 200mV如果收发器没有加偏置电阻总线电平会漂在门限附近从站可能误判总线状态。解决办法是给 RS485 总线加上下拉偏置A 线对地接 10k 下拉B 线对电源接 10k 上拉同时把终端电阻保留。加完偏置电阻后空闲电平稳定后面再没有出现过这种随机丢帧。这类问题在实验室里很难复现因为实验室环境干扰小所以每次遇到总线偶发问题我第一反应都是检查总线偏置和终端匹配。4.3 温度异常速查表调试过程中遇到温度异常我习惯先按下面的表格排查比漫无目的改代码高效得多。现象可能原因检查点解决办法本地温度跳变幅度大供电纹波超标示波器测传感器 VDD 纹波加LDO滤波和大电容本地温度读数整体偏高探头位置靠近热源检查探头安装位置移出热区加导热介质I2C 偶发读不到数据上拉电阻不够或时序太快查 SCL/SDA 波形确认上拉 4.7k降低时钟远程节点间歇性无应答总线无偏置电阻测 A/B 空闲电压加 10k 上下拉偏置远程温度漂移从站供电不足查从站电源线压降加粗线径或单独供电远程节点离线误报超时太短查主站超时参数放宽到 200ms 左右这张表我每次新项目调试温度通道都会翻出来看大部分温度相关问题都能在里面找到方向。5. 往控制器里再走一步记录、告警与控制联动5.1 温度历史记录与超限告警温度和告警是强相关的。HVAC 设备里温度超限往往意味着换热异常、风机故障或者制冷剂问题。我之前在这个方案上扩展了两件事一是把本地和远程温度值周期写入 PIC18F86J55 的片内 EEPROM比如每五分钟记录一次掉电不丢失方便售后时查看历史温度曲线二是温度超限时通过 IO 输出告警信号或者通过 RS485 上报给上位机。很多 PIC18F86J55 的应用只把它当数据采集器用其实它还有片内数据存储自编程能力记录数据和跑逻辑都够用。如果记录点很多还可以外扩一块 SPI Flash成本很低。这里有个经验写 EEPROM 不要太频繁Flash 和 EEPROM 都有写寿命长时间持续写会提前磨损做分区写入、均衡磨损虽然代码多一点但对工业设备来说很值。5.2 本地远程温度联合进 PID一个实用的闭环思路最后说一个很多控制器设计者容易忽略的点本地温度和远程温度不是两个孤立的监控对象它们应该一起进控制逻辑。以恒温柜为例PJ85718DM 测的是柜内空气温度可以作为 PID 的主反馈量远程节点测的是换热器出口温度可以用作前馈或者保护条件。比如出口温度异常升高时即使本地温度还没超限也能提前降低加热功率避免系统惯性导致超调。我实际实现时是把本地温度作为主控制环路的反馈值远程温度作为辅助判断远程温度偏差超过设定阈值时把 PID 输出限幅调小等远程温度恢复正常再放开。这种联动逻辑让系统响应平稳很多。温度监测不只是看数字更要让数字参与决策这个思路放到任何 HVAC 项目里都适用。最后聊几句调试心态做温度采集调试大多数时候问题不在传感器本身而在电源、接线、时序、总线和环境干扰这些外围条件。PJ85718DM 和 PIC18F86J55 这套组合本身不复杂复杂的是把它放进一个真实的 HVAC 设备里还能保持稳定。我个人的习惯是每次改动只动一个变量量到波形再下结论不要凭感觉叠加重试次数和滤波层数那只会掩盖问题。把供电、接口、通信三个基础环节打扎实温度数据自然就稳了。 
长河君 · 2026/10/24 8:13:46 · 阅读 1.2k 嵌入式HVAC控制器：本地与RS485远程温度采集方案详解
做HVAC控制器的人应该都有过这种体会本地温度读得好好的拉到远端就漂或者两个温度探头的数据各说各话PID都不知道该听谁的。我最近在调一套嵌入式恒温柜控制器主控用 PIC18F86J55本地端接 PJ85718DM远程端挂了一串 RS485 温度节点专门解决嵌入式和 HVAC 场景里本地与远程温度同时监测的问题。这篇文章把方案从硬件到固件到调试完整展开正在做暖通控制、机房环境监测、嵌入式温控采集的同学可以直接抄作业。先说结论这套方案的思路不复杂就是“本地用数字温度传感前端远程用总线轮询从站”但真正干活的时候坑全藏在接口时序、总线超时、供电纹波这些细节里。我会按自己实际调试的顺序来讲不绕弯子。1. 方案拆解一台 MCU 怎么同时盯住本地和远程两路温度1.1 系统里的温度点分两类处理方式完全不一样很多初学者最困惑的地方是既然都叫温度采集为什么不能一套电路全搞定真实项目里不能这么干原因在于两类温度点的物理位置和信号性质不一样。本地温度指的是主控板附近的温度比如柜内空气温度、PCB 板温、风道入口温度。这类温度点离 MCU 近线缆短干扰小要求响应快、精度相对高。PJ85718DM 这类数字温度传感前端就适合干这个测温单元和 ADC 集成在一起直接输出数字量不需要外置调理电路也不会被模拟走线引入乱七八糟的噪声。远程温度是分布在设备各个角落甚至设备外部的温度点比如冷凝器出口温度、远端风管温度、室外环境温度。这类温度点离主控可能几十米甚至上百米如果用模拟量信号直连线缆压降和电磁干扰会把你折磨到怀疑人生。所以远程温度必须走总线每个远端位置放一个小采集节点节点通过 RS485 接回主控主控用 Modbus RTU 轮询所有节点。这样布线简单、抗干扰强、扩展节点也方便。从主控的角度看PJ85718DM 对应的是“本地温度通道”RS485 总线对应的是“远程温度通道”两条链路互相独立最后在 PIC18F86J55 内部统一做滤波、换算和逻辑判断。1.2 选型不是选最强芯片而是选最顺手的组合我为什么在主控上坚持用 PIC18F86J55而不是随手拿个主流 32 位 MCU因为在这个场景里PIC18F86J55 的外设匹配度确实很舒服。它自带多个 UART、两个 I2C/SPI、12 位 ADC还有 CAN 和 USB 模块意味着本地接数字传感器、远程挂 RS485、想留一个 USB 口做调试和参数导出全都靠这一颗芯片就能完成不需要额外挂转接芯片。PJ85718DM 这个数字温度传感前端最大的吸引力是它把温度采集的脏活累活都干完了。内部集成了精度校准逻辑直接把温度值映射到寄存器MCU 只要通过 I2C 读寄存器就行。比起传统的 NTCADC 方案省掉了查表、非线性修正、批量标定这些工作量。当然代价是单颗成本比 NTC 高电路板 BOM 成本会涨一点但换来的是生产一致性和调试效率尤其是交货期紧的时候这个交换很值。选型时还有一点容易被忽略HVAC 设备运行环境往往有接触器吸合、变频器启停温度采集方案的抗干扰能力比精度更重要。数字传感器对干扰的容忍度比模拟小信号高一个量级这也是我把本地温度交给 PJ85718DM 的直接理由。2. 硬件对接PJ85718DM 本地探头与 PIC18F86J55 的连接细节2.1 PJ85718DM 接线别在小信号线上省事PJ85718DM 的接口很简单典型用法就是 I2C 接口加两根电源线。我按数据手册上的推荐电路来搭VDD 接 3.3V对地放一个 104 去耦电容而且这个电容要尽量靠近芯片的电源引脚这是数字传感器稳定工作的第一道保障。SCL 和 SDA 分别接 4.7k 欧姆上拉电阻到 3.3V上拉电阻不能省否则 I2C 时序边沿会很烂轻则通信不稳定重则直接读不到数据。信号脚接到 PIC18F86J55 的 MSSP 模块对应引脚SCL 和 SDA 不要跳线跳得到处都是尽量用短走线直连。如果主控板 IO 电平不完全匹配稳妥的做法是串一个 330 欧姆的电阻再加一个钳位二极管实际项目里我这么处理过效果很稳。PJ85718DM 如果有地址配置引脚一般是通过 A0/A1 的电平组合来改 I2C 地址。单颗使用时我习惯把两个配置引脚都接地用默认地址省得后面换芯片还要改固件。需要特别注意探头放置位置如果是测风道温度探头要伸进风道但不能贴在加热丝或散热片上如果是测板温要加导热介质让探头和被测面贴合紧密否则读出来的就是探头自己的空气温度不是你要测的温度。这里有个实操经验探头引线不要跟继电器控制线、220V 动力线走同一个线槽。我见过一个项目远程温度节点装得好好的就是本地温度偶尔跳一下排查到最后发现是 PJ85718DM 的引线和接触器线圈线绑在一起接触器一吸合就跳变。后来把引线单独走问题立刻消失。2.2 远程温度节点RS485 总线怎么组、节点怎么挂远程温度这块我用 RS485 总线挂多个采集从站。每个远程从站的结构类似一颗小 MCU或者专用采集芯片 温度探头 RS485 收发器。主站这边PIC18F86J55 的一个 UART 通过 RS485 收发器接到总线上用 Modbus RTU 协议轮询所有从站。从站地址自己设定一般 1 到 247 都可以但我会给每个节点固定拨码地址防止上电后地址冲突。总线拓扑推荐手拉手菊花链不要在中间分支太多分支线越短越好。总线两端各放一个 120 欧姆终端电阻这是 RS485 的基本功不放终端电阻在长线上容易出现信号反射表现为偶发通信失败。波特率我固定用 9600 或 19200HVAC 场景里总线距离通常几十到一两百米这个波特率够用而且抗干扰好。追求速度把波特率提到 115200在环境安静的实验室没问题搬到现场大概率会被教做人。温湿度采集从站如果挂的是 NTC 或 PT1000需要在从站板上做模拟前端和标定如果直接用支持 Modbus 的成品温度模块那就更省事主控只需要关心寄存器地址和数据类型。这里的关键是统一数据格式我规定所有远程从站返回的寄存器值都换算成带一位小数的温度值比如 25.3℃ 就返回 253主控侧不用为不同从站的单位差异写一堆特判。2.3 供电与干扰HVAC 现场最容易踩的坑在这个环节HVAC 现场和实验室最大的区别就是干扰源多。接触器一吸合感性负载会产生很强的反向电动势变频器一启动整个电源线上都是毛刺。如果系统供电不做处理温度数据就会跟着一起抖。我的做法是分三级处理第一级主控板电源入口放 TVS 管加共模电感把外部浪涌挡在第一道关卡第二级给 RS485 收发器的 A/B 线上加 TVS 管和偏置电阻防止总线空闲时电平不确定第三级PJ85718DM 和远程从站的供电单独滤波用磁珠加电容做 π 型滤波把 DC-DC 的高频纹波压下去。一个常见的认知误区是温度采集是低速信号不需要太在意电源质量。实际上温度芯片对供电纹波非常敏感尤其是内部 ADC 的参考电压直接来自 VDD 时纹波会直接叠加到读数里。我之前遇到 PJ85718DM 温度值在某个区间反复跳 0.5℃就是供电纹波超标导致的在芯片电源引脚附近补了一个 100uF 电解电容和一个 104 瓷片电容后彻底解决。3. 固件实现从底层寄存器读到温度换算滤波3.1 PJ85718DM 的 I2C 读取流程与代码PIC18F86J55 的 MSSP 模块配置成 I2C 主模式时钟 400kHz这组配置代码每次都差不多。关键点是 PJ85718DM 完成一次温度转换需要一定的转换时间典型值在 10 到 20 毫秒所以我每次读取前都会先延时然后再从温度寄存器取数。下面这段代码是我基于 XC8 编译器写的读取流程可以直接参考。初始化部分配置 MSSP 为主模式设置 SSPADD 来产生 400kHz 的 SCL 时钟读取部分先发器件地址加写位再发送温度寄存器地址最后发起读操作连续读两个字节。// I2C 主模式初始化400kHz假设 Fosc16MHz void i2c_init(void) { SSPCON1 0x08; // 主模式时钟由 SSPADD 控制 SSPCON2 0x00; SSPADD 9; // 16MHz / (4 * (91)) 400kHz SSPSTAT 0x00; TRISBbits.TRISB0 1; // SCL 设为输入开源引脚 TRISBbits.TRISB1 1; // SDA 设为输入 } // 读取 PJ85718DM 温度寄存器返回无符号 12 位原始值 unsigned int read_local_temp(void) { unsigned char high, low; unsigned int raw; __delay_ms(20); // 等转换完成实测 20ms 比较稳 // 起始条件 器件写地址默认地址为 0x48 SSPCON2bits.SEN 1; while(!SSPSTATbits.R_nW !SSPCON2bits.SEN); SSPBUF 0x90; // 0x48 1 0x90 while(!SSPSTATbits.BF); // 发送温度寄存器地址 0x00 SSPBUF 0x00; while(!SSPSTATbits.BF); // 重复起始 器件读地址 SSPCON2bits.RSEN 1; while(!SSPCON2bits.RSEN); SSPBUF 0x91; // 0x48 1 | 1 while(!SSPSTATbits.BF); // 读高字节然后读低字节最后发 NACK 停止 SSPCON2bits.RCEN 1; while(!SSPSTATbits.BF); high SSPBUF; SSPCON2bits.RCEN 1; while(!SSPSTATbits.BF); low SSPBUF; SSPCON2bits.ACKDT 1; SSPCON2bits.ACKEN 1; SSPCON2bits.PEN 1; while(!SSPCON2bits.PEN); raw ((unsigned int)high 8) | low; return raw; }拿到 raw 值之后还需要按纸面定义的位权换算成摄氏度。一般这类数字温度传感前端高位是符号位和整数位低位是小数位具体换算因子我建议在调试时用一个已知温度校准一下避免对数据手册理解偏差导致整段数据整体偏移。3.2 远程 Modbus 轮询超时、重试、CRC 一个都不能少远程温度通道我用 Modbus RTU 轮询。主站定时遍历所有从站地址读保持寄存器功能码 03数据部分两个寄存器代表温度值。帧格式是标准的从站地址、功能码、寄存器起始地址、寄存器数量和 CRC16。下面是我常用的 CRC16 计算函数Modbus 的 CRC 是查表法或按位计算都行按位计算更省 Flash 空间。// Modbus CRC16多项式 0xA001 unsigned short modbus_crc(unsigned char *buf, unsigned char len) { unsigned short crc 0xFFFF; unsigned char i, j; for (i 0; i len; i) { crc ^ buf[i]; for (j 0; j 8; j) { if (crc 0x0001) { crc (crc 1) ^ 0xA001; } else { crc 1; } } } return crc; }轮询逻辑里最核心的是超时和重试机制。我一开始把接收超时设成 50ms想着现场也就挂五个节点轮询一圈很快。结果在实际运行中偶尔出现节点无应答看一眼是超时太短从站还没来得及把帧发完。后来把超时放宽到 200ms并且对无应答的重试两次连续两次超时才判定节点离线丢帧率明显下降。还有一个细节是总线空闲判断。RS485 是半双工主站发完请求帧后要等从站响应但如果主站刚发完就立刻切换接收模式总线上的最后一位可能还没完全发送完会截断导致第一帧响应错乱。正确的做法是发完帧后延时 3 到 5 个字节时间再切到接收状态或者直接靠收发器芯片的自动方向控制。实测下来多加这几十毫秒的延时通信可靠性提升非常明显。// 发送 Modbus 请求帧读从站地址为 addr 的保持寄存器 1 个 void modbus_read_temp(unsigned char addr) { unsigned char frame[8]; unsigned short crc; frame[0] addr; frame[1] 0x03; frame[2] 0x00; // 寄存器高字节 frame[3] 0x00; // 寄存器低字节 frame[4] 0x00; frame[5] 0x01; crc modbus_crc(frame, 6); frame[6] crc 0xFF; frame[7] (crc 8) 0xFF; // 清空接收缓冲发送帧切换方向 uart_send_buffer(frame, 8); }从站返回的帧是地址、功能码、字节数、数据、CRC。主控收到后先校验 CRC再取数据区前两个字节合成温度值。如果 CRC 不对我直接丢弃这一帧不更新温度值而不是把错误数据用进来。3.3 温度滤波与断线处理数据不是读完就能用无论是本地还是远程温度拿到原始值之后都别直接往里送控制逻辑。温度信号本身是缓变信号我习惯在固件里做一阶低通滤波公式是new_value old_value alpha * (raw_value - old_value)。alpha 取 0.2 到 0.4 之间太小会导致响应迟钝太大会把噪声保留。这个参数要靠实际调试感受没有标准答案。断线和异常值的处理更重要。PJ85718DM 如果读到寄存器值全为 0xFFFF 或者超过合理温度区间我判断为传感器异常远程从站连续三次超时我判断为节点离线。无论哪种情况都不能直接把异常值传给上层否则控制器会以为温度 300℃ 然后疯狂降功率或者以为温度 -40℃ 然后拼命加热这在实际设备里是很危险的。我的策略是温度异常时置一个状态位同时保持上一次正常值参与控制并上报故障。这样即使传感器坏了设备还能按最后的安全值运行一段时间不会立刻产生剧烈动作。等故障持续超过设定时间再进入保护停机逻辑。这个思路很朴素但在 HAVC 控制器里非常实用因为用户不会希望因为一个传感器失灵导致整个机组停摆。4. 调试实录本地跳变与远程丢帧的排查过程4.1 本地读数上下跳 0.5℃问题出在供电纹波讲一个我实际踩过的坑。第一次把 PJ85718DM 接到板子上室温下读到的温度值在 25.0℃ 到 25.6℃ 之间来回跳而且是随机跳非常烦人。一开始我怀疑是 I2C 时序问题把时钟降到 100kHz跳变依然存在。后来用示波器看芯片 VDD 引脚发现纹波峰峰值到了 80mV 左右这明显不正常。顺着供电链路查发现 PJ85718DM 的电源是从主控板 3.3V 网络直接拉过来的而这个 3.3V 来自一颗 DC-DC没有做后级 LDO开关纹波直接灌进了传感器。处理办法是给 PJ85718DM 单独加了一路 LDO 滤波并在芯片电源引脚处放 100uF 电解和 104 瓷片电容并联。处理后纹波降到 10mV 以内读数稳定在 25.3℃ 不变。这个案例提醒我数字温度传感器虽然抗干扰比模拟方案强但供电质量依然是硬指标。设计阶段就要留出滤波电容的位置不然样机阶段再来补会很被动。4.2 远程节点回答“忽快忽慢”超时和总线偏置另一个典型问题远程从站单个节点用电脑 USB 转 485 调试一切正常一接到 PIC18F86J55 主控上就出现偶发无应答尤其是总线空闲一会儿再发请求时概率更高。排查后定位到两个原因。第一个原因是上面提过的超时设置太短主站请求帧发出后立刻切接收从站响应帧的前几个字节被截断主站收到的第一帧永远是残缺的。第二个原因是总线空闲时的电平不稳定RS485 在空闲状态时 A/B 之间的压差必须大于 200mV如果收发器没有加偏置电阻总线电平会漂在门限附近从站可能误判总线状态。解决办法是给 RS485 总线加上下拉偏置A 线对地接 10k 下拉B 线对电源接 10k 上拉同时把终端电阻保留。加完偏置电阻后空闲电平稳定后面再没有出现过这种随机丢帧。这类问题在实验室里很难复现因为实验室环境干扰小所以每次遇到总线偶发问题我第一反应都是检查总线偏置和终端匹配。4.3 温度异常速查表调试过程中遇到温度异常我习惯先按下面的表格排查比漫无目的改代码高效得多。现象可能原因检查点解决办法本地温度跳变幅度大供电纹波超标示波器测传感器 VDD 纹波加LDO滤波和大电容本地温度读数整体偏高探头位置靠近热源检查探头安装位置移出热区加导热介质I2C 偶发读不到数据上拉电阻不够或时序太快查 SCL/SDA 波形确认上拉 4.7k降低时钟远程节点间歇性无应答总线无偏置电阻测 A/B 空闲电压加 10k 上下拉偏置远程温度漂移从站供电不足查从站电源线压降加粗线径或单独供电远程节点离线误报超时太短查主站超时参数放宽到 200ms 左右这张表我每次新项目调试温度通道都会翻出来看大部分温度相关问题都能在里面找到方向。5. 往控制器里再走一步记录、告警与控制联动5.1 温度历史记录与超限告警温度和告警是强相关的。HVAC 设备里温度超限往往意味着换热异常、风机故障或者制冷剂问题。我之前在这个方案上扩展了两件事一是把本地和远程温度值周期写入 PIC18F86J55 的片内 EEPROM比如每五分钟记录一次掉电不丢失方便售后时查看历史温度曲线二是温度超限时通过 IO 输出告警信号或者通过 RS485 上报给上位机。很多 PIC18F86J55 的应用只把它当数据采集器用其实它还有片内数据存储自编程能力记录数据和跑逻辑都够用。如果记录点很多还可以外扩一块 SPI Flash成本很低。这里有个经验写 EEPROM 不要太频繁Flash 和 EEPROM 都有写寿命长时间持续写会提前磨损做分区写入、均衡磨损虽然代码多一点但对工业设备来说很值。5.2 本地远程温度联合进 PID一个实用的闭环思路最后说一个很多控制器设计者容易忽略的点本地温度和远程温度不是两个孤立的监控对象它们应该一起进控制逻辑。以恒温柜为例PJ85718DM 测的是柜内空气温度可以作为 PID 的主反馈量远程节点测的是换热器出口温度可以用作前馈或者保护条件。比如出口温度异常升高时即使本地温度还没超限也能提前降低加热功率避免系统惯性导致超调。我实际实现时是把本地温度作为主控制环路的反馈值远程温度作为辅助判断远程温度偏差超过设定阈值时把 PID 输出限幅调小等远程温度恢复正常再放开。这种联动逻辑让系统响应平稳很多。温度监测不只是看数字更要让数字参与决策这个思路放到任何 HVAC 项目里都适用。最后聊几句调试心态做温度采集调试大多数时候问题不在传感器本身而在电源、接线、时序、总线和环境干扰这些外围条件。PJ85718DM 和 PIC18F86J55 这套组合本身不复杂复杂的是把它放进一个真实的 HVAC 设备里还能保持稳定。我个人的习惯是每次改动只动一个变量量到波形再下结论不要凭感觉叠加重试次数和滤波层数那只会掩盖问题。把供电、接口、通信三个基础环节打扎实温度数据自然就稳了。