基于PJ85718DM与STM32L081CB的低功耗HVAC温控系统设计

直接进入正题。前阵子给一套HVAC控制器做温控方案升级，要把冷媒管温和环境回风温度一起采集，还得兼顾功耗和成本，最后敲定了 PJ85718DM 这颗数字温度传感器配合 STM32L081CB 低功耗 MCU 来跑整个监测逻辑。这套组合在嵌入式和暖通场景里都挺有代表性，从硬件选型到固件实现踩了不少坑，花了些时间把整个调试过程捋顺了，拿出来分享给做温控、做物联网数据采集的朋友参考。

1. 项目拆解：为什么需要本地和远程两路温度

做 HVAC 或者嵌入式环境监测，温度从来不是单一数据。拿常见的精密空调或恒温恒湿机组来说，控制器本身在配电箱或者机组内部，但真正决定启停的是风管里的送回风温度、室外冷凝器温度、水管温度，这些探头位置离主控板往往有几米甚至十几米远。如果只测控制器本地温度，获取的是机箱内部的发热环境，跟实际被控对象根本不是一回事。所以“本地温度”和“远程温度”这两路数据必须同时存在，本地温度用来做设备保护和参考补偿，远程温度用来做真正的闭环控制。

选型阶段其实对比了几套方案。最开始考虑用 NTC 热敏电阻加运放调理电路，成本确实便宜，但问题在于每一路都需要单独的基准电阻、校准点和 ADC 通道，批次一致性也差，到了现场还要逐点标定，维护成本太高。后来也看过用热电阻 PT100 加变送器的方案，精度和稳定性够，但整套 BOM 体积大、功耗也高，用在嵌入式小板上不太划算。最终锁定了数字传感器方案，PJ85718DM 这颗芯片本身能够直接做远程温度采集，通信走 I2C 总线，只需两根线就能把远端的温度数据传到核心板，抗干扰能力比模拟量传输强得多，省掉了模拟前端的大量外围器件。

STM32L081CB 则是这套系统的控制大脑。这是 ARM Cortex-M0+ 内核的低功耗芯片，主频 32MHz 不算高，但在温控这种场景里完全够用。它的优势是低功耗模式非常丰富，尤其是 STOP 模式配合 RTC 定时唤醒，可以在两次采样之间让整个系统睡大觉，平均功耗压到微安级别，这对电池供电的嵌入式监测设备来说非常关键。即使 HVAC 控制器通常有外接电源，低功耗设计也能显著降低整机发热和电源负载，间接减少因温升带来的测量误差。

整套系统要解决的最终问题可以概括成一句话：用稳定可靠的数字链路，以较低功耗持续采集控制器本地和设备远端两路温度，并根据温度阈值和变化趋势驱动后续的执行机构或报警输出。适合的场景包括冷冻站控制柜、机房环境监控、配电柜温度预警、冷链运输箱体等，凡是需要“近处看护 + 远处测量”这套组合逻辑的，都可以直接套用这个设计思路。

2. 硬件架构与关键电路实现细节

2.1 电源系统设计：本地稳压与远端供电的取舍

主控板的电源输入范围设计得比较宽，9V 到 28V 直流都支持，内部用了一颗低静态功耗的 LDO 先把电压降到 3.3V，给 STM32L081CB、PJ85718DM 以及接口电路供电。这里有个值得强调的经验：LDO 的输入输出压差如果太大，功耗会全部转化为热量，导致板面温度升高。而我们要测的是环境温度，板子自身发热对传感器的影响是致命的隐患。所以布局时 LDO 尽量贴近板边或靠近散热过孔区域，同时 PJ85718DM 的本地测温探头要远离 LDO 和电源芯片至少 1.5 厘米以上，实测下来这个距离能让自热误差控制在 0.1℃ 量级。

远程传感器如果距离较远，线缆电阻会引入额外的压降。PJ85718DM 的工作电压允许低至 2.7V，只要确保远端传感器端的供电电压不低于这个值即可。为了稳妥，我给远程传感器的 VDD 和 GND 之间加了一个 4.7uF 的钽电容和 0.1uF 的陶瓷电容并联组合，既做低频稳压支撑，也滤除高频杂讯。另外信号线 SDA 和 SCL 各串了一个 330Ω 的终端电阻，如果线长超过 3 米，这个电阻还能跟线缆寄生电容组成低通滤波器，明显减小信号边沿的过冲。

2.2 本地温度传感器布局与热隔离技巧

PJ85718DM 的本地温度测量实际上测的是芯片自身管芯温度，如果直接贴在 PCB 上，测到的会是“板温”而不是“环境温度”，这对 HVAC 应用来说是不允许的。我采用的方案是：把本地温度传感器小板独立出来，通过 4Pin 排针与主控板连接，传感器小板上的铜皮面积尽量小，避免形成大面积吸热层，并且在小板背面开槽，减少热量从主控板传导过来。这样一来，传感器感受的就是探头附近的气流温度，而不是主板的热量。

如果对响应速度有更高要求，可以在传感器表面加一层薄薄的导热硅脂并贴到金属风管壁面，这样测到的就是管壁温度，反应速度比纯空气测量快很多。但需要注意，加了导热硅脂之后，传感器引脚和 PCB 焊盘的应力会增大，时间久了可能出现焊点开裂。这个场景下建议把传感器改用飞线引出，引脚套热缩管固定，机械可靠性会好很多。

2.3 远程传感器线缆选择与防护电路

远程温度探头的通信链路是这套系统里最容易出问题的地方。最初我用的普通四芯屏蔽线，屏蔽层单端接地，结果现场调试时发现数据偶尔会卡死，用示波器抓波形发现 SCL 线上有毛刺，幅值超过逻辑高电平阈值导致 I2C 状态机错乱。后来把屏蔽层改成在传感器端接地、主控端悬空，并且线上并联一个 2.2nF 的电容到地，干扰立刻压下去了。

另外 I2C 总线上的上拉电阻取值也要重新计算。近距离板载通信用 4.7kΩ 上拉没问题，但远程线缆一旦达到几米，4.7kΩ 加上线缆电容会导致信号上升沿变慢，极端情况下 SSDA 信号根本到不了高电平。综合线缆长度和芯片输入电容之后，我把上拉电阻调整到 2.2kΩ，配合 400kHz 通信速率，实测 5 米线缆下波形依然干净。这里有个规律要记牢：总线电容每增加 100pF，上拉电阻就应该往下降了约 1kΩ，具体取值需要根据示波器波形来定，不能照本宣科。

防护电路方面，远程接口处加了 TVS 二极管阵列，防止静电放电和感性负载的浪涌打坏芯片。HVAC 现场常有接触器、变频器启停，电网浪涌非常频繁，这一级防护必须加。TVS 选的是双向 5V 型号，放在连接器入口处，地端要与主控板的地平面保持低阻抗连接，否则防护效果大打折扣。

3. 固件实现：从寄存器配置到应用层逻辑

3.1 MCU 初始化与 I2C 外设配置

STM32L081CB 的初始化这一步比较讲究，尤其是引脚复用和时钟树配置。我用的 I2C1 外设，PB6 作为 SCL，PB7 作为 SDA，初始化时要把这两个引脚配置为开漏输出，不能设成推挽输出，否则 I2C 总线仲裁机制会被破坏。另外 GPIO 的上下拉都保持浮空，由外部上拉电阻来提供默认高电平。

时钟方面，系统主频跑 32MHz，APB1 总线时钟保持与系统时钟一致，这样 I2C 的时钟频率计算更直观。I2C 外设配置为 400kHz 快速模式，使能时钟延长功能，毕竟远程线缆的容性负载可能会让从机需要拉低时钟来延时，如果主控不支持时钟延长，从机根本没法正常通信。

下面是 I2C 初始化的核心代码片段，用的是 STM32CubeMX 加 HAL 库框架：

void MX_I2C1_Init(void) { I2C_HandleTypeDef hi2c1; hi2c1.Instance = I2C1; hi2c1.Init.ClockSpeed = 400000; hi2c1.Init.DutyCycle = I2C_DUTYCYCLE_2; hi2c1.Init.OwnAddress1 = 0; hi2c1.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT; hi2c1.Init.DualAddressMode = I2C_DUALADDRESS_DISABLE; hi2c1.Init.OwnAddress2 = 0; hi2c1.Init.GeneralCallMode = I2C_GENERALCALL_DISABLE; hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_DISABLE; if (HAL_I2C_Init(&hi2c1) != HAL_OK) { Error_Handler(); } }

注意NoStretchMode必须配成I2C_NOSTRETCH_DISABLE，也就是允许从机拉低时钟线。很多人图省事直接开 NoStretch，短距离通信也许没问题，远程传感器极大概率会出现随机卡死。

3.2 温度寄存器读取与数据转换

PJ85718DM 的寄存器映射不算复杂，关键在于读时序和转换时间控制。每次主机发起读操作之前，必须先写配置寄存器，设置分辨率模式和转换周期。读取温度数据的流程是：主机发器件地址加写方向，写入命令字到寄存器指针，然后重新发送器件地址加读方向，连续读取两个字节，一个是高字节、一个是低字节。PAUSE 模式下转换结果存在寄存器里，主机随时可读，不会因为读取操作影响测量精度。

转换方面，温度的 LSB 对应 0.01℃。也就是说，寄存器中的 signed 16 位整数直接除以 100 就是摄氏温度。这个处理逻辑要注意符号扩展，如果字节读出来是负数，一定要先转成 int16_t 再进行除法运算，否则转换结果会直接错掉。

我写了一个容错性比较强的读取函数：

float Read_Temperature(uint8_t addr) { uint8_t buf[2] = {0}; int16_t raw = 0; float temp = 0.0f; if (HAL_I2C_Mem_Read(&hi2c1, addr << 1, 0x00, I2C_MEMADD_SIZE_8BIT, buf, 2, 100) != HAL_OK) { return TEMP_ERR_READ_FAIL; } raw = (int16_t)((buf[0] << 8) | buf[1]); temp = raw / 100.0f; return temp; }

这里addr << 1是把 7 位器件地址左移一位加上读写标志位，HAL 库的数据结构必须要这样处理。还有一点值得提醒：I2C 读超时时间设定为 100ms 是留足了余量的，正常情况下满足远程传感器在总线重试机制下的最差响应时间，避免因为瞬时总线忙而误报读取失败。

3.3 本地与远程温度的数据融合策略

整个系统最有价值的地方在于本地和远程两路温度的数据融合逻辑。HVAC 控制不能只看单点温度就做决策，比如室外温度变化剧烈时，如果回风温度探头正好被太阳直射，读数就会虚高，这时候如果依据单点温度去控制冷阀，实际环境温度已经被过度制冷了。我在代码里采用了加权融合算法：

float fused_temp = local_temp * 0.3f + remote_temp * 0.7f;

这里权重的分配依据是应用场景的敏感度。如果主要用于设备保护，本地温度权重要调高，因为设备过热是主要的失效模式；如果主要用于环境温控，远端温度权重要占大头，本地温度只是辅助判断控制器自身发热状态。

实际工程中，我发现一味的固定权重在早晚温差大的时段会存在震荡。比如白天太阳辐射强，室外侧传感器读数偏高，到了夜间又偏低，单一权重无法兼顾两种工况。于是引入了动态权重修正：根据本地温度的变化率自动调整权重比例。当本地温度变化率超过 0.5℃/分钟 时，说明设备可能进入了高负载状态，此时设备保护优先，就把本地权重临时提高到 0.5 以上；当温度变化率平缓时，恢复正常权重。

另外加了一个简单的滑动平均滤波器来消除高频噪声干扰：

#define FILTER_LEN 5 float temp_filter[FILTER_LEN] = {0}; int filter_index = 0; float Temp_FilterUpdate(float new_value) { static float sum = 0.0f; sum -= temp_filter[filter_index]; sum += new_value; temp_filter[filter_index] = new_value; filter_index = (filter_index + 1) % FILTER_LEN; return sum / FILTER_LEN; }

这个 5 点滑动窗口在保持响应速度的同时，能把 50Hz 工频干扰和线缆感应噪声基本滤掉。如果现场干扰特别严重，可以把窗口加长到 10 点，但温度突变时响应会变慢，需要结合具体需求取舍。

3.4 告警触发与系统间通信协议

温度监测系统如果不做告警，就失去了存在的意义。我设计了两级告警逻辑：软件阈值告警和硬件中断告警。硬件中断由 PJ85718DM 的比较器寄存器实现，当温度超过上限寄存器预设值时，芯片会把 ALERT 引脚拉低，STM32 的外部中断输入检测到下降沿后进入低功耗唤醒流程。这种方式的优势是 MCU 不需要频繁轮询传感器，可以长时间待在 STOP 模式下，只在温度越限时才被唤醒。

软件层面的告警逻辑则要处理迟滞问题。直接设一个固定阈值的话，温度在阈值附近小幅波动会导致告警状态反复切换，这在 HVAC 系统里是绝对不允许的，会频繁启停风机或压缩机，大幅缩短设备寿命。我的做法是设置两个边界值：上限告警值比如 60℃，解除告警值设为 55℃。当温度上升到 60℃ 以上时进入告警状态，之后必须温度回落到 55℃ 以下才解除告警。5℃ 的死区足够避开正常波动。

上位机或者控制中心的通信通过标准 Modbus RTU 协议实现，预留了一路 UART 接口，波特率 9600，8 数据位、1 停止位、无校验。寄存器地址分配规则如下表：

温度值放大 100 倍再传输是为了兼容很多上位机组态软件不支持浮点数解析的情况，工程上非常常见。寄存器 0x0001 到 0x0003 都是只读，但 Modbus 的常规轮询指令可以对只读寄存器执行读操作，只要返回状态码正常就可以。

4. 实测数据与现场调试记录

4.1 模拟工况下的温度稳定性验证

在实验室环境做了三组测试：常温环境、恒温恒湿箱高温高湿环境、模拟温度骤变的低温环境。常温组将整块板卡放在防静电工作台上，传感器悬空，记录两路温度读数 6 小时。结果非常稳定，本地温度波动不超过 ±0.2℃，远程温度因为走线较长，波动略大，在 ±0.4℃ 左右，这在暖通控制场景里完全满足要求。

恒温恒湿箱测试时湿度调到 85%RH，温度设为 45℃，持续运行 4 小时后断电重启，再上电后系统能快速恢复正常采集。这个环节重点验证的是焊接工艺和防护层对高湿环境的耐受性，因为 HVAC 现场常有凝露，如果传感器焊盘裸露在外，长期在高湿环境中运行会有漏电风险。后来在量产版本的传感器焊盘区域做了涂覆处理，用的三防漆，效果改善明显。

低温骤变测试是将传感器突然从常温环境移入 0℃ 环境，记录恢复时间。不带滤波算法时，温度读数在 10 秒内能稳定到目标温度的 90%，带了 5 点滑动平均滤波后，稳定时间延长到 20 秒左右。这个响应速度对 HVAC 控制而言仍然够用，毕竟热惯性远大于电惯性。

4.2 现场干扰导致的 I2C 总线异常排查

现场调试遇到一个非常典型的故障：系统在客户现场运行一周后突然出现温度数值跳变，一会在 25℃ 上下，一会在 45℃ 左右跳。排查过程很有意思，抓 I2C 总线波形时发现 SCL 和 SDA 在通信间隙会出现小幅振荡，频率大概在 1MHz 左右。开始以为是电源噪声耦合进去的，换了稳压器加了更多滤波电容，问题依然存在，频谱结构不变。

后来用共模电流探头查找干扰源，发现干扰源来自变频风机的动力线，它在启动瞬间会产生强烈的共模噪声，通过线缆耦合进了远程传感器的信号线。解决办法是在远程传感器的电源输入端加了一个共模扼流圈，型号是 ACT45B，绕两圈，截止频率大概在 10MHz，正好能把这 1MHz 的振荡滤掉。问题彻底解决，再也没有复发。

这次排障给我的经验是：HVAC 现场和实验室环境完全是两个世界，变频器、继电器、接触器产生的干扰花样非常多。硬件设计阶段就应当在远程传感器接口处预留共模滤波器的位置，哪怕初期不贴装，也要留出焊盘，否则问题出现后要飞线整改，非常痛苦。

4.3 上拉电阻取值不当造成的通信偶发失败

还有一次是通信偶发失败的奇葩故障。系统运行大部分时间正常，但每隔几十分钟会出现一次读取超时，复位之后马上恢复。抓取超时瞬间的波形，发现 SCK 在第九个时钟周期之后 SDA 没有释放，从机一直拉着数据线不放。这种情况通常是主机在通信结束后没有正确发送停止条件，或者从机的状态机因为中间位错误被卡住。

实际原因定位为总线电容太大，导致 SCL 信号上升沿过慢，部分时钟周期的上升沿斜率不够陡峭，从机内部的边沿检测电路偶发性漏检了时钟边沿，最终状态错乱。把上拉电阻从 4.7kΩ 调整到 2.2kΩ，总线上升沿时间从原来的 1.2μs 下降到 400ns 左右，故障随即消失。这个替换动作在稳定复现故障的环境下一小时就能确认效果，但要在现场从间歇性故障中发现规律，还是费了不少工夫。

总结一个原则：I2C 总线上挂了多颗器件或者线缆较长时，上拉电阻的取值一定要用示波器确认波形，而不是照搬数据手册。数据手册里给的 4.7kΩ 适合板级通信，线缆超过 1 米之后，这个值基本不够用。

4.4 校准与零点漂移的处理技巧

PJ85718DM 出厂自带一定精度，但是长期使用后会出现零点漂移现象。特别是在温度剧烈交变的环境下，芯片封装内部的应力变化会导致零点偏移，漂移量大约为 ±1℃ 甚至更多。解决这个问题有两个思路：一种是依靠软件校准，每次开机时读取一个已知温度点，计算出偏移量并补偿到所有后续读数中，但实际环境中不太可能每次开机都有已知温度基准；另一种是定期做现场校准，拿标准水银温度计或者高精度铂电阻温度计作为参考源，把偏差量写入到芯片的偏移校准寄存器中。

实操中我更推荐第二种方式。PJ85718DM 提供了偏移校准寄存器，软件可以随时写入一个 16 位有符号数值，芯片会在最终输出之前自动加上这个偏移值。校准流程是：先把传感器和标准温度计放在同一恒温槽中，等待 30 分钟让热平衡充分建立，读取传感器原始温度值和标准值，计算出差值后写入校准寄存器，再等待 10 分钟验证校准效果。一般情况下两点校准（比如 0℃ 和 50℃）就能把误差修正到 ±0.3℃ 以内。

另外还发现一个现象：在长时间运行后，传感器读数会逐渐出现微小偏移，大概每天 0.05℃ 左右。这个量级在普通 HVAC 应用中根本无感，但是如果在实验室做精密控温，就需要引入上电自检和定期重新校准的逻辑。固件里我加了一个 30 天自动校准提醒功能，到期之后通过 Modbus 寄存器上报校准标志位，提醒现场工程师做复校。

5. 低功耗策略与电池供电场景的扩展思路

5.1 STM32L081CB 低功耗模式配置

如果项目要扩展到电池供电的无线温度记录仪场景，这套方案的功耗表现非常关键。STM32L081CB 的 STOP 模式在保留 SRAM 内容和 RTC 运行的条件下，典型功耗只有 0.29μA 左右。PJ85718DM 在待机模式下的功耗只有微安级别，两路传感器合计不超过 2μA。整个系统的平均功耗主要取决于唤醒周期。

我实现了这样一个低功耗循环过程：系统上电初始化，完成一次温度采集后立刻进入 STOP 模式，RTC 外部 32.768kHz 晶振保持运行，定时 10 秒唤醒一次执行采集和处理，完成后再次进入 STOP 模式。在 3.7V 锂电池供电的情况下，这套流程实测平均电流约 4.5μA，一个月下来消耗的电量约 3.2mAh，对比动辄 500mAh 以上的电池容量，续航可以按年来计算。

STOP 模式进入和退出的代码比较简单，但有一个细节非常容易踩坑：进入 STOP 之前必须关闭 I2C 外设时钟，否则唤醒后 I2C 状态会有残留，导致首次通信失败。在 HAL 库中，进入 STOP 模式会自动关闭外设时钟，但退出时不会自动恢复，需要在唤醒中断里重新调MX_I2C1_Init()或者重新使能外设时钟。如果不注意这一点，低功耗唤醒后的首轮采集几乎必然失败。

5.2 低功耗模式下温度采集时序调整

低功耗模式下温度的采样时序也需要调整。PJ85718DM 在高分辨率模式下完成一次转换需要约 500ms，如果每 10 秒唤醒一次，转换时间占用了唤醒周期的大部分，会增加有效工作时间段的平均电流。所以低功耗版本我选择把分辨率降低一档，转换时间缩短到约 100ms，温度分辨率为 0.05℃，对大多数应用来说精度已经足够。

同时把通信频率从 400kHz 降到了 100kHz。虽然通信时间变长了，但总通信电流基本一致，慢速通信对总线的容性负载容忍度更高，远程链路更可靠，这个交换很划算。低功耗与高可靠性的平衡，需要在这几个参数之间反复取舍，没有绝对的答案，只有针对具体场景最合适的配置。

6. 工程化落地要点与量产经验总结

6.1 PCB 布局与布线的最终建议

整体布局上，核心原则是所有高噪声元件（LDO、DC-DC、继电器驱动）和敏感元件（MCU、传感器模拟区）分离布局。我的板子分成了三个明确的功能区：电源区在主控板左下角，数字逻辑区在右下角，传感器接口区域分布在板边。这样布局的热方向是从电源区向板外散发，不会直吹传感器。

地平面不要随便开槽。曾经为了把数字地和模拟地隔开，在传感器区域下方开了个大口子，结果发现传感器读数噪声反而变大了，原因在于返回路径面积变大了，地阻抗跟着升高。后来我干脆把传感器区域的铜皮做成完整地平面，底部不布置走线，形成一个近乎理想的参考地，噪声显著下降。远距传感器的屏蔽层接这个地平面，效果比之前任何方案都好。

连接器选型上，远程传感器的接口使用 4Pin 带锁扣的连接器，避免振动环境中松脱。每一种连接器在出图前都让采购确认了供货周期和替代型号，这种做法在量产阶段救了不少次，因为芯片短缺导致料号停产的情况非常常见。

6.2 上电自检与看门狗机制

固件中加入上电自检逻辑，开机后先进行一次传感器复位命令，然后读取设备 ID 寄存器，确认通信链路正常后再进入正常运行状态。如果发现传感器不在线，主控板不会直接进入低功耗模式，而是通过板上指示灯给出错误代码闪烁，同时通过 Modbus 上报故障状态。这一设计避免了很多现场误判故障的情况，因为缺援传感器时系统没有一个明确的状态指示，工程师以为是主控坏了，实际上只是传感器连接器松了。

硬件看门狗使用了独立看门狗，超时时间为 4 秒。主程序在每次温度转换完成后喂狗。之所以不用窗口看门狗，是因为温度转换时间受分辨率影响而变化，如果窗口设置太窄反而容易误复位。独立看门狗是纯粹的减计数器，只要在主循环里定期刷新就行，可靠性最高。

6.3 关于长期稳定性的三点体会

这个项目做下来，最大的体会是：稳定性不是某一个环节导致的，而是所有环节叠加之后的综合结果。硬件上要保证电源干净、地平面完整、信号走线合规；固件上要保证读取逻辑有容错、有看门狗保护、有通信超时处理；系统上还要保证校准和防护措施到位。

第二点，HVAC 类应用对“可维护性”的要求甚至高于“先进性”。设备装上去是要连续运行五年十年的，普通工程师不需要理解 I2C 细节，但需要能通过一组简单的 LED 指示和 Modbus 寄存器表快速定位故障。所以每个功能模块都尽量提供了可观测的状态信息，这种设计原则对中小型项目帮助很大。

第三点，温度采集系统在交付之前一定要在接近真实工矿环境下做至少 72 小时的连续运行测试。测试时不要只看功能是否正常，还要记录每一次时间同步、每一次温度上报的间隔和数值偏差。这些数据是未来优化算法、排查现场问题的宝贵基线。当初第一批样板测试时记录的基线数据，后来在排查现场偶发故障时帮了大忙，很多问题通过比对基线和现场数据就能直接判断是传感器劣化还是环境干扰。

如果你也要做类似的 HWAC 温度监测或者需要采集本地和远端多路温度的嵌入式项目，这套基于 PJ85718DM 和 STM32L081CB 的方案可以作为直接参考的起点，硬件原理图和固件框架基本都能复用。按照这个思路走下来，从立项到稳定运行，我这边整体耗时大概一个月不到，最大的时间消耗是在现场干扰排查环节，而不是在代码编写上。希望你少走这些弯路，一次就能把系统跑稳。