我最早接手这个需求的时候，其实不太理解为什么要用一颗带“远程测温”功能的芯片来做 HVAC 控制器。NTC 热敏电阻又便宜又常见，用主控的 ADC 采一下不就行了？后来把板子放进老化箱，把测温点拉到压缩机外壳、蒸发器翅片和风道出口，才发现远程二极管测温这条路在嵌入式测温里几乎不可替代。尤其当你手头有 STM32F407ZG 这种资源富余的主控，配上一颗 PJ85718DM 这样的本地/远程双通道温度传感器，整个测温链路的精度、响应速度和校准成本都会明显不一样。
这篇内容适合两类人：一类是做暖通空调、变频器、压缩机保护板、冷库控制器的嵌入式工程师，另一类是从裸机、Arduino 转向工业级测温方案的新手。我会把硬件搭接、固件读写、误差排查和 HVAC 控制逻辑串起来讲，尽量做到看完就能照着搭一套能跑的原型。
1. 项目背景：HVAC 现场为什么同时要“本地温度”和“远程温度”
1.1 先分清本地通道和远程通道到底测什么
“本地温度”听着像废话，其实就是指温度传感器芯片自己所在位置的温度。在 HVAC 控制板上，这个位置通常是主控周围、功率驱动管附近、开关电源的 PCB 区域。它反映的是控制板本身的发热状况，防止板级过热、电容老化、驱动管温升异常。
“远程温度”则是通过一对细线，把测温点放到离主控几十厘米甚至几米远的地方。HVAC 系统里典型的远程测点包括压缩机壳体、冷凝器盘管、蒸发器出口、风道回风口、水系统管路表面。这些点离主控远，走线环境往往还很恶劣，有压缩机启停的电磁干扰、有高频开关电源的辐射、有冷凝水和高温。
如果用 NTC，每一个测点都要单独拉两根线回 ADC，还要在板上放分压电阻，每一路都要做查表线性化，不同批次的 NTC 阻值误差还会引入额外偏差。而 PJ85718DM 这种双通道芯片，本地通道就是片内测温，远程通道只需要外接一颗二极管接法的三极管，通过 I2C 一条总线就把两个温度点全部读回来。这在多测点、长走线、强干扰的 HVAC 场景里非常实用。
1.2 远程二极管测温的原理，三句话讲完
二极管的正向压降 VF 随温度变化，温度每升高 1°C，VF 大约下降 2mV。芯片给外接二极管施加固定的激励电流，测量二极管的 VF 变化，再经过内部 ADC 和计算，就能得到远端温度。
不过只测 VF 会受激励电流、走线电阻、器件离散性的影响。稍微讲究一点的芯片会用“改变电流大小测量 ΔVBE”的方式消除走线电阻和绝对 VF 偏差，这也是远程二极管测温能做到 ±1°C 级别精度的关键。所以我们在硬件上把 D+、D- 这对线拉得远一点，只要接法对、噪声控制好，读数依然可信，这是 NTC 方案很难复制的优势。
1.3 为什么选 STM32F407ZG 当主控
STM32F407ZG 在 HVAC 控制器里很常见，Cortex-M4 内核、主频可以跑到 168MHz，带有多个 I2C、UART、CAN、ADC、高级定时器，还有充足的内存和 Flash。一块板子往往既要跑温度采集，又要跑 PWM 驱动、通信协议和人机交互。温度监测只是它众多任务里的一环，但 I2C 资源、中断能力、调试手段都要够成熟，这颗芯片在这些方面都经得起抠细节。而且从固件开发的角度，用它的 HAL 库把 I2C 从机读写串起来，代码量并不大，后面维护也方便。
2. 硬件搭接：I2C 引脚、上拉电阻与远程二极管走线的细节
2.1 核心连接拓扑，先看一张示意图
我实际搭的原型连接方式很简单，如果你手里有现成的 STM32F407 开发板，完全可以照这个接法验证。
+3.3V | [4.7k] [4.7k] | | PB6 (I2C1_SCL) <----> SCL ---- PJ85718DM PB7 (I2C1_SDA) <----> SDA ---- PJ85718DM GND ---- GND ALERT ---- PB4/任意EXTI引脚(可选) D+ ---- 二极管接法三极管的基极/集电极 D- ---- 三极管的发射极- I2C1 的 SCL 是 PB6，SDA 是 PB7，这个映射是 STM32F407 系列上的默认复用，Cortex-M4 的引脚配置里非常常用。
- PJ85718DM 的 I2C 地址由地址引脚或固定值决定，写代码前务必确认 7 位地址，HAL 库里面要传的是左移一位后的 8 位地址，这一步是新手最容易看错的地方。
- 上拉电阻我默认放 4.7kΩ，适用于板内短走线、400kHz 快速模式。如果传感器离主控很远，总线电容变大，就要降到 2.2kΩ 甚至 1kΩ，或者退回 100kHz 标准模式，否则波形边沿会变差导致通信偶发失败。
- 芯片供电、I2C 上拉都统一用 3.3V，不要和功率部分的 5V 或 12V 混在一起。
- 在芯片电源引脚旁边放一颗 100nF 的陶瓷电容，最好再并一颗 4.7µF 的电解电容，尤其在远程通道要精读的场景下，电源纹波会影响内部 ADC 的参考。
2.2 远程二极管端，最容易翻车的地方
远程端其实就是一个二极管，但工程上更推荐“二极管接法”的三极管，把集电极和基极短接在一起，当作 PN 结来用。三极管比普通二极管的一致性更好，温度特性也更接近芯片厂商标定时的参考器件。具体型号以 PJ85718DM 手册推荐的清单为准，常见的 NPN 小功率三极管一般都能用。
接法上有一点必须反复检查：D+ 接短接后的基极/集电极，D- 接发射极，接反了读出来的温度会完全乱掉。曾经我在一块样机上调了半个小时，最后拿万用表一量才发现设计文件里 D+、D- 丝印画反了。这类错误不烧芯片，但会让人怀疑固件有问题，排查链路非常烧时间。
走线方面：
- 远程通道的两根线尽量贴着走，做成一对平行线，不要中间穿隔一层地铜箔，那样会破坏电流回路，反而更容易引入共模干扰。
- 走线长度控制在 1 米以内，穿屏蔽线的话，屏蔽层单端接地，不要两端都接。
- 如果这颗芯片支持“走线电阻补偿”或者叫 series resistance cancellation，就把对应位打开；如果不支持，就要实测线阻，把它从温度误差里校准掉。这种误差是固定偏移，远程温度越高越明显，非常像“参考点标定不准”，稍不注意会被误导成传感器型号问题。
- 在远程端 D+/D- 之间并联 100pF 左右的滤波电容可以滤掉高频噪声，但电容不能太大，太大反而会让激励电流建立时间变长、读数偏慢。经验值是 100pF 到 1nF，先小后大。
2.3 PCB 布局与 EMC 的几条硬建议
HVAC 板子上最不缺的就是干扰源：继电器、接触器、压缩机的感性负载、PWM 变频驱动、开关电源。温度采集虽然不算高速电路，但远程通道的激励电流很小，噪声一不小心就会直接进 ADC。
优先把 PJ85718DM 放在远离功率开关管和电感的位置，I2C 的两根上拉电阻放在主控一侧，SDA/SCL 串联 33Ω 到 100Ω 的电阻可以稍微抑制振铃。远程 D+/D- 走线不要贴着 PWM 输出线和继电器控制线，更不要跨过它们。如果实在避不开，宁可绕远路，也要把感温线的“清净区”保住。
另外，I2C 总线不要超过 3到4 个设备。PJ85718DM 本身地址占用一个，加上别的传感器、EEPROM、RTC 以后，总线电容和地址冲突的风险都会上升。HVAC 板子上如果纯粹为了多路温度就往 I2C 上挂一堆传感器，往往不如用一颗多通道芯片划算，这也是我后来选定本地/远程双通道方案的原因之一。
3. 固件链路：从 STM32F407ZG 的 I2C 初始化到温度数值计算
3.1 CubeMX 初始化 I2C1，速度选 400kHz 之前先想想
在 STM32CubeMX 里配置 I2C1，使能 PB6/PB7 的复用功能，模式选 I2C，速度先选 100kHz 或 400kHz。第一次调试我建议用 100kHz 起步，原因很简单：远程走线、接插件、手焊板子都可能给总线带来意外电容，400kHz 在示波器上可能非常漂亮，但给用户现场长长的线缆之后，边沿变缓就是通信随机失败的温床。先把功能跑通，再根据实际波形慢慢提速度。
初始化代码大致是这个样子，HAL 库会自动补齐时钟使能和引脚复用配置：
I2C_HandleTypeDef hi2c1; void MX_I2C1_Init(void) { hi2c1.Instance = I2C1; hi2c1.Init.ClockSpeed = 400000; hi2c1.Init.DutyCycle = I2C_DUTYCYCLE_2; hi2c1.Init.OwnAddress1 = 0; hi2c1.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT; hi2c1.Init.DualAddressMode = I2C_DUALADDRESS_DISABLE; hi2c1.Init.OwnAddress2 = 0; hi2c1.Init.GeneralCallMode = I2C_GENERALCALL_DISABLE; hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_DISABLE; if (HAL_I2C_Init(&hi2c1) != HAL_OK) { Error_Handler(); } }实际项目里我建议把温度采集放进一个独立的任务或定时器中断，不要在 I2C 读取时长时间关中断。STM32F407ZG 在 168MHz 下跑这套逻辑完全有余量，但 HAL 的 I2C 阻塞式读写会等总线释放，放在中断里容易把其他实时任务堵死。优先级不要给太高，除非你的 ALERT 中断需要非常迅速地保护压缩机。
3.2 寄存器映射与配置流程，务必以手册为准
远程二极管温度芯片的寄存器布局，不同厂家、不同批次会有差异。我下面给出的是这类芯片很典型的映射，也是我在这颗料上实际用的布局，但你在正式干活前一定要把数据手册下载下来核对，尤其是地址位宽、字节序和保留位。
这里给出一个常见映射，作为工程参考：
| 寄存器功能 | 寄存器地址 | 说明 |
|---|---|---|
| 本地温度数据 | 0x00~0x01 | 16位读数，高字节在前，12位数据左对齐或右对齐（以手册为准） |
| 远程温度数据 | 0x02~0x03 | 同上，对应远程通道 |
| 配置寄存器 | 0x04 | 转换模式、转换速率、ALERT 极性等 |
| 状态寄存器 | 0x05 | 温度数据就绪标志、ALERT 状态标志 |
| 远程上限阈值 | 0x06~0x07 | 远程通道高温告警阈值 |
| 远程下限阈值 | 0x08~0x09 | 远程通道低温告警阈值 |
| 本地上限阈值 | 0x0A~0x0B | 本地通道高温告警阈值 |
| 本地下限阈值 | 0x0C~0x0D | 本地通道低温告警阈值 |
注意：如果手册里写的 16 位数据是“左对齐”的，也就是低 4 位恒为 0，那右移处理要看原始位数。如果是右对齐，只要把无用的低位丢弃就行。别小看这一步，错一位数据，温度就会差 0.5°C 到 1°C，而且方向还是固定的，特别隐蔽。
3.3 读取两路温度并换算成摄氏度
先把读写函数写扎实。用 HAL 的HAL_I2C_Mem_Read可以直接指定从机地址、寄存器地址和长度，干净利落：
#define PJ85718DM_ADDR7 0x4E // 假设7位地址是0x4E，实际以手册/硬件为准 #define PJ85718DM_ADDR (PJ85718DM_ADDR7 << 1) // HAL 需要8位地址 static int16_t pj85718dm_read_temp(uint8_t reg_high) { uint8_t buf[2] = {0}; HAL_StatusTypeDef st; // reg_high 是高字节寄存器地址，连续读两个字节 st = HAL_I2C_Mem_Read(&hi2c1, PJ85718DM_ADDR, reg_high, I2C_MEMADD_SIZE_8BIT, buf, 2, 100); if (st != HAL_OK) { return 0x7FFF; // 读失败给一个明显异常值 } int16_t raw = (int16_t)((buf[0] << 8) | buf[1]); return raw; } float pj85718dm_get_local_celsius(void) { int16_t raw = pj85718dm_read_temp(0x00); if (raw == 0x7FFF) return NAN; // 假设12位右对齐，去掉低4位；保留符号做补码换算 raw >>= 4; return raw * 0.0625f; } float pj85718dm_get_remote_celsius(void) { int16_t raw = pj85718dm_read_temp(0x02); if (raw == 0x7FFF) return NAN; raw >>= 4; return raw * 0.0625f; }这里的 0.0625°C/LSB 是常见的 12 位分辨率，如果你手册里写的是 11 位或者 13 位，把右移位数和系数改成对应值就行。负数温度的换算完全交给有符号整型处理，raw声明成int16_t之后右移保留符号位，补码转十进制这一步 C 语言已经替我们做完了，再乘系数就是正确的负温度。
读完数据后最好检查一下状态寄存器里的数据就绪标志，尤其是低功耗采样模式下，如果没有等到一次完整转换完成就读数，可能拿到的是上一次的旧值。对于 HVAC 这种温度变化很慢的系统，偶尔读旧值问题不大，但如果你后面要跑保护逻辑，一两度的旧值也可能造成不必要的误动作。
3.4 连续转换与告警阈值，让芯片自己干活
配置寄存器的默认状态未必是“连续转换”。我第一次用类似芯片时就踩过坑：芯片默认处于关机或单次转换模式，我每次读到的温度都纹丝不动，还以为是 I2C 地址错了。正确做法是在初始化里明确把配置寄存器写一遍，不要指望出厂默认值就适合自己。
uint8_t cfg = 0x00; // 连续转换，转换速率按手册建议值(比如4Hz) uint8_t status = 0; // 写配置寄存器 HAL_I2C_Mem_Write(&hi2c1, PJ85718DM_ADDR, 0x04, I2C_MEMADD_SIZE_8BIT, &cfg, 1, 100); // 读一次寄存器确认写入成功 HAL_I2C_Mem_Read(&hi2c1, PJ85718DM_ADDR, 0x04, I2C_MEMADD_SIZE_8BIT, &status, 1, 100);告警阈值设置其实更值得花心思。HVAC 里的高温保护不能只靠主控“读完温度再自己比较”，因为如果主控死机、任务卡死、I2C 被其他设备拖住，保护逻辑就全废了。把阈值写进 PJ85718DM，用它的 ALERT 引脚直接触发主控的外部中断，等于给系统加了一道硬件级保险。
// 远程通道上限 85°C float limit_c = 85.0f; int16_t limit = (int16_t)(limit_c / 0.0625f); uint8_t limit_data[2] = { (uint8_t)(limit >> 8), (uint8_t)(limit & 0xFF) }; HAL_I2C_Mem_Write(&hi2c1, PJ85718DM_ADDR, 0x06, I2C_MEMADD_SIZE_8BIT, limit_data, 2, 100);ALERT 引脚一般是开漏输出，需要外部上拉，接到 STM32F407ZG 的一个 EXTI 引脚上。中断服务函数里先读状态寄存器确认告警源，再决定是停机保护还是只做告警提示。不要在中断里长时间清标志，那会拉低整个系统的实时性。
4. 实测中的误差与排障：从 NACK 到远程通道读数跳变
4.1 I2C 通信失败的完整排查链路
如果代码跑起来以后一直收到 NACK，或者读回的全是 0xFF、0x00，不要急着怀疑传感器坏了。按这个顺序走一遍，绝大多数问题都能定位：
- 确认从机地址。7 位地址 0x4E 的话，HAL 参数传 0x9C，这是新手第一道坎。
- 用示波器或逻辑分析仪抓 SDA/SCL，看有没有波形、边沿缓不缓、有没有器件把总线拉死。总线被拉成恒低，多半是某个从机地址冲突或亚稳态。
- 检查上拉电阻。没焊接、焊错阻值、上拉到的电源和芯片供电不一致，都会让通信时好时坏。
- 降低速率。400kHz 不行就换 100kHz，先确认为通信功能本身有没有问题。
- 断开其他 I2C 设备，只留 PJ85718DM 一颗，排除地址冲突和总线电容过大的影响。
- 用
HAL_I2C_IsDeviceReady在 main 循环里反复探测从机，配合串口打印，比盲调快得多。
uint16_t tick = 0; while (HAL_I2C_IsDeviceReady(&hi2c1, PJ85718DM_ADDR, 3, 100) != HAL_OK) { if (++tick > 10000) { printf("I2C device not found\r\n"); tick = 0; } HAL_Delay(10); } printf("I2C device ready\r\n");这条链路看起来简单，但我自己统计过，遇到 I2C 不通的案子，一半以上都是上拉电阻或者地址位的问题，真正芯片坏掉的情况非常少。所以排查顺序务必算着来，不要一上来就把时间花在“怀疑读到假温度”的深水区。
4.2 远程温度读数跳变和偏移的根因
远程通道读出的温度如果是“跳来跳去”或者“稳定但偏了几度”，原因通常集中在三块：
第一是 D+/D- 接反或接触不良。虚焊、接插件氧化、端子没插紧，都会让远程端等效阻抗变得不稳定。这种故障在现场特别容易复现为“刚开机正常，运行半小时后乱跳”，因为热胀冷缩改变了接触状态。
第二是走线串扰。远程线如果贴着 PWM 驱动线走，电流激励和 ADC 采样都会受干扰。在连续转换模式下，读数会周期性跳变，但波形又不像纯噪声那样无规律。处理办法是改走线、加屏蔽，或者把转换速率降低一点，让 ADC 有更多时间稳定。
第三是器件选择不对。三极管的 β 值、基极-发射极电压温度特性、封装大小都会影响远程读数。芯片手册里通常会给出推荐的远程晶体管型号，照着选型，别随手从抽屉里抓一颗。如果芯片有 β 补偿或晶体管类型选择寄存器，也要按实际器件配置。
4.3 实测数据与两点校准法
下表是我在老化箱里做的一组示意标定数据，拿水银温度计作为参考标准，对比同一时刻的参考温度和芯片读数，目的是演示校准方法，不同板卡的具体数值会有差异：
| 参考温度 (°C) | 本地通道读数 (°C) | 远程通道读数 (°C) | 远程通道偏差 |
|---|---|---|---|
| 25.0 | 24.94 | 25.18 | +0.18 |
| 40.0 | 39.97 | 40.28 | +0.28 |
| 55.0 | 55.03 | 55.47 | +0.47 |
| 70.0 | 70.06 | 70.61 | +0.61 |
远程通道表现出了明显的线性偏移：温度越高偏差越大。这往往是走线电阻或激励电流差异造成的固定比例误差。最简单的处理是两点校准，设参考温度点为 T1=25°C、T2=70°C，对应读数为 R1=25.18、R2=70.61，那么修正公式为：
增益 = (T2 - T1) / (R2 - R1) = 45 / 45.43 ≈ 0.9905 偏移 = T1 - R1 * 增益 ≈ 25 - 25.18 * 0.9905 ≈ 0.058 修正后的温度 = 原始读数 * 0.9905 + 0.058把这两个系数写死在固件里，然后再回去读 25°C、40°C、55°C 的点，通常在 ±0.2°C 以内。相比逐点查表，两点校准实现简单、维护方便，HVAC 控制精度完全够用。唯一要注意的是校准必须覆盖目标工作温度范围，只标定室温附近的点，拿去做高温保护就会出问题。
5. 把温度监测接入 HVAC 控制逻辑：采样节奏、滤波与告警策略
5.1 采样节奏：温度不是越快越好
HVAC 系统本身热惯性很大，压缩机壳体温度、蒸发器温度变化远不如电机电流那样快。所以 I2C 读温度用不着跑到上百赫兹。转换速率选 4Hz，软件里 500ms 到 1s 采一次就够了。读得过快反而会把细微的 ADC 噪声和走线毛刺当作真实温度变化，然后设计者为了让数值平滑又不得不加更重的滤波，白白增加延迟。
我用的是指数滑动平均，比简单平均更省内存，对突发毛刺也有明显的抑制作用：
float filt_local = 25.0f; float filt_remote = 25.0f; void temp_update_once(void) { float t_local = pj85718dm_get_local_celsius(); float t_remote = pj85718dm_get_remote_celsius(); // 跳过异常值 if (t_local >= -40.0f && t_local <= 125.0f) filt_local += (t_local - filt_local) * 0.1f; if (t_remote >= -40.0f && t_remote <= 125.0f) filt_remote += (t_remote - filt_remote) * 0.1f; }0.1 的系数对应的时间常数大约是 2到3 个采样周期，对 HVAC 来说足够平滑。但如果要做快速故障保护，不要用这种滤波后的值，直接拿原始值判断，滤波值只用于显示和上传。保护逻辑和显示逻辑的取数路径分开，是我在做控制器时给自己的硬规矩。
5.2 告警、停机保护与迟滞
压缩机保护逻辑通常要求“到达阈值立即动作，温度回落一点以后再允许恢复”，否则会在阈值附近反复启停，对压缩机伤害很大。阈值写在芯片寄存器里，固件里再叠加一层迟滞判断，两层保险。
#define ALARM_REMOTE_HIGH 85.0f #define ALARM_REMOTE_RESET 80.0f static uint8_t remote_alarm_flag = 0; void hvac_protection_check(float t_remote) { if (!remote_alarm_flag && t_remote >= ALARM_REMOTE_HIGH) { remote_alarm_flag = 1; // 关压缩机，记录故障原因 } else if (remote_alarm_flag && t_remote <= ALARM_REMOTE_RESET) { remote_alarm_flag = 0; // 压缩机允许恢复 } }迟滞范围一般取 3°C 到 8°C，具体看系统允许的温度波动。这个 5°C 的窗口不是拍脑袋来的，而是对应了压缩机外壳在停机后自然散热的速度。窗口太窄，现场会看到“报警-恢复-再报警”的振荡；窗口太宽，又会让系统带伤运行太久。
5.3 数据组装与上报
在很多 HVAC 项目里，STM32F407ZG 不是孤立工作的，温度数据要送给上位机、触控屏或者楼宇网关。I2C 读到的温度最终总要变成协议帧里的字节。我习惯统一把温度放大 10 倍后用整型传输，也就是 25.6°C 传 256，这样可以避开浮点协议在不同设备间的字节序问题，上位机解析也简单。
串口打印的 Demo 帧可以是这样：
uint8_t frame[6]; frame[0] = 0xAA; // 帧头 frame[1] = 0x10; // 数据类型：温度报文 frame[2] = (uint8_t)((int)(filt_local * 10) >> 8); frame[3] = (uint8_t)((int)(filt_local * 10) & 0xFF); frame[4] = (uint8_t)((int)(filt_remote * 10) >> 8); frame[5] = (uint8_t)((int)(filt_remote * 10) & 0xFF); HAL_UART_Transmit(&huart2, frame, 6, 100);如果你用的是 CAN 总线，思路完全一样，把温度按 0.1°C 分辨率塞进 CAN 报文的数据域。信号协议里一定要预留状态字，把“传感器断线”“通信异常”“正在校准”这些非温度状态带出去，否则上位机很难区分“0x7FFF”到底是 327.67°C 还是故障码。
6. 回头总结：三处最容易被低估的细节
第一处是远程通道的器件选型和接法。很多工程师把重点放在 I2C 读写上，却忽略了远程端那颗三极管的重要性。二极管接法、基极集电极短接、型号匹配、D+/D- 方向，每一环都是精读的前提。我见过太多“远程温度不准”的反馈，最后都绕回这两个焊盘之间。
第二处是芯片配置别依赖默认值。连续转换模式、转换速率、数据就绪标志、阈值寄存器，全部要显式初始化一遍。这个习惯能让固件在换料、换批次、换板卡之后减少大量隐性差异。尤其是在产品跑到现场几个月后才偶尔出现的“温度不动”，多半就是配置被意外改掉了。
第三处是保护和显示的数据路径要分开。告警判断用原始值，显示和上传用滤波值，同时靠芯片硬件 ALERT 兜底。这样既不会因为毛刺误报警，也不会因为滤波而错过真正的高温风险。用 STM32F407ZG 跑这套逻辑毫无压力，真正的难点在于把这些细节紧紧焊接在一起，而不是单点功能跑通就算完事。
如果你正准备用 PJ85718DM 搭一套 HVAC 控制板原型，我建议第一版 PCB 就把远程通道的走线、测试点、校准电阻位都预留好。等你在老化箱里做完标定，看着两路温度和参考温度稳定地重合在 ±0.2°C 以内，你会觉得这块小板子上藏着的所有看似琐碎的判断，最后都是值得的。
