1. 项目拆解一套“本地远程”温度系统到底要解决什么做HVAC控制柜和嵌入式数据采集的工程师几乎都绕不开温度监测。温度这个物理量看起来最简单但真正落地一套既要做本地实时显示、又要远程上报的系统各种藏在细节里的坑才会慢慢浮出来。本文要聊的项目以PJ85718DM数字温度传感器为核心测温器件配合PIC24FJ64GB004这颗16位微控制器完成了一套同时覆盖嵌入式设备本地显示和HVAC现场远程集中上传的双通道温度监测方案。这套系统能做什么一句话就能说清本地通过字符屏实时显示多路温度同时通过RS-485总线把数据送到几十米外的监控室板载USB虚拟串口还能让调试人员直接插线读数据。无论你是刚开始碰MCU温度采集的开发者还是正在做机房环境监测、空调风系统测控这类项目的硬件工程师这套方案的思路都值得参考。文章不会停在原理图层面我会把选型理由、接口设计、固件流程和现场调试时踩过的坑全部交代清楚。1.1 为什么本地和远程两个需求必须同时存在HVAC系统里的温度监测看似就是“测温度”实际上至少分成两类用途。第一类是控制回路直接输入比如风机盘管回风温度、表冷器进出口水温这类温度要求实时和准确要直接参与PID调节或联锁保护第二类是管理层面的监测像机房环境温度、管道外壁温度、冷通道平均温度这类数据不直接参与控制但需要集中查看最好还能积累历史趋势。两类需求在同一个项目里撞车非常常见所以最合理的产品形态就是一个本地采集终端加远程监控平台并行。我在现场见过不少方案为了省事把所有温度数据统一交给上位机现场不保留任何显示。这个做法在运维阶段很麻烦电工师傅打开柜门的第一反应永远是看本地表头而不是去电脑上翻数据。反过来如果只做本地显示管理方拿不到实时数据设备异常时也没办法做追责和趋势分析。因此这个项目从设计初始就没把远程当作“后续扩展功能”而是本地和远程两条通道一视同仁同时开发、同时验证。1.2 器件角色分配谁负责感知谁负责控制PJ85718DM在系统里承担感知层工作把物理温度转换成可供单片机读取的数字量。PIC24FJ64GB004承担数据处理和通信层的全部工作负责轮询传感器、做滤波计算、驱动本地显示、响应远程和USB请求。两个器件各管一段选型时可以独立考虑不会出现“传感器性能够了但主控拖后腿”或者反过来“主控很强但传感器精度有限”的尴尬。PIC24FJ64GB004这款芯片我看重的是两个点第一是片上带USB控制器做虚拟串口完全不需要外接USB转串口芯片BOM成本和PCB面积都能省下一块第二是外设资源比较齐全I2C、UART、定时器、看门狗一个不缺适合把多路温度采集、人机交互、通信协议这些任务全部塞进一颗芯片。对HVAC这种讲究长期稳定性的设备来说用这种中等定位的16位MCU比使用廉价8位机性能余量充足又比直接上应用处理器简单可靠属于折中得比较舒服的选择。1.3 围绕测温环节的选型取舍温度测量的方案其实很多最简单的是NTC热敏电阻加分压电阻再通过ADC采集。这个方案成本极低但也有一个让我很头疼的问题每一路都要单独标定生产一致性不好。做单台样机无所谓一旦做几十台设备每台每一路都要做温度整定产线效率和售后成本都会很难看。数字温度传感器出厂前就做了校准直接读出摄氏度数值省掉了大量产线工作量整体成本反而更优。PJ85718DM就是按这个思路选进来的数字传感器。它和主控之间走I2C总线接线简单传感器地址还可以通过引脚电平改变一条I2C总线上挂多路传感器非常方便。主控选型方面如果项目只需要本地显示其实一颗低端控制器就够用但本系统需要USB和RS-485同时工作PIC24FJ64GB004自带USB控制器、又有多余的UART外设优势就很明显了。选型不是看谁参数最漂亮而是看谁刚好覆盖你全部需求并且不浪费。2. 硬件方案设计从采样点到通信链路的完整通路硬件设计这部分我认为最值得讲清楚的不是那张总原理图而是几个在调试阶段让人反复折腾的细节传感器与主控之间怎么接最稳本地显示和远程通信怎么共存HVAC现场干扰怎么防。把这些细节处理到位后面的固件调试才会顺利。2.1 传感器与主控的电气连接细节PJ85718DM按I2C接口方式接入PIC24FJ64GB004最简单的接法就是四根线电源、地、SDA、SCL。电源两端我习惯加一个0.1uF的去耦电容而且要尽量靠近传感器管脚。数字器件的高频开关噪声一旦耦合到传感器电源上会在特定温度区间造成读数的低频抖动这种问题看示波器波形反而不明显拉长时间看数据曲线就会发现温度值在某个范围内反复横跳。I2C上拉电阻的取值也值得展开讲。传感器和主控如果放在同一块板子上互连距离很短总线寄生电容小上拉电阻选4.7k比较合适信号边沿能保持得比较干净。但如果传感器通过延长线或者航空插头接到几米外的风管里总线寄生电容大幅上升这时候必须把上拉电阻降到2.2k甚至1k否则SCL上升沿会变缓I2C通讯偶发超时。这个现象在实验室桌面环境很难复现只有到现场拉长距离才会暴露我第一次做远距离传感器点位时就因为这个原因抓了很久的头发。传感器I2C地址也需要留意。PJ85718DM这类器件通常有地址选择引脚把A0/A1接到高电平或低电平就能配置出多个不同地址这样一条总线上可以挂多个传感器。我一般会在原理图上把地址选择引脚以跳线形式引出现场根据实际点位分配地址生产时再根据设备配置把跳线电阻焊死。这个方法在维护阶段特别有用某个传感器坏了不用拆总线直接按地址定位更换。2.2 本地显示、USB、RS-485三路输出如何在硬件上共存本地显示这一块我选了一块字符型LCD挂在主控的并行接口上。刷新频率不用太高2Hz足够人眼看温度变化本来就属于慢变量没必要让MCU一直忙着刷新屏幕。显示内容通常包括点位编号和温度值比如“T1: 24.5C”方便现场人员直接对照。远程通信硬件方面系统设计了两条独立的物理链路。第一条是RS-485。PIC24FJ64GB004的UART1输出经过一颗RS-485收发器转换成差分信号。RS-485收发器带一个方向控制引脚发送数据前必须把方向引脚拉成发送态发送完成后再切回接收态否则总线上的其他节点没法响应。这个方向切换看起来很基础但很多刚开始做RS-485通信的人都会在这里翻车方向切换早了数据没发完方向切换晚了总线一直被某个节点霸占。第二条是USB虚拟串口。PIC24FJ64GB004内部的USB控制器完成枚举后会被识别成一个CDC类虚拟串口上位机直接打开对应的COM口就能读数据。这个通道最典型的用途是现场调试工程师带一台笔记本电脑插上USB线即可看到MCU当前采集到的原始数据和通信状态不用额外依赖监控主机。它的另一个价值是作为本地固件升级通道搭配引导程序可以实现不开盖升级对售后服务非常友好。2.3 电源与抗干扰设计HVAC现场的核心难点HVAC现场对电子设备最大的考验来自变频器和冷机启停带来的电磁干扰。这套电路板我采用DC-DC方案把外部24V电源降到3.3V给MCU和传感器供电输入端加入整流滤波输出端再加一级LC滤波确保模拟和数字部分的电源纹波在可控范围内。3.3V电源的地平面和24V电源的输入地之间采用单点连接避免大电流回灌到数字地这是减少现场数据抖动的基础措施。RS-485接口的防护也不能省。总线端我加了自恢复保险丝和TVS管防止现场接线错误或者雷击感应电压把收发器打坏。温度传感器走延长线时如果现场变频器功率较大建议使用屏蔽双绞线并且屏蔽层单端接地。屏蔽层两端都接地会形成地环路反而会在屏蔽层上感应出更大的共模电流。双绞线的作用是让两根信号线上的干扰接近共模接收端的差分结构可以把它抑制掉。有一件事我吃过亏传感器线缆不要和动力线走在同一个线槽里至少要隔开几十厘米否则即使加了屏蔽变频器输出侧的强跳变电流还是能通过线间耦合串进信号。位置上实在躲不开时宁可把I2C速率从400kHz降到100kHz也不要贪快低速模式下信号容忍度会明显好很多。3. 固件实现一个可以直接抄作业的流程硬件只是骨架固件才是这套系统真正跑起来的关键。固件部分我会按模块拆开讲从传感器驱动、数据滤波、本地显示到远程RS-485报文协议和USB虚拟串口每段都给出可以直接改改就用的思路。别看每个模块单拎出来都不复杂组合在一起顺序和时间线会直接影响系统稳定性。3.1 传感器驱动与一阶低通滤波PJ85718DM这类I2C数字温度传感器的读取流程一般遵循一个固定套路发起温度转换等待转换完成读取温度寄存器的高字节和低字节再把两个字节拼成有符号整数乘以分辨率系数得到摄氏温度。下面代码按这个通用框架写。因为不同批次器件在寄存器地址定义上可能略有差异实际使用时请把宏定义替换成你手上数据手册里的真实地址。#define SENSOR_ADDR 0x48 // 按实际地址配置 #define REG_TEMP_MSB 0x00 // 温度高字节寄存器 #define REG_TEMP_LSB 0x01 // 温度低字节寄存器 uint8_t temp_read_reg(uint8_t reg) { uint8_t val 0; i2c_start(); i2c_write((SENSOR_ADDR 1) | 0); // 写方向 i2c_write(reg); i2c_stop(); i2c_start(); i2c_write((SENSOR_ADDR 1) | 1); // 读方向 val i2c_read(0); i2c_stop(); return val; } float temperature_read(void) { uint8_t msb temp_read_reg(REG_TEMP_MSB); uint8_t lsb temp_read_reg(REG_TEMP_LSB); int16_t raw (msb 8) | lsb; // 按分辨率系数换算示例按0.0625度/LSB return raw * 0.0625f; }读到的温度值不要直接送去显示和上传我强烈建议加一级一阶低通滤波。公式很简单filtered filtered * 0.8f new_sample * 0.2f;这个滤波的核心思想是让新采样值只占20%权重旧值占80%单次偶发跳变不会直接反应到输出上。0.8和0.2这组系数是我在HVAC项目里试出来的平衡点既能压制传感器靠近压缩机时的高频抖动又不会让温度响应慢得离谱。如果你需要特别快的响应可以把系数调到0.6/0.4如果传感器装在惯性大的水管表面可以调到0.9/0.1让曲线更平滑。3.2 本地显示与简单报警逻辑本地显示的实现重点是格式化字符串和定时刷新。我一般用定时器产生2Hz的中断标志主循环检测到标志后再刷新LCD而不是每轮循环都刷一次。这样既省MCU时间也避免屏幕频繁刷新出现闪烁感。while (1) { if (display_flag) { display_flag 0; snprintf(line_buf, 16, T1:%05.1fC, filtered_temp); lcd_line_write(0, line_buf); } }显示之外我还会加一组简单的越限报警逻辑。比如某个点位温度超过设定的上限主控直接驱动一个LED或者继电器同时把报警标志位放进远程报文里。报警阈值用EEPROM保存现场可以不改固件直接通过上位机写入调试时不用反复烧录程序。3.3 远程协议选型自定义帧还是Modbus RTU远程通信协议这部分我通常会根据项目对接方的要求来决定。如果上位机是自己写的或者只是简单的串口调试助手自定义帧协议完全够用。自定义帧的好处是结构透明、调试简单我常用的帧格式包含帧头、设备地址、数据区和CRC校验每250ms主动上报一次上位机只要按照帧头解析即可。如果项目要对接楼宇自控系统、SCADA或者第三方的组态软件那就必须换成Modbus RTU协议没有商量的余地。楼宇自控领域对Modbus兼容性的要求很严格自定义帧很难被通用组态软件识别。Modbus RTU从机实现时重点处理03功能码把多路温度放入保持寄存器区上位机通过轮询读取。不要觉得Modbus复杂其实它的核心就是接收请求帧、计算CRC、按功能码组织响应帧网上标准文档很多照着实现并没有门槛。3.4 RS-485方向切换与发送时序这个细节要单独拎出来讲。很多人把RS-485通信不稳定简单归因于干扰实际上最常见的根源是方向切换时序不对。发送前把方向脚拉高然后等待一小段时间让收发器完全切换再启动UART发送发送完成后要等待发送移位寄存器真正把数据全部送出去然后才能把方向脚拉低。如果方向脚拉低太早帧尾会被截断接收端收到的CRC必然错误。void rs485_send(uint8_t *buf, uint16_t len) { RS485_DE 1; // 进入发送模式 delay_us(10); // 等待收发器切换 uart_send_bytes(buf, len); // 发送数据 uart_wait_txe(); // 等待发送移位寄存器空 delay_us(5); // 确保最后一bit送完 RS485_DE 0; // 回到接收模式 }这里有两个延迟时间很重要切换等待时间取决于收发器数据手册给出的转换时间一般是几个微秒发送结束后的延迟则取决于波特率波特率越低一个bit的时间越长5us在9600波特率下大约只能覆盖半个bit如果实测帧尾被切就适当加大这个延迟。3.5 传感器校准与标定流程数字传感器出厂带校准但项目里多路传感器之间依然可能存在微小偏差。我的做法是做一个简单的两点校准把传感器探头放进冰水混合物记录读数偏差记为offset_0再放进恒温水浴或者用一个精度0.1度的参考温度计对比记录另一个偏差。最终在固件里做一个线性修正calibrated_temp raw_temp slope * raw_temp offset;HVAC温度监测通常不追求绝对精度现场误差控制在0.5度以内完全满足要求。冰水混合物提供0度参考点恒温水浴提供第二个参考点两点确定一条直线斜率修正增益误差偏移修正失调误差。校准完成后我会把修正系数写进EEPROM同一批硬件烧录同一个固件但每台设备的修正系数不同这样售后更换主板时也能保留原始校准数据。4. 实测记录与现场排坑软硬件都做完真正有价值的部分在实测阶段。这里我记录了实际运行过程中遇到的问题和对应排查思路尤其是几个看起来像玄学、实际有明确物理原因的故障。4.1 精度实测与修正结果设备在实验室恒温环境下跑了一周和参考水银温度计对比PJ85718DM裸读数偏差在正负0.3度以内经过两点校准后多个点位之间的最大偏差可以收敛到正负0.2度。这个精度做HVAC环境监测绰绰有余。但需要提醒的是传感器封装和实际安装位置对读数的影响比传感器自身精度大得多。我把传感器贴在管道外壁测量水温时得到的是管壁表面温度和管道内实际水温有偏差把传感器放在机柜内测量环境温度时如果旁边就是开关电源读出的温度会明显偏高。这个不是传感器精度问题是测量位置问题。所以我在每个传感器标签上标注了物理位置和测量对象避免后期误读数据。4.2 数据周期性跳动的根源有一台样机在测试时出现周期性读数跳动波动范围大约1度周期和现场压缩机的启停周期完全吻合。排查过程有点曲折先怀疑传感器本身换了两颗芯片还是一样又怀疑I2C干扰示波器抓SDA波形也没有明显异常。最后把万用表打在传感器电源两端发现压缩机启动瞬间传感器电源上有接近200mV的跌落这才定位到是电源问题。解决办法是给传感器供电单独加一级LDO而不是直接从3.3V总线上取电。LDO的输出纹波很小还能提供一定电源抑制比压缩机启停造成的电源跌落被隔离在外。另外我也把去耦电容从0.1uF加大到1uF进一步抬高电源抗跌落能力。这个故障是我在HVAC项目里印象最深的一个坑因为它的表象是“传感器读数波动”真实原因却在供电链路上。4.3 RS-485通信不稳定排查另一个高频问题是RS-485通信偶发失败。前期在实验室用短线测试一切正常到了现场接上几十米线缆后上位机每隔一段时间就报一次CRC错误。这里我排查了三个方向第一查方向切换时序确认收发器在9600波特率下切换时间足够第二查A/B线是否接反用万用表验证接线颜色第三查终端电阻实测后发现现场线路末端没有加120欧终端电阻信号在长线末端反射波形出现过冲和振铃。把终端电阻加上之后通信错误率明显下降。还要提醒一点RS-485终端电阻应该加在总线物理末端的两个节点上而不是每个节点都加。多节点并联时如果每个设备都加了120欧电阻总线上的等效负载会小到让收发器输出能力不足反而更难通信。4.4 常见故障排查速查表下面这个表格是我整理给自己的现场排障手册也分享出来供参考。每一类故障基本都对应明确的排查路径按顺序检查通常能快速定位问题。故障现象可能原因排查方法温度读数恒定不变或为0传感器未应答检查I2C地址配置、上拉电阻、接线排母读数偶发跳变1度以上传感器电源跌落检查去耦电容、是否单独供电、避免与驱动电路共用电源I2C通讯偶发超时总线电容过大降低上拉电阻、降速到100kHz、缩短延长线RS-485偶发CRC错误方向切换时序不对加大切换延迟避免帧尾被切断RS-485完全不通A/B反接核对总线极性用万用表电压法确认LCD显示花屏并行接口干扰或时序过快降低写屏频率检查排线是否过长远程数据偶尔断流缺少终端电阻在总线两端各加120欧终端电阻5. 扩展方向与生产化经验主体功能跑通以后这套系统还有不少可扩展空间。硬件上可以增加湿度传感器用同一颗MCU的I2C总线挂上去固件里增加一个采集通道输出端可以预留继电器实现温度超限自动联动风机或者报警。软件上可以做本地历史记录外挂一颗EEPROM或Micro SD卡定时把温度数据存下来即使上位机离线现场也有数据可以追溯。如果想进一步降低功耗让设备在电池供电下也能长期运行可以启用PIC24FJ64GB004的休眠模式平时MCU睡觉定时唤醒后采集一次温度然后继续睡觉。HVAC现场一般都有持续供电功耗不是首要问题但如果传感器点位分散且不方便拉线低功耗版本就很有实用价值。需要注意的是传感器在休眠期间是否也要断电如果传感器不断电它的静态功耗会抵消MCU的省电效果如果传感器断电唤醒后必须等待传感器重新稳定后再读取不能上电立即读数。生产化环节还有一个建议把每个传感器的物理位置编号和设备通信地址做一张对应表贴在柜门内侧。温度监测系统出问题找原因时最难的不是修电路而是确认数据对应的是哪台设备、哪个点位。我在现场见过很多次上位机报一个温度异常工程师先在电脑前面猜了半天最后还是得打开柜门看表头对应关系不清晰排查效率非常低。这套系统做完后我最大的体会是稳定可靠的温度监测七分靠合理的软硬件设计三分靠清晰完整的过程记录。越是看起来简单的功能越要在细节上较真这也是嵌入式项目调试中最有价值的那部分经验。 
长河君 · 2026/10/22 17:02:15 · 阅读 1.2k HVAC温度监测系统设计：PJ85718DM数字传感器与PIC24F双通道方案
1. 项目拆解一套“本地远程”温度系统到底要解决什么做HVAC控制柜和嵌入式数据采集的工程师几乎都绕不开温度监测。温度这个物理量看起来最简单但真正落地一套既要做本地实时显示、又要远程上报的系统各种藏在细节里的坑才会慢慢浮出来。本文要聊的项目以PJ85718DM数字温度传感器为核心测温器件配合PIC24FJ64GB004这颗16位微控制器完成了一套同时覆盖嵌入式设备本地显示和HVAC现场远程集中上传的双通道温度监测方案。这套系统能做什么一句话就能说清本地通过字符屏实时显示多路温度同时通过RS-485总线把数据送到几十米外的监控室板载USB虚拟串口还能让调试人员直接插线读数据。无论你是刚开始碰MCU温度采集的开发者还是正在做机房环境监测、空调风系统测控这类项目的硬件工程师这套方案的思路都值得参考。文章不会停在原理图层面我会把选型理由、接口设计、固件流程和现场调试时踩过的坑全部交代清楚。1.1 为什么本地和远程两个需求必须同时存在HVAC系统里的温度监测看似就是“测温度”实际上至少分成两类用途。第一类是控制回路直接输入比如风机盘管回风温度、表冷器进出口水温这类温度要求实时和准确要直接参与PID调节或联锁保护第二类是管理层面的监测像机房环境温度、管道外壁温度、冷通道平均温度这类数据不直接参与控制但需要集中查看最好还能积累历史趋势。两类需求在同一个项目里撞车非常常见所以最合理的产品形态就是一个本地采集终端加远程监控平台并行。我在现场见过不少方案为了省事把所有温度数据统一交给上位机现场不保留任何显示。这个做法在运维阶段很麻烦电工师傅打开柜门的第一反应永远是看本地表头而不是去电脑上翻数据。反过来如果只做本地显示管理方拿不到实时数据设备异常时也没办法做追责和趋势分析。因此这个项目从设计初始就没把远程当作“后续扩展功能”而是本地和远程两条通道一视同仁同时开发、同时验证。1.2 器件角色分配谁负责感知谁负责控制PJ85718DM在系统里承担感知层工作把物理温度转换成可供单片机读取的数字量。PIC24FJ64GB004承担数据处理和通信层的全部工作负责轮询传感器、做滤波计算、驱动本地显示、响应远程和USB请求。两个器件各管一段选型时可以独立考虑不会出现“传感器性能够了但主控拖后腿”或者反过来“主控很强但传感器精度有限”的尴尬。PIC24FJ64GB004这款芯片我看重的是两个点第一是片上带USB控制器做虚拟串口完全不需要外接USB转串口芯片BOM成本和PCB面积都能省下一块第二是外设资源比较齐全I2C、UART、定时器、看门狗一个不缺适合把多路温度采集、人机交互、通信协议这些任务全部塞进一颗芯片。对HVAC这种讲究长期稳定性的设备来说用这种中等定位的16位MCU比使用廉价8位机性能余量充足又比直接上应用处理器简单可靠属于折中得比较舒服的选择。1.3 围绕测温环节的选型取舍温度测量的方案其实很多最简单的是NTC热敏电阻加分压电阻再通过ADC采集。这个方案成本极低但也有一个让我很头疼的问题每一路都要单独标定生产一致性不好。做单台样机无所谓一旦做几十台设备每台每一路都要做温度整定产线效率和售后成本都会很难看。数字温度传感器出厂前就做了校准直接读出摄氏度数值省掉了大量产线工作量整体成本反而更优。PJ85718DM就是按这个思路选进来的数字传感器。它和主控之间走I2C总线接线简单传感器地址还可以通过引脚电平改变一条I2C总线上挂多路传感器非常方便。主控选型方面如果项目只需要本地显示其实一颗低端控制器就够用但本系统需要USB和RS-485同时工作PIC24FJ64GB004自带USB控制器、又有多余的UART外设优势就很明显了。选型不是看谁参数最漂亮而是看谁刚好覆盖你全部需求并且不浪费。2. 硬件方案设计从采样点到通信链路的完整通路硬件设计这部分我认为最值得讲清楚的不是那张总原理图而是几个在调试阶段让人反复折腾的细节传感器与主控之间怎么接最稳本地显示和远程通信怎么共存HVAC现场干扰怎么防。把这些细节处理到位后面的固件调试才会顺利。2.1 传感器与主控的电气连接细节PJ85718DM按I2C接口方式接入PIC24FJ64GB004最简单的接法就是四根线电源、地、SDA、SCL。电源两端我习惯加一个0.1uF的去耦电容而且要尽量靠近传感器管脚。数字器件的高频开关噪声一旦耦合到传感器电源上会在特定温度区间造成读数的低频抖动这种问题看示波器波形反而不明显拉长时间看数据曲线就会发现温度值在某个范围内反复横跳。I2C上拉电阻的取值也值得展开讲。传感器和主控如果放在同一块板子上互连距离很短总线寄生电容小上拉电阻选4.7k比较合适信号边沿能保持得比较干净。但如果传感器通过延长线或者航空插头接到几米外的风管里总线寄生电容大幅上升这时候必须把上拉电阻降到2.2k甚至1k否则SCL上升沿会变缓I2C通讯偶发超时。这个现象在实验室桌面环境很难复现只有到现场拉长距离才会暴露我第一次做远距离传感器点位时就因为这个原因抓了很久的头发。传感器I2C地址也需要留意。PJ85718DM这类器件通常有地址选择引脚把A0/A1接到高电平或低电平就能配置出多个不同地址这样一条总线上可以挂多个传感器。我一般会在原理图上把地址选择引脚以跳线形式引出现场根据实际点位分配地址生产时再根据设备配置把跳线电阻焊死。这个方法在维护阶段特别有用某个传感器坏了不用拆总线直接按地址定位更换。2.2 本地显示、USB、RS-485三路输出如何在硬件上共存本地显示这一块我选了一块字符型LCD挂在主控的并行接口上。刷新频率不用太高2Hz足够人眼看温度变化本来就属于慢变量没必要让MCU一直忙着刷新屏幕。显示内容通常包括点位编号和温度值比如“T1: 24.5C”方便现场人员直接对照。远程通信硬件方面系统设计了两条独立的物理链路。第一条是RS-485。PIC24FJ64GB004的UART1输出经过一颗RS-485收发器转换成差分信号。RS-485收发器带一个方向控制引脚发送数据前必须把方向引脚拉成发送态发送完成后再切回接收态否则总线上的其他节点没法响应。这个方向切换看起来很基础但很多刚开始做RS-485通信的人都会在这里翻车方向切换早了数据没发完方向切换晚了总线一直被某个节点霸占。第二条是USB虚拟串口。PIC24FJ64GB004内部的USB控制器完成枚举后会被识别成一个CDC类虚拟串口上位机直接打开对应的COM口就能读数据。这个通道最典型的用途是现场调试工程师带一台笔记本电脑插上USB线即可看到MCU当前采集到的原始数据和通信状态不用额外依赖监控主机。它的另一个价值是作为本地固件升级通道搭配引导程序可以实现不开盖升级对售后服务非常友好。2.3 电源与抗干扰设计HVAC现场的核心难点HVAC现场对电子设备最大的考验来自变频器和冷机启停带来的电磁干扰。这套电路板我采用DC-DC方案把外部24V电源降到3.3V给MCU和传感器供电输入端加入整流滤波输出端再加一级LC滤波确保模拟和数字部分的电源纹波在可控范围内。3.3V电源的地平面和24V电源的输入地之间采用单点连接避免大电流回灌到数字地这是减少现场数据抖动的基础措施。RS-485接口的防护也不能省。总线端我加了自恢复保险丝和TVS管防止现场接线错误或者雷击感应电压把收发器打坏。温度传感器走延长线时如果现场变频器功率较大建议使用屏蔽双绞线并且屏蔽层单端接地。屏蔽层两端都接地会形成地环路反而会在屏蔽层上感应出更大的共模电流。双绞线的作用是让两根信号线上的干扰接近共模接收端的差分结构可以把它抑制掉。有一件事我吃过亏传感器线缆不要和动力线走在同一个线槽里至少要隔开几十厘米否则即使加了屏蔽变频器输出侧的强跳变电流还是能通过线间耦合串进信号。位置上实在躲不开时宁可把I2C速率从400kHz降到100kHz也不要贪快低速模式下信号容忍度会明显好很多。3. 固件实现一个可以直接抄作业的流程硬件只是骨架固件才是这套系统真正跑起来的关键。固件部分我会按模块拆开讲从传感器驱动、数据滤波、本地显示到远程RS-485报文协议和USB虚拟串口每段都给出可以直接改改就用的思路。别看每个模块单拎出来都不复杂组合在一起顺序和时间线会直接影响系统稳定性。3.1 传感器驱动与一阶低通滤波PJ85718DM这类I2C数字温度传感器的读取流程一般遵循一个固定套路发起温度转换等待转换完成读取温度寄存器的高字节和低字节再把两个字节拼成有符号整数乘以分辨率系数得到摄氏温度。下面代码按这个通用框架写。因为不同批次器件在寄存器地址定义上可能略有差异实际使用时请把宏定义替换成你手上数据手册里的真实地址。#define SENSOR_ADDR 0x48 // 按实际地址配置 #define REG_TEMP_MSB 0x00 // 温度高字节寄存器 #define REG_TEMP_LSB 0x01 // 温度低字节寄存器 uint8_t temp_read_reg(uint8_t reg) { uint8_t val 0; i2c_start(); i2c_write((SENSOR_ADDR 1) | 0); // 写方向 i2c_write(reg); i2c_stop(); i2c_start(); i2c_write((SENSOR_ADDR 1) | 1); // 读方向 val i2c_read(0); i2c_stop(); return val; } float temperature_read(void) { uint8_t msb temp_read_reg(REG_TEMP_MSB); uint8_t lsb temp_read_reg(REG_TEMP_LSB); int16_t raw (msb 8) | lsb; // 按分辨率系数换算示例按0.0625度/LSB return raw * 0.0625f; }读到的温度值不要直接送去显示和上传我强烈建议加一级一阶低通滤波。公式很简单filtered filtered * 0.8f new_sample * 0.2f;这个滤波的核心思想是让新采样值只占20%权重旧值占80%单次偶发跳变不会直接反应到输出上。0.8和0.2这组系数是我在HVAC项目里试出来的平衡点既能压制传感器靠近压缩机时的高频抖动又不会让温度响应慢得离谱。如果你需要特别快的响应可以把系数调到0.6/0.4如果传感器装在惯性大的水管表面可以调到0.9/0.1让曲线更平滑。3.2 本地显示与简单报警逻辑本地显示的实现重点是格式化字符串和定时刷新。我一般用定时器产生2Hz的中断标志主循环检测到标志后再刷新LCD而不是每轮循环都刷一次。这样既省MCU时间也避免屏幕频繁刷新出现闪烁感。while (1) { if (display_flag) { display_flag 0; snprintf(line_buf, 16, T1:%05.1fC, filtered_temp); lcd_line_write(0, line_buf); } }显示之外我还会加一组简单的越限报警逻辑。比如某个点位温度超过设定的上限主控直接驱动一个LED或者继电器同时把报警标志位放进远程报文里。报警阈值用EEPROM保存现场可以不改固件直接通过上位机写入调试时不用反复烧录程序。3.3 远程协议选型自定义帧还是Modbus RTU远程通信协议这部分我通常会根据项目对接方的要求来决定。如果上位机是自己写的或者只是简单的串口调试助手自定义帧协议完全够用。自定义帧的好处是结构透明、调试简单我常用的帧格式包含帧头、设备地址、数据区和CRC校验每250ms主动上报一次上位机只要按照帧头解析即可。如果项目要对接楼宇自控系统、SCADA或者第三方的组态软件那就必须换成Modbus RTU协议没有商量的余地。楼宇自控领域对Modbus兼容性的要求很严格自定义帧很难被通用组态软件识别。Modbus RTU从机实现时重点处理03功能码把多路温度放入保持寄存器区上位机通过轮询读取。不要觉得Modbus复杂其实它的核心就是接收请求帧、计算CRC、按功能码组织响应帧网上标准文档很多照着实现并没有门槛。3.4 RS-485方向切换与发送时序这个细节要单独拎出来讲。很多人把RS-485通信不稳定简单归因于干扰实际上最常见的根源是方向切换时序不对。发送前把方向脚拉高然后等待一小段时间让收发器完全切换再启动UART发送发送完成后要等待发送移位寄存器真正把数据全部送出去然后才能把方向脚拉低。如果方向脚拉低太早帧尾会被截断接收端收到的CRC必然错误。void rs485_send(uint8_t *buf, uint16_t len) { RS485_DE 1; // 进入发送模式 delay_us(10); // 等待收发器切换 uart_send_bytes(buf, len); // 发送数据 uart_wait_txe(); // 等待发送移位寄存器空 delay_us(5); // 确保最后一bit送完 RS485_DE 0; // 回到接收模式 }这里有两个延迟时间很重要切换等待时间取决于收发器数据手册给出的转换时间一般是几个微秒发送结束后的延迟则取决于波特率波特率越低一个bit的时间越长5us在9600波特率下大约只能覆盖半个bit如果实测帧尾被切就适当加大这个延迟。3.5 传感器校准与标定流程数字传感器出厂带校准但项目里多路传感器之间依然可能存在微小偏差。我的做法是做一个简单的两点校准把传感器探头放进冰水混合物记录读数偏差记为offset_0再放进恒温水浴或者用一个精度0.1度的参考温度计对比记录另一个偏差。最终在固件里做一个线性修正calibrated_temp raw_temp slope * raw_temp offset;HVAC温度监测通常不追求绝对精度现场误差控制在0.5度以内完全满足要求。冰水混合物提供0度参考点恒温水浴提供第二个参考点两点确定一条直线斜率修正增益误差偏移修正失调误差。校准完成后我会把修正系数写进EEPROM同一批硬件烧录同一个固件但每台设备的修正系数不同这样售后更换主板时也能保留原始校准数据。4. 实测记录与现场排坑软硬件都做完真正有价值的部分在实测阶段。这里我记录了实际运行过程中遇到的问题和对应排查思路尤其是几个看起来像玄学、实际有明确物理原因的故障。4.1 精度实测与修正结果设备在实验室恒温环境下跑了一周和参考水银温度计对比PJ85718DM裸读数偏差在正负0.3度以内经过两点校准后多个点位之间的最大偏差可以收敛到正负0.2度。这个精度做HVAC环境监测绰绰有余。但需要提醒的是传感器封装和实际安装位置对读数的影响比传感器自身精度大得多。我把传感器贴在管道外壁测量水温时得到的是管壁表面温度和管道内实际水温有偏差把传感器放在机柜内测量环境温度时如果旁边就是开关电源读出的温度会明显偏高。这个不是传感器精度问题是测量位置问题。所以我在每个传感器标签上标注了物理位置和测量对象避免后期误读数据。4.2 数据周期性跳动的根源有一台样机在测试时出现周期性读数跳动波动范围大约1度周期和现场压缩机的启停周期完全吻合。排查过程有点曲折先怀疑传感器本身换了两颗芯片还是一样又怀疑I2C干扰示波器抓SDA波形也没有明显异常。最后把万用表打在传感器电源两端发现压缩机启动瞬间传感器电源上有接近200mV的跌落这才定位到是电源问题。解决办法是给传感器供电单独加一级LDO而不是直接从3.3V总线上取电。LDO的输出纹波很小还能提供一定电源抑制比压缩机启停造成的电源跌落被隔离在外。另外我也把去耦电容从0.1uF加大到1uF进一步抬高电源抗跌落能力。这个故障是我在HVAC项目里印象最深的一个坑因为它的表象是“传感器读数波动”真实原因却在供电链路上。4.3 RS-485通信不稳定排查另一个高频问题是RS-485通信偶发失败。前期在实验室用短线测试一切正常到了现场接上几十米线缆后上位机每隔一段时间就报一次CRC错误。这里我排查了三个方向第一查方向切换时序确认收发器在9600波特率下切换时间足够第二查A/B线是否接反用万用表验证接线颜色第三查终端电阻实测后发现现场线路末端没有加120欧终端电阻信号在长线末端反射波形出现过冲和振铃。把终端电阻加上之后通信错误率明显下降。还要提醒一点RS-485终端电阻应该加在总线物理末端的两个节点上而不是每个节点都加。多节点并联时如果每个设备都加了120欧电阻总线上的等效负载会小到让收发器输出能力不足反而更难通信。4.4 常见故障排查速查表下面这个表格是我整理给自己的现场排障手册也分享出来供参考。每一类故障基本都对应明确的排查路径按顺序检查通常能快速定位问题。故障现象可能原因排查方法温度读数恒定不变或为0传感器未应答检查I2C地址配置、上拉电阻、接线排母读数偶发跳变1度以上传感器电源跌落检查去耦电容、是否单独供电、避免与驱动电路共用电源I2C通讯偶发超时总线电容过大降低上拉电阻、降速到100kHz、缩短延长线RS-485偶发CRC错误方向切换时序不对加大切换延迟避免帧尾被切断RS-485完全不通A/B反接核对总线极性用万用表电压法确认LCD显示花屏并行接口干扰或时序过快降低写屏频率检查排线是否过长远程数据偶尔断流缺少终端电阻在总线两端各加120欧终端电阻5. 扩展方向与生产化经验主体功能跑通以后这套系统还有不少可扩展空间。硬件上可以增加湿度传感器用同一颗MCU的I2C总线挂上去固件里增加一个采集通道输出端可以预留继电器实现温度超限自动联动风机或者报警。软件上可以做本地历史记录外挂一颗EEPROM或Micro SD卡定时把温度数据存下来即使上位机离线现场也有数据可以追溯。如果想进一步降低功耗让设备在电池供电下也能长期运行可以启用PIC24FJ64GB004的休眠模式平时MCU睡觉定时唤醒后采集一次温度然后继续睡觉。HVAC现场一般都有持续供电功耗不是首要问题但如果传感器点位分散且不方便拉线低功耗版本就很有实用价值。需要注意的是传感器在休眠期间是否也要断电如果传感器不断电它的静态功耗会抵消MCU的省电效果如果传感器断电唤醒后必须等待传感器重新稳定后再读取不能上电立即读数。生产化环节还有一个建议把每个传感器的物理位置编号和设备通信地址做一张对应表贴在柜门内侧。温度监测系统出问题找原因时最难的不是修电路而是确认数据对应的是哪台设备、哪个点位。我在现场见过很多次上位机报一个温度异常工程师先在电脑前面猜了半天最后还是得打开柜门看表头对应关系不清晰排查效率非常低。这套系统做完后我最大的体会是稳定可靠的温度监测七分靠合理的软硬件设计三分靠清晰完整的过程记录。越是看起来简单的功能越要在细节上较真这也是嵌入式项目调试中最有价值的那部分经验。