用PJ85718DM单总线温度传感器配合STM32F765ZI单片机做HVAC控制器的本地与远程温度监测是我最近在模拟项目X里验证过的一套方案。做嵌入式最怕什么怕客户说温度不对。温度一旦采集不准后面的控制全乱套。HVAC控制器既要盯住主控板本身有没有过热又要同时采集风管回风温度、送风温度和盘管供回水温度正好是典型的“本地远程”问题。这篇文章把选型、电路、时序驱动、标定滤波和现场排障的过程都整理出来给做嵌入式设备、暖通空调控制或者机房环境监控的朋友一个参考。这个项目里本地温度负责板卡自保护远程温度负责参与HVAC逻辑控制。两条单总线分别接不同端口等于在物理上做了隔离一条挂了不会拖垮另一条。下面直接进入正题先说清楚为什么会有“本地远程”这个需求再讲器件选型和电路然后给核心代码最后把现场踩过的坑列出来。1. 需求拆解为什么嵌入式与HVAC都要“本地远程”温度1.1 本地温度板卡自保护与系统稳定性本地温度指的是主控板上的温度重点不是测房间环境而是盯着板上发热源。嵌入式设备不是只跑逻辑就行板上的电源模块、MOS管、电机驱动芯片、甚至MCU自身都是热源。HVAC控制箱很多安装在配电间、吊顶、机房这类通风差的位置夏天箱内环境温度可能到50℃以上再加上主板自身功耗局部温度很容易超过器件规格。如果只依赖MCU内部温度传感器只能反映芯片结温而且精度比较一般装的位置也不可调整。所以我在PCB上单独放了一颗PJ85718DM靠近电源发热区域通过单总线读取。这颗传感器体积小、接线少可以贴放在任意需要关注的角落例如电感旁边、驱动器散热片附近。本地温度一旦超过阈值就立刻触发降频、报警或切断输出防止设备长期高温运行导致电解电容失效、焊点开裂、芯片性能下降。本地监测还有一个作用帮助判断远程温度数据是否可信。比如现场环境温度显示60℃而板载测温只有30℃这说明远程探头可能被太阳直晒、靠近热源或者安装位置有问题。两个温度互相印证比只看单一数据要踏实很多。1.2 远程温度HVAC环境控制的关键参数远程温度是HVAC系统真正用来做控制的数据。一个风机盘管控制器通常要测回风温度、送风温度、盘管冷水/热水供水温度和回水温度新风机组还要加测室外温度、混风温度。这些测点分布在风管、水管、房间天花板里距离主控板从几十厘米到几十米不等。这些温度直接参与控制逻辑。回风温度代表房间实际温度是风机转速和水阀开度的主反馈供回水温差反映盘管换热量用于判断冷热源是否足够送风温度则影响除湿和舒适度。如果某个温度点缺失或者跳变PID调节会乱房间温度就会跟着波动。所以远程温度采集必须可靠。一股脑把传感器并到一条总线上确实节省IO和线缆但长线、多节点、现场干扰都是麻烦。我在项目里把远程节点控制在8个以内线长最远25米用三线制供电一个人一条总线上拉完。事实证明只要硬件和时序处理到位单总线远程测温完全能用于HVAC控制。1.3 器件选型背后的逻辑为什么选PJ85718DM而不选常见的I2C传感器、SPI传感器或者PT100铂电阻最直接原因是单总线协议。PJ85718DM是单总线数字温度传感器测温范围覆盖-55℃到125℃12位分辨率下的精度满足HVAC控制要求分辨率最低可以做到0.0625℃。它自带64位序列号一条总线上挂多个节点每个节点可以独立寻址。工作电压范围宽3.0V到5.5V都能跑和STM32F765ZI的3.3V电平直接匹配不需要额外电平转换。对比一下几种常见测温方案方案优点缺点适用场景PJ85718DM单总线接线少、可并联多点、成本低长线时序敏感需要软件处理HVAC分散测点、板级测温I2C数字传感器地址少、速率中等地址有限、长线抗干扰差板级近距离测温SPI数字传感器速度快、带宽高接线多、占IO高速采集、多通道板级测温PT100铂电阻精度高、稳定性好调理电路贵、线缆成本高工业高精度测温对于HVAC控制器测温点是分散的精度要求并不是实验室级别0.5℃精度已经足够所以数字单总线是性价比很高的选择。STM32F765ZI选型则看重它性能余量大216MHz主频Cortex-M7内核双精度FPU跑控制算法、显示、通信都绰绰有余内置ADC和多个定时器方便扩展后续功能。单总线用GPIO模拟不占用专用外设IO资源仍然宽裕。2. 硬件设计与安装双总线分层架构2.1 本地传感器如何布置本地传感器我放在MCU电源区域附近具体是DC-DC电感和LDO散热焊盘旁边距离发热源大约5到10毫米不直接贴在电阻本体上否则读数会高出实际环境温度不少。DQ引脚接PB1VDD接3.3VGND接覆铜地在电源引脚旁放一个0.1uF去耦电容。总线上拉电阻用4.7kΩ。DQ线不用太长控制在5厘米以内所以上升沿很陡时序余量很大。传感器背面大面积敷铜接地帮助散热也让温度变化更平滑。这里有个容易犯的错不要把传感器放在PCB边缘或者靠近通风孔的位置否则冷风直吹会让本地测温偏低和实际器件温度产生较大偏差。我另外还利用了STM32F765ZI内部温度传感器做冗余。内部传感器读出的芯片结温和外部PJ85718DM读出板温做对比两者差值如果突然变大可以推断是散热异常或者传感器故障。内部传感器精度一般不直接参与HVAC控制只用于严重超温保护。2.2 远端传感器总线的拓扑与供电远程传感器总线接在PA4引脚上与本地PB1物理隔离。这样如果远端线缆被老鼠咬断、接线端子松脱、或者总线被雷击损坏本地温度监测仍然可以工作保护逻辑不会失效。远端节点采用三线制供电每个PJ85718DM的VDD和GND分别由现场24V转5V的电源模块供电DQ信号线单独拉回控制器。三线制比寄生供电可靠得多寄生供电虽然能省一根线但长线的寄生电容大单总线在传感转换期间需要的电流脉冲很容易把总线电压拉垮导致转换失败。实际做过对比超过5米后寄生供电几乎不可用。拓扑结构上建议走手拉手的菊花链而不是星形分布。星形连接会在分支处产生信号反射导致波形畸变尤其是远距离节点读回来的CRC经常出错。菊花链每个节点都是“前一个接后一个”信号路径单一阻抗一致性更好。如果现场布线已经定死只能星形我会建议把总线速度放慢一点并且在每个分支终端加上适当的上拉或端接电容但这不是理想方案。上拉电阻的选择跟线长有关。短距离用4.7kΩ没问题线长超过10米后总线电容增大上升沿变缓我会把上拉电阻降到2.2kΩ到25米左右直接换1kΩ。上拉电阻越小上升沿越陡但静态功耗会增大。PJ85718DM在DQ空闲时是高电平这条线上拉电流只有几个毫安级1kΩ对STM32F765ZI的IO驱动能力来说压力不大。2.3 长线传输与隔离注意事项HVAC现场不是干净实验室变频器、接触器、风机电机都是干扰源。单总线协议本身没有差分能力抗干扰全靠硬件和布线上做文章。信号线一定要用双绞线最好带屏蔽层。双绞线能抵消一部分共模干扰屏蔽层单端接地接在控制器侧的大地上不要两端都接否则屏蔽层会形成地环路低频干扰反而更严重。总线不要和变频器输出电缆平行走至少要离开20厘米必须交叉时垂直交叉不要长距离并排。在总线进入控制板的连接器附近加一颗TVS管和一个小电容滤波。TVS可以吸收静电和瞬态浪涌但要注意选择结电容小的型号否则会拖慢总线上升沿。电容也不宜过大我一般控制在100pF以内主要用来滤高频噪声。地电位差是远程测温里最容易忽略的问题。远端传感器如果由不同的电源模块供电而那个电源模块的地和控制板的地之间存在电位差总线上的信号就会叠加偏移电压导致读到的数据偶尔出错。最彻底的办法是加数字隔离器把单总线信号隔离开远端供电和控制板供电彻底分开。但单总线是双向半双工信号数字隔离器必须支持双向选型时要特别确认方向控制逻辑。如果现场距离不远电线都是走同一根线槽共地问题不严重可以不加隔离但一定要保证远端传感器电源的GND通过单独线缆回到控制板GND不要依赖屏蔽层或者机壳做地回路。3. 单总线驱动与数据处理把时序吃透3.1 从复位到读温度的标准流程PJ85718DM和经典单总线传感器一样主机必须严格按照时序通信先复位再发送ROM命令再发送功能命令。读一次温度的完整流程是复位总线等待传感器存在脉冲。发送跳过ROM命令0xCC表示当前总线上的所有传感器都执行后续命令。发送温度转换命令0x44。等待转换完成。12位分辨率下最长要750ms9位分辨率只要93.75ms。再次复位总线。发送跳过ROM命令0xCC。发送读暂存器命令0xBE。连续读取9个字节温度LSB、温度MSB、用户上限、用户下限、配置寄存器、三个保留字节、CRC校验字节。做CRC校验通过后提取温度值。温度数据是两个字节低字节在前。原始值是一个有符号16位数乘以0.0625就是实际温度。12位分辨率下每一位代表0.0625℃例如0x0190换算出来是25℃。如果原始值最高位是1说明是负温按照有符号数解析即可。Scratchpad里的配置寄存器可以设置分辨率。9位代表0.5℃步进转换时间93.75ms10位0.25℃步进187.5ms11位0.125℃步进375ms12位0.0625℃步进750ms。HVAC控制我建议直接用12位虽然转换时间长但控制周期通常是1秒完全够用。如果系统里同时要采集几十个点可以把所有传感器一起发转换命令让它们并行转换然后逐个读取时间就不是简单的累加。3.2 STM32F765ZI上的GPIO模拟时序实现STM32F765ZI没有硬件单总线外设所以要用GPIO模拟。主频216MHz下微秒级延时必须用硬件计数器不能用空循环加编译器优化那种办法。我用的是Cortex-M7内核自带的DWT计数器精度很高而且不受中断影响。要记得先使能DWT。代码如下以HAL库为例/* 单总线引脚配置 */ #define OW_PORT GPIOB #define OW_PIN GPIO_PIN_1 #define OW_EXT_PORT GPIOA #define OW_EXT_PIN GPIO_PIN_4 static void ow_delay_us(uint32_t us) { uint32_t start DWT-CYCCNT; uint32_t ticks us * (SystemCoreClock / 1000000U); while ((DWT-CYCCNT - start) ticks) { } } static void ow_set_output(void) { GPIO_InitTypeDef gpio {0}; gpio.Pin OW_PIN; gpio.Mode GPIO_MODE_OUTPUT_OD; gpio.Pull GPIO_PULLUP; gpio.Speed GPIO_SPEED_FREQ_VERY_HIGH; HAL_GPIO_Init(OW_PORT, gpio); } static void ow_set_input(void) { GPIO_InitTypeDef gpio {0}; gpio.Pin OW_PIN; gpio.Mode GPIO_MODE_INPUT; gpio.Pull GPIO_PULLUP; HAL_GPIO_Init(OW_PORT, gpio); } static void ow_write_bit(uint8_t bit) { ow_set_output(); HAL_GPIO_WritePin(OW_PORT, OW_PIN, GPIO_PIN_RESET); if (bit) { /* 写1拉低2us然后释放 */ ow_delay_us(2); HAL_GPIO_WritePin(OW_PORT, OW_PIN, GPIO_PIN_SET); ow_delay_us(60); } else { /* 写0拉低60us */ ow_delay_us(60); HAL_GPIO_WritePin(OW_PORT, OW_PIN, GPIO_PIN_SET); ow_delay_us(2); } } static uint8_t ow_read_bit(void) { uint8_t val 0; ow_set_output(); HAL_GPIO_WritePin(OW_PORT, OW_PIN, GPIO_PIN_RESET); ow_delay_us(2); ow_set_input(); ow_delay_us(6); val HAL_GPIO_ReadPin(OW_PORT, OW_PIN); ow_delay_us(50); return val; } static uint8_t ow_reset(void) { uint8_t presence 1; ow_set_output(); HAL_GPIO_WritePin(OW_PORT, OW_PIN, GPIO_PIN_RESET); ow_delay_us(480); HAL_GPIO_WritePin(OW_PORT, OW_PIN, GPIO_PIN_SET); ow_set_input(); ow_delay_us(60); presence HAL_GPIO_ReadPin(OW_PORT, OW_PIN); ow_delay_us(420); return (presence 0) ? 0 : 1; } static void ow_write_byte(uint8_t byte) { for (uint8_t i 0; i 8; i) { ow_write_bit((byte i) 0x01); } } static uint8_t ow_read_byte(void) { uint8_t val 0; for (uint8_t i 0; i 8; i) { if (ow_read_bit()) { val | (1 i); } } return val; }读取温度的代码可以这样写float read_temp_pj85718dm_local(void) { uint8_t data[9] {0}; int16_t raw; float temp; ow_reset(); ow_write_byte(0xCC); /* Skip ROM */ ow_write_byte(0x44); /* Convert T */ HAL_Delay(750); ow_reset(); ow_write_byte(0xCC); /* Skip ROM */ ow_write_byte(0xBE); /* Read Scratchpad */ for (uint8_t i 0; i 9; i) { data[i] ow_read_byte(); } if (crc8(data, 8) ! data[8]) { return -999.0f; /* 错误标志 */ } raw (int16_t)((data[1] 8) | data[0]); temp raw * 0.0625f; return temp; }有几个细节容易被忽略。单总线通信期间任何中断都可能导致时序拉长传感器就会判错。所以关键时序段最好关闭中断或者确保中断服务函数足够短。我在实际代码里把延时和读写位操作都放进了临界区只在读取结束后恢复中断。GPIO方向切换也要注意每次复位前都要把IO切到输出模式并且拉低如果一直保持输入模式总线是释放状态复位脉冲根本拉不下去传感器芯片也就永远不会响应。CRC校验函数是单总线协议的标准多项式0x8C网上可以找到现成实现。不要为了省代码跳过CRCHVAC系统里只要有一个节点误码温度数据就可能从25℃跳成85℃这是不能接受的。3.3 多节点编号与多点温度采集状态机PJ85718DM每颗芯片都有64位ROM序列号。多节点采集有两种方式每次都执行搜索ROM算法枚举总线上所有传感器或者在生产调试时把每个物理位置的ROM序列号读出来存进配置表运行时用匹配ROM命令直接寻址。我推荐后面这种方式。搜索ROM算法代码量大每次上电都要跑而且如果总线上一颗传感器时好时坏搜索过程很容易卡死或者漏设备。固定点位时把序列号和安装位置绑定运行逻辑简单得多。匹配ROM命令是0x55后面跟8个字节的序列号总线上的传感器会比对ID只有匹配的那个节点响应后续命令。采集状态机这样设计typedef enum { TEMP_STATE_IDLE, TEMP_STATE_CONVERT, TEMP_STATE_WAIT, TEMP_STATE_READ, TEMP_STATE_UPDATE } temp_state_t; void temp_task(temp_state_t *state, uint32_t tick_ms) { switch (*state) { case TEMP_STATE_IDLE: ow_reset(); ow_write_byte(0xCC); /* Skip ROM */ ow_write_byte(0x44); /* Convert T */ *state TEMP_STATE_WAIT; break; case TEMP_STATE_WAIT: if (tick_ms 750) { *state TEMP_STATE_READ; } break; case TEMP_STATE_READ: /* 对每个传感器ID执行匹配ROM然后读取Scratchpad */ for (uint8_t id 0; id node_num; id) { ow_reset(); ow_write_byte(0x55); /* Match ROM */ for (uint8_t i 0; i 8; i) { ow_write_byte(id_table[id][i]); } ow_write_byte(0xBE); /* Read Scratchpad */ /* 读取9字节并做CRC校验 */ } *state TEMP_STATE_UPDATE; break; case TEMP_STATE_UPDATE: /* 更新温度表、报警标志 */ *state TEMP_STATE_IDLE; break; } }这样1秒读取一次所有温度点主循环其余时间可以用来跑显示、按键、通信、PID控制不会因为等待750ms转换时间而阻塞系统。4. 温度标定、滤波与HVAC联调4.1 温度校准与探头固定数字温度传感器出厂有精度但实际安装位置、探头封装、导热条件都会带来额外偏差。HVAC现场如果只是把裸芯片吊在风管里读数会有明显误差因为气流会带走热量。正确的做法是风管测回风、送风温度时把传感器放进专用的测温套管里套管内填充导热硅脂让传感器和管壁良好接触。铝合金套管响应速度快但要注意绝缘处理。水管温度测量用抱箍式安装把传感器紧贴在管外壁外面再包一层保温棉防止环境温度干扰。标定我建议做两步。第一步在常温下用精密温度计或恒温水浴比对记录每颗传感器的偏差值。第二步在控制板上电模拟现场热量做整体补偿。偏差可能来自探头安装位置比如传感器离吸顶灯太近读数会偏高1~2℃。每个人的安装工艺不一样工厂批次也不一样所以标定数据要跟随传感器ROM序列号保存。温度计算时temp_cal temp_raw offset_table[id];不要试图在电路上调整电阻值补偿软件偏移量简单可靠。4.2 数字滤波策略和参数选择长线单总线采集回来的数据偶发CRC错误可以靠重试解决但如果有轻微干扰导致错误恰好碰巧通过CRC就会变成跳变点。软件滤波必不可少。HVAC温度变化本身是缓慢的我用滑动平均和一阶低通两种组合。滑动平均对随机噪声好但对突发尖峰抑制作用弱中值滤波对尖峰效果好但会延迟反应时间。实际项目中我在每个温度通道加了3到5次中值滤波再套一阶低通。一阶低通的公式很简单float lpf_temp(float new_temp, float last_temp, float tau, float dt) { float alpha dt / (tau dt); return last_temp alpha * (new_temp - last_temp); }其中dt是采样周期tau是滤波时间常数。回风温度变化慢tau取10秒左右让数据平滑供回水温度变化稍快tau取3到5秒板级保护温度我基本不滤波最多去一下毛刺因为它要尽快反映超温。滤波参数不要一刀切要给每个通道配置单独的时间常数。滤波后的数据会带来控制滞后。PID参数标定时要把这个滞后考虑进去不然温度容易过冲。4.3 联调中的故障模式与冗余策略HVAC控制器不允许因为某个温度传感器故障就停机。所以联调时要明确每一路的故障行为。本地超温保护是最高优先级。当本地温度超过设定值比如85℃控制器立刻降频或者关断输出并且在人机界面上显示“板卡过温”。这个逻辑不依赖远程传感器即使后面全部传感器都断开保护依然有效。远程传感器故障时系统要进入安全模式。回风温度故障就不能盲目控风机我会把这个通道的值替换成送风温度或者上次有效值同时上报故障码。供水温度故障时水阀控制切到开环限制模式防止水温过高或过低。每个传感器连续读失败三次以上才判定故障避免单次通信干扰误报。我额外给远程总线做了双通道支持。如果默认的远程总线PA4连续30秒没有读到任何有效节点系统会自动切换到备用总线PB2去尝试当然备用总线下要再接一组传感器。这个成本增加不多但对长期稳定运行帮助很大尤其是现场总线接头容易被保洁员碰到松掉的情况。5. 常见问题速查与实测效果5.1 问题排查表格这里把项目中遇到过的问题整理成表排查思路可以直接照搬问题现象可能原因排查与解决一个传感器都读不到上拉电阻缺失、复位时序不对、电源没接用万用表量DQ静态电压应接近3.3V确认VDD和GND能读到本地远端全无远端总线供电不足、屏蔽层接地错误、拓扑星形分支改三线制有源供电换菊花链屏蔽层单端接地单个节点偶发CRC错误长线干扰、连接器氧化、上拉偏弱减小上拉电阻加TVS清洗端子降低为9位分辨率某个点温度一直异常跳变探头固定不良、靠近变频器电缆改善导热检查探头封装总线远离动力线读到的温度固定是85℃或-55℃数据全1或全0传感器可能损坏用替换法判断检查CRC重新上电复位本地温度比实际偏高很多传感器离热源太近、导热路径有问题移位增加空气隔离软件偏移修正排查的顺序永远是先硬件后软件。先看供电、接线、静态电压再用示波器看总线波形最后才怀疑代码逻辑。很多“时序不对”的问题实际是上拉电阻选得太大导致上升沿太缓。5.2 调试工具与抓时序的方法强烈建议准备一台采样率至少25MHz的逻辑分析仪。单总线的读写时隙都是微秒级25MHz采样能清楚看到每个时隙的高低电平宽度。我用逻辑分析仪抓复位和存在脉冲时能直接判断传感器有没有应答没应答时基本就是接线或者供电问题不用猜代码。示波器更好特别是看上升沿。把探头夹在DQ线上单总线拉低再释放后空闲电平要从0V爬回3.3V。如果上升沿超过10微秒传感器就容易误判成低电平结果就是读写全错。这时候把上拉电阻从4.7kΩ换成1kΩ波形立刻改善。我还习惯在每颗传感器头部加一段本地回环测试。软件跑一个自检模式连续读100次温度统计CRC错误率和温度波动范围。CRC错误率高于1%就说明总线硬件肯定有问题别调软件了去检查接线和干扰源。5.3 实测效果与经验总结模拟项目X里本地1个节点加远程8个节点最远线长25米12位分辨率读取周期1秒连续运行48小时远程温度数据全都在±0.3℃以内波动。把总线故意靠近一台变频器电缆后CRC错误率明显上升但软件三次重试加中值滤波后实际参与控制的温度依然平滑没有出现跳变。这个结果说明单总线系统只要在硬件上把上拉、屏蔽、接地做好完全能在HVAC现场稳定工作。如果再做一次这个项目我会在第一个版本就加入数字隔离器和双总线冗余调试后端现场能省很多事。整套系统最终实现了两个关键目标本地温度保护灵敏可靠远程温度数据稳定可控HVAC控制逻辑在真实工况下没有因为测点异常而停机重启。做温度监测最大的心得是传感器本身并不复杂但安装工艺、总线拓扑和软件时序这些“周边”才是决定成败的地方。先抓时序再调滤波最后才调PID这个顺序是踩过几次坑之后总结出来的。
