做 HVAC 自控和嵌入式设备测温时，最常遇到的一个问题是：一个系统里往往要同时盯好几个点。比如空调机组的送风口温度、回风口温度，还有控制板所在的电气腔温度。过去我习惯每个点放一颗独立温度传感器，后来在某个设备监控项目里换成了 PJ85718DM 配合 STM32F429ZI 的方案，才意识到一枚芯片兼顾本地和远程测温能省掉多少事。这篇文章就把这套方案的硬件连接、驱动写法、误差校准以及 HVAC 联动里的工程经验完整聊一遍，适合正在做温度采集、空调控制或嵌入式监控项目的朋友参考。
PJ85718DM 这类带远程测温通道的芯片，和普通单点传感器最大的区别在于：它内部自带一个本地测温单元，同时还能外接一颗二极管来测远端温度点。这意味着你在采集控制板自身温度的同时，可以把另一路探头拉到几十厘米甚至更远的地方，比如风管内部、机柜深处、功率器件散热器上。配合 STM32F429ZI 的多个 I2C 外设和足够强的处理能力，整套方案无论是结构、成本还是后期维护，都比单点传感器堆叠要干净许多。
1. 为什么 HVAC 和嵌入式系统需要“本地 + 远程”双点温度监测
1.1 单点测温照顾不到的场合
先说 HVAC 侧。空调箱、新风机组、风机盘管这类设备，温度测点通常不止一个：送风温度、回风温度、混风段温度、盘管进出口温度，有些还要求监测电气控制柜内部温度。送风温度在风管内，回风温度在回风口的格栅附近，控制板温度在电控盒里，这些位置之间的距离少则三四十厘米，多则一两米。如果每个测点都单独放一颗数字温度传感器，不仅要额外准备传感器供电、I2C 地址分配、总线负载管理，接线数量也会成倍增加。设备一旦批量生产，线束成本和装配时间都是实打实的负担。
嵌入式侧也有类似痛点。功率 MOSFET、IGBT、电机驱动模块这类器件的热特性直接关系到系统可靠性，但很多器件内部并不集成数字温度传感器，不适合直接在发热点安装大体积探头。工程上常用的做法是把一颗二极管紧贴在散热器或功率器件外壳上，利用二极管正向压降和温度的线性关系来间接测量结温和壳温。这个测量点距离主控板通常有一段线距，如果主控板上已经有一颗支持远程测温的温度芯片，就可以把这颗二极管直接挂在芯片的远程通道上，省去一个独立采集模块。
1.2 PJ85718DM 和 STM32F429ZI 的搭配思路
我一开始看到 PJ85718DM 这颗芯片，是被它的双通道结构吸引的：本地通道负责测 MCU 附近的环境温度，远程通道通过两颗引脚接外部二极管，测远端热点的温度。两个通道共享同一个转换器和校准参数，数据一致性比两颗独立传感器更好，也不存在两套 I2C 地址、两套滤波配置互相打架的问题。
STM32F429ZI 在这个系统里的角色是主控。它是一颗 Cortex-M4F 内核、主频可以到 180MHz 的芯片，用来读个温度传感器完全是杀鸡用牛刀，但如果整个设备除了测温还要跑风机控制、继电器逻辑、Modbus 上报、按键显示，这颗芯片的资源就刚刚好。我选它的另一个原因是它的 I2C 外设足够多，且引脚映射灵活，可以在不牺牲调试串口的前提下把传感器总线独立出来。硬件瑞萨、ST 的生态很成熟，CubeMX 初始化、HAL 库调用都省事，适合快速出原型。
2. 围绕 PJ85718DM 的硬件接线与抗干扰细节
2.1 引脚与最小系统
入手这块芯片后，第一步是照数据手册搭最小系统。以我用的封装为例，核心引脚就几个：VDD、GND、SDA、SCL、远程通道的正负端 DXP/DXN，另外还有地址选择引脚 A0/A1，以及一个可选的报警输出引脚 ALERT。电源部分我用了 100nF 陶瓷电容加 10µF 钽电容并联去耦，电容尽量靠近 VDD 引脚。很多温度传感器对电源纹波并不太敏感，但 HVAC 设备里常有风机、压缩机这类感性负载，电源线上容易窜入尖峰，去耦电容不能省。
地址选择引脚按数据手册设定。PJ85718DM 的 I2C 7 位地址可以通过 A0、A1 的组合在几个地址之间切换，默认悬空时是 0x48。我的系统里只挂了一颗这样的芯片，就全部接地，直接用默认地址，省得之后软件里还要根据硬件跳线做地址映射。如果一台主控要挂多颗，比如每个风管区域一个传感器节点，那就需要通过这两个引脚把地址区分开，I2C 总线上最多可以挂几颗这样的芯片。
2.2 与 STM32F429ZI 的 I2C 连接
STM32F429ZI 的 I2C1 我映射到了 PB6（SCL）和 PB7（SDA），这是 F4 系列最常用的复用功能位置。在 CubeMX 里把这两个引脚选为 I2C1_SCL 和 I2C1_SDA，外设速率设成 400kHz，开漏输出模式，硬件上不需要再配额外的电平转换电路，传感器和 MCU 都是 3.3V 供电。串在 SDA 和 SCL 上的两个 4.7kΩ 上拉电阻是必须的，I2C 协议本身是开漏结构，没有上拉电阻总线根本拉不高。电阻值我试过 2.2kΩ 和 4.7kΩ，400kHz 下影响不大；总线长度短时 4.7kΩ 更省功耗，长度长时 2.2kΩ 的上升沿更好看。
接线表大致是这样：
| PJ85718DM 引脚 | 连接目标 | 说明 |
|---|---|---|
| VDD | 3.3V | 经 100nF + 10µF 去耦 |
| GND | 系统地 | 尽量单点接地 |
| SDA | STM32 PB7 | 接 4.7kΩ 上拉至 3.3V |
| SCL | STM32 PB6 | 接 4.7kΩ 上拉至 3.3V |
| DXP | 外部二极管阳极 | 双绞线引出 |
| DXN | 外部二极管阴极 | 双绞线引出 |
| A0 / A1 | GND | 选用默认地址 |
| ALERT | 可接 STM32 外部中断引脚 | 不高频使用可以先悬空 |
2.3 远程探头的长线处理
远程测温通道最容易出问题的地方是长线。传感器芯片测量远端二极管是利用不同偏置电流下的 ΔVBE 差来推算温度，线缆自身电阻会叠加到这个差分信号上。线越长、线径越细，额外串入的电阻越大，测温结果会明显偏离真实值。我在一个模拟项目里试过用普通杜邦线拉出来 50cm，读数比实际温度偏高约 0.6℃ 左右，后来改成双绞线并且尽量缩短到 30cm 以内，误差就回到了可接受范围。
如果探头线不得不拉得比较长，有几个工程上的补救措施。一是把远程二极管区域做好屏蔽，屏蔽层单端接地；二是避免与风机供电线、继电器控制线走同一桥架，高频干扰会耦合进来；三是在软件里做滤波和偏差补偿，这个问题后面单独讲。另外要注意 DXP 和 DXN 不能接反，二极管的极性搞反了，芯片读到的电压会完全不对，温度读数会非常离谱。
3. 从寄存器到摄氏度：I2C 驱动与数据换算
3.1 I2C 初始化和寄存器读取
在 STM32F429ZI 上，我用 CubeMX 生成基础工程后，只需要在 I2C 初始化完成后调用 HAL 库的 Mem_Read 接口就能读到传感器寄存器。PJ85718DM 的寄存器地址映射按简化逻辑来记：本地温度寄存器，远程温度寄存器，配置寄存器，状态寄存器。读温度时一次读两个字节，高字节在前。
寄存器读取函数参考：
#include "i2c.h" #define PJ85718DM_ADDR 0x48 #define PJ85718DM_REG_LOCAL 0x00 #define PJ85718DM_REG_REMOTE 0x01 #define PJ85718DM_REG_CFG 0x02 #define PJ85718DM_REG_STAT 0x03 static int16_t pj85718dm_read_reg(I2C_HandleTypeDef *hi2c, uint8_t reg) { uint8_t buf[2] = {0}; // 注意 HAL 库的地址要左移一位，7 位地址变成 8 位传输地址 if (HAL_I2C_Mem_Read(hi2c, PJ85718DM_ADDR << 1, reg, I2C_MEMADD_SIZE_8BIT, buf, 2, 100) != HAL_OK) { return 0x7FFF; // 返回一个明确错误标志 } return (int16_t)((buf[0] << 8) | buf[1]); }这里特别提醒，HAL 库的 I2C 地址参数是 8 位传输地址，也就是 7 位地址左移一位后的值，千万别把 0x48 直接填进去。我第一次调试时就是忘了左移，结果总线一直 NACK，浪费了不少时间。
3.2 符号扩展和分辨率换算
PJ85718DM 的本地和远程温度寄存器都以 16 位格式存放。如果我在配置寄存器里把分辨率设为 12 位，那有效数据在高 12 位，低 4 位读取后直接丢弃。温度是有正有负的，比如零下温度时寄存器值用二进制补码表示，如果直接把高字节左移再拼低字节当成无符号数，那 0xFB 这样的负数会被当成 251 处理，之后无论怎么乘系数都得不到正确温度。因此必须先做符号扩展，把原始 12 位补码转成有符号整数。
换算代码：
float pj85718dm_read_temp(I2C_HandleTypeDef *hi2c, uint8_t remote) { int16_t raw = pj85718dm_read_reg(hi2c, remote ? PJ85718DM_REG_REMOTE : PJ85718DM_REG_LOCAL); if (raw == 0x7FFF) return -273.0f; // 错误标志，返回一个明显非法的温度值 raw >>= 4; // 丢弃低 4 位无效位，保留带符号的 12 位数据 float temp = (float)raw * 0.0625f; // 12 位分辨率，LSB 为 0.0625°C return temp; }0.0625 这个系数怎么来的？12 位温度传感器的典型量程是 -40℃ 到 +125℃，对应数字量程是 -2048 到 +2047，温度范围跨度 165℃，数字量跨度 4096，每一步对应的物理温度就是约 165/4096 ≈ 0.04，实际芯片手册会根据设计定成 0.0625°C/LSB，这是二进制小数里比较规整的一个值。我在驱动里把这个系数换成浮点乘，代码可读性好，但要注意 STM32F429ZI 带 FPU，浮点计算几乎不耗时，不用为了省周期改成定点。
3.3 采样策略：轮询、定时器与 DMA
温度信号本身变化很慢，每秒采样一到两次就足够了，完全不需要像采集音频一样用高速 DMA。我在系统里用了一个基础的定时器中断，每 500ms 触发一次，在中断回调中把温度读取请求挂到一个标志位，主循环检测到标志后再执行 I2C 读取和数据换算。这样做的原因是避免在主循环里用 HAL_I2C_Mem_Read 的阻塞式调用卡住其他逻辑，比如风扇转速控制、按键扫描、通信报文处理。
也可以用 DMA 方式启动 I2C 读取，温度传感器一次只读两个字节，DMA 的中断开销和普通中断读取差不多，反而增加了代码复杂度。如果想要省电，可以让芯片进入单次转换模式，读完后立刻进入低功耗状态；如果系统在充电桩或者车载设备这种持续供电场景，保持连续转换模式即可，电流消耗很小。
4. 误差解剖与现场校准方法
4.1 误差来源和量级
刚接触这套方案时，我一直以为温度传感器的读数就可以直接信任，实际测下来发现误差源远比我预想的多。首先是器件本体误差，PJ85718DM 这类芯片手册上会写本地通道典型精度在 ±0.5℃ 左右，远程通道若配合标准二极管，精度在 ±1℃ 左右，这是芯片内部基准和测量电路决定的，无法通过外部接线消除。其次是远程探头的引线电阻误差，前面提到，长线引入的额外电阻会被当成二极管的一部分，导致读数系统性正向偏移。第三是探头二极管本身的质量差异，工业级二极管的温度特性曲线与芯片内部预设的系数不可能完全匹配，不同批次之间差异能到零点几度。
我整理了一个误差来源对照表，方便实际项目里排查问题：
| 误差来源 | 典型量级 | 对策 |
|---|---|---|
| 芯片本地通道测量误差 | ±0.5℃ | 通过软件校准修正 |
| 芯片远程通道测量误差 | ±1℃ | 选用匹配的标准二极管 |
| 远程引线电阻 | 每 10Ω 可能引入 0.5℃ 到 1℃ | 双绞线、短线、软件补偿 |
| 二极管批次差异 | 0.2℃ 到 0.5℃ | 同一货源、批次校验 |
| 电磁干扰耦合 | 表现为读数跳动 | 屏蔽、远离动力线、滤波 |
4.2 两点校准和偏移处理
工程上我不追求把传感器校到实验室级别，只要求在设备运行的典型温度范围内误差可控。最实用的方法是两点校准。假设系统实际工作范围是 10℃ 到 50℃，就在这个区间选两个温度点，比如用恒温槽或者精密温度计作为参考。先让传感器稳定在温度点 A，记录芯片读数和参考温度的偏差 offset1；再稳定在温度点 B，记录 offset2。因为温度传感器的输出基本呈线性，两个点就能拟合出“真实温度 = 芯片读数 × gain + offset”的模型。
代码如下：
typedef struct { float ref1; // 校准点 1 参考温度 float raw1; // 校准点 1 芯片读数 float ref2; // 校准点 2 参考温度 float raw2; // 校准点 2 芯片读数 } cal_point_t; float temp_calibrated(float raw_temp, cal_point_t *cal) { float gain = (cal->ref2 - cal->ref1) / (cal->raw2 - cal->raw1); float offset = cal->ref1 - raw_temp_placeholder; // 示意，实际按公式计算 ... }实际写的时候要注意，如果 raw2 和 raw1 非常接近，说明两个校准点选得太近，gain 会异常放大，这时候反而会把小噪声放大。理论上校准点尽量覆盖整个量程两端，但 HVAC 现场很难找到 0℃ 以下的恒温环境，所以在实际工作区间内选两点就够用了。
4.3 用 STM32 做自动校准
如果设备批量生产，手动校准一台台调不现实。我的经验是把校准流程做成一个“校准模式”：设备上电后按住某个按键进入校准状态，用调试串口或上位机传来参考温度值，STM32 侧的代码自动记录当前传感器读数，在收到第二个参考温度后自动算出 gain 和 offset，并把结果写入片内 Flash 的专用扇区。下次开机时，驱动初始化会先读取 Flash 里的校准参数，如果参数有效就应用，无效则按默认 1 倍增益、0 偏移处理。
这样做的核心好处是把“校准”从研发环节挪到了生产测试环节，产线上只要有一个稳定温度源，操作员通过串口助手发两个温度值就能完成一台设备的校准，效率和一致性比我最初想象的强很多。要注意写入 Flash 前必须对校准数据进行校验，比如存储一个简单的 CRC 或者两次复制校验，防止数据写了一半导致设备上电后计算出荒谬的增益值。
5. HVAC 联动的工程落地细节
5.1 采样滤波：去野值 + 移动平均
HVAC 环境里温度读数的噪声主要来自风机启停、变频器干扰和长线电磁耦合。我在系统里做了两级滤波，第一级是滑动窗口去野值，第二级是移动平均。去野值的基本逻辑是：如果某一次采样值比前一次正常值跳变超过 2℃，就先不采用这个值，而是连续多读几次，如果连续三次都跳变，才认为温度真的变了。这样做能有效滤掉转速变化瞬间产生的干扰尖峰。
移动平均窗口我取了 8 次，也就是大约 4 秒的滤波时间。窗口太小滤不干净，窗口太大则控制响应变慢，比如 16 次时风机启停的温度滞后很明显，会让控制系统误判断温度根本没有变化。代码上用一个环形缓冲区，每来一个新采样值就覆盖最旧的一个，实时计算平均值。浮点加法在 STM32F4 上很快，每秒才执行两次，完全不用担心性能。
5.2 滞回控制的阈值逻辑
HVAC 最常见的就是温度控制，但直接用单一阈值会导致继电器频繁吸合释放。比如设定 50℃ 启动风机，温度到 50.1℃ 风机启动，风一吹温度掉到 49.9℃，风机又停，然后温度又回升，如此反复。继电器一秒钟动作好几次，不是烧触点就是吵得客户退货。解决办法是用滞回比较：启动阈值和停止阈值之间留 2℃ 左右的死区。
滞回控制示意：
#define FAN_ON_TEMP 50.0f #define FAN_HYST 2.0f #define FAN_OFF_TEMP (FAN_ON_TEMP - FAN_HYST) static uint8_t fan_state = 0; void hvac_control_loop(float temp_local, float temp_remote) { float t = (temp_local > temp_remote) ? temp_local : temp_remote; if (!fan_state && (t >= FAN_ON_TEMP)) { fan_state = 1; HAL_GPIO_WritePin(FAN_CTRL_GPIO_Port, FAN_CTRL_Pin, GPIO_PIN_SET); } else if (fan_state && (t <= FAN_OFF_TEMP)) { fan_state = 0; HAL_GPIO_WritePin(FAN_CTRL_GPIO_Port, FAN_CTRL_Pin, GPIO_PIN_RESET); } }这个逻辑的关键在于比较对象选本地还是远程温度，要看实际控制对象。如果是控制风机的温度，就要看风管内的远端温度；如果是保护控制板，那就要看本地温度。别把两个温度平均起来用，同一个系统里两个点的优先级往往不一样。
5.3 故障自检：传感器开路与断线
远程探头长期暴露在风管或设备外部，端子松动、线缆断裂是迟早的事。PJ85718DM 这类芯片一般会有远程通道开路或者短路检测状态位，驱动里要主动读取状态寄存器，一旦发现异常，就不能让设备傻乎乎地按错误温度执行控制逻辑。我在程序里做了一个故障熔断机制：如果连续 10 次读取都失败，或者连续 10 秒检测到远程通道异常，就把远程温度标记为无效，并让控制逻辑自动回退到“只依据本地温度”或者“默认安全状态”。
默认安全状态很重要，比如冷却风机在温度异常时应该强制开启而不是关闭，否则功率器件可能直接热击穿。而加热器控制逻辑中温度异常时则应强制关闭加热，避免热量持续累积。这个“失效保护方向”必须在需求阶段就确定，不能在代码里临场加，否则方向反了经常出大事。
6. 实测过程里遇到的几个典型坑
6.1 I2C 总线读回 0xFF 和 ACK 异常
第一次往 STM32F429ZI 上接 PJ85718DM 时，我遇到的最诡异问题是 SCL、SDA 明明连线没问题，用示波器看波形也算正常，但 HAL_I2C_Mem_Read 一直超时。排查了很久才发现是 CubeMX 默认把 PB6、PB7 配置成了普通 GPIO，而我手动重映射后工程里的复用功能配置没同步刷新，导致输出模式不对。重新生成代码后就好了。如果你也遇到这种问题，优先检查引脚复用功能是否生效，而不是怀疑芯片坏了。
另一个常见情况是 SDA 上拉了，SCL 没上拉，这时候读出来的数据不是 0xFF 就是随机值。I2C 总线上 SCL 和 SDA 都要有上拉电阻，只在 SDA 上上拉是新手常犯的错。总线挂多颗设备时，每个设备上的上拉电阻不会叠加，只要在总线上最远端放一组合适的电阻即可，不要每个设备都加，否则下拉能力不足，时序会飘。
6.2 远程通道接错极性的教训
我有一回把远程二极管接到 DXP/DXN 上，温度读数比真实值高了 15℃ 以上而且非常不稳定。检查了很久，才发现自己把二极管的极性接反了。远程通道对极性极其敏感，接反后芯片测量到的不是标准 ΔVBE，而是反偏漏电流相关的东西，完全无参考意义。这里提醒两点：一是二极管的阳极必须接 DXP，阴极接 DXN，我后来在 PCB 上直接丝印标注了正极方向和安装方向，避免产线装配时看错；二是连接探头前最好用万用表二极管档确认一下管脚极性，特别是手工焊接的传感器探头，很容易拿反。
还有一次是选用的二极管封装太小，焊接时间太长导致二极管内部特性漂移，温度读数怎么校都对不齐。后来我改成带有较长引线的二极管，焊接时用镊子夹住管脚帮助散热，问题才解决。这类看似小事的细节，在批量生产中会造成大量售后投诉。
6.3 布线导致的温度跳变
最后一个坑来自系统集成测试时，我把远程探头线和 220V 风机供电线绑在了同一个线槽里。只要风机一启动，远程温度读数就会跳变 1℃ 到 2℃，风机停转后读数又恢复正常。这个现象非常典型，本质是电磁耦合窜入了差分信号线。解决办法是三方面同时做：把探头线移出动力线槽，至少保持 10cm 以上间距；探头线改用双绞屏蔽线，屏蔽层在传感器远端单点接地；软件里把去野值滤波阈值收紧。三者都做完后，温度曲线肉眼可见地稳定了，实测风机启动瞬间的最大跳变从 1.5℃ 降到了 0.1℃ 以内。
我后来在类似项目上的经验是，PCBA 打样阶段就预留出 DXP/DXN 的滤波电容位置，虽然芯片手册不一定强制要求，但如果现场干扰严重，加一个小容值电容在差分引脚之间能显著抑制噪声。这个元件成本几乎为零，却能让现场调试省下大量时间。硬件上的余量和软件上的滤波一样，都属于花小钱办大事的工程习惯。
