企业官网建设流程全解析

搞嵌入式的朋友应该都有过这种经历：一个设备跑着跑着突然过热死机，或者空调系统明明显示温度正常，现场却冷得受不了。温度监测这件事，单独看每个环节都不难——读传感器、算温度、传数据，但真正落地到项目里，会发现全是细节。这篇文章想梳理一套我实际整理过的方案：用 PJ85718DM 数字温度传感器配合 STM32F302VC，做一个既能测本地温度、又能采集远程温度的监测系统，覆盖嵌入式设备散热监控和 HVAC 风管、房间温度采集两类场景。

我最近刚好在整理这套方案，从芯片选型、硬件连接、驱动代码到现场调试都过了一遍，过程中踩了不少坑。现在把这套思路完整写出来，供做嵌入式开发或者暖通现场集成的朋友参考。哪怕你手上用的不是这个型号，里面关于 I2C 传感器读取、RS485 组网、滤波处理和故障排查的思路，也一样能用。

1. 项目设计思路：先搞清楚“本地”和“远程”到底怎么划分

1.1 为什么要把温度监测拆成两路

温度监测听起来很简单，就是读一个数而已。但一进到实际项目，就会发现“本地”和“远程”是两个完全不同的技术问题。

本地温度，指的是离 MCU 很近的地方，比如设备内部 PCB 附近的空气温度、功率管散热器表面温度、机箱内热点温度。这种场景下，传感器和主控之间的物理距离一般不超过几十厘米，直接走 I2C 总线读就行，实时性好、成本低、布线也简单。

远程温度就麻烦多了。在 HVAC 项目里，风管温度传感器可能装在十几米甚至几十米外的空调箱、末端风口、冷水管道上，主控制器和传感器之间隔了好几道墙、几个强电桥架。如果强行用 I2C 把线拉过去，总线电容会变大、波形会畸变，信号很容易受变频器、压缩机的电磁干扰，最后读到的是上下乱跳的数。

所以我在设计这方案时，第一件事不是选芯片，而是把测温架构拆开：本地点位用 I2C 直连，远程点位走带隔离的通信总线组网。这样本地和远程互不拖累，本地响应快，远程够稳定。

1.2 器件的选型逻辑

确定架构之后才进入选型。

温度传感器这一侧，我用的 PJ85718DM 是一颗数字输出的 I2C 温度传感器，低功耗、体积小，温度数据直接通过寄存器读出来，不必像 NTC 那样先做 ADC 采集、再查表或跑公式换算。它最吸引我的是省事：I2C 读两字节，按分辨率换算就是温度，免掉了模拟链路里关于基准、放大、滤波、校准的一大堆事情。

有人会问：为什么不用 NTC 或者 PT100？我也对比过，原因很直接。NTC 便宜，但非线性强，而且必须依赖 ADC 精度；在 HVAC 这种环境温度变化范围不大、但对稳定性有要求的场景，NTC 的标定和查表工作是纯增量负担。PT100 精度确实高，但要配恒流源、精密运放、冷端补偿，PCB 面积和物料成本都上去一截。PJ85718DM 这种数字传感器，相当于把标定和线性化都做进芯片里了，对嵌入式产品来说，少一个需要人工介入的环节，就少一个现场出问题的点。

MCU 这颗选了 STM32F302VC。它属于 STM32F3 系列，Cortex-M4F 内核，带硬件浮点单元，主频 72MHz。温度监测本身不需要很强的算力，但 VC 后缀这颗芯片的封装是 LQFP100，引脚数量充裕，I2C、USART、SPI、CAN 这些外设基本都齐了。更关键的是，F3 系列的特色在于工业控制相关的模拟外设比较丰富，后续如果要把温度数据和电机、风阀、水泵联动，不用重新换平台。我实际用下来的体会：F3 相比 F1 多出来的那点计算性能和 FPU，在处理滑动平均、温度曲线平滑这类需求时很舒服，不需要做定点换算。

我把三个常见方案放在一起对比一下，方便各位根据自己的场景核对：

这个表只是参考，不是说 NTC 一无是处。如果做的是极低成本、大批量的消费产品，NTC 依然有它的位置。但如果你和我一样需要快速、稳定地把测温链路跑起来，数字传感器确实是最省心的起点。

1.3 整体通信拓扑规划

整体拓扑我采用了“主机 + 本地传感器 + RS485 远程节点”的结构。STM32F302VC 作为主节点，板载直接挂 1 到 2 颗 PJ85718DM，负责本地温度采集；同时通过 USART 外接一个 RS485 收发器，接到外面的远程传感器节点总线上。每个远程节点也可以是一颗 PJ85718DM 加一颗小 MCU，负责把温度转换成 Modbus 寄存器，供主节点轮询读取。

这样设计的核心好处是解耦。本地 I2C 链路非常短，不受远距离干扰影响；远程链路使用 RS485 差分信号，抗共模干扰强，传输距离可以到几百米，而且天然支持多点组网。后续要增加测点，只需要在总线上挂一个新的节点，主节点代码里加一条配置，不用重新布线、不用改硬件。

如果现场只需要 1 到 2 个远程测点、距离也不超过几米，那确实没必要上 RS485，直接 I2C 加总线缓冲器也能跑。但从长期维护的角度看，用 RS485 组网之后，每个测点都是独立节点，故障隔离会清晰很多。这个选择看你对自己项目的判断，没有绝对正确，只有适合不适合。

2. 硬件连接与关键参数

2.1 PJ85718DM 的接口与典型电路

PJ85718DM 这类 I2C 温度传感器的外围电路非常简洁。基本引脚就是电源、地、SDA、SCL，另外可能有一到两个地址配置引脚，有的型号还有报警输出引脚。实际使用中，我习惯在 VDD 和 GND 之间放一个 100nF 去耦电容，靠近芯片引脚放置，不要拉到很远，否则电源噪声会直接耦合到温度读数上。

I2C 总线需要上拉电阻，这个位置很容易被忽略。上拉电阻的大小取决于总线电容和通信速率：标准模式（100kHz）下常用 4.7kΩ，快速模式（400kHz）下多用 2.2kΩ。如果板上有多个 I2C 设备，总线电容变大，上拉电阻就要适当调小，否则信号上升沿会变缓，严重时直接导致通信不稳定。我用示波器看过一个案例，上升沿缓得像一条斜线，就是上拉电阻选太大导致的。

地址配置引脚要提前规划。如果板子上要放两颗以上的传感器，需要把它们配置成不同地址。PJ85718DM 具体有几个地址引脚，做硬件前最好翻一下数据手册确认，不要像我第一次那样直接默认只有一颗，结果第二颗传感器焊上去发现地址冲突，还要飞线改电平。

2.2 STM32F302VC 外设配置要点

STM32F302VC 这边，我主要用到了两组外设：一组 I2C 用于读本地 PJ85718DM，一组 USART 用于接 RS485 收发器。

I2C 引脚要查芯片的引脚复用表，避免想当然。比如 I2C1 可能映射到 PB6/PB7，也可能是 PB8/PB9，具体取决于封装和复用配置。做 PCB 的时候就要把 I2C 引脚确定下来，再配合代码里的 GPIO 配置。RS485 方向控制也有讲究，收发器通常有 DE 和 RE 两个引脚，一般会在硬件上并在一起，由 MCU 的 GPIO 控制。发送数据时拉高，接收时拉低。方向切换时序要留够余量，发送完最后一字节之后不能立刻切到接收，否则最后一两个字节可能就丢了。

时钟方面，STM32F302VC 支持外部晶振和内部时钟。RS485 波特率要准，建议用外部晶振，避免内部 HSI 温漂导致长时间运行后通信错位。我曾经为了省两颗电容用内部时钟，结果现场温度一上来，RS485 偶发乱码，排查了很久才发现是时钟精度问题。

2.3 供电与抗干扰设计要点

温度和干扰是分不开的，尤其在 HVAC 现场，变频器、接触器、压缩机的启停都会带来强烈的电磁干扰。我总结下来，供电和布线方面有几点值得注意。

传感器电源最好经过 RC 滤波，一个小电阻加一个电容就能挡住不少高频毛刺。远程节点的供电要单独隔离，不要和现场强电设备共用开关电源，否则地线上的一点噪声就可能把通信链路打乱。RS485 总线在施工时用屏蔽双绞线，屏蔽层单点接地，不要两端都接地，否则屏蔽层会变成地环路的一部分，反而引入更大的干扰。

关于终端电阻，总线上最远的两端各接一个 120Ω 电阻。很多人只在主机端接，漏掉远端节点，导致波形反射，高速率下数据错乱。我建议在硬件设计时就把终端电阻的焊盘预留出来，现场通过跳线或拨码决定是否接入，这样可以适应不同长度的总线。

3. 软件驱动：STM32F302VC 读取 PJ85718DM 的完整流程

3.1 I2C 寄存器读取流程

PJ85718DM 一类的 I2C 数字温度传感器，寄存器结构大同小异：温度寄存器是 16 位，其中高 12 位是有效数据，低 4 位一般不用。读取流程分成两步：先写一次寄存器指针，把片内地址指向温度寄存器，然后再连续读两个字节。这样做是为了避免在多次轮询时，传感器内部寄存器指针跑到别的位置。

代码看起来是这样：

float read_pj85718dm(uint8_t dev_addr) { uint8_t reg = 0x00; // 温度寄存器地址，以实际数据手册为准 uint8_t buf[2]; uint16_t raw; int16_t val; // 写指针寄存器 i2c_write_reg(dev_addr, &reg, 1); // 连续读两个字节 i2c_read_bytes(dev_addr, buf, 2); raw = (buf[0] << 8) | buf[1]; val = (int16_t)(raw >> 4); // 低 4 位无效，先右移 return val * 0.0625f; // 12 位分辨率，LSB 为 0.0625°C }

这段代码里有几个细节要特别注意。一个是右移之前先要按有符号数处理，否则负温度会变成很大的正数；另一个是低 4 位必须屏蔽或右移掉，不然读数会在低位反复跳动，看起来像信号噪声，其实是数据处理不到位。如果芯片的实际分辨率不是 12 位，换算系数也要跟着改，比如 14 位分辨率时 LSB 就是 0.0078125°C。具体的位数和寄存器地址，以数据手册为准，这行字值得印在代码注释里。

3.2 滤波算法怎么选

读出来的温度值不能直接用。嵌入式设备里，风扇启动、功率变化都会让测温点温度小幅度波动；HVAC 现场更明显，压缩机一启一停，气流方向变化，温度读数能瞬间跳 0.5°C 以上。直接把这个数显示给用户，大概率会被投诉。

滤波不是越强越好，关键看响应速度要求。嵌入式设备做散热保护，需要尽快发现温度上升，滤波窗口太大会把过温信号平滑掉，等你看到数值已经晚了。HVAC 场景则刚好相反，房间温度本来就变化慢，稍微平滑一点完全不影响体验，反而更稳定。

我当时实际用的是滑动平均法，维护一个环形缓冲区，嵌入式设备取 4 到 8 次平均值，HVAC 测点取 16 次，采样间隔统一设 1 秒。如果现场对响应速度有更高要求，可以改成一阶低通滤波，用一个加权系数调节平滑程度。系数取 0.8 表示偏向新值，取 0.2 表示偏向历史值，这个系数比用固定窗口灵活，但调试时更依赖手感。

3.3 温度数据的异常判定

除了滤波，我还加了两层异常判定。第一层是范围检查，PJ85718DM 的测量范围通常在某个区间内，如果读到的值超出合理范围，比如远远超过工作温度上限，那基本可以判断传感器故障或者通信异常。第二层是变化率检查，温度不会在 1 秒内突变 10°C，如果出现这种数据，大概率是读取错位或者总线干扰。

这两层检查配合一个简单的异常计数，可以避免把了一次偶发错误当成真实温度。我的处理逻辑是：连续 3 次读到异常值，才上报传感器故障；中间只要恢复正常，就重新计数。这样既不会漏报，又不会因为一次抖动误报。

4. 远程温度采集的工程实现

4.1 RS485 与 Modbus RTU 组网

远程采集我选择了 RS485 物理层加 Modbus RTU 协议。这个组合在工业现场和 HVAC 行业太常见了，几乎所有上位机、触摸屏、楼宇控制器都支持 Modbus 协议，后续接入第三方系统不需要单独开发。

主从结构很简单：STM32F302VC 作为 Modbus 主站，按地址轮询远程节点。远程节点则是从站，每个节点配置一个地址，把本地采集到的 PJ85718DM 温度放到保持寄存器里。主站发 03 功能码读寄存器，从站返回温度值，再加上 CRC16 校验。

轮询周期要算一下，别拍脑袋。以 9600bps 波特率为例，一个标准 RTU 帧大约是 8 个字节，加上帧间隔，一帧约 12ms 左右。挂 16 个节点，一轮完整轮询就是 200ms 上下；扩展 32 个节点，也就 400ms 到 500ms。如果每轮之间再留一点余量，整体刷新周期 1 秒完全够用。实际项目中，温度不像电机转速那样需要毫秒级刷新，9600bps 的稳定性比高速率更好。

4.2 远程节点设计要点

远程节点是颗小系统，不复杂但有几个容易忽略的点。

第一，从站要处理总线空闲时的数据接收和超时机制。如果主机因为异常停止轮询，从站应该能够在一段时间后自行恢复等待状态，而不是死等。第二，从站的温度寄存器要增加 CRC 校验，防止瞬时干扰导致寄存器值被改写。第三，远程节点的电源最好用隔离电源，至少也要用 DC-DC 与强电侧隔开，否则 RS485 的共模电压会漂移，严重时烧毁收发器。我见过有些项目为了省成本，远程节点直接用一个简易稳压器连着现场 24V 电源，结果电机一启动，RS485 就乱码，最后拆开一看，收发器芯片损坏的也不少见。

PJ85718DM 在远程节点上的读法和本地完全一样，只是数据最终通过 Modbus 寄存器对外暴露。如果远程节点用的是低功耗 MCU，还可以在两次采样之间让传感器进入低功耗模式，不过一般 HVAC 现场不差这点功耗，我就没有做太多优化。

4.3 主机汇总与对外接口

主机侧的逻辑有些像是“温度数据的中转站”。STM32F302VC 定时读本地 PJ85718DM，同时通过 RS485 轮询远程节点，把得到的所有温度保存在一个统一的数据数组里。这个数组再通过另一路串口或者以太网模组，提供给触摸屏、上位机或者楼宇控制器读取。

我在做对外接口时，直接了当地采用 Modbus RTU 从站模式。也就是说，主机对上是一个从站，对外提供一组保持寄存器，寄存器 0 到 3 放本地温度，寄存器 4 到 35 放远程节点温度。这样无论是接触摸屏还是接组态软件，都只需要配置一张点表，不需要写私有协议，后期维护成本低很多。数据帧格式也建议在头文件里集中定义，不要散落在各处，后面加测点的时候改一处就可以了。

5. HVAC 场景适配与现场经验

5.1 温度测点选型与安装

HVAC 场景里的温度测点不能一概而论，风管温度、回风温度、冷水管温度和房间温度，安装方式完全不同。

风管温度传感器要保证探头插入气流中间位置，不能贴管壁，否则测的是管壁温度不是空气温度。安装孔要做好密封，防止漏风。回风温度测点要避开新风直吹的位置，否则测到的是混合不均的气流。冷水管表面温度测量需要良好的导热耦合，用导热硅脂填充探头和管壁之间的缝隙，再用保温棉覆盖，否则环境温度会直接影响读数。嵌入式设备里则相反，传感器要尽量贴近热源，比如功率器件旁边，但不要紧贴会产生高频干扰的开关节点。

PJ85718DM 如果直接用裸芯片布置在 PCB 上，适合测板级环境温度。如果要做成风管探头，需要把芯片放进防水探头壳里，引线出来接主板。这类封装变化会影响热响应时间，实测下来，裸芯片响应可能只要几秒，套上外壳之后可能要几十秒才能稳定，程序里的滤波窗口也要跟着调整。

5.2 现场测量误差的常见来源

凡是做过现场调试的人都知道，仪表显示温度与实际温度不一样是最常见的投诉。其实大多数测量误差不是传感器精度不够，而是安装和传热方式的问题。

传感器放在气流死角，风吹不到，温度自然和主流温度差别大。传感器壳体和热源之间没有导热介质，中间是空气，热阻大，响应慢。传感器自身发热，虽然数字传感器功耗很低，但在密闭壳体内长时间工作，壳体内部温度会高于环境温度，形成自热误差。遇到这种情况，我一般拿红外测温枪和接触式温度计做对比，确认误差来源后再做补偿，而不是盲目改软件偏移量。

5.3 监测与控制联动

温度监测系统不是拿来欣赏的，最终要联动控制。嵌入式设备里，温度超过设定阈值要触发报警或者调速散热；HVAC 系统里，风管温度要参与冷热水阀的开度调节。只采集不上报，这套系统的价值就少了一大半。

我在做联动时，用的是滞回控制，避免继电器频繁吸合。以散热风扇为例，设备温度高于 55°C 开启风扇，低于 45°C 关闭，中间这 10°C 是滞回区间。如果精确到单点控制，现场会听到风扇不停地启动停止，人也受不了。HVAC 的电动阀控制同理，温度上下限之间留缓冲，阀门调节频率会低很多。

6. 调试实录与问题速查表

6.1 I2C 总线无应答排查

发 I2C 地址之后没等到 ACK，这是最常遇到的现象。排查顺序其实很固定：先用万用表量芯片供电电压，确认 VDD 和 GND 没有接反；再用示波器抓 SCL 和 SDA 波形，确认有没有时钟、数据波形是否完整；之后检查地址引脚电平是否和代码里的设备地址一致；最后看上拉电阻是否焊上、阻值是否合适。

我实际碰到过一次特别隐蔽的问题，原因是 PCB 上芯片的 SDA 和 SCL 印反了，照着丝网印接上去，波形始终是乱的。所以遇到 I2C 不通，先不要怀疑代码，拿放大镜看芯片本体引脚和 PCB 封装是否一一对应，很多低级错误都藏在这种地方。

6.2 读数跳变或者长时间不变

读数跳变，先看低 4 位有没有屏蔽，再看滤波窗口够不够。很多“噪声”其实是软件问题。读数长时间不变，多半是寄存器指针没有正常切换，每次读的都停留在同一个位置。I2C 连续读操作一定要记得先写地址指针，不然就可能出现这个现象。

6.3 RS485 链路通信异常

RS485 问题排查时，先看 A/B 是否接反，这是现场接线的头号问题。A、B 反接之后，差分信号倒置，整个总线上都是乱码。再看终端电阻，距离较长的现场，少了远端电阻，波形反射会让数据偶发出错。然后是 DE/RE 方向控制时序，方向切换太快，会吃掉发送末尾的数据。最后检查屏蔽地是否单点接地，地环路是隐藏杀手，排查难度远高于前面几个问题。

6.4 常见问题速查表

6.5 几条独家避坑心得

做一个比较完整的固件方案时，有一点很重要：温度采集参数不要一上来就定死，尤其是滤波窗口长度。现场环境千差万别，我建议先在目标现场跑几个小时，用串口把原始滤波前后数据都打出来，再决定要不要加大平滑力度。不要觉得这是浪费时间，现场数据和实验室数据往往差很多。

还有就是远程节点的地址分配，要在硬件上留好拨码开关或者跳线焊盘。如果地址靠程序固化，后期临时增加节点，就要重新烧录，很麻烦。我在第二版就改了设计，把地址引脚引出来接到拨码，现场想换节点、换地址都很方便。这个小改动，后来帮我省了不少去现场跑腿的时间。

做这套方案的过程中，我自己最大的感触是：温度监测系统最后出问题的地方，往往不是算法复杂不复杂，而是传感器装得准不准、通信链路稳不稳。PJ85718DM 和 STM32F302VC 的组合，胜在简单和稳定，数字传感器免标定，配上 RS485 组网又能把本地和远程清晰地分开，后期维护思路非常直观。如果你也在搭类似的系统，我的建议是先打通一条链路，把一本地一远程两个测点调稳定，再去扩展更多节点。链路通了，后面的工作就只是复制和参数微调了。