STM32与PJ85718DM协作：HVAC本地远程双路温度采集方案

在嵌入式系统里，温度往往是最容易被忽略、又最容易出幺蛾子的那一环。尤其是 HVAC 场景下，风管、压缩机、风机盘管、控制板堆在一个箱体里，既要看板子自己热不热，又要看远端探头量到的空气温度，两路数据还不能互相干扰。最近我调了一套方案，用 PJ85718DM 做温度前端，搭配 STM32L433RC 做主控，把"本地温度"和"远程温度"两条链路同时跑了起来。这篇文章就围绕这套结构，把硬件连接、固件处理、滤波标定和 HVAC 场景下的现场调试经验从头到尾梳理一遍，适合正在做楼宇自控、冷冻冷藏、嵌入式温控设备的朋友参考。

1. 这套系统到底要解决什么问题：本地温度与远程温度的区别

1.1 同样是测温，两个对象的脾气完全不同

很多初学者有个误区，觉得温度传感器嘛，接上去能读数就完事了。但在 HVAC 和嵌入式设备里，"本地"和"远程"的物理本质差别很大，处理逻辑完全不能混为一谈。

我做的这套系统里，PJ85718DM 的本地通道测的是主控板附近的温度，通常就是把测温元件做在同一个封装或紧贴 PCB 的位置。它反映的是电路板自身的热状态，受芯片功耗、周边电源发热影响很大。而远程通道接的是分布在设备其他位置的探头，比如风管里的空气温度、回水管表面温度、压缩机壳体温度。远程通道的信号要经过一段线缆从远处送到前端芯片，线长、线阻、外界电磁干扰都会叠加进去。

这两种温度的应用目的也不同：

• 本地温度主要是做热保护。板子上的电源、驱动芯片、MCU 如果长时间超温，寿命会明显缩短，所以本地温度要响应快、阈值准。
• 远程温度主要是做过程控制。HVAC 系统要知道实际空气或水侧温度，用来决定压缩机启停、风机转速、阀门开度。它对绝对准确度要求更高，但对瞬时跳变的容忍度可以稍放宽。

如果一套系统里只用一个传感器放在 PCB 上，测风管温度就得拉很长的线，引线误差和板温干扰都会被带进去；如果只测远端温度，板子已经热到快出问题了，系统还不知道。所以"本地 + 远程"并不是多余，而是两个维度的信息缺一不可。

1.2 从应用场景倒推硬件选型

我当时做选型时，手头有几个候选方案，最终还是定了 PJ85718DM + STM32L433RC 这套组合。理由主要有三点。

第一，PJ85718DM 这类温度前端芯片内部把本地感温元件和远程探头接口集成在一起，也就是说主控只需要通过一条总线去交换数据，不需要对模拟小信号做太多预处理。远程温度信号本质上是毫伏级的变化，如果让 MCU 的 ADC 直接去量，很容易被参考电压波动和走线噪声干扰；让前端芯片先做调理，再用数字接口送进 MCU，工程实现稳得多。

第二，STM32L433RC 是一颗超低功耗的 MCU，内部有灵活的时钟管理和多种低功耗模式，非常适合 HVAC 设备里那种"大部分时间休眠、周期性唤醒采样"的工作方式。它本身的 ADC 还可以留给其他模拟量用，比如湿度传感器、水压传感器，不用和温度采集抢资源。

第三，这套组合的跨电压域兼容性比较好。HVAC 控制板上常见的 3.3V 逻辑供电和模拟前端供电可以共用一个 LDO，简化电源树设计。

于是系统拓扑就很清晰了：PJ85718DM 放在控制板上采集本地温度，同时远端探头通过屏蔽线接到它；STM32L433RC 负责通过 I2C 或类似接口读回数据，做滤波、标定，再通过 RS485 或 UART 把温度值送给上位机或楼宇控制器。下面我从硬件开始，逐层往下拆。

2. PJ85718DM 和 STM32L433RC 怎么分工

2.1 前端芯片负责采集，MCU 负责处理

PJ85718DM 在我这套系统里承担的角色很明确：它只干测温相关的脏活累活。本地测温部分它内部集成了感温器件，远程部分它给外接二极管型探头提供激励电流并读出电压差，然后内部转换成温度数字量。主控端拿到的已经是能直接用的温度值，或者最多做一下进制换算。

选择这种"前端芯片数字输出"的方式，还有一个隐性好处：报警阈值可以在前端芯片上预设。也就是说，即使 MCU 处于休眠模式，前端芯片自己检测到温度越限，可以通过一个中断引脚把 MCU 叫醒。这个特性对低功耗 HVAC 控制器特别有用——系统平时没事就睡，温度异常了才进入完整处理流程，平均功耗非常低。

MCU 侧的任务则是：

• 初始化通信接口，周期性地发起温度读取；
• 剔除明显异常值，做滑动滤波和趋势判断；
• 根据本地、远程温度数据，控制风扇、继电器或输出报警；
• 通过通信接口把数据打包上传。

其实很好理解：前端芯片像个专业温度仪表，MCU 像个现场工程师。仪表负责把读数搞准，工程师负责看懂数据并决定下一步动作。

2.2 STM32L433RC 的资源折算

STM32L433RC 属于超低功耗系列中的中端型号，内核是 Cortex-M4，带 FPU 和 DSP 指令。在这套系统里，FPU 不一定大规模用得上，但跑温度滤波算法时浮点运算确实省心，不用自己做定点折算。

它的存储空间对这类应用绰绰有余。写一套 Modbus 协议栈、传感器驱动、滤波算法，再加几十条错误日志，程序量不会超过几十 KB。我习惯留出足够冗余，把诊断信息和标定参数都存下来，方便现场改配置。

引脚资源方面，L433RC 用 LQFP64 封装时 I/O 数量足够富裕，温度采集、继电器控制、数码显示、通信接口都能同时接。我实际分配下来，温度前端占一路 I2C 和一个中断脚，RS485 占一组 USART，显示部分占 SPI 或段码屏驱动，还剩了不少 GPIO 可以接拨码开关、状态灯。

因为 STM32L433RC 内部有独立电源域，我在布局时把模拟部分、数字部分、通信隔离部分的电源分开设计，保证前端测温芯片不会被 MCU 高速翻转的 IO 噪声带偏。这也是很多 HVAC 设备温度读数在现场乱跳的根源——不是传感器差，是板子布局和电源没处理好。

3. 硬件连接细节：电源、接口、去耦和探头走线

3.1 通信接口与电源基础连接

我在实际画板时，PJ85718DM 和 STM32L433RC 的连接关系很简单，核心信号就四根：电源、地、时钟、数据。如果芯片支持单总线或者带报警输出，再加一根中断线。

需要特别提醒的是 I2C 上拉电阻。很多开发者直接用 MCU 内部上拉，图省事，但内部上拉阻值普遍偏大，在较长 PCB 走线或带连接器的情况下上升沿会变缓，通信速率拉不上去，偶尔还会出现第一个字节读错。外部上拉我都按总线电容计算，通常用 4.7kΩ 起步，如果总线上挂的设备多、线长超过 20cm，改成 2.2kΩ 或 1.8kΩ 再实测波形。

电源去耦方面，PJ85718DM 的电源脚就近放一个 100nF 陶瓷电容，容值再大一点放 1μF 也可以。关键是要放在芯片同一面、尽量贴近引脚的位置。我曾经试过只在大电容旁边取电，读取的温度偶尔会抖个零点几度，后来把去耦电容贴到芯片背面才稳定。

另外，如果温度探头需要长距离走线，我建议在 PCB 的插座位置预留一个串联电阻或者滤波电容位。这个后面单独讲。

3.2 远程探头的走线与屏蔽处理

远程温度探头的处理是这套系统最需要用心的地方。PJ85718DM 的远程通道测的是传感器上的微弱信号变化，探头线一旦穿过强电区域，或者和压缩机电源线走同一线槽，读数基本不可能干净。

我现场遇到过一种典型情况：探头线走过变频器旁边，温度值开始周期性跳动，跳幅接近 1℃。用示波器看，干扰全部是 PWM 载频附近的尖峰。解决办法很土但很有效：换双绞屏蔽线，屏蔽层单端接地，并且在芯片输入端加一个小电容构成低通滤波。对于二极管式远程温度探头，带宽本来就不需要很宽，滤波之后读数值稳定很多。

如果选的是模拟电压输出的探头，比如常用的 NTC 分压方案，那么远程通道还要考虑分压电阻的精度和温漂。NTC 本身非线性严重，PJ85718DM 如果内部有校正表或者 MCU 查表分段拟合，就能把误差控制在可接受范围。没有校正表的话，工业级场合还是建议用数字式或二极管式探头，省下来的调试时间远大于省下的物料成本。

3.3 雷击与静电防护的前置设计

HVAC 设备安装在屋顶、户外机组、工厂车间时，探头电缆很容易变成天线，把静电和浪涌引到主板上。温度前端芯片位置靠前，最容易先受伤。

我不建议在主控板上只靠芯片内部保护，标准的做法是在探头插座处加共模电感或者 PTC 电阻，再并一个 TVS 管到地。TVS 的电压选择要略高于正常工作电压，又不能太高，否则保护触发不及时。信号线上的串联电阻值不需要太大，几十到几百欧姆即可，既能限流又不会明显影响测温精度。

有人会觉得这些是放大器该考虑的事，温度信号不是数字量吗？其实数字芯片内部模拟前端同样会因过压损坏。现场故障率最高的往往是这些看似不起眼的接口部分，多花几毛钱器件，能省掉日后一大半售后。

4. 初始化与数据读取：让 MCU 把温度“掏”出来

4.1 从底层初始化说起

我习惯先初始化 MCU 的时钟和电源，再接外设。STM32L433RC 上电后默认用 MSI 时钟，对低速外设完全够，不过 I2C 时序如果要跑得准确，我一般会把系统时钟切到 PLL 输出，再把 I2C 时钟配好。下面的代码片段展示了最基础的 I2C 初始化流程：

void i2c_init(void) { GPIO_InitTypeDef gpio = {0}; __HAL_RCC_GPIOB_CLK_ENABLE(); __HAL_RCC_I2C1_CLK_ENABLE(); gpio.Pin = GPIO_PIN_6 | GPIO_PIN_7; gpio.Mode = GPIO_MODE_AF_OD; gpio.Pull = GPIO_NOPULL; gpio.Speed = GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOB, &gpio); __HAL_RCC_GPIOA_CLK_ENABLE(); gpio.Pin = GPIO_PIN_5; gpio.Mode = GPIO_MODE_OUTPUT_PP; HAL_GPIO_Init(GPIOA, &gpio); // PA5 用于控制前端芯片的复位或使能 }

I2C 外设本身配置时，我比较关注时钟频率。温度采样不是高速业务，100kHz 标准模式都嫌快，400kHz 也没问题，关键是 SCL 时序要符合前端芯片手册的要求。稳妥起见，我总是把 I2C 启动信号、停止信号和重复启动部分检查清楚，因为很多“偶发读不到数据”的问题都出在这里。

4.2 读取温度寄存器的固件套路

PJ85718DM 一般会把本地温度和远程温度放在不同寄存器地址，有的芯片还需要先读取状态寄存器确认新数据就绪。我习惯写一个底层读函数，每次返回设备内部地址，再由上层决定读本地还是远程。

#define PJ85718DM_I2C_ADDR 0x48 // 根据实际芯片地址修改 #define REG_LOCAL_TEMP 0x00 #define REG_REMOTE_TEMP 0x01 #define REG_STATUS 0x02 uint8_t temp_read_reg(uint8_t reg, uint8_t *buf, uint8_t len) { HAL_StatusTypeDef status; status = HAL_I2C_Master_Transmit(&hi2c1, PJ85718DM_I2C_ADDR, &reg, 1, 100); if (status != HAL_OK) return 1; status = HAL_I2C_Master_Receive(&hi2c1, PJ85718DM_I2C_ADDR, buf, len, 100); if (status != HAL_OK) return 2; return 0; }

读完原始数据之后，温度换算公式因芯片而异。我的做法是：先取符号位，再把整数部分和小数部分分离。很多芯片输出的是 0.0625℃/LSB 或者类似的分辨率，把原始值乘以分辨率就是实际温度。

代码里还需要注意符号扩展。如果温度是负值，原始数据按补码存储，直接把无符号变量转成浮点数再乘分辨率，正负号可能错乱。我一开始在这个地方踩过坑：冬天调试室外机时显示 -40℃，处理器把负数当成大正数了。后来统一把所有温度相关变量声明为 int16_t，再转回 float，问题自然消失。

4.3 报警中断接入低功耗流程

STM32L433RC 的低功耗特性是我选择它的另一大原因。系统平时停在 Stop 模式，电流能降到微安级别。PJ85718DM 检测到温度越限时，通过 ALERT 引脚把 MCU 唤醒，MCU 再读一次温度并执行动作。

这时候硬件上有一个很小的细节：ALERT 引脚接到 MCU 的 EXTI 输入，注意选择支持在 Stop 模式下唤醒的引脚，并配置为上拉或下拉输入，防止悬空导致误触发。我还习惯在脚上并联一个几十皮法的电容，滤掉毛刺，避免温度刚过阈值上下抖动时反复唤醒 MCU。

一旦进入报警唤醒流程，我建议不要立刻按一次读数就做判断，而是快速连续读 3 次，每次间隔 200ms，取中间值。温度越限一般不会是一瞬间的毛刺，连续确认可以大幅减少误报警。

5. 温度数据处理：滤波、校准和标定

5.1 滑动平均和中值滤波怎么搭配

原始温度读数直接拿去用，往往会有抖动。因为温度本身就是个慢变量，瞬时噪声可能是电磁干扰、量化噪声或者探头接触不良。给 HVAC 控制器用，读数跳个 0.2℃ 可能没啥影响，但如果要参与 PID 调节或报警判断，信号必须平滑。

我用的组合策略是：先去极端值，再做滑动平均。

去极端值用中值滤波，窗口取 3 或 5 就够。如果连续 5 个采样点排序后取中间那个，偶尔的尖峰跳变会被丢出去。注意窗口不能太大，温度变化是渐变的，窗口太大会把真实温升趋势也滤掉，现场看到的现象就是压缩机已经启动半天了，显示值还在慢慢爬。

#define FILTER_WINDOW 5 static int16_t temp_filter(int16_t new_sample) { static int16_t history[FILTER_WINDOW]; static uint8_t idx; int16_t sorted[FILTER_WINDOW]; uint8_t i, j; history[idx] = new_sample; idx = (idx + 1) % FILTER_WINDOW; for (i = 0; i < FILTER_WINDOW; i++) sorted[i] = history[i]; // 简单冒泡排序，窗口小，不耗时间 for (i = 0; i < FILTER_WINDOW-1; i++) for (j = i+1; j < FILTER_WINDOW; j++) if (sorted[j] < sorted[i]) { int16_t t = sorted[i]; sorted[i] = sorted[j]; sorted[j] = t; } return sorted[FILTER_WINDOW / 2]; }

中值滤波之后再做递推滑动平均，平滑效果更好，同时算法简单，在固件里不占太多 CPU。不过滑动平均的响应速度变慢，所以我会根据本地和远程的用途设置不同系数：本地温度参与过温保护，平均窗口取 4；远程温度参与环境控制，平均窗口取 8。给温控系统用，宁可晚半分钟显示，也不要乱跳。

5.2 两点标定是怎么做的

传感器出厂时会有一致性误差，但对 HVAC 这种应用，通常希望把绝对误差控制在 ±0.5℃ 甚至更好。这时候需要做两点标定。

做法很简单：把探头放在稳定的 0℃ 冰水混合物中记录读数偏差，再放在 50℃ 或 70℃ 温水中记录偏差，然后线性校正。

// 假设已测出两个标定点 float cal_slope = (temp_hot_real - temp_cold_real) / (temp_hot_raw - temp_cold_raw); float cal_offset = temp_cold_real - cal_slope * temp_cold_raw; float temperature_real = cal_slope * temperature_raw + cal_offset;

需要注意的是，标定环境本身的温度计精度要比被标定系统高，至少高一个等级，否则标了个寂寞。我自己现场操作时用过标准水银温度计和经过送检的电子温度计，两者读数要先互相对一下，确认没差再开始标。

标定参数要存到非易失区，比如 STM32L433RC 内部 Flash 或者外部 EEPROM。每次上电读取标定参数后应用，不用重新烧程序就能整机标定，产线效率会高很多。

5.3 温度探头自热问题

自热是测温系统最容易忽略的误差源。探头在做电流激励时，自身会消耗一点功率，导致探头温度略高于被测介质。尤其远程探头放在静止空气中，散热条件差，自热误差会更明显。

避免办法是尽量降低激励电流。PJ85718DM 如果支持激励电流档位配置，优先选小档位。如果探头是 NTC，也要注意分压电阻上的工作电流，不要让整体功耗超过微安级别太多。我的经验值是：远程空气温度探头，激励电流造成的自热误差控制在 0.1℃ 以内，否则风管里测出来的温度会明显偏向偏高的方向。

6. HVAC 里的通信与低功耗管理

6.1 把温度数据发送到上位机或楼宇系统

单机读数只是第一步，HVAC 系统通常要把温度上传到集中控制器或者楼宇自控平台。最省事也最稳的方式是走 RS485 总线，用 Modbus 协议。STM32L433RC 的 USART 外设很成熟，外部加一颗 RS485 收发器即可。

通信帧的设计上，我不建议把原始寄存器值直接上发，而是在 MCU 里先算好实际温度值再发送，乘以 10 或 100 转成整数。比如 23.45℃，发送 2345 表示，上位机按整数运算不容易出事。Modbus 寄存器里可以这样规划：

如果没有现成的楼宇协议，直接 UART 输出 JSON 也不错，方便接网关或者二次开发板。但 JSON 解析对单片机有内存开销，建议只在调试接口上用，正式总线还是 Modbus 稳。

6.2 周期唤醒功耗测算

低功耗 HVAC 控制器，很多时候产品需求里有一条待机功耗指标。STM32L433RC 在 Stop 模式下电流能降到几个微安，PJ85718DM 是否进入低功耗模式也要看手册配置。我在项目里采用 1 秒唤醒一次、每 10 次唤醒读一次温度的周期。

唤醒后先处理通信事务，再执行温度读取和滤波，总共耗时控制在几毫秒内。这样平均电流仍然很低。实测下来，整板在 24V 供电转 3.3V 的情况下，待机功耗不超过几十毫瓦，对空调面板、风机盘管控制器这类设备完全够用。

关键点在于唤醒之后的流程要“快进快出”。不要在中断里处理大运算，也不要为了显示刷新而频繁唤醒。把温度采集和显示刷新分开：采集只取最新值放变量里，显示部分需要的时候再读变量，避免相互拖累。

6.3 多设备总线的地址冲突规避

一个工程里往往有多块控制板、多个温度采集器挂在同一条 RS485 总线上。新加入设备时如果地址重复，整个总线都会乱套。我在固件里做了一组拨码设置地址，程序运行时读拨码值再初始化通信协议，避免烧录时手工改地址改错。

同时，PJ85718DM 的 I2C 地址如果可以通过引脚配置，也建议在硬件上留出不同的地址选择方式。这样同一块板子在总线里插多颗前端芯片，也能分别寻址。硬件设计时留个小电阻组合选项，比程序上做复杂枚举灵活得多。

7. 现场调试容易踩的坑和排查路径

7.1 读数随负载变化的案例分析

我调试过程中遇到过一种很隐蔽的问题：风机制冷启动后，温度读数瞬间跳高 2℃，然后慢慢回落。一开始以为是传感器问题，换了新探头还是一样。后来用示波器同时抓电源轨和 SDA 线上的波形，才发现风扇继电器吸合的瞬间，电源上出现了一个十几毫秒的电压跌落，前端芯片供电波动导致读数短暂异常。

处理方案是两级：硬件上加钽电容和 LC 滤波，把瞬间压降缓冲掉；软件上在采样时间戳里避开继电器动作窗口。做法是继电器切换后先延时 50ms 再发起温度读取，并把动作后第一次读数从滤波队列中丢弃。温度是慢变量，完全没必要和继电器动作抢那几十毫秒。

这类问题排查的通用思路是：先观察故障是否伴随其他外设动作；如果是，优先怀疑电源相互干扰；再用示波器确认电源轨和通信信号；最后分别在硬件和软件上隔离，而不是盲目改滤波参数。

7.2 长线探头导致的数据随机跳变

远程探头线长超过 10 米时，经常遇到读数偶尔跳变。这时滤波器会把尖峰吃掉，显示是稳了，但报警判断会被影响，因为中值滤波窗口只有 3 到 5，漏掉一个尖峰还行，连续来几个尖峰就骗过滤波了。

正确做法是分层治理。首先用屏蔽双绞线，屏蔽层单端接地，避免地环路；其次在探头入口对地并联一个 10nF 到 100nF 电容；最后在固件中加入变化率限制：如果温度变化速度超过 1℃/秒，判定数据异常，连续异常计数达到 3 次才刷新数据，否则沿用旧值。

uint8_t temp_rate_check(int16_t old_val, int16_t new_val) { int16_t diff = new_val - old_val; if (diff > 25 || diff < -25) // 温度变化超过约1.5℃ return 0; return 1; }

这是给瞬时变化设了个紧箍咒。正常温度根本不可能在每秒采样间隔内猛跳这么多，一旦出现，基本是干扰或接触不良。

7.3 传感器故障与开路检测

HVAC 现场，探头断线、短路时有发生。PJ85718DM 这类芯片通常会有传感器故障标志，但固件不能只在上电时查一次，要定期检查。我的习惯是周期读取状态寄存器，并把故障次数累计，超过一定次数直接上报“传感器故障”，不推荐进入温控自动模式，防止设备因误判温度而烧坏压缩机。

代码逻辑大致是：

if (fault_count >= 5) { temp_status = SENSOR_FAULT; relay_compressor = OFF; } else if (temp_status == SENSOR_FAULT) { temp_status = SENSOR_REBOOT; }

这样处理的好处是，传感器恢复后系统不会立刻重新启动压缩机，而是先观察一段确认时间，避免现场设备反复抖动启停。

把 PJC85718DM 的故障标志和 MCU 侧的异常判断叠加起来，两重保险，比单纯信一个来源要可靠得多。

7.4 标定完过几天又偏了，问题多半不在传感器

还有一个让我印象很深的项目：标定好之后第二天再看，远程温度比标准表低了 0.8℃。换了探头、改了滤波，都没解决。最后查到原因是探头插座氧化导致接触电阻变大，影响微弱信号传输。

这个坑提醒我：现场连接器是温度采集系统最容易老化的一环。选型时尽量选镀金端子，接线端子压线要可靠，定期巡检时重新插拔一次连接器，能大幅缓解接触电阻漂移问题。现场维护手册里我都会注明这个保养步骤，别以为接线拧紧了就一劳永逸。

8. 这套方案后续可以怎么扩展

严格来说，这套方案做完，其实已经不只是“一个温度计”了。PJ85718DM 的本地通道如果配合 STM32L433RC 的内核温度传感器，可以做一个简单的双阈值保护：前端芯片管外部温度越限，MCU 内核传感器管芯片自身发热，两个维度互不冲突。

远程探头的数量如果只有一路不够用，可以把通道分配表扩展出来，比如一路接风管供风温度、一路接回风温度、一路接盘管表面温度。只要前端芯片支持多通道，MCU 侧只要增加寄存器地址映射就行，代码结构不需要大改。

另外，STM32L433RC 上我还留了一个醒来的低功耗定时器，可以把系统做成“正常时 5 秒报一次、异常时 1 秒报一次”的自适应上报。调整节奏、降低总线占用，对多点楼宇自控系统很有价值。

我个人的体会是，温度采集这类功能，硬件上只要认真处理布局、电源、探头走线，bug 就已经消失了一大半；固件上再做好滤波、标定、故障逻辑，基本就是一套能长期稳定运行的成熟方案。很多现场“温度不准”的售后问题，追到最后都不是算法算错，而是基础功夫没下够。把这套思路留在这里，希望对正在做 HVAC 或嵌入式温控的同行有点帮助。