嵌入式温度监测实战：PJ85718DM+STM32F723IE双通道测温方案-开发者社区

做嵌入式温度监测这些年，我用过热电偶、NTC 热敏电阻、各种数字温度传感器，也踩了不少坑。直到后来在一套 HVAC 控制器项目里用了 PJ85718DM 这类“本地+远程”双通道温度传感器，配合 STM32F723IE 做主控，才真正体会到什么叫把测温做成一件省心的事。这套方案能同时测量控制器板卡自身的温度（本地）和远端探头的温度（远程），远程测温不需要总线协议，而是通过一对导线连接一个外部 PN 结，靠测量压降反推温度，探头可以拉出去好几米甚至上十米，非常适合设备和传感器物理分离的场景。

如果你正在做嵌入式控制器、暖通空调（HVAC）电控、或者工业设备监控，这篇文章值得看完。特别是远程探头读数老是偏高、读数跳变、I2C 通信偶发失败这些问题，下面都会有对应的排查思路和实战经验。文章会按照方案拆解、硬件电路、软件实现、工程落地、问题排查的顺序展开，全程按一个真实项目的推进方式来讲。

1. 方案拆解：为什么要把本地和远程温度放在一颗芯片里

1.1 嵌入式测温的三个痛点与对应解法

嵌入式设备测温，最麻烦的往往不是写驱动代码，而是测温点根本不止一个。一块主控板自身需要过热保护，被控设备——比如压缩机的排气口、蒸发器的盘管、送回风管道——又离主控有一段物理距离。如果每个测温点都单独接一个传感器、单独占一路 ADC，BOM 成本、PCB 面积和现场接线工作量会同时飙升。

NTC 热敏电阻虽然便宜，但一致性是个大问题。以常见的 10k NTC 为例，在 0~70°C 范围内的个体分散度，批量生产时往往需要逐台校准，而校准的人工和时间成本经常比器件本身还贵。热电偶能测高温，但要冷端补偿、要信号调理放大，对 HVAC 这种精度要求没那么极端、但要求长期稳定可靠的场合来说，性价比并不划算。

单点数字温度传感器（I2C 接口那种）倒是方便，但只能测自己所在位置的温度，没法同时去盯远端。真的想在远端测温，无非两条路：要么在远端也放一颗完整的传感器芯片，要么把传感元件和应用电路分离。PJ85718DM 这类器件选的正是第二条路：芯片内部有一个本地测温单元，同时留出一个远程通道，专门接外部 PN 结。

远程测温的原理说穿了并不神秘：PN 结的正向压降 Vbe 和温度近似线性关系，温度每升高 1°C，压降大约下降 2mV。芯片通过内部电流源激励这个外部 PN 结，再测量其压降，就能反推出温度。于是远端传感元件只需要一颗二极管，或者一颗三极管的 BE 结，甚至可以借用某些 CPU、GPU 芯片内部自带的测温二极管。这样做的好处是探头部分极便宜、无源、不需要独立供电，线缆可以拉得很长，而且 PN 结的 Vbe 一致性远好于普通 NTC。

这恰好正中 HVAC 场景的痛点。一台中央空调外机，主控板在电控盒里，但吸气温度、排气温度、盘管温度散布在好几个物理位置。用这个方案，主控板上放一颗 PJ85718DM，每个远端点挂一个二极管或三极管探头，一条 I2C 总线就能全部覆盖，而且远程部分不怕长线衰减——因为线缆上传的是电压信号，不是电阻值。

1.2 STM32F723IE 凭什么当 HVAC 主控

传感器只是前端，主控芯片的选择同样关键。STM32F723IE 属于 Cortex-M7 家族，主频 216MHz，带双精度硬件浮点单元，1MB Flash、256KB RAM。在 HVAC 控制器里，这点算力不仅用来读温度，还要同时跑温控 PID、风机调速、压缩机启停保护逻辑，以及可能存在的 Modbus 从站协议或以太网网关转发。M7 的浮点能力在处理温度换算、滤波、PID 计算时绰绰有余，完全不会成为性能瓶颈。

选它还有几个更实际的原因。第一，PJ85718DM 这类传感器走 I2C 且兼容 SMBus 时序，F723 的 I2C 外设跑 100k/400k 毫无压力，引脚分配也很灵活。第二，F723 自带以太网 MAC、CAN、多个 USART 接口，方便后续把温度数据送到楼宇自控系统（BMS）或工厂数据平台，做远程运维。第三，1MB Flash 足够同时放下固件和一段温度运行曲线记录，方便故障回溯。第四，整个工具链和生态非常成熟，CubeMX 配好引脚后 HAL 库直接生成初始化代码，迭代效率很高。

当然，如果项目只做纯测温，一颗几块钱的 M0 单片机也够用。但 HVAC 控制器的本质是“控制”，不是“采集”，温度只是控制逻辑的输入之一。用 F723 是把采集、控制、通信三项能力放进同一颗芯片，省掉一颗独立的通信 MCU，从整板成本看反而更划算。

我个人选型的习惯是，先看外设能不能覆盖未来三五年的扩展需求，再看性能和价格。F723 在网络化和边缘计算方面的余量，让这套方案在后续升级（比如加云连接、加数据诊断）时不需要换主控，这一点在项目周期长的工控行业里尤其重要。

2. 硬件电路设计：传感器接口与远程探头布局

2.1 PJ85718DM 外围电路与 I2C 连接

PJ85718DM 的典型工作电压是 3.3V，接口是 I2C/SMBus 兼容的两线制。引脚不多，但有两个引脚需要特别重视：远程温度正输入和负输入，也就是接外部 PN 结的两个引脚。按这类器件的典型用法，外围电路基本就是四块：

电源去耦：VCC 对地接一个 0.1uF 陶瓷电容，尽量靠近电源引脚。数字芯片全速转换时电流变化快，去耦电容离引脚越近效果越好。
I2C 上拉：SCL、SDA 是开漏输出，必须外部上拉。总线速率 100~400kbps 时，典型取 4.7kΩ；如果总线长度大、负载重，可以降到 2.2kΩ。
地址配置：A0/A1 引脚接 GND 或 VCC，可以配置出多个不同地址。板子上如果有多个测温点，可以直接挂多颗传感器，共享同一条 I2C 总线。
ALERT 报警输出：开漏输出，接上拉电阻后连 STM32 的 EXTI 外部中断引脚。温度越限时芯片自动拉低，MCU 不用轮询也能实时感知异常。

这里要提醒一个画板时容易犯的错：VCC 上不能只放一个大电解电容而漏掉高频去耦电容。电解电容等效串联电阻大，高频特性差，I2C 翻转时会在电源线上产生明显毛刺，可能被误判为总线上多出数据。正确做法是“大电解 + 0.1uF 陶瓷”组合，电解电容放电源入口，陶瓷电容紧贴芯片电源引脚。

关于去耦电容的数量，如果 PCB 空间允许，我还会在传感器旁边再放一个 0.01uF 的电容专门滤高频。别小看这颗小电容，它能把远程测温通道的参考电压噪声压下去，间接改善温度读数的稳定性。这是我在多次对比测试后发现的一个经验，常规开发文档里很少会写。

2.2 远程探头的正确接法与走线规范

远程通道是整个方案里技术含量最高的地方，也是翻车重灾区。先把结论放前面：远程 PN 结用三极管的 BE 结，比用普通二极管稳定得多，因为三极管 BE 结的 Vbe 一致性更好，批量生产时读数更整齐。具体接法是把三极管的基极和集电极短路，当成二极管用，然后按器件手册标注的正负极性接到 D+ 和 D- 上。不同芯片对极性的定义可能相反，接之前一定要看手册，原则就一条：让 PN 结正向导通，电流能按芯片预期的方向流过去。

探头封装在 HVAC 现场很有讲究。最简单的做法是：三极管用热缩管包好，塞进不锈钢套管里，管内填充导热硅脂，引出三根线，用环氧树脂封口。工业上也可以直接买现成的“二极管温度探头”，本质一样，只是外壳和线缆做了更好的耐候处理。

走线方面有三个要点，每个都是踩过坑换来的：

尽量使用双绞屏蔽线，屏蔽层在控制器端单端接地，不要两端都接地。两端接地很容易形成地环路，反而把共模噪声引入测量回路。
探头线要远离压缩机、风机等功率线，尤其不能平行长距离走线。如果现场条件限制必须走同一线槽，至少要用屏蔽层隔开，并且让信号线贴着线槽壁，不要和动力线捆在一起。
D+ 和 D- 之间不要乱加滤波电容。远程测温本质上是芯片输出周期性电流脉冲、测量 PN 结压降，如果在两端并联大电容，电流脉冲的建立时间会被拉长，芯片在没有充分建立时就去采样，结果必然偏移。按我的实测经验，电容超过几百 pF 就开始出问题。

线缆的串联电阻同样影响读数：线阻越大，等效压降越大，读出来的温度会偏高。如果探头线拉到十来米，建议采用三线制接法：远程端用三根线，一根公共线，两根分别接 D+ 和 D-，芯片利用不同电流下的测量差值做线阻补偿。我的习惯是只要走线超过 3 米就上三线制，省得后面因批次换线而重新标定。

2.3 与 STM32F723IE 的完整接线梳理

整体连接关系不复杂，列出来就是：

SCL、SDA：接到 STM32F723IE 的 I2C 引脚，比如 I2C1 的 PB6/PB7，或者 I2C2 的 PB10/PB11，具体用 CubeMX 按引脚冲突情况分配。
每个 I2C 通道的 SCL、SDA 各接一个上拉电阻到 3.3V。
ALERT：接到一个支持外部中断的 GPIO，配置为下降沿触发。
A0/A1：按实际挂载颗数配置地址，多颗并联时确保地址不冲突。

一个容易忽略的细节：如果系统的 3.3V 由 LDO 供电，而 LDO 输入侧纹波偏大，I2C 上拉电阻建议接到 MCU 的 VDD 网络，而不是直接接到传感器的 VCC 引脚。虽然大多数情况下两者同源，但传感器内部转换时会产生电源电流波动，如果上拉正好接了这一段电源，总线上就可能看到毛刺，严重时读到偶发错误数据。

关于 I2C 速率，我强烈建议调试阶段先跑 100kHz，跑通后再提到 400kHz。温度数据更新频率本来就不高，每秒读十次已经是奢侈了，完全没有必要追求高速。我见过有人上来就配 400kHz，结果现场线缆一长，偶发超时，排查一圈才发现是速率问题。

3. 软件实现：驱动、滤波与阈值管理

3.1 寄存器布局与驱动初始化

软硬件接口这里，先说明一下寄存器的大致布局。不同厂家的远程温度芯片寄存器定义差异不大，我按最常见的一种布局来写，具体地址还是要以你手里的器件手册为准，但思路完全可以直接照搬。

典型寄存器包括：

本地温度数据寄存器：存放芯片自身温度
远程温度数据寄存器：存放远端 PN 结温度
本地/远程上限寄存器、下限寄存器：分别设置每个通道的报警阈值
配置寄存器：控制转换模式、报警极性、分辨率
状态寄存器：标志当前有没有报警、远程传感器是否开路或短路

使用 STM32 HAL 库初始化的代码大概长这样：

#define TEMP_SENSOR_ADDR 0x48 // A0/A1 接地时的典型地址，实际以手册为准 #define REG_CONFIG 0x08 #define REG_REMOTE_TEMP 0x01 static void temp_sensor_init(void) { uint8_t cfg = 0x00; // 默认连续转换模式，正常报警极性 HAL_I2C_Mem_Write(&hi2c1, TEMP_SENSOR_ADDR << 1, REG_CONFIG, I2C_MEMADD_SIZE_8BIT, &cfg, 1, 50); }

这段代码虽然只有一次写配置，但实际项目里我坚持在写配置之前先读一次器件 ID 或状态寄存器，确认器件在位。这样做的好处是能提前发现地址冲突和虚焊问题。曾经有一批板子 I2C 上挂了多颗传感器，有一颗地址配重了，读回来的数据来源混乱，排查半天，最后就是靠逐个读 ID 才定位到的。

3.2 原始数据处理、换算与软件滤波

读温度数据的核心代码如下：

static int16_t temp_sensor_read(uint8_t reg) { uint8_t buf[2]; int16_t raw; HAL_I2C_Mem_Read(&hi2c1, TEMP_SENSOR_ADDR << 1, reg, I2C_MEMADD_SIZE_8BIT, buf, 2, 50); raw = (buf[0] << 8) | buf[1]; raw >>= 4; // 去掉低位的扩展位 if (raw & 0x0800) // 12位有符号数做符号扩展 raw |= 0xF000; return raw; }

温度值就是 raw 乘以 0.125。为什么是 0.125？因为这类芯片常见的分辨率就是 0.125°C，也就是 12 位数据里去掉低 4 位后，剩下 11 位，最高位是符号位，其余位表示温度，正好对应 0.125°C 的粒度。如果配置寄存器里设置了更高分辨率，比如 0.0625°C，那换算系数要跟着改。

换算成摄氏度之后，我强烈建议加一层软件滤波。原因很直接：HVAC 现场电磁环境不干净，温度又是变化很慢的量，不做滤波会看到读数在稳定值附近抖动，用户第一反应就是这设备不准。我用过两种滤波，各有适用场景。

滑动平均：维护一个长度为 N 的环形队列，每次把新值放进去，取平均值。N 取 8 到 16 效果都不错。优点是波形平滑、物理意义直白，跟同事解释“我们拿最近 10 秒的数据做平均”对方很容易接受。

一阶低通：y[n] = y[n-1] + alpha * (x[n] - y[n-1])，alpha 取 0.1~0.3。代码更短，不需要环形队列缓冲，调参时 alpha 越大响应越快、滤波越弱，alpha 越小越平滑但滞后越明显。

我个人偏向滑动平均，因为它在现场调试时语义清晰。但要注意别在滤波上用力过猛。温度变化本身就不快，如果滤波深度太大，会把真实温升趋势拖没，导致 PID 和保护逻辑反应迟钝。我有一次试过 N=64 的滑动平均，结果压缩机保护动作慢了半拍，后来老实改回 16。

3.3 阈值报警与 ALERT 中断机制

温度监测如果没有报警机制，价值就少了一半。这类传感器通常支持把阈值直接写进寄存器，让芯片硬件自己判断，越限就拉低 ALERT 引脚。相比让 MCU 每个周期比较一次数据，硬件比较的实时性和可靠性更好，也更省电。

配置步骤可以这样走：

把本地/远程的上限、下限写入对应寄存器。
配置报警模式：超过上限或者低于下限都触发报警。
使能 ALERT 输出，设置极性为低有效。
在 STM32 里把 ALERT 引脚配置成下降沿触发的外部中断，中断服务程序只置一个标志位。

主循环发现标志位被置位后，再读状态寄存器，确认到底是哪个通道越限、是上限还是下限、有没有远程开路或短路，然后做对应处理，最后写状态寄存器清除标志。

这里有一个特别重要的坑：不要在中断服务程序里直接调用 HAL_I2C_Mem_Read。HAL 的 I2C 阻塞接口有可能等待总线，在中断里等总线非常危险，轻则拉长中断响应时间，重则死锁。正确做法是中断里只置标志，把 I2C 读操作放到主循环或低优先级任务里做。我踩过这个坑，花了一个晚上排查系统为什么每隔几分钟卡死一次，最后发现就是中断里的 I2C 访问在抢总线导致的。

void EXTI9_5_IRQHandler(void) { if (__HAL_GPIO_EXTI_GET_FLAG(ALERT_PIN) != RESET) { __HAL_GPIO_EXTI_CLEAR_FLAG(ALERT_PIN); g_temp_alert_flag = 1; // 只置标志，不在中断里读 I2C } }

4. HVAC 场景落地：从主控板到远端探头的完整链路

4.1 本地通道：主控板温与风扇联动

在 HVAC 控制器里，本地温度通道测的是电控盒内部温度。电控盒里的发热器件不少：功率管、继电器排、开关电源、变压器，温度高了对器件寿命有直接影响，甚至触发保护。用本地通道读取温度，可以做一个简单可靠的风扇联动逻辑：

if (local_temp > 55.0f) fan_ctrl(ON); if (local_temp < 45.0f) fan_ctrl(OFF);

阈值加滞回，避免风扇在临界温度附近反复启停。这个逻辑虽然简单，但在实际项目里非常实用。除了高温保护，低温场景也要考虑。如果设备在低温环境下启动，本地温度过低时可能需要控制加热带，防止冷凝水和润滑油黏稠影响设备运行。这是本地通道的另一个价值：它不只是提供一个温度值，还反映设备运行环境是否正常。

实测中我发现，电控盒内的温升曲线和散热风道设计高度相关。最好在结构定型前，把传感器放在几个候选位置各测一轮，选一个既能代表最热器件、又不被风直吹的点。PJ85718DM 这类器件封装小，可以直接贴装在 PCB 上靠近热源的位置，比把传感器放外壳上测环境温度更能反映器件实际工况。

4.2 远程通道：风管、盘管与排气温度测量

远程探头在 HVAC 里的部署位置，最有代表性的有四个：回风管温度，用于温控 PID 的反馈；送风管温度，用于判断制冷或制热效果；蒸发器或冷凝器盘管温度，用于除霜控制、过热度计算；压缩机排气温度，用于高压保护。

不同位置的安装方式有差别。风管温度探头直接插入风管，插入深度建议到管道中心附近，不要贴着管壁，因为靠近管壁的气流处于边界层，温度代表性差。盘管温度探头一般卡在铜管弯头处，用金属卡簧固定，外面再包一层保温棉，确保测的是管壁温度而不是环境温度。压缩机排气温度要求探头耐高温，PN 结探头如果封装不到位，长期高温下会漂移，这时候要选工业级探头，或者干脆在排气口使用热电偶方案。

远程通道的多探头扩展是这套方案的加分项。一颗 PJ85718DM 虽然有远程通道，但通常只有一个远端通道。如果板子上放多颗，每颗接一个探头，主控就能同时看到多个测温点。这也是当初选 I2C 地址可配置的意义：总线能挂多颗，不用为了增加一个测温点去换主控、加 ADC。

4.3 数据上报与控制联动逻辑

读到的温度数据最终要产生价值，要么给控制逻辑用，要么给人看。在 HVAC 项目里，两者通常都要。

给控制逻辑用，最常见的是温控 PID。F723 上的代码组织大致是这样：

float pid_update(float setpoint, float feedback) { float error = setpoint - feedback; integral += error * dt; derivative = (error - last_error) / dt; output = kp * error + ki * integral + kd * derivative; last_error = error; return output; }

M7 的双精度 FPU 跑这种计算只占极小比例的 CPU，温控周期哪怕做到 100ms 一次，也完全不影响其他任务。

给系统间通信用，通常走 RS485 Modbus 或以太网。F723 的 USART 和以太网 MAC 都是现成的。Modbus 保持寄存器里，把本地温度、远程温度、报警状态放到固定地址，上位机直接读就行。如果对接的是云平台，可以在 F723 上跑一个轻量的 MQTT 客户端，定时上报温度数据，顺便把设备告警事件发出去。

我在实际项目里的分工是：传感器中断负责“紧急保护”，主循环负责“常规控制”，空闲时间处理“通信上报”。这样温度数据的采集、控制、上报三级解耦，任何一个环节出问题都不会拖垮整个系统。

5. 实测问题与排查技巧实录

5.1 最常见的故障：远程读数整体偏高

远程读数比实际值高出几度，是远程测温方案里遇到最多的故障。原因大概率出在下边三个地方：

第一是线阻太大。远程通道测的是 PN 结压降，线缆电阻会叠加进测量回路，表现为读数偏高。排查时先量一下 D+ 到 D- 回路的总电阻，如果超过 10Ω，就该考虑换更粗的导线、缩短线缆长度，或者启用三线制补偿。

第二是 D+、D- 之间并了过大的电容。前面反复强调过，远程测温是电流脉冲激励，并联电容会让建立时间拉长，芯片在未充分建立时采样，读数就会偏移。我在一个项目里为了抗干扰，在 D+ 和 D- 之间并了 1nF 电容，结果读数整体偏高近 3°C，去掉电容后立刻恢复。后来我改成在探头端加一个几十皮法的小电容，同时用屏蔽线，效果更好。

第三是供电电压偏低。芯片 VCC 如果接近下限，内部参考电压可能偏移，导致转换结果系统性偏移。排查时直接量 VCC 电压，再和手册比对。这类问题往往发生在板卡上有大电流负载、电源瞬间跌落的时候。

5.2 读数跳变与偶发错误

读数跳变比整体偏高更让人头疼，因为它是间歇性的。常见诱因有三个：

探头接线端子氧化或松动，接触电阻时大时小，读数自然跟着跳。工业现场振动大，端子压接不牢的情况尤其常见。排查方式是关机后逐个端子重新压接，顺便检查有没有氧化发黑。

电磁干扰。压缩机启动瞬间、变频器开关瞬间，噪声都可能耦合进探头线。处理办法是屏蔽层单端接地、探头线远离功率线、必要时在软件里加三重采样一致性校验。

传感器状态寄存器已经报了开路或短路，但软件没有及时处理，读回来的数据是无效值。很多远程温度芯片在探头开路时会返回一个特征值，比如 0xFF 或某个极端值，如果软件不做状态判断直接拿来用，就会看到“跳变”的假象。

软件层面的对策，我对远程温度连续读三次，三次之间偏差超过 1°C 就不采信，标记为无效；连续多次无效后，直接报“探头异常”。这个三重采样校验实现简单，效果却很好，已经在多个项目里帮我挡住了不少干扰。

5.3 I2C 通信失败与地址冲突

I2C 总线长度超过 30cm 时，偶发失败的概率会显著上升。现象是读回来的数据偶尔是 0xFF，或者 HAL 接口超时。解决优先级很明确：

第一步，降低总线速率，从 400kHz 降到 100kHz，经常立竿见影。第二步，减小上拉电阻，从 4.7k 换成 2.2k，提升总线驱动能力。第三步，缩短总线走线长度，实在没法缩短，就把传感器分散到不同的 I2C 总线上。第四步，检查 SDA 和 SCL 之间有没有串扰，用示波器看波形边沿有没有振铃，必要时在信号线上串联一个几十欧姆的电阻抑制振铃。

另一个容易被忽略的问题是地址冲突。如果板子上挂了多颗传感器，A0/A1 配置重复，从机地址就会冲突，读回来的数据可能来自错误的芯片。排查办法是逐个读每颗传感器的 ID，确认地址唯一。这里还有个小技巧：给每颗传感器预留独立的地址配置引脚，不要图省事全部焊死到同一电平，否则后期想改地址就得动烙铁。

为了让大家排查时有对照，我整理了一张速查表：

现象	可能原因	排查手段	解决方案
远程读数偏高 2~5°C	线缆电阻大 / D+、D-并联电容大	万用表量线阻，查看板端电容	换粗线、改三线制、去掉大电容
远程读数跳变	端子接触不良 / 电磁干扰	看状态寄存器、示波器查波形	紧固端子、屏蔽层单端接地、软件三重采样
I2C 偶发超时	总线太长或上拉过大	示波器看波形边沿	降到 100k、上拉改成 2.2k
本地温度固定偏差	供电电压偏低 / 芯片参考偏差	实测 VCC，比对手册	软件校准偏移量或改善供电
远程读数恒定异常值	探头开路或短路	读状态寄存器确认	检查接线，更换探头

6. 收尾：三个容易忽略的工程细节

6.1 探头封装与一致性控制

先说探头封装的成本：一颗几毛钱的三极管，加上热缩管和不锈钢套管，就是一套能用的远程探头。批量生产时，封装一致性要盯紧，尤其是导热硅脂的涂覆量和套管压接方式，这两点直接影响长期稳定性。硅脂涂少了，探头和套管之间有空气层，热传导变差，温度响应慢；涂多了，封装过程麻烦，还容易污染引线。如果产品要过振动测试，套管和引线之间最好加一个应力释放结构，否则现场振动几个月后，引线根部容易断裂。

另外，我吃过亏的地方是探头线选型。千万不要为了省成本用普通电子线的替代屏蔽线。普通线在湿度大的环境里，绝缘电阻下降，远程测温通道的微弱电流会泄漏，读数会慢慢漂移。工业设备常年运行，线缆防潮比什么都重要。