STM32+PJ85718DM实现HVAC本地远程1-Wire温度监测方案详解

做嵌入式项目这些年凡是要跟“环境控制”沾边的场景基本都绕不开温度监测。前阵子我在一个暖通HVAC项目里用 STM32F746VG 做主控搭配 PJ85718DM 数字温度传感器做了一套同时能覆盖本地和远程测点的温度监测方案。处理完之后回头复盘觉得这个组合其实很适合做嵌入式温度采集的入门到进阶参考——一个 MCU、一根总线、若干传感器就能把“本地温度”和“远程温度”分开部署和统一读取比起传统 NTC 方案省了无数布线也少了很多模拟回路的调试麻烦。这篇文章就把这个项目的完整思路拆开讲一遍从硬件选型、传感器通信原理到 STM32F746VG 上的驱动实现再到 HVAC 现场常见的安装和校准问题最后附上我自己的排障记录。无论你是刚接触 STM32 的开发者还是在给别人做楼宇自控、暖通空调系统改造都能在里面找到可以直接抄作业的部分。1. 项目总体拆解嵌入式与 HVAC 场景下为什么需要“本地 远程”温度监测1.1 HVAC 应用对温度监测的真实需求很多人会下意识觉得测温度嘛一个传感器就够了把数据读回来显示在屏上就完事。但在暖通系统里一套设备往往有多个温度参考点机组回风温度、送风温度、冷却水进出水温度、空调箱外环境温度、机柜内部温度……这些点的位置相隔可能只有几米也可能跨着几十米的风道和线槽。以我这次做的 HVAC 控制器为例本地温度要贴在主控板附近负责监测控制柜内部温升防止功率器件过热远程温度则要布到风管里测送风温度。如果只把温度探头都堆在主板上那测出来的只能叫“板温”跟实际风道温差可能差出好几度控制逻辑一参考错数据整个系统都在“盲调”。所以项目标题里“本地与远程”这六个字本质上是 HVAC 场景里最常见也最实用的一种测温拓扑主控本地一测点远程若干测点共享同一套采集链路。1.2 “本地”和“远程”在数据链路上的差异嵌入式系统内部所说的“本地温度”通常指传感器紧贴 MCU 电路板或紧挨电源模块走线短、信号强、干扰小读起来非常稳定。而“远程温度”则意味着传感器通过线缆延伸到设备外部——可能是风道里可能是外墙管道上——这时要考虑的就不是传感器本身能不能测温而是长距离传输会不会丢数据、压降会不会影响供电、外部电磁干扰会不会让通信不稳。这也是为什么我最终选了数字式一线制传感器 PJ85718DM而不是传统模拟 NTC 或 PT100。数字传感器在本地端和远程端用的是同一套协议远程传感器再接十几米线也依然稳定而模拟传感器一到远程基线漂移和线阻补偿就够你调一个月。1.3 为什么是 STM32F746VG 这颗主控STM32F746VG 在这套方案里其实有点“杀鸡用牛刀”的意味。它是一颗 Cortex-M7 内核、主频 216MHz、带浮点运算单元的高性能 MCU常规温度采集任务根本跑不满它的算力。我实际这么选的原因有两层一是为后续扩展留余地。HVAC 控制器里除了测温还要跑 PID 控温、阀位计算、触摸屏 UI、通信协议栈。STM32F746VG 的 SRAM 和 Flash 足够把这些统统塞进去做温度监测只是它工作的一部分。二是调试体验好。M7 内核调试断点响应快SWD 下载稳定程序跑飞了也容易定位。对我来说稳定的调试环境比算力更值钱。2. PJ85718DM 深度解读一线制温度传感器的原理与实战2.1 PJ85718DM 是什么它到底好在哪PJ85718DM 是一款数字温度传感器通信接口走一线制1-Wire协议跟经典的 DS18B20 指令集和时序兼容因此在网上能找到大量现成参考代码和成熟方案上手成本极低。它的典型分辨率为 12 位对应 0.0625°C 的温度分辨率测温范围覆盖常见的-55°C 到125°C在 HVAC 环境里完全够用。它最值钱的特点是“多点共总线”。一根 1-Wire 总线上可以同时挂多个 PJ85718DM每颗芯片出厂都有唯一 64 位 ROM 序列号主控通过地址区分不同传感器。这意味着我可以在远程风道里挂两颗、机柜里挂一颗、水管表面贴一颗最终只需要三根线或两根线回到主控施工成本大大降低。2.2 一线制总线的工作原理1-Wire 总线和 I2C 不一样它只有一根数据线 DQ数据通信和部分供电都在这根线上完成。总线的静态电平靠上拉电阻拉高通信时主机或从机通过拉低 DQ 来产生时序。因为总线是开漏结构所以同一根线上所有器件可以“线与”在一起。总线通信分三个基本动作复位脉冲主机拉低 DQ 至少 480us然后释放从机在释放后 60~240us 内拉低总线产生存在脉冲表示“我在这”。写时隙主机通过控制拉低时间长度来写 0 或写 1。写 1 时拉低总线后马上释放写 0 时拉低电平并保持 60us 左右。读时隙主机发起一个短拉低脉冲至少 1us随后立即释放总线并在 15us 内采样电平。从机如果返回 1 就保持高电平返回 0 就把总线拉低。这套时序的关键在于时间窗口。快 1us 慢 1us 都可能读到错误数据很多人第一次写 1-Wire 驱动就是从读回 0xFF 开始的。2.3 温度数据的格式与换算PJ85718DM 转换完成后温度值存放在芯片内部的暂存器Scratchpad中是 16 位有符号数。在默认 12 位模式下数据寄存器的高位在前最低位相当于小数部分。常用换算公式非常简单温度 原始值16位有符号 4如果直接用带符号整数右移后会丢掉小数所以更好的写法是float temp; int16_t raw (int16_t)(data[1] 8 | data[0]); temp raw * 0.0625;我举个例子读取到原始值 0x0191对应十进制 401乘以 0.0625 后得到 25.0625°C。如果是负温度原始值会是补码形式要先按照 int16_t 符号扩展再换算否则会出现一个大数值。2.4 硬件接法与上拉电阻的事PJ85718DM 跟 STM32F746VG 硬件连接非常简单传感器 DQ 接到一个 GPIO中间加一颗上拉电阻到 3.3V。VCC 和 GND 正常供电。上拉电阻的取值我在不同项目里试过几种场景推荐上拉阻值说明传感器贴在板子上线长30cm4.7kΩ默认值信号边沿干净传感器远程线长 5~20 米2.2kΩ更强驱动克服线缆容抗线长30米或恶劣干扰环境1kΩ边沿更陡但注意功耗略增注意上拉电阻太大长线分布电容会让信号边沿变软读时序时容易误判上拉电阻太小总线拉不低或功耗偏大。我一般以 4.7k 起步实测波形不满意再往下换。3. STM32F746VG 侧的硬件准备与底层驱动移植3.1 最小系统与引脚规划STM32F746VG 的引脚资源非常丰富我这里只列出温度监测最起码用到的部分DQ 数据线选任意 GPIO建议选带 FTFive-volt tolerant能力的引脚比如 PH 口或 PF 口方便以后兼容 5V 电平场景。供电3.3V 主电源给传感器单独加 0.1uF 去耦电容远程传感器可以在远端并联一个 10uF 电解电容。调试接口SWDIO / SWCLK标准四针。串口用来把温度数据打出去调试时看日志。尽管 STM32F746VG 内部有丰富的外设我却没打算用 USART 来做 1-Wire——因为 1-Wire 时序对时隙精度要求高用 GPIO 模拟反而最可控、最透明出问题好排查。3.2 GPIO 模拟 1-Wire 时序在 STM32F746VG 上模拟 1-Wire 时序核心是把引脚在两个方向之间切换输出模式下拉低输入模式或开漏输出并释放让上拉电阻把总线拉高。我用 HAL 库实现的最简驱动如下。先定义引脚宏#define OW_PORT GPIOG #define OW_PIN GPIO_PIN_9 #define OW_OUT_LOW() HAL_GPIO_WritePin(OW_PORT, OW_PIN, GPIO_PIN_RESET) #define OW_OUT_HIGH() HAL_GPIO_WritePin(OW_PORT, OW_PIN, GPIO_PIN_SET) #define OW_INPUT_MODE() HAL_GPIO_DeInit(OW_PORT, OW_PIN) #define OW_INPUT_READ() HAL_GPIO_ReadPin(OW_PORT, OW_PIN) void OW_Init(void) { GPIO_InitTypeDef gpio {0}; __HAL_RCC_GPIOG_CLK_ENABLE(); gpio.Pin GPIO_PIN_9; gpio.Mode GPIO_MODE_OUTPUT_OD; // 开漏输出 gpio.Pull GPIO_PULLUP; gpio.Speed GPIO_SPEED_FREQ_VERY_HIGH; HAL_GPIO_Init(OW_PORT, gpio); HAL_GPIO_WritePin(OW_PORT, OW_PIN, GPIO_PIN_SET); }开漏输出配上内部上拉再外加一个外部上拉电阻这样输出模式下拉、释放后自动恢复高电平逻辑非常干净。3.3 时隙级的延时控制STMF7 跑 216MHz循环里的空操作执行速度非常快直接用HAL_Delay()做微秒级延时误差太大。我建议用 DWTData Watchpoint and Trace实现微秒延时精确且不占定时器。static volatile uint32_t *DWT_CYCCNT (uint32_t *)0xE0001004; void DWT_Init(void) { CoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; *DWT_CYCCNT 0; } void delay_us_cpu(uint32_t us) { uint32_t start *DWT_CYCCNT; uint32_t ticks us * (SystemCoreClock / 1000000); while ((*DWT_CYCCNT - start) ticks); }提示SystemCoreClock必须等于实际主频。如果开了 PLL 后时钟配置没更新全局变量延时就会整体偏快或偏慢这是驱随时好时坏的常见原因。3.4 把远程传感器挂上总线的拓扑建议HVAC 项目里远程传感器通常在风道内走线我建议采用“菊花链”手拉手方式连接总线像一根树枝串过去而不是星型拓扑。星型连接会导致信号在不同支路反射某条支路长度不对称时通信质量会明显下降。远程走线最好使用带屏蔽的双绞线屏蔽层单端接地。DQ 线跟电源线尽量双绞降低环路面积。我这个项目里远程段最长走了约 12 米实测 2.2k 上拉 菊花链拓扑下通信非常稳定。4. 固件实现HAL 库架构下的温度采集主流程与关键代码4.1 单次温度转换与读取流程一次标准的温度读取流程分四步主机发送复位脉冲等待存在脉冲。发送 SKIP ROM0xCC跳过 ROM 匹配或发送匹配 ROM0x55指定设备。发送 CONVERT T0x44启动温度转换。等待转换结束12 位模式下约 750ms 上限再发送 READ SCRATCHPAD0xBE读回 9 个字节。代码里我把这四步封装成了函数uint8_t OW_Reset(void) { uint8_t presence 1; OW_OUT_LOW(); delay_us_cpu(480); OW_OUT_HIGH(); delay_us_cpu(70); OW_INPUT_MODE(); if (OW_INPUT_READ() 0) presence 0; delay_us_cpu(410); OW_OUT_HIGH(); return presence; } void OW_WriteByte(uint8_t byte) { for (int i 0; i 8; i) { if (byte 0x01) { OW_OUT_LOW(); delay_us_cpu(2); OW_OUT_HIGH(); delay_us_cpu(60); } else { OW_OUT_LOW(); delay_us_cpu(60); OW_OUT_HIGH(); delay_us_cpu(2); } byte 1; } } uint8_t OW_ReadByte(void) { uint8_t byte 0; for (int i 0; i 8; i) { byte 1; OW_OUT_LOW(); delay_us_cpu(2); OW_OUT_HIGH(); OW_INPUT_MODE(); delay_us_cpu(8); if (OW_INPUT_READ()) byte | 0x80; delay_us_cpu(50); } return byte; }4.2 多点挂载与 ROM 扫描如果想要同一根总线上区分多个传感器就必须读回每条传感器唯一的 64 位 ROM 序列号。标准做法是执行 ROM 搜索算法主机通过“读位 读互补位 写期望位”的循环过程逐位确认总线上每一位是 0、1 还是冲突位并据此遍历所有可能的分支。实际项目里我通常不在每次上电时都做全量 ROM 扫描因为遍历过程会消耗不少时间。更稳妥的做法是首次启动时扫描一次把所有传感器序列号保存到本地 Flash之后的正常运行直接用序列号匹配。除非现场人员更换传感器才手动触发重扫。4.3 多层滤波与采集周期管理温度值本身是慢变量传感器转换一次就要上百毫秒再加风道里的温度变化惯性很大完全不需要高速采样。我一般设置 1 秒一次采样周期连续取 4 次做去最值平均能有效滤掉偶发的电源纹波干扰。float filter_read_temperature(uint8_t index) { float vals[4]; for (int i 0; i 4; i) { vals[i] read_temperature_by_index(index); delay_ms(100); } // 简单冒泡排序 for (int i 0; i 3; i) for (int j 0; j 3 - i; j) if (vals[j] vals[j 1]) { float tmp vals[j]; vals[j] vals[j 1]; vals[j 1] tmp; } return (vals[1] vals[2]) / 2.0f; }4.4 数据出口与上层集成温度读出来后要交给上层业务逻辑。我这次给数据做了两层出口一是标准的 Modbus 寄存器映射方便 PLC 或上位机直接读取二是本地屏幕直接显示实时温度和曲线。Modbus 部分比较老套这里不多说——重点是把“温度采集”和“温度使用”隔离开上层只依赖数据结构不依赖底层驱动。typedef struct { uint8_t rom[8]; char tag[12]; float last_temperature; uint16_t crc_error_count; } sensor_node_t; sensor_node_t g_sensor_table[8]; uint8_t g_sensor_count 0;5. HVAC 现场的真实部署安装位置、热耦合与校准5.1 不同类型的测点选不同的传感器探头HVAC 现场测点千奇百怪但归纳起来就三类空气温度测点送风、回风、新风、排风。这类测点要求探头能跟空气充分接触最好加装防风罩避免局部气流直接冲刷造成读数跳动。管道表面温度测点冷媒管、热水管。传感器需要贴在管壁外侧并在外面包裹保温棉让探头跟管道形成热耦合同时隔绝环境温度干扰。机柜内部温度测点距离 MCU 发热源有一定距离但不能太远要能反映真实整机温升。我这次项目比较典型主板上一个本地传感器测机柜温度风道里两个远程传感器测送风。风道探头我特意加了不锈钢套管避免传感器塑料外壳直接暴露在高速气流中。5.2 传感器自发热与安装热阻问题数字传感器工作时本身也会消耗一点电流尤其是在转换期间大约会有 1mA 级别的电流流过芯片这会导致芯片内部温度略高于环境温度。如果传感器在密封套管里散热不良自发热可能造成 0.3~0.5°C 的正偏差校准后依然会受影响。规避办法有三个降低采样频率让转换占空比减小。1 秒采一次还是 10 秒采一次对 HVAC 控制来说差异不大但自发热会明显降低。加长探头导热路径让传感器芯片和外壳之间通过导热膏充分接触。校准后整个系统做偏移修正一次性补偿自发热。5.3 现场校准流程我在 HVAC 现场最常用的校准方法是“冰水两点法”。把传感器探头和标准温度计同时放进冰水混合物中等读数稳定后记录偏差。再放到 40°C 左右的恒温水浴或空调送风口用标准表读数对比得到第二个偏差点。然后对每个传感器做一阶线性修正实际温度 读取温度 × 斜率 偏移注意校准一定要在现场安装好之后做因为线缆长度、接线端子引入的接触电阻会影响供电电压从而轻微改变内部基准。实验室里校准得再准到了现场线一长照样有偏差。5.4 多传感器的一致性问题多颗传感器出厂一致性通常不错但安装在同一个风道里不同位置的温度本身就有差异。所以做系统联调时不要以为是传感器偏差先确认两个探头的物理位置是不是真的处于同一温度场中。如果现场风道有弯头弯头前后温度都可能不同此时顺序保证“测点正确”比“读数一致”更重要。6. 常见问题与调试实录6.1 远程传感器偶发“读不到”或“返回 0xFF”这是 1-Wire 项目里最常见的坑。我遇到过几次总结下来就两类原因第一总线上挂的设备太多或线太长上拉电阻过大导致信号边沿太软主控在读时隙窗口采样时读到高电平。解决方法是换小一点的上拉电阻比如从 4.7k 换到 2.2k。第二电源供电不足。远程传感器如果采用寄生供电方式转换瞬间电流很大线缆压降会把 DQ 电瓶拖垮。我建议所有远程传感器都单独接 VCC 和 GND两根线供电DQ 一根线传数据必要时远端并电容。6.2 CRC 校验频繁失败1-Wire 协议自带 CRC 校验数据读回后如果 CRC 不对直接丢弃重读即可。但频繁出现 CRC 错误就不是偶然了八成是布线干扰或时序临界。常见解决方案在传感器电源引脚并联 0.1uF 和 10uF 电容。把 1-Wire 线缆远离变频器输出线和接触器线圈。缩短 DQ 线长度或在主控端加一个 RC 滤波电阻 100Ω 电容 100pF。我实际测试过把 DQ 线跟 220V 动力线平行走管 3 米CRC 错误率就从几乎为零上升到几分钟一次非常明显。6.3 温度读数漂移且跳动如果读数不是通信错误而是数值本身不稳定多半是传感器自身发热或探头固定不牢。排查步骤用手摸一下传感器外壳是否明显发热如果发热明显提高采样间隔。检查探头是否确实固定在管道表面有没有虚接触。用示波器看 DQ 波形是否毛刺过多毛刺可能会导致偶发读错位换算出来的温度就跳一下。6.4 常见问题速查表现象可能原因处理办法读取始终为 0xFF上拉电阻缺失或过大检查 DQ 上拉参考 4.7k偶发超时线缆走线与动力电缆平行分开走线或加屏蔽层CRC 错误多总线过载或干扰远端并电容缩短总线长度读数偏高 1°C 以上传感器自发热降低采样频率增加导热耦合读数偏低探头未与被测体充分接触使用导热硅脂和保温棉多个传感器读取均失败复位时序不正确检查延时基准 和 DQ 引脚是否开启开漏6.5 关于寄生供电最后提醒一句PJ85718DM 这类芯片通常支持寄生供电模式也就是 VDD 和 GND 短接仅靠 DQ 线上的寄生能量工作。这个模式在贴板近距离场景能省一根线看起来很香但在 HVAC 现场我强烈不建议用。因为远程线缆一旦超过两三米寄生电容和压降就会让芯片在转换阶段供电不足出现越来越多诡异问题。老老实实把 VCC 引过去是最省心的选择。我在这个项目里走的弯路多半是在“远距离供电”和“时序微调”上。如果你照着上面的电路和代码做下来发现读取还是不稳定建议用示波器抓一下复位脉冲和读时隙波形跟标准波形对一下。绝大多数问题都能在波形图上直接看出来比闷头改代码高效得多。最后再分享一个实用小技巧每颗传感器出厂都有唯一序列号你可以在焊接前先把每颗传感器的 ROM 码读出来记录在 Excel 里标上“送风 1”“回风 2”之类的物理位置。这样现场安装时不用拆探头去猜哪根线对应哪个位置做 Modbus 地址映射也顺手得多。这步看似不起眼后期联调能帮你省下大半天时间。