企业官网建设流程全解析

做暖通项目的时候，有个场景我印象特别深：控制板装在吊顶检修口旁边，温度探头却要伸进风管里，中间隔着三五米线。用 NTC 直接进 MCU 的 ADC，线上拾到的工频噪声和长线电容带来的延迟能把人折磨疯。后来在一套嵌入式 HVAC 控制器的方案里，我改用 PJ85718DM 这颗本地/远程双通道温度传感器搭配 STM32L442KC 单片机：PJ85718DM 的本地通道测控制板附近的环境温度，远程通道通过双绞线接远端风管探头，一路硬件同时拿到两路温度，STM32L442KC 负责把温度读出来、做校准和告警，再通过 RS-485 上报给楼宇自控系统。这篇文章把当时从选型、硬件布线再到固件调试的完整过程梳理一遍，适合正在做暖通控制器、嵌入式温度采集节点，或者想把 NTC 模拟方案换成数字传感器方案的朋友参考。

1. 这套组合解决了 HVAC 测温里的什么问题

1.1 “本地温度”和“远程温度”在项目里分别指什么

在 HVAC 系统里，本地和远程这两个词不是随便叫的，它们对应的是完全不同的控制逻辑。本地温度通常指控制板所在位置的环境温度，用于判断设备是否过热、是否出现凝露、作为控制器自身保护逻辑的输入。远程温度则指真正参与温控调节的被测点，比如风管送风温度、回风温度、冷热盘管的进出口温度、室外机换热片温度，甚至是对着室外侧的干球温度。

这两个点的物理距离往往差得很远。控制板可能在吊顶里，温度探头在风管内部或者水管表面，走线能从几十厘米长到好几米。PJ85718DM 这类双通道传感器芯片的价值就在于：它把两路测温整合进一颗芯片，本地通道直接测板卡空气温度，远程通道通过专用引脚外接探头，这样不需要为每一路都单独设计一套信号调理电路。实际做下来，两路温度数据还能来自同一颗芯片，温度漂移和基准源都保持一致，上位机做补偿时会省掉很多对不齐的麻烦。

1.2 为什么是 STM32L442KC 而不是普通 8 位单片机

我见过不少同行做温度采集喜欢用 8 位单机，价格低、上手简单，但放到 HVAC 场景里往往会卡壳。这块应用长期上电，控制板可能放在吊顶里，夏天温度能到 60℃ 以上，MCU 不但要稳定工作，还要在无人维护的情况下运行好几年。STM32L442KC 是 Cortex-M4F 内核，带硬件浮点单元，主频最高 80MHz，处理温度换算和滤波算法绰绰有余，关键是它的低功耗模式做得比较全，STOP 模式下的静态电流只有微安级别，对分布式温控节点来说非常重要。

另外一个实际的考虑是外设能力。PJ85718DM 走的是 I2C 接口，L442KC 的硬件 I2C 支持 400kHz 快速模式，还有时钟延展、超时检测这些功能，比起 GPIO 模拟 I2C 稳定得多。同时它自带 LPUART，后续连接 RS-485 或者无线模块都不用再加额外的桥接芯片。再加上 12 位 ADC 留着做电压监测，一颗 MCU 就把采集、逻辑控制、通信全包了，PCB 面积能省下一大块。

1.3 为什么不用 MCU 内置 ADC 直接采热敏电阻

这个选择我犹豫过很久，毕竟热敏电阻方案便宜，很多低成本控制器都在用。但把探头放到几米外，ADC 直采方案的问题就全冒出来了：热敏电阻是非线性器件，软件里要查表或者跑分段拟合，每一条线缆的线阻都会直接参与分压，换一根线就要重新校准；长线还是天然的噪声天线，电机启停时 ADC 采出来的数据能跳好几度。

数字传感器方案的本质区别在于，它把模拟前端放到芯片内部或者探头旁边，总线上传输的已经是数字结果，线缆对精度的影响被大幅压低。PJ85718DM 的远程测温通道用的是恒定电流激励加二极管结压检测的思路，线阻造成的误差可以定量修正，而不是像 NTC 那样整个测量链路都被线缆参数绑架。对我来说，稳定性压倒那一两毛钱的成本差。

2. 硬件上最容易翻车的三个点：远程走线、I2C 上拉与供电

2.1 远程通道走线的三个原则

远程通道是整块板子里最容易踩坑的地方。第一个原则是传感器到探头之间必须双绞，或者至少两根线紧紧并行走，不要飞线。两根线一旦形成一个大的环路面积，电机启动时的 dI/dt 会在环路里感应出噪声，结果就是温度读数间歇性跳动。第二个原则是滤波电容要放在传感器引脚附近，而不是探头端，放在传感器端才能真正滤掉进入信号调理入口之前的噪声，放探头端基本没有作用。电容值控制在 1nF 到 10nF 之间，太大会拖慢内部转换电路的建立时间。

第三个原则很容易被量产忽略：线长一定要固定并记录。远程通道的读数和线阻强相关，设计定型时的线缆长度是 3m，生产阶段换成了 5m，温度会系统性偏高。这个差异不是单纯的现场校准能解决的，因为线阻随线缆批次、温度还会漂。所以我把线缆长度、线缆规格写进了设计规格书，采购那边换供应商之前必须拿样品来实测。

2.2 I2C 上拉电阻与总线速率的选择

PJ85718DM 和 STM32L442KC 之间的 I2C 总线虽然短，但上拉电阻不能拍脑袋。我在 3.3V 供电、100kHz 速率下用 4.7kΩ，跑到 400kHz 时会换成 2.2kΩ。如果总线上还挂了其他设备，每个设备的上拉电阻是并联关系，等效阻值会变小，这时候要确认开漏输出的灌电流没有超过 MCU 引脚的限制。最简单的做法就是只在靠近 MCU 一侧放一组上拉，从机侧全部悬空，避免多设备百花齐放式地上拉。

总线的物理长度也要控制。板内走线没问题，但如果传感器被拉出去放在探头端，SCL/SDA 超过 20cm，就把速率降到 100kHz 并且缩短时钟低电平时间留出余量。L442KC 的 I2C 外设支持时钟延展，从机拉低时钟时主机要能正确等待，固件里这个狗时间要打开，否则在意外的总线占用时，主机会一直卡在读状态里。

2.3 供电去耦与 RS-485 接口的隔离处理

HVAC 设备里最不缺的就是干扰源：继电器吸合、风机启停、电动阀开关。电源轨上的毛刺如果直接灌进传感器，温度数据就会出现周期性跳变。PJ85718DM 的电源引脚旁边一定要放 0.1uF 陶瓷电容，并且电容的地要直接打过孔回到 MCU 的地平面，不要绕远路。如果板上有电机驱动，建议再把 LC 滤波加在模拟供电之前。

RS-485 接口那边我也吃过亏：收发器的电源没有单独滤波，现场总线一波动，MCU 就被拉复位。后来在 RS-485 芯片电源前面串一个 10Ω 电阻再加 0.1uF 电容形成 π 型滤波，A/B 端子外接 TVS 管，雷击浪涌和静电这些问题才算真正压住。对 HVAC 这种常年在现场跑的设备，接口防护宁多勿少，这部分的成本不值得省。

3. 固件主线：从寄存器字节到稳定可用的温度值

3.1 PJ85718DM 的初始化与读取流程

拿到 PJ85718DM 的第一步是读 ID 寄存器确认芯片型号，防止 PCB 贴错批次。然后写配置寄存器，把转换模式设成连续转换，分辨率设成 12 位，转换速率根据现场需求设成每秒 4 次左右。HVAC 温控的响应周期一般在 1 到 5 秒，每秒 4 次绰绰有余；如果后面要走电池供电，就必须改成单次转换模式，需要时启动一次转换，等 50ms 再去取数。

温度寄存器的读取逻辑很固定：读高字节寄存器，再读低字节寄存器，两个字节拼起来取高 12 位有效数据。下面的 C 代码是我在实际项目里用的读取函数，寄存器地址按实际手册调整即可：

static float pj85718_read_temperature(uint8_t reg_hi) { uint8_t hi = i2c_read_byte(PJ85718_ADDR, reg_hi); uint8_t lo = i2c_read_byte(PJ85718_ADDR, reg_hi + 1); int16_t raw = ((int16_t)hi << 4) | (lo >> 4); if (raw & 0x1000) { raw |= 0xF000; /* 符号扩展，处理负温度 */ } return raw * 0.0625f; /* 12 位分辨率，0.0625 ℃/LSB */ }

这个 12 位格式在大多数同类芯片里都是通用的，但不要直接照抄，先把 datasheet 里的寄存器位定义对一遍再下手。

3.2 温度数据格式与定点数内部处理

PJ85718DM 的 12 位温度数据里，每个 LSB 对应 0.0625℃，也就是 1/16℃。正温度很简单，直接把原始值乘 0.0625 就得到浮点温度；负温度则是二进制补码，所以我在代码里做了符号扩展。如果 MCU 没有 FPU，浮点运算虽然也能跑但会占掉不少时间，这种情况下更推荐内部全部用定点：温度值直接乘以 16 存成整数，Modbus 上报的时候再换算成 0.1℃ 的整型，省掉一整套浮点库。

我自己的习惯是底层驱动只返回原始 uint16_t 和错误标志，上层逻辑统一用定点数做滤波和阈值判断，只有在最后打包通信帧时才做单位换算。这样做的好处是所有计算环节都不会引入浮点误差，而且整个工程里温度的表示方式只有一种，代码 review 的时候不容易出现"这个变量是温度还是原始码"的混乱。

3.3 告警阈值与防抖机制

PJ85718DM 这类芯片通常内置高低温告警寄存器，可以设置 T_high 和 T_low，还能直接输出一个告警引脚。HVAC 场景里我会用这套逻辑做盘管防冻和风机过热保护，比如盘管温度低于 5℃ 开始关水阀防风冻，风机电机表面温度高于 90℃ 停机。

但告警触发必须防抖，不能读一次超限就动作，否则现场一个毛刺就会让继电器反复吸合。芯片内部一般有故障队列寄存器，要求连续 2 到 4 次超限才真的触发；固件这边我又加了一层逻辑，连续 3 个采样周期异常才认为是真的故障。两层防抖叠加之后，现场误报率基本降到零，等温度恢复正常还需要持续一段时间才能复位，这是有意为之，避免控制点频繁切换。

3.4 STM32L442KC 的 I2C 初始化与错误重试

STM32L442KC 的 I2C 初始化用 LL 库写起来很干净。要配置的关键项包括引脚复用、外设时钟、7 位从机地址模式、时序寄存器里的上升时间和保持时间。最需要注意的是读寄存器时的重复起始条件：先发从机地址写方向，写寄存器指针，然后不发 STOP，直接再发一次从机地址读方向去读数据。很多第一次上手的人在这里出错，STOP 发得太早，导致传感器还没有把数据准备好，读出来的全是 0xFF。

错误重试方面，我固定用一个带超时计数的读取函数，每次 I2C 操作失败就重试 3 次，3 次都失败就标记数据失效，同时沿用上一次的有效温度值向上一层输出。温度是慢变量，几秒内保持旧值比突然跳变到 0 或者上一次错误值要合理得多，上位机看到状态字里的失效位也能明白当前数据是旧的，而不是去猜一个诡异的温度。

4. 远程温度比实际高 1.3℃，一条完整的排查链路

4.1 现象：本地正常，远程读数系统性偏高

样机装配完以后做风管模拟测试，本地通道读到 25.1℃，和标准温度计一致；远程通道却显示 26.4℃，标准温度计实测探头处是 25.1℃。偏差 1.3℃，而且非常稳定，不跳动，只随探头线缆长度变化。我一开始怀疑探头里的二极管被静电打坏了，连续换了三个新探头，读数还是 26℃ 附近，问题显然不在探头本身。

这种系统性偏差往往不是偶发故障，最怕的就是在这种时候东一榔头西一棒子地猜。我先把固件嫌疑排除，单独打印原始寄存器值和换算后的 LSB，发现数值稳定，没有毛刺；再把同一颗传感器用两根 5cm 短导线连接探头，读数立刻回落到 25.2℃。到这里基本确定问题出在探头线缆上。

4.2 用变量实验定位线阻影响

接下来用万用表四线法测探头线的电阻，3 米双绞线总阻值大约 4.6Ω。为了验证这个数据跟读数的关联，我做了三组对照：分别用 1m、3m、6m 的同规格双绞线接同样的探头，远程读数依次是 25.5℃、26.4℃、27.2℃。偏差和线长几乎线性增长，到这一步，线阻造成的误差已经没有悬念了。

再往下想，远程通道测的是二极管结压降，芯片输出恒定偏置电流流过探头二极管和整个回路。线缆的串联电阻会在这段电流上产生额外压降，这部分压降被芯片当成二极管结压的一部分，于是温度读数整体偏高。偏置电流越大、线阻越大，误差越明显。这就是为什么换了短导线之后误差消失的原因。

4.3 软件补偿的两种做法与实际效果

线阻误差已经定量了，接下来就是怎么修。最简单的办法是在读取远程温度后减去一个固定偏移，比如现场标定偏差 1.3℃，代码里直接减掉。但单点偏移只对校准温度附近有效，因为线阻压降基本不随温度变，而二极管结压随温度变化，误差在整个温区里不是完全恒定的。

更稳的做法是做两点校准。在 0℃ 和 60℃ 两个恒温点分别记录偏差，拟合出一条修正曲线，内部根据当前温度插值修正。我们实际做下来，3m 标准线缆下，20℃ 到 35℃ 的温区误差全部压进了 ±0.3℃，完全满足暖通控制的要求。量产阶段把这个修正系数写进设备的标定参数区，每台机器出厂前做一次 25℃ 常温校验就够了。

4.4 沉淀下来的远程测温避坑清单

这张表后来直接印在了我自己的项目管理 checklist 里，每次评审方案时逐项过一遍，远程通道的坑基本就挡在了实验室阶段，而不是等到现场批量安装再去擦屁股。

5. 接入 HVAC 系统：Modbus 上报与低功耗策略

5.1 Modbus RTU 寄存器表设计

PJ85718DM 和 STM32L442KC 做出来的产品，最终要拿去和楼宇自控系统对接，工业现场绕不开 Modbus RTU。我习惯把寄存器表设计得很克制：只实现 03 功能码读保持寄存器，用来上报温度；再实现一个 06 功能码写单寄存器，用来写入远程温度校准偏移值。寄存器分布如下：

通信参数用 9600bps、8 位数据位、1 位停止位、无校验，这是楼宇自控设备最常见的配置。CRC16 用查表法实现，现场几个设备对接下来帧都没错。需要提醒的是 RS-485 收发器的 DE/RE 引脚控制，发送完最后一个字节后不能立刻拉低，要等移位寄存器把数据全部送出去，一般加两个字节时间左右的延时，否则总线上最后一个字节的末尾会被截断，从机永远回不了响应。

5.2 低功耗模式与平均功耗估算

HVAC 场景里不是所有节点都有 220V 供电。温度巡检节点、无线温控器这类设备经常要靠电池跑很久，所以低功耗策略在项目里占了比较大的一块设计比重。STM32L442KC 的 STOP2 模式电流很低，PJ85718DM 设成单次转换模式，需要时启动转换，等待完成后再读取。整个周期我控制在 10 秒一次，唤醒后运行约 20ms 完成一次转换、读取、组包、发送，然后重新进入 STOP2。

按这个表估算，平均电流大约 8uA，2000mAh 电池假设可用容量打 8 折，理论上能撑二十多年，实际限制早就变成了电池自放电而不是负载电流。所以低功耗节点真正要注意的是别让 RS-485 收发器一直处于监听状态，那种模式电流毫安起步，直接把电池功耗打穿。我的做法是平时把收发器整个断电，只在唤醒发送窗口上电，发完就扔回关机模式。

5.3 后续扩展：多节点、无线化和远程升级

这套本地/远程温度监测架构往上扩展并不吃力。一个很常见的做法是每个节点分配独立 Modbus 地址，挂到同一条 RS-485 总线上，集中控制器按地址轮询。如果布线不方便，LPUART 直接接一个无线透传模块，把 Modbus 帧原封不动地通过无线链路送出去，上位机侧不需要改任何协议解析逻辑，这是成本最低的无线化路线。

固件升级方面，STM32L442KC 自带的 flash 空间足够，在 bootloader 里实现一个基于 Modbus 写帧的分块写入协议，配合 CRC 校验和备份区回滚，就可以实现现场不拆机升级。底层温度采集的任务仍然由 PJ85718DM 独立完成，升级过程中温度和告警逻辑不受影响，对 HVAC 这种不允许长时间停机的设备来说，这个特性非常实用。

最后说一个我保留到现在的习惯：拿到新批次 PJ85718DM 的第一件事是读 ID 和校准寄存器，把所有寄存器地址和系数都做成宏定义。温度芯片偶尔会有批次差异，寄存器位定义也可能微调，代码里如果不做这层隔离，后面维护时对着一个莫名其妙的偏移量会排查很久。把型号、批次、寄存器版本、校准参数写清楚，这台设备三年后再回来改需求，也能轻松接手。