企业官网建设流程全解析

做暖通空调嵌入式监控这几年，我遇到最多的需求不是“测不准”，而是“温度到底要从哪里拉回来”。同一个控制柜里要采回风温度，几十米外的室外换热器温度也要实时看，两者还要一起上传到中控室。这个项目里，我最终的方案是 STM32F415RG 做主控，本地和远程温度全部挂在同一条单总线上，传感器统一用 PJ85718DM。整套系统跑下来，温度误差能控制在 0.3℃ 以内，远程长线 30 多米也不掉线。今天就把这套方案的选型逻辑、硬件接法、驱动时序、远程上送手段和实际调试中踩过的坑一次性讲清楚。

如果你也在做嵌入式或 HVAC 这类对可靠性有要求、又不想在传感器布线上下太多成本的设备，这篇文章可以直接当参考。尤其是“一条 GPIO 怎么同时读本地和远程好几路温度”这个点，很多人第一反应是上 I2C、上 SPI、上 ADC，但单总线方案往往被低估。

1. 为什么是 PJ85718DM + STM32F415RG 这个组合

1.1 PJ85718DM 到底是什么器件

PJ85718DM 是一款单总线数字温度传感器，封装和引脚功能都沿用了常见的 DS18B20 体系，寄存器映射、ROM 命令、时序参数基本一致。我最早就是按 DS18B20 的协议流程来驱动它的，跑通后再对着 PJ85718DM 的规格书逐个核对报警阈值和 EEPROM 设置，确认没有差异后才批量用。

它的典型特性大家应该很熟悉：测温范围 -55℃ 到 +125℃，12 位分辨率下温度最小分辨率 0.0625℃，典型精度 ±0.5℃；每个器件出厂带一个 64 位唯一序列号，所以理论上同一条总线上可以挂很多个传感器，主机通过序列号寻址区分它们。对 HVAC 这种需要多点测温的场景，这个特性非常关键——不需要每个传感器单独占一个 ADC 通道，也不需要额外拉多条信号线，一根 DQ 线就能串起来。

实际项目里我挂了三颗：一颗作为“本地温度”，装在控制柜内回风口附近；另外两颗作为“远程温度”，拉到室外换热器的进水和出水位置。控制板和传感器之间走双绞线，最远一颗约 30 米，靠单总线完全能带得动。这里有个重要前提：远程传感器必须用外部供电，而不是用寄生供电。后文我会专门讲长线供电和上拉电阻的取舍。

1.2 STM32F415RG 在这个项目里的角色

主控选 STM32F415RG，很多人会问为什么不用更常见的 F103 或者 F407。核心原因有三点。

第一，F415RG 的主频是 168MHz，Flash 1MB，RAM 192KB。跑 lwIP 协议栈、做 TCP 报文处理、同时还要保持单总线微妙级时序实时性，F103 那 72MHz 会显得比较紧张，尤其当远程数据传输和温度采样都在同一时刻发生时。

第二，F415RG 内置以太网 MAC，只需要外接一颗 PHY 芯片就能跑 10/100M 以太网。这对 HVAC 设备来说非常实用——现场多数中控室都具备以太网或者 Modbus TCP 的接入条件，走网络比走 RS485 布线和配置地址省事很多。

第三，F415RG 相比 F407 多了一套硬件加解密单元，支持 AES、DES、HASH。虽然这次项目里远程上报走的是局域网 Modbus TCP，没有真正启用加密，但我预留了这个能力，后续如果要做 MQTT 或私有协议的数据签名，不需要换 MCU。

下面是选型初期做过的简单对比：

Wi-Fi 方案做民用原型确实方便，但 HVAC 现场经常要面对工业控制柜、金属机箱、较差的无线环境，稳定性明显不如有线以太网。所以我最后还是退回 STM32F415RG 这条线，哪怕前期把 PHY、变压器、RJ45 这一串硬件搭起来稍微麻烦点，后面省心。

1.3 整套系统的拓扑关系和职责划分

从功能上看，可以分成四层：

• 温度采集层：三颗 PJ85718DM 挂在同一条 DQ 总线上，负责本地回风温度和远程换热器进、出水温度的采样。
• 主控处理层：STM32F415RG 负责单总线时序、CRC 校验、温度换算、告警判断和通信协议的组包解包。
• 本地人机层：一块小尺寸 LCD 显示三路温度，指示灯和蜂鸣器负责本地告警。
• 远程通信层：通过以太网将温度数据以 Modbus TCP 或自定义 TCP 帧的形式发送到中控室。

这里“本地与远程温度”有两个维度：物理位置上的本地传感器与远程传感器，以及数据链路本地的就地显示与远程上送。两种理解在这套系统里都落实了，所以标题里那句“本地与远程温度”不是虚的，而是整个项目最核心的诉求。

2. 硬件接线：同一条单总线上怎么挂本地和远程传感器

2.1 单总线的三个硬件基本点

单总线的名字叫“总线”，本质上就是一个漏极开路的线与逻辑。主机 GPIO 和所有传感器的 DQ 引脚都接在同一条线上，外部用一颗上拉电阻拉到 3.3V。平时总线处于高电平，任何一个设备要发数据，就主动把 DQ 拉低一段时间，发完释放，总线自动回到高电平。

所以硬件上三个点必须做到位：

• 主机侧 GPIO 必须配置成开漏输出模式，不能是推挽输出。如果用推挽，传感器拉低总线时主机会和它打架，轻则读数错误，重则烧引脚。
• 总线上必须有一颗上拉电阻。常见取值 4.7kΩ，短距离、传感器少时没问题；长距离或者挂多个传感器，要往下调到 2.2kΩ 甚至 1kΩ，前提是总线负载能力撑得住。
• 每个传感器的 VCC 和 GND 必须可靠连接。很多 DS18B20 时代的教程喜欢用寄生供电省一根线，但工程上我不建议，尤其远程长线场景。

具体接线表如下：

我用的是 PB5 作为 DQ 总线引脚，这个位置在 LQFP64 封装上比较方便走线，且 PB5 本身就支持开漏输出，不占用特殊功能外设。如果你要用别的引脚，只要不是同时被调试口占用的就行，功能上没有硬性限制。

2.2 远程长线怎么做才稳定

远程传感器和控制板之间最远的距离大约 30 米。这个长度对单总线来说并不是极限，但前提是线材、供电、上拉电阻都要做对。

线材我推荐屏蔽双绞线。DQ 信号和 GND 走一对双绞线，VCC 单独走一根稍粗的线，屏蔽层只在主机端单点接到系统地，远端不要接。这样既降低了 DQ 线上的串扰，也避免了形成地环路。地环路在 HVAC 现场是个很容易被忽略的大坑——传感器远端的设备地和控制板地之间往往有电位差，如果屏蔽层两端都接地，地电流会通过屏蔽层流动，温度读数反而会乱跳。

上拉电阻的选择要根据实际总线长度和节点数调整。我用的是 4.7kΩ 起步，远程 30 米线布完后发现上升沿变慢，读数偶发 CRC 错误，后来换成 2.2kΩ，问题明显改善。如果你挂的传感器数量多、线又长，甚至要试到 1kΩ。判断标准很简单：用示波器看 DQ 线上的上升沿，如果每次写位、读位时上升沿都能干净地翻到 3.3V 附近，而不是缓慢爬坡，那这个上拉值基本就合适。

远程传感器端的供电也值得多说一句。传感器工作电压是 3.0V 到 5.5V，统一用 3.3V 供电即可。但 30 米线上存在压降，远端 VCC 可能只剩 3.0V 出头。如果你的电源质量一般，可以改用 5V 给远程传感器供电，DQ 接口仍然通过总线上的 3.3V 上拉通信。STM32 引脚是 3.3V 逻辑，传感器 DQ 引脚通过内部 MOS 管把总线拉低，不会反向往主机灌 5V，只要传感器手册明确 DQ 允许在 VCC 高于主机逻辑电压时工作，这个接法就可以用。我在这个项目里选择了保守方案，远程传感器全部也用 3.3V，只是加大了供电线径，确保远端电压不低于 3.2V。

2.3 接线时最容易出现的低级错误

• 端子排上的 DQ 和 GND 接反。传感器不会立刻烧，但温度会一直读成 85℃ 或者 CRC 报错，排查起来非常困惑。
• 远程线压接不牢。现场振动多，端子螺丝没拧紧，表现为偶发掉线，时好时坏。
• 传感器 VCC 引入了过多噪声。如果没有就近去耦电容，温度数值在整数位附近抖动，看起来精度很差。
• 主机 DQ 引脚配置成了推挽输出。这个问题最隐蔽，因为有时候传感器少且工作正常，等到某个设备拉低总线时，上升沿和下降沿出现异常的尖峰。

我在正式安装前都会先做一次裸板测试，把三颗传感器全部拿到桌子上，用杜邦线和短路端子排模拟现场线缆长度，全部读数稳定后才装机。这个习惯帮我省掉了不少现场返工时间。

3. 驱动实现：一个 GPIO 怎么读出温度

3.1 单总线时序的本质

单总线所有通信都由主机发起，传感器只有在主机下发读时序时才会拉低总线。可以理解成两个人用一根绳子的暗号：拉低时间短表示“0”，拉低时间长表示“1”，关键是两边的时间窗口必须严格对齐。

在 STM32F415RG 这种 168MHz 的 MCU 上，微秒级延时可以用 DWT 或者 SysTick 来做。我习惯用 DWT 计数器，因为它精度高，且不会像 SysTick 那样可能被中断优先级配置干扰。下面这段是基础延时函数：

static inline void delay_us(uint32_t us) { DWT->CYCCNT = 0; uint32_t start = DWT->CYCCNT; uint32_t ticks = us * (SystemCoreClock / 1000000U); while (DWT->CYCCNT - start < ticks); }

使用前别忘了使能 DWT：

CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;

单总线的三个基本时序我就不再贴完整库了，只把关键逻辑说一下。

• 复位时序：主机拉低 480μs 以上，释放后等待 60μs 到 240μs，传感器会把 DQ 拉低 60μs 到 240μs，形成存在脉冲。
• 写时序：主机拉低，写“0”时继续拉低 60μs 到 120μs 后释放；写“1”时拉低 6μs 左右就释放，让上拉电阻在剩余时间内把总线拉高。
• 读时序：主机拉低 6μs 后释放，随后在约 9μs 处读取引脚电平。传感器如果返回“0”，会在释放后继续拉低总线；返回“1”则不动作。

这些时序参数和 DS18B20 完全兼容，PJ85718DM 同样适用。需要注意的一点是，写位和读位的时序是微妙级，如果在中间被打断，整个帧就废了。后面我会详细说以太网中断是如何破坏它的。

3.2 复位、存在脉冲与 ROM 操作

复位是一切指令的前提。复位成功后才能发 ROM 命令，比如跳过 ROM、匹配 ROM、搜索 ROM。

int ow_reset(void) { // 拉低总线 480us PIN_DQ_LOW(); delay_us(500); // 释放总线 PIN_DQ_HIGH(); delay_us(60); // 读存在脉冲 int presence = PIN_DQ_READ(); // 低电平表示存在 delay_us(400); return (presence == 0) ? 1 : 0; }

传感器复位成功后，主机可以发 0xCC（跳过 ROM）或者 0x55（匹配 ROM）。当总线上只有一颗传感器时，跳过 ROM 最省事；多颗时必须先读每颗的 ROM 编号并保存下来，再通过匹配 ROM 精确访问。

温度转换和读取的核心流程是：

float read_temp_by_rom_id(uint64_t rom_id) { if (!ow_reset()) return TEMP_ERR; ow_write_byte(0x55); // MATCH ROM ow_write_u64(rom_id); // 输出 64 位序列号 ow_write_byte(0x44); // 启动温度转换 // 转换时间约 750ms，期间不要做单总线操作 delay_ms(800); if (!ow_reset()) return TEMP_ERR; ow_write_byte(0x55); ow_write_u64(rom_id); ow_write_byte(0xBE); // 读暂存器 uint8_t scratch[9]; for (int i = 0; i < 9; i++) { scratch[i] = ow_read_byte(); } if (crc8(scratch, 8) != scratch[8]) { return TEMP_CRC_ERROR; } return decode_temp(scratch[0], scratch[1]); }

3.3 CRC 校验和负温度解析

单总线通信没有硬件检验，所以每个传感器回传的暂存器最后一字节是 CRC-8。计算多项式采用常见实现代码，我建议把它做成独立函数，每次读温度后必须校验一次，不通过直接当错误处理，不要重试超过三次。这是远程长线场景下保证数据可靠性的底线。

uint8_t crc8(uint8_t *data, uint8_t len) { uint8_t crc = 0; while (len--) { crc ^= *data++; for (uint8_t i = 0; i < 8; i++) { if (crc & 0x01) { crc = (crc >> 1) ^ 0x8C; } else { crc >>= 1; } } } return crc; }

温度解析是 12 位带符号数。低字节是 Bits 0-7，高字节低四位是 Bits 8-11，高字节高四位是符号扩展位。

float decode_temp(uint8_t lsb, uint8_t msb) { int16_t raw = (int16_t)((msb << 8) | lsb); if (raw & 0x8000) { raw = ~raw + 1; return -((float)raw * 0.0625f); } return (float)raw * 0.0625f; }

这里有个容易踩的坑：新上电的 PJ85718DM 在不经过转换命令就读取暂存器时，返回值往往是最初的 85℃。如果你的程序某次复位时序失败，但后续通信稀里糊涂对上了，可能就会读到 85℃ 这个默认值。我处理的方式是在驱动层写了一个“合理性检查”：读到的温度明显超出物理范围（比如超过 125℃ 或低于 -55℃）时，直接丢弃这次结果，并累计一次通信故障计数。85℃ 也是正常范围内，单独靠范围检查拦不住，所以必须依赖前面 CRC 校验和完整的指令状态机，不要跳步。

3.4 多传感器的自动搜索与排序

总线上挂了三颗传感器，安装顺序不能乱。我在固件里写了一个自动搜索 ROM 的流程，上电时扫描总线上的所有器件，按搜索顺序把 64 位 ROM 编号存储到数组中，然后为每个编号指定一个逻辑通道名，比如“本地回风”、“远程进水”、“远程出水”。

搜索 ROM 的算法本身不算复杂，但第一次实现容易绕晕。核心思想是通过两次读位来确定当前比特位：第一次读到的值如果为 0，第二位也为 0，说明总线冲突且当前位为 0；如果第二次读到的值为 0 结果不同，就能确定一些方向和位置。实际代码量不小，我的建议是先用上位机通过串口把三颗传感器的 64 位序列号打印出来，运行时直接存进一个写死的数组，这样最直观也最稳。搜索算法留着作为工厂自校准功能，通过一个按键触发，平时不参与主循环。

在 HVAC 现场，给每颗传感器贴上物理标签并记录下来，比在程序里做任何自动映射都可靠。你不想等到设备装到楼顶才发现“远程出水温度”和“远程进水温度”反了。

4. 把温度送出去：本地显示、现场告警和远程上报

4.1 本地温度的实时落地

温度采集出来后，第一件事是在本地 LCD 上显示。我的刷新周期是 1 秒，温度转换是 12 位，转换时间最长 750ms，所以一秒钟读三颗传感器并显示是足够的。如果改成 9 位分辨率，转换时间降到 100ms 以内，刷新可以更快，但对 HVAC 这种大热惯性场景没有必要。

本地告警不只做个上限比较那么简单。以回风温度为例，设定值 25℃、告警上限 28℃、下限 18℃，直接比较会产生临界点抖动，继电器频繁吸合释放。我做了 1℃ 回差：温度超过 28℃ 才报警，降到 27℃ 以下才解除。这样既不漏报，又不会让继电器在边界处反复跳动。

typedef struct { float alarm_high; float alarm_low; float hysteresis; uint8_t flag; } temp_alarm_t; void update_alarm(temp_alarm_t *a, float temp) { if (a->flag) { if (temp < a->alarm_high - a->hysteresis && temp > a->alarm_low + a->hysteresis) { a->flag = 0; } } else { if (temp >= a->alarm_high || temp <= a->alarm_low) { a->flag = 1; } } }

本地温度还有一个容易被忽视的作用：判断远程传感器是否还“活着”。如果本地温度正常变化，而远程温度长时间卡在一个异常值，多半是远程传感器死线了，这时应该主动在显示界面给出“传感器离线”的提示，而不是把错误数据直接上传到中控室。我在程序里给每颗传感器维护了一个最近 N 次读取的失败计数，连续失败超过 5 次就标记离线。

4.2 远程温度上行的三条路径

STM32F415RG 自带以太网 MAC，外接一颗 RMII 接口的 PHY 芯片和网络变压器就能跑。固件这边用 lwIP，简单可靠。远程上报方式我根据现场条件做了三种，由跳线选择。

第一种是 Modbus TCP。这是工业现场最常见的方式，PLC、组态软件、能源管理平台基本都支持。我把三颗温度分别映射到三个保持寄存器，数值放大 100 倍，避免用浮点数。

第二种是 MQTT 上报。对办公楼宇这类非工业环境，Modbus 协议反而不方便，MQTT 接云平台或本地 broker 更直接。我用 lwIP 跑 TCP，再用开源 MQTT 客户端库发布主题。STM32F415RG 的硬件加密模块在 MQTT TLS 场景下可以帮你承担 AES 计算，但 mbedTLS 和硬件加速的适配比较费工，如果只在局域网内用，可以先用明文，后期再加签名。

第三种是自定义 TCP 帧。这种适合纯私有系统，帧结构简单，不用啃 Modbus 寄存器表。我用一个固定长度结构体，前 2 字节是帧头，中间是三路温度和状态字，最后 2 字节 CRC16。省掉了解析协议的开销，也便于在中断服务里直接组包。

远程上送的调度原则很简单：数据变化量小于一定阈值时不主动发包，超过 0.1℃ 再上报，同时每 30 秒强制上报一次心跳包。这样中控室既能及时看到变化，网络报文量又不会太大。

4.3 主循环调度：慢传感器和快网络怎么共存

温度转换是慢的，以太网收发是快的，如果程序写串行阻塞，整个系统会卡成幻灯片。我采用裸机状态机加简单的定时器调度。

主循环大致长这样：

while (1) { if (flag_1s) { flag_1s = 0; start_all_convert(); // 广播复位+跳ROM+启动转换 } if (flag_1s_after_750ms) { read_all_temps(); // 此时三颗传感器转换完成 update_display(); update_alarms(); update_mqtt_or_modbus(); // 组包发送 } ethernet_poll(); di_key_scan(); }

三颗传感器可以同时启动转换，等待 750ms 期间继续跑网络任务，等到时间到了再分别读取。这个模型本质上是把温度转换当成一个定时执行的“慢外设”，而不是每次读取时都在那儿傻等。如果你上了 RTOS，也可以用二值信号量让读取任务挂起，等转换任务延时结束后释放。

5. 实际调试中踩过的坑

5.1 以太网中断把单总线时序撕碎

第一次联调时，本地温度一直很正常，一旦打开以太网，温度读取就开始偶发错误。示波器抓 DQ 线波形，看不到明显的干扰，但错误概率和以太网数据流量正相关。后来定位到根因：我的以太网 DMA 完成中断优先级比较高，单总线写位、读位过程中被中断插入，延时被拉长，某个 15μs 的窗口错过了传感器返回的电平，整帧就错乱了。

解决方式有两个层面。第一，写位和读位的时序段用临界区保护，在进入关键时序前关中断，时序结束后恢复。单总线一次写位最长也就 70μs 左右，关中断时间不会影响网络任务。第二，把温度采样相关的定时器中断优先级调成比以太网中断更高。但要注意，不能把整个温度读取过程全部放在高优先级中断里，那样会长时间阻断网络。正确做法是只保护单总线的底层位时序，帧级逻辑继续放在普通任务中执行。

void ow_write_byte(uint8_t b) { __disable_irq(); for (uint8_t i = 0; i < 8; i++) { if (b & (1u << i)) { write_bit_1(); } else { write_bit_0(); } } __enable_irq(); }

这个改动之后，以太网跑全速收发时温度读取也稳定了。类似的坑在 CAN 中断、USB 中断场景下同样会碰到，只要协议对时序敏感，就得用同一种思路处理。

5.2 远程长线的误码率和上拉电阻的关系

三颗传感器前两颗都很稳定，第三颗在控制柜装满线后才开始出现 CRC 错误。我发现现场布线与测试时不一样，第三颗传感器的双绞线跟着强电电缆走了十几米，干扰明显增大。单总线设备虽然抗干扰能力比很多弱信号协议强，但也扛不住长期贴着大电流动力线走。

处理方法是重新规划走线路径，让 DQ 双绞线尽量远离变频器输出线和接触器控制线，并在主机端 DQ 线上加一颗 100Ω 的阻尼电阻和一颗对地的 1nF 电容，形成一个简单的低通滤波。加上这些之后，CRC 错误率降为 0。这里的阻尼电阻和电容不能加得太大，否则会拖慢上升沿，窄脉冲可能被滤掉。1nF 是一个平衡点，你可以用示波器验证一下自己的线缆长度和上拉电阻值。

另一个现象：上拉电阻 4.7kΩ 时，30 米线在示波器上看到上升沿明显倾斜，高电平建立时间超过了单总线要求的规范。我换成 2.2kΩ 后，上升沿改善明显，再往上调成 1kΩ 又看到总线空闲时功耗偏高，所以最终定在 2.2kΩ。这个参数的确定没有捷径，只能结合实际线缆长度和传感器数量来试。

5.3 温度一致性：同一批传感器读出来不一样

三颗传感器贴在同一块金属板上静置两小时，显示温度分别是 25.42℃、25.75℃、25.31℃，最大偏差 0.44℃。这个偏差对 HVAC 控制来说其实能用，但中控室的人一旦看到三个温度不一样，就会质疑系统有问题。

我做了零下和常温和高温三点校准，把每颗传感器的偏差值保存到 Flash 中，运行时读出来补偿。校准最简单的方法是找一块稳定的金属块，把参考级温度计和传感器贴在一起，记录静态温度，计算出每颗的偏置，写到传感器 EEPROM 的用户字节区，或者直接放在主控 Flash 里。现场实测下来，三颗传感器校准后的最大偏差可以控制到 0.1℃ 以内，显示界面明显好看了很多。

这里提醒一句：补偿偏置是线性的，但传感器出厂一致性通常不是纯线性误差。如果你的应用要求极高精度，就得做两点校准并考虑非线性修正，但 HVAC 系统到 ±0.5℃ 已经非常够用，没必要过度校准。

5.4 程序重新上电后找不到传感器

设备断电再上电后，偶尔会出现总线扫描不到第三颗远程传感器的情况，手动复位一次又能正常。排查了很久才发现，是远程传感器供电建立时间比主控慢，主控已经完成第一次复位扫描，传感器还没上电，自然没有存在脉冲响应。

解决方案是在远程传感器供电回路中增加了一颗由主控 GPIO 控制的 MOSFET 开关，主控上电后先给传感器供电，延时 200ms 等待电源稳定，再执行总线搜索。这个开关还有一个额外的好处：当传感器真正死线或者进入某种锁死状态时，可以由主控主动断电几秒再上电，把设备拉回正常状态，相当于给总线上的寂寞设备加了一个“重启键”。

最后再分享一个我个人的习惯：每次修改单总线驱动层代码，我都会在实验环境跑一个 24 小时的稳定性测试，统计 CRC 错误次数和温度最大值、最小值、平均值。如果没有连续 24 小时零错误记录，我不会把固件放到现场设备里。这套方法帮我在出差路上排掉了很多大概率在现场才会暴露的时序问题。