嵌入式双通道温度传感器驱动设计与HVAC联动控制实践

前阵子我一直在折腾一个挺典型的嵌入式测温项目：用一颗不太常见的双通道数字温度传感器 PJ85718DM，搭配 TM4C123GH6PZL 这颗带 FPU 的 Cortex-M4F 微控制器，给暖通空调（HVAC）应用做一个本地和远程温度监测装置。所谓本地温度，是控制器自身周边、机柜里的空气温度；远程温度，则是通过线缆引到风管、回风口或者室外机组的被测点温度。两个温度同时放在同一个设备里监测，很多楼宇自控和机房环境监控场景都会用到。

这篇文章就把整个路径顺一遍：从硬件选型、引脚分配、I2C 通信细节、温度换算与滤波算法，到 HVAC 联动控制逻辑、实际测量偏差校准和一堆容易踩的坑。如果你也在做类似的风机盘管控制器、新风机监控网关、配电柜温度保护，或者单纯想把一颗 MCU 的 I2C 和传感器驱动练熟，都可以直接照着做，代码和电路我会尽量给到可以直接“抄作业”的程度。

1. 项目背景与整体设计思路

1.1 本地温度和远程温度，到底差在哪儿

很多人一开始会问：监测温度就监测一个点，为什么要分本地和远程两路？这个问题的答案跟 HVAC 的实际安装场景直接相关。

在暖通项目里，“本地”通常指设备所在位置的环境温度，比如控制柜内部温度、挂墙控制器的周围气温。这个温度主要影响设备自身工作环境是否安全——夏天机柜暴晒时内部可能到 60°C 以上，冬天低温停车场里又可能到 -20°C以下，这些都会影响 MCU、继电器、通信模块的可靠性。而“远程”指需要被控对象的实际状态温度，例如空调箱出风温度、送回风温度、冷冻水管进出水温度、某个机房内距离主机几十米远的环境温度。远程温度是运行策略里真正参与 PID 调节和启停判断的物理量。

只测一个点没法做“区间判断”。典型的 HVAC 联动逻辑要求比较温差：比如送风温度与回风温度之差，可以用来判断输出风量是否合理；供冷工况下，出风温度大于某个阈值且持续一段时间，就需要加大阀开度或提高风机转速。如果本地和远程两个温度不是由同一颗传感器芯片测出来的，就会有零点漂移不一致、冷端误差叠加、标定不统一的问题。所以项目标题里“本地 + 远程”这个组合，本质上是要求用一套测量机制同时覆盖两个空间位置，并且测量结果是同源的。

另外还有一层原因：嵌入式设备本身发热不可忽略。MCU 全速跑起来时板温会上升几摄氏度，如果传感器只有一个本地通道，那测到的温度根本不能代表环境温度。必须把真正环境被测点的温度拉远到探头端，才能得到可用于监控的有效数据。所以这个项目的数据结构里面，本地温度更多用于设备保护告警，远程温度才是环境控制的主反馈量。

1.2 选型：为什么是 TM4C123GH6PZL 和 PJ85718DM

从方案选型说起。TM4C123GH6PZL 是 TM4C123 系列里的一颗中高端型号，ARM Cortex-M4F 内核，主频最高可以到 80MHz，带硬件 FPU，单精度浮点运算说跑就跑。存储方面有 256KB Flash 和 32KB SRAM，跑一个完整的数据采集、滤波、报警、通信协议栈绰绰有余。外设相当丰富：4 个 I2C、4 个 UART、2 个 SPI、多个 12 位 ADC 通道，还有 PWM 模块和正交编码器接口。做 HVAC 控制器这种要靠多种通信接口对接触摸屏、传感器、继电器驱动、RS-485 总线的场景，这颗芯片的引脚和外设数量是非常从容的。

选 TM4C123GH6PZL 而不是更小的或更低成本的型号，原因也很实际：需要同时承担温度采集、算法运算、报警控制、上位机通信四件事。虽然单测温度用 8 位单片机也够，但后续要加程序升级、故障记录、曲线存储、Wi-Fi 模块透传时，至少得有一个像样的内存和外设平台。Cortex-M4F 的硬件浮点单元在处理温度滤波和温差控制时非常省事，直接 float 运算，不用为定点数转换折腾半天。

PJ85718DM 这一侧的选型逻辑就更清晰了：它是一颗双通道数字温度传感器，一个通道测芯片自己附近的本地温度，另一个通道通过 D+/D- 引线接入远端的测温二极管或热敏电阻探头。两路温度都由同一颗芯片内部 ADC 采集、同一份寄存器输出，天然规避了“两路传感器标定不一致”的问题。数字 I2C 接口直接连 MCU，省掉了模拟信号调理电路，也不用在 PCB 上反复调运放偏置电压，这对现场设备来说非常友好。

做个对比参考：如果用传统的负温度系数热敏电阻加 ADC 方案，需要额外计算 NTC 分压的非线性关系，还要做查表和二次插值，而且热敏电阻本身一致性差，每一路都要单独标定。用独立的两颗单通道 I2C 温度传感器也不是不行，但硬件连接复杂一倍，两路之间的测量偏差全靠芯片自身保证，未必有双通道芯片来得稳。PJ85718DM 这类双通道结构，正是针对“本地 + 远程”这个需求点专门设计的。

1.3 整体设计思路：从采集到联动控制

这个项目不是一个“测出来、串口打出来”的小 Demo，而是要落到 HVAC 应用上的完整控制节点。所以整体设计思路分了四层：

第一层是物理采集：PJ85718DM 负责把本地温度和远程温度分别转换成数字量，放在温度寄存器里，等待 MCU 读取；第二层是驱动与算法：MCU 初始化 I2C，周期读取寄存器原始值，完成二进制补码到温度值的换算、滤波、阈值判断，算出本地与远程的温差；第三层是控制输出：根据温差和温度设定值，决定风机启停、阀门开度的联动逻辑；第四层是通信和人机交互：把两路温度、设备状态、报警标志通过串口打印或 RS-485 总线传给上层系统。

这样的分层有一个好处：每一层都能独立验证。硬件工程师可以只测采样值是否准确，软件工程师可以拿预设寄存器值测试算法，调试完再合到一起联调，不会出现什么问题都搅在一起，排错非常痛苦的情况。

我给这套系统定的具体指标是：温度采集周期 500ms，本地和远程温度分辨率为 0.0625°C，精度误差控制在 ±0.5°C；温差超过设定值 2°C 时触发风机联动；远程温度超过 45°C 或本地温度超过 70°C 时触发硬件告警输出。后面所有电路和代码的取舍，都是围绕这几个指标来的。

2. 硬件连接与接口设计

2.1 PJ85718DM 的本地通道和远程通道接线说明

先明确 PJ85718DM 的接口结构。这颗芯片的供电范围一般是 3.0V 到 3.6V，数字接口电平与供电一致，可以直接接 3.3V 的 TM4C123GH6PZL，不用做电平转换。I2C 从机地址通常由两个地址引脚 AD0、AD1 的电平组合决定，默认地址在 0x48 附近。如果你的系统里打算挂多颗传感器，只需要改 AD0/AD1 的上拉或下拉电阻，就能错开地址。

芯片本身有本地测温通道和远程测温通道。本地通道就是芯片内部的二极管测温单元，直接得到 PCB 附近的大气温度，精度主要受芯片自身功耗影响。远程通道通过 D+ 和 D- 两根信号线引出，接一个远端测温二极管。D+ 和 D- 必须是差分方式走线，极性不能接反，否则读出来的温度会是错误的大数值或者报警标志被触发。在实际 HVAC 现场，远程探头装在被测风道或机房里，中间可能要走 1 到 5 米长的导线，这里强烈建议用屏蔽双绞线，屏蔽层在 MCU 侧单端接地，避免共模干扰。

寄存器方面，这颗芯片通常会有配置寄存器、本地温度寄存器、远程温度寄存器和告警状态寄存器。配置寄存器里可以设置转换精度和转换周期，比如默认 12 位精度、每 220ms 更新一次；如果想更快，可以配置成 9 位模式换取约 120ms 更新周期。温度寄存器输出的是带符号的二进制补码，后续换算时要特别注意符号位。ALERT 引脚是开漏输出，可以配置成温度超限硬件中断，直接拉到 MCU 的外部中断输入，这样 MCU 不用每轮都主动轮询温度是否越限。

2.2 TM4C123GH6PZL 引脚规划与关键电路

引脚分配是整个硬件设计的关键。我用 TM4C123GH6PZL 上面的 I2C1 模块来接 PJ85718DM，因为 I2C0 在我这块板子上要留给扩展外设，避免和调试下载口冲突。I2C1 默认引脚是 PD0 为 SDA、PD1 为 SCL，两个字正好挨在一起，布线很方便。

PD0/PD1 这两个引脚默认是普通 GPIO，使用时需要开启外设复用功能，配置成 I2C 模式。I2C 总线还需要接上拉电阻，标称值 4.7kΩ 到 3.3V。如果远程线缆接得很长、总线电容变大，可以把上拉电阻降到 2.2kΩ，否则通信上升沿太缓会导致时序错误。

UART0 的默认引脚 PA0 是 RX、PA1 是 TX，我用它接 USB 转串口模块，用来打印实时温度数据和调试信息。PE2 作为 ALERT 输入，接 PJ85718DM 的告警输出，触发后进入中断处理函数。PB6/PB7 作为两个继电器控制引脚，用于联动风机和阀门，通过 PWM 占空比或者普通 I/O 的高低电平控制外部继电器模块。

电源部分给 PJ85718DM 单独加一个 0.1μF 陶瓷电容紧挨着电源引脚，再在稍远处加一个 10μF 电解电容吸收低频纹波。TM4C123GH6PZL 的 VDDA/VDDB 同样要接一组 0.1μF + 10μF，并且使用模拟地和数字地单点连接。MCU 的复位引脚需要接一个 10kΩ 上拉电阻和 0.1μF 高频滤波电容，防止现场干扰导致异常复位。

2.3 连线实操与供电保护细节

硬件连线实操中，我遇到最多的问题不是功能不通，而是现场干扰导致远程温度值跳动。PJ85718DM 的远程通道走的是小信号测温二极管，线长超过 1 米以后，如果没有双绞和屏蔽，很容易耦合进电机启停时的感应脉冲。D+/D- 布线要尽量远离继电器驱动线和 AC 供电线，如果必须交叉，建议垂直交叉，避免平行走线。

ESD 和过压保护也不能省。远程探头很可能引出到控制柜外面，一旦探头导线绝缘破损碰到动力线，整套板子可能直接报废。可以给 D+、D- 对地并联一个小电容或者 TVS 二极管，具体容量要根据传感器手册的驱动能力来定，容量太大会影响上升沿，导致采集精度下降。SDA、SCL 线上也可以加比较小的串连电阻，如 33Ω，用于抑制振铃。

供电这一层，如果系统里带了继电器、风机等感性负载，绝对不能把负载电源和 MCU 共用一个开关电源做乱接，一定要做到“控制电、动力电、模拟电”三个回路分开。大功率负载启停时，瞬间拉低的母线电压会导致 MCU 跑飞、传感器读数跳变。我的习惯是：控制板使用独立的 24V 转 5V 转 3.3V 电源链，继电器采用单独的 12V 电源，驱动部分与 MCU 之间用光耦隔离。

3. 固件实现：从一个 I2C 读到的原始值开始

3.1 时钟、GPIO 与 I2C 初始化

固件部分我分成五个模块：系统初始化、I2C 读写、温度读取、处理算法、控制输出。第一个要做的就是把外设时钟和引脚配置好。以 TM4C123GH6PZL 为例，系统上电后默认主频可能只有 16MHz 或者更低的内部振荡器模式，必须先切换 PLL 到 80MHz，再使能 GPIO 和 I2C 外设时钟。

参考固件片段：

#include <stdint.h> #include "tm4c123xx.h" // 厂商 SDK/库的器件定义头文件 void System_Clock_Init(void) { SYSCTL_RCC_R = (SYSCTL_RCC_R & ~SYSCTL_RCC_XTAL_M) | SYSCTL_RCC_XTAL_16MHZ; SYSCTL_RCC_R = (SYSCTL_RCC_R & ~SYSCTL_RCC_OSCSRC_M) | SYSCTL_RCC_OSCSRC_M; SYSCTL_RCC_R |= SYSCTL_RCC_USESYSDIV; SYSCTL_RCC_R = (SYSCTL_RCC_R & ~(SYSCTL_RCC_MOSCDIS | 0xFFFFFFFFUL)) | SYSCTL_RCC_SYSDIV_10; }

这段寄存器操作说明的是思路：先配置外部晶振源，再开启 PLL 并把系统时钟分频到 80MHz。如果你用厂商 SDK 的驱动库，可以直接调用初始化函数，效果相同。需要注意的是，各厂商的 SDK 版本对具体寄存器宏定义名称可能不同，不要盲抄，关键是先看器件手册确认主频时钟树关系。

接着配置 GPIO。PD0/PD1 切换为 I2C1 功能，PE2 设置为输入并开启内部上拉，PB6/PB7 设置为输出。

void GPIO_Config(void) { // 使能各 GPIO 端口时钟 SYSCTL_RCGCGPIO_R |= SYSCTL_RCGCGPIO_R3 | SYSCTL_RCGCGPIO_R4; // PD 和 PE while ((SYSCTL_PRGPIO_R & (SYSCTL_PRGPIO_R3 | SYSCTL_RCGCGPIO_R4)) == 0); // PD0 + PD1: I2C1 功能 GPIO_D_AFSEL_R |= (1U << 0) | (1U << 1); GPIO_D_DEN_R |= (1U << 0) | (1U << 1); GPIO_D_ODR_R |= (1U << 0) | (1U << 1); // 开漏，I2C 需要 // 开启 I2C1 外设时钟 SYSCTL_RCGC1_R |= (1U << 1); // I2C1 对应的时钟位 // PE2 输入，PB6/PB7 输出 GPIO_E_DEN_R |= (1U << 2); GPIO_B_DEN_R |= (1U << 6) | (1U << 7); GPIO_B_DIR_R |= (1U << 6) | (1U << 7); }

I2C1 主模式初始化要设置时钟为 100kHz 标准模式，因为远程传感器线缆比较长，100kHz 比 400kHz 可靠得多。配置主模式、时钟分频、发送起始条件和接收停止条件等操作，都可以在 SDK 里找到对应函数。I2C 时序上，建议每次传输完成后清一下错误标志位，否则总线异常后主机会一直卡在忙状态，这是很常见的一个坑。

3.2 读配置寄存器和温度寄存器的完整函数

PJ85718DM 的寄存器读取套路是：先发目标寄存器地址，然后读取 1 到 2 个字节。温度寄存器是 16 位，需要连读两个字节，接收顺序通常是高字节在前。I2C 这里有一个关键点：读两个字节时，倒数第二字节要发送 NACK，最后一个字节才回 ACK，否则传感器会认为主机还想继续读，导致总线状态错乱。

参考读写函数：

#define PJ85718DM_ADDR 0x48 // 由 AD0/AD1 决定 #define REG_LOCAL_TEMP 0x00 // 本地温度寄存器，16位 #define REG_REMOTE_TEMP 0x01 // 远程温度寄存器，16位 #define REG_CONFIG 0x03 // 配置寄存器 uint8_t I2C_WriteReg(uint8_t addr, uint8_t reg, uint8_t data) { // 发送 START // 发送 (addr<<1) | 0 表示写 // 发送 reg // 发送 data // 发送 STOP // 返回状态 } uint16_t I2C_ReadTempReg(uint8_t addr, uint8_t reg) { uint8_t hi, lo; // 发送 START // 发送 (addr<<1) | 0，然后 reg，完成寄存器指针定位 // 发送 RESTART // 发送 (addr<<1) | 1，进入读模式 // 接收 hi，回 ACK // 接收 lo，回 NACK // 发送 STOP return ((uint16_t)hi << 8) | lo; }

如果你的 SDK 有更高级的 I2C 驱动库，可以封装成一行调用。但我建议无论如何都要理解上面的底层时序，因为现场排查时最常见的问题就是“为什么读出来永远是 0xFFFF”或者“读一次正常，读第二次卡死”，这基本都是总线时序没有完全按 I2C 规范处理导致的。

远程通道和本地通道的读取流程几乎一样，只是寄存器地址不同。ALERT 引脚如果不使用中断，也可以在读取温度寄存器后顺带读状态寄存器，检查 ALERT 标志位是否被置位。使用中断方式可以更快响应温度越限事件，但要小心中断函数里不能做耗时过长的 I2C 读写，最好只置一个标志位，让主循环处理。

3.3 温度换算、滤波与温差计算

PJ85718DM 在 12 位精度模式下的温度数据，是以 0.0625°C 为一个 LSB 的有符号数值。读取出来的 16 位寄存器里，高 12 位是有效数据，低 4 位是保留位。换算公式非常简单：

typedef int16_t temp_raw_t; float ConvertTempRawToC(temp_raw_t raw) { // 将 12 位补码右对齐后除以 16 return (float)(raw >> 4) * 0.0625f; }

注意 raw 必须是有符号类型。如果直接拿无符号整型右移，负温度会变成很大的正值。比如 -1°C 在 12 位补码里是 0xFFF0，按无符号算就是 65520*0.0625=4095°C，显然不对；先转成 int16_t 再做算术右移，得到 -16，再乘 0.0625 才是 -1°C。

原始 ADC 值即便在静止环境中也会有小幅抖动，分辨率越高越明显。所以我在读取之后加了一个数字滤波：先连续采集 8 次，去掉一个最大值和一个最小值，再对剩下 6 个值求平均数。这个方法比单纯滑动平均更能抵抗偶发干扰脉冲，尤其是在继电器吸合的瞬间，温度值偶尔会跳出两个明显的离群点。

#define SAMPLE_N 8 float FilterTemp(uint8_t reg) { int16_t raw[SAMPLE_N]; int i; int16_t sum = 0; int16_t min, max; for (i = 0; i < SAMPLE_N; i++) { raw[i] = (int16_t)I2C_ReadTempReg(PJ85718DM_ADDR, reg); } min = raw[0]; max = raw[0]; for (i = 1; i < SAMPLE_N; i++) { if (raw[i] < min) min = raw[i]; if (raw[i] > max) max = raw[i]; } for (i = 0; i < SAMPLE_N; i++) { if (raw[i] != min && raw[i] != max) sum += raw[i]; } // 同一套去极值后平均 return (float)(sum >> 4) * 0.0625f; }

滤波之后，温差计算就很简单了：

float delta_t = remote_c - local_c;

不过这里我要提醒一句：如果把“本地温度”和“远程温度”直接拿来做环境温差，需要先确认本地探头的安装位置是否受设备自身发热影响。像我一开始那样把 PJ85718DM 贴在 MCU 旁边，本地温度比环境温度高 2°C 都算正常。要测设备外部环境温度，必须靠远程探头；要测机柜内部温度，本地通道就够了，两者定义不能搞混。这也是代码里要把两个变量分开命名的原因，我见过不少人把这两个概念在代码里混用，最后排查温差异常查半天。

3.4 HVAC 温控逻辑与报警输出

核心控制逻辑我用一个简单的状态机来实现，避免了在中断里写复杂判断的问题。主循环每 500ms 读取一次刷新后的温度，然后计算温差，根据这几个温度量做决策。

典型供冷控制逻辑是这样的：

#define REMOTE_HIGH_ALARM 45.0f #define LOCAL_HIGH_ALARM 70.0f #define DELTA_ON 2.0f #define DELTA_OFF 0.8f void HvacControlLoop(float local_c, float remote_c) { float delta_t = remote_c - local_c; if (local_c > LOCAL_HIGH_ALARM) { Relay_Fan_On(); Relay_Valve_On(); UART_Print("LOCAL OVER TEMP!\r\n"); } else if (remote_c > REMOTE_HIGH_ALARM) { Relay_Fan_On(); UART_Print("REMOTE OVER TEMP!\r\n"); } else if (delta_t > DELTA_ON) { Relay_Fan_On(); // 温差大，需要加大空气循环 Relay_Valve_On(); } else if (delta_t < DELTA_OFF) { Relay_Fan_Off(); // 温差小，说明热负荷已降低 Relay_Valve_Off(); } }

这样的逻辑有一个明显的防回差作用。如果不设置 DELTA_ON 和 DELTA_OFF 两个不相同阈值，而只在 1.5°C 一个点上开和关，那么当温差在 1.5°C 附近抖动时，继电器会频繁吸合断开，触点寿命缩短，电机也受不了。设置 2.0°C 开、0.8°C 关，就形成了一个约 1.2°C 的回差区间，系统输出会稳定很多。

报警输出方面，ALERT 硬件中断触发快速保护：远程温度超过 45°C 或者本地温度超过 70°C，立即打开风机并输出高电平报警到上位机。软件层面再做二次确认，避免误报。报警标志要在显示屏或者串口监控中显示出来，方便现场维护人员直接看到是哪一路越限。

4. 实测数据、校准和问题排查

4.1 三组实测数据和校准偏移

硬件调试完成后，我做了三组测试。第一组在恒温室内，设定室温 26°C，用标准水银温度计做参考；第二组把远程探头放进冰水混合物里，验证低温准确度；第三组把远程探头放到空调出风口吹热风，验证动态响应和高温区表现。

实测下来，远程通道的绝对误差基本在 ±0.3°C 以内，本地通道则明显高于环境温度。原因是 PCB 上 MCU 和电源芯片的发热传导到了 PJ85718DM 的本地引脚上，导致本地读数偏高。这是传感器本身没问题、安装位置引入的系统误差。

解决办法是在固件里给本地温度加一个补偿偏移量。实测这台设备在静置一小时、板温稳定后，本地读数比真实环境温度高出约 1.1°C。我在初始化参数里设置了一个LOCAL_OFFSET = 1.1f，最后显示前减掉这个值：

float local_display = local_c - LOCAL_OFFSET;

远程传感器探头本身也有两个不太明显的误差来源：一个是探头与空气接触不充分，导致热响应滞后；另一个是线缆内引线电阻带来的测量误差。对于引线电阻的影响，可以通过把 D+/D- 做成三线制或者四线制来消除，PJ85718DM 这类双通道传感器如果支持远程接法，可以降低这部分误差。实际 HVAC 现场对 ±0.5°C 的精度普遍接受，所以这个项目没有继续做硬件补偿，直接把 0.3°C 以内的偏差留给现场标定。

4.2 常见问题排查速查表

调试过程中我整理了一张问题排查表，把这些坑按出现频率排了个序。这里列出来，大家照着检查比反复抓头发有效得多。

其中“远程温度显示为 -40°C”是最容易误判的一个。很多数字温度传感器在设计上，远端开路时给出的数值就是最大的负数，所以当代码读到 -40°C 时，不要首先怀疑温度真到了零下，而是应该怀疑探头没接好或者断了。这个检查习惯可以帮你节省不少时间和排查工具。

还有一个容易被忽略的细节：PJ85718DM 这类传感器在上电之后需要一段稳定时间，尤其是远程通道，首次读取结果并不一定是有效值。最好在上电后延时 300ms 以上再配置寄存器，然后丢弃前几次采样。否则你会发现开机瞬间的温度值会略微偏低，之后慢慢爬升，如果不处理，报警回差逻辑可能被一开始的错误值扰动。

4.3 扩展到多站点监测与上位机联动

这套硬件和代码并不是只能做一块板子上的两路测温。只要把 PJ85718DM 的地址通过 AD0/AD1 区分开，一条 I2C 总线上可以挂多颗芯片，每颗芯片都可以继续带自己的远程探头。比如一个楼宇配电柜里，可以放三块这样的采集节点板：一块测柜顶环境温度，一块测母线触点温度，一块测进风口温度。MCU 通过 RS-485 总线轮询各节点板，汇总后统一上报上层控制主机。

多站点部署时要注意地址冲突和总线电容的问题。I2C 总线上挂的芯片越多，总线上拉电阻需要越小的阻值，但也不能无限降低，否则空闲时电流偏大。工程上常用做法是用 I2C 总线多路复用器把不同区域的传感器隔离到不同通道上，MCU 先选通某条通道，再去读对应传感器，这样即使其中一路出现短路故障，也不会拖垮整条总线。尤其是 HVAC 现场施工时，你不知道哪一路传感器会被施工人员踩断线，通道隔离比事后排查要省心得多。

数据上报方面，MCU 通过 UART0 输出结构化字符串，例如逗号分隔的文本协议，上层系统按帧解析。如果要接触摸屏，可以改成 Modbus RTU 协议，温度寄存器映射到保持寄存器，这样上位机组态软件可以直接读到数据。我在这套系统上尝试过 Modbus 方式，稳定性比裸文本好不少，因为协议有从机地址、校验功能，数据错误能被识别，而不至于把垃圾数据当成真实温度去控制风机。

最后再说几个实际操作中的体会

做这个项目我踩过的坑，其实大部分不在算法本身，而在硬件现场。温度传感器这个东西，电路原理看起来很简单，但现场环境因素会让数据变得非常不干净。第一是电源，一定要保证传感器供电的纹波不超过 50mV 左右，否则数字温度寄存器的最低几位会在现场环境中不断跳动。第二是 I2C 总线长距离传输时，宁愿把速率降到 100kHz 也不要一味追求 400kHz，测量系统一点五秒的刷新周期完全够用，稳定压倒一切。第三是校准这件事，任何传感器板子放在不同的机柜里，本地通道的偏移就可能不同，批量生产时要预留一个在线上可调的校准参数，不要把它写死在代码里。

另外我建议把这个项目做成带掉电保存的设备：把校准偏移、报警阈值、控制回差都放到非易失存储区里，通过串口命令或者按键在线修改。这样现场调试时可以快速调整，不用每次改代码重新烧录。我在实际做的时候，把参数表做成结构体，修改之后写回 Flash，复位后自动加载，使用体验和产品化的程度都会高很多。

这套“本地温度 + 远程温度”的双路监测框架，不管是给 HVAC 用，还是将来换成冷库监控、服务器机柜温度保护、恒温箱控制，只需要换传感器探头和调整阈值参数就能复用。骨架不变，变的只有应用层判断逻辑。算下来，这个项目最值钱的不是那几个 I2C 寄存器，而是那套能可靠测量、能稳定控制、能定位现场故障的工程化思路，把这套思路吃透，随便换什么芯片都能很快上手。