做嵌入式温度监测，我最近一直在用 PJ85718DM 这颗传感器加上 STM32F042C6 这颗 M0 主控，做本地和远程温度采集。刚开始以为这就是“上拉电阻读寄存器”的小活，真正深入进去才发现，本地温度、远程二极管测温、HVAC 环境里的干扰和安装方式，每一环都有讲究。这篇文章就把这套组合从选型、硬件、固件到现场调试的完整过程写出来，适合正在做温控、低压变频器、HVAC控制器或者电池管理系统里温度保护的朋友参考。

PJ85718DM 是一颗带 I2C 接口的数字温度传感器，和普通单点温度芯片最大的区别是，它同时支持本地温度采样和远程二极管温度采样。STM32F042C6 则是 Cortex-M0 内核的 MCU，主频 48MHz，内置 CAN、USB、多路 USART 和硬件 I2C，做传感器数据读取、PID 调节、Modbus 上报都足够用。这个组合解决的核心问题只有一个：设备既要知道“自己身边有多热”，也要知道“远处一个温度敏感点有多热”，而且两边数据要在同一套采集链路里完成，成本还不能高。

1. 方案拆解：为什么是“本地温度传感器 + 远程测温通道”的组合

1.1 PJ85718DM 到底解决了什么问题

很多场景需要一个传感器同时照顾两个测温点。举几个我实际接触过的例子：

• 嵌入式控制器里，要监控 PCB 环境温度，同时还要监控功率器件或者主芯片的结温。
• 变频器或者电机驱动器里，IGBT 模块附近需要温度保护，但控制板上的 MCU 也想拿到散热器温度。
• HVAC 空调内机，控制板需要知道板载温度来做防凝露判断，而蒸发器管路、回风风道的温度又得靠一个伸出去的探头采集。

如果只用普通 NTC，每个测温点都要一路信号调理、一个 ADC 通道、一套校准系数，硬件复杂，校准更是麻烦。PJ85718DM 这种带远程通道的芯片，本地通道直接读芯片内部结温，远程通道则通过一对 D+、D- 引脚接一颗二极管连接的三极管，就能把远处的温度信号拉回到同一颗芯片上处理，输出统一走 I2C 总线上报。

远程测温的核心原理并不难理解。二极管的 PN 结正向压降 Vbe 会随温度变化，大约每升高 1°C 降低 2mV 左右。但直接用 Vbe 绝对值算温度，会受到器件批次、串联电阻、焊接工艺带来的误差影响。PJ85718DM 这类芯片更常用的做法是“不同激励电流下的 ΔVbe 测量”：分别用两种电流去驱动外部二极管，测量两个 Vbe 的差值。因为 Vbe 绝对值里的固定项会被差分运算抵消，剩下的 ΔVbe 就和绝对温度近似成正比，再经过片上 ADC 转换，就能得到数字温度。这也是远程通道在较长距离走线时仍然能维持精度的原因。

本地通道则简单很多，芯片内部有一个寄生的测温二极管和同一个 ADC 采样链路。因为本地传感器和 ADC 在同一颗芯片里，距离短、温度梯度小，所以本地精度通常能做到比远程更好。手册里给的典型规格大约是本地 ±0.5°C，远程 ±1°C 上下，这在 HVAC 和一般嵌入式热保护里已经够用。如果你只需要“大概准”而不是“实验室级别准”，这套方案比外面挂三四个 NTC 省事得多。

1.2 为什么选 STM32F042C6 当主控

STM32F042C6 不算新器件，但在这个项目里非常合适。它的技术参数并不华丽，而是胜在接口全、功耗低、价格稳定。

• Cortex-M0 内核，48MHz 主频。跑 I2C 采样、滤波算法、PID 或者简单的 Modbus 协议栈完全够用，不需要上高成本 M4。
• 内置 CAN 2.0B 和 USB FS。嵌入式场景里如果要和车辆总线、运动控制器通讯，CAN 是现成的；如果要做本地调试，USB 虚拟串口插上就能看数据流。
• I2C 接口是硬件外设，不需要软件模拟时序。配合 DMA 和中断，读温度寄存器只需要几个周期，CPU 时间可以留给控制逻辑。
• 工作电压只有 3.3V，逻辑电平、功耗模型都很好规划。整个测温节点如果控制得够精细，运行电流可以做到很低。
• OFQFN 或者 LQFP 封装体积小，适合塞进 HVAC 控制板这种空间不宽裕的场合。

有人会问，既然只是读温度，为什么不用一颗 8 脚的小单片机？因为这类项目通常不是“只测温”这一个功能。STM32F042C6 还要负责继电器控制、风扇调速、状态指示、与上位机通讯，甚至跑本地保护逻辑。留出一路 I2C 接温度传感器，只是它的本职工作之一。

1.3 这套组合在什么项目里最划算

我做这套的时候总结过一个判断标准：如果你只需要测一个点的温度，用一颗单通道数字传感器或者 NTC 加运放就解决了，完全没必要上双通道远程方案；但如果系统里“板内温度”和“远端温度”都必须要，而且两者距离可能超过 20cm、甚至分属不同 PCB 或者不同结构件，那 PJ85718DM 这种方案就开始变得合适。

典型的嵌入式场景包括：

• 充电器 / 电源适配器：本地测内部环境温度，远程测充电接口或者电池包表面温度，超过阈值直接降功率。
• 无刷电机驱动板：本地测 PCB 温度，远程通过一颗贴在三相桥散热片上的二极管三极管测散热器温度。
• 智能照明电源：LED 金属基板上的温度点通过远程探头采集，实现过温降额，延长 LED 寿命。

HVAC 场景则更直接：

• 空调外机控制器：本地测电控盒温度，远程探头固定到压缩机排气管或者冷凝器管壁，配合制冷逻辑做防过载。
• 新风系统：控制板测电路温度，远程探头伸进风道测进风温度，用来判断是否结露。
• 恒温恒湿设备：本地是控制板温度，远程测量水箱或者出风口温度。

这些场景的共同点是：远端温度点本身不方便放一整块带 MCU 和通信芯片的电路板，只放一颗小二极管非常灵活。把二极管用导热胶贴在目标物体表面，引线长度控制在几十厘米内，温度信号就能回到主控板上的 PJ85718DM，再由同一颗芯片转成 I2C 数据给 STM32F042C6。这种一主一从的架构，比在每个测温点单独放传感器、再通过长线通讯回传，可靠性和成本都更优。

2. 硬件设计：PJ85718DM 与 STM32F042C6 的完整连接链路

2.1 传感器最小电路：别只拉两线上拉电阻

PJ85718DM 的引脚不多，一般可以归纳为：电源 VDD、地 GND、I2C 时钟 SCL、数据 SDA、远程测温正负端 D+、D-，还有地址选择 ADD0/ADD1、报警输出 OS/ALERT。不同批次可能引脚定义顺序有变化，但功能类别是稳定的。

在设计最小电路时，下面这几个要点是我自己的习惯：

• VDD 对 GND 必须放 0.1μF 陶瓷电容，并且靠近引脚放。如果系统电源纹波较大，再并联一个 1μF 到 10μF 的电容，实测对温度读数稳定性很有帮助。
• SDA、SCL 都需要上拉电阻。电阻值要按总线上挂的设备数量、走线长度和通信速率来定。总线上只有这颗传感器，工作频率在 400kHz 以内，上拉 4.7kΩ 通常没问题；如果线长超过 10cm 或者总线电容偏大，就换 2.2kΩ。
• ADD0/ADD1 决定 I2C 地址。做多路采集时可以用同一个寄存器地址，通过不同地址段的芯片接在同一条 I2C 总线上，每路能区分开。
• OS/ALERT 是漏极开路输出，也要接上拉电阻，并且可以接到 STM32F042C6 的外部中断引脚。这样温度超过阈值时，MCU 不需要轮询，直接被中断唤醒处理。

我通常把传感器放在控制板边缘，靠近远程探头接线端子那一侧，避免 D+、D- 的长走线穿过板子中间的电源区域。

一个需要注意的坑是远程测温脚 D+、D- 的极性。大多数传感器要求把二极管三极管的集电极和基极短接后接 D+，发射极接 D-，接反了读数会明显不对。有的芯片手册里说“支持反接检测”，但为了省调试时间，我建议直接按标准接法设计，不要赌。

下面是一张参考连接示意表：

STM32F042C6 这边，VDD 就近加 0.1μF 和 4.7μF 电容，NRST 默认上拉，BOOT0 下拉到地。如果系统里要跑 USB 或者 CAN，还要注意晶振和终端电阻，这些和普通 STM32 设计没有区别，不展开细说。

2.2 远程测温为什么非得用“三极管接成二极管”

很多人第一次看到远程温度探头，会下意识觉得“直接拿一个普通整流二极管不就行了吗”。我试过，能工作，但精度差不少。PJ85718DM 这类芯片测量远程温度，依赖的是二极管的 Vbe 温度特性，而我们实际希望测量的是一个理想二极管模型的结温。

普通整流二极管（比如 1N4007）正向特性不一致，生产批次差异大，而且封装管壳热阻高，感应到的往往是引脚周围空气温度，而不是目标物体温度。更合适的做法是用小信号三极管，比如常见的 MMBT3906，把基极和集电极短接，让集电结变成零偏置，只让发射结发挥二极管作用。这样：

• 发射结面积小、热阻低，能更准确地感应粘贴位置的温度。
• 三极管的工艺一致性比普通二极管好，批次离散性小。
• 不同型号三极管的 ideality factor 值（非理想因子）相对接近，芯片内置的校正算法能更好匹配。

更进一步的场景是直接测量 MCU、CPU、GPU 芯片内部的结温。很多处理器会把片上测温二极管引到外部引脚，使用前要查清楚是 PNP 对管还是 NPN 对管结构、电流激励大小、是否需要设置 ideality factor 寄存器。PJ85718DM 如果提供 n-factor 校正配置，就要按目标芯片手册里的参数写进去。如果忽略这一步，远程读数可能会有 1°C 到 2°C 的误差，在某些应用里这就足以触发保护动作了。

2.3 HVAC 环境下的 PCB 布局和抗干扰经验

HVAC 设备里的电磁环境说不上恶劣，但比实验室恶劣得多。我踩过的坑里，印象最深的是风机继电器吸合的瞬间，温度读数跳一下，然后恢复正常。用示波器看 D+ 引脚，发现上面叠加了不小的高频毛刺。温度传感器内部 ADC 采样虽然会做滤波，但远程模拟输入端口是高阻抗，处理不好就容易吸收噪声。

我的处理经验有这么几条：

• D+、D- 差分走线尽量贴近，中间不要穿插其他信号线，避免形成大的环路面积。
• 在传感器 D+、D- 引脚附近加一个几十 pF 到几百 pF 的对地电容。注意不能加太大，电容过大会影响电流建立时间，导致转换结果偏低。通常 100pF 起步，实测可用性最高。
• 如果远程探头线必须过长，超过 30cm，就在探头端做一个 RC 低通滤波，而不是在主板上硬扛。
• 传感器和 MCU 的地、电源地之间做单点连接，避免继电器驱动的地电流串进传感器地。
• 报警输出漏极开路引脚上拉电阻不要选太大，否则边沿过慢，在电磁噪声里容易被误触发中断，我一般用 4.7kΩ。

另外，不管板内空间多紧张，我都建议给远程温度探头留一个独立的连接器，不要直接把裸线焊在主板上。现场接线时，HVAC 设备往往需要拆装多次，可插拔连接器能减少线缆折断的概率，后续维护更换探头也方便。接线端子尽量选带锁定结构的，防止震动松脱。

3. 固件设计：把温度读数变成可控可用的数据

3.1 I2C 底层读取与寄存器读写

STM32F042C6 使用硬件 I2C，我在项目里优先用 HAL 库，因为它对超时、错误标志的处理比较完整。调用方式并不复杂，以读取本地温度寄存器为例：

uint8_t data[2]; HAL_StatusTypeDef status; status = HAL_I2C_Mem_Read( &hi2c1, (uint16_t)(PJ85718_ADDR << 1), PJ85718_REG_LOCAL_TEMP, I2C_MEMADD_SIZE_8BIT, data, 2, 100 ); if (status != HAL_OK) { // 记录一次总线错误，连续失败则尝试恢复 I2C 总线 }

PJ85718_ADDR 要根据 ADD0、ADD1 的跳线来定义，不能写死成 0x90。寄存器地址按照手册填写，读取顺序要一次性读完 2 字节，不要拆成两次字节读取，否则在两次读取之间数据更新，高低字节会错位，温度值可能出现异常跳变。

为了屏蔽总线上其他干扰，我给每次读取加了超时。HAL 里面最后一个参数就是超时时间（毫秒），在温控逻辑中，我习惯设为 20ms。超过 20ms 还没读回来，就判定总线挂死，走 5.2 小节的恢复流程。

3.2 温度转换计算：从寄存器原始值到“让人看得懂”的摄氏度

PJ85718DM 的温度数据寄存器一般是 16 位，高 12 位是有效温度，低 4 位作为扩展精度或者为 0。典型分辨率是 0.0625°C，也就是把最高有效位当作符号位。转换时，先将两个字节拼成 int16_t，再右移 4 位得到真正的 12 位有符号数，最后乘 0.0625。

int16_t raw = (int16_t)((data[0] << 8) | data[1]); raw >>= 4; // 保留 12 位有符号温度 float temp_c = (float)raw * 0.0625f;

举个例子，如果 data[0]=0x0D，data[1]=0xA0，拼起来是 0x0DA0，右移 4 位得到 0x0DA 即 218，218 × 0.0625 = 13.625°C。如果寄存器值是负温度，右移后符号扩展依然成立，这个公式不用额外处理。

远程温度寄存器采用同样的转换方式。在把原始值转成 float 之前，我还建议保留一份原始寄存器值，用于后期排查。现场设备一旦出现温度异常，先用 I2C 调试器读寄存器，确认是“传感器本身读数就不对”，还是“固件转换或上层处理引入了错误”。这一步在 HVAC 设备远程维修时特别管用，能省下大量来回跑现场的功夫。

3.3 阈值报警：让 MCU 靠中断而不是阻塞轮询

如果每 100ms 读一次温度，轮询也不会占用很多 CPU，但优势在于报警能力。PJ85718DM 一般有本地和远程高低温限值寄存器，还会有一个 OS/ALERT 输出脚。把高低温限值写进去之后，芯片自身会持续监控两个通道温度，一旦超限，就把 OS/ALERT 引脚拉低。

我在项目里是这样安排的：

• 初始化阶段写入本地通道高温限值、远程通道高温限值和恢复回差。
• OS/ALERT 配置成“比较器模式”，温度低于限值时自动恢复，不锁存。
• STM32F042C6 的 PA0 配置为外部中断下降沿触发。
• 中断服务函数里只置一个标志位，具体的风扇调速、降功率、报警动作放在主循环处理，避免在中断里做耗时的 I2C 操作。

有一点值得注意，报警限值寄存器用的是和温度寄存器一样的分辨率，写入时要把目标温度值除以 0.0625 再换算成整型。比如远程最高温度要设成 85°C，寄存器值就是 85 / 0.0625 = 1360，也就是 0x0550。如果用浮点算完以后不处理对齐问题，可能写入一个略高于目标值的数，导致保护动作偏差。

3.4 低功耗轮询策略

这个方案里传感器本体功耗很低，真正的功耗大头是 MCU。STM32F042C6 常用的运行模式电流有个几十毫安，但对电池供电的设备来说还不够。我的低功耗策略是“传感器 asleep，MCU stop，定时醒来一下”。

具体时序是：

1. 将 PJ85718DM 写 shutdown 配置，进入低功耗待机。
2. STM32F042C6 进入 STOP 模式，使用 RTC 或低功耗定时器设置唤醒周期。
3. 唤醒后，给传感器发起一次 one-shot 转换，等待转换完成，读取温度寄存器。
4. 判断温度是否超限，然后迅速重新进入 STOP。

这样的设计能把平均电流压到微安级别，适合温度采集节点。HVAC 控制板通常不要求这么省电，但嵌入式电池设备，比如无线传感器、冷链标签，就非常有帮助。

需要注意的是，one-shot 转换不是马上完成的，启动后必须让传感器内部 ADC 完成采样，再读寄存器。有的芯片会提供数据更新标志，没有标志的话，就按手册里的转换时间延时。延时太短读到的还是上一次数据，太长又浪费电流，所以这个时间要按手册算准。不同分辨率模式对应不同的转换时间，一般从几十毫秒到一两百毫秒不等。

4. 数据从量测到应用：嵌入式保护逻辑与 HVAC 监控平台

4.1 嵌入式场景里的环形缓冲、滤波与 ODT 保护

嵌入式中控板需要的不仅仅是“当前温度值”，而是“趋势”和“变化率”。我常用的做法是在内存里维护一个环形缓冲，保存最近 16 到 32 次温度采样，然后计算移动平均。

#define TEMP_BUF_LEN 16 static float temp_buf[TEMP_BUF_LEN]; static uint8_t idx = 0; static float temp_sum = 0.0f; float update_moving_average(float new_value) { temp_sum -= temp_buf[idx]; temp_buf[idx] = new_value; temp_sum += new_value; idx = (idx + 1) % TEMP_BUF_LEN; return temp_sum / TEMP_BUF_LEN; }

这个写法占用资源极小，但能明显抑制偶发毛刺。配合变化率检测，还能做 ODT（过温降额）或者热保护：当远程温度每秒钟上升超过某个斜率，比如 5°C/s，就提前降低 PWM 占空比，而不是等温度冲到阈值才动。在电机驱动和电源适配器里，提前一点降额往往比事后切断更实用，因为负载可以继续工作，只是性能稍微下降。

HVAC 里的风机调速逻辑也类似。远程冷凝器温度高时，提高风机转速；温度降下来后，再逐步降速，中间加滞回区间，避免风机频繁变速。PJ85718DM 双通道的优势在这里体现得很充分：本地温度负责控制板自身热保护，远程温度负责制冷循环热负荷判断，两路各自有独立的报警限值，互不干扰。

4.2 HVAC 场景：通过 Modbus 把温度上报到监控平台

设备端的温度数据要送到人机界面或者楼宇控制系统，在 HVAC 行业最通用的还是 RS485 加 Modbus RTU。STM32F042C6 的 USART 加上一个收发器，配合中断发送和接收，就能实现简洁的从机栈。

我习惯把温度值按 0.1°C 为单位存到保持寄存器里，这样整数运算足够，精度也比 0.0625°C 低不了多少，还能避开浮点和 Modbus 协议编码的麻烦。一张典型的寄存器映射表如下：

协议栈不需要做全套复杂逻辑，只需要支持 03 读保持寄存器、06 写单个寄存器、16 写多个寄存器，就能满足大多数现场需求。写入功能多用于远程设置温度阈值，这里要留意整数单位换算，比如上位机写入 850 表示 85.0°C，固件里要除以 10 再存到浮点变量，写回传感器时再乘回 16 倍换算成寄存器的 0.0625°C 单位。单位不统一是现场参数错乱的高频原因，我建议在代码里把所有温度值统一成“0.1°C 有符号整型”，到了传感器驱动层再单独换算。

嵌入式设备内部通讯如果走 CAN，则更简单：每 100ms 发送一帧 CAN 标准帧，ID 前 8 位是设备类型，后面数据字节放本地温度、远程温度、报警标志。总线节点少的话，不需要复杂的网络管理，只要约定好数据格式即可。

4.3 多点校准与一致性

传感器出厂虽然做过校准，但远程通道的探头安装位置、导热介质、线路电阻都会影响最终读数。在 HVAC 和嵌入式现场，我强烈建议做一次“系统级校准”，而不仅仅是芯片级校准。

校准流程我一般这样做：

• 把远程探头的感温端和一只标准温度探头绑在一起，放在同一个恒温环境里。
• 分别在 0°C、25°C、50°C（或者项目关心的下限、中间、上限）三点读取 PJ85718DM 远程温度值。
• 用最小二乘法拟合出实际温度 = 测量温度 × k + b 的系数，把 k 和 b 存在 STM32F042C6 的 Flash 里。
• 固件每次上报前调用这段校正公式，而不是直接上报原始转换值。

如果应用场景温度范围不大，也可以只做单点偏移校正。但要注意：只调整偏移，不调整增益，在距离中心温度较远的位置可能依然有偏差。比如 HVAC 设备冬季远程温度在零下，夏季在 60°C，跨度大，就必须两到三点校正。

导热介质也是容易忽略的误差来源。远程探头感温部分要用导热硅脂和被测物体充分接触，不能留空气间隙。空气的导热系数很低，会造成明显滞后和偏低读数。现场如果是测水管外壁，还要先清除表面的锈渍和水垢，否则测量的是“锈层温度”而非“管壁温度”。

5. 实测中的坑与排查办法

5.1 温度读数跳变几十度，过一会儿又恢复

这个现象我在第一次做远程测温时碰到过。表面看是数字乱跳，用示波器看发现远程通道波形上叠加了尖峰。排查顺序如下：

1. 确认远程三极管基极和集电极确实短接。如果只是用一个普通二极管，接法不对就可能出现异常。
2. 检查 D+、D- 走线是否和继电器驱动线、电源线平行。如果平行长度长，尝试换层、加宽间距。
3. 在 D+、D- 对地加 100pF 到 220pF 电容，看跳变是否减小。
4. 如果数据还是乱跳，把远程探头线断开，用短跳线直接在板载焊盘上接入测温管，排除长线问题。

这个问题的本质是远程模拟信号太容易被干扰。和普通数字 I2C 不一样，远程二极管测量是一个微弱的模拟量，你没法靠“重发一次数据”来补救，必须在硬件端就把噪声抑制住。

5.2 I2C 总线挂死，传感器不回 ACK

现象是主控读取超时，SCL 正常，SDA 一直是低电平。这种情况多数是系统刚上电、总线上有其他设备抢占了通信，或者 SDA 在通信过程中被干扰拉低。我用的恢复方法是“总线时钟脉冲恢复法”：

void recover_i2c_bus(void) { GPIO_InitTypeDef gpio = {0}; gpio.Mode = GPIO_MODE_OUTPUT_OD; gpio.Pull = GPIO_PULLUP; gpio.Speed = GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(SDA_GPIO_Port, &gpio); for (int i = 0; i < 10; i++) { HAL_GPIO_WritePin(SCL_Pin, GPIO_PIN_RESET); delay_us(5); HAL_GPIO_WritePin(SCL_Pin, GPIO_PIN_SET); delay_us(5); } HAL_GPIO_WritePin(SDA_Pin, GPIO_PIN_SET); MX_I2C1_Init(); // 重新初始化硬件外设 }

这个办法利用 SCL 时钟沿让挂死的从机释放 SDA，成功率比较高。但如果传感器彻底死机，脉冲不起作用，就需要掉电重启传感器。所以我在硬件设计上，给 PJ85718DM 的电源加了一个由 GPIO 控制的负载开关。真到需要复位传感器的时候，只需要把 GPIO 拉低再拉高，不用整个系统断电。

这一点在 HVAC 现场特别重要，因为设备一旦运行，断电重启需要停机，会造成很大的麻烦。能单独复位传感器，比复位整个控制器好太多。

5.3 低温环境下读数偏高的“假高温”

有次在冷库设备里，传感器装在控制柜内，控制柜在冷库内部，远程探头贴在蒸发器盘管上。调试时发现远程温度始终比现场温度高 3°C 左右，而且很稳定。后来发现是冷库环境里，空气相对湿度很大，远程探头感温部分和导热硅脂暴露在潮湿空气中，表面结了一层冰水混合物，等效热阻变大，导致传感器感知的不是盘管壁温，而是冰层外面的温度。

解决办法并不神秘：把探头感温部分用高强度导热胶密封起来，再压紧在管壁上；接线端子涂抹防凝露硅胶；控制柜内加一点小功率加热，防止 PCB 直接结露。之后读数就和参考温度一致了。HVAC 设备做温度监测，安装工艺常常比电路设计影响更大。

5.4 远程二极管选型导致的精度偏移

我这里补充一个容易踩的坑：PJ85718DM 的手册通常会建议用 2N3904/2N3906 这类小信号三极管做远程测温探头，但现场如果采购替代料，很可能买到贴片封装、die 材料或者工艺参数差异较大的管子。替代料的 ideality factor 和手册校正参数不匹配，采集到的温度会稳定偏移，有的甚至会偏移 2°C 以上。

处理方式有两种：

• 严格按推荐型号采购，不随意替代。远程温度探头是整个系统里的极小成本项，没必要在这里省几毛钱。
• 如果必须替代，就在固件里开放一个远程通道增益校正参数，通过远程补偿寄存器把误差拉回来。前提是芯片支持 ideality factor 或 offset 补偿，PJ85718DM 这类芯片一般会有对应寄存器。

我把常见现象和排查方法整理成了表格，方便现场用：

最后再分享一个小技巧

这套方案真正稳定运行之后，我反而舍不得删掉调试阶段留下的一组“原始值日志”。就是每次把 PJ85718DM 的本地温度高字节、远程温度高字节、报警状态原样打进日志，和经过程序转换后的温度值放在一起。线上设备一旦出现保护动作，先看原始寄存器就知道是传感器数据本身出错，还是后端的滤波、转换、阈值比较环节出了问题。

另一个小经验是给远程探头预留一个“开路自检”流程。当远程 D+、D- 悬空时，芯片一般能返回一个明显异常的温度值（比如 -64°C 或者 127°C）。固件里判断到这种情况，直接把对应通道标记为故障，而不是把异常温度送进控制逻辑。否则 HVAC 设备在运行中探头线断掉，控制逻辑可能会误以为温度过低，持续加热，酿成事故。温度监测系统最重要的不是把数据算得多么精确，而是在传感器异常时能“知道自己是异常的”。这一点，做嵌入式的人越早明白越好。