基于PJ85718DM与STM32F767ZI的双路温度监测系统设计

搞嵌入式温度监测这一块也六七年了，各种传感器轮着用过一遍，回过头来发现工程项目里最稳的反而不是那些花里胡哨的方案。这次用 PJ85718DM 加 STM32F767ZI 做了一套本地与远程双路温度监测系统，主要是给暖通空调（HVAC）控制器和嵌入式设备机柜做环境与热源监测，整个项目做下来，从选型、接线到软件联调，有不少值得记录的地方，这里完整整理出来，方便后面做类似项目的朋友直接参考。

这个方案核心解决的问题其实很典型：一个系统里往往有两个测温需求——一个是设备本身所处环境的温度（本地温度），另一个是发热元件、风道或水箱等需要远程布点的位置温度（远程温度）。以前的做法要么是装两个单点传感器，要么用一个多路 ADC 外接 NTC 热敏电阻，前者成本高还要占用两个总线地址，后者存在非线性校准麻烦、长线干扰大的问题。PJ85718DM 一片就能同时搞定本地和远程两路测温，而且走 SMBus 总线，挂载简单、精度可控，非常适合做温控和过温保护。STM32F767ZI 作为主控，本身资源充裕，有多个 I2C/SMBus 外设、足够的中断引脚和通信接口，采集完数据以后无论是本地显示、报警还是上报给上位机，都很轻松。

如果你正在做一个带温度采集的控制器、机柜监控设备，或者想把手头的 HVAC 系统升级成带数字通信的智能温控方案，这篇文章可以参考的价值在于：把器件选型逻辑、硬件接线细节、寄存器配置顺序、温度换算公式、报警阈值处理，以及常见的坑和排查方法都讲透。

1. 项目整体思路与方案选型

1.1 双路测温的需求从哪来

HVAC 设备里测温点位看着不多，但每个位置含义不同。机房空调或者楼宇新风机组里，回风温度、出风温度、冷却盘管表面温度、电控箱内部温度，属于完全不同的测量对象。

电控箱内部的本地温度，反映的是主控板、继电器、变压器这些元器件周围的散热状况，温度太高说明柜内通风不良，或者负载异常。回风管、盘管、电机表面的温度，属于真正的工艺监测点，离主控板可能隔了半米到几米，这些点的温度直接关系空调除湿、制冷效果和压缩机保护。这个场景天然就需要两路温度，一路贴近控制板测环境，一路拉到远端测目标物体。

嵌入式设备上其实也一样。很多高性能 MCU 和功率器件对工作温度敏感，比如功率 MOS 管的壳温、电源模块的热点温度，都需要实时监测。主控板附近的空气温度代表不了芯片结温，必须在热源表面放一个温度探头。这时候双通道芯片的价值就体现出来了。

1.2 为什么选 PJ85718DM 而不选 NTC 或单点数字传感器

NTC 热敏电阻方案看起来便宜，但用起来麻烦：阻值-温度曲线是非线性的，虽然可以用 Steinhart-Hart 方程算，精度仍然有限；信号是模拟量，长线传输容易受干扰；做隔热和防水处理也得单独设计。单点数字传感器像常见的 I2C 温度芯片，精度和线性度都很好，但一片只能测一路，两路需要两片，占用两个地址，PCB 面积也翻倍。

PJ85718DM 这种本地+远程双通道数字温度传感器，把两路需求集成在一颗芯片里。本地通道直接用芯片内部的带隙温度传感器，免去了外部电路；远程通道通过 DXP/DXN 两个引脚外接一颗廉价的三极管（比如 2N3904 接成二极管形式），就能把测温点放到需要的位置，中间连接线只要做好屏蔽，可以拉几十厘米到一米以上。这点特别适合 HVAC 设备里传感器板与主控板分离的布局。

远程测温的原理值得多说两句。芯片内部会给外部二极管施加两个不同电流，分别测量二极管两端的压降 Vbe1 和 Vbe2，因为 ΔVbe 与绝对温度成正比，通过公式换算就能得到当前的绝对温度。这个差分测量方式好处很明显：二极管本身的初始压降、连接线上的串联电阻都会被抵消掉，所以只要二极管选型和接法正确，远程温度精度可以做得很好。这一点是普通 NTC 方案没法比的。

1.3 STM32F767ZI 在这个系统里扮演什么角色

STM32F767ZI 是 Cortex-M7 内核的高性能 MCU，主频 216MHz，2MB Flash、512KB RAM，做温度采集绰绰有余，但它在这个项目里不只是个“读寄存器”的角色。HVAC 控制器一般还要处理压缩机启停、风机调速、通信协议栈、人机交互，这些逻辑都需要算力。M7 内核带 FPU 和 DSP 指令，做滤波算法、PID 温控、百分比换算都很顺手。

更重要的是外设的匹配度。F767ZI 有 4 个 I2C 外设（实际型号引脚映射以参考手册为准），可以独立挂 SMBus 温度传感器、EEPROM、RTC 等设备，不用挤在同一条总线上。它还有多个外部中断引脚，刚好用来接传感器 ALERT 报警输出。如果你要做远程数据上报，F767ZI 的多个 UART 可以扩展 RS485 Modbus，内部还带以太网 MAC，配合 PHY 芯片就能直接上网络。这意味着温度采集之后的数据链路非常灵活，从串口到总线再到以太网都能覆盖。

2. 硬件设计要点与接线实操

2.1 PJ85718DM 远程通道的传感器选择与接法

远程温度通道核心是一颗外部半导体结，常见的做法是直接用 NPN 三极管把基极和集电极短接，形成一个小二极管。2N3904 这类通用小信号三极管就够用，便宜、到处能买到。要注意的关键点是极性和连接方式。

常规接法是把三极管的发射极接到芯片的 DXP 引脚，集电极与基极短接后接到 DXN 引脚。接反的话远程温度读数会异常跳变，或者报故障。有些芯片支持二极管反接检测，但工程上没必要赌这个功能，老老实实按手册接最稳妥。

选三极管也有讲究。要选 Vbe 温度特性稳定的普通小信号管，不要用达林顿管，也不要选功率管或者集成带电阻的数字三极管，因为这些管的 Vbe 特性和标准 PN 结差异很大。同一型号批次间的参数一致性通常不错，但如果量产，建议确认货源稳定，因为不同厂家同名型号的三极管 Vbe 特征可能存在细微差异，最终会反映在远程温度误差上。

2.2 主板接线与抗干扰设计

远程测温的 DXP/DXN 两根线属于精密模拟信号路径，虽然芯片内部做了差分测量来抵消串联电阻影响，但长距离走线依然会被强干扰源影响。工程上几个具体要求：

• 线径不要太细，用普通 0.3mm² 以上的信号线即可，关键是做双绞处理。如果把两根线绞在一起，外部磁场在两根线上感应的共模噪声基本相同，差分测量能把它消除掉。
• 传感器部分如果靠近继电器、变频器、压缩机这类强干扰源，建议外层加屏蔽，屏蔽层单端接地，不要两端都接地，否则可能形成地环路电流，反而引入干扰。
• 线长能短尽量短，1 米以内衰减和干扰都可控，超过 1.5 米就要慎重，必要时降低总线速率、加小电容滤高频。
• PCB 上从芯片引脚出来的走线也要远离继电器驱动线、PWM 输出线，模拟地与数字地在芯片处用 0Ω 单点连接或者通过磁珠隔离。

2.3 SMBus 总线上拉与引脚连接

PJ85718DM 的 SCLK 和 SDATA 是标准 SMBus 双向引脚，属于开漏输出，总线上必须有上拉电阻。上拉电阻阻值不是随便选的，它跟总线电容和通信速率有关。常用做法是在 3.3V 电源下用 4.7kΩ 上拉，如果总线挂载设备多，整体电容变大，要适当减小到 2.2kΩ 甚至 1kΩ。但注意阻值不能太小，否则灌电流太大，低电平可能抬不起来，也增加功耗。实测下来，单传感器、走线 10cm 以内的场景 4.7kΩ 完全没问题；如果传感器板通过连接线与主板分开，总线长度超过 30cm，换成 2.2kΩ 更稳妥。

STM32F767ZI 接 SMBus 用的是标准 I2C 引脚，注意 F767ZI 的 I2C 外设引脚有多组复用，选哪组都行，但要避开与其他外设冲突的引脚。ALERT 报警输出是开漏结构，也要一个上拉电阻，接在主控的任意可作外部中断的 GPIO 上，这样报警事件来的时候不经过轮询，直接打断 MCU 处理。

2.4 地址配置

PJ85718DM 的从机地址由 ADD0 和 ADD1 两个引脚决定，可以有四个不同组合。单板只有一片传感器时，两个引脚直接接地即可，用默认地址。如果系统里有多片，就要分配不同地址。

工程上建议把地址规划写在设计文档里，比如主板本地温度传感器占用地址 0，远程回风温度传感器占用地址 1，冷却盘管温度传感器占用地址 2。这样后续软件写 SCAN 枚举逻辑时，可以依次探测各地址是否存在设备，任何一路掉线都能定位到具体位置。物理上把 ADD0/ADD1 引脚的跳线或者焊盘做成可配置的，同一种 PCB 可以兼容不同安装位置。

2.5 电源与去耦

传感器供电建议直接用 3.3V，与 STM32 同一电源轨。芯片电源引脚旁边放一个 100nF 电容，如果供电线比较长或者电源噪声大，再加一个 10μF 钽电容或者电解电容。这里有个小技巧：如果你发现本地温度读数比室温明显偏高 2~3°C，大概率不是传感器坏了，而是自热效应——测温芯片本身的功耗让裸片温度略高于环境温度。降低这种偏差可以从两方面入手：一是把 100nF 去耦电容靠近芯片放，减小电源纹波对内部基准的影响；二是转换速率不要设太高，连续高频转换会增加动态功耗， HVAC 场景 1 秒采一次完全足够。

3. 软件实现与温度数据解析

3.1 初始化流程与寄存器配置

软件第一件事是初始化 I2C/SMBus 外设。STM32F767ZI 的 I2C 在 HAL 库中可以直接配置为 SMBus 模式，这里没有必要去手写 GPIO 模拟时序，用硬件外设稳定性和实时性都更好。

关键配置项：时钟速率按 100kHz 设置比较稳，SMBus 标准模式下时钟一般就 100kHz，这已经足够传输温度数据了。如果追求更高的刷新率，可以按芯片支持的上限提到 400kHz，但前提是总线电容小。上电之后先做一次设备探测，往器件地址写一个字节看是否收到 ACK，这样能排除接线问题再继续操作。

PJ85718DM 这类带报警功能的传感器，初始化时通常要配置三个部分：运行模式、转换速率、报警阈值。运行模式就是连续转换和单次转换。HVAC 后台监控适合连续模式，MCU 定时去读最新结果即可；如果是手持设备或者低功耗电池供电，可以每 10 秒唤醒一次，用单次转换测完就睡。报警阈值放到后面单独说。

3.2 SMBus 读写时序与温度寄存器

SMBus 读温度数据的关键套路是“先写指针，再读数据”。温度传感器内部寄存器很多，总线上通过一个指针寄存器来决定接下来读写的是哪个寄存器。比如要读本地温度：先发一个写命令，带上本地温度寄存器地址作为命令字节，然后重新发送起始条件（Repeat Start），再发读命令，从设备就会从刚才选中的寄存器开始输出数据。

为了让你有个直观认识，我直接给一段 HAL 库的读寄存器函数：

uint8_t temp_read_reg(uint8_t dev_addr, uint8_t reg_addr) { uint8_t data = 0; HAL_I2ST_Read(&hi2c1, dev_addr, reg_addr, I2C_MEMADD_SIZE_8BIT, &data, 1, 100); return data; }

代码里用I2C_MEMADD_SIZE_8BIT是因为传感器寄存器地址是 8 位的。如果是 16 位寄存器地址的器件，就要改成I2C_MEMADD_SIZE_16BIT，很多新手在这里踩坑，读回来全是乱码。

读取双通道数据的时候，建议一次性连续读完多个寄存器，减少总线往返。比如把状态寄存器、本地温度高字节、本地温度低字节、远程温度高字节、远程温度低字节按顺序连续读取，避免数据不同步。如果你先读本地温度，隔了一会儿再读远程温度，中间的延时可能导致两个温度采样点对不上，在快速温变场景造成判断混乱。

3.3 温度值换算：从原始 ADC 到实际温度

数字温度传感器输出的是一段二进制补码，需要经过换算才是实际温度。以常见的 12 位分辨率为例，LSB 对应 0.0625°C，也就是说温度 = 原始值 × 0.0625。把这个逻辑写出来：

float extract_temp(int16_t raw) { return raw * 0.0625f; }

听起来很简单，但有一个细节非常容易出错：符号扩展。如果寄存器值本身是 16 位带符号类型，直接用没问题；但不少 MCU 代码里读回来的是 uint8_t，需要先拼成一个 int16_t，再右移 4 位（因为 12 位有效数据在寄存器的高 12 位），最后再做符号扩展。这里稍一马虎，负温度读出来就是一个巨大的正数，你拿着这个数去算温控逻辑，整个系统都乱了。

完整的读取函数可以这么写：

typedef struct { float local_temp; float remote_temp; uint8_t status; } temp_data_t; temp_data_t read_temperature(uint8_t dev_addr) { uint8_t buf[5]; temp_data_t result = {0}; HAL_I2C_Mem_Read(&hi2c1, dev_addr, TEMP_REG_LOCAL_MSB, I2C_MEMADD_SIZE_8BIT, buf, 5, 100); int16_t local_raw = (int16_t)((buf[0] << 8) | buf[1]); int16_t remote_raw = (int16_t)((buf[2] << 8) | buf[3]); local_raw >>= 4; remote_raw >>= 4; result.local_temp = local_raw * 0.0625f; result.remote_temp = remote_raw * 0.0625f; result.status = buf[4]; return result; }

注意我在读完后把原始数据右移了 4 位，因为 12 位分辨率下温度数据占据寄存器的高 12 位，低 4 位无效。如果你配置的是 9 位分辨率，就要右移 7 位，换算系数也变成 0.5°C/LSB。分辨率不同，数据位宽和系数都要对应调整。

3.4 报警阈值与滞回控制

PJ85718DM 这类传感器都支持本地和远程温度的高低阈值报警。报警条件满足后，ALERT 引脚拉低，主控通过外部中断立刻感知，不需要一直轮询。这在 HVAC 设备里很有用，比如本地温度超过 70°C 意味着电控箱散热异常，需要在几百毫秒内响应，关掉加热器或者风扇，等温度降下来再决定恢复。

阈值设置的原则是必须带滞回。如果只设一个上限值，温度在阈值附近小幅度波动时，ALERT 会反复拉低拉高，继电器频繁通断，这对设备是灾难。实际操作中我会把报警恢复值设为比报警值低 3~5°C，比如风机启动温度 55°C，停止温度 50°C，这样中间留出一个迟滞带，系统稳定得多。

如果你在软件层面做迟滞，代码思路大致是：

#define FAN_START_TEMP 55.0f #define FAN_STOP_TEMP 50.0f static _Bool fan_state = 0; void temp_control_loop(void) { temp_data_t t = read_temperature(TEMP_DEV_ADDR); if (!fan_state && t.remote_temp >= FAN_START_TEMP) { fan_state = 1; fan_on(); } else if (fan_state && t.remote_temp <= FAN_STOP_TEMP) { fan_state = 0; fan_off(); } }

这种滞回逻辑在风扇、加热器、压缩机控制上非常通用，比单纯比较大小好用得多。

3.5 数据上报与系统集成

温度数据拿到之后怎么用，决定了整个项目的高度。前期调试时，最简单的方法是直接通过串口打印，配一个 115200 波特率，每秒打印一次本地和远程温度，肉眼观察曲线。量产阶段就要走协议了。

HVAC 系统里最常用的就是 Modbus RTU over RS485。STM32F767ZI 的 UART 引脚外接一个 RS485 收发器，在软件里把实时温度映射到保持寄存器，比如寄存器地址 0x0001 放本地温度，0x0002 放远程温度。上位机或者楼宇自控系统轮询读取，频率 1 秒一次就够。更高级一点的做法是用以太网，MCU 跑一个精简的 Modbus TCP 或者直接上报 MQTT，数据要进物联网平台也不难。

如果系统里还需要显示，接一块小屏，本地温度、远程温度、状态信息三行轮播。F767ZI 的算力做这些完全没压力。

4. 实测数据与调试验证

4.1 测试环境与采集方法

做实测的时候没有直接用标准恒温槽，因为实验室里临时搭建的校温环境很容易引入误差。我更推荐先用简单的模拟场景验证系统逻辑，再去做精确校准。

第一组测试是常温环境：把传感器板放在桌面上，远离风吹和热源，连续采集 30 分钟。本地温度应该在室温附近，远程不接二极管时报错，接上二极管后测到的应该是二极管所处的环境温度，通常是室温附近。这时候本地和远程数据可能相差 1°C 左右，因为二极管在空气中有一定自热，而且和芯片内部传感器的热路径完全不同。这个偏差在常温下是正常的，不要急着改代码。

第二组测试是升温响应：用一个小功率电阻贴在 2N3904 的管壳上，或者干脆用手指捏住三极管，观察远程温度是否快速上升。数秒内应该看到温度跟随变化，反应最灵敏的是短时间内的斜率，而不是绝对数值。如果捏住后温度纹丝不动，基本可以判断远程通道配置有问题。

第三组测试是稳定性验证：用热风枪给传感器板加热，让本地温度从室温升到 60°C 左右，观察读数是否平滑，有没有跳变。跳变通常不是传感器问题，而是总线上拉不够强或者电源噪声导致读到了错误字节。

4.2 数据误差的来源与校准方法

温度传感器出厂标称精度通常是 ±1°C 这个级别，实际系统误差来源却可能远大于这个数。远程通道最大的误差来源是所选二极管的特性与芯片内建理想模型之间的偏差。

校准的办法不复杂：准备一个标准温度计或者用恒温槽，把远程二极管放进已知温度环境中，比对该芯片的读数和标准值，然后用两点校准法修正。取得两个温度点（比如 0°C 和 60°C）的偏差，在软件里做一次线性补偿：

static float remote_cal(float raw_temp) { return (raw_temp + CAL_OFFSET) * CAL_GAIN; }

偏移量和增益值根据实际校准结果算出。量产批次如果二极管货源固定，校准参数基本可以固化；如果换过二极管供应商，建议重新抽检一份校准参数。

本地通道的误差主要来自芯片自热和 PCB 布局。如果传感器离发热元件太近，比如紧挨着 LDO 或者 MCU，读出的温度会明显偏高。最有效的办法是布局时让传感器周围留出一点空间，不要直接贴着大功率器件。如果布线时实在避不开，就在软件里减去一个经验常数，比如 2°C，但这样做的前提是你已经在上电前后对比过无负载和有负载时的差值，而不是拍脑袋减。

4.3 实测中发现的时序与稳定性问题

在调试过程中发现的典型问题是偶发的温度跳变。现象是数据屏上大多时候正常，但每隔几分钟会突然跳一个很大的正数或者 0，然后又恢复正常。用示波器抓 SMBus 波形后发现，问题的根子是单片机的 I2C 中断被高优先级任务打断，导致传输时序被拉长，个别字节采样错误。

排查结果是两个因素叠加：一是 F767ZI 内部跑着多个中断，I2C 事件优先级设置偏低；二是传感器总线上拉电阻偏大，边沿不够陡峭，稍微一点时序扰动就会读错。解决办法是在初始化里把 I2C 中断优先级调高，并把上拉电阻从 4.7kΩ 换成 2.2kΩ。改完之后连续跑 24 小时，没有出现一次跳变。这类问题在实验室排查起来耗时，但根源往往是硬件边界条件没做到位，而不是传感器本身的问题。

5. 常见问题与排查技巧实录

做这套系统的过程中，好用的排查思路值得沉淀下来。下面这些现象我都实际遇到过，整理成表方便检索。

还有一个容易被忽略的问题：很多 SMBus 温度传感器在首次上电后需要几十毫秒稳定时间，主控如果复位后立刻访问，可能拿不到 ACK。稳妥的做法是主控上电延时 50ms 以上再开始初始化总线，或者用重试机制，连续读三次，三次都失败才报告传感器故障。这个逻辑加进去之后，整机上电死机率明显下降。

6. 扩展方向与个人实操心得

这套系统跑顺之后，可以往几个方向扩展。第一个是做成多节点温度监测网络，多片 PJ85718DM 挂在不同地址上，分别监测电控箱、压缩机回气管、冷凝水盘和出风口温度。F767ZI 的 I2C 外设足够挂载多片，温度点多了以后可以做出更细的温控逻辑，比如根据回风和出风温差判断换热器是否结垢、根据压缩机排气温度做保护。

第二个是接入 FreeRTOS。现在这套代码是裸机轮询加中断，实际上 F767ZI 跑 RTOS 才是常态。把温度采集放在一个独立任务里，通过消息队列把数据发给显示任务和通信任务，报警事件用信号量或者事件标志组通知。这个架构清晰以后，后续加逻辑不用东改西改，扩展性好很多。

第三个是低功耗改造。如果设备要用电池供电，可以把传感器闲置模式用起来，MCU 定时 30 秒唤醒一次，单次转换获取温度后立刻休眠。这样整机平均电流可以做得非常低，传感器本身的功耗反而成了大头，选型时要注意看静态电流参数。

最后再说一个实际体会。很多人做温度采集，觉得不就是读个寄存器嘛，却不知道真正的坑全在物理层和系统层：远程二极管的选型极性、总线上拉匹配、报警滞回设置、中断优先级、符号扩展，任何一个细节没处理好，温度数据就是错的。PJ85718DM 的双通道架构解决了我之前用两颗传感器才能干的事，成本和布板面积都有优势，但前提是把硬件底子打扎实。

我个人的经验是：拿到这类传感器，别急着写业务逻辑，先做三个小实验——扫描地址、连续读温度打印曲线、用手改变被测温度观察响应。这三个实验做完，这个芯片在你项目里能不能站住脚基本就有数了。剩下的，无非是把报警阈值、上报协议和可靠性测试一件件补完。