基于STM32F373VC与PJ85718DM的HVAC温度监测系统方案

最近在做一个嵌入式温度监测项目，控制对象是暖通空调（HVAC）设备里的风机、压缩机和辅助加热器，要求在一套硬件上同时搞定本地温度和远程温度的采集。我最终选型是 PJ85718DM 数字温度传感器加 STM32F373VC 主控：本地温度走板载 I2C 直读，远程温度走 RS-485 总线分布式采集，再统一汇到控制器做联动和报警。项目从原理图设计、驱动调试到现场联调踩了不少坑，这篇就把完整方案、代码逻辑和排查经验都整理出来。

如果你正在做 HVAC 控制柜、嵌入式环境监测终端，或者需要做“传感器在本地、数据要远端汇总”的类似系统，这篇应该能帮你省掉不少试错时间。全文不会只停留在“引脚怎么接、寄存器怎么读”，我会把为什么这么选型、为什么这么设计、哪些地方容易翻车一起讲清楚。

1. 项目目标拆解：为什么把本地温度与远程温度放在同一套系统里

1.1 本地采集与远端采集到底分别解决什么问题

很多人一看到“本地温度 + 远程温度”，第一反应是“不就是多挂几个传感器吗”，其实这里面的本地和远程，解决的是两类完全不同的控制问题。

本地温度指主控板自身或就近设备的工作温度。比如控制柜内部的温度、功率器件附近的温度、风机出口的即时温度。这种温度的特点是：距离 MCU 近，适合用 I2C 这类短距离总线直接采集，采样周期可以做到很短，用来做快速保护最合适。我在项目里用 PJ85718DM 直接贴在功率驱动区域附近，读取主控板环境温度，一旦超过 70°C 就触发风扇调速和降载保护。

远程温度则指分布在现场不同位置的监测点。比如 HVAC 系统里多个风管采样点、不同房间的温控传感器、冷却水进出水温度，甚至是整栋楼的集中采集节点。这些传感器离主控有几十米甚至上百米，不可能用 I2C 直连，必须走 RS-485、CAN 或者以太网这类远距离总线。远程温度的价值不是保护单板，而是让系统知道“整个环境现在是什么状态”，进而决定压缩机启停、风机转速、水阀开度这些大局层面的控制策略。

这两个需求放在同一套系统里，最大的好处是软硬件可以分层复用：MCU 只负责处理温度值，不关心温度是从 I2C 读到的还是从串口收到的。本地温度走实时保护，远程温度走环境调节，两路数据在同一个控制循环里做仲裁。

1.2 温度监测项目最核心的指标：精度、稳定性、实时性

做温度项目，不能只看传感器标称精度，一定要把精度、稳定性和实时性分开来评估。我列了一张需求表，直接指导选型：

PJ85718DM 这类数字温度传感器的好处是内部直接完成模数转换和线性化，MCU 通过 I2C 读寄存器就能拿到现成的温度数据。对比传统的 NTC 热敏电阻加 ADC 方案，省掉了外部基准源校准、分压电阻温漂、查表线性化这一大堆麻烦。HVAC 现场环境恶劣，温度变化范围大，数字传感器的稳定性和一致性明显更靠谱。

实时性方面要理性看待。HVAC 的惯性很大，房间温度不可能 100ms 变一次，所以远程温度没必要高速轮询。本地保护温度才需要快速响应，比如功率器件过热时，最好在几百毫秒内做出反应。这个差异直接决定了后面滤波和通信策略的设计。

1.3 介于“手搓温度计”与“大型SCADA”之间的方案边界

这个项目最开始的备选方案其实有两个极端：一是用 NTC + 运放 + ADC 自己做温度采集，成本很低，但每一路都要标定，而且随着时间推移会飘；二是直接上大型楼宇自控系统，功能很全但价格和开发周期都扛不住。

PJ85718DM + STM32F373VC 的组合正好落在中间：数字传感器保证了精度和一致性，省掉逐路标定的工作；MCU 提供了足够的算力和外设资源，既能跑温度采集，也能顺便跑通信协议和控制逻辑。对于中小规模的 HVAC 控制柜、嵌入式环境监测终端来说，这套方案性价比很高，后期扩展也方便，比如多挂一路传感器，只要 I2C 地址不冲突就行。

2. PJ85718DM与STM32F373VC的选型逻辑与器件特性

2.1 PJ85718DM的接口特性与实用参数

PJ85718DM 是一颗典型的 I2C 接口数字温度传感器，工作电压 2.2V~3.6V，温度测量范围覆盖 -55°C 到 +150°C，完全能覆盖 HVAC 和嵌入式设备的常规工作区间。温度寄存器是 16 位，分辨率可以达到 0.0078°C 左右，这个分辨率对 HVAC 控制来说绰绰有余。

需要特别说明的是，我在项目里使用的是 PJ85718DM 常见配置方式：默认 7 位 I2C 地址，支持通过地址引脚修改地址，以便一条 I2C 总线上挂多颗传感器。器件内部一般会有配置寄存器，可以设置连续转换模式和单次转换模式。单次转换在低功耗场景非常好用，唤醒之后发一条命令，等待转换完成再读数据，其他时间器件处于休眠状态。

PJ85718DM 的温度数据以二进制补码形式存放在寄存器里，读取时需要注意符号位的处理。比如 -0.25°C 对应的原始值是 0xFFFF（16位补码），如果直接按无符号数处理，后面换算就会出大问题。这一点在代码里必须处理清楚，后面实操部分会给出代码。

我在电路设计时给这款传感器加了较宽范围的电源去耦，因为 HVAC 控制柜里经常有继电器、接触器动作，电源瞬间跌落很容易导致传感器读数跳变。数字传感器虽然抗干扰能力强于模拟方案，不代表可以忽略电源质量，特别是它内部有 ADC，电源纹波会直接影响转换结果。

2.2 STM32F373VC的适配点：运控能力、高精度ADC与通信外设

选择 STM32F373VC，看中的不只是它的 Cortex-M4 内核，而是它和这个项目场景的匹配度。F373 系列主频 72MHz，跑温度采集、Modbus 协议栈、控制算法完全没有压力，Flash 有 256KB，RAM 有 32KB，给后续功能扩展留够了空间。

F373 自带的高分辨率 ADC 是个隐藏优势。HVAC 系统里除了温度，往往还要检测湿度、电流、压力等模拟量，F373 内置 16 位 Σ-Δ ADC，可以直接接传感器信号，不用额外加外部 ADC 芯片。这一点在选型当时很加分，等于一块芯片把数字温度采集和高精度模拟量采集都包了。

通信外设方面，F373 提供了多个 I2C、USART 和 CAN 接口。我的规划是：I2C1 接板载本地温度传感器，USART1 外接 RS-485 收发器走远程温度总线，另外一个 USART 留作调试串口。外设之间互不抢占，软件设计上也清晰，每个外设一个模块，接口统一。

F373 的另一个优点是它有比较丰富的高级定时器，可以做 PWM 输出和输入捕获。如果后续需要控制风机无级调速或者检测霍尔传感器转速，完全不需要额外加定时器芯片。这种“一块芯片覆盖采集、通信、控制”的特性，在小体积控制板设计里非常实用。

2.3 器件配合时的三处细节：地址、电源、电平匹配

选型定了不代表没问题，两颗芯片配合时有三个细节必须在原理图阶段就考虑到。

第一是 I2C 地址分配。PJ85718DM 有一颗地址引脚可以配置地址，我先算了一下整板需要挂几个传感器：本地温度一颗、预留扩展两颗，那就要把地址引脚分别接 GND、VDD 和悬空来区分。如果后面要挂更多，就得分到第二条 I2C 总线。这个问题最容易被忽略，等画完板才发现地址冲突，只能飞线解决。

第二是电源域。STM32F373VC 工作电压是 2.0V~3.6V，但 HVAC 控制板上的外设经常是 5V 供电，比如 RS-485 收发器、继电器驱动、LCD 背光。设计时要把 3.3V 模拟电源、3.3V 数字电源、5V 外设电源分开走，I2C 上拉电阻接到 MCU 的 3.3V 域，避免传感器和 MCU 之间出现电平打架。

第三是电平匹配。如果传感器挂在 5V 电源下，而 MCU 是 3.3V 逻辑，SCL/SDA 线上就要加双向电平转换或者至少确认传感器是否 5V 容忍。我在画原理图时直接把传感器接到 3.3V，省掉了转换电路，但现场线缆延长时会在末端加保护电阻，防止外部短路损坏引脚。

3. 本地温度采集的电路设计与I2C通信实现

3.1 最小电路：上拉电阻、去耦电容、连接器

本地温度传感器距离 MCU 很近，电路可以做到非常精简。PJ85718DM 在板上的连接只有 4~6 个引脚：电源、地、SCL、SDA，外加可选的地址引脚和报警输出引脚。

I2C 总线必须接上拉电阻，具体阻值要结合总线速率和负载电容来选。400kHz 模式下，如果总线上只有两三颗器件，上拉电阻选 4.7kΩ 通常没问题；如果线缆较长或者器件较多，我会把上拉降到 2.2kΩ 来增强驱动能力。计算公式是 RC 时间常数要小于 I2C 规范允许的上升时间，在 400kHz 下上升时间要求不超过 300ns，当总线电容约 100pF 时，4.7kΩ 的上升沿大约 470ns，偏慢，所以保守起见 2.2kΩ 更稳妥。

去耦电容我习惯放两级：一颗 0.1μF 陶瓷电容放在电源引脚附近，滤除高频噪声；一颗 2.2μF~10μF 钽电容或陶瓷电容放在稍远处，吸收低频电源波动。HVAC 现场有大量感性负载，继电器动作瞬间会产生很大的电流冲击，去耦电容不能省。

地址引脚直接通过 0Ω 电阻或跳线接到 GND/VDD，方便现场改地址。报警输出引脚如果不使用，可以悬空或接上拉电阻，避免干扰。

PCB 布局上有个容易踩的坑：I2C 走线不要和继电器驱动线、PWM 电机线平行走长距离。我在初版布局时把 SCL/SDA 走在了功率线旁边，结果继电器一吸合温度读数就跳，后来重新调整走线才解决。数字传感器抗干扰不等于 PCB 可以随便画，现场大电流回路的干扰能力远超想象。

3.2 I2C初始化与传感器寄存器通讯实现

STM32F373VC 的 I2C 外设使用标准库或 HAL 配置都可以。我这里以寄存器操作风格给出初始化代码，核心是配置 GPIO 复用为开漏输出、使能上拉、设置 400kHz 时钟。

void PJ85_I2C_Init(void) { GPIO_InitTypeDef gpio; I2C_InitTypeDef i2c; RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOB, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE); /* PB8 = I2C1_SCL, PB9 = I2C1_SDA, 复用开漏, 带上拉 */ GPIO_PinAFConfig(GPIOB, GPIO_PinSource8, GPIO_AF_4); GPIO_PinAFConfig(GPIOB, GPIO_PinSource9, GPIO_AF_4); gpio.GPIO_Pin = GPIO_Pin_8 | GPIO_Pin_9; gpio.GPIO_Mode = GPIO_Mode_AF; gpio.GPIO_OType = GPIO_OType_OD; gpio.GPIO_PuPd = GPIO_PuPd_UP; gpio.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOB, &gpio); RCC_APB1PeriphResetCmd(RCC_APB1Periph_I2C1, ENABLE); RCC_APB1PeriphResetCmd(RCC_APB1Periph_I2C1, DISABLE); i2c.I2C_ClockSpeed = 400000; i2c.I2C_Mode = I2C_Mode_I2C; i2c.I2C_DutyCycle = I2C_DutyCycle_2; i2c.I2C_OwnAddress1 = 0x00; i2c.I2C_Ack = I2C_Ack_Enable; i2c.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit; I2C_Init(I2C1, &i2c); I2C_Cmd(I2C1, ENABLE); }

读取温度的核心操作是向传感器写入寄存器地址，然后连续读取 2 个字节。我封装了一个带超时和错误码的读取函数：

#define PJ85_I2C_ADDR 0x48 #define PJ85_REG_TEMP 0x00 int16_t PJ85_ReadTempRaw(void) { uint8_t cmd = PJ85_REG_TEMP; uint8_t buf[2]; uint16_t timeout = 0; /* 写寄存器地址 */ while (I2C_GetFlagStatus(I2C1, I2C_FLAG_BUSY)) { if (++timeout > 10000) return -1; } I2C_GenerateSTART(I2C1, ENABLE); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)); I2C_Send7bitAddress(I2C1, PJ85_I2C_ADDR, I2C_Direction_Transmitter); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)); I2C_SendData(I2C1, cmd); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTED)); /* 重复起始, 读取 2 字节温度 */ I2C_GenerateSTART(I2C1, ENABLE); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)); I2C_Send7bitAddress(I2C1, PJ85_I2C_ADDR, I2C_Direction_Receiver); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_RECEIVER_MODE_SELECTED)); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_RECEIVED)); buf[0] = I2C_ReceiveData(I2C1); I2C_AcknowledgeConfig(I2C1, DISABLE); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_RECEIVED)); buf[1] = I2C_ReceiveData(I2C1); I2C_AcknowledgeConfig(I2C1, ENABLE); I2C_GenerateSTOP(I2C1, ENABLE); return (int16_t)((buf[0] << 8) | buf[1]); }

这里有个细节：读最后一个字节前要让 I2C 外设发出 NACK，告诉传感器“后面不用继续发了”，然后才能产生 STOP。很多新手在 I2C 通信上卡住，就是因为读最后一个字节时的 ACK/NACK 时序没处理好。另外，触发条件是要给初次读取留超时控制，不然 I2C 总线卡死会导致 MCU 死循环。

3.3 把原始值换算成可靠温度：数据转换与校验

PJ85718DM 的 16 位温度寄存器，低 12 位有效，数据格式是二进制补码，每个 LSB 代表 0.0078125°C。换算公式很简单：

float PJ85_ConvertToCelsius(int16_t raw) { return (float)raw * 0.0078125f; }

注意 raw 必须是有符号 16 位数，否则负温度会变成很大的正数。我举个具体例子：0x01CC 换算出来是 460 × 0.0078125 = 3.59375°C；如果是 0xFE34，那对应的是 -460，换算为 -3.59375°C。

工程上不能只做换算就完事，还要做数据有效性判断。我的方案是连续读取两次，如果两次结果差值绝对值大于设定阈值（比如 2°C），就认为本次读取异常，丢弃并重新采样。这个方法低成本但很有效，既能发现 I2C 通信错误，也能发现传感器正在转换中读到的不完整数据。

在正式使用前，一定要读一遍传感器自检或版本寄存器。PJ85718DM 一般会提供厂商 ID 或器件 ID 寄存器，上电初始化时读一次，核对是否符合预期值。这一步能快速排除传感器芯片虚焊、接错芯片、I2C 地址不对等问题，比直接读温度靠谱得多。

4. 远程温度监测的组网方式与数据链路设计

4.1 远程温度本质上是一条长数据链路

很多人把远程温度理解成“一个传感器，一根线，接到单片机”，这在距离近的时候没问题，一旦跨越几十米甚至上百米，就要把整个链路想清楚。远程温度系统的最小链路是：远端传感器 → 采集终端 → 通信介质 → 主控/上位机 → 人机界面或云平台。

在我的项目里，远程传感器并不直接挂在 STM32F373VC 的 I2C 上，而是由一个远程采集终端统一读取，终端通过 RS-485 总线把温度数据传给主控。主控侧看到的是一个协议报文，而不是某个传感器。这样做的最大好处是隔离了总线长度对 I2C 时序的影响，现场施工也简单，一条双绞线串起所有终端即可。

远程温度的数据流向不止是“读过来显示”，还要进入控制逻辑。HVAC 场景里，主控拿到多个远端温度后，可能要做平均、取最大、做温差比较，再决定风机转速和冷热水阀开度。这就要求数据结构上给每个节点分配唯一 ID，并且报文里带地址，否则数据会乱套。

4.2 组网方案对比与选型

远程温度可选的组网方式不少，我做了个对比表，直接给结论：

我选用 RS-485 作为远程温度总线，理由是 HVAC 项目里设备安装位置通常分散，但控制在几十米到几百米范围内，RS-485 的传输距离足够，两线制布线也很成熟，造价低。Modbus RTU 协议在暖通和工业领域几乎成了事实标准，后续接第三方上位机或者触摸屏都很方便。

如果你需要把温度数据送到远端监控中心，可以在 RS-485 总线上加一个协议转换网关，把 Modbus 转成以太网或者无线协议再上传。这种分层架构的好处是，温度采集网络内部不依赖复杂网络，即便外网断了，本地控制逻辑仍然能正常工作。

4.3 Modbus RTU从站实现与工程要点

主控 STM32F373VC 在 RS-485 总线上作为 Modbus 从站，响应上位机或网关的查询请求。Modbus RTU 的帧格式是：从站地址（1字节）、功能码（1字节）、数据区（N字节）、CRC16（2字节）。

我实现了一个最小可用的 Modbus 处理逻辑：收到完整一帧后校验 CRC，地址匹配则解析功能码。最常用的功能码是 0x03 读保持寄存器，我们把温度值和报警状态映射到寄存器列表里：

CRC16 计算是 Modbus 从站的必备代码，网上有很多实现，我直接用了查表法，速度最快。这里给出核心函数：

uint16_t Modbus_CRC16(uint8_t *buf, uint16_t len) { uint16_t crc = 0xFFFF; uint16_t i; uint8_t j; for (i = 0; i < len; i++) { crc ^= buf[i]; for (j = 0; j < 8; j++) { if (crc & 0x0001) crc = (crc >> 1) ^ 0xA001; else crc >>= 1; } } return crc; }

工程上有两个容易被忽视的点。第一，RS-485 收发器的方向控制引脚必须在发送前拉高、发送完拉低，不能一直处于发送状态，否则会占用总线，导致其他节点无法通信。第二，总线上首尾两个节点必须接 120Ω 终端匹配电阻，中间节点不能接。没有终端电阻时，总线信号反射会非常严重，距离稍长就会出现乱码。

4.4 HVAC联动报警逻辑：本地裁决+远程上报

远程温度不只是给上位机看的，主控自己也要根据温度做联动控制。我的逻辑设计原则是“本地裁决、远程上报”：温度阈值判断和控制动作放在 STM32F373VC 本地完成，即使上位机断线，设备也能独立工作；远程侧只负责显示、记录和高级策略下发。

报警阈值用可配置参数实现，保存在 MCU 的 Flash 模拟 EEPROM 区域。比如房间温度超过 30°C 就开启风机；超过 35°C 就报告警并全速运行。为了避免温度在阈值附近反复抖动导致继电器频繁吸合，必须加回差滞环，比如高温报警阈值为 35°C，则恢复阈值为 33°C，中间这 2°C 就是缓冲区间。

远程上报使用主动推送和被动轮询结合的方式。正常情况下，上位机通过 Modbus 周期轮询温度数据；当发生本地报警时，主控通过一个专门的报警寄存器位告诉上位机，同时点亮本地 LED、驱动报警继电器。这种设计既保证了可靠性，又不会让总线一直处于“主控不停广播”的混乱状态。

5. HVAC与嵌入式场景下的工程化细节：滤波、标定与功耗控制

5.1 温度滤波：滑动平均与中值滤波的配合

HVAC 设备启动时，大电流设备会引起电源波动；风机旋转带来的气流变化也会让温度传感器读数轻微跳动。直接拿原始温度做控制会导致输出不稳定，必须做滤波。

我采用“先中值后滑动平均”的两级处理。中值滤波对脉冲干扰非常有效，比如一次偶然的电磁干扰导致读数偏离 10°C，单纯滑动平均会被带偏好几秒，但中值滤波能直接把它剔除。滑动平均则负责平滑正常波动，让温度曲线看起来平顺，控制输出也稳定。

代码上维护一个环形缓冲区，每次有新值就替换最旧的值。中值取 5 点中的中间值，滑动平均对中值输出再做 4 次平均。这样滤波延迟大约在 100ms~200ms，对 HVAC 控制来说完全够用，又不会迟钝到漏报真实过热。

#define FILTER_DEPTH 5 int16_t temp_buf[FILTER_DEPTH]; uint8_t temp_idx = 0; float Temperature_Filter(float new_celsius) { int16_t sorted[FILTER_DEPTH]; int16_t raw = (int16_t)(new_celsius * 100); int16_t sum = 0; int16_t median; uint8_t i, j; temp_buf[temp_idx] = raw; temp_idx = (temp_idx + 1) % FILTER_DEPTH; /* 复制后冒泡排序, 取中位数 */ for (i = 0; i < FILTER_DEPTH; i++) sorted[i] = temp_buf[i]; for (i = 0; i < FILTER_DEPTH - 1; i++) { for (j = i + 1; j < FILTER_DEPTH; j++) { if (sorted[i] > sorted[j]) { int16_t t = sorted[i]; sorted[i] = sorted[j]; sorted[j] = t; } } } median = sorted[FILTER_DEPTH / 2]; /* 对中值再做简单滑动平均 */ for (i = 0; i < FILTER_DEPTH; i++) sum += temp_buf[i]; return ((float)(median + sum / FILTER_DEPTH)) / 200.0f + 0.0f; }

实际调试时我发现，滤波参数必须和采样周期匹配。如果采样周期是 100ms，5 点中值加 4 点平均，系统对真实温升的响应延迟约 0.5s，这已经是我能接受的极限。如果要做更快的过热保护，就得分出两路数据：一路滤波后做显示和远程上报，一路不滤波或轻滤波做保护判断。

5.2 现场标定：两点校准与偏差补偿公式

数字温度传感器出厂前做过校准，但装到 PCB 上以后，板内其他器件发热、传感器与测量对象之间的距离、外壳热阻都会引入系统偏差。HVAC 现场的标准做法是：在设备安装完成后，用参考温度计实测关键点温度，然后对传感器读数做偏移修正。

最常用的是两点校准。选取两个温差较大的测量点，比如 5°C 和 50°C，记录传感器读数 T1_sensor/T2_sensor 和参考值 T1_ref/T2_ref，然后计算线性修正系数：

k = (T2_ref - T1_ref) / (T2_sensor - T1_sensor) b = T1_ref - k * T1_sensor

修正后的温度 = k × 传感器读数 + b。k 值可以修正增益误差，b 值可以修正偏移误差。对于 HVAC 中 0~60°C 范围的测量，线性修正已经足够，不需要做高次曲线拟合。

我把 k 和 b 两个参数存放在 MCU 的参数区，提供串口命令在线修改。这里有个经验：出厂测试时不要把传感器紧贴大功率电阻或芯片表面，因为自热效应会带来额外误差。如果要测空气温度，传感器应该和热源之间留出空气间隙，或者用导热系数低的支架隔离。

5.3 功耗预算与长时间运行的稳定性策略

虽然 HVAC 设备大部分时间都是市电供电，功耗不是第一优先级，但嵌入式监测终端往往带电池备份，或者需要在断电后继续记录现场温度。功耗预算仍然要做。

PJ85718DM 支持单次转换模式：MCU 发送转换命令后，传感器完成一次转换进入低功耗状态。STM32F373VC 在主循环空闲时进入 Stop 模式，用定时器唤醒。这样的设计可以把整板平均功耗降到很低，在外部电源断电、由电池维持运行的情况下也能撑很长时间。

/* 进入停止模式前, 先把 I2C 外设时钟关闭 */ void Enter_LowPower(uint32_t sleep_ms) { I2C_Cmd(I2C1, DISABLE); PWR_EnterSTOPMode(PWR_Regulator_LowPower, PWR_STOPEntry_WFI); /* 唤醒后重新初始化 I2C 和时钟 */ SystemInit(); PJ85_I2C_Init(); }

长时间运行最重要的是喂狗和看门狗策略。STM32F373VC 内置独立看门狗（IWDG），主循环每周期清除一次。但要注意：如果主循环因为 I2C 卡死而停在等待循环里，看门狗反而救不了你。我采用的是“看门狗 + 通信超时”双保险：I2C 操作每次设置超时退出，Modbus 收发也设置帧超时，从而避免系统死锁。

6. 实测调试过程与典型问题排查

6.1 第一类问题：I2C通信完全失败的排查链路

项目调试中遇到最典型的问题是传感器读不到数据，现象是 I2C 读取函数一直超时，返回值始终是 -1。我的排查过程按这个顺序展开：

先用万用表量 SCL/SDA 对地电压。正常工作时空闲状态应该是高电平（因为有上拉电阻），如果量到 0V，说明总线被拉死了，要么是某颗器件把总线拉低，要么是 SCL/SDA 虚焊短路。接着量传感器电源引脚是否有 3.3V，很多“读不到数据”的问题其实是电源没供上。

如果电压正常，再用示波器看 I2C 波形。上电后执行初始化代码，应该能看到 START 信号、地址字节和 ACK。如果只有 START 之后什么都没有，通常是从机没有应答，需要检查地址是否匹配。这里有个细节：PJ85718DM 的 7 位地址左移一位才是 I2C 总线上的 8 位地址，很多错误是把这两个值搞混了。

我那次调试的根因总结出来有点尴尬：传感器地址引脚没接固定电平，悬空状态下地址不确定，导致主机发送的地址和传感器实际地址不匹配。把地址引脚用 0Ω 电阻接到 GND 后，瞬间恢复正常。所以画板时地址引脚一定要处理好缺省状态。

6.2 第二类问题：温度读数抖动的处理

另一种常见情况是温度能读出来，但数值上下跳动，幅度大的时候能到 1°C~2°C。这个问题在实验室里复现不了，一到现场就出现，干扰源通常是继电器或接触器线圈。

排查分三步：第一步，观察抖动是否和某个继电器动作同步。如果是同步的，大概率是电磁干扰耦合到 I2C 线缆或电源线上。第二步，用示波器测量传感器电源引脚，注意看继电器动作瞬间有没有尖峰，如果有，就需要加强去耦或调整 PCB 走线。第三步，核对 I2C 线缆长度和布线，如果 SCL/SDA 走了长飞线，建议改成屏蔽线，屏蔽层单端接地。

软件上也要配合。前面提到的中值滤波就是对抗这种脉冲干扰的利器，把 5 次采样取中位后，单次干扰脉冲会被直接丢弃。实测结果表明，滤波后温度波动从 ±1.5°C 降到了 ±0.1°C 以内，效果非常明显。硬件上我在传感器电源脚并联了 1μF 陶瓷电容和 0.1μF 高频电容，同时把 I2C 速率从 400kHz 降到 100kHz，稳定性进一步提升，代价是采样周期变长了一点，但 HVAC 场景完全能接受。

6.3 第三类问题：远程链路掉线与数据乱码

RS-485 在长距离传输时如果遇到乱码或者通信超时，我按下面几个方向排查。

先确认 A/B 线有没有接反。RS-485 是差分信号，A/B 接反时不会完全不通，但常常表现为通信极不稳定，时好时坏。再检查总线两端终端电阻，缺终端电阻时波形反射严重，表现在数据上就是偶发 CRC 错误。

CRC 错误还有一个隐蔽原因：波特率误差。如果 RS-485 收发器或 MCU 的串口波特率与实际设定偏差超过 2%，长数据帧就会出错，短帧反而不容易暴露。STM32F373VC 的串口波特率由外设时钟分频而来，要校准时钟源，避免用内部 RC 振荡器跑较高波特率。我的方案是：Modbus 波特率固定 9600，确保稳定优先，不追求高速。

通过串口助手抓包时，如果看到帧头正确但 CRC 校验不过，优先怀疑传输层干扰和主从波特率不一致；如果帧头都不对，则检查接线和终端电阻。远程链路调试最重要的是把问题分层：物理层问题先排除，再查协议层，不要上来就改代码。

6.4 留给后续项目的验证清单

项目收尾时我把所有验证项整理成了一张清单，后续硬件改版或新项目可以直接复用：

• 上电后读取 PJ85718DM 器件 ID 是否匹配
• 本地温度是否与参考温度计误差在 ±0.5°C 以内
• 连续运行 24 小时，温度波动是否小于 ±0.2°C
• 继电器动作时温度读数是否无明显跳变
• 远程总线断开一个节点，主控能否在设定超时时间内报警并继续运行
• Modbus 上位机读取所有寄存器数值是否正确
• 断电重启后，设备能否自动恢复通信，无需人工干预
• 电池供电模式下，整板功耗是否在预算范围内

每一项验证都要留下测试记录，尤其是温度偏差和波动范围这两个指标。很多项目在实验室看着没问题，一到现场就出岔子，往往是因为少了“长时间带载运行”和“干扰场景下运行”这两项测试。

最后再分享一个实用技巧：给传感器代码加一个轻量级的调试开关，通过串口打印每次的原始寄存器值、滤波前温度和滤波后温度。这样在现场出问题时，不用接仿真器也能清楚看到数据链路上从原始值到最终控制值每一步的变化情况，定位问题会快很多。温度采集看起来是个基础功能，但真正做得稳、做得可维护，靠的是这些工程细节的积累。