企业官网建设流程全解析

做嵌入式温度监测这些年，最烦的就是“测不准”和“传不远”这两个问题。尤其是在HVAC（暖通空调）这类现场环境里，设备间距离远、干扰多、温度变化周期长，普通的NTC热敏电阻方案往往校准麻烦，而纯本地测温芯片又解决不了远程监控的需求。最近我基于PJ85718DM这颗数字温度采集芯片，搭配STM32F767BI主控，做了一套同时覆盖本地温度采集与远程温度上报的监测方案，在嵌入式和HVAC两个场景里都能直接落地。这篇文章就把这套系统的完整设计思路、硬件连接、软件驱动、整机标定和现场调试经验全部拆开来讲，适合正在做温控器、风机盘管控制器、嵌入式数据采集设备，或者想把手里的MCU项目接上温度监控功能的朋友参考。

1. 项目方案定位与器件选型逻辑

1.1 为什么选PJ85718DM这颗芯片

接触过温度采集的朋友应该都有体会：NTC方案成本低但一致性差，每批物料都需要单独校准；DS18B20虽然用起来简单，但精度一般，而且单总线在长线传输时容易受干扰。PJ85718DM这颗芯片我刚开始用的时候也犹豫过，毕竟市面上数字温度传感器选择很多，但真正跑过几个项目之后发现，它在“本地测温”和“远程测温”的双场景需求下确实有天然优势。

PJ85718DM内部集成了一路高精度本地温度传感通道，同时支持外接传感器的远程测温通道。也就是说，一颗芯片能同时读出“芯片附近的环境温度”（本地温度）和“通过延长线放在远处的测温点温度”（远程温度）。这对HVAC场景特别实用，因为空调箱的送风温度、回风温度、盘管进出水温度往往分布在设备的不同位置，如果用独立传感器就要布好几路信号线，而PJ85718DM一颗芯片就能覆盖两个测点，PCB布线和物料清单都能简化。

另外这颗芯片走的是I2C接口，正好和STM32F767BI的硬件I2C外设直接对接，驱动代码不用自己用GPIO模拟时序，稳定性和代码量都更可控。测温分辨率做到0.0625℃级别，温度数据以16位数字量直接输出，MCU拿到原始值后只需要做一点换算和滤波，不需要额外搭放大电路和ADC参考源。项目开发周期里最烦的就是模拟前端调试，PJ85718DM把这一整个环节都省掉了。

1.2 STM32F767BI在系统里的角色定位

STM32F767BI这颗料属于STM32F7系列的高性能型号，Cortex-M7内核，主频可以跑到216MHz，双精度硬件FPU，板载2MB Flash和512KB RAM。用在这种温度采集场景里，说实话性能是溢出的，但我的选型思路很明确：宁可主控性能富余，也不能在后续加功能时被迫换平台。

这套系统除了温度采集，还要承担Modbus协议栈、本地LCD显示刷新、按键输入处理、远程通信上报、看门狗喂狗这些任务。如果用低端的F1系列，也不是不能做，但一旦要在上位机端加历史曲线查询、本地存储、多从机扩展，CPU负载和Flash空间马上就会吃紧。F767BI的2MB Flash对协议栈加日志存储非常友好，512KB RAM足够撑起几个环形缓冲区，运行RTOS也没压力。另外它的硬件I2C、UART、SPI外设数量充足，后续想扩展4G模块、RS485收发器、Wi-Fi模块都不用纠结引脚复用冲突。

单片机的“选型超额”在我看来是一种值得投入的成本。嵌入式产品一旦进入量产，换主控意味着固件重写、硬件改版、认证重跑，这些隐性成本远高于芯片本身的差价。所以在这个项目里，PJ85718DM负责“感知温度”，STM32F767BI负责“统筹数据”，两者配合，前端采集的实时性和后端处理的扩展性都兼顾了。

1.3 本地与远程温度的统一处理架构

整个系统的温度数据流是这样的：PJ85718DM通过I2C接口持续输出本地温度原始值和远程温度原始值，STM32F767BI在定时中断里读取这两路数据，经过换算、滤波、越限判断之后，一方面在本地屏幕上实时显示，另一方面按照预设周期打包成通信帧，通过RS485总线或者以太网上报给上位机。

我在设计这个数据流的时候，刻意把“采集”和“上报”解耦。采集部分跑在定时中断里，固定每100ms读一次PJ85718DM；上报部分跑在主循环或者RTOS任务里，按1秒、10秒、60秒可配置的周期向上位机发送数据。这样做的好处是：即使通信链路拥堵或者上位机响应慢，温度采集的实时性也不会受影响。温度数据始终在本地保持最新，通信只是把最新数据同步出去，而不是等通信空闲了才去触发采集。

这个思路有点类似“生产者-消费者”模型。采集任务就是生产者，不停地把温度原始值丢进共享缓冲区；通信任务是消费者，按自己的节奏从缓冲区取最新数据打包发送。缓冲区只需要放最新一次的数据即可，不需要队列堆积，这样既能保证数据新鲜度，又不会因为缓冲区溢出导致故障。实际操作中我在内存里定义了一个结构体变量，包含本地温度、远程温度、采集时间戳、数据有效性标志，采集任务负责更新，通信任务负责读取，两个任务之间的互斥只需一个临界区保护就能解决。

2. 硬件电路设计与关键连接细节

2.1 PJ85718DM与STM32F767BI的接线方案

PJ85718DM的引脚不多，典型应用就是标准I2C接线：VCC接3.3V电源，GND接系统地，SCL和SDA分别接到STM32F767BI的PB8和PB9引脚（这是F767的I2C1引脚），在SCL和SDA上各接一个上拉电阻到3.3V。芯片的A0、A1、A2地址选择引脚根据实际需求接高或接地，用来配置设备的I2C从机地址，这样一条I2C总线上最多能挂8颗芯片，对多测点系统来说扩展很方便。

远程测温通道的连接方式要看传感器类型。PJ85718DM的远程通道支持外接二极管型传感器或者NTC电阻，具体取决于芯片的配置模式。我在项目里用的是NTC外接方式，通过一颗10kΩ NTC热敏电阻接在远程传感引脚上，NTC的另一端接地，同时在引脚上并联一颗0.1μF的旁路电容，用来滤除长线引入的高频干扰。如果被测距离超过1米，我还会在NTC两端加一个小阻值电阻串联，起限流和抗干扰作用。

STM32F767BI这边，我给I2C1的两个引脚配置为开漏输出模式，外部上拉电阻选了4.7kΩ。这个阻值在3.3V供电、总线速率100kHz的标准模式下是合适的，既能保证信号的上升沿足够陡，又不会因为上拉过强导致芯片驱动电流超限。如果以后要把总线速率提到400kHz，建议把上拉电阻换成2.2kΩ。

2.2 电源设计与信号完整性处理

温度采集系统最容易踩的坑就是电源纹波。PJ85718DM这类数字传感器虽然内部有比较完善的模拟前端，但如果供电电源纹波过大，测温数据依然会出现周期性跳变。我在设计中给PJ85718DM的供电加了RC滤波：3.3V经过一颗10Ω电阻后进芯片VCC，电阻后并联一颗10μF钽电容再加一颗0.1μF瓷片电容。10Ω电阻和10μF电容组合起来能形成一个低通滤波器，对几十kHz以上的高频噪声有很好的抑制效果，同时因为PJ85718DM的功耗本身很低，10Ω电阻上的压降完全可以忽略。

STM32F767BI的电源设计遵循ST官方推荐的外围电路，每个VDD引脚就近放一颗0.1μF去耦电容，VCAP引脚按要求接4.7μF电容。这里有一个容易忽略的细节：F767的VCAP引脚不是普通电源引脚，它是内部核心稳压器的外部滤波电容接入点，电容的ESR和容值都有要求。如果省了这颗电容或者容值不对，MCU可能出现上电启动不稳定、跑着跑着死机这类莫名其妙的问题，而且这类问题很难排查，往往会被误判为软件Bug。

信号完整性方面，I2C数据线和远程测温线的布线要尽量远离继电器、变压器、电源模块这些干扰源。我在PCB布局时把PJ85718DM放在了板子边缘，靠近传感器接插件的位置，STM32F767BI放在板子中央，I2C走线控制在20mm以内。远程测温的NTC引线从接插件出来就直接进入芯片引脚，中间不要穿过电源区域。

2.3 长线测温的隔离与保护

HVAC现场最常遇到的情况就是传感器和主控板不在同一个位置。风管里的温度传感器可能要拉到距离主控板两三米远，这时候就不能直接拿裸线接了。我的做法是NTC传感器使用屏蔽双绞线连接，屏蔽层在靠近主控板的一端单点接地。双绞线能抑制磁场的共模干扰，屏蔽层能防止静电和电场干扰，两者配合基本能解决长线传输带来的测量噪声问题。

如果被测距离超过5米，我的建议是放弃NTC直连这种模拟长线方案，改用独立的数字温度传感器放在远程测点，通过RS485总线把数据传回主控板。因为NTC的阻值变化是通过模拟电压信号来体现的，线缆电阻会直接串联进分压电路里造成读数偏高，线缆越长误差越大。虽然可以通过软件校准补偿一部分，但线缆电阻随温度变化本身也是不确定的，补偿效果有限。

在实际项目中我还发现一个容易被忽略的问题：远程测温引脚在雷雨天气或者空气干燥时容易积累静电。我在远程通道的输入端加了一颗ESD防护二极管，型号是常见的USBLC6-2SC6，保护电压很低，响应速度快。加了这颗芯片之后，现场出现过几次操作人员直接触碰传感器接插件的情况，设备都扛住了，没有出现传感器通道损坏的问题。

3. 软件驱动设计与数据换算流程

3.1 I2C初始化与寄存器读写逻辑

软件部分的第一步是初始化STM32F767BI的I2C1外设。我用的是ST官方的HAL库，初始化的关键参数如下：时钟速率设为100kHz（标准模式），自身地址随便分配一个不冲突的地址即可，由于F767在这里做主机，自身地址实际上用不到。HAL库的初始化函数配置完就调用MX_I2C1_Init，然后可以通过HAL_I2C_Mem_Read和HAL_I2C_Mem_Write这两个函数直接读写PJ85718DM的寄存器。

PJ85718DM的寄存器映射遵循常见的温度传感器逻辑，有两个关键寄存器分别存放本地温度的原始值和远程温度的原始值。每次读取时先发器件地址加寄存器地址，然后连续读取两个字节，得到完整的16位原始数据。这里有个经验：I2C读取操作别放在主循环里直接调用HAL库函数，因为HAL的阻塞式读写会占住CPU等待总线时序完成。在100kHz速率下，读一次温度需要的时间大概在几百微秒级别，虽然不算长，但如果主循环里还有其他任务，频繁阻塞会影响系统响应。

我后面的做法是启用定时器触发的软件定时中断，每100ms在中断里做一次I2C读取操作。如果担心中断里做I2C通信会影响其他高优先级中断，也可以做一个简单的状态机：主循环不断轮询一个时间标志，时间到了就执行一次I2C读取，读取完更新温度结构体。两种方式我都测试过，稳定性差别不大，看个人代码风格偏好。

3.2 本地与远程温度的换算与滤波算法

拿到16位原始值之后，需要根据PJ85718DM的分辨率和温度计算公式转换成实际温度值。一般来说，这类数字温度传感器的转换公式是“温度 = 原始值乘以某个比例因子”，具体系数参考芯片数据手册。以常见的0.0625℃分辨率来算，16位温度值的高字节是整数部分，低字节是小数部分，直接把原始值右移4位得到有符号整数温度，低4位按6.25%、12.5%、25%、50%的比例加起来就是小数部分。这个换算过程非常像二进制定点小数的处理，熟悉之后可以写成一行代码搞定。

原始温度数据直接使用时往往会有轻微波动，尤其是在HVAC环境里，风机启动、压缩机启停都会造成测温点附近的气流扰动，导致读数上下跳动。我在软件里加了一级简单的递推平均滤波，维护一个长度为10的环形缓冲区，每采到一次新值就覆盖最旧的值，然后输出缓冲区平均值。这种滤波方式的优点是响应快，滞后小，对随机噪声的抑制效果也不错。如果现场温度变化非常缓慢，想要更平滑的曲线，可以把缓冲区长度加到20或者30，但要注意响应时间也会相应变长，风机盘管的温度控制会变得迟钝。

实际测试下来，10点滑动平均后的温度曲线已经很平滑了，同时温度的动态响应时间大概在1秒左右，HVAC控制完全够用。对于那些需要更平滑曲线的场景，我建议在应用层再套一层一阶低通滤波，也就是常见的“新值 = 旧值 α + 新值 (1-α)”的形式，α取0.8左右。

3.3 数据上报与本地交互策略

本地的数据显示我用的是一块简单的点阵LCD屏幕，通过F767的FSMC接口直接驱动，刷新速度比GPIO模拟快得多。屏幕上主要显示三块内容：当前本地温度、当前远程温度、设备工作状态。工作状态包括“正常”“告警”“通信故障”三种，通过温度越限判断和通信超时判断自动切换。

远程上报我用的是RS485总线加Modbus RTU协议。STM32F767BI的UART外设接了一颗RS485收发芯片（实际用的是常见的SP3485），F767在发送数据之前先把收发器的DE引脚拉高，发送完成之后拉低，切换回接收模式。Modbus RTU的报文按标准格式组帧，温度数据映射到保持寄存器里，每个温度值占两个寄存器（32位浮点数），上位机通过Modbus读保持寄存器的功能码就能拿到温度数据。F767作为从机，响应上位机的查询请求。

这块有一点需要提醒：RS485总线在HVAC现场经常和变频器的动力线走同一个线槽，共模干扰比较大。我在RS485收发器的A、B输出端各加了一颗10Ω的匹配电阻，总线两端也各接了一个120Ω终端电阻。实际在现场调试中，A、B线对地各接了一颗TVS管，这样即使变频器启动瞬间的浪涌窜到总线上，也能被TVS吸收掉大部分能量。加了这个保护之后，我的Modbus通信几乎没有再出现过误码和丢包。

4. 系统标定、部署调试与现场实测

4.1 温度校准的具体操作流程

PJ85718DM这类数字温度传感器出厂时内部已经做了校准，理论上不需要额外的软件修正。但实际项目中，不同批次的芯片可能存在±0.5℃左右的个体偏差，再加上PCB布局、机箱热阻、传感器探头工艺等因素，整机做一次标定还是很有必要的。我的标定流程分三步：恒温槽标定、上位机比对修正、在线补偿。

恒温槽标定使用的是常见的液体恒温槽，温度点分别设定在0℃、25℃、50℃、75℃，每个点稳定15分钟之后记录PJ85718DM输出的温度值和标准温度计读数。把这些数据对做一条拟合曲线之后，把偏差值做成一个三段的折线校准表，存进STM32F767BI的Flash里。运行时MCU根据当前温度值查表做线性插值，得到修正后的最终温度值。这个方法比单纯的一阶线性修正更贴合真实温度传感器的响应曲线，因为大多数温度传感器的非线性误差都是分段变化的，三点或四点的折线修正能把大部分误差压掉。

实际操作时我发现，标定时最容易忽略的是“热平衡时间”。放进恒温槽之后不要急着读数据，温度传感器本身是有热容量的，它和槽内液体之间也需要时间达到热平衡。我一般等传感器读数在15分钟内稳定不再漂移之后，才开始记录数据。如果急着采数，前面几组标定点基本都是偏的，整个拟合曲线的精度都会被拉低。

4.2 HVAC现场的部署位置与热干扰规避

在HVAC项目里，温度传感器装在哪里，直接决定了系统测出来的温度有没有意义。我把这套设备用在一个模拟的风机盘管控制器场景里，本地温度传感器安装在控制器外壳内部，用来监测控制板附近的空气温度，这个值主要是做设备过温保护用的，防止控制板在密闭配电箱里散热不良导致故障。远程温度的NTC探头安装在风机盘管的回风管道里，用来测回风温度，这个值是做温控逻辑的主反馈量。

这里有一个常见的安装误区：很多人把回风温度探头直接贴在管道金属壁上。实际上金属管壁的温度和空气温度是有差别的，夏天管壁上有冷凝水，温度比空气低不少，直接贴上去测出来的值偏低，空调压缩机就会多运转很长时间，白白耗电。正确做法是让探头悬在管道中心，用支架固定，保证探头周围的气流能正常流过，这样测到的才是真正的回风温度。我一开始也踩过这个坑，后来把探头移位之后，同样工况下温度读数差了将近2℃，整个温控逻辑的表现立刻正常了。

另一个要注意的是探头线缆的穿线密封。HVAC管道里气流压力会变化，如果穿线孔不密封，管道内的温度和湿度会通过缝隙渗到控制箱里，造成设备结露。我在穿线孔处加了一个带硅胶密封圈的格兰头，既固定了线缆又防止了漏风，设备运行一个夏季下来，控制板内部没有出现明显的结露痕迹。

4.3 实测数据与稳定性结果

设备在模拟现场连续运行了大概两周，我记录了几组典型环境下的数据表现。白天环境温度28℃至32℃之间波动时，本地温度读数稳定在设备内部实际温度的±0.3℃以内，远程回风温度和水银温度计的比对差值在±0.5℃以内。夜晚环境温度降到22℃左右时，温度曲线依然平滑，没有出现回差跳变或者数据毛刺。

远程通信的稳定性方面，RS485总线挂载了三台设备做从机，轮询周期1秒。连续跑了一个礼拜，上位机收到的数据包没有出现丢包，也没有响应超时的情况。在风机盘管变频器启动和刹车的瞬间，用示波器看RS485总线上的波形，A、B线之间的差分信号幅度稳定在1.5V以上，没有出现明显的振铃和过冲。这证明了之前的电路保护和布线措施起到作用了。

温度告警功能我也做了测试：把远程温度阈值设在35℃，用热风枪吹探头附近空气，温度升到35.2℃时，主控板上的告警继电器按时吸合，同时屏幕上显示“告警”状态；撤掉热风枪后，温度降到34.6℃（回差1℃）时，告警继电器释放。回差的意义在于防止温度在临界点附近反复抖动导致继电器频繁动作，这个细节在温控产品里非常重要。

5. 实操中的常见问题与排查速查表

5.1 I2C总线读取失败或数据全为0

这个现象我在项目调试初期遇到过，最终定位到两个原因。第一个是I2C上拉电阻忘记焊接，SCL和SDA引脚处于高阻态，通信完全建立不起来。第二个是PJ85718DM的地址引脚配置和代码不一致，导致主机在发送器件地址时从机不应答。

排查顺序建议这样来：先用万用表测SCL和SDA的对地电压，正常情况应该在3.3V附近。如果电压为0，说明上拉电阻虚焊或者漏焊。再用逻辑分析仪抓I2C时序，看主机发出的地址字节是否和从机实际地址一致。如果逻辑分析仪上能看到ACK信号，说明通信已经建立，问题多半出在寄存器地址或者数据转换上。

5.2 远程温度读数明显偏高或偏低

读数偏高通常是线缆电阻引起的。NTC通过长线连接时，线缆的电阻会叠加到传感器支路上，导致分压点电压变化，表现为温度偏高。解决方法是改用屏蔽双绞线降低线阻，或者通过软件做线阻补偿。如果读数固定偏了某个值，可以先用万用表测一下线缆实际电阻，然后在换算公式里把这个阻值扣掉。

读数偏低则往往和传感器探头的安装位置有关。探头如果被安装在风管弯头的涡流区，气流流通不畅，测出来的温度会跟回风温度有偏差。还有可能就是探头外壳有导热硅脂或者污物包裹，导致传热路径变化，测温变慢。

5.3 温度曲线频繁跳变

跳变问题通常是电磁干扰造成的。如果跳变值在0.5℃以上且伴随明显的随机性，先看电源纹波，再看数据线布线。我在现场遇到过一次温度值每隔几秒跳一下的情况，排查到最后发现是继电器线圈的续流二极管没焊，继电器断开瞬间产生了高压反峰，干扰到了I2C总线和远程测温通道。把续流二极管补上之后，温度曲线立刻稳定了。

5.4 常见问题速查表

这个表格我在项目维护时打印出来贴在实验室墙上，排查问题的时候先对号入座，能省掉很多逐个排查的时间。

结语：一些个人经验

这套PJ85718DM加STM32F767BI的温度监测系统做完之后，给我留下最深的印象是：硬件设计决定了温度采集的下限，软件设计决定了温度系统的上限。电源滤波、屏蔽接地、ESD保护这些硬件功夫不到位，软件写再多滤波也救不回来；反过来，硬件做得再扎实，没有合理的滤波算法、校准表和回差控制逻辑，最终用户体验也一样糟糕。我建议打算复刻这套方案的朋友，画板子的时候就把传感器接口的滤波和保护做完整，写代码的时候踏踏实实把校准和滤波做好，哪怕前期多花点时间，后面调试和量产阶段都能省心很多。最后再分享一个小技巧：远程测温探头在线缆入口处打一小段热缩管，既能固定线缆防止拉扯，又能避免金属格兰头直接压伤线皮，这个小细节能让现场故障率明显下降。