1. 需求分析与系统方案选型先说清楚我在做这个项目时遇到的真实场景。HVAC暖通空调控制器需要同时监测两个位置的温度一个是控制板上芯片附近的温度用来判断控制板自身是否过热另一个是冷媒管路或者风道里几米开外位置的温度用来参与温控策略。如果只把传感器贴近MCU板子管路温度测不准因为距离实在拉得太远如果只用外置探头控制板上又没有位置塞下额外的一整套传感器电路和走线。PJ85718DM这种同时支持本地测温通道和远程测温通道的数字温度监测芯片就是为这类“既要测自身、又要测远处”的场景设计的。STM32G491RE是我选的主控。这颗MCU在STM32G4系列里属于均衡型选手ARM Cortex-M4F内核主频最高170MHz板载512KB Flash和96KB SRAM。我选它不是因为算力多强而是因为这个项目最终要在同一颗主控上跑HVAC的PID控制算法、风机调速逻辑和Modbus通信这些功能叠加起来对实时性有要求但又不至于需要上Linux级别的主控。测温只是整个系统的一个功能模块而不是全部任务所以在性能上不能选太弱的芯片去“吊车尾”。温度监测方案的核心权衡在于本地温度很好测几乎所有温度传感器都能做到远程温度才是难点。远程测温在行业里有三种常见思路我逐个对比过使用I2C/SPI接口的温湿度传感器模块通过延长数字信号线放到远处。问题是I2C和SPI对线长和信号完整性很敏感超过几十厘米就容易出时序问题。使用热敏电阻或者PT100配合调理电路再做ADC采集。这种方案成本低、也成熟但需要额外做漂移补偿而且不同批次的传感器一致性一般标定工作量不小。使用具备“远程PN结测温”功能的专用芯片也就是PJ85718DM这一类器件。它用一个外部二极管比如三极管接成二极管形式作为感温元件只用两根普通线就能拉出去几十厘米甚至更远数字信号通过I2C总线回传精度和抗干扰都有保障。我最终选了第三种也就是PJ85718DM配STM32G491RE的组合。这篇分享就把当时的整个软硬件设计和实测结果都展开聊一聊包括原理、寄存器配置、代码结构、以及折腾过的一堆坑。如果你也在做类似的多点温度采集这篇文章应该能帮你少走不少弯路。1.1 温度监测场景细化开始画原理图之前我先把温度监测需求拆成了几个具体子项。没有这一步后面芯片选型、电路设计都会变成拍脑袋。本地温度在这个项目里有三个具体用途监控MCU控制板的元器件工作温度。控制板装在现场配电柜里柜内环境可能升到60℃以上电容和芯片的寿命都跟工作温度强相关。作为HVAC系统控制回路的参考值。变频空调项目里控制板温度过高时需要主动降频保护不能等器件烧了才动作。用于校准和补偿。某些测量通道的温漂可以通过板温做软件补偿本地温度数据正好可以做基准。远程温度在本项目里则对应三个测量点冷媒管路表面温度。这个温度直接参与制冷/制热逻辑的判定不允许偏差太大。回风口温度。放在风道内部距离主板大约30厘米用于判断实际环境温度。关键的功率器件壳温比如IGBT或功率模块的散热器温度位置在强电区域离控制芯片超过20厘米。这几种远端测温点的共同特点是距离不极端在0.2米到1米之间传感器安装位置不允许放一块PCB测温小板再引I2C因为空间局促必须适应现场环境包括冷凝水、震动和一定程度的电磁干扰。PJ85718DM这种用二线制PN结测量的方案在这种场景下施工和维护都很方便远程传感器本身就是一个廉价的三极管坏了直接换掉成本极低。1.2 器件选型逻辑说说为什么最后选了这两颗器件。PJ85718DM——我记得当时看过的同类芯片有各种选择比如经典的ADT7481、EMC1412等。PJ85718DM的定位也是一样的一颗内置本地测温通道、并且带一个远程测温通道的数字温度传感器IC。接口走I2C/SMBus供电电压3.0V到3.6V都可以测温结果通过寄存器直接读取不用自己做模拟调理。我选这颗器件主要基于三点第一它支持SMBus报警协议也就是ALERT引脚。过温报警可以不依赖MCU轮询而是由传感器芯片自己判断阈值然后把ALERT脚拉低触发MCU中断。这就能让主控在低压检测保护这类任务上少费心思报警响应也更快。第二它的远程测温通道支持外部三极管作为感温头而且对外部三极管型号不挑常见的小信号NPN三极管比如S8050、2N3904都能用只要把基极和集电极短接在发射极和基极之间量电压即可。这就比某些只能用特定型号二极管的芯片在采购上灵活得多。第三芯片内置了温度偏置和失调补偿寄存器。远程测温的物理原理是测量PN结压差这导致它天然会受线阻、焊接电阻和远端器件的工艺差异影响。厂家在芯片里给了几个可编程寄存器让我可以在软件里做校准不用改硬件。这点在批量生产中也是实用价值极高的因为换一批三极管或者改变线缆长度时只需要更新校准参数。再说STM32G491RE。这颗主控在这个项目里承担的不只是读温度还包括完整的HVAC主逻辑。它有什么优势可以重点说带FPU的Cortex-M4F内核跑PID和滤波算法很顺。温度数据虽然简单但HVAC整体工况切换、压缩机变频控制、多路风机协调这些都要在同一个主控上跑算力余量是必须留出来的。STM32G4系列的ADC是有硬件过采样功能的可以在不打扰CPU的情况下做多次采样累加。虽然测温数据走I2C数字接口但后续如果还要扩展NTC接口或者采集电流电压ADC的能力会直接影响系统复杂度。丰富的I2C接口以及硬件I2C对SMBus超时处理的支持。很多人知道I2C有两个引脚但在SMBus协议里当总线被拉死时需要超时复位机制。STM32的I2C外设支持时序超时检测这让系统在异常时更不容易死锁。对比过STM32F1系列和STM32G0系列F1便宜但算力相对弱G0性价比高但外设没那么全G4处于一个更合适的位置有能力做主控而不只是做测温的“陪衬”。一个实际体感是如果只是测温STM32G030都绰绰有余但你要把一套完整的HVAC控制逻辑塞进去G4这个级别用起来才从容。2. 硬件电路设计决定器件型号之后硬件设计就要落到电路图上了。这一块看着简单实际踩坑的地方全在细节里。2.1 芯片电源与引脚外围电路PJ85718DM的VDD引脚需要3.3V供电。虽然芯片内部有电源管理但供电质量直接决定远程测温精度尤其是远程PN结的电压测量是微伏级别的信号电源上的一点点毛刺都可能在温度数据里体现出来。我当时的做法是给VDD脚用一颗1μF陶瓷电容和一颗0.1μF陶瓷电容并联去耦两颗电容尽量靠近电源引脚。硬件设计里这个组合是“标配”但很多人会在布局时忽略放置距离导致高频噪声根本没被滤掉。芯片的I2C地址引脚用于设置总线地址。PJ85718DM把地址引脚的高低电平组合映射到不同地址典型情况下允许在一个I2C总线上挂多颗芯片。不过我觉得一颗这样的芯片就够了因为它本身支持一路本地测温加一路远程测温大多数HVAC项目的传感器点位需求也就这么两路没有必须扩展。ALERT引脚值得单独说。这个脚是开漏输出正常工作时是高阻态触发报警时拉低。因此外部必须接上拉电阻。我用了10kΩ的上拉电阻接到3.3V。在实际测试中有一个容易被忽略的坑ALERT引脚在芯片上电初期会保持在一个不确定的电平状态如果这个脚接到MCU的外部中断引脚并且MCU配置的是上升沿/下降沿触发就会在系统启动阶段产生一个误中断。我的解决方案是MCU端先配置成普通输入等系统初始化完成并确认ALERT脚电平稳定后再使能外部中断。还有个容易忽略的引脚是THERM或者叫过热输出不同芯片命名不一样。PJ85718DM留了这个功能引脚它和ALERT不同作用更像一个硬件急停当温度超过最高阈值时直接触发不需要MCU干预。在HVAC的过温保护设计里我用它来直接关断压缩机的驱动信号使能而不是等软件慢慢处理。因为从接到报警到主控做出反应总有一小段延迟硬件直接锁断驱动会更安全。2.2 与STM32G491RE的I2C接口连接STM32G491RE的I2C接口和PJ85718DM的连接理论上就是两根线SCL和SDA再加上一个ALERT中断线。I2C是开漏协议所以SCL和SDA都必须接上拉电阻。上拉电阻的阻值选择不是随便定的需要根据总线电容和通信速率计算。这个项目里I2C速率定在100kHz标准模式走线长度不长40厘米以内。总线上挂了两颗设备一颗是PJ85718DM另一颗是EEPROM用于掉电保存参数。总线电容估下来约80pF到150pF上拉电阻取4.7kΩ。这个组合实测波形上升沿干净,Z没有过冲也不存在边沿偏缓的问题。如果有些人想把通信频率提上去比如跑到400kHz上拉电阻就要降低到2.2kΩ甚至更低。这个调整的原因也很直接上拉电阻和总线寄生电容构成RC电路阻值越大边沿越缓太快就达不到协议要求的上升时间。我们不用高频因为PJ85718DM这类芯片本身也不是高速器件更高的速率对HVAC场景没有实际好处反而可能带来EMC风险所以就让它工作在100kHz,稳扎稳打。STM32端I2C外设配置为主模式。需要注意SCL和SDA引脚要选择一个支持开漏模式的推挽配置。很多初学者会直接把GPIO配置成推挽输出然后去操作I2C这样虽然也能通信但一旦有外部设备强拉总线就会出问题甚至可能损坏引脚。正确做法是把GPIO配置为开漏输出模式配合外部上拉电阻工作这跟I2C协议要求的线与逻辑一致。还有一个电平匹配问题。PJ85718DM的I2C电平是跟VDD走的如果VDD是3.3V那么它的高电平输出也是3.3V跟STM32G491RE的IO电平兼容。要注意的是有些旧款温度芯片的I2C引脚不是标准IO内部会用到5V容忍结构。PJ85718DM我没记错的话是没有问题的但如果你用别的型号一定要去看数据手册里I2C引脚是否支持“5V tolerant”不然引脚电平可能拉不上来。2.3 PCB布局与强电抗干扰设计HVAC设备的控制板上往往既有弱电控制部分又有强电驱动部分板上干扰源很多比如变频器的PWM开关节点、继电器线圈、压缩机驱动线等。温度监测电路本身不复杂但走线布局如果随随便便远程测温精度会一塌糊涂。远程测温的两根线最关键。PJ85718DM的远程测温通道本质上是一个高精度的电压差分测量电路外部PN结通过两根线接入芯片。如果这两根线靠近PWM输出线或继电器线耦合过来的噪声会叠加在被测信号上温度读数就会跳。我在布局时的做法是远程测温线尽量短从芯片引脚出来后就往传感器接口方向走不要绕大圈。远程测温线之间采用差分走线保持平行且尽量接近让外部干扰同时叠加在两根线上利用芯片的差模抑制能力抵消。如果两根线的间距太大共模干扰就会转化为差模干扰没法被消除。在远程测温接口附近加一个100pF到1nF的电容跨接在两根线之间滤除射频干扰。这个电容的取值需要谨慎后面我会单独展开讲因为它跟测温精度之间有矛盾。电源走线也应该和强电区域隔离。PJ85718DM的VDD可以由MCU板上的3.3V直接供电但尽量让电源走线不穿越强电区域否则电源纹波会污染测温结果。如果实在没法避开可以用磁珠隔一下再配合去耦电容。还有一个值得注意的点是远程三极管的安装位置。在冷媒管或回风口这些位置安装传感器时传感器本身可以用扎带固定在管壁上但一定不要让线材的金属屏蔽层直接接触带电部分。HVAC设备现场环境复杂有的客户安装人员不一定规范设计上最好在传感器接口处加TVS保护或者限流电阻以防万一。我在接口处串了一个100Ω电阻这个电阻同时也能帮助抑制振铃。3. 软件架构与驱动实现硬件搭起来之后真正决定系统好不好用的就是软件了。这个测温模块的软件我分了三个层次底层I2C驱动、PJ85718DM芯片驱动、上层应用逻辑。这种分层方式在工程上最省心因为以后如果换芯片只需要替换中间层上层逻辑几乎不用动。3.1 I2C通信基础与寄存器地图先建立一点基础认知。I2C总线上的通信是主从模式STM32G491RE作为主机发起通信PJ85718DM作为从机响应。通信过程大体是主机发出START信号然后发送从机地址加读写位从机收到匹配的地址后回ACK然后主机和从机通过数据字节交换信息最终以STOP信号结束。PJ85718DM这类芯片的寄存器访问方式通常是主机先发送要读的寄存器地址然后重启I2C总线或者直接重发START再发送设备地址加读位接着读取数据。具体到这片芯片它的寄存器地址空间不大算下来也就十几个寄存器其中最关键的有配置寄存器控制测温模式比如连续转换还是单次转换、报警模式等。本地温度寄存器存放最近一次本地温度转换结果。远程温度寄存器存放远程通道的温度结果。本地/远程高温报警阈值寄存器当实测值超过这个值就触发报警。失调补偿寄存器用于调整远程通道的温度测量偏移。我建议的做法是拿到芯片后第一步先读一遍所有寄存器的复位值。很多人直接按数据手册里的默认值写配置但在不同的上电时序或外部环境条件下实际默认值可能会跟手册描述有细微差异。先把复位值读出来能建立芯片当前状态的基线后面再排查问题会容易很多。3.2 初始化与温度读取代码结构驱动代码我习惯先做两个底层函数I2C写寄存器和I2C读寄存器。这两个函数不涉及具体芯片逻辑是纯粹的通信协议封装方便在STM32的HAL库之上再做一层薄薄的抽象。uint8_t temp_write_reg(uint8_t dev_addr, uint8_t reg_addr, uint8_t data) { return HAL_I2C_Mem_Write(hi2c1, dev_addr 1, reg_addr, I2C_MEMADD_SIZE_8BIT, data, 1, 100); } uint8_t temp_read_reg(uint8_t dev_addr, uint8_t reg_addr, uint8_t *data) { return HAL_I2C_Mem_Read(hi2c1, dev_addr 1, reg_addr, I2C_MEMADD_SIZE_8BIT, data, 1, 100); }底层通信确保没问题之后第一步是芯片初始化。初始化要做的操作是清空报警状态、设置转换模式、设置温度数据分辨率、配置报警阈值、以及使能远程通道的外部器件连接检测。void pj85718dm_init(void) { uint8_t val; // 设置连续转换模式使用0.0625°C分辨率 val PJ85718DM_CONV_CONTINUOUS | PJ85718DM_RES_12BIT; temp_write_reg(PJ85718DM_ADDR, PJ85718DM_REG_CONFIG, val); // 设置远程通道高温报警阈值为80°C temp_write_reg(PJ85718DM_ADDR, PJ85718DM_REG_REMOTE_HIGH_H, (uint8_t)((80 * 256) / 128)); temp_write_reg(PJ85718DM_ADDR, PJ85718DM_REG_REMOTE_HIGH_L, 0); // 使能远程二极管断线检测 val temp_read_reg(PJ85718DM_ADDR, PJ85718DM_REG_CONFIG); val | PJ85718DM_DIODE_FAULT; temp_write_reg(PJ85718DM_ADDR, PJ85718DM_REG_CONFIG, val); }在读取温度时我先读状态寄存器确认转换完成标志置位然后才读取本地温度和远程温度的寄存器。这一步骤不能省因为如果在转换过程中读到的是中间值可能会得到不稳定的数据。温度寄存器是高字节和低字节两个组合时需要做符号扩展处理。低温时寄存器里的数值是负数编码如果直接按无符号数拼起来就会出错。float pj85718dm_read_local_temp(void) { uint8_t high, low; int16_t raw; temp_read_reg(PJ85718DM_ADDR, PJ85718DM_REG_LOCAL_HIGH, high); temp_read_reg(PJ85718DM_ADDR, PJ85718DM_REG_LOCAL_LOW, low); raw (int16_t)((high 8) | low); // 右移处理符号位保留12位有效数据 raw 4; return raw * 0.0625f; }这里有个经验型细节温度寄存器的高低字节组合不同芯片的位定义略微有差异有的是12位数据有的是更细的13位甚至16位。PJ85718DM支持12位精度数据手册里写的LSB是0.0625℃。我出于省事把所有温度值都用float类型来存储在主控算力充足的前提下浮点数直接参与后续计算比较顺手也避免定点数缩放到最后把自己绕晕。3.3 数据处理与滤波策略硬件传感器读取的原始温度数据不能直接使用尤其是远程测温通道它很容易受到各种干扰和电气噪声的影响。我在项目里做了一层软件滤波策略有三板斧第一板斧是滑动平均滤波。连续取8个温度值每次读取新值时丢弃最老的一个用这8个值的平均值作为输出。这个滤波器对周期性噪声和随机毛刺都有不错的抑制效果而且实现简单几乎不占资源。第二板斧是限幅滤波。设定一个最大允许变化率比如1℃/s如果两次采样之间的温度变化超过了这个值就认为是异常跳变直接用上一次的有效值替代。这个策略在工业现场很实用因为温度变化本身是慢变量突然跳变大概率是干扰或者接插件接触不良。第三板斧是断线检测。PJ85718DM内置的远程二极管断线检测功能会判断远程传感器是否存在如果检测到断线寄存器里会置一个标志位。我在读取温度后都会检查这个标志如果断线告警置位就把温度值置为一个显式的无效值而不去参与控制逻辑。这三个策略组合下来实际效果相当稳。之前有一次现场调试时压缩机启动的瞬间本地温度显示出现了约1.5℃的跳变加了限幅滤波后这个跳变直接被挡住显示和上报的温度始终平滑。这种感受非常直观软件滤波不是可有可无的锦上添花而是工程落地必备的环节。4. 远程测温实现细节与误差控制远程测温是这颗芯片最核心的价值点但也是整个项目里最容易出错的地方。这一节单独展开说。4.1 远程PN结测温原理PJ85718DM的远程测温原理简单说就是利用半导体PN结的电压和温度的确定关系来推算温度。外部三极管的基极和集电极短接后接在芯片的远程测温引脚上芯片内部给这个PN结施加不同大小的偏置电流测量两次电流下的VBE电压差再通过公式推算温度。原理上有个很关键的点PN结的VBE电压绝对值本身受工艺影响比较大不同批次的三极管同一温度下VBE可能差几十毫伏但ΔVBE不同电流下的电压差与温度的关系曲线相对稳定受工艺影响很小。因此芯片使用ΔVBE而不是直接测VBE绝对值这样可以把器件个体差异的影响降到最低这也是这个方案能保持较高精度的原因。为什么选择三极管而不是普通二极管我实际用下来的理解是三极管短接基极-集电极后在VBE在0.4V到0.8V范围内集电极-发射极漏电流产生的误差更小响应也更接近理想PN结模型。有些芯片数据手册会特定推荐使用2N3904原因就是它的β值足够高等效串联电阻较小。当然这个技术也有它的脆弱面。远程PN结上的电压信号是毫伏级别的而且芯片要分辨的是不同电流下微小电压差异因此外部引线上的任何电阻都会引入误差。引线电阻上流过电流会产生压降这个压降直接叠加在被测的VBE上导致芯片误以为PN结温度更高。线阻越大温度读数偏高的幅度越大。4.2 硬件误差来源与补偿方法远程测温的误差主要来自三个方面。第一个是线阻误差。典型值估算下来引线电阻每增加1Ω远程测温读数大约会产生0.5℃到1℃的偏差。如果传感器引出线很长比如超过半米铜线的电阻已经有0.02Ω/m量级两根线合计下来还是有零点几欧的电阻也就是零点几度的误差。处理线阻误差有两种做法一种是在电路设计上做四线制测量额外引两根线给芯片做补偿适合远距离高精度场景另一种是软件补偿也就是在失调寄存器里写一个偏移值。我采用的是后者因为项目里的传感器线不长精度要求也不苛刻。先在常温下用标准温度计校准一次把偏差记录进EEPROM下次上电时自动加载补偿值。第二个是滤波电容带来的误差。远程测温引脚在PCB上加小电容是抑制高频干扰的常规手段但电容过大时会影响芯片在切换偏置电流时的建立时间导致ΔVBE测量不准确。数据手册里对典型推荐值的描述不一定根据你的电路做过验证。我的经验是先不加电容看看原始温度数据的噪声水平如果噪声可以接受就不加如果噪声偏大从100pF开始尝试逐步加大到1nF直到噪声降下来且温度读数没有明显偏移为止。第三个是共模干扰导致的读数波动。远程传感器安装位置靠近强电或马达时两根引线上会感应出共模干扰信号。芯片对共模信号有一定的抑制能力但这个抑制能力受到引线不平衡度的影响。如果两根引线完全等长等距干扰就是纯共模信号抑制效果很好。如果不是干扰进来就可能变成差模信号导致温度读数抖动。我实测遇到的一个典型现象是远程读数在压缩机启动瞬间会跳高几度而停机会跳低几度且抖动的方向和幅度比本地温度明显更剧烈。排查后发现远程传感器安装位置正好穿过了一块大电流走线的上方干扰耦合严重。处理方法是调整走线路径把远程传感器的引线绕开那个区域并把跨接电容加到470pF问题就明显缓解了。4.3 软件校准与多点标定方法说来惭愧第一版我直接把远程温度读数拿去跟水银温度计比偏差有2℃左右。分析下来发现主要不是芯片的问题而是传感器的安装方式和线阻导致的系统性偏差。于是我做了一套简单的软件校准流程分享出来供参考。第一步是单点偏移校准。把远程传感器和标准温度计放在同一个恒温环境下比如室温25℃读取芯片的远程温度值记下偏差量ΔT_offset然后把补偿值写入失调补偿寄存器。这个操作能修正掉大部分系统误差。说实话这种级别的校准能应付很多需求了。第二步是两点校准。在HVAC项目里我们关心的温度范围比较宽从0℃到60℃。单点校准只保证在校准点附近准离远了误差还是可能拉大。我选择两个校准点比如10℃和50℃各记录一次偏差然后做线性插值得到两个温度区间的不同补偿系数。这样做之后整个工作区间的最大误差从初始的2℃压缩到了标定后的0.3℃以内。第三步是批量生产时通过测试夹具写入校准参数。在生产阶段直接在产品主控里跑一套自动校准程序给传感器施加已知温度程序自动读取测量值计算偏移量后把参数写进EEPROM。这样每条产线出来的设备都带自己的校准参数既保证了批量一致性也不增加太多工时。软件校准的前提是硬件本身就稳定不能指望校准去弥补恶劣的硬件设计。如果偏差是随机的、跳变的那就是干扰问题或者接触问题单纯靠校准根本救不回来。5. 系统联调与HVAC场景部署驱动写好、硬件调通之后剩下的事情是把温度监测功能嵌进整个HVAC系统里跑起来。这一环节我们做了不少联调也暴露了很多单测时看不到的问题。5.1 报警联动与过温保护逻辑在HVAC系统里温度监测的意义不是“显示一个数字”而是参与控制和保护。这个项目里温度数据对接了三层逻辑。第一层是常规监控。温度每500ms刷新一次显示在本地LCD上同时通过Modbus寄存器对外提供读取。这层逻辑最简单纯读数据不参与控制。我在ROM里做了一个超时计数器超过5秒读取失败就显示“--”代表传感器故障不显示错误的数字。第二层是过温保护。本地的PJ85718DM高温报警阈值设置为85℃远程通道设置为70℃。当温度超过阈值时ALERT引脚拉低触发STM32G491RE的外部中断主控进入保护流程记录故障时间、关闭压缩机输出、在屏幕上显示故障代码。这套逻辑最大价值在于不需要主控软件去轮询温度硬件引脚本身就完成了“看门狗”的功能。第三层是降频策略。在温度超过第一阈值但还没有到报警阈值时比如本地温度超过75℃但未到85℃控制器会对压缩机的最大运行频率做限制。这层逻辑不做硬开关只调整运行参数保证系统在高温环境下还能继续运行但性能受限保护了器件又不会让系统直接停机。这个“软降额”策略在HVAC现场接受度很高因为客户更希望设备能持续运行而不是频繁告警。在设计报警阈值时还有个小细节需要给报警和恢复设置滞回区间。比如高温报警阈值是85℃恢复阈值设为75℃否则温度在84℃到86℃之间波动时系统会反复进入保护和退出保护导致压缩机频繁启停。我在配置寄存器里设置了报警阈值和恢复阈值两个不同值这个思路来自工程经验而不是数据手册的强制要求。5.2 远程数据上报方式嵌入式应用里的“远程”有两种理解一种是远程传感器物理位置上距离主控远另一种是远程数据上报通过网络把温度数据送出去。这个项目两个层面都有。PJ85718DM的远程通道解决的是第一个层面的问题直接把传感器拉远。而数据上报层面我用了Modbus RTU协议通过RS485发出去。RS485的接入也很常规STM32G491RE的UART外设接一个RS485收发芯片比如MAX3485这类半双工模式由GPIO控制收发方向。Modbus RTU协议里挂的是几个保持寄存器地址固定内容包含本地温度、远程温度、报警状态和系统状态标志位。上层调度系统或者楼宇自控主站通过Modbus读这些寄存器就能拿到所有数据。说一个Modbus对接时的坑HVAC现场的RS485总线往往会挂很多设备总线空闲时的偏置电阻设置不当会导致收到乱码或者干扰。我们在布线时给A线和B线之间加了终端电阻并且在主机端配置了偏置电阻来锁定空闲电平。一开始没加偏置电阻实测通信丢包率约在3%到5%加了之后就完全正常。这个经验成本很低但效益很明显值得记一笔。5.3 实测数据与稳定性验证联调完成后我在实验室做了48小时连续运行记录模拟温度波动、切换运行工况以及反复通断电。下面放一组有代表性的实测数据表测试条件本地传感器处于控制板上远程传感器贴在散热器表面环境温度约28℃。时间点本地温度读数℃远程温度读数℃标准温度计℃偏差℃0分钟31.134.234.00.210分钟31.235.635.50.120分钟31.037.837.60.230分钟31.438.938.60.360分钟31.339.839.60.2120分钟31.540.240.00.2从数据看经过校准后远程通道的最大偏差控制在0.3℃以内对于HVAC应用已经完全足够。需要注意这个精度的前提是传感器安装良好、没有接触不良或线缆过长问题。如果现场安装偷懒直接把传感器扔在角落不贴紧被测表面再好的芯片也救不回来。稳定性方面48小时连续运行期间没有出现一次温度数据跳变到离谱值的情况也没有发生I2C总线死锁。我还特意测试了在高压PWM输出切换的瞬间读取温度寄存器结果没有出现抛错或异常数据这主要归功于前面的软件滤波和硬件布局。6. 常见问题排查与实测经验技术项目到了最后踩过的坑和排查思路往往是这pa整体内容里最值钱的部分。把我在这个项目里遇到的问题整理成了速查表并附上排查思路供你直接对照使用。6.1 常见问题速查表现象可能原因排查步骤与解决方案I2C通信失败读不到任何寄存器值上拉电阻缺失或阻值过大地址配置错误SCL/SDA接线反了先用示波器看SCL/SDA波形确认从机地址配置用逻辑分析仪抓取时序确认ACK位是否正常本地温度正常远程温度读数为0或异常值远程传感器未接/接反断线检测误报滤波电容过大用万用表量远程二极管正向压降确认基极-集电极已短接检查电容之后是否读数恢复远程温度读数偏高且稳定引线电阻偏大远程传感器热耦合不良更换更粗更短的引线软件写入负偏移补偿确保传感器贴紧被测表面并涂导热硅脂压缩机启动瞬间温度跳变强电干扰耦合到远程测温线或电源检查走线是否平行贴近大电流路径增加远程测温引脚滤波电容在软件里增加限幅滤波ALERT引脚启动时误触发中断ALERT上电状态不稳定MCU初始化时先配置为普通输入等待200ms稳定后再配置为外部中断在ALERT输出上加上拉电阻I2C总线在长时间运行后死锁SMBus超时机制未处理总线上有设备拉死SDA开启STM32外设的超时检测在软件中增加总线恢复流程检查是否有设备地址冲突导致总线仲裁异常6.2 调试过程中最值得记的几件事如果只看数据手册做题这些坑是不会明摆着告诉你的。先说ALERT引脚的处理。我一开始是直接把ALERT接到MCU中断引脚一上电就收到了中断搞得我还怀疑芯片是不是坏了。后来单独量电平才发现芯片在上电初始化阶段会有一段不稳定的时间。如果你的设计把ALERT接到了硬件使能端或者安全继电器回路这种上电抖动可能会造成设备误动作这一点务必在设计中预留延时或者锁存机制。再说远程传感器的线长问题。虽然芯片理论上可以支持相对长的引线但实际线长在超过50厘米后温度读数的噪声会明显上升。我试过拉2米线读数在某些干扰条件下能跳个好几度。如果你确实需要拉更远有两个方向可以选择选支持特殊线阻补偿功能的芯片或者干脆在远端安装一个小小的I2C测温芯片通过数字信号回传。最后是I2C总线的稳定性。虽然I2C协议很长时间没变过但在嵌入式现场环境中总线死锁的情况一点都不少见。主要原因是SMBus协议里规定的超时机制在普通I2C传输中不会自动启动一旦有设备异常拉低总线整个通信就卡住。STM32G491RE的I2C外设支持硬件超时检测我建议无论目标芯片支不支持SMBus都开启这个功能。哪怕只把它当作一个防止总线的“安全绳”在项目后期节省的调试时间也会让你觉得值。根据我个人多次做类似项目的经验单片机读写温度芯片的代码本身不算难真正影响成败的反而是硬件工程师往往容易忽视的几个“无关紧要”的细节滤波电容取值、引线长度、布局走向和报警引脚的电平逻辑。如果你在调试中发现温度数据表现异常先别急着怀疑芯片或者改写软件拿示波器去量量传感器引线上有没有噪声可能问题一瞬间就能定位。毕竟在HVAC这种电磁环境相对复杂的现场稳定的数据链路往往比漂亮的程序架构更稀缺也更值钱。
1. 需求分析与系统方案选型先说清楚我在做这个项目时遇到的真实场景。HVAC暖通空调控制器需要同时监测两个位置的温度一个是控制板上芯片附近的温度用来判断控制板自身是否过热另一个是冷媒管路或者风道里几米开外位置的温度用来参与温控策略。如果只把传感器贴近MCU板子管路温度测不准因为距离实在拉得太远如果只用外置探头控制板上又没有位置塞下额外的一整套传感器电路和走线。PJ85718DM这种同时支持本地测温通道和远程测温通道的数字温度监测芯片就是为这类“既要测自身、又要测远处”的场景设计的。STM32G491RE是我选的主控。这颗MCU在STM32G4系列里属于均衡型选手ARM Cortex-M4F内核主频最高170MHz板载512KB Flash和96KB SRAM。我选它不是因为算力多强而是因为这个项目最终要在同一颗主控上跑HVAC的PID控制算法、风机调速逻辑和Modbus通信这些功能叠加起来对实时性有要求但又不至于需要上Linux级别的主控。测温只是整个系统的一个功能模块而不是全部任务所以在性能上不能选太弱的芯片去“吊车尾”。温度监测方案的核心权衡在于本地温度很好测几乎所有温度传感器都能做到远程温度才是难点。远程测温在行业里有三种常见思路我逐个对比过使用I2C/SPI接口的温湿度传感器模块通过延长数字信号线放到远处。问题是I2C和SPI对线长和信号完整性很敏感超过几十厘米就容易出时序问题。使用热敏电阻或者PT100配合调理电路再做ADC采集。这种方案成本低、也成熟但需要额外做漂移补偿而且不同批次的传感器一致性一般标定工作量不小。使用具备“远程PN结测温”功能的专用芯片也就是PJ85718DM这一类器件。它用一个外部二极管比如三极管接成二极管形式作为感温元件只用两根普通线就能拉出去几十厘米甚至更远数字信号通过I2C总线回传精度和抗干扰都有保障。我最终选了第三种也就是PJ85718DM配STM32G491RE的组合。这篇分享就把当时的整个软硬件设计和实测结果都展开聊一聊包括原理、寄存器配置、代码结构、以及折腾过的一堆坑。如果你也在做类似的多点温度采集这篇文章应该能帮你少走不少弯路。1.1 温度监测场景细化开始画原理图之前我先把温度监测需求拆成了几个具体子项。没有这一步后面芯片选型、电路设计都会变成拍脑袋。本地温度在这个项目里有三个具体用途监控MCU控制板的元器件工作温度。控制板装在现场配电柜里柜内环境可能升到60℃以上电容和芯片的寿命都跟工作温度强相关。作为HVAC系统控制回路的参考值。变频空调项目里控制板温度过高时需要主动降频保护不能等器件烧了才动作。用于校准和补偿。某些测量通道的温漂可以通过板温做软件补偿本地温度数据正好可以做基准。远程温度在本项目里则对应三个测量点冷媒管路表面温度。这个温度直接参与制冷/制热逻辑的判定不允许偏差太大。回风口温度。放在风道内部距离主板大约30厘米用于判断实际环境温度。关键的功率器件壳温比如IGBT或功率模块的散热器温度位置在强电区域离控制芯片超过20厘米。这几种远端测温点的共同特点是距离不极端在0.2米到1米之间传感器安装位置不允许放一块PCB测温小板再引I2C因为空间局促必须适应现场环境包括冷凝水、震动和一定程度的电磁干扰。PJ85718DM这种用二线制PN结测量的方案在这种场景下施工和维护都很方便远程传感器本身就是一个廉价的三极管坏了直接换掉成本极低。1.2 器件选型逻辑说说为什么最后选了这两颗器件。PJ85718DM——我记得当时看过的同类芯片有各种选择比如经典的ADT7481、EMC1412等。PJ85718DM的定位也是一样的一颗内置本地测温通道、并且带一个远程测温通道的数字温度传感器IC。接口走I2C/SMBus供电电压3.0V到3.6V都可以测温结果通过寄存器直接读取不用自己做模拟调理。我选这颗器件主要基于三点第一它支持SMBus报警协议也就是ALERT引脚。过温报警可以不依赖MCU轮询而是由传感器芯片自己判断阈值然后把ALERT脚拉低触发MCU中断。这就能让主控在低压检测保护这类任务上少费心思报警响应也更快。第二它的远程测温通道支持外部三极管作为感温头而且对外部三极管型号不挑常见的小信号NPN三极管比如S8050、2N3904都能用只要把基极和集电极短接在发射极和基极之间量电压即可。这就比某些只能用特定型号二极管的芯片在采购上灵活得多。第三芯片内置了温度偏置和失调补偿寄存器。远程测温的物理原理是测量PN结压差这导致它天然会受线阻、焊接电阻和远端器件的工艺差异影响。厂家在芯片里给了几个可编程寄存器让我可以在软件里做校准不用改硬件。这点在批量生产中也是实用价值极高的因为换一批三极管或者改变线缆长度时只需要更新校准参数。再说STM32G491RE。这颗主控在这个项目里承担的不只是读温度还包括完整的HVAC主逻辑。它有什么优势可以重点说带FPU的Cortex-M4F内核跑PID和滤波算法很顺。温度数据虽然简单但HVAC整体工况切换、压缩机变频控制、多路风机协调这些都要在同一个主控上跑算力余量是必须留出来的。STM32G4系列的ADC是有硬件过采样功能的可以在不打扰CPU的情况下做多次采样累加。虽然测温数据走I2C数字接口但后续如果还要扩展NTC接口或者采集电流电压ADC的能力会直接影响系统复杂度。丰富的I2C接口以及硬件I2C对SMBus超时处理的支持。很多人知道I2C有两个引脚但在SMBus协议里当总线被拉死时需要超时复位机制。STM32的I2C外设支持时序超时检测这让系统在异常时更不容易死锁。对比过STM32F1系列和STM32G0系列F1便宜但算力相对弱G0性价比高但外设没那么全G4处于一个更合适的位置有能力做主控而不只是做测温的“陪衬”。一个实际体感是如果只是测温STM32G030都绰绰有余但你要把一套完整的HVAC控制逻辑塞进去G4这个级别用起来才从容。2. 硬件电路设计决定器件型号之后硬件设计就要落到电路图上了。这一块看着简单实际踩坑的地方全在细节里。2.1 芯片电源与引脚外围电路PJ85718DM的VDD引脚需要3.3V供电。虽然芯片内部有电源管理但供电质量直接决定远程测温精度尤其是远程PN结的电压测量是微伏级别的信号电源上的一点点毛刺都可能在温度数据里体现出来。我当时的做法是给VDD脚用一颗1μF陶瓷电容和一颗0.1μF陶瓷电容并联去耦两颗电容尽量靠近电源引脚。硬件设计里这个组合是“标配”但很多人会在布局时忽略放置距离导致高频噪声根本没被滤掉。芯片的I2C地址引脚用于设置总线地址。PJ85718DM把地址引脚的高低电平组合映射到不同地址典型情况下允许在一个I2C总线上挂多颗芯片。不过我觉得一颗这样的芯片就够了因为它本身支持一路本地测温加一路远程测温大多数HVAC项目的传感器点位需求也就这么两路没有必须扩展。ALERT引脚值得单独说。这个脚是开漏输出正常工作时是高阻态触发报警时拉低。因此外部必须接上拉电阻。我用了10kΩ的上拉电阻接到3.3V。在实际测试中有一个容易被忽略的坑ALERT引脚在芯片上电初期会保持在一个不确定的电平状态如果这个脚接到MCU的外部中断引脚并且MCU配置的是上升沿/下降沿触发就会在系统启动阶段产生一个误中断。我的解决方案是MCU端先配置成普通输入等系统初始化完成并确认ALERT脚电平稳定后再使能外部中断。还有个容易忽略的引脚是THERM或者叫过热输出不同芯片命名不一样。PJ85718DM留了这个功能引脚它和ALERT不同作用更像一个硬件急停当温度超过最高阈值时直接触发不需要MCU干预。在HVAC的过温保护设计里我用它来直接关断压缩机的驱动信号使能而不是等软件慢慢处理。因为从接到报警到主控做出反应总有一小段延迟硬件直接锁断驱动会更安全。2.2 与STM32G491RE的I2C接口连接STM32G491RE的I2C接口和PJ85718DM的连接理论上就是两根线SCL和SDA再加上一个ALERT中断线。I2C是开漏协议所以SCL和SDA都必须接上拉电阻。上拉电阻的阻值选择不是随便定的需要根据总线电容和通信速率计算。这个项目里I2C速率定在100kHz标准模式走线长度不长40厘米以内。总线上挂了两颗设备一颗是PJ85718DM另一颗是EEPROM用于掉电保存参数。总线电容估下来约80pF到150pF上拉电阻取4.7kΩ。这个组合实测波形上升沿干净,Z没有过冲也不存在边沿偏缓的问题。如果有些人想把通信频率提上去比如跑到400kHz上拉电阻就要降低到2.2kΩ甚至更低。这个调整的原因也很直接上拉电阻和总线寄生电容构成RC电路阻值越大边沿越缓太快就达不到协议要求的上升时间。我们不用高频因为PJ85718DM这类芯片本身也不是高速器件更高的速率对HVAC场景没有实际好处反而可能带来EMC风险所以就让它工作在100kHz,稳扎稳打。STM32端I2C外设配置为主模式。需要注意SCL和SDA引脚要选择一个支持开漏模式的推挽配置。很多初学者会直接把GPIO配置成推挽输出然后去操作I2C这样虽然也能通信但一旦有外部设备强拉总线就会出问题甚至可能损坏引脚。正确做法是把GPIO配置为开漏输出模式配合外部上拉电阻工作这跟I2C协议要求的线与逻辑一致。还有一个电平匹配问题。PJ85718DM的I2C电平是跟VDD走的如果VDD是3.3V那么它的高电平输出也是3.3V跟STM32G491RE的IO电平兼容。要注意的是有些旧款温度芯片的I2C引脚不是标准IO内部会用到5V容忍结构。PJ85718DM我没记错的话是没有问题的但如果你用别的型号一定要去看数据手册里I2C引脚是否支持“5V tolerant”不然引脚电平可能拉不上来。2.3 PCB布局与强电抗干扰设计HVAC设备的控制板上往往既有弱电控制部分又有强电驱动部分板上干扰源很多比如变频器的PWM开关节点、继电器线圈、压缩机驱动线等。温度监测电路本身不复杂但走线布局如果随随便便远程测温精度会一塌糊涂。远程测温的两根线最关键。PJ85718DM的远程测温通道本质上是一个高精度的电压差分测量电路外部PN结通过两根线接入芯片。如果这两根线靠近PWM输出线或继电器线耦合过来的噪声会叠加在被测信号上温度读数就会跳。我在布局时的做法是远程测温线尽量短从芯片引脚出来后就往传感器接口方向走不要绕大圈。远程测温线之间采用差分走线保持平行且尽量接近让外部干扰同时叠加在两根线上利用芯片的差模抑制能力抵消。如果两根线的间距太大共模干扰就会转化为差模干扰没法被消除。在远程测温接口附近加一个100pF到1nF的电容跨接在两根线之间滤除射频干扰。这个电容的取值需要谨慎后面我会单独展开讲因为它跟测温精度之间有矛盾。电源走线也应该和强电区域隔离。PJ85718DM的VDD可以由MCU板上的3.3V直接供电但尽量让电源走线不穿越强电区域否则电源纹波会污染测温结果。如果实在没法避开可以用磁珠隔一下再配合去耦电容。还有一个值得注意的点是远程三极管的安装位置。在冷媒管或回风口这些位置安装传感器时传感器本身可以用扎带固定在管壁上但一定不要让线材的金属屏蔽层直接接触带电部分。HVAC设备现场环境复杂有的客户安装人员不一定规范设计上最好在传感器接口处加TVS保护或者限流电阻以防万一。我在接口处串了一个100Ω电阻这个电阻同时也能帮助抑制振铃。3. 软件架构与驱动实现硬件搭起来之后真正决定系统好不好用的就是软件了。这个测温模块的软件我分了三个层次底层I2C驱动、PJ85718DM芯片驱动、上层应用逻辑。这种分层方式在工程上最省心因为以后如果换芯片只需要替换中间层上层逻辑几乎不用动。3.1 I2C通信基础与寄存器地图先建立一点基础认知。I2C总线上的通信是主从模式STM32G491RE作为主机发起通信PJ85718DM作为从机响应。通信过程大体是主机发出START信号然后发送从机地址加读写位从机收到匹配的地址后回ACK然后主机和从机通过数据字节交换信息最终以STOP信号结束。PJ85718DM这类芯片的寄存器访问方式通常是主机先发送要读的寄存器地址然后重启I2C总线或者直接重发START再发送设备地址加读位接着读取数据。具体到这片芯片它的寄存器地址空间不大算下来也就十几个寄存器其中最关键的有配置寄存器控制测温模式比如连续转换还是单次转换、报警模式等。本地温度寄存器存放最近一次本地温度转换结果。远程温度寄存器存放远程通道的温度结果。本地/远程高温报警阈值寄存器当实测值超过这个值就触发报警。失调补偿寄存器用于调整远程通道的温度测量偏移。我建议的做法是拿到芯片后第一步先读一遍所有寄存器的复位值。很多人直接按数据手册里的默认值写配置但在不同的上电时序或外部环境条件下实际默认值可能会跟手册描述有细微差异。先把复位值读出来能建立芯片当前状态的基线后面再排查问题会容易很多。3.2 初始化与温度读取代码结构驱动代码我习惯先做两个底层函数I2C写寄存器和I2C读寄存器。这两个函数不涉及具体芯片逻辑是纯粹的通信协议封装方便在STM32的HAL库之上再做一层薄薄的抽象。uint8_t temp_write_reg(uint8_t dev_addr, uint8_t reg_addr, uint8_t data) { return HAL_I2C_Mem_Write(hi2c1, dev_addr 1, reg_addr, I2C_MEMADD_SIZE_8BIT, data, 1, 100); } uint8_t temp_read_reg(uint8_t dev_addr, uint8_t reg_addr, uint8_t *data) { return HAL_I2C_Mem_Read(hi2c1, dev_addr 1, reg_addr, I2C_MEMADD_SIZE_8BIT, data, 1, 100); }底层通信确保没问题之后第一步是芯片初始化。初始化要做的操作是清空报警状态、设置转换模式、设置温度数据分辨率、配置报警阈值、以及使能远程通道的外部器件连接检测。void pj85718dm_init(void) { uint8_t val; // 设置连续转换模式使用0.0625°C分辨率 val PJ85718DM_CONV_CONTINUOUS | PJ85718DM_RES_12BIT; temp_write_reg(PJ85718DM_ADDR, PJ85718DM_REG_CONFIG, val); // 设置远程通道高温报警阈值为80°C temp_write_reg(PJ85718DM_ADDR, PJ85718DM_REG_REMOTE_HIGH_H, (uint8_t)((80 * 256) / 128)); temp_write_reg(PJ85718DM_ADDR, PJ85718DM_REG_REMOTE_HIGH_L, 0); // 使能远程二极管断线检测 val temp_read_reg(PJ85718DM_ADDR, PJ85718DM_REG_CONFIG); val | PJ85718DM_DIODE_FAULT; temp_write_reg(PJ85718DM_ADDR, PJ85718DM_REG_CONFIG, val); }在读取温度时我先读状态寄存器确认转换完成标志置位然后才读取本地温度和远程温度的寄存器。这一步骤不能省因为如果在转换过程中读到的是中间值可能会得到不稳定的数据。温度寄存器是高字节和低字节两个组合时需要做符号扩展处理。低温时寄存器里的数值是负数编码如果直接按无符号数拼起来就会出错。float pj85718dm_read_local_temp(void) { uint8_t high, low; int16_t raw; temp_read_reg(PJ85718DM_ADDR, PJ85718DM_REG_LOCAL_HIGH, high); temp_read_reg(PJ85718DM_ADDR, PJ85718DM_REG_LOCAL_LOW, low); raw (int16_t)((high 8) | low); // 右移处理符号位保留12位有效数据 raw 4; return raw * 0.0625f; }这里有个经验型细节温度寄存器的高低字节组合不同芯片的位定义略微有差异有的是12位数据有的是更细的13位甚至16位。PJ85718DM支持12位精度数据手册里写的LSB是0.0625℃。我出于省事把所有温度值都用float类型来存储在主控算力充足的前提下浮点数直接参与后续计算比较顺手也避免定点数缩放到最后把自己绕晕。3.3 数据处理与滤波策略硬件传感器读取的原始温度数据不能直接使用尤其是远程测温通道它很容易受到各种干扰和电气噪声的影响。我在项目里做了一层软件滤波策略有三板斧第一板斧是滑动平均滤波。连续取8个温度值每次读取新值时丢弃最老的一个用这8个值的平均值作为输出。这个滤波器对周期性噪声和随机毛刺都有不错的抑制效果而且实现简单几乎不占资源。第二板斧是限幅滤波。设定一个最大允许变化率比如1℃/s如果两次采样之间的温度变化超过了这个值就认为是异常跳变直接用上一次的有效值替代。这个策略在工业现场很实用因为温度变化本身是慢变量突然跳变大概率是干扰或者接插件接触不良。第三板斧是断线检测。PJ85718DM内置的远程二极管断线检测功能会判断远程传感器是否存在如果检测到断线寄存器里会置一个标志位。我在读取温度后都会检查这个标志如果断线告警置位就把温度值置为一个显式的无效值而不去参与控制逻辑。这三个策略组合下来实际效果相当稳。之前有一次现场调试时压缩机启动的瞬间本地温度显示出现了约1.5℃的跳变加了限幅滤波后这个跳变直接被挡住显示和上报的温度始终平滑。这种感受非常直观软件滤波不是可有可无的锦上添花而是工程落地必备的环节。4. 远程测温实现细节与误差控制远程测温是这颗芯片最核心的价值点但也是整个项目里最容易出错的地方。这一节单独展开说。4.1 远程PN结测温原理PJ85718DM的远程测温原理简单说就是利用半导体PN结的电压和温度的确定关系来推算温度。外部三极管的基极和集电极短接后接在芯片的远程测温引脚上芯片内部给这个PN结施加不同大小的偏置电流测量两次电流下的VBE电压差再通过公式推算温度。原理上有个很关键的点PN结的VBE电压绝对值本身受工艺影响比较大不同批次的三极管同一温度下VBE可能差几十毫伏但ΔVBE不同电流下的电压差与温度的关系曲线相对稳定受工艺影响很小。因此芯片使用ΔVBE而不是直接测VBE绝对值这样可以把器件个体差异的影响降到最低这也是这个方案能保持较高精度的原因。为什么选择三极管而不是普通二极管我实际用下来的理解是三极管短接基极-集电极后在VBE在0.4V到0.8V范围内集电极-发射极漏电流产生的误差更小响应也更接近理想PN结模型。有些芯片数据手册会特定推荐使用2N3904原因就是它的β值足够高等效串联电阻较小。当然这个技术也有它的脆弱面。远程PN结上的电压信号是毫伏级别的而且芯片要分辨的是不同电流下微小电压差异因此外部引线上的任何电阻都会引入误差。引线电阻上流过电流会产生压降这个压降直接叠加在被测的VBE上导致芯片误以为PN结温度更高。线阻越大温度读数偏高的幅度越大。4.2 硬件误差来源与补偿方法远程测温的误差主要来自三个方面。第一个是线阻误差。典型值估算下来引线电阻每增加1Ω远程测温读数大约会产生0.5℃到1℃的偏差。如果传感器引出线很长比如超过半米铜线的电阻已经有0.02Ω/m量级两根线合计下来还是有零点几欧的电阻也就是零点几度的误差。处理线阻误差有两种做法一种是在电路设计上做四线制测量额外引两根线给芯片做补偿适合远距离高精度场景另一种是软件补偿也就是在失调寄存器里写一个偏移值。我采用的是后者因为项目里的传感器线不长精度要求也不苛刻。先在常温下用标准温度计校准一次把偏差记录进EEPROM下次上电时自动加载补偿值。第二个是滤波电容带来的误差。远程测温引脚在PCB上加小电容是抑制高频干扰的常规手段但电容过大时会影响芯片在切换偏置电流时的建立时间导致ΔVBE测量不准确。数据手册里对典型推荐值的描述不一定根据你的电路做过验证。我的经验是先不加电容看看原始温度数据的噪声水平如果噪声可以接受就不加如果噪声偏大从100pF开始尝试逐步加大到1nF直到噪声降下来且温度读数没有明显偏移为止。第三个是共模干扰导致的读数波动。远程传感器安装位置靠近强电或马达时两根引线上会感应出共模干扰信号。芯片对共模信号有一定的抑制能力但这个抑制能力受到引线不平衡度的影响。如果两根引线完全等长等距干扰就是纯共模信号抑制效果很好。如果不是干扰进来就可能变成差模信号导致温度读数抖动。我实测遇到的一个典型现象是远程读数在压缩机启动瞬间会跳高几度而停机会跳低几度且抖动的方向和幅度比本地温度明显更剧烈。排查后发现远程传感器安装位置正好穿过了一块大电流走线的上方干扰耦合严重。处理方法是调整走线路径把远程传感器的引线绕开那个区域并把跨接电容加到470pF问题就明显缓解了。4.3 软件校准与多点标定方法说来惭愧第一版我直接把远程温度读数拿去跟水银温度计比偏差有2℃左右。分析下来发现主要不是芯片的问题而是传感器的安装方式和线阻导致的系统性偏差。于是我做了一套简单的软件校准流程分享出来供参考。第一步是单点偏移校准。把远程传感器和标准温度计放在同一个恒温环境下比如室温25℃读取芯片的远程温度值记下偏差量ΔT_offset然后把补偿值写入失调补偿寄存器。这个操作能修正掉大部分系统误差。说实话这种级别的校准能应付很多需求了。第二步是两点校准。在HVAC项目里我们关心的温度范围比较宽从0℃到60℃。单点校准只保证在校准点附近准离远了误差还是可能拉大。我选择两个校准点比如10℃和50℃各记录一次偏差然后做线性插值得到两个温度区间的不同补偿系数。这样做之后整个工作区间的最大误差从初始的2℃压缩到了标定后的0.3℃以内。第三步是批量生产时通过测试夹具写入校准参数。在生产阶段直接在产品主控里跑一套自动校准程序给传感器施加已知温度程序自动读取测量值计算偏移量后把参数写进EEPROM。这样每条产线出来的设备都带自己的校准参数既保证了批量一致性也不增加太多工时。软件校准的前提是硬件本身就稳定不能指望校准去弥补恶劣的硬件设计。如果偏差是随机的、跳变的那就是干扰问题或者接触问题单纯靠校准根本救不回来。5. 系统联调与HVAC场景部署驱动写好、硬件调通之后剩下的事情是把温度监测功能嵌进整个HVAC系统里跑起来。这一环节我们做了不少联调也暴露了很多单测时看不到的问题。5.1 报警联动与过温保护逻辑在HVAC系统里温度监测的意义不是“显示一个数字”而是参与控制和保护。这个项目里温度数据对接了三层逻辑。第一层是常规监控。温度每500ms刷新一次显示在本地LCD上同时通过Modbus寄存器对外提供读取。这层逻辑最简单纯读数据不参与控制。我在ROM里做了一个超时计数器超过5秒读取失败就显示“--”代表传感器故障不显示错误的数字。第二层是过温保护。本地的PJ85718DM高温报警阈值设置为85℃远程通道设置为70℃。当温度超过阈值时ALERT引脚拉低触发STM32G491RE的外部中断主控进入保护流程记录故障时间、关闭压缩机输出、在屏幕上显示故障代码。这套逻辑最大价值在于不需要主控软件去轮询温度硬件引脚本身就完成了“看门狗”的功能。第三层是降频策略。在温度超过第一阈值但还没有到报警阈值时比如本地温度超过75℃但未到85℃控制器会对压缩机的最大运行频率做限制。这层逻辑不做硬开关只调整运行参数保证系统在高温环境下还能继续运行但性能受限保护了器件又不会让系统直接停机。这个“软降额”策略在HVAC现场接受度很高因为客户更希望设备能持续运行而不是频繁告警。在设计报警阈值时还有个小细节需要给报警和恢复设置滞回区间。比如高温报警阈值是85℃恢复阈值设为75℃否则温度在84℃到86℃之间波动时系统会反复进入保护和退出保护导致压缩机频繁启停。我在配置寄存器里设置了报警阈值和恢复阈值两个不同值这个思路来自工程经验而不是数据手册的强制要求。5.2 远程数据上报方式嵌入式应用里的“远程”有两种理解一种是远程传感器物理位置上距离主控远另一种是远程数据上报通过网络把温度数据送出去。这个项目两个层面都有。PJ85718DM的远程通道解决的是第一个层面的问题直接把传感器拉远。而数据上报层面我用了Modbus RTU协议通过RS485发出去。RS485的接入也很常规STM32G491RE的UART外设接一个RS485收发芯片比如MAX3485这类半双工模式由GPIO控制收发方向。Modbus RTU协议里挂的是几个保持寄存器地址固定内容包含本地温度、远程温度、报警状态和系统状态标志位。上层调度系统或者楼宇自控主站通过Modbus读这些寄存器就能拿到所有数据。说一个Modbus对接时的坑HVAC现场的RS485总线往往会挂很多设备总线空闲时的偏置电阻设置不当会导致收到乱码或者干扰。我们在布线时给A线和B线之间加了终端电阻并且在主机端配置了偏置电阻来锁定空闲电平。一开始没加偏置电阻实测通信丢包率约在3%到5%加了之后就完全正常。这个经验成本很低但效益很明显值得记一笔。5.3 实测数据与稳定性验证联调完成后我在实验室做了48小时连续运行记录模拟温度波动、切换运行工况以及反复通断电。下面放一组有代表性的实测数据表测试条件本地传感器处于控制板上远程传感器贴在散热器表面环境温度约28℃。时间点本地温度读数℃远程温度读数℃标准温度计℃偏差℃0分钟31.134.234.00.210分钟31.235.635.50.120分钟31.037.837.60.230分钟31.438.938.60.360分钟31.339.839.60.2120分钟31.540.240.00.2从数据看经过校准后远程通道的最大偏差控制在0.3℃以内对于HVAC应用已经完全足够。需要注意这个精度的前提是传感器安装良好、没有接触不良或线缆过长问题。如果现场安装偷懒直接把传感器扔在角落不贴紧被测表面再好的芯片也救不回来。稳定性方面48小时连续运行期间没有出现一次温度数据跳变到离谱值的情况也没有发生I2C总线死锁。我还特意测试了在高压PWM输出切换的瞬间读取温度寄存器结果没有出现抛错或异常数据这主要归功于前面的软件滤波和硬件布局。6. 常见问题排查与实测经验技术项目到了最后踩过的坑和排查思路往往是这pa整体内容里最值钱的部分。把我在这个项目里遇到的问题整理成了速查表并附上排查思路供你直接对照使用。6.1 常见问题速查表现象可能原因排查步骤与解决方案I2C通信失败读不到任何寄存器值上拉电阻缺失或阻值过大地址配置错误SCL/SDA接线反了先用示波器看SCL/SDA波形确认从机地址配置用逻辑分析仪抓取时序确认ACK位是否正常本地温度正常远程温度读数为0或异常值远程传感器未接/接反断线检测误报滤波电容过大用万用表量远程二极管正向压降确认基极-集电极已短接检查电容之后是否读数恢复远程温度读数偏高且稳定引线电阻偏大远程传感器热耦合不良更换更粗更短的引线软件写入负偏移补偿确保传感器贴紧被测表面并涂导热硅脂压缩机启动瞬间温度跳变强电干扰耦合到远程测温线或电源检查走线是否平行贴近大电流路径增加远程测温引脚滤波电容在软件里增加限幅滤波ALERT引脚启动时误触发中断ALERT上电状态不稳定MCU初始化时先配置为普通输入等待200ms稳定后再配置为外部中断在ALERT输出上加上拉电阻I2C总线在长时间运行后死锁SMBus超时机制未处理总线上有设备拉死SDA开启STM32外设的超时检测在软件中增加总线恢复流程检查是否有设备地址冲突导致总线仲裁异常6.2 调试过程中最值得记的几件事如果只看数据手册做题这些坑是不会明摆着告诉你的。先说ALERT引脚的处理。我一开始是直接把ALERT接到MCU中断引脚一上电就收到了中断搞得我还怀疑芯片是不是坏了。后来单独量电平才发现芯片在上电初始化阶段会有一段不稳定的时间。如果你的设计把ALERT接到了硬件使能端或者安全继电器回路这种上电抖动可能会造成设备误动作这一点务必在设计中预留延时或者锁存机制。再说远程传感器的线长问题。虽然芯片理论上可以支持相对长的引线但实际线长在超过50厘米后温度读数的噪声会明显上升。我试过拉2米线读数在某些干扰条件下能跳个好几度。如果你确实需要拉更远有两个方向可以选择选支持特殊线阻补偿功能的芯片或者干脆在远端安装一个小小的I2C测温芯片通过数字信号回传。最后是I2C总线的稳定性。虽然I2C协议很长时间没变过但在嵌入式现场环境中总线死锁的情况一点都不少见。主要原因是SMBus协议里规定的超时机制在普通I2C传输中不会自动启动一旦有设备异常拉低总线整个通信就卡住。STM32G491RE的I2C外设支持硬件超时检测我建议无论目标芯片支不支持SMBus都开启这个功能。哪怕只把它当作一个防止总线的“安全绳”在项目后期节省的调试时间也会让你觉得值。根据我个人多次做类似项目的经验单片机读写温度芯片的代码本身不算难真正影响成败的反而是硬件工程师往往容易忽视的几个“无关紧要”的细节滤波电容取值、引线长度、布局走向和报警引脚的电平逻辑。如果你在调试中发现温度数据表现异常先别急着怀疑芯片或者改写软件拿示波器去量量传感器引线上有没有噪声可能问题一瞬间就能定位。毕竟在HVAC这种电磁环境相对复杂的现场稳定的数据链路往往比漂亮的程序架构更稀缺也更值钱。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
