基于STM32与PJ85718DM的HVAC双通道测温方案

做过嵌入式温控项目的人都有个体会：方案里最容易被低估的环节，往往就是温度采集本身。早前我在某商用暖通控制系统里做监测功能时，现场条件给得很直接——主控制板要实时读取板卡附近的环温，风机盘管那头还要再拉一根几米长的探头测风管温度，本地和远程两路温度得同时汇给上位机。整套系统最后是用 PJ85718DM 这类数字温度传感器搭配 STM32H743ZI 主控跑通的。后来过了老化柜测试，又跟了两个现场项目，本地和远程温度读得稳、上报也可靠，给暖通调试省了不少事。这篇文章就把我做这套方案的选型逻辑、硬件搭建、固件实现和现场踩坑完整拆开讲，给正在做嵌入式测温、控制器或者 HVAC 系统的工程师作个参考。

1. 选型思路：PJ85718DM 与 STM32H743ZI 的分工与优势

1.1 为什么温度监测不直接沿用模拟热敏电阻

很多设备做测温，第一反应是用 NTC 热敏电阻，原理简单、物料便宜，一颗电阻一颗电容就能搭出采样电路。但在 HVAC 这种要长期运行、现场环境又不干净的场景里，模拟方案会带来一连串麻烦：分压电路的参考电压精度直接决定测温误差，批量生产时每一路都要做分压电阻校准，线缆一长还会引入线阻误差和共模干扰。我在早期项目里用 NTC 吃过亏，传感器离主板超过 1 米之后，示波器上能看到明显的噪声叠加，查表和软件滤波只能补救一部分，很难真正做到全温区稳定。

PJ85718DM 这类单总线数字温度传感器把很多问题前置解决掉了——芯片内部自带温度采集和数字化电路，出厂前做了校准，主控只要按时序把数字量读回来就行。同样一颗芯片，既能焊在主板上做本地温度监测，也能做成远端正探头，通过线缆挂到几十米外。加上它支持单总线上挂多个器件，每个器件有独立识别码，一路 GPIO 就能管理多路测点，这对温控面板、风管探头、回风温度传感器这类多测点场景特别合适。实测下来，PJ85718DM 在 -20℃ 到 60℃ 这个暖通常用区间里，读数一致性比我手头那批 NTC 好很多，省掉了逐板校准的工序。

1.2 STM32H743ZI 在这条链路上到底承担了什么

如果只是为了读两路温度，用一颗 8 位单片机也够用。但 HVAC 控制器从来不是“只测温”的设备——它同时要跑风机调速、阀位控制、按键显示、通信协议栈，还要处理告警联动。STM32H743ZI 在这套方案里的价值，不只是因为它能驱动传感器，而是因为它有足够的算力和外设余量，让温度监测变成整个控制系统里一个可靠的后台任务。

这颗芯片是 Cortex-M7 内核，主频跑到 480MHz，带双精度硬件浮点单元。温度换算、滑动滤波、中值滤波这类运算对它来说负载很低，即使同时开着一个 Modbus 从站、一个 PWM 风机控制、一个 LCD 刷新，CPU 占用率也压得下来。外设层面，它有多路 UART、FDCAN、SPI、I2C，后续如果要接触摸屏、接楼宇自控总线、或者扩展更多传感器，都不用换主控方案。而且它内置了加密算法加速和大量 Flash/RAM，给固件后续迭代留了很宽裕的空间。简单说，选它不是因为“读温度必须用这么强的芯片”，而是因为整个设备需要一颗能兜住全局的主控，测温只是它工作的一部分。

1.3 本地与远程双通道的整体监控架构

整套测温链路的拓扑并不复杂：主控板上焊一颗 PJ85718DM，作为本地温度通道，测的是控制器周围的空气温度；风管或空调房间内再布置一颗或多颗远程探头，用线缆拉回主控板。这两路数据由 STM32H743ZI 周期轮询读取，经换算、滤波、故障判断后，通过串口或现场总线报给上位机。

本地通道的典型用途是补偿电子元件发热带来的温漂。比如功率器件附近温度升高，导致控制参数漂移，此时用本地温度做补偿最直接。远程通道的用途则是监控空调系统里真正需要关心的物理点，比如出风温度、回风温度、水管温度，帮助判断制冷制热效果。实际项目中，这两路往往是独立探头、独立测点，而不是同一个数据复制两份。把通道设计成“本地温感 + 远端正探头”还有一个好处：现场调试时，如果发现本地温度异常升高，能靠对比快速定位是传感器故障还是板卡过热，省掉不少判断时间。

2. 硬件链路搭建：本地探头、远程探头与长线传输细节

2.1 本地温度通道：传感器贴近 MCU 时的布局约束

本地传感器看起来只是“焊在板上就行”，但布局如果不讲究，读出来的数据会让人摸不着头脑。PJ85718DM 在 PCB 上的位置，要避开电源模块、大功率驱动芯片、变压器这些明显热源，不要为了走线方便直接塞到电源下方或 MCU 正旁边，否则传感器测到的不是板卡环境温度，而是某个发热器件的局部温度。

我在这块板上的处理方式，是把本地 PJ85718DM 放在板子边缘、远离发热区和通风孔的位置，同时尽量保持它和主控之间只有一条短走线。传感器底部如果覆盖大面积的铜皮，铜皮会变成散热片，导致温度响应变慢；所以我把芯片下方的铜皮做了局部挖空处理，让传感器更接近空气温度。板上热源是不可避免的，关键是让传感器处在板内“平均温度”的位置，而不是某个局部的热点旁。这样测出来的本地温升数据，对整机热设计才有真正的参考价值。

硬件接线方面，PJ85718DM 的电源脚建议直接接 3.3V 模拟电源区域，如果有条件可以从主电源先过一个磁珠再做隔离。单总线数据线需要接上拉电阻，常规取值在 4.7kΩ 左右。走线短时 10kΩ 也能工作，但一旦要考虑外接远程探头，4.7kΩ 是更稳妥的起点，后面长线场景还要再调。

2.2 远程温度通道：探头走线、接口保护与长线时序

远程探头是这套方案里最容易出问题的部分。现场风管温度探头通常要离开主板两三米甚至更远，线上的分布电容、外界电磁干扰、插头氧化都会直接影响单总线通信。我第一版样机用的是普通端子加两根跳线，结果在老化房里远程通道频繁读不到数据，最后发现是线缆电容导致信号沿变得太缓，再叠加现场变频器的干扰，总线时序直接被破坏。

后来的做法做了几处调整。远程探头线改用屏蔽双绞线，屏蔽层在主控板一侧单端接地，不两端都接，避免形成地环路；线径上选稍粗一点的导体，降低长线的直流电阻。探头端用了防反接插座，插座引脚旁边加 TVS 管和 ESD 防护器件，防止现场调试时带电插拔产生的浪涌损坏传感器。如果线长超过 10 米，我建议不要单纯依赖加大上拉电阻来提升驱动能力，而是考虑加一级总线缓冲芯片，把逻辑电平重新整形后再往后送，这样时序才有保证。

长线还有一个容易忽视的问题：上拉电阻的取值要和线缆电容匹配。线越长电容越大，上拉电阻太大时信号上升沿会变慢，导致主控判断电平出错；上拉电阻太小又会加大数据线驱动负担。以我的经验，3 米线缆配 4.7kΩ 通常没问题，超过 5 米建议降到 2.2kΩ 再实测，找到一个既能可靠拉高电平又不至于让低电平抬升的平衡点。最理想是有示波器看波形，没有示波器就靠反复读数据、统计误码率来判断。

2.3 供电去耦与地回路：精度杀手往往藏在电源里

温度传感器本身是数字器件，很多人会觉得它对电源噪声不敏感，但实际项目里，HVAC 设备旁边就是压缩机、风机、变频器，电源线上的毛刺非常夸张。PJ85718DM 的供电如果不加去耦，读数会出现间歇性跳变，尤其在压缩机启动瞬间，温度值可能直接跳高 1℃ 以上，靠软件滤波都难完全消除。

我在传感器电源脚旁边放了 0.1μF 陶瓷电容，本地传感器和一个 10μF 钽电容共用一个局部电源区域；远程探头的供电则通过板级 LDO 单独拉一路出来，并在接口处再放一个 0.1μF 电容。这样处理之后，现场实测的温度曲线干净很多，不会跟着压缩机启停一起波动。

地回路问题同样隐蔽。远程探头和主控板之间如果存在两条以上的地连接路径，比如探头地线接了结构件，结构件又通过别的地方和板子地相连，就会形成地环路。碰到这种情况，温度读数可能整体偏移零点几度。解决思路是让远程探头的地线只能在主控板接口处单点汇入系统地，其他任何金属接触点都不能无意间构成第二条回路。这个点在现场接线时尤其容易被忽略，因为“地线多点接”在万用表上量起来往往都是通断正常的，但实际工作状态完全不同。

3. 固件落地：驱动移植、温度换算与数据滤波

3.1 单总线底层驱动：时序精度决定通信成败

PJ85718DM 的底层通信时序是整个固件里最需要抠细节的地方。单总线协议的特点是“一根线既传数据又传时钟”，所有时序都以微秒级延时作为依据，一旦代码里被中断打断，通信就会失败。我用 STM32H743ZI 的 GPIO 模拟时序，用的是高优先级定时器中断做切换，读数据的临界段会暂时关闭可抢占中断，尽量保证时序稳定。

核心驱动大致分四步：复位总线、跳过 ROM 或匹配 ID、发送转换命令、读取暂存器。复位信号先把总线拉低一段时间再释放，然后读取设备的存在脉冲，没有这个脉冲就直接报传感器离线。读温度和写命令时，对不同宽度的时隙要严格计时，延时函数建议用 DWT 或 SysTick 做微秒级延时，不要直接依赖编译器优化后的空循环。

void onewire_write_bit(uint8_t bit) { if (bit) { HAL_GPIO_WritePin(OW_PORT, OW_PIN, GPIO_PIN_RESET); delay_us(6); HAL_GPIO_WritePin(OW_PORT, OW_PIN, GPIO_PIN_SET); delay_us(64); } else { HAL_GPIO_WritePin(OW_PORT, OW_PIN, GPIO_PIN_RESET); delay_us(60); HAL_GPIO_WritePin(OW_PORT, OW_PIN, GPIO_PIN_SET); delay_us(10); } }

实际延时参数以具体器件手册为准，不同批次芯片对时序的容限会有差异。我调试时先用逻辑分析仪抓波形，把每个时隙拉到手册标称范围内，再批量测试几十片传感器，确认没有“这只能读那只不能读”的现象。

3.2 从传感器原始数据到物理温度：一个 0 代替不了 0.0625

把寄存器的原始字节读回来只是第一步，温度换算如果不严谨，会在应用层上出很隐蔽的偏差。PJ85718DM 出来的原始数据通常是补码格式，符号位在高字节，换算时要先把两个字节拼接成有符号数，再做右移或乘法得到最终温度。

以常见的 12 位分辨率为例，每个 LSB 对应 0.0625℃，换算代码很简单：

int16_t raw = (int16_t)((uint16_t)(msb << 8) | lsb); float temperature_celsius = raw * 0.0625f;

这里有个容易踩的坑：如果在拼接之前就把高字节当成无符号数，负温度会出现严重错误。比如零下温度时高字节是 0xFF，直接按无符号左移再和低字节相或，会得到一个接近 65535 的正数，换算出来就变成一百多摄氏度。所以必须先把 16 位合并结果强制转换成 int16_t，让编译器按补码解释。

负温度的场景在暖通里不像北方冬季那么常见，但冷库、新风预热段、或过渡季节停机状态下都可能出现。建议在驱动层就统一处理成浮点温度值，上层业务代码不管原始字节格式，只跟物理量打交道，这样后续接入不同传感器型号时，改动面最小。

3.3 软件滤波与上报：别让 1 秒一次的温度把总线变成热点

温度数据本身是慢变量，没必要每次都裸发到上位机。我在工程里把采集任务做成 1 秒一次，每次读到最新温度后先进队列，再做滑动滤波。HVAC 现场的干扰往往是尖峰脉冲，比如压缩机启动、变频器调频瞬间，温度值可能突然跳变 0.5℃ 到 1℃。对这种噪声，中值滤波比单纯滑动平均更有效，因为它天然会把异常突变剔除掉。

我的实现是维护一个长度为 5 的环形缓冲，每来一个新数据，把窗口内数据排序取中值，作为当前稳定温度。如果窗口长度取得太长，比如 15 个点，虽然更平滑，但真实温度变化也会被拖慢，导致风管温度已经明显上升了，显示值还慢半拍。经过实测，5 点中值滤波在“抗尖峰”和“不迟钝”之间最均衡。

上报的逻辑也要克制。Modbus 等总线协议虽然支持高频轮询，但没必要每秒都推温度。我一般把温度上报周期设为 2 秒或根据主站请求应答，同时在本地维护一个“变化超过 0.3℃ 才主动上报”的死区判断，这样既能保证温度变化及时送达，又不会拼命刷屏占用总线带宽。经过这样处理，整条通信链路负载很低，温度数据也不会因为过度频繁的请求而影响其他控制命令的实时性。

4. HVAC 场景专项：风管测温、冷热冲击与故障保护

4.1 空调现场与实验室最大的差距在哪

实验室里跑得好好的测温方案，一到 HVAC 现场就可能翻车。原因是现场环境远比恒温实验室复杂：风机启停带来的温度骤变，会让传感器读数瞬间跳变；变频器产生的电磁干扰会耦合进长线；冷凝水可能顺着探头线流进插座，引起腐蚀和绝缘下降。这就意味着，硬件和固件不能只用“常温、短连线、无干扰”的理想条件来设计。

我在做这套方案前，特意用温度冲击箱做了一轮测试，让传感器在 -10℃ 到 60℃ 之间快速切换。结果发现，传感器本身的响应速度比理论值慢，尤其在密封探头外壳里，热传导路径被空气层阻隔后，读数滞后明显。这个滞后不是软件能完全消除的，所以现场要明确一个预期：显示的温度变化会比实际管温晚几十秒，但稳态精度最终能追上。在控制逻辑里，如果拿这个滞后读数做闭环控制，需要考虑加一点预测补偿，否则系统容易震荡。

另一个温差陷阱是传感器和大功率器件之间的“热耦合”。风管探头线如果和强电电缆绑扎在一起走线，强电电缆发热会让探头读数偏高。现场布线时，温度探头线尽量单独走槽，不要和 220V 动力线紧密捆扎，通信线也一样。这一点在图纸设计阶段就要提出来，否则施工队布线往往只看美观，不注意信号完整性。

4.2 风管探头安装与热接触细节

远程探头插入风管的方式，直接影响测量代表性。如果探头只插进风管一点点，测到的可能是风管壁附近的边界层空气，而不是气流主区的真实温度。我一般要求探头插入深度至少达到管径的 1/3，并且探头迎着气流方向，头部处于气流主通道中。遇到矩形风管，探头可以从侧面斜插，让热敏感部位在截面中部附近停留。

安装时的热接触也很关键。PJ85718DM 如果做成分立探头，传感器外壳和被测空气之间最好有金属导热路径，而不是让传感器悬在塑料壳里“蹭空气”。现场把探头头部用金属卡夹固定在回风格栅或者管道支架上，接触面涂少量导热硅脂，能明显提高响应速度。我曾经对比过两套相同探头，一套金属夹固定、一套只用扎带绑在风管外壁，同一时刻两个读数值能差 2℃ 以上。风管外壁的温度本来就和内部气流温度不一样，拿它当风温做控制自然会有偏差。

对于冷凝水环境，比如表冷器附近的送风温度测点，探头要做好防水处理。传感器引脚和线缆焊接处套热缩管，再用密封胶封堵接头；探头如果长期处在高湿环境，建议选带防水头的成品探头壳，不要自己拿热缩管缠两圈就上现场，时间长了很容易受潮漏电，导致该通道温度值一路漂移。

4.3 断线、短路与失效保护：宁可上报错误，不可上报假数据

远程探头再可靠，也架不住现场施工或长时间运行后的老化。我在这套系统里专门做了失效保护逻辑：单总线通信过程加 CRC 校验，读取到的数据如果校验不过，就认为这是一次无效读取，重试 3 次；重试仍然失败，就把该通道标记为故障，温度值强制置为无效值并上送告警，而不是继续把上一次的旧温度当作当前温度显示。

为什么强调这一点？因为 HVAC 控制逻辑一旦拿到一个“看起来正常但实际过时”的温度值，可能会继续按错误温度启动压缩机或加热器，轻则能耗升高，重则设备保护失效。我看到过别的项目因为传感器断线后主控继续保有旧值，导致冬季运行时机组持续高负荷运转，最后触发高压保护。所以温度上报接口里，我特别留了一个状态字段：0 表示数据有效，1 表示离线，2 表示校验失败。上位机拿到非 0 状态，至少能知道测温链路出问题了。

针对短路线路，还有一点要提：单总线数据线如果对地短路或对电源短路，GPIO 配置不当可能把板子拉死。我在驱动初始化和通信前会检查总线电平，如果总线一直保持异常电平，就停止通信并直接报故障。这样既能保护传感器接口，也让故障定位更简单——现场工程师看到“通道离线”告警，第一时间就去看线缆，而不是怀疑代码逻辑。

5. 实测效果与避坑记录：从原理图到稳定运行的最后一公里

5.1 实测数据：本地/远程通道的读数表现

样机做完后，我在老化柜和现场各做了一轮对比测试。本地通道因为距离近、走线短，读数非常稳定；远程通道经过长线传输后，虽然偶发通信重试，但最终的温度值没有出现系统性偏差。用标准温度计做参照物，在同一时刻记录了一组数据，见下表：

这组数据是在稳态条件下测的，偏差稳定在 ±0.3℃ 以内，满足暖通控制的精度要求。需要说明的是，PJ85718DM 自身的精度指标通常足以覆盖这类场景，真正影响最终偏差的反而是探头安装方式和参照温度计本身的误差。现场测试中，我发现两次不同日期的同一测点读数能复现到 ±0.2℃ 以内，这个一致性让我后续做整机标定时很有信心。

5.2 成本与功耗实测

这套方案的成本和功耗也是可以拿出来说的。PJ85718DM 单片价格不高，HVAC 控制器里常用作温度测点的替换升级，相比用模拟 NTC 加仪表放大器的方案，硬件成本不升反降，还省了校准工时。STM32H743ZI 虽然相比 8 位单片机要贵不少，但它同时承担了控制、通信、显示和温测四个职能，折算到单板成本上是划算的。

功耗方面，STM32H743ZI 在正常运行模式下整板功耗主要集中在主控和外围设备上，传感器和测温链路本身耗电很少。我做了一组粗略测量：系统正常运行时，单颗 PJ85718DM 工作电流在毫安级以下，转换期间电流略高，空闲时基本可以忽略。如果将来做电池供电的无线温湿度记录仪，可以用 GPIO 给传感器供电，在两次采样之间直接关断传感器电源，把待机功耗压到非常低。这套思路放在嵌入式设备上很实用，只是暖通控制器大多有稳定供电，所以我没做极端优化。

5.3 避坑清单

整个项目做下来，我踩过不少坑，也有几件“如果再来一次我当时就会这么做”的事，顺手整理成一个清单：

• 单总线时序被中断打断是头号问题。读数据临界段务必关中断或放到高优先级定时器回调里执行。
• 远程探头线越长，上拉电阻越要重新调，不要抱着 4.7kΩ 不放手，线长超过 5 米时务必实测波形。
• 传感器下方大铜皮会导致测温迟钝，PCB 布局时做局部挖空处理。
• 远程探头的地线必须单点汇入系统地，不要让结构件或屏蔽层形成第二地回路。
• 负温度换算必须按有符号数处理，这是控制逻辑里最容易出现的隐蔽 bug。
• 滤波窗口不需要太长，5 点中值滤波对暖通现场噪声已经足够，窗口过大只会让响应变慢。
• 每次传感器读取都要做 CRC 校验，失败了就重试，重试不行就报离线，不能让旧值一直顶替新值。

另外在调试阶段，我建议准备一个逻辑分析仪，专门看单总线波形。很多时候传感器读不到数据，不是因为代码逻辑错，而是时序边沿不合格，这时候靠眼睛看代码很难发现问题，波形一抓就了然。工程调试不怕慢，怕的是绕圈子。

最后再分享一个调试心得：把本地通道和远程通道的原始读数、换算值、滤波值、故障状态全部做成可在调试串口里查看的版本，现场出现任何异常温度，我都能快速判断是哪一层出了问题。这套“分层次监控”的习惯帮我省了大量现场排查时间，也让我对 PJ85718DM 和 STM32H743ZI 这套组合在不同工况下的表现有了更准确的判断。做温度监测，稳定可靠的实测数据比什么都值钱。