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.3℃以内，对于HVAC应用已经完全足够。需要注意这个精度的前提是传感器安装良好、没有接触不良或线缆过长问题。如果现场安装偷懒直接把传感器扔在角落不贴紧被测表面，再好的芯片也救不回来。

稳定性方面，48小时连续运行期间没有出现一次温度数据跳变到离谱值的情况，也没有发生I2C总线死锁。我还特意测试了在高压PWM输出切换的瞬间读取温度寄存器，结果没有出现抛错或异常数据，这主要归功于前面的软件滤波和硬件布局。

6. 常见问题排查与实测经验

技术项目到了最后，踩过的坑和排查思路往往是这pa整体内容里最值钱的部分。把我在这个项目里遇到的问题整理成了速查表，并附上排查思路，供你直接对照使用。

6.1 常见问题速查表

6.2 调试过程中最值得记的几件事

如果只看数据手册做题，这些坑是不会明摆着告诉你的。

先说ALERT引脚的处理。我一开始是直接把ALERT接到MCU中断引脚，一上电就收到了中断，搞得我还怀疑芯片是不是坏了。后来单独量电平才发现芯片在上电初始化阶段会有一段不稳定的时间。如果你的设计把ALERT接到了硬件使能端或者安全继电器回路，这种上电抖动可能会造成设备误动作，这一点务必在设计中预留延时或者锁存机制。

再说远程传感器的线长问题。虽然芯片理论上可以支持相对长的引线，但实际线长在超过50厘米后，温度读数的噪声会明显上升。我试过拉2米线，读数在某些干扰条件下能跳个好几度。如果你确实需要拉更远，有两个方向可以选择：选支持特殊线阻补偿功能的芯片，或者干脆在远端安装一个小小的I2C测温芯片，通过数字信号回传。

最后是I2C总线的稳定性。虽然I2C协议很长时间没变过，但在嵌入式现场环境中，总线死锁的情况一点都不少见。主要原因是SMBus协议里规定的超时机制在普通I2C传输中不会自动启动，一旦有设备异常拉低总线，整个通信就卡住。STM32G491RE的I2C外设支持硬件超时检测，我建议无论目标芯片支不支持SMBus都开启这个功能。哪怕只把它当作一个防止总线的“安全绳”，在项目后期节省的调试时间也会让你觉得值。

根据我个人多次做类似项目的经验，单片机读写温度芯片的代码本身不算难，真正影响成败的反而是硬件工程师往往容易忽视的几个“无关紧要”的细节：滤波电容取值、引线长度、布局走向和报警引脚的电平逻辑。如果你在调试中发现温度数据表现异常，先别急着怀疑芯片或者改写软件，拿示波器去量量传感器引线上有没有噪声，可能问题一瞬间就能定位。毕竟在HVAC这种电磁环境相对复杂的现场，稳定的数据链路往往比漂亮的程序架构更稀缺，也更值钱。