STM32 I2C双温度点监测：从传感器选型到HVAC控制实战

最近在折腾一套暖通空调（HVAC）控制器的温度监测单元，主控选择了 STM32F429ZI，温度传感器用的是一颗 I2C 接口的数字温度芯片 PJ85718DM。系统要同时测两路温度：一路放在控制板上，测机箱内部环境温度；另一路通过 I2C 总线拉到设备风管深处，测回风口的真实温度。这个“本地 + 远程”的双温度点架构，在嵌入式设备尤其是 HVAC 场景里非常典型，但真正实现起来，坑比想象中多。

这篇文章不是教科书式的原理讲解，而是把我从选型、画板、写驱动、调控制逻辑到最后实测定版的全过程整理出来。涉及的硬件连线、寄存器操作、滤波算法和 HVAC 联动逻辑，都是可以直接抄作业的。如果你正在做类似项目，或准备在 STM32 上接数字温度传感器做多点监测，这篇应该能让你少走不少弯路。

1. 项目背景与技术选型：为什么是 PJ85718DM 和 STM32F429ZI

1.1 HVAC 温度监测的真实需求

很多人以为 HVAC 控制器测温度就是“读个数、显示一下”，其实工程上的需求要复杂得多。

第一，控制逻辑需要准确的回风温度和送风温度。制冷时压缩机要不要启动、制热时电加热要不要投入，这些都依赖温度传感器的实时反馈。第二，现场设备通常工作在机柜、管道、机房等环境里，控制板自身的温度也必须监控，防止 MCU、电源模块过热保护。第三，系统的故障诊断需要温度数据支撑，比如传感器短路、断路、通信异常，都要能及时发现。

所以“本地温度”和“远程温度”并不是同一路信号的冗余备份，而是两种维度：本地温度管设备安全，远程温度管环境控制。这也是为什么我在选型时没有图省事搞一个传感器测完事，而是从一开始就规划了一颗板载传感器加一颗远端传感器的方案。

选型时，温度传感器我对比过热电偶、NTC 热敏电阻和数字温度传感器。热电偶测量范围广但需要冷端补偿和调理电路，成本高、调试麻烦；NTC 还要自己做标定和线性化，批量生产一致性不好控制。最后锁定了数字温度传感器，尤其是 I2C 接口的型号，因为 STM32F429ZI 自带多个硬件 I2C 外设，直接读寄存器就能拿到温度值，代码简单，不需要模拟电路调参。

1.2 PJ85718DM 传感器参数速览

PJ85718DM 是一颗低功耗、I2C 接口的数字温度传感器。这类芯片常见的典型参数如下：

最吸引我的是它的地址引脚。HVAC 场景中往往要挂多个传感器，A0/A1 可以硬编码出不同地址，意味着一条 I2C 总线上可以挂多颗芯片，对布局非常友好。远程传感器不需要额外供电线之外的通讯线，直接两根信号线就能拉出去。

需要补充一句：PJ85718DM 温度寄存器的数据格式，与常见的 I2C 数字温度传感器基本一致，寄存器布局也是“指针寄存器 + 数据寄存器”的结构。后面写驱动时会按照这个约定来操作，如果你的芯片是其他型号但也是同协议的，代码可以直接参考。

1.3 STM32F429ZI 的选型理由：从接口资源到性能余量

STM32F429ZI 是 Cortex-M4 内核，主频 180MHz，带 FPU，2MB Flash 和 256KB RAM。单从跑一个温度监测任务来看，绝对是杀鸡用牛刀。但实际选型我考虑的是整个控制器的综合需求：

• 它有多达 3 个硬件 I2C、4 个 USART、多个 SPI，可以同时接温度传感器、触摸屏、RS485 总线、无线模块，不用挤接口。
• 180MHz 的主频跑控制算法和协议栈都绰绰有余，未来扩展需求不用换芯片。
• 内置的 DMA 和定时器配合，可以做到周期自动读取传感器数据，几乎不占 CPU 负荷。

另外一点很关键：这款芯片市场保有量大，开发资料和 HAL 库支持都很成熟，哪怕遇到问题，论坛和社区也容易找到参考。对工程项目来说，这是一个极其重要的隐性选型因素。

2. 硬件连接设计：一个 I2C 总线上挂两个温度点的细节

2.1 接线拓扑与地址配置

我的方案是 STM32F429ZI 的 I2C1 外设作为总线主机，挂接两片 PJ85718DM：一片在板载区域，称作本地传感器；一片通过线缆引出到风管，称作远程传感器。

I2C1 我映射到 PB6（SCL）和 PB7（SDA），这两个引脚通过复用功能配置为 I2C。两条线都接上拉电阻到 3.3V 电源域。本地传感器的地址引脚 A0、A1 接地，I2C 地址为 0x48；远程传感器的 A1 接高、A0 接地，地址为 0x49。

这里有一个很容易忽略的细节：远程传感器的地址引脚如果引线过长，接高接低的电平可能受干扰，导致地址漂移。所以远程传感器板上的 A1 和 A0 引脚要就近硬连到 VCC 或 GND，不要用跳线悬空，更不要靠软件里改地址去回避硬件问题。

本地传感器和远程传感器的 VCC 和 GND 必须从同一个电源域取，且每个传感器的 VCC 引脚旁边都要放一个 100nF 去耦电容，我习惯再加一个 10uF 钽电容用于线缆较长时的储能缓冲。

2.2 上拉电阻、线长与信号完整性：远程测温最容易被低估的三个坑

I2C 总线设计看着简单，一旦涉及“远程”两个字，水就深了。

第一个坑是上拉电阻阻值。短距离板内通信，常规 4.7kΩ 到 10kΩ 都能工作。但线拉长以后，总线电容会显著增加，上拉电阻太大，信号上升沿会被拉得很缓，超过 I2C 协议的上升沿时间要求，通信就会偶发失败。我实测过 1.5 米左右的普通杜邦线，10kΩ 上拉在 100kHz 速率下已经出现波形畸变，换成 2.2kΩ 后才稳定下来。

第二个坑是线缆类型。远程传感器走线如果和继电器驱动线、220V 强电线捆在一起，干扰会直接耦合进 SCL/SDA。我的做法是使用带屏蔽层的双绞线，屏蔽层单端接地，信号线走同一组线缆避免环路面积过大。

第三个坑是总线速率。I2C 标准模式是 100kHz，快速模式是 400kHz。远程传感器场景下我建议从 100kHz 甚至 50kHz 起步调试，等波形和通信稳定了再往上提速。在 HVAC 这种 PWM 继电器频繁动作的现场环境里，保守的速率换来的是可靠性。

如果条件允许，最好在总线上加一个简单的 ESD 保护器件，比如在远程传感器的 SCL、SDA 对地并联 TVS 管。温度传感器往往安装在金属风管或机柜内，静电和浪涌风险并不低。

2.3 供电与去耦：避免温度跳变的隐形因素

传感器自身的功耗很小，但它的供电质量直接影响温度读数稳定性。如果 VCC 纹波较大，芯片内部 ADC 的参考电压会抖动，温度值可能在小数位上下跳动。我实际测过，在同一块板上靠近开关电源模块的位置，传感器读数波动明显比远离干扰源的位置大。

解决办法是给每个传感器安排独立的 RC 滤波或 LC 滤波。简单做法就是 VCC 先经过一个 10Ω 电阻再加 10uF 钽电容，组成低通滤波，然后再进芯片 VCC 引脚。两路传感器的地线要从主控板一点接地，不要在线上串联接地回路。

3. 固件驱动实现：从 CubeMX 到寄存器级读取

3.1 CubeMX 工程配置与 I2C 引脚分配

我用 STM32CubeMX 初始化工程，设置如下：

• MCU 选择 STM32F429ZI，外部晶振 25MHz，系统主频 180MHz。
• I2C1 选择 PB6/PB7，模式为 I2C 标准模式，速率设置为 100kHz。
• 两个传感器地址的设备枚举通过扫描实现，后续逻辑按地址区分。

这里要注意 GPIO 复用配置：PB6/PB7 要设置成开漏输出模式（I2C 协议要求），使能内部上拉可以在外部上拉不足时提供一部分缓冲，但不能完全依赖内部上拉。CubeMX 生成代码后，再检查一下 GPIO 初始化的速度设置，一般建议设为高速。

3.2 读取温度寄存器的完整时序与代码

PJ85718DM 这类 I2C 温度传感器的典型读取流程是：先发送设备地址加写位，再发送寄存器指针（温度寄存器地址 0x00），然后发送设备地址加读位，连续读取两个字节。有的芯片支持重复起始条件（Repeated Start）直接读取，可以省掉一次 START 操作。

我使用 STM32 HAL 库实现，核心代码如下：

#define TEMP_REG_ADDR 0x00 #define LOCAL_SENSOR_ADDR 0x48 #define REMOTE_SENSOR_ADDR 0x49 typedef struct { float local_temp; float remote_temp; uint8_t local_valid; uint8_t remote_valid; } temp_data_t; static HAL_StatusTypeDef read_temperature(uint8_t sensor_addr, uint8_t reg_addr, uint16_t *raw_temp) { HAL_StatusTypeDef status; uint8_t temp_byte[HAL_I2C_BUFFER_SIZE]; // 先写寄存器指针 status = HAL_I2C_Master_Transmit(&hi2c1, (sensor_addr << 1) | 0x00, &reg_addr, 1, 100); if (status != HAL_OK) { return status; } // 再读两个字节温度数据 status = HAL_I2C_Master_Receive(&hi2c1, (sensor_addr << 1) | 0x01, temp_byte, 2, 100); if (status != HAL_OK) { return status; } // 大端序，高字节在前 *raw_temp = ((uint16_t)temp_byte[0] << 8) | temp_byte[1]; return HAL_OK; }

注意这里把设备地址左移了一位，HAL 库的接口需要的是包含读写位的完整 8 位地址，所以0x48 << 1才是发送到总线上的地址字节。

3.3 用 DMA 和定时器做周期读取，绕开阻塞问题

如果直接在 while 循环里调用 HAL_I2C_Master_Transmit 和 Receive，每读两路温度大概要占用几毫秒到十几毫秒的时间（取决于总线上是否出错、是否重试）。在 HVAC 控制里，这可能挤占继电器控制或通信协议的时间片。所以我采用了“定时器触发 + DMA 完成中断”的读取方式：

1. 使用一个基本定时器，比如 TIM6，设置为 500ms 周期中断。
2. 在定时器中断中置一个标志位，主循环发现标志位后，把需要读取的地址和操作信息交给 DMA 配合 I2C 完成数据传输。
3. DMA 传输完成中断里处理温度数据解析。

这种方式最关键的好处是，读取过程不会阻塞主循环。即便总线因为外部干扰出现错误，主循环仍然可以继续处理其他任务，不会整个系统卡死。

一个工程经验：I2C 总线出错时，HAL 库会在错误回调里返回错误码，但硬件层面的 BUSY 状态有时不会自动清除。需要在错误处理中调用HAL_I2C_DeInit与HAL_I2C_Init重新初始化外设，或者调用__HAL_I2C_CLEAR_FLAG手动清掉忙标志。

4. 温度数据加工：原始值到稳定温度值的处理链条

4.1 寄存器数据解析：符号位、分辨率与单位换算

拿到温度寄存器的原始 16 位数据后，首先要确认分辨率。12 位分辨率下，温度寄存器的低 4 位是无效位，实际有效数据是高 12 位。数值格式是二进制补码，最高位为符号位，代表正负温度。

转换方法很简单：

float raw_to_celsius(uint16_t raw) { int16_t signed_raw = (int16_t)raw; // 右移 4 位，丢弃无效位，保留符号位 signed_raw >>= 4; // LSB 为 0.0625°C return (float)signed_raw * 0.0625f; }

这里有一个常见的错误：有人会先把raw & 0x0FFF取出 12 位后再转换，这时负数温度就会出错，因为补码符号位被切掉了。正确做法是先按 16 位符号数右移，再参与计算。

如果你确认当前配置为 12 位精度，那么温度范围是 -55°C 到 +125°C，分辨率 0.0625°C。对于 HVAC 控制来说，0.1°C 级别的分辨率已经完全够用，不要去追求超小 LSB，因为传感器自身的噪声和精度上限已经决定了最终测量误差。

4.2 滤波策略：滑动平均 + 中值剔除的组合打法

原始温度值即使来自数字传感器，也会有轻微的 ADC 噪声，尤其在环境干扰大的工业现场。我不用单一滤波算法，而是两级组合：先做中值剔除，再做滑动平均。

中值剔除的窗口取 5 个样本，取中间值作为有效样本。这样可以把突发的、明显异常的尖峰削掉，比如继电器打火瞬间耦合进来的干扰导致的数据跳变。然后再送入长度为 16 的滑动平均窗口，让输出曲线平滑下来。

两个窗口组合后，温度读数的波动可以从 ±0.5°C 压缩到 ±0.1°C 以内，而且响应速度仍然很快，不会像纯滑动平均窗口过长那样导致温度变化严重滞后。

需要提醒的是，滤波后的数据不要直接用于所有环节。保护逻辑（比如过温停机）要使用滤波前的原始值，防止真实的高温尖峰被平均算法掩盖掉。控制逻辑（比如制冷启动）则用滤波后的稳定值，避免误动作。

4.3 校准技巧：冰水浴 + 恒温槽的两点校准

数字温度传感器出厂精度一般为 ±0.5°C，但实际使用时可能会因为焊接应力、探头封装热阻、PCB 布局热传导等原因产生偏差。如果系统要求更高精度，可以做两点校准。

我常用的校准方法是：

• 低温点：把传感器探头放入冰水混合物中，稳定 10 分钟，记录输出值，此时标准温度为 0°C。
• 高温点：把探头放入设定为 50°C 的恒温槽中，稳定后记录输出值。

根据两点的实测值与标称值，计算增益误差和偏移误差：

gain = (T_high_std - T_low_std) / (T_high_meas - T_low_meas) offset = T_low_std - gain * T_low_meas calibrated_temp = raw_temp_process * gain + offset

校准系数可以保存在 STM32 内部 Flash 的专用存储区里，每次上电时读取。需要强调的是，校准只能对当前接线方式和安装方式有效。如果把远程探头换了安装位置，热阻变了，校准结果就不一定适用了。

4.4 异常处理：NACK、旧数据、通信超时怎么办

实际运行中，I2C 通信不可能永远一帆风顺。远程线缆经过一段时间的运行后，可能因为端子松动或环境因素出现偶发通信错误。我的处理策略是为每一路传感器维护三个状态量：

• 最后有效温度值：通信失败时继续使用该值，避免控制逻辑拿到错误数据导致设备急停。
• 连续失败计数器：连续失败次数超过阈值（比如 5 次），判定该传感器离线。
• 离线标志：离线后触发报警，并切换到单点控制模式。

对于温度寄存器本身，也要检查返回值是否在合理范围内。比如 PJ85718DM 测量范围是 -55°C 到 +125°C，如果读出 -100°C 或者 200°C，大概率是通信错误或者寄存器读到乱码，应该丢弃本次数据并重新读取。

5. HVAC 业务逻辑：本地远程温差与滞回控制

5.1 双温度点的角色分配：远程控温、本地保护

在这个项目里，明确了两路传感器的职责划分：

• 远程传感器：安装在风管回风口，是 HVAC 控制的主反馈量。压缩机或电加热的启停依据就是它。
• 本地传感器：安装在主控板上，监测机箱内部温度，作为保护变量。当机箱温度过高时，无论远程温度如何，都应该降低负载或发出报警。

这样的分配避免了一个核心问题：如果控制逻辑只看本地温度，主控板的位置靠近发热器件，会导致温度滞后和误判；如果只看远程温度，一旦线路出问题系统就失去控制依据。双点形成了交叉验证，单点异常时至少有一个可靠的温度参考。

5.2 滞回控制设计：避免压缩机和继电器频繁启停

HVAC 控制中，最忌讳的就是压缩机在阈值附近频繁启停。压缩机启动电流大、机械应力高，频繁动作几分钟就能让设备受损。滞回控制是解决这个问题的标准手段。

以制冷模式为例：

• 当远程温度 >= 24.5°C 时，启动制冷输出。
• 当远程温度 <= 22.5°C 时，停止制冷输出。
• 中间 2°C 区间为滞回带，保持当前状态。

代码逻辑如下：

#define COOL_ON_TEMP 24.5f #define COOL_OFF_TEMP 22.5f typedef enum { STATE_IDLE, STATE_COOLING } cooling_state_t; cooling_state_t update_cooling_control(float remote_temp, cooling_state_t current_state) { switch (current_state) { case STATE_IDLE: if (remote_temp >= COOL_ON_TEMP) { return STATE_COOLING; } break; case STATE_COOLING: if (remote_temp <= COOL_OFF_TEMP) { return STATE_IDLE; } break; } return current_state; }

这里还可以加上启动抑制延时：当状态从 IDLE 切换到 COOLING 时，强制延时 3 分钟才真正吸合压缩机继电器，确保压缩机在停机后充分泄压，避免启动转矩过大。

5.3 故障诊断与报警：传感器失效要能自己发现

温度传感器是 HVAC 系统里故障率较高的部件。我的故障诊断策略包括：

报警输出可以驱动蜂鸣器、LED 或者通过 RS485 发给上位机。远程传感器离线时，我会把控制权切到本地温度，同时保持设备运行，而不是直接停机——毕竟对于一个环境复杂、检修不方便的现场，盲目停机可能比温度偏高更危险。

6. 实测数据与踩坑记录：从拿到样品到稳定运行的总结

6.1 首上电就找不到设备的排查过程

第一次焊接好样板后，用 I2C 扫描程序尝试枚举总线上的设备，结果一个都没回应。我当时第一反应是芯片坏了，但量了供电、检查了焊接，都正常。

后来排查发现，地址引脚的处理出了问题。本地传感器板上的 A1/A0 引脚不小心悬空了，芯片内部对悬空引脚的上拉/下拉不确定，导致地址不是预期的 0x48，很可能会随机落到其他地址。把地址引脚硬接到确定电平后，扫描程序立刻看到了两个设备。

这是我每次都要强调的教训：数字芯片的配置引脚永远不要悬空。看似无关紧要的引脚，往往会影响芯片的初始状态。

6.2 远程线拉到 1.5 米后的通信故障与修复

初始测试时两块传感器板都在同一块板上，通信一切正常。把远程传感器用 1.5 米线缆拉出去后，出现了间歇性通信失败，有时候连续几次都读不到数据，有时候又完全正常。

我实际用示波器看了 SCL 和 SDA 波形，发现远程端的信号上升沿明显变缓，而且 SDA 线上叠加了明显的噪声毛刺。逐一排查后，采取了三项修复措施：

• 上拉电阻从 4.7kΩ 改成 2.2kΩ，改善上升沿速率。
• I2C 速率从 100kHz 降到 50kHz，给信号留出更多稳定时间。
• 换用带屏蔽的双绞线，屏蔽层在控制器端单端接地。

三项措施共同作用下，通信连续稳定运行一周不再掉线。这说明远程 I2C 测温的问题往往是综合性的，不能指望单点修复就能解决。

6.3 精度实测与校准效果对比

我把本地传感器和远程传感器的读数与一台 0.1°C 精度的工业温度计放在同一个恒温箱里做了比对。未校准时，两颗传感器的读数分别偏差 +0.4°C 和 -0.6°C，说明出厂标称 ±0.5°C 还是有依据的，但具体到每颗芯片，误差方向和大小确实各不相同。

做两点校准后，两颗传感器在 0°C 和 50°C 两个标定点的误差都控制在了 ±0.1°C 以内。但在 25°C 附近的中间温区，由于两点校准本质上是线性修正，误差会有一定程度的回弹。对于 HVAC 应用来说，中间区域 ±0.3°C 的误差完全可接受。

这里分享一个个人经验：校准之后不要急着把旧参数覆盖掉。先把校准参数保存在一个调试接口里，运行一段时间如果发现补偿过度，还能回退。工程上，可回退的调试手段比一次性的“完美”校准更有价值。