做嵌入式或者暖通空调（HVAC）项目的朋友，应该都有过这种体会：产品功能看着简单，就是测个温度，但真正要拿到稳定、可信、能在现场扛得住干扰的温度数据，一点都不轻松。我最近在一个模拟项目X里，用 PJ85718DM 这颗本地/远程双通道温度传感器配合 STM32F767ZG 做主控，把嵌入式和 HVAC 场景里最常见的两类温度——板级环境温度和远端关键点温度——同时采了起来，并且做了本地显示、告警和远程上报。这套方案不算稀奇，但把硬件、驱动、标定和现场调试串起来讲一遍，对刚接触温度采集或者想把测温做到更好的朋友来说，应该能省不少试错时间。

PJ85718DM 这类芯片最大的特点是“一颗芯片、两个测温点”：一个通道测它自己所在 PCB 附近的环境温度，另一个通道通过外部二极管测温点去测比较远的热源温度。配合 STM32F767ZG 这颗主控，测温、滤波、告警、显示、Modbus 上报都能在一颗 MCU 上跑完，系统不臃肿，后期也好维护。

1. 项目定位：为什么要把“本地温度”和“远程温度”分开测

1.1 标题拆解：这里的“本地/远程”不是网络概念

很多人第一次看到“本地与远程温度”，容易理解成“现场温度”和“云端温度”，其实在这个项目里完全是另一回事。PJ85718DM 说的“本地”，是传感器芯片自身所在位置的环境温度，一般就代表控制板板卡附近的温度；“远程”，则是指通过芯片上的 D+/D- 引脚，外接一个二极管测温点，去测离传感器有一定距离的热源温度。

打个比方：传感器芯片像是一个“温度管家”，它自己站在门口看室内气温，同时又拉了根细线把触角伸到锅炉房去看炉壁温度。两个读数都能从同一个 I2C 总线上读出来，硬件上省事，软件上也统一。

这种设计对嵌入式设备和 HVAC 设备都特别合适。嵌入式设备里，主控 CPU、功率电感、大功率 MOS 发热严重，但测温点不一定都在主控板附近；HVAC 设备里，控制器可能装在空调箱的面板上，但真正需要监测的却是深处几米开外的盘管温度、压缩机排气温度或者电机绕组温度。一颗芯片兼顾两个测量点，正好解决这个问题。

1.2 典型应用场景：嵌入式与 HVAC 各取所需

先说嵌入式。我做过的板卡里，最常见的事情就是“开机正常，跑一会儿发现有些器件烫手”。以前大家的做法是板子上布几路 NTC 热敏电阻，每一路都要走 ADC 采样、分压电阻、查表标定，麻烦不说，NTC 的一致性也让人头疼。换成 PJ85718DM 这种双通道方案之后，本地通道直接测板卡环境温度，远程通道可以贴到功率器件表面固定一个测温二极管，两个点都是数字量输出，精度和一致性比 NTC 电路从原理上就稳一截。

再说 HVAC。机房空调、风机盘管、组合式空调箱这类设备，通常需要测进出风温度、盘管防冻温度、压缩机吸排气温度。这些点位分散在设备各处，走线往往超过一米甚至几米。传统 NTC 长线会引入引线电阻误差，线缆经过变频器、接触器附近时又容易耦合干扰。PJ85718DM 的远程二极管通道对串联电阻相对不那么敏感，配合双绞屏蔽线和滤波电容，可以拉到比较远的距离。我实测在中等电磁干扰环境下，三到五米距离内读数依旧能保持稳定。

1.3 为什么选了 STM32F767ZG 和 PJ85718DM 这套组合

选 STM32F767ZG 首先是因为它资源确实够。Cortex-M7 内核跑到 216MHz，Flash 容量大、SRAM 也充足，跑温度采集这种轻任务绰绰有余，剩下的资源还能跑显示、通信、甚至 PID 控制算法。外设上更省心：多路 I2C 可以单独拿一路给温度传感器、一路给 OLED；多路 USART 可以做 RS485 Modbus 上报；自带以太网 MAC，外接一颗 PHY 就能走网络上报；FMC 接口以后想升级 TFT 触摸屏也留了路。对一套要长期迭代的 HVAC 控制器来说，这个选型不会两三年就撞到资源天花板。

PJ85718DM 的选型逻辑也很直接：一颗芯片覆盖本地和远程两个测温点，I2C 接口，宽温度范围，本地典型精度能做到 ±0.5℃ 左右，远程通道在做好标定后也能控制在 ±1℃ 以内，还带 ALERT/THERM 可编程阈值告警引脚。这些特性几乎就是为“嵌入式板级测温 + HVAC 远端测温”这类需求量身定做的。实际项目里，你不需要在 MCU 里做复杂的模拟前端，传感器自己负责测量和初步判断，软件逻辑就能做得非常干净。

注意：芯片的具体寄存器偏移量和精度参数，不同批次、不同封装可能有差异，下文凡是涉及寄存器地址的地方，都以你手里的 PJ85718DM 数据手册为准，我给出的值是实现时常用的基址框架。

2. 硬件设计与连接要点

2.1 最小系统与传感器 I2C 接口

先说供电。STM32F767ZG 和 PJ85718DM 都用 3.3V 供电，我从板子的主 3.3V 电源轨直接给传感器供电，但传感器电源引脚旁边必须加去耦电容。我习惯的做法是 10µF 钽电容并联一个 0.1µF 陶瓷电容，就近放在传感器电源引脚附近。这个细节很容易被忽略，去耦没做好，温度读数的跳动会非常奇怪，而且不容易排查。

I2C 总线我用了 I2C1，引脚是 PB6/SCL、PB7/SDA，配置成 400kHz 快速模式。两条线各自接一个 4.7kΩ 上拉电阻到 3.3V。上拉电阻这个值不需要太纠结，短走线用 4.7k 很稳，走线长了改成 2.2k 也行。电阻太大总线沿变慢，太小灌电流偏大，4.7k 是工程上最不容易出问题的起点。

传感器地址通过 A0、A1 引脚选择。A0 和 A1 都接地时，7 位地址通常是 0x48；A0 接 3.3V、A1 接地，地址就变成 0x49。在 STM32 的 HAL 库里，发送地址时要左移一位，也就是(0x48 << 1)。如果以后想要一条 I2C 总线上挂多片传感器，可以靠 A0/A1 区分，一个总线上最多挂四片。

ALERT 引脚值得单独说。它是开漏输出，所以必须接上拉电阻，我在板上用了 10kΩ 上拉到 3.3V，同时接到 STM32 的 PB4 引脚并配置成外部中断输入。温度超过上限、低于下限，或者远端测温点断开时，ALERT 都会拉低触发中断，MCU 只需要在中断里去读状态寄存器判断具体原因。这样不用轮询温度值也能第一时间感知异常。

引脚分配我放在下表里，方便直接照着画板：

2.2 远端测温通道的接线、滤波与防错

远程测温是这套方案里最需要花心思的地方。PJ85718DM 的 D+/D- 引脚需要外接一个二极管测温点。工程上最常用的做法不是用普通二极管，而是用 NPN 三极管把集电极和基极短接在一起，形成“二极管接法”，然后基极/集电极接 D+，发射极接 D-。很多通用型号的三极管都行，比如常见的 2N3904。

为什么不用普通二极管？因为芯片测量远端温度时，依靠的是晶体管基极-发射极结压降 VBE 随温度变化的特性，激励电流的设定、电压-温度曲线都是按晶体管的 VBE 特性设计的。普通开关二极管的伏安特性曲线和晶体管的 VBE 曲线有明显差异，直接代换轻则偏一两度，重则完全不能用。

接线方面，我的经验是：远端线缆必须用双绞屏蔽线，屏蔽层单端接地，并且尽量避开继电器、接触器、变频器的动力线缆。如果现场布线实在避免不了交叉，也要尽量让信号线以 90 度角跨越动力线，不能平行走线。

滤波网络的参数也要控制好。靠近传感器端，我习惯在 D+ 和 D- 上各串一个 22Ω 到 100Ω 的电阻，再在靠近芯片端并联一个 2.2nF 到 10nF 的电容。但要注意，远程测温通道的并联电容不能随意加大，因为芯片测量时会对远端结施加周期性激励电流，电容太大，激励电流的建立时间不够，反而会把测量搞乱。总电容要控制在数据手册规定的范围内。

一个很容易犯的错是：远端二极管线路距离长，串联电阻大，如果数据手册允许，可以通过校准把这部分误差抵消掉。但绝对不能为了省事把整个系统的基础精度寄希望于“应该没多大影响”。我习惯的做法是先测出远端回路的实际串联电阻，然后用两点标定做整体补偿，后面软件部分会细说。

2.3 HVAC 工业现场的抗干扰处理

实验室里跑的好好的，拿到现场就出现读数乱跳甚至 MCU 复位，这是 HVAC 项目最经典的坑。根子大多在变频器、接触器、继电器启停造成的强电磁瞬变。我在这个项目里做了三件事：

第一，信号线隔离。传感器远端线和 RS485 通信线都不跟动力线走同一个线槽，RS485 端加隔离收发器，数字量输入输出全部走光耦，电源端加 TVS 管和续流二极管。这些动作看着增加成本，但现场调试点少一次，价值就回来了。

第二，地线处理。控制板的地要和被控设备的大电流地严格区分，最好采用星型单点接地，避免形成地环路。地环路是很多“一到现场就飘”问题的元凶，示波器接上去看都是几十伏甚至上百伏的尖峰，不处理电路再稳定也没用。

第三，给 MCU 做防护。STM32F767ZG 的系统电源入口加 TVS，复位芯片要选工业级的，硬件看门狗也必须留。在 HVAC 现场，接触器断开瞬间，感性负载反电动势经常能把电源拉出一个很大的毛刺，稍有偷懒，单片机就会莫名其妙复位。

经验：现场调试时先不要急着跑整套软件。先把所有外围通信、显示停掉，只读温度和状态字，看原始数据稳不稳。如果原始数据稳，再逐步打开显示、告警、Modbus，这样最容易定位干扰是从哪里进来的。

3. 软件实现：从寄存器读到一个稳定温度

3.1 图形化初始化与 I2C 时序

整个软件我用的是厂商提供的图形化外设初始化工具来搭底子。配置过程很简单：选好 STM32F767ZG，时钟部分用外部晶振做主时钟源，APB1 时钟让工具自动分配；I2C1 选择 PB6/PB7，标准模式也好、快速模式也好，我直接选了 400kHz；然后给 ALERT 引脚 PB4 配置成 GPIO 外部中断。

这里有一个新手容易忽略的点：PB4 这个引脚，如果用 JTAG 调试接口会被占用，所以调试口要选择 SWD 模式，这样才能把 PB4 空出来给 ALERT 用。我在第一个版本里就因为默认调试口设置，导致 PB4 怎么配都配不出预期的中断效果。

初始化生成之后，HAL 库已经帮你把 I2C 外设的时序参数算好了，这部分基本不用动。真正要注意的是 I2C 通信时的错误处理。HAL 的 I2C 函数是带超时参数的，但我见过很多人把超时值设得极小，总线稍微忙一下就直接返回错误。我的做法是所有 I2C 操作超时给 100ms，并且每次通信前检查一下 I2C 状态是否空闲。

uint8_t pj_write_reg(uint8_t reg, uint8_t val) { return HAL_I2C_Mem_Write(&hi2c1, PJ_ADDR, reg, I2C_MEMADD_SIZE_8BIT, &val, 1, 100); } uint8_t pj_read_regs(uint8_t reg, uint8_t *buf, uint8_t len) { return HAL_I2C_Mem_Read(&hi2c1, PJ_ADDR, reg, I2C_MEMADD_SIZE_8BIT, buf, len, 100); }

3.2 寄存器读取与温度换算

PJ85718DM 的寄存器布局，我按常见框架来组织：本地温度高字节、本地温度低字节、远程温度高字节、远程温度低字节，后面跟着配置寄存器、上限阈值寄存器、下限阈值寄存器。读取温度时，一次性把高字节和低字节读出来。

温度寄存器是 16 位数据，大端格式，也就是高字节在前。默认配置下我使用 12 位分辨率，数据的高 12 位有效，低 4 位是 0，所以把读到的 16 位数右移 4 位，再用符号扩展还原成有符号数，最后乘以 0.0625 就是摄氏度。

为什么是 0.0625？因为 12 位分辨率下，一个 LSB 代表 0.0625℃。400 个 LSB 就是 25.0℃，这个换算关系在 9 到 12 位几种分辨率下分别是：9 位是 0.5℃/LSB，10 位是 0.25，11 位是 0.125，12 位是 0.0625。分辨率越高，读数越细，但每次转换时间也越长。测温项目里我一般固定用 12 位，精度优先，反正转换时间也就几十毫秒级别，完全够用。

static uint16_t pj_read_raw(uint8_t reg) { uint8_t buf[2] = {0}; if (HAL_I2C_Mem_Read(&hi2c1, PJ_ADDR, reg, I2C_MEMADD_SIZE_8BIT, buf, 2, 100) != HAL_OK) { return 0xFFFF; } return (uint16_t)((buf[0] << 8) | buf[1]); } static float pj_raw_to_temp_c(uint16_t raw) { int16_t val = (int16_t)(raw >> 4); if (val & 0x0800) { val -= 4096; } return val * 0.0625f; } float pj_read_local_temp(void) { return pj_raw_to_temp_c(pj_read_raw(PJ_REG_LOCAL_TEMP)); } float pj_read_remote_temp(void) { return pj_raw_to_temp_c(pj_read_raw(PJ_REG_REMOTE_TEMP)); }

这段逻辑不算复杂，但符号处理这个地方特别容易错。温度是负数时，寄存器里是二进制补码，比如 -1℃ 在 12 位下是 0xFFF0，右移 4 位变成 0x0FFF，如果直接按无符号数乘以 0.0625，会得到 255.9℃，那就完全不对了。所以一定要先判断最高位，做符号扩展。

3.3 滤波、标定与阈值告警

裸读数直接拿来用，在这种项目里是不现实的。HVAC 现场最典型的现象就是：风机一启动、压缩机一吸合，温度瞬间跳一下，然后慢慢回来。这个跳变不是真的温度变了，而是干扰或空气流动造成的。

我做的第一层滤波是滑动平均。连续采 8 次，取平均作为当前显示值和控制值。这个成本最低，大多数场景够用。如果现场干扰特别强，我会上中值滤波：采 5 次，去掉一个最大值、去掉一个最小值，剩下 3 个取平均。中值滤波对尖峰干扰非常有效，代价是多等几次转换时间。

第二层是简单的指数滑动平均，代码就一行：

filtered_temp += (new_temp - filtered_temp) * 0.1f;

0.1 这个系数相当于把新采样值的权重控制在 10%。滤出来的数据平滑，响应也不会太迟钝。实际用下来，连续平均配合指数滑动，可以在“抗干扰”和“响应速度”之间取得不错的平衡。

标定是另一个绕不开的环节。硬件一致性再好的传感器，装到具体板子上都会有系统偏差，可能是传感器离热源太近，也可能是远端线缆电阻带来的误差。我的做法是两点标定，公式是：

real_temp = K * measured_temp + B;

两个标定点用 0℃ 和 40℃。0℃ 用冰水混合物做参考，40℃ 用高精度温度计或恒温槽。假设标定时传感器读到的值分别是 0.8℃ 和 41.2℃，那么：

K = (40 - 0) / (41.2 - 0.8) = 0.9901 B = 0 - K * 0.8 = -0.792

把 K 和 B 存到 Flash 里，每次上电后都按这个公式修正。这套标定流程对本地通道和远程通道都适用，但远程通道最好在真实线缆长度、真实测温点的状态下做，因为那一段线缆的电阻已经在系统里了。

阈值告警我直接利用了芯片的 ALERT 机制。上限阈值和下限阈值写入相应的寄存器，然后设置迟滞值，防止温度在阈值附近反复抖动造成告警频繁触发。MCU 侧在 PB4 的外部中断服务函数里读状态寄存器，判断是什么原因触发的告警，再决定是点亮指示灯、响蜂鸣器，还是通知上位机。

4. 从“能测”到“可用”：本地显示与远程上报

4.1 板级显示：OLED 与人机交互

数据测出来了，还得让人看得见。我在板上加了一块 0.96 寸 OLED，通过另一路 I2C 接在 I2C2 上。为什么不用 I2C1？因为我不想让温度采集总线和显示设备相互干扰，高温运行工况下显示刷新太频繁会影响传感器通信时序。分开之后，温度采集该走的多快走多快，显示刷新慢一点也无所谓。

显示内容很简单：第一行显示本地温度，第二行显示远程温度，有告警时在第三行用字符提示告警类型。三个按键用来切换显示模式：查看温度、查看阈值、进入参数设置。参数设置里可以调整上限、下限、迟滞、滤波系数，这些参数存到 STM32 的内部 Flash，断电不丢。这一套交互逻辑在 HMI 需求不高的设备上非常实用，不需要外接触摸屏，成本低、代码量也少。

OLED 刷新频率我控制在 2Hz 左右，也就是 500ms 刷一次。温度这种缓变量，刷太快没意义，反而占用 CPU 和总线时间。做嵌入式的都知道，显示刷新越频繁，对主控的打扰越多，能给出“不卡顿”的体验就够了。

4.2 远程上报：Modbus RTU 与以太网两套方案

温度数据只显示在本地，在 HVAC 场景里显然不够。设备装在天花板上面、机柜里面，运维人员总得找个办法在远处看到数据。我做了两套远程上报方案，一套是经典的 RS485 Modbus RTU，另一套是走以太网。

先说我更推荐的 RS485 Modbus。它简单、皮实、抗干扰好，机房空调、楼宇自控、电力监控系统几乎都认 Modbus。我用 STM32F767ZG 的一路 USART 接 RS485 收发器，波特率 9600、8 位数据、无校验、1 位停止位。从机地址用拨码开关设置，一组拨码设置完能覆盖常用设备地址范围。

寄存器映射就三四个，不搞复杂：

Modbus 的报文解析也不难，重点是把 CRC16 算对，以及处理 3.5 个字符长度的帧间隔。我用的是状态机方式，串口收到一字节就进状态机，判断一帧是否结束，再解析地址码、功能码、数据区、CRC。这个方案我跑了很久，上位机组态软件 200ms 轮询一次， très 稳。哦不，非常稳。

以太网方案也没做太重。STM32F767ZG 自带 MAC，外接一颗 PHY 芯片加网口变压器就能跑 LwIP 协议栈。我在这套板子上起了一个简单的 TCP 服务器，上位机连接后直接发指令读取温度和状态字，相当于把 Modbus 的功能映射到 TCP 上。以后要是接云平台，再改成 MQTT 客户端，定时把温度数据推送到服务器，逻辑也不复杂。对 HVAC 这种设备生命周期长的行业来说，留一个以太网口在选型上是很值的，现场网络条件允许时，调试和维护会方便很多。

5. 调试实录：我在这套系统上踩过的坑

5.1 读数飘、跳动、不准

这是遇到最多的问题。有一版我把 PJ85718DM 放得离板载 DC-DC 电感太近，结果本地温度读数整体偏高 2℃ 多，而且负载变化时读数还会小幅波动。这个不是芯片有问题，纯粹是传感器测到了它附近器件的发热。后来把传感器挪到板子边缘，远离电感和大功率器件，读数立刻正常。

远端读数跳动的原因一般出在线上。继电器吸合瞬间，远端二极管线缆感应到干扰，温度跳一下，之后恢复。我当时的做法是：确认双绞屏蔽线屏蔽层单端接地，靠近传感器端加强滤波电容，固件里把平均次数从 8 提到 16。三个措施叠加之后，现场再没有出现过明显跳动。

还有一种“读数就是不对”的情况，多半是远端测温点接法错了。有一回我把普通二极管当测温结用，读数直接差了三四度。换成三极管二极管接法之后，误差立刻回到正常范围。

5.2 I2C 总线异常

I2C 卡死是嵌入式测温项目的经典难题。表现是：开机正常，过一段时间读不到温度，函数返回错误，之后再也不恢复。这个问题我在很多项目里都见过，根子基本是两个：一是总线上有毛刺导致器件进入异常状态，二是软件里没有做总线恢复机制。

我的处理办法分两层。第一层是硬件上把上拉电阻、去耦、走线距离都处理好，尽量别让毛刺产生。第二层是软件上加总线恢复：如果 I2C 连续几次超时，把 I2C 外设 DeInit 掉，然后用 GPIO 手动把 SCL 引脚翻转 9 个时钟，再重新初始化 I2C。这个操作能让卡死的总线复位回来，相当于“软复位”。

void i2c_bus_recover(void) { HAL_I2C_DeInit(&hi2c1); /* 用 GPIO 手动翻转 SCL 9 次 */ for (int i = 0; i < 9; i++) { HAL_GPIO_WritePin(SCL_GPIO_Port, SCL_Pin, GPIO_PIN_RESET); delay_us(5); HAL_GPIO_WritePin(SCL_GPIO_Port, SCL_Pin, GPIO_PIN_SET); delay_us(5); } MX_I2C1_Init(); }

另外每次调用 I2C 读写之前，我都会检查 HAL 库返回的错误码，该捕获错误就捕获错误，别放任一次失败继续跑下去。实践下来，只要硬件没有明显设计缺陷，这套恢复机制基本不会让系统死在通信上。

5.3 告警与边缘场景的坑

ALERT 引脚一直拉低不恢复，是告警功能最常见的问题。第一反应先查硬件：开漏输出到底有没有接上拉电阻；确认上拉没问题，再看软件。很多芯片读取状态寄存器、清除了中断标志之后，ALERT 引脚才会释放。如果软件从来不去读状态寄存器，告警就会一直挂在那里，看起来像硬件坏了。

阈值写入不对是另一种情况。上限、下限寄存器是有符号数，和温度寄存器一样有符号扩展问题。我见过有人把 80℃ 写成 80，结果 12 位下右移 4 位以后和负数混淆，导致阈值完全错乱。写阈值之前先做一次换算，自己心里要有数：0x500 在 12 位下到底是什么温度。

远端测温点断开也是一个必须处理的情况。现场线缆接头松了，或者测温三极管损坏，芯片读数会变成一个明显的异常值。我的做法是：读到温度后先做范围检查，如果读数超出传感器合理工作范围，直接置一个“远端故障”标志位，同时把这个状态通过状态寄存器的 bit2 上报给上位机。不能让一个断线故障被当成“设备温度异常超限”，那会影响运维判断。

5.4 现场干扰与电源问题

整个系统在实验室跑了两周都没事，一接到现场空调箱上就开始偶尔复位。最后定位到是接触器线圈断开瞬间产生的反电动势尖峰，通过电源线传导进了控制板。解决办法是：接触器线圈两端并续流二极管，控制板电源入口加 TVS 管，再把硬件看门狗打开。这三个动作缺一不可，其中硬件看门狗其实是最后一道防线，不能指望它来救电源设计。

另外一个很值得复用的排查方法：现场不稳定时，先把远程上报和显示全部关掉，只保留温度采集和串口调试输出，让系统在最简单状态下跑。如果这样还复位，问题大概率在电源和主芯片电路；如果这样不复位，再逐步打开通信、显示、告警，打开哪一个功能就出问题，问题就在哪一个环节。这种“二分排查法”能帮你省掉大量现场瞎猜的时间。

5.5 高频问题速查表

最后整理一个速查表，现场排查时可以直接对照：

最后分享一个我自己一直在保留的习惯：任何温度项目，第一版固件里就要把原始值、滤波值、标定参数同时通过调试串口打出来。看起来多打了几行日志，但后期标定、排查干扰、确认算法是否生效时，这三组数据能帮你省大量时间。另外，再赶工期，也要在最高温和最低温两个点做一次标定，单点偏移补偿只能保证那个点准，两个点才能把斜率和偏移一起兜住。这套 PJ85718DM 加 STM32F767ZG 的方案，我后面还会往多通道方向扩展，到时候再单独记一篇。