最近一个暖通HVAC控制器改造项目里客户提出一个听起来很简单的需求既要看控制板内部的温升又要看风道里的空气温度。等真正拆开需求才发现这是两套测温逻辑——本地温度用来做保护远程温度用来参与控制两者如果混在一起整个温控策略都会乱掉。我手上的主控是PIC32MX795F512L温度传感器则统一换成PJ85718DM一颗12位I2C接口的数字温度传感器。两路温度、同一颗芯片、同一套驱动硬件和软件都能简化很多。这套本地与远程温度监测方案在嵌入式和HVAC应用里实测跑得很稳这篇就把架构选型、硬件设计、驱动移植、数据处理和工程避坑完整记录一遍给正在做类似项目的同行一个可复用的参考。1. 系统架构与两路温度监测的职责划分1.1 HVAC监测场景里本地与远程温度分别解决什么问题先还原一下现场。HVAC控制器通常装在室内机或控制柜里板上有开关电源、继电器、主控芯片这些发热源。控制器自身有一个环境工作温度范围一般要保证在-20°C到70°C之间正常运行超过这个范围就可能出现电容老化加速、晶振频率漂移、继电器线圈阻值变化等问题。所以本地温度监测本质上是在盯控制器自己的体温属于设备保护性质的测量。远程温度就完全不同了。风道里的送风温度、回风温度、室外换热器温度这些是HVAC系统做闭环控制的核心输入。压缩机要不要启动、风机转速调到多少、电子膨胀阀开度怎么变化都要看这几个温度点。这类测量关注的是环境本身的状态数据会被控制器拿去参与算法计算属于控制性质的测量。实际项目中这两个测点经常被混成一谈。有一次我把本地传感器放在主控芯片旁边结果读到的温度比机箱环境温度高了快10°C客户拿红外温度枪一测风道没问题但控制逻辑却因为温度异常告警了。后来才意识到板载传感器如果离发热器件太近测到的其实是芯片温升不是控制器内部环境温度更不能直接代表外部环境。所以系统设计的第一步是先把测量对象定义清楚本地测什么、远程测什么、各自动作逻辑是什么这比选什么芯片更重要。1.2 为什么是PIC32MX795F512L PJ85718DM这个组合选主控的时候PIC32MX795F512L这颗芯片在项目里的地位很明确512KB Flash和128KB RAM在HVAC控制器里完全够用80MHz的MIPS M4K内核跑Modbus协议栈、PID温控算法、LCD驱动都绰绰有余不需要上更复杂的MPU。最打动我的是它的外设配置。PIC32MX795F512L带两个独立的I2C模块I2C1和I2C2这意味着本地温度和远程温度可以在物理上分成两条独立总线互不干扰。另外这颗芯片的I2C模块有比较完善的寄存器状态标志比如重复起始、ACK检测、接收缓冲满等对这些标志位做轮询调度很容易判断通信状态而且还有6个UART后续如果要和上位机或触摸屏通信串口资源也不用省着用。传感器选择PJ85718DM原因其实很实在这颗传感器是标准I2C接口、12位分辨率、测温范围覆盖-55°C到125°C在HVAC的应用温度区间内精度足够而且多颗传感器可以通过地址引脚配置成不同地址挂同一条总线上挨个轮询。对我来说最大的收益是软件统一——不用再像以前那样本地用NTC热敏电阻采样、远程用其他数字传感器软件得维护两套驱动。统一用PJ85718DM之后本地和远程只是挂在不同总线上或者不同地址而已读取逻辑完全一致备料和测试都省心很多。1.3 总线拓扑单条I2C挂多个节点还是双I2C模块分流PJ85718DM这类传感器的地址线数量有限一般有A0、A1两个引脚可配置加上基地址一条总线上能挂4颗。如果项目只需要2到3个测温点单条I2C总线是完全够用的。但我在这个项目里还是把本地和远程拆到了两条总线上。原因是可靠性和故障隔离。远程传感器要通过线缆拉到风道、室外机或者水管上线缆本身就是最大的干扰引入点。如果远程那一路出了短路故障只会在I2C2上面发作I2C1上的本地温度仍然正常控制器至少还能做远程温度异常、保持当前状态、报警通知的处理。如果把所有传感器都挂一条总线一个远程节点出问题整条总线上的传感器全部读不到连本地保护温度都丢了这在小故障演变成大问题之前就等于先把自己置于盲飞状态。两条总线还有一个好处可以给不同应用场景设置不同的通信速率和滤波强度。本地总线上传感器近、线缆短、信号干净直接用400kHz快速模式读取远程总线考虑线缆电容可以降到100kHz标准模式牺牲一点速率换稳定。这个拓扑思路后面接其他传感器也方便比如再挂一个温湿度传感器分配到哪条总线都不会挤压现有温度采样周期。2. 硬件设计要点地址配置、上拉电阻与远程线缆防护2.1 PJ85718DM的引脚、地址分配与寄存器概览PJ85718DM的引脚定义和市面主流的12位I2C温度传感器基本一致VDD、GND、SDA、SCL再加上A0、A1两个地址选择引脚。地址的计算逻辑很简单基地址固定A0和A1接不同电平就能得到不同地址比如基地址0x48A0接高地址加1A1接高地址加2。实际布局时本地传感器地址设成0x48远程第一颗设成0x49第二颗设成0x4A代码里用数组管理地址列表加传感器就是往数组里加一个元素的事。有一点要提醒一下地址引脚千万别悬空。有些开发板为了省事不焊地址设置全部悬空结果所有传感器读到的地址都是同一个I2C总线上直接冲突两颗设备同时应答数据完全乱套。哪怕只挂一颗传感器地址引脚也要明确接到VDD或GND上这是一个成本几乎为零、但能省掉大量调试时间的习惯。寄存器结构也相对直观一般有温度数据寄存器、配置寄存器、上限报警寄存器、迟滞报警寄存器。温度寄存器是只读的存的是12位温度数值配置寄存器决定分辨率等参数上限和迟滞寄存器用于设定硬件报警阈值。这个项目里我主要用温度数据寄存器软件每周期读取一次并自己处理数据硬件报警功能暂时空着。寄存器详细偏移地址每个厂家略有差异焊接前第一件事就是把手册对应页摘出来打印放在工位上后面调试会经常翻。2.2 I2C上拉电阻到底取多大算一次就记住I2C是开漏结构SDA和SCL必须各接一个上拉电阻。这个电阻的取值不是拍脑袋定的它直接影响总线的上升沿时间。I2C协议规定了不同模式下的最大上升时间标准模式100kHz是1微秒快速模式400kHz是300纳秒。上升时间、总线上电容和上拉电阻之间的关系是上升时间约等于0.8473乘以总线电容乘以上拉电阻。我实际算了一遍。假设远程总线有1米左右的线缆双绞线加上传感器输入电容总线电容估算在250到300pF左右按快速模式300纳秒的上限要求上拉电阻就得在1.2到1.4千欧附近。而本地板上走线很短总线电容可能只有100到150pF用2.2千欧左右就能满足上升沿要求而且还能省一点功耗。所以我在本地传感器上用2.2千欧远程传感器总线用1.2千欧最好把示波器探头夹在SCL上实测一下上升沿波形再做最后确认。需要说明的是这是算一次就记住的方式。实际项目里如果远程线缆再长或者多挂传感器导致电容增大就不要迷信计算值了最可靠的做法还是示波器实测波形确认上升沿没有呈圆弧状拖尾、没有明显的振铃。总线电容这东西很难精确估算线缆厂家给的每米电容值也只是一个参考实测得到的是最终答案。2.3 远程传感器长线布线的抗干扰处理HVAC现场是典型的强电干扰环境压缩机和风机启停的时候线缆上会感应出很高的噪声尖峰。远程温度传感器线缆如果直接裸奔I2C信号很容易被干扰轻则读到跳变的温度值重则总线挂死。我在这条远程总线上做了三件事实测效果不错。第一是线缆选型用带屏蔽的双绞线屏蔽层在控制器端单点接地不要两端都接地避免形成地环路。第二是在远程节点进线端口并了一个双向TVS管加一颗1千欧以内的串联电阻这样即使线缆被打出高压尖峰也能先被TVS钳住不会直接打到传感器的SDA、SCL引脚上。第三是接插件选带锁扣的端子防止现场震动导致传感器线松脱。这三样东西成本都不高但能避免大多数温度偶尔跳一下的灵异问题。如果远程距离超过1米我更建议在总线中间加I2C总线缓冲器或者在远程侧放一个小PCB板集中处理多个传感器再通过一根线回传。I2C的物理层本身是为板级短距离通信设计的别指望它能像RS-485那样跑个几百米还稳定。HVAC应用里有一句话叫传感器远不远不重要信号干不干净才重要说的就是这个道理。3. PIC32MX795F512L上的I2C驱动实现与温度读取3.1 用寄存器操作I2C还是MCC自动生成在PIC32上做I2C通信有两条路一条是用MPLAB Code ConfiguratorMCC自动生成驱动代码图形化配置接口参数生成之后直接调用API另一条是直接操作PIC32的I2C寄存器自己写启动、停止、发送、接收的时序控制。MCC的优点是上手快点几下鼠标就能把I2C初始化代码生成好。但做HVAC控制器这种需要长期维护、现场环境复杂的项目我更推荐直接操作寄存器。原因不是MCC生成的代码不好而是寄存器的状态机完全透明可控什么时候检查总线忙不忙什么时候判断ACK什么时候处理重启动每个标志位都明明白白。现场如果出了通信问题对着数据手册一行行看寄存器状态比在MCC生成的抽象层代码里翻来翻去找问题要快得多。另外PIC32的I2C外设本身就是一个硬件状态机只要按顺序设置控制位它就会自动完成时序动作。而且寄存器操作方式生成的代码量非常小对Flash占用几乎可以忽略对于温度采集这种固定流程的通信来说完全够用。3.2 一次完整温度读取时序、代码与关键标志位一次完整的温度读取本质上是I2C通信的读流程PJ85718DM这类温度传感器的标准读法是先发设备写地址再写一个寄存器指针指定要读的寄存器然后重新发一次启动信号换成设备读地址连续读两个字节最后停止。整个过程里最容易被忽略的是重启动这一步——读地址不能跟在写地址后面直接发必须先发一个重复起始位总线才能切换读写方向。下面这段代码是我在实际项目里用的核心函数基于PIC32的I2C寄存器操作// 从PJ85718DM读取温度原始值返回12位整数温度码 // slaveAddr7bit为7位设备地址例如0x48 int16_t PJ85718DM_ReadRaw(uint8_t slaveAddr7bit) { uint8_t hi, lo; // 等待总线空闲 while (I2C1CONbits.SEN || I2C1STATbits.TRSTAT || I2C1STATbits.ACKSTAT); // 1. 启动 I2C1CONbits.SEN 1; while (I2C1CONbits.SEN); // 2. 发送设备写地址 I2C1TRN (slaveAddr7bit 1) | 0; while (I2C1STATbits.TRSTAT); if (I2C1STATbits.ACKSTAT) { I2C1CONbits.PEN 1; return -1; } // 3. 写寄存器指针0x00 温度寄存器 I2C1TRN 0x00; while (I2C1STATbits.TRSTAT); if (I2C1STATbits.ACKSTAT) { I2C1CONbits.PEN 1; return -1; } // 4. 重复启动 I2C1CONbits.RSEN 1; while (I2C1CONbits.RSEN); // 5. 发送设备读地址 I2C1TRN (slaveAddr7bit 1) | 1; while (I2C1STATbits.TRSTAT); if (I2C1STATbits.ACKSTAT) { I2C1CONbits.PEN 1; return -1; } // 6. 读高字节返回ACK I2C1CONbits.RCEN 1; while (!I2C1STATbits.RBF); hi I2C1RCV; I2C1CONbits.ACKDT 0; I2C1CONbits.ACKEN 1; while (I2C1CONbits.ACKEN); // 7. 读低字节返回NAK I2C1CONbits.RCEN 1; while (!I2C1STATbits.RBF); lo I2C1RCV; I2C1CONbits.ACKDT 1; I2C1CONbits.ACKEN 1; while (I2C1CONbits.ACKEN); // 8. 停止 I2C1CONbits.PEN 1; while (I2C1CONbits.PEN); return (int16_t)((hi 8) | lo); }这里有一个经验读取最后一个字节时要回NAK这是告诉从机不要再发了我要结束这次读取。如果两个字节都回了ACK从机会继续尝试发送下一个字节总线时序就可能错乱。很多人第一次写I2C驱动都会在这个地方踩坑。另外PIC32的I2C中断标志位和状态位的含义在不同批次的数据手册上表述略有差异实际调试时最直接的办法就是在每个步骤后加一个断言或串口打印打印关键状态位的值这样能迅速判断卡在哪一步。3.3 轮询多节点传感器时的调度策略本地加远程一共三颗传感器之后主循环里的温度采集调度就要想清楚。HVAC温度变化本身很慢远程风道温度一分钟能变个两三度已经算剧烈了所以不需要每毫秒都去读传感器。我的做法是设置一个100毫秒的定时器节拍每个节拍只读一颗传感器三颗轮询下来就是300毫秒一轮既满足控制需要又不会占用总线太久。轮询顺序上我习惯先读本地传感器再读远程传感器。原因是本地温度参与的是保护逻辑优先级更高一旦控制板过温需要立即发现。远程温度即使晚几百毫秒读到也不影响控制效果毕竟风道热惯量在那里摆着数据不会因为这点延迟就失效。还有一个细节是轮询时如果遇到某颗传感器通信失败不要立刻重试。因为重试大概率还是失败反而会浪费总线时间、拖慢其他正常节点的读取。我的策略是记录连续失败次数连续失败超过3次才判定设备故障触发告警。中间某次成功读取就会重置失败计数。这样处理下来带瞬间干扰的毛刺会被自动过滤掉远程总线也比较稳定。4. 数据从原始值到可用的温度换算、滤波与标定4.1 12位原始值怎么换算成摄氏度PJ85718DM的12位温度数值是左对齐存放在16位寄存器里的也就是说读出来的两个字节中高字节是高8位有效数据低字节的高4位是剩下的有效位低4位恒为0。所以在代码里要把读回的16位原始值右移4位得到一个12位的有符号整型再乘以每个LSB代表的温度步进0.0625°C就得到实际的摄氏度数值。int16_t raw PJ85718DM_ReadRaw(0x48); if (raw 0) { raw 4; } else { raw (raw 0x10000) 4; // 负数需要先把符号位扩展回来再做右移 } float tempC raw * 0.0625f;这里负温度处理是个常见的坑。C语言对有符号整型的右移在负数时是算术右移编译器平台不同行为也不完全一致直接对负的16位值做右移可能得不到正确的结果。最稳妥的做法是先扩展成32位有符号数再统一右移或者像我上面这样正负分别处理。HVAC的应用场景经常要测零下的温度这个细节在冬天现场调试的时候会很关键。另外有些温度传感器的温度寄存器在12位模式下会有符号位扩展高字节直接读出0xFE不代表温度寄存器异常而是代表负温度的高字节值。早期开发时我经常看到0xFE或0xFF的高字节就以为是传感器坏了后来才意识到这是在表示负温。所以算法里第一步永远是把原始值当成有符号数处理再做右移和乘法。4.2 软件滤波组合滑动平均中值剔除温度信号的特点是变化慢但有随机噪声配合远程线缆的意外干扰单次读取的数据偶尔会离谱地跳变。只用滑动平均一个毛刺就会被拉进平均值里导致滤波结果整体偏移只用中值滤波响应速度又不够。我实际使用的是一个组合策略先做中值剔除再做滑动平均。具体来说每收集5次原始读数排序后去掉最大和最小值剩下的3个取平均得到一次干净值然后再把连续8次干净值做滑动平均输出给上层逻辑使用。5次中值取3次平均再加上8次滑动平均等效时间常数大约1秒左右对HVAC来说响应足够快数据又非常平滑。#define MEDIAN_N 5 #define SMOOTH_N 8 static float MedianAndAverage(float newVal) { float buf[MEDIAN_N], sum 0, tmp; // 将新值插入循环缓冲区取5个值 // 排序并去掉最大最小值求中间3个的平均 // 再把这个平均值送入滑动平均缓冲区 // 滑动平均返回最终结果 }实测下来这套组合能有效消除绝大多数瞬时干扰。有一次远程传感器线缆经过一个继电器旁边继电器吸合瞬间总会产生一个很大的尖峰单次读取偶尔跳到60°C以上但经过中值剔除后滤波输出的温度曲线几乎没有肉眼可见的毛刺。滤波的代价是输出延迟。做这种滤波之前要确认系统对温度响应速度的要求如果要做快速的过热保护就应该直接使用原始值做保护判断滤波后的平滑值只用于控制显示。保护逻辑和显示逻辑分开这是我做HVAC控制器的一个习惯。4.3 两点校准与系数存储PJ85718DM这类传感器的出厂精度一般在±0.5°C左右大部分应用直接使用没问题。但对HVAC控制来说测温的绝对准确性有时没有一致性重要——多台设备如果每台都偏零点几度集中监控界面上就会出现几台设备显示温度不一致的情况这很影响用户体验。所以我自己加了一步软件校准。校准方法很简单拿一颗经过计量比对的标准温度计或恒温槽把传感器和标准温度计放在同一个温度环境中做两个温度点记录比如0°C冰水混合物和50°C的恒温箱。记录传感器原始换算值和标准温度计读数然后求一次函数的斜率和截距y k*x b。把k和b存储在MCU的Flash预留区或外挂EEPROM里每次读到的原始温度都套用这个公式输出校准后的温度。这个方法的本质是修正传感器个体的系统偏差和PCB焊接带来的应力偏移。要注意的是校准只在特定温度范围内有效超出范围误差会重新变大所以校准时选择的是HVAC应用最关注的工作温度范围两端。另外校准完成后要做一次反向验证把传感器重新放在中间温度点看误差是否收敛如果偏差还很大就要考虑重新焊接或者换一颗传感器。4.4 传感器断线、短路和地址冲突的检测温度传感器在长期运行中迟早会遇到线缆折断、接头老化、短路这些问题控制程序必须能识别出来而不是把错误数据当成真实温度参与控制。最常见的识别方式有三种。第一种是通信层识别发送设备地址之后收不到ACK说明总线上根本不存在这个地址的设备大概率是断线或设备损坏。第二种是数据层识别能读到数据但读回来连续多帧是0xFFFF或者0x0000这类值超出PJ85718DM的物理测温范围可能是SCL或SDA对地短路、对电源短路。第三种是逻辑层识别数据在正常范围内但变化速率异常快比如一秒内跳变超过10°C说明可能有强干扰或传感器接触不良。我在代码里做了一个统一的状态机一个温度节点在正常态、警告态、故障态之间切换连续N次读取异常才切换到故障态并且一旦进入故障态上层控制逻辑采用上一次有效值固定偏差作为安全温度同时上报告警。这个设计比直接报0°C或者报满量程要温和得多至少HVAC系统不会因为一个传感器失效就突然停机或者猛启动。5. 从监测到控制HVAC闭环里的告警逻辑与实测复盘5.1 本机过温保护与远程风道温度控制的阈值逻辑温度监测最终要落到控制逻辑上。这条系统里我实现了两种不同类型的告警和动作。本地过温保护逻辑采用的是电气保护思维当本地温度读到75°C时系统直接关断加热器和压缩机并在LCD和上位机上报控制器过温告警等温度降到60°C以下再允许自动恢复。这中间的15°C就是回差避免温度在阈值附近抖动导致继电器反复通断。回差不是拍脑袋定的而是根据继电器触点的耐受能力和系统热惯性确定的HVAC设备对继电器动作次数是有明确寿命要求的。远程风道温度控制逻辑则是舒适控制思维以风道送风温度为目标值用PID算法调节风机转速和压缩机启动频率。这个回路上远程温度读数的平滑度很关键前面做的滤波处理在这里就发挥了作用。如果直接用带毛刺的温度值做PID执行器会被高频抖动折磨缩短寿命不说房间温度也会忽高忽低。实践下来滤波后的温度值做主PID反馈、原始温度做安全上限判断整体效果最理想。5.2 现场最常见的事故线缆、接头和传感器老化项目从实验室移到现场后总会遇到几个实验室里根本不会出现的问题。我在现场排查中碰到最多的就是远程传感器线缆被机械设备压断、被老鼠咬破绝缘层以及接插件腐蚀氧化导致的接触不良。这类故障最难排查因为温度显示不是完全没反应而是偶尔跳动、偶发无响应。排查这套系统时我先用示波器看远程总线上的波形确认SCL和SDA的边沿是否干净、幅度是否够高。然后是逐段排除法把远程总线拆下来面板一侧短接一个传感器看通信是否恢复恢复后再把远端传感器接回去判断是线缆问题还是传感器节点问题。自从用过一次这个方法后面基本都按这个顺序排查效率高很多。另一个现场体会是接插件的选型和环境防护很重要。HVAC设备常年工作在湿度较大、温差明显的环境里廉价端子用半年就开始氧化。后来我全部换成镀金端子和密封接头再在接插位置涂一层硅胶密封胶故障率直接下降了一个数量级。硬件上这种一劳永逸的投入是值得的。5.3 后续扩展方向与最终体会这套本地与远程温度监测架构的扩展性不错。PIC32MX795F512L的资源还很富余后续如果要加更多测温节点可以在远程总线尾部继续挂新传感器只要在地址配置和轮询数组里加一个地址就行。如果想做更远距离的传感器接入可以考虑把远程节点的I2C信号转成RS-485或者4-20mA变送器信号再通过PIC32的UART或GPIO接收这样传感距离可以从几米扩展到大楼弱电井级别的几百米。按我的实际经验温度监测这类听起来基础的功能想在HVAC这种长期运行、环境恶劣的场景里做到稳定可靠关键不是把模块选得多高级而是把测量对象定义清楚、把通信物理层做扎实、把数据滤波和故障检测做充分。这套方案里没有一项技术是高精尖但每一项都是根据现场痛点逐一打磨过的。如果你也在做类似的嵌入式和HVAC温度监测项目不妨按这个思路走一遍——先分清本地和远程的职责再把I2C物理层和传感器驱动做扎实最后用滤波和故障状态机兜底。能让系统跑得稳的往往就是这些看起来不够刺激、但真正决定设备寿命和用户口碑的细节。