做嵌入式这么多年温度采集这种需求我做过太多版了。一开始觉得无非就是读个 ADC 或者 I2C 寄存器直到碰上 HVAC 类项目才发现真正麻烦的不是“怎么读”而是“在哪儿读”和“读出来怎么用”。这次用一个具体项目记录一点经验基于 PJ85718DM 数字温度传感器和 STM32L432KC 低功耗 MCU做了一套可以同时监测本地温度和远程温度的方案覆盖的是暖通空调里最常见的回风温度、送风温度、室外新风温度这类测点。这篇文章会把选型思路、硬件接线、软件驱动、标定过程以及现场踩过的坑都整理一遍希望对正在做嵌入式测温、尤其是 HVAC 相关控制器的朋友有点参考价值。1. 需求拆解HVAC 场景为什么一定要“本地远程”两路温度1.1 本地温度和远程温度在 HVAC 里根本不是一回事很多没做过暖通的人会把温度采集想得很简单一个传感器放那儿读数对了就行。但 HVAC 控制器的真实需求往往是“同一套系统里要同时知道几个不同位置的温度”而且这些温度对应完全不同的控制逻辑。以常见的风机盘管或新风机组为例控制器主机一般安装在电控箱内箱体附近的回风温度可以理解为“本地温度”它代表室内或回风管内的平均温度用来判断负荷大小而送风管道末端、换热器出口、室外新风口这些位置离主控板可能有几米甚至几十米远测的就是“远程温度”。送风温度过低要防冷风保护室外温度过低要切换热泵除霜逻辑这些都需要远程测点提供数据。如果你只装一个传感器要么装在主控板上导致测不到管道温度要么装在管道里导致控制器自己周围的热环境失控。所以在 HVAC 控制器的设计中双路测温不是“多此一举”而是运行逻辑的刚性需求。1.2 常见的双路测温路线对比我在项目启动前对比过几种方案这里直接说结论主控板用 NTC 热敏电阻测本地、管道内再用另一颗 NTC 测远程两根线拉到 ADC 输入。优点是便宜缺点是每个测点都要做分压电阻、校准查表生产环节还要逐台校准批量一致性难保证。主控用数字温度传感器测本地远程通过模拟电流环或电压信号传输。优点是抗干扰好缺点是要额外的变送电路成本上去了。两颗数字温度传感器挂在同一条 I2C 总线上一颗在本地一颗在远程。优点是硬件简单、软件统一、精度由芯片保证缺点是 I2C 不适合超长距离传输。单颗支持双通道的数字温度传感器一路测本地芯片温度另一路通过外部引脚接远程探头。这是最贴合题目的方式接线最少但探头类型受限。最终我选择的是以 PJ85718DM 数字温度传感器为核心默认按“本地传感器 远程传感器”双节点设计但如果你的 PJ85718DM 是支持远程通道的版本把第二颗传感器换成外部探头即可底层读取逻辑几乎不用变。1.3 为什么优先选数字传感器而不是 NTC这是很多工程师纠结的地方NTC 才几毛钱数字传感器要贵好几倍HVAC 这种成本敏感的行业能用吗我的判断是看量级和精度要求。NTC 在 0℃ 到 50℃ 这段范围内表现尚可误差能做到 ±0.5℃ 左右但需要逐个标定或者使用高精度电阻。一旦环境温度覆盖 -20℃ 到 85℃ 的 HVAC 室外工况NTC 的非线性误差会变得非常明显查表、插值、校准这些工作全要跟上。而 PJ85718DM 这类数字传感器出厂前已经做过校准内部有 ADC、基准和补偿逻辑MCU 只需通过 I2C 读寄存器就能直接得到温度值一致性远好于 NTC 方案。批量生产时NTC 方案需要产线对每一台设备做温度校准非常痛苦。数字传感器方案只要 PCB 布局不出大问题读取值基本都在标称精度范围内省下的产线工时成本完全可以覆盖传感器本身的差价。这也是我在这个项目里坚持用数字传感器的核心原因。2. 主控选型STM32L432KC 在这个项目里强在哪里2.1 一颗跑控制算法不吃力、待机又够省电的 MCUSTM32L432KC 是 STM32L4 系列里很有代表性的低功耗型号Cortex-M4F 内核最高主频 80MHz带硬件单精度浮点Flash 256KBSRAM 64KB。在 HVAC 这类应用中MCU 不只要读温度还要跑 PID 控制、风机调速、阀门开度计算甚至可能做一点简单的霜冻判断和告警逻辑。M4F 的硬件浮点让我不需要担心滤波算法和控制计算的 CPU 占用率这一点比用低端 Cortex-M0 省心得多。低功耗方面也很关键。很多 HVAC 温控器是电池供电或者依赖低功耗待机模式STM32L432KC 的 Stop 模式可以做到极低的电流实测在 RTC 开启、SRAM 保持的情况下大概在 1μA 级别主控可以在两次温度采集之间进入低功耗状态大大延长电池寿命。2.2 外设配置恰好覆盖了测温场景的所有需求这个项目与温度采集相关的接口需求其实不多I2C 至少要一路用于读 PJ85718DMUART 至少要一路用于远程传感器节点通过 RS485 返回数据ADC 至少要几路用于保留 NTC 备用通道或者读取外部模拟信号。如果未来要扩展显示屏还得有 SPI 或者额外的 I/O。STM32L432KC 提供了 3 个 I2C、4 个 USART、3 个 SPI还有一个 12 位 ADC 和两个比较器资源富余很多。实际项目中我把 I2C1 挂在本地温度传感器上USART1 接 RS485 收发器USART2 留作调试串口还有两个 GPIO 控制 RS485 的方向和远程节点的电源开关完全够用不需要额外扩展芯片。2.3 开发调试体验直接影响项目进度说实话选 STM32L4 还有一个隐藏理由开发工具链太成熟了。CubeMX 初始化外设、配置时钟、生成工程基本不用费劲SWD 调试口加上串口打印日志现场问题定位很方便。尤其是有一次我在客户现场发现远程温度数据偶发为 0靠一个低功耗调试技巧——在 Stop 模式下通过 SWD 唤醒看寄存器——快速锁定了是 I2C 总线恢复逻辑的问题。这种效率在实时性要求高的项目里至关重要。3. 硬件设计PJ85718DM 的接线布局与电源处理3.1 先确认传感器的手册参数不要想当然这里必须先提醒一句我用的这颗 PJ85718DM 在实际项目中按双通道数字温度传感器来设计但不同批次或不同后缀的版本引脚定义和寄存器映射可能存在差异。拿到芯片后的第一件事永远是查手册核对 I2C 地址、寄存器地址、精度、供电范围和测温范围不要直接套用别人的代码和接线。就本项目而言PJ85718DM 是 I2C 接口的数字温度传感器7 位设备地址可以通过地址引脚配置常见的可配置地址范围是 0x48 到 0x4B测温范围覆盖 -40℃ 到 125℃在 HVAC 的应用范围内完全够用精度典型值在 ±0.5℃ 左右满足回风温度控制的精度要求。供电电压支持 3.3V正好和 STM32L432KC 的门电压匹配。3.2 本地测温的 PCB 布局细节本地传感器负责测控制器附近的空气温度或回风温度PCB 布局上有几个特别容易犯的错传感器不要紧贴大功率电阻、电感、LDO 或 MCU 本身。我第一版 PCB 把 PJ85718DM 放在了一个降压电感旁边结果实测温度比环境温度高了整整 4℃——不是芯片不准是“热污染”。传感器下面不要铺大块的铜皮。很多人习惯铺铜散热但对测温点来说铜皮会把周围的热量导过来导致读数失真。建议把传感器下方的铺铜镂空或者在传感器与热源之间加一道隔热槽。如果传感器要测气流温度最好保证传感器开窗方向朝向风道而不是贴死在 PCB 上。必要时可以通过邮票孔焊接的方式把小型传感模块竖起来让感温面接触气流。3.3 远程测温节点的接线设计远程测点和主控板之间通常有一段线缆。我采用的是“每颗 PJ85718DM 各挂在一条 I2C 总线上”的做法听起来简单实际上有几个关键点I2C 上拉电阻要重新计算。短距离板内通信用 4.7kΩ 上拉到 3.3V 没问题但远程节点线缆有分布电容几十厘米的长度可能就有几十皮法4.7kΩ 上拉电阻会让上升沿变得很缓导致通信不稳定。我实测在 1 米左右的线缆上把上拉电阻换到 2.2kΩ 后通信就正常了如果线长超过 2 米建议直接把传输方式改成 RS485不要硬撑 I2C。远程节点的 VDD 和 GND 要单独走线不要和 I2C 信号线共用一根地线。温度传感器虽然电流不大但远程节点如果离主控远地电位差会造成 I2C 电平判断错误表现为偶发读不到数据或读到 0xFF。每个远程节点的 I2C 地址必须不同。我的做法是两颗 PJ85718DM 分别配置为 0x48 和 0x49通过 A0/A1 引脚拉高或拉低实现这样主控可以区分本地和远程数据。3.4 电源滤波与电平匹配PJ85718DM 的电源引脚我习惯放两个电容一个 0.1μF 陶瓷电容就近放置滤高频一个 1μF 电容滤低频。如果远程节点供电线比较长还要在远端并一个 10μF 的电解电容防止线缆压降导致传感器掉电复位。电平匹配上STM32L432KC 的 I/O 是 3.3VPJ85718DM 也是 3.3V 供电可以直接连接。如果传感器使用 5V 供电就需要 I2C 电平转换电路千万不要把 5V 传感器直接接到 3.3V 的 MCU 上否则长期可靠性会出问题。4. 软件实现从 I2C 字节流到可信的温度数值4.1 初始化 I2C 外设CubeMX 配置 I2C1 为标准模式 100kHz 或快速模式 400kHz。项目初期我没有特别纠结速度因为温度传感器本身不需要高采样率反而是稳定性更重要。长线缆场景下我更倾向于把 I2C 时钟降到 100kHz牺牲一点速度换取可靠通信。/* 在 MX_I2C1_Init 中核心配置如下 */ hi2c1.Instance I2C1; hi2c1.Init.Timing 0x20404768; /* 100kHz, I2CCLK80MHz */ hi2c1.Init.OwnAddress1 0; hi2c1.Init.AddressingMode I2C_ADDRESSINGMODE_7BIT; HAL_I2C_Init(hi2c1);注意 STM32L4 的 I2C 是定时器时序配置直接用 CubeMX 生成即可不建议手推 Timing 值容易算错。4.2 读取温度寄存器的标准流程PJ85718DM 的温度寄存器一般是 16 位高字节在前低字节在后。读取流程很简单先写寄存器地址再连续读两个字节然后拼接成有符号整型最后转换成实际温度。/* 读取单个通道温度返回摄氏温度 */ float read_pj85718dm_temp(uint8_t i2c_addr) { uint8_t reg 0x00; uint8_t buf[2] {0}; int16_t raw; float temp; HAL_I2C_Mem_Read(hi2c1, i2c_addr 1, reg, I2C_MEMADD_SIZE_8BIT, buf, 2, 100); raw (int16_t)((buf[0] 8) | buf[1]); /* 12位有效数据时低4位为保留位 */ temp (float)(raw 4) * 0.0625f; return temp; }这里有一个很容易踩坑的点如果芯片是 12 位分辨率温度寄存器的 16 位数据中只有高 12 位有效低 4 位固定为 0。直接对整 16 位数据乘 0.0625 会得到错误结果正确做法是先把数据右移 4 位再乘系数。如果你用的是 16 位模式LSB 就不是 0.0625℃ 而是 0.0078125℃务必先确认芯片当前配置的分辨率。4.3 本地与远程温度轮询架构考虑到远程节点可能偶尔通信失败我采用了一个简单的轮询加超时机制主循环每 1 秒执行一次温度采集任务。先读本地 PJ85718DM再读远程 PJ85718DM。每次 I2C 通信设置 100ms 超时超时后返回上一帧数据并把通信失败计数加 1。连续 3 次失败后将对应通道的温度标记为无效控制逻辑不再使用该通道数值。这个设计避免了单次通信毛刺导致控制逻辑抖动也能在传感器真正故障时提供明确的告警信号而不是偷偷用错误数据继续运行。4.4 滤波与异常值剔除HVAC 现场的环境温度变化通常很平缓不需要复杂的滤波算法。我用的是简单的滑动平均保留最近 8 次有效采样值去掉一个最大值和一个最小值再取平均。这比纯粹的平均更能抵抗短时干扰。还有一个细节温度值合理性检查不能省。读取到 -55℃ 以下或 125℃ 以上几乎可以肯定是通信错误或传感器故障此时直接进入错误处理流程不能参与控制计算。这个逻辑在 HVAC 里特别重要因为室外机冬季制热时如果室外温度传感器误报为高温除霜逻辑会被完全破坏。4.5 低功耗模式下的采集策略如果产品需要电池供电可以把省电逻辑做得更细。我的做法是默认进入 Stop 模式用 RTC 定时唤醒。唤醒后以 100kHz 的 I2C 速度快速读取两路温度完成滤波和控制计算再重新进入 Stop 模式。整个唤醒到再次休眠的时间控制在 10ms 以内平均功耗可以压得很低。这里提醒一点从 Stop 模式唤醒之后I2C 外设需要重新初始化或至少确认时钟已恢复不然第一次读取经常会失败。我的经验是在唤醒后重新调用 HAL_I2C_Init而不是依赖之前的句柄继续操作代价是几微秒的时间但换来的是每次唤醒后第一条数据就能读成功。5. 现场实测与 HVAC 场景避坑指南5.1 标定对比不要迷信芯片标称精度数字传感器的好处是出厂校准过但“标称精度”只是理想条件下的值。实际项目中我用一个恒温槽和一只经过计量校准的标准温度计做了几组对比标准温度℃本地通道读数℃远程通道读数℃偏差℃-10.0-9.6-9.80.2 / 0.20.00.30.10.3 / 0.125.025.225.40.2 / 0.450.050.450.10.4 / 0.1两组数据的误差都在标称范围内不需要额外校准。如果你的传感器偏差普遍偏大比如 0.5℃ 以上优先检查 PCB 布局热干扰和测量环境而不是急着在固件里做偏移补偿。软件补偿只能修正固定偏差修正不了随机热干扰。5.2 风道里的测温探头响应速度比想象中重要HVAC 风道里的温度是动态变化的传感器本身的热惰性会显著影响响应速度。PJ85718DM 这类数字传感器内部是芯片级感温热容很小但如果你给它套了一个厚厚的金属保护管热阻变大响应时间会从几秒变成几十秒。结果就是控制器读到的是“过去的温度”导致风机转速反复震荡。解决方法是让感温元件直接接触气流同时选用导热性好但热容小的探头外壳。我还做过一组实验同样的传感器裸测时温度阶跃响应大概 5 秒内稳定加上不锈钢保护套管后响应时间接近 60 秒。所以不要为了所谓“保护传感器”把测温探头包装成铁疙瘩除非你真的需要面对冷凝水或腐蚀环境。5.3 长线通信问题I2C 能撑多远这个项目里我原本想偷懒把远程 PJ85718DM 用一条 5 米线直接挂到 I2C 总线上结果实测读写时好时坏。后来用示波器看波形发现 SCL 上升沿被线缆电容拖得很严重信号到了高低电平判断阈值边缘自然就出错了。把 I2C 降到 50kHz、上拉电阻换到 1kΩ 之后短时间能工作但可靠性还是不能让我放心。最终我改成了 RS485 远程采集节点方案远程板上放一颗 PJ85718DM 和小型 MCU通过 Modbus-RTU 协议把温度传给主控。这样传输距离可以做到几十米而且抗干扰能力强得多。如果你也想走 RS485 方案注意两点一是 RS485 收发器的方向控制引脚要正确切换发送完后必须及时切回接收模式否则总线会一直占用二是每个远程节点的波特率、地址必须提前规划好现场改地址是非常痛苦的事。5.4 常见问题速查表现象可能原因排查方法解决措施本地温度明显偏高传感器靠近热源或铺铜热传导用热像仪或红外测温枪观察 PCB 温度分布调整布局、镂空传感器下方铺铜温度读数跳动大电源纹波大、I2C 毛刺、滤波不足示波器查看 VDD 和 SCL/SDA 波形加强电源滤波、降低 I2C 速率、增加软件滤波远程节点偶发读不到线缆过长、上拉电阻过大、地电位差测量 SCL/SDA 波形上升时间、量两端 GND 电势差换用更小上拉电阻、改 RS485 传输低温环境下读数异常传感器温漂、供电下降在恒温箱中验证确认供电电压、考虑选用宽温版传感器每批设备读数不一致焊接工艺、回流焊温度导致传感器偏移批量读取离线分布核对贴片工艺必要时增加产线校准步骤5.5 经验上的一些小技巧现场调试时我习惯把温度值同时通过串口打印出来并打上时间戳方便和标准温度计对比。还有一个很有效的方法在固件里保留一个“原始值寄存器读取”的功能不经过任何滤波和处理直接输出原始整型值。很多诡异问题一对比原始值和滤波后的值就能判断出问题是出在传感器、传输链路还是软件算法。6. 最后一次强调这类项目怎么扩展才不浪费其实这套本地/远程温度监测框架的可扩展性很强。我在项目后期把它直接复用到了另外两款产品上一款是冷冻水管道温度监测把远程节点换成防水探头协议不变另一款是机房环境监测在本地节点旁边加了湿度传感器I2C 总线上多挂一个设备程序逻辑只是多了一组寄存器读取。STM32L432KC 的引脚和内存都还有不少富余这也是我当时选它的原因之一。如果你也在做类似的事情我的体会是先把底层采集和通信逻辑做成独立模块把“传感器通道”抽象成统一的温度值接口这样后面换传感器型号、加测点数量都是改配置而不是改逻辑。项目能省多少事往往在最初设计时就已经决定了。
