做嵌入式温度监测这些年最烦的就是“测不准”和“传不远”这两个问题。尤其是在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收发芯片实际用的是常见的SP3485F767在发送数据之前先把收发器的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 常见问题速查表故障现象可能原因排查方法解决方案I2C通信完全失败上拉电阻缺失测量SCL/SDA电压补焊4.7kΩ上拉电阻I2C通信时好时坏总线过长或电容过大检查总线长度和负载降低总线速率或增加上拉强度本地温度偏低芯片附近有强热源查看PCB发热器件布局调整布局或加隔热垫远程温度偏高线缆电阻过大测量线缆阻值改用双绞屏蔽线温度读数跳变电源纹波或干扰示波器测供电波形加强RC滤波和屏蔽接地温度响应太慢滑动滤波点数过多检查滤波参数减少滤波点数或改用一阶低通告警频繁动作缺少回差值检查越限判断逻辑加入回差控制逻辑RS485通信丢包缺少终端电阻或保护检查A/B总线波形加120Ω终端电阻和TVS管这个表格我在项目维护时打印出来贴在实验室墙上排查问题的时候先对号入座能省掉很多逐个排查的时间。结语一些个人经验这套PJ85718DM加STM32F767BI的温度监测系统做完之后给我留下最深的印象是硬件设计决定了温度采集的下限软件设计决定了温度系统的上限。电源滤波、屏蔽接地、ESD保护这些硬件功夫不到位软件写再多滤波也救不回来反过来硬件做得再扎实没有合理的滤波算法、校准表和回差控制逻辑最终用户体验也一样糟糕。我建议打算复刻这套方案的朋友画板子的时候就把传感器接口的滤波和保护做完整写代码的时候踏踏实实把校准和滤波做好哪怕前期多花点时间后面调试和量产阶段都能省心很多。最后再分享一个小技巧远程测温探头在线缆入口处打一小段热缩管既能固定线缆防止拉扯又能避免金属格兰头直接压伤线皮这个小细节能让现场故障率明显下降。