嵌入式HVAC温度监测：STM32F469与PJ85718DM单总线实现本地远程测温

做了这么多年嵌入式，其实最能拉开差距的往往不是 CPU 主频能跑多高、外设能开多少个，而是那些不起眼的传感器数据能不能在工业现场长期稳定地跑起来。这次要聊的项目，从标题上看很直白：用 PJ85718DM 这颗温度传感器芯片配合 STM32F469II 做主控，把嵌入式和 HVAC 场景里的本地温度与远程温度都监测起来。项目本身不算复杂，但牵扯到的点很杂：单总线协议、长线传输、多点采集、低功耗、还有 HVAC 经常遇到的强干扰环境。如果你正准备做类似的温度采集系统，或者想在项目里引入远程温控节点，这篇文章应该能帮你少走不少弯路。

这个项目能解决的问题其实很明确：本地温度，就是传感器装在设备本体上，直接读；远程温度，则是传感器通过较长的线缆布放到房间、风道、冷却管道这些不方便放主控的位置。HVAC 领域尤其常见——中央空调的回风温度、新风系统的进风温度、冷冻水管的表面温度，这些点位离控制器往往有几十米甚至上百米。PJ85718DM 本身支持单总线多点挂接，STM32F469II 负责协议解析、数据处理和联动控制，整套方案在成本和工程复杂度上都比较平衡。适合正在做温控器、楼宇自控、机房环境监测或者嵌入式 HMI 项目的开发者参考。

1. 项目解析与选型思路

1.1 标题拆解：本地、远程、嵌入式、HVAC 四个关键词意味着什么

“本地与远程温度”这个说法，在不少方案里会被理解成两种完全不同的东西。第一种是物理位置的远近：传感器在主控板上叫本地，传感器拉线出去装在远端就叫远程；第二种是数据链路的远近：本地数据走 I2C、SPI 直接读，远程数据走 RS485、CAN 或者无线再汇总到主控。这个项目标题里的“嵌入式与 HVAC 应用”，指向的其实是第一种为主、第二种为辅的混合场景。

为什么这么说？因为 HVAC 项目中，温度点位的分布非常典型——压缩机排气管温度、回气温度属于本地；车间四个角落的温湿度、楼顶冷却塔的出水温度属于远程。而使用 PJ85718DM 这种单总线芯片，天然就能在一条总线上挂多个探头，本地远程共用同一套驱动逻辑，既省 IO 又省代码。STM32F469II 选在这里，不是因为它跑得快，而是因为它接口齐全、大容量 Flash 适合做数据记录和界面缓存，能在同一个芯片里把采集、运算、显示、联网全包掉。

从工程角度看，这种“一芯多探头、总线长距离”的架构最大的好处是：无论探头装在设备内部还是挂在百米之外，硬件拓扑完全一致，软件层只需要根据设备地址区分逻辑位置。这比起每个点位都用独立 ADC 通道采集热敏电阻，或者用一堆 4-20mA 变送器再配模拟量模块，要省太多事。

1.2 为什么选 PJ85718DM 与 STM32F469II

PJ85718DM 在国内的嵌入式温度采集项目里出镜率不低，核心原因有三个：一是数字输出，不需要额外做信号调理，接上 MCU 的 GPIO 就能读；二是单总线协议，一根数据线就能挂多个探头，地址唯一；三是测量范围覆盖 -55℃ 到 +125℃，12 位分辨率下温度转换精度可以做到 0.5℃ 以内，HVAC 场景完全够用。

STM32F469II 的定位则是“全能主控”。它有 Cortex-M4 内核带 FPU 和 DSP 指令，跑温度滤波算法很轻松；内置大容量 Flash 和 RAM，可以缓存长时间的温度记录；同时外设丰富，以太网 MAC、多个 USART、CAN、SDIO 都有，为后续接人机界面或者联网上报预留了充足空间。实际项目中，我用它既做过带彩色触摸屏的温控面板，也做过纯采集节点，表现都很稳定。

选型组合没什么花哨，核心逻辑就是一句话：传感器便宜易得，主控资源富余，两者搭配能把开发周期压到最短。如果你手头已经有别的单总线温度传感器（比如常见的 DS18B20 兼容型号），代码层面几乎可以直接复用；如果你主控资源紧张，用 STM32F103 也能跑，但 F469 在中大型 HVAC 项目里更从容。

1.3 系统整体架构与技术路线

整套系统的数据流向大概是这样的：多个 PJ85718DM 探头挂在一根（或几根）单总线上，STM32F469II 通过 GPIO 模拟单总线时序，依次发起温度转换和读取命令，拿到原始数据后在 MCU 内部做校验、滤波、标定，再根据配置把某些点位作为本地温度、某些点位作为远程温度进行分类存储。最终数据一方面用于本地显示和 HVAC 控制逻辑判断，另一方面通过串口、以太网或者 RS485 上报给上层监控平台。

技术路线上有一条主线：单总线采集、CRC 校验、滑动滤波、阈值联动。为什么坚持用 GPIO 模拟而不是用芯片自带的收发器？因为单总线时序要求很严格，且总线状态受线缆长度和寄生电容影响较大，用 GPIO 模拟可以灵活调节时序，适配不同长度和质量的线材。实测下来，在 30 米左右的普通屏蔽双绞线上，合理配置上拉电阻和时序参数后，误码率完全可控。

HVAC 联动部分，我把温度数据按功能分区管理，比如送风温度、回风温度、盘管温度，每组数据独立设置报警阈值和控制回差。这套框架不复杂，但胜在稳定，后续加点位、改阈值都只要改配置表。

2. 硬件架构与连接方案

2.1 PJ85718DM 的关键特性与引脚说明

PJ85718DM 的外观和大多数单总线温度传感器差不多，三根引脚：VDD、DQ、GND。供电方式支持外部电源，也支持寄生供电。实际 HVAC 项目中我基本都用外部电源，原因稍后讲。

电气层面，这颗芯片在 3.0V 到 5.5V 供电范围内都能工作。STM32F469II 的 GPIO 是 3.3V 电平，所以直接供电 3.3V、数据线直接连 IO 就可以，不需要电平转换。需要注意的一点是，单总线的数据线通常要接一个 4.7kΩ 左右的上拉电阻到 VDD。如果总线上的探头数量多、线缆比较长，上拉电阻可能需要降到 2.2kΩ 甚至 1kΩ，否则信号上升沿太慢，很容易出现读时序不稳定。

分辨率方面，可以通过配置寄存器在 9 到 12 位之间切换。对应转换时间分别是 93.75ms、187.5ms、375ms、750ms。HVAC 项目一般不急那一两百毫秒，建议直接用 12 位分辨率，精度优先。如果你做的是快速响应的设备保护，可以切到 9 位，转换一次不到 100ms，采样频率更高。

下表是 PJ85718DM 在不同供电和接线方式下的推荐配置：

2.2 STM32F469II 的资源分配与引脚规划

STM32F469II 有 176 个引脚，管脚资源非常充裕。这个项目我实际用到的外设不多：一组 GPIO 模拟单总线、一个定时器做延时基准、一个 USART 做调试日志、一个 USART 或以太网做远程数据上报。剩下大量资源可以留给 LCD 显示、按键输入、继电器控制和数据存储。

引脚规划上要注意一个细节：单总线数据线选一个 5V 容忍的 GPIO，并且最好支持推挽输出与开漏输出切换。因为在单总线通信中，主机既要主动拉低总线发送时序，又要释放总线读取从机响应，所以常见做法是把 GPIO 配置为开漏输出，外部上拉保证高电平。这样主机拉低就是发送，释放就是接收，不需要反复切换模式。

我自己习惯把单总线放在 STM32F469 的 PB5 或者 PD7 这类普通 IO 上，避免和 JTAG、调试串口冲突。处理批量生产时，管脚分配越固定的越好，不然换一颗芯片就要改一堆代码。

另外，如果系统里要驱动继电器或者接触器控制 HVAC 设备，强烈建议把强电驱动部分和单片机从物理上隔离，至少不要在同一个电源域。PJ85718DM 这种数字传感器抗干扰能力比模拟传感器强，但继电器吸合的瞬间干扰还是可能通过地线串进来，导致单总线通信偶尔复位。加个磁珠或者共模电感在传感器供电入口，效果很明显。

2.3 本地与远程温度探头的接线细节

本地温度传感器接线最简单，VDD 接 3.3V，GND 接地，DQ 通过 4.7kΩ 上拉后直接到 MCU 的 GPIO。探头和 MCU 之间距离短，噪声影响小，重点是保证供电稳定。

远程温度探头的接线则要考虑三件事：线缆电阻、分布电容、干扰耦合。PJ85718DM 这类传感器工作在 3V 到 5.5V 宽电压范围，线缆上的压降只要不超过 0.5V 基本都能正常工作。以常见的 0.5mm² 铜芯双绞线为例，电阻大约是每百米 3.6Ω，在 60 米距离、每探头平均 1mA 工作电流的工况下，压降很小，完全可控。真正麻烦的是分布电容和电磁干扰。

长距离布线的推荐做法是使用屏蔽双绞线，屏蔽层单端接地。数据线和电源线走在同一根线缆内时，要用双绞线里的一对给 DQ 和 GND，另一对给 VDD 和 GND，避免数据线受到电源纹波串扰。如果现场还有变频器或大功率电机，传感器线缆要和动力电缆保持至少 30cm 的距离，交叉时尽量垂直走线。

还有一个很多新手会踩的坑：远程探头的 VDD 和 GND 必须在主控端集中供电，不要在远端再接一个独立电源。两个电源的地电位如果不一致，会在总线上形成地环路电流，轻则读数跳动，重则直接损坏传感器。单点供电、单点接地，这是铁律。

2.4 供电、隔离与抗干扰设计细节

STM32F469II 的供电一般用 3.3V LDO，输入来自 24V DC 或者 5V 开关电源。HVAC 现场最常见的 24V 交流供电，整流滤波后再进 DC-DC，这种方案在商用空调控制器里很普遍。需要注意的问题是，24V 交流整流后的地并不是干净的信号地，数字部分和传感器供电最好通过 LC 滤波隔离。

PJ85718DM 常规用法下不需要光电隔离。但如果远程探头布线距离超过 50 米，且现场电磁环境恶劣，我会在总线入口加一个 TVS 管到地，同时串联一个 100Ω 左右的电阻到 GPIO。TVS 管选击穿电压 5V 左右的型号，防止线缆感应雷击或电机启停浪涌打坏 MCU 引脚。有人觉得加电阻会影响时序，实测 100Ω 对单总线通信几乎没有影响，但保护作用很值。

关于温漂，也有必要提一句：PJ85718DM 出厂精度在 ±0.5℃ 左右，但长线传输时信号波形畸变会导致读值出现偶发跳变。硬件上无法完全避免时，要在软件层做滤波和无效值剔除，这个后面单独讲。

3. 固件驱动与数据采集实现

3.1 单总线驱动核心逻辑

单总线协议虽然简单，但对时序要求很严格。主机和从机之间的通信由一系列特定时长的脉冲序列组成。最常见的操作流程就是三步：初始化复位、写命令、读数据。

初始化复位脉冲是这么个过程：主机把总线拉低至少 480μs，然后释放并等待 60μs 左右，总线上的从机会拉低 60-240μs 作为存在脉冲。主机检测到这个低电平脉冲，就算确认总线上有设备在线。代码里我习惯写一个带超时保护的检测函数，避免总线短路时死循环。

写时序分写 0 和写 1。写 0 是拉低总线 60-120μs；写 1 是拉低 1-15μs 后释放。读时序则是主机拉低 1-15μs 后释放，然后在 15μs 内采样总线电平。STM32F469 跑 168MHz，GPIO 操作很快，所以我在延时函数里用 DWT 或者定时器做微秒级延时，避免用空循环被编译器优化掉。

代码层面，最核心的单总线读一个字节函数如下：

uint8_t onewire_read_byte(void) { uint8_t data = 0; for (uint8_t i = 0; i < 8; i++) { data >>= 1; if (onewire_read_bit()) { data |= 0x80; } } return data; }

实际使用中，每个探头的读取流程是：复位、发送跳过 ROM 命令（0xCC）或者匹配指定 ROM（0x55）、发送温度转换命令（0x44）、等待转换完成、复位、发送读暂存器命令（0xBE），最后读取 9 个字节，其中前两个字节是温度值，最后两个字节是 CRC。

如果你在一条总线上挂了多个传感器，跳过 ROM 的方式就不能用了，必须先执行搜索 ROM 命令把每个设备的 64 位序列号读出来，存到数组里，之后每次读取都指定设备地址。搜索 ROM 的算法有点绕，但 STM32 内存足够，直接用查表法或状态机实现都不难。

3.2 本地远程探头的统一数据管理

当一条总线上有多个 PJ85718DM 时，传感器本身是不区分本地和远程的。本地远程的概念只在应用层有意义。我的做法是建立一张设备配置表，每个设备的唯一序列号对应一个逻辑点位编号，再通过点位编号关联到“本地温度”或“远程温度”的房间、区域、设备类型。

举个例子，设备 1 序列号结尾是 A1，配置成“主机回风温度”，属于本地采集；设备 5 序列号结尾是 B2，配置成“冷冻水管表面温度”，属于远程采集。温度转换完毕后，MCU 按配置表把原始数据写进不同的结构体字段。这样后续做显示、报警、PID 控制时，只读逻辑点位，不直接操作传感器地址。

统一数据管理的另一个好处是故障隔离。某一路远程探头断线、短路或者 CRC 校验失败时，只标记该点位数据无效，不影响其他点位正常采集。HVAC 系统里，一个传感器故障不应该导致整机停机，最多进入相应的保护或旁路模式。这是工程上很重要的一点。

温度采集的周期，我一般设置在 1 秒左右。PJ85718DM 在 12 位分辨率下转换时间是 750ms，理论上 1 秒读一轮刚好。如果你要读 10 个探头，每个探头都要等转换时间，最简单的方式是广播温度转换命令，然后统一等 750ms，再逐个读数据。这样无论挂多少个探头，一轮采集的总时间基本固定。

3.3 温度数据滤波与标定补偿

单总线传感器数据偶发跳变是常态，尤其是远程探头在恶劣环境下。跳变的来源可能是线缆干扰、供电瞬间跌落或者时序受温度影响导致采样偏差。硬件抗干扰只是一部分，软件滤波必须做。

我常用的是中值滤波加滑动平均的组合。具体做法是每轮采集把同一个点位的连续 3 次读数取中值，再把最近 5 个中值做滑动平均。这块算法在 F469 上开销很小，几分钟完成验证。实测下来，原本偶尔会有 ±1℃ 的毛刺，滤波后基本稳定在 ±0.1℃ 以内。

标定补偿方面，PJ85718DM 出厂精度已经不错，但如果你对特定温度点有要求，比如 0℃ 和 50℃，可以用冰水浴和恒温槽做两点校准。校准参数就是偏移量和增益系数，存在 Flash 里。F469 内部有足够空间存这些标定数据，断电不丢。

如果项目里有多个通道，每个通道单独校准后效果更好。批量生产时可以用一台基准恒温槽配合自动化测试工装，把每台设备的标定参数写入出厂配置区。这里省时间不值得，后面用户现场发现问题再返工，成本翻好几倍。

3.4 与 HVAC 逻辑的联动控制

采集温度不是最终目的，最终目的是让 HVAC 系统根据温度做出正确响应。项目里最简单的联动逻辑是这样：远程温度代表房间实际温度，本地温度代表设备回风温度，两路数据共同参与制冷/制热控制。

制冷模式下，当远程温度大于设定温度加上回差时，开启压缩机或者电动阀；当远程温度小于设定温度减去回差时，关闭设备。回差一般取 1-2℃，避免继电器频繁吸合。这类逻辑写成状态机非常清晰：

if (remote_temp > set_temp + hysteresis) hvac_output = ON; else if (remote_temp < set_temp - hysteresis) hvac_output = OFF;

更进阶一点，可以用本地温度做辅助保护。比如本地回风温度过高，说明设备可能过载或风道堵塞，即便远程温度还没达到停机条件，也应该限制压缩机运行时间或者触发告警。这种联动逻辑，说白了就是把传感器从“读数”升级为“决策依据”。

报警阈值和回差参数，我习惯全部放在一个配置结构体里，通过串口命令或者人机界面实时调整。STM32F469 的大容量 Flash 在这里很实用，配置区单独划一个 Flash page，擦写次数低频可控，不用担心寿命。

4. 远程监测的工程实现

4.1 “远程监测”的两种实现层次

这个项目里的“远程温度监测”，如果只是把探头拉远再拉回 MCU，那远程还停留在物理层。真正的工程价值在于把多个远程点位的数据汇总、上报、展示，让不在现场的人也能掌握设备状态。

在这个系统里，STM32F469II 采集所有温度后，需要把数据“送出去”。常用的方式有几种：RS485 总线接楼宇自控系统、以太网接本地服务器、MQTT 上报到云平台。F469 自带以太网 MAC，配合 PHY 芯片可以直接跑 TCP/IP；如果不熟悉以太网协议栈，也可以用 W5500 这类外挂网络芯片，开发更快。

我这里推荐一个比较稳的组合：本地数据用 RS485 + Modbus RTU 协议上报给监控主机，远程云平台通过监控主机再转发。RS485 在工业现场是最老牌最可靠的物理层，Modbus RTU 协议简单，不管是组态软件还是 PLC 都能直接对接。F469 的 USART 之一配置成 485 模式，再加一个收发切换引脚控制方向，很轻松。

4.2 远程数据上报协议与数据格式

Modbus RTU 的帧结构和 CRC 校验是固定的，实现起来没有太多歧义。我从机端只需要维护一个寄存器表。比如把温度值乘以 100 转成整数存到保持寄存器里，点位 1 到 50 是温度值，点位 100 到 150 是报警状态。上位机轮询读寄存器即可。

寄存器地址规划建议一开始就留够余量。HVAC 项目后期经常要加点位，如果地址规划太挤，后面换协议表很痛苦。

如果选择走网络上报，MQTT 是比 TCP 裸传更灵活的方案。F469 + 网络芯片跑 MQTT，把 JSON 数据包发到本地 broker，或者直接发到云端。要注意的是，MQTT 报文虽然灵活，但解析 JSON 在 MCU 上要占用不少资源。F469 的性能足够，但代码组织要规范，尽量用结构体封装底层数据，协议层只做收发和序列化。

4.3 上位机展示与数据记录

温度数据远程化之后，必须配合可视化和历史记录才有价值。最简单的上位机方案是 PC 上跑一个组态软件或者自己写一个小工具，通过串口或以太网读取数据，画趋势曲线、存历史 CSV。再往上一档，就是把数据接入数据库并用网页展示。

如果你用的是 MQTT 上报，那数据链路天然适合接时序数据库。云端的规则引擎还可以实现邮件或者小程序告警推送。温度超限第一时间通知运维人员，这在无人值守的空调机房和冷库场景里很关键。

存储方面，STM32F469II 自带的 Flash 可以存一定量的历史温度，掉电不丢。但 Flash 擦写次数有限，不能频繁写入。工程上的做法是先在 RAM 中缓存一轮数据，定时批量写入一次，并且用环形缓冲区控制写入频率。这个项目里，我用 F469 的 SDIO 接口接了一张 TF 卡，每分钟存一条历史温度记录，一年下来数据量不大，完全扛得住。

4.4 报警阈值分级与联动告警

远程监测系统的报警机制，比本地控制逻辑要更细致一些。我一般会设置三个等级：提示、预警、告警。提示是温度偏离正常范围但还在可控区间；预警是接近上限或下限，需要关注；告警是已经超出安全边界，必须立刻处理。

报警分级听起来简单，实际工程里却很容易被忽略。很多人一上来就是一个阈值，到点就报警，结果现场频繁误报，运维人员干脆把报警关了。分级之后，配合回差和延时确认，能明显减少误报。具体做法是：温度连续 3 次采样超过阈值才确认报警，避免单次干扰触发。

报警事件除了写日志，还可以联动继电器输出。比如冷库温度过高时，除了云平台告警，控制器本地也输出一个声光报警信号。这样即便远程链路断了，现场人员也能第一时间发现异常。

5. 常见问题与避坑实战

5.1 传感器读不到或返回 85℃

85℃ 这个读数特别典型，实际上是传感器上电默认值。出现这种情况，第一怀疑对象不是传感器坏了，而是上一次温度转换没成功或者复位时序不对。先检查总线初始化有没有正常检测到存在脉冲，再检查复位后是否等待了足够时间再发命令。

如果你用的是跳 ROM 的方式直接读，总线上挂了多个设备时返回数据会错乱。必须先搜索 ROM 拿到唯一地址，再按地址读取。这个坑我见过好多次，排错的时候先回顾一下读取流程的顺序。

如果时序检查都正常还是读到 85℃，用示波器抓一下数据线波形。上拉电阻太大会导致上升沿过缓，主机采样时读到低电平；上拉电阻太小则可能导致从机拉低时无法拉出合法低电平。根据线缆长度调整上拉电阻，一般能解决。

下表整理了温度采集最常见的几类问题：

5.2 长线传输的时序适配

远程探头布线超过 20 米后，单总线的时序就会因为线缆电容而“变钝”。信号上升沿变慢，最直接的影响是主机在释放总线后采样时，总线还没恢复到逻辑高电平，导致把从机发送的“1”误读成“0”。

解决这个问题的核心策略是缩短采样点和释放点之间的间隔。我习惯把读时序里的延时从标准 15μs 稍微下调到 10-12μs，让主机在总线电位真正起来之前就完成采样。同样，写 1 时序里的拉低时间也适当缩短，给总线更多恢复时间。

另一个经验是减少分支线。一条总线上多个探头，最好采用菊花链串接方式，而不是星型连接。星型连接的分支会产生阻抗不匹配和信号反射，长线传输时问题会被放大。如果现场已经留了星型管线，可以在每个分支末端加一个小电阻匹配，或者干脆把单总线拆成两路独立总线，每路挂一部分探头。

5.3 电源与地环路带来的不确定性

远程传感器供电的坑比参数配置更隐蔽。一个典型故障现象：本地读数正常，远程读数在压缩机启动瞬间跳变好几度，甚至直接报通信错误。查到最后，往往是远程探头的电源地和主控之间形成了一个地环路。

地环路的核心成因是回路中存在两个接地点，两点之间有电位差便产生线缆电流。正确的做法是单点接地。远程探头端不要接地，屏蔽层只在主控端单端接地，传感器电源也由主控端统一供给。这样电流路径是干净的，噪声不会串进信号线。

如果现场电源实在干扰太厉害，比如和变频器共用一路电源，我建议给传感器供电单独加一个 DC-DC 隔离模块，或者至少加一个 LDO 加 LC 滤波。成本增加不多，但稳定性提升明显。

5.4 批量校准与生产测试建议

最后说一个量产经验。如果这个项目不只是一块样机，而要做几十上百套设备，传感器校准和测试流程一定要提前设计好。

校准：用一个高精度的标准温度计作为基准，在恒温槽中设定几个温度点，让设备自动记录 PJ85718DM 读数与标准值的偏差，再写入每个通道的补偿参数。这样即使传感器出厂一致性稍差，整机精度也能保证。

测试：生产测试工装应该能自动完成以下检查——每个通道是否都能正常识别传感器、CRC 校验是否连续通过、在室温下读数是否在正常范围、模拟断线时系统是否上报故障。这些测试全自动跑下来，一台设备一两分钟就够。

如果你在项目里省掉这一步，到了现场再发现某一路探头经常掉线，排查成本会远超生产测试的时间成本。做嵌入式项目，往往后面省事都是前面做足了功课。这个道理，相信懂得都懂。

写到这里，这个项目从硬件选型、驱动实现到远程对接的完整脉络基本都梳理了一遍。我个人在实际操作中的体会是：PJ85718DM 和 STM32F469II 这套组合，最大的优势不是某个单项性能有多强，而是整个链路——采集、处理、控制、上报——都可以在一颗芯片和一根单总线上跑通，省心且可靠。最后再分享一个小技巧：如果你打算长期维护这个项目，建议把传感器配置表、上报协议字段表都整理成单独的文件，和主逻辑代码分离开。项目后期加传感器、加点位是必然的事，结构清晰能省下大量改代码的时间。HVAC 和嵌入式测温项目都不是一次性地活，打好的地基，会一直帮你省力下去。