HVAC本地与远程双通道温度监测方案：基于PIC32与PJ85718DM的嵌入式实战

1. 先说结论：这套方案到底做了什么

温度监测放在嵌入式开发里看着只是一个小功能，真正落地的时候一堆坑。最近做的这个项目，要在 HVAC 控制板上同时监测本地温度和远端温度：本地是板载环境温度，远端要用一根细线把探头引到风管、压缩机或电机绕组附近去测。控制核心选了 PIC32MX664F064L，温度前端用了 PJ85718DM，一颗同时支持本地测温通道和远端二极管测温通道的集成测温前端。整块板方案做下来，本地通道负责板上环境温度与散热趋势判断，远端通道负责真正需要关心的热源位置，两路数据汇总后送到主控做控制决策。

为什么值得把这套方案拿出来写：它覆盖了嵌入式开发里最容易被低估的两件事——模拟小信号处理和跨场景系统设计。HVAC 设备和一般嵌入式设备表面上差很远，一个在管风管和水路，一个在管板级功耗和散热，但温度监测的需求是高度重叠的：都要测“本地环境”和“远端热源”，都容易被布线和干扰折磨，都需要校准和告警。把这套用 PJ85718DM 加 PIC32MX664F064L 的方案讲清楚，等于同时解决了两类产品的共性需求。

适合看这篇文章的人：准备做 HVAC 控制器、楼宇自控的硬件和固件工程师，做嵌入式板级热管理的开发者，以及正在选型温度传感器方案的学生和爱好者。文章里不会有太多花哨的东西，基本都是可以直接抄作业的接线、寄存器配置和实测经验。

2. 为什么要“本地+远程”双通道监测

2.1 本地温度：解决“板子自己热了”的问题

先说本地通道。很多人会习惯性地把温度探头全部外置，觉得只要把传感器放到外面去测环境温度就行了，其实这是偷懒。控制器本身是会发热的：继电器线圈、开关管、电源模块、甚至 PIC32MX664F064L 自己在 80MHz 主频下跑起来，板子内部温度和外壳环境温度可以差出好几度。如果只测外部环境，你会漏掉“板子内部已经过热”这个重要信号。

本地通道解决的就是这个问题。PJ85718DM 自身的本地通道测的是芯片附近的板内温度，用来做三件事：判断控制板散热是否正常、给风扇做调速参考、给电源和驱动器件做降额保护。举个例子，HVAC 控制箱里如果风道堵塞或者继电器排布太密，板内温度会先于风管温度出现异常，这时候本地温度就是最早的预警信号。

另外一个容易被忽略的点：本地温度还可以用来做远程通道的参照。远程测温本身已经做了线性化，但如果你把探头放在一个受辐射热影响的位置，本地温度能帮你判断是环境热还是被测对象真热。两路数据交叉验证，远比单一传感器靠谱。

2.2 远程温度：把探头放到真正要测的位置

远程通道是这个方案的重头戏。所谓远程测温，本质上是用一颗外接的二极管结（最常见的是把一颗小信号 PNP 三极管的集电极和基极短接，利用 BE 结）作为温度探头，再通过长线接到 PJ85718DM 的远端输入引脚。前端芯片会往二极管里依次灌两个不同大小的电流，测量两个电流下的正向压降差。

这里的物理原理不复杂：二极管正向压降 Vbe 本身随温度变化，但 Vbe 的绝对值和工艺关系很大，不适合直接当温度信号。而两个电流下的 ΔVbe 满足 ΔVbe = (k·T/q)·ln(N)，其中 k 是玻尔兹曼常数，T 是绝对温度，N 是两个电流的比值。这个表达式的亮点在于，它跟二极管本身的绝对参数几乎无关，只要工艺温漂和串联电阻控制好，就能得到线性度非常好的温度读数。

所以远程通道的价值就很明显了：探头可以很小，就一个三极管封装加两根引线，不需要在远端布置任何有源电路，装进风管探头、绑在压缩机表面、贴在散热器上都行。对 HVAC 场景，比如要到送风口、回风口、冷凝器盘管这些离主控板几米远的位置测温，远程通道是成本最低、干扰最小的方案之一。

2.3 为什么选 PIC32MX664F064L 和 PJ85718DM 这个组合

先说 PIC32MX664F064L。这是一颗 MIPS 内核的 32 位 MCU，主频能到 80MHz，64KB Flash、16KB RAM，片上通信外设比较齐全，UART、SPI、I2C、USB 都有。对 HVAC 控制器来说，它不只是做温度采集，还要跑控制策略、驱动继电器、做 HMI 通信，甚至通过 USB 和上位机联调。温度监测只是它的一部分工作，这颗芯片的余量完全够用。

再说 PJ85718DM。它相当于把“测温传感器、信号调理、ADC、通信接口”集成到了一起。我选它的核心理由是，它内部把远端二极管的电流激励、ΔVbe 测量、ADC 转换、线性化都做好了，输出端直接用 I2C 读寄存器就行。这样 MCU 就不用自己做恒流源和运放，省掉了大量模拟设计和校准工作，也降低了器件离散性带来的误差。

这个组合的分工很清楚：PJ85718DM 负责把物理温度变成数字，PIC32MX664F064L 负责把数字温度变成业务逻辑。模拟部分越少往 MCU 这边放，产品越容易维护，出了问题也越容易定位。

3. 硬件设计要点与接口连接

3.1 系统信号流

整条信号链可以简单描述成：远端 PNP 三极管的 BE 结作为温度探头，D+、D- 两根线回到 PJ85718DM 的远端输入；PJ85718DM 的本地通道直接利用芯片内置传感器，不占外部资源；转换完成后，芯片通过 I2C 总线把温度和状态寄存器暴露给 PIC32MX664F064L；MCU 轮询或接收 ALERT 中断后读取数据，再经过滤波、换算、告警判断，最终通过 UART 或 USB 上报给监控平台或人机界面。

还有一个值得提的细节：PJ85718DM 一般会有一个开漏的 ALERT 引脚，当温度超过阈值或者探头开路、短路的时候拉低。我当时把它接到了 PIC32MX664F064L 的一个带中断功能的 GPIO 上，这样 MCU 不用高频轮询，可以一边睡一边等告警，适合功耗敏感的产品。这个引脚本身是开漏的，需要接上拉电阻。

3.2 远程探头布线：精度都藏在布线上

远程测温对布线的要求比很多人想象中高。线路不好，精度再好的前端也白搭。我把这些年踩过的经验总结成几条硬规矩。

第一，探头到芯片的引线尽量短，如果必须走几百毫米到几米，就用双绞线，并且整段保持对称。ΔVbe 测量依赖两个电流下的压差，任何不对称的串联电阻都会直接叠加进误差。第二，D+、D- 两条走线在 PCB 上要并行走、等长走，不要跨过开关电源的环路，也不要在附近铺大面积的开关节点铜皮。远程通道属于微小模拟信号，被开关噪声耦合进去之后，读数会出现明显的跳动。

第三，如果应用环境电磁干扰比较重，可以考虑在远端输入口加对称的串联电阻和差分电容。注意不能随手加太大，很多测温前端的最大串联电阻和最大线电容在手册里是有限制的，加过头反而会破坏测量。我通常的做法是先不加任何滤波，等 EMC 测试发现问题再加，以实测为准。

第四，探头建议用金属封装的小信号三极管，型号最好是数据手册推荐的或者特性接近的。我自己习惯用 2N3906、MMBT3906 这一类通用小信号 PNP。探头端的三极管基极和集电极短接，等效成一个二极管使用，引线焊点要可靠，热缩管包裹时要让探头尽量贴近被测表面，减少空气间隙。

3.3 电源与 I2C 接口的硬件细节

电源方面，PIC32MX664F064L 和 PJ85718DM 都用 3.3V 供电，整体用一个低噪声 LDO 给模拟前端单独供电会更省心。PJ85718DM 的工作电流不大，但不能和继电器驱动这种大电流负载共用同一路电源的末端，否则每次继电器吸合都会让温度读数抖一下。我习惯在器件电源脚放 100nF 加 1µF 组合去耦，并且让电源线从 LDO 输出端单独拉过来。

I2C 接口需要注意三点。一是上拉电阻，标准模式一般用 4.7kΩ 左右，如果总线速度提到 400kHz 或者挂的设备比较多，可以换成 2.2kΩ，具体要结合总线上电容估算。二是地址，PJ85718DM 这类前端通常有地址配置引脚，通过 A0、A1、A2 的上下拉来设定地址，务必提前规划，避免和板上其他 I2C 设备冲突。三是 ALERT 引脚的上拉，千万别漏了，我见过有人把它当成普通推挽引脚用，结果装上去告警永远不触发。

4. 固件实现：从寄存器到可用的温度值

4.1 初始化流程与关键寄存器

整个固件最核心的部分就是把 PJ85718DM 的寄存器吃透。不同批次的器件寄存器位定义会有差异，下面写的流程和寄存器名称是基于同类远端测温前端的通用实践整理的，具体每一位的含义请以 PJ85718DM 的官方数据手册为准。

我推荐的初始化顺序是：上电后先延时一段时间，等电源稳定和芯片复位完成；然后读设备 ID 寄存器，确认芯片在线，防止总线地址配错或者芯片没起来；接着清一次状态寄存器，把上电时可能残留的故障标志清掉；随后配置转换速率、ADC 分辨率或滤波模式、报警阈值和迟滞、本地和远程的偏移校正值；最后使能 ALERT 中断或告警输出，启动连续转换。

这个流程写成伪代码大概是下面这样：

int init_temp_sensor(void) { uint8_t id; i2c_start(I2C_BUS); if (i2c_read_reg(TEMP_ADDR, REG_ID, &id) != I2C_OK) return -1; // 芯片没有应答，先查供电和地址 if (id != TEMP_EXPECT_ID) return -2; // ID 对不上，核对是不是贴错芯片 i2c_write_reg(TEMP_ADDR, REG_STATUS, 0x00); // 清状态 i2c_write_reg(TEMP_ADDR, REG_CONFIG, 0x08); // 配置速率/分辨率 i2c_write_reg(TEMP_ADDR, REG_THIGH, 0x); i2c_write_reg(TEMP_ADDR, REG_TLOW, 0x); i2c_write_reg(TEMP_ADDR, REG_LOCAL_OFFSET, 0x00); i2c_write_reg(TEMP_ADDR, REG_REMOTE_OFFSET, 0x00); i2c_write_reg(TEMP_ADDR, REG_CONFIG2, 0x01); // 使能告警/连续转换 return 0; }

这里有个容易被忽视的点：偏移校正寄存器的默认值不一定是 0。上电后如果发现读数整体偏差，先去看这两个寄存器里的默认值，再决定要不要写校正值。我看到过有人上来就写偏移，结果把本来正确的数据改坏了。

4.2 读取数据与温度换算公式

温度数据在寄存器里通常是带符号的定点数格式。常见做法是高字节和低字节拼成一个 16 位值，根据分辨率把低字节的若干位丢弃，然后按 LSB 对应的温度值相乘。以 12 位分辨率、LSB 等于 0.0625°C 的常见格式为例，读取和换算代码可以这样写：

float read_remote_temp(void) { uint8_t buf[2]; uint16_t raw; int16_t signed_raw; if (i2c_read_regs(TEMP_ADDR, REG_REMOTE_H, 2, buf) != I2C_OK) return NAN; raw = (uint16_t)((buf[0] << 8) | buf[1]); signed_raw = (int16_t)raw; signed_raw >>= 4; // 去掉低 4 位无效位 return (float)signed_raw * 0.0625f; }

最后这个转换是个典型坑点：必须先把 16 位整合值强转成有符号类型，再做右移，否则无符号数右移会把负数的高位补成 0，读出的温度在零下时就会变成一个巨大的正数。我第一次用无符号数直接移位，-10°C 显示成了 65526，后来排查了很久才发现是符号扩展的问题。

换算完之后，还要把状态寄存器和故障寄存器一并读出来，检查远程探头是否开路、是否短路、数据是否新鲜。真实的工程习惯是绝不无条件相信温度数值，探头发丝一样细的连接线在振动环境里很容易出问题，宁愿报故障也不要用脏数据去跑控制逻辑。

4.3 滤波、告警与数据上报

原始温度数据直接拿去用会很难受，尤其是 HVAC 环境里风机振动、压缩机启停带来的干扰，会让读数在目标值附近来回跳。我常用的组合是“滑动平均加中值去尖峰”：中值滤波窗口取 5 到 7 个点，用来剔除偶发尖峰；滑动平均窗口取 8 到 16 个点，用来平滑趋势。

告警部分要加迟滞和去抖。温度到了 60°C 触发高温告警之后，数据降到 59.9°C 就立刻恢复，会让整个系统在阈值附近振荡。我一般是设置一个 1 到 2°C 的迟滞带，同时在固件里要求连续 3 次采集都越限才真正触发告警，连续 3 次回落到限内才清除告警。这个去抖计数放在 ALERT 中断里做很顺手。

数据上报方面，我建议在 PIC32MX664F064L 上用一个简单但有 CRC 校验的串口帧格式，把本地温度、远程温度、状态标志、固件版本打包成周期报文发出来。如果不方便接串口，也可以用 USB 虚拟串口方式，几乎不占额外硬件，调试验证时特别好用。后面接 Modbus 或者其他总线协议，也只是把帧格式替换掉而已。

5. HVAC 应用落地与校准

5.1 典型部署位置与通道选择

HVAC 系统里温度点很多，但不是每个点都适合用远程通道。我按实际项目经验整理了一个对照表：

选通道的时候不要只看距离。风管里的温度本身波动大，探头要尽量放在气流稳定段，避开回风死角；压缩机表面温度高，探头的固定方式和导热介质，比探头本身的精度更影响结果。这些问题软件改不了，只能在结构和安装上想办法。

5.2 两点校准与误差修正

任何传感器都不能拆开就用，尤其是要过计量或者对温度精度要求严格的项目。我的校准习惯是两点校准：先让探头处于第一个参考温度 T1，记录芯片读数 R1；再让探头处于第二个参考温度 T2，记录读数 R2。然后按线性修正公式 y = a·x + b 计算修正系数，其中 a = (T2 - T1) / (R2 - R1)，b = T1 - a·R1。

参考温度怎么给？实验室里最省事的是冰水混合物，这个点稳定而且廉价，0°C 的标准点很容易复现。第二个点可以用恒温槽或者精度更高的温度计做传递标准，温度选在应用量程中间偏上的位置，比如 40°C 或 60°C。修正系数算出来后，写进 MCU 的 Flash 或者外挂 EEPROM，上电时读出来叠加到换算结果上。

对于远程通道，还有两个额外的误差源要处理：一是探头的理想因子与芯片默认值不一致，如果芯片寄存器支持理想因子修正，就按探头型号调整；二是长引线的串联电阻，带补偿功能的芯片可以直接使用内部补偿，不带的就要在偏移校准里一并消化。我的经验是：先把接线固定，再校准，最后验证，顺序不能乱，否则换一根线缆校准参数就全废了。

5.3 结构件与热响应时间

温度测量还有一项经常被忽略的指标，热响应时间。探头封装得越厚，越耐机械冲击，但热惯性也越大。风管测温追求快速响应，探头就不要在外面包太厚的塑料套；测水温或者压缩机的场合，反而是导热胶和金属套管更重要，响应慢一点没关系，稳定可靠是第一位。

安装位置对读数的干扰也很典型：风管探头如果直接裸露在强辐射源旁边，比如加热段或者太阳直射的管道上，辐射热会让读数虚高。这种情况下要么加防辐射罩，要么让探头尽量靠到气流内壁，减少辐射影响。解决问题的思路不是换传感器，而是先问自己，这个传感器到底在测什么。

6. 实测中踩过的坑

6.1 常见问题速查表

我把这个项目里实际遇到、以及和同行交流时高频出现的问题整理成了速查表，排查问题的时候可以直接对号入座：

6.2 三个最容易被忽略的细节

第一个细节是探头三极管的选型。有些项目图省事，拿大功率三极管甚至 MOS 管的寄生二极管当温度探头，这类器件的理想因子和 Vbe 特性一致性差，测量误差会显著放大。远程测温前端是为小信号二极管优化的，探头老老实实用数据手册推荐的小信号三极管才是正路。

第二个细节是本地和远程通道的故障标志要看全。芯片一般会分别提供本地故障、远程开短路等状态位，我踩过的坑是只看了温度寄存器的有效标志，没看远程通道的开短路标志，结果探头掉了之后固件还在用旧数据。正确做法是每次读取温度后，把状态寄存器一并读回来，发现异常就立即进入故障处理分支。

第三个细节是告警阈值比较的位置。要比较的是换算后的实际温度值，而不是寄存器原始值。尤其是分辨率不同的通道，直接把原始寄存器值和阈值比较会差出好几个 LSB，换算完之后再比较，整个系统的一致性会好非常多。同时阈值和迟滞寄存器里的值，也要用单位温度折算成对应格式写入，别把格式搞混。

6.3 我的排查流程建议

遇到温度读数不对，我通常按下面这个顺序排查，基本能筛掉九成的问题。先用 I2C 扫描确认设备和地址正常，再读一遍 ID 寄存器和配置寄存器，确保芯片被正确初始化；然后用万用表或者示波器量 D+、D- 的直流电平，正常情况下应该能测到二极管压降量级的电压，开路和短路会明显异常；接着对比本地和远程两路读数，如果两路同时偏，大概率是偏移寄存器或者校准参数的问题，如果只有远程偏，大概率是探头、引线或者理想因子的问题；最后把原始寄存器值通过串口打出来，跟在线的温度曲线比对，看是稳定偏差还是间歇跳变，稳定偏差走校准流程，间歇跳变走布线和滤波排查。

这个排查顺序不依赖复杂仪器，一个万用表、一个逻辑分析仪足够。关键是每一步都要留下打印记录，否则改了一堆参数之后，根本不知道是哪一步起了作用。

7. 最后的一点体会

这个项目做完之后，我最大的体会是：温度监测系统的瓶颈很少在芯片本身，而在于你有没有把模拟前端、探头安装、固件处理和结构设计当成一个整体来对待。PJ85718DM 和 PIC32MX664F064L 这套组合之所以好用，是因为分工明确、接口标准、验证路径清晰，但只要探头焊点松了、引线被干扰了、校准顺序乱了，再好的芯片也一样给出错误数据。

最后再分享一个小技巧：固件里一定要留一个“临时偏移量”的注册入口，通过串口命令就能在线调整，不需要重新烧录程序。现场调试 HVAC 设备的时候，你大概率会需要对着实际工况微调温度偏差，有这个入口会省掉大量来回烧写的折腾。温度监测这件事，硬件决定了精度的上限，软件和管理手段决定了你能不能稳定地拿到这个上限。