做嵌入式温控的人基本都会遇到这种尴尬：板子上的温度要测，板子外面几十厘米甚至隔着一层风道的温度也要测。以前我图省事，直接挂两个独立传感器，第二个传感器得多占一路走线、多占一个 I2C 地址，软件里也要多维护一份校准表。后面换成 PJ85718DM 搭配 STM32F723ZE 这个组合，用一颗芯片同时管“本地温度”和“远程温度”，才真正把这个流程顺了过来。PJ85718DM 本身带一个本地测温通道，同时能通过独立引脚去读远端测温结，内部还有 ALERT 输出，特别适合嵌入式板卡热点保护和 HVAC 环境温度采集这两类场景。对新手来说，最关心的无非是三件事：这个组合怎么连、温度数据怎么读准确、出了故障怎么定位。这篇就把这套方案从选型到调试完整讲一遍，偏实战，不堆满页寄存器表。
1. 为什么本地和远端温度要放进同一颗芯片：先从需求拆开再选型
1.1 嵌入式应用里最常见的两个温度点
嵌入式设备表面看只需要一个“板温”，真正要盯住的往往是功率管、电机驱动、电感、电池这些局部发热点。传感器本体能测的是自己所在位置附近的环境温度，可发热点经常离它好几厘米，甚至隔着铜箔和风道。PJ85718DM 这类带远程通道的测温芯片，解决的就是这个“够不着”的问题：把本地通道放在主控板上测环境温度，把远程通道引到远端测温结上，那个结可以贴功率管，也可以贴散热器。对精度要求不那么苛刻的设计，这个方案比热电偶省事得多，不用考虑冷端补偿和热电偶线性化，软件上也几乎不用做查表。
1.2 HVAC 应用里它对应的是什么测点
在暖通系统里，“本地温度”和“远程温度”的关系也很好理解。控制器通常装在电控箱里，电控箱里的空气温度跟送回风管里的实际气流温度相差很大。以前做集中控制，要么在风管里单独装变送器，要么从电控箱拉一根长感温探头出来。用双通道传感器之后，本地通道就当电控箱环境温度，远程通道接一个小型二极管探头伸进风管或贴在盘管表面，一根线搞定。防冻开关、新风预热、送回风温差监测这几个场景，本质上都是“柜内温度 + 远端测点温度”配对出现，很适合这种通道布局。特别是防冻场景，风管温度一旦低于设定值就要触发保护，这个温度点通常离控制板很远，正好是远程通道发挥价值的地方。
1.3 一颗芯片和两颗独立传感器的取舍
从成本和维护角度讲，一颗双通道传感器确实有吸引力。少一个器件、少一个 I2C 地址、少一路供电，两路读数还在同一个 ADC 基准上，温度一致性会比两个芯片拼出来的好很多。但也有不适合的场景：如果两个测温点之间要走几十米线缆，或者两个点分属不同的供电域和安全隔离区，那还是老老实实用两个隔离的探头更稳妥。我自己判断的规则是：距离在几十厘米到几米，且供电域相同，优先双通道；超过这个范围或者要求完全隔离，拆开做。
| 对比项 | 单颗双通道方案 | 两颗独立传感器方案 |
|---|---|---|
| BOM 数量 | 少一个器件，封装面积有优势 | 多一颗器件，占板面积更大 |
| 地址与软件 | 一个 I2C 地址，逻辑简单 | 两个地址，需要分别初始化和校准 |
| 校准一致性 | 共享同一 ADC 基准，偏差趋势接近 | 两颗芯片工艺差异可能会带来额外偏差 |
| 长距离隔离 | 不适合长线且隔离要求高的场合 | 适合部署分散测点，可单独隔离 |
| 故障诊断 | 有远程开路短路标志，诊断集中 | 需要额外设计通信层诊断 |
2. PJ85718DM 的测温机制与寄存器配置：看懂读数为什么准
2.1 本地通道怎么变成数字量
这类双通道传感器的本地通道，通常是利用片上 PN 结测温，ADC 采样后得到一个带符号的数字温度值。PJ85718DM 数据手册里的输出格式一般是 12 位或 13 位，最低位代表 0.0625°C。把两个字节拼成一个有符号整数后，整体右移 3 位再去乘 0.0625，就得到了摄氏温度。这个换算关系要特别留意，因为不少同事直接把原始整数当作温度，会读出一个大得离谱的数字。转换周期也是容易忽略的一项。HVAC 环境温度变化慢，可以把周期放到几千毫秒一测，噪声低、功耗也低；嵌入式功率模块的温度变化快，就开更高频的转换，宁可提高功耗也要保证及时看到变化。
2.2 远程通道的 ΔVbe 原理：远程探头为什么能用普通二极管
远程通道的原理和本地通道不太一样。它测的是一颗远端二极管或晶体管结：传感器轮流灌入两个不同的电流 I1 和 I2，再测两次正向压降的差 ΔVbe。根据半导体物理，这个差值约等于 (kT/q) 乘以电流比的自然对数，和外部偏置电流绝对值、反向饱和电流都没有直接关系，所以温度测量可以在不校准二极管工艺的情况下做到不错的一致性和线性度。工程里常见的做法，是把 NPN/PNP 三极管的基极和集电极短接，当成一个二极管来接，或者直接选用芯片厂商推荐的测温二极管。
但远程通道也有几个要补偿的地方。第一是线缆串联电阻，电流差和电阻会造成真实误差，很多芯片带串联电阻补偿，开启后可以把这部分抵消掉。第二是晶体管的 β 补偿，PNP/NPN 电流放大倍数不够理想时，流入结的电流和传感器认为的电流不一致，同样会引入偏差。第三是线缆电容，线越长，半导体结的电压建立时间越慢，如果转换周期很短，读数会不稳定。HVAC 应用里把探头用几米线接到风管时，这几个问题会同时出现，所以不能只看标称精度，还要结合真实接线长度来评估。
2.3 配置寄存器时优先盯住的三类项目
我把 PJ85718DM 的配置拆成三类：测量行为、告警阈值、状态与故障标志。测量行为主要指转换周期、分辨率、平均次数；告警阈值是本地和远程通道各自的上限、下限和迟滞；状态标志用来判断远程通道有没有开路、短路，以及上一轮转换是否完成。写配置的顺序也有讲究。比如先写阈值再清状态标志，避免旧的超限状态带着新阈值去判断；开 ALERT 中断之前，先读一遍状态寄存器，把历史置位清掉，防止上一轮触发导致上电就误报警。如果某个版本支持多个远程通道，每个通道的阈值和故障标志要分开配，不能只盯住第一个通道；本方案里只启用一个远程通道，这个习惯也依然适用。
3. STM32F723ZE 侧的通信设计：从 I2C 上拉到滤波调度
3.1 物理层：I2C 速度、上拉电阻和地址选择
STM32F723ZE 上有好几组 I2C 外设，我挑一组空闲的 I2C 和 PJ85718DM 对接。电气上，SCL 和 SDA 都要上拉到 3.3V，近端用 4.7k；如果总线电容大，比如控制器到探头有一段软线，可以改成 2.2k，同时考虑把速率从 400kHz 降到 100kHz。PJ85718DM 的地址通常由 A0/A1 两个引脚的电平组合决定，一块板上挂多个模块时也能靠地址区分。插拔和 ESD 环境要特别注意，地址引脚如果悬空，会随机读到错误地址，导致 I2C 一直 NACK。ALERT 引脚也要处理。PJ85718DM 的 ALERT 输出一般是开漏，需要外部上拉，然后再接到 F723 的一个带中断功能的输入引脚。部分场景如果还需要更直接的保护，可以把 ALERT 信号同时接到硬件安全回路，比如风机控制器的硬关断，这样即使 MCU 卡死，超温也能切断输出。
3.2 软件读取：周期轮询与事件通知的配合
读取温度不用太花哨。我在主程序里维护一个 500ms 的周期任务：每到周期点，发起一次读本地温度、一次读远程温度，换算成浮点温度。如果启用了 ALERT 中断，超温和断线都由硬件拉低打断主程序，主循环只负责响应事件，不在中断里面做 I2C 读取。代码骨架大概长这样：
float pj85_get_temp(uint8_t reg) { uint8_t raw[2] = {0}; i2c_write_reg(PJ85_ADDR, reg); i2c_read(PJ85_ADDR, raw, 2); int16_t val = (int16_t)((raw[0] << 8) | raw[1]); val >>= 3; /* 12-bit 分辨率时保留高 12 位 */ return val * 0.0625f; }注意这只是一个简化示例，实际工程要按编译器和库函数做替换。更稳妥的做法是先读状态字，确认转换完成后再读温度数据，避免拿到上一轮的半旧值。F723 的 SRAM 余量很足，我习惯 I2C 用 DMA 双缓冲接收，把读取和后续滤波解耦，DMA 半满中断和全满中断交替触发，主循环拿到数据后做换算和滤波。这样即使系统里同时跑着 Modbus 和本地界面，温度采样也不会被其他任务卡住。
3.3 滤波策略：为什么远程通道比本地通道更需要低通
温度信号本身是窄带信号，但 HVAC 的风机、压缩机的启停会让读数在真实值附近快速抖动。一味加大移动平均窗长确实能平滑，但会让响应变慢，超温时来不及动作。我这里的做法分两级：先做限幅，再做滑动平均。限幅的意思是，如果新采样比上一个有效值跳变超过 5°C，先不采用，继续观察下一次；连续 3 次都在同一个方向，才认为真的发生了剧烈变化。限幅之后，再用一个长度为 8 的滑动平均或一阶低通滤波。本地通道变化慢，滤波可以温和一点；远程通道往往被拉到远端，容易受线缆干扰，滤波要更重一些。F723 的 Cortex-M7 跑这点浮点运算完全没有压力，开发效率也高，不用像以前在 8 位机上那样到处用整型近似。
3.4 温度值到告警之间，还有一段软硬配合
如果阈值完全放在主控里，好处是现场改参数不用重新固化传感器寄存器；缺点是主控一旦死机，保护逻辑也就没了。如果阈值写在 PJ85718DM 内部，ALERT 引脚就能脱离主控独立工作，硬件动作更可靠。实际项目里我推荐两者结合：传感器内部写一个“绝对安全阈值”和迟滞，专门做硬保护；主控内部再做软件分级告警，用来提示风机转速调节、记录事件、联动上位机。这样既保留了硬件的独立性，又能灵活处理复杂逻辑。
4. 双通道校准：标定模型、实测数据和产线踩坑
4.1 校准环境：先让两个探头处在同一个热场里
校准的原理不复杂：用一个高精度参考温度计或恒温槽，与 PJ85718DM 的本地通道和远程探头放在同一个热场里，等待热平衡后，记录参考值和两个通道的读数。恒温槽不是每个团队都有，简易做法是用保温杯装冰水混合物做 0°C 点，再用 50°C 左右的恒温水浴做第二点。关键是热平衡时间要足够，至少 10 到 15 分钟；还有就是探头不能直接触碰杯壁或加热器，否则读到的不是水温而是局部金属温度。校准前的接线状态也要固定下来，因为后面所有误差都会包含探头线缆的影响。
4.2 两点校斜率和偏移
双通道传感器出厂时通常已经有不错的校准，但系统接好后，由于远端线缆电阻、探头类型差异，再次修正很有必要。常见模型是 real_temp = slope * raw_temp + offset。利用两个标定点，可以解出斜率和偏移。远程通道如果存在明显非线性，再加一个二次项，不过 HVAC 和嵌入式常见的 0°C 到 70°C 范围内，线性模型几乎够用。校准后的系数保存在 F723 的 Flash 非易失区，每次上电加载一次。注意保存时要写 CRC 或双备份页，防止掉电写坏导致整套温度全部偏移。单点补偿不够的原因在于，它只能消除 offset，无法修正增益误差，而两个通道的增益误差来源不同。
4.3 一组实测数据的处理方式
我用一组演示数据来说明算法，实际数值会因为探头和线缆不同而不同。参考温度 0.0°C 时，本地读 0.25°C，远程读 0.40°C；参考温度 50.0°C 时，本地读 50.20°C，远程读 50.80°C。
| 参考温度 | 本地读数 | 远程读数 |
|---|---|---|
| 0.0°C | 0.25°C | 0.40°C |
| 25.0°C | 25.10°C | 25.30°C |
| 50.0°C | 50.20°C | 50.80°C |
单看这些数据都算正常，但远程通道相对参考已经多了大约 0.8°C 的满量程偏移，计算出的斜率约为 (50.8 - 0.4) / (50 - 0) = 1.008。把这个斜率落到每个远程读数里，再算 offset，然后去验证中间点 25°C 的读数，看是否在 ±0.3°C 以内。如果中间点还是偏，先查探头接线和热平衡时间，而不是继续加多项式去硬拟合。硬拟合通常会把噪声也一起拟合进去，换个环境温度就失效。
4.4 产线上最容易翻车的三个细节
第一，校准时机必须在探头的最终连接状态下进行。插拔一次插头，接触电阻变化就可能把刚刚校好的偏移吃掉。第二，远程探头要防静电。测温结本质是个 PN 结，ESD 会把它打坏，症状非常像“读数线性但整体偏得离谱”，容易被误判成软件问题。第三，本地和远程通道要分开校，不要图省事只调一个 offset 用在两个通道上，因为两者的误差来源完全不同，远程误差更多来自线缆和探头工艺，本地误差更多来自 PCB 热传导和芯片自身。
5. ALERT 信号与超温保护：把“测温”变成“动作”
5.1 ALERT 的两种模式：比较器模式与中断模式
PJ85718DM 的 ALERT 引脚通常可以工作在比较器模式：温度超过阈值就拉低，回落到阈值以下自动释放；也可以工作在中断模式：一旦触发就锁存，必须读状态寄存器或写配置位才能恢复。比较器模式适合做硬件层面的直接保护，比如超温就切断继电器，不需要主控持续在线；中断模式适合做事件型通知，由主控决定后续处理。在 HVAC 控制器里，我一般把防冻报警配置成比较器模式，因为即使 CPU 重启，安全输出也要保持；把用于调试的温度上下限做成中断模式，方便上位机记录变化事件。
5.2 通过状态寄存器区分开路、短路和真实超温
双通道传感器的状态寄存器里通常有远程故障标志。读数表现上，远程通道开路时通常读到全 1 或接近满量程，短路时可能读到接近 0 或全 0；而真实超温的数值是有界且已知的，可以和故障标志区分开。排查时一定要先读状态再读数据，因为如果远端故障标志已经置位，温度数据本身就不可信，直接拿去做阈值判断没有意义。我自己的经验是：任何用到远程通道的告警逻辑，都必须把“数据无效”当成独立分支处理，然后输出默认安全动作。嵌入式里传感器掉线时，强制把输出降到安全档位，比继续维持大电流更稳妥。
5.3 保护动作的状态机设计
温度保护真正难的不是单个阈值，而是阈值附近的抖动。我用一个四态状态机来管理：正常、预警、跳闸、故障。正常状态里，只要本地或远程连续 3 次采样超过预警阈值，就进入预警，提醒上位机但不停机；预警持续超过 10 秒仍高，再进入跳闸，执行硬保护动作。无论哪个状态，只要状态寄存器报告远程通道故障，就立刻跳到故障状态，按预设安全输出处理。跳闸之后不能马上回到正常，要等温度回落到恢复阈值以下，并保持 30 秒以上再复位。迟滞可以分两处配：硬件阈值寄存器配 1°C 左右的迟滞，软件状态机再做连续次数确认，双保险之后误动作的概率会低很多。
6. 现场调试最容易栽的四个坑：从跳变到误中断
6.1 远程温度上下乱跳：先看接线和转换周期，别急着加滤波
现象是远程读数在正常范围附近无规律跳 2°C 到 5°C，本地通道一切正常。这个问题的定位顺序很关键：先读原始未滤波的数据，因为软件滤波后的数值已经把跳变细节抹掉了。然后检查探头引线是否过长、屏蔽层是否单端接地、转换周期是不是过快。常见解决办法是把 I2C 速率和转换周期降下来，给远端探头加一组小阻值串联电阻和并联电容，组成低通。只调软件移动平均是下策，因为移动平均会同时拖慢真实温度变化的响应，超温时容易出现误判或漏判。
6.2 读数恒定变成 0xFF 或 -64：多半是探头开短路
如果远程通道读到全 1、全 0 或者某个固定饱和值，状态寄存器又同时给出了故障标志，优先怀疑探头开路或短路，而不是 I2C 时序问题。可以先换一个已知良好的探头做交叉验证，看读数是否恢复正常。如果换探头就能正常，基本可以判定原探头内部的测温结已经损坏，这时候不要反复调软件，直接去查探头的 ESD 防护和机械固定。有些现场人员的习惯是把探头从端子排上拆下来再插回去，反复插拔最容易损伤引脚，特别是冬天干燥环境下静电风险更高。
6.3 ALERT 反复触发：阈值和迟滞没配合好
有个常见误配是只设了报警阈值，没有设恢复阈值或迟滞。当实际温度在阈值边缘来回抖时，ALERT 就会被反复拉低。解决方法是把迟滞调到至少 1°C，同时在软件里记录持续超温次数。另一个隐蔽问题是清中断方式不对。中断模式下，有些芯片必须写指定的状态位或者先读再写，乱清会导致 ALERT 一直保持拉低状态，看起来像“某条线路对地短路”。处理这类问题前，先读一遍传感器手册里关于状态寄存器清位的说明，再用示波器看 ALERT 引脚波形，基本能确认是电气问题还是软件配置问题。
6.4 通用排查顺序清单
我把现场排查顺序固定成一份清单，遇到温度相关异常就按这个顺序走一遍。第一，确认 I2C 地址和上拉电平正常；第二，读状态寄存器，看有没有故障位；第三，读原始温度字节，并做位宽换算；第四，对比本地和远程通道的读数趋势，判断是单通道问题还是公共电源问题；第五，检查滤波后的曲线，确认是不是把真实波动滤掉了；最后再动硬件参数，比如转换周期、滤波器、上拉电阻。按这个顺序走下来，大部分问题的原因都能在两三个小时内定位，比凭感觉换探头和改软件可靠得多。
