做暖通控制和嵌入式设备运维的人，应该都经历过这种场景：控制器装在设备机柜里，不仅要实时知道柜内温度，还得盯着十几米外风管送风温度或者水系统回水温度。早期我习惯拉一根NTC热敏电阻直接过去，信号线长、阻值飘、误差随季节漂移，调试时最头疼的就是这些看不见的线缆损耗。后来在一个HVAC配套项目里，我用 PJ85718DM 配合 STM32F101ZG 做了一套“本地+远程”双通道温度监测，效果比预期好不少。

这篇文章就把这套系统的设计思路、驱动细节、抗干扰处理和调试验证完整写出来。里面包括我踩过的寄存器坑、远端二极管的布线限制，以及最后怎么把两路温度接进HVAC联动逻辑。适合正在用STM32F1系列做环境监测、暖通控制，或者想了解远程温度传感器到底怎么用的嵌入式工程师参考。

1. 链路拆解：HVAC项目里那个“本地/远程”温度问题到底卡在哪

1.1 一个典型的暖通控制场景

我接过的某类配套项目大致长这样：风冷热泵或者冷梁系统的控制箱放在电控间里，箱内控制器要监视自身散热情况，防止变频器、继电器长期过热；同时控制逻辑又必须知道送风管或者回风管里的空气温度，甚至还要参考冷水管路的供水温度。物理距离通常从几米到几十米，环境也完全不同——箱内是密闭电气空间，管道附近则是高湿、震动、温差大的工业现场。

这种情况下，“本地温度”和“远程温度”不是同一个量程、同一根线能解决的。本地要求响应快、抗干扰、贴近发热源；远程要求能长距离稳定传输、现场更换方便、在恶劣环境里不被噪声淹没。早期常用的方式无非三种：

• 长线NTC直采：成本最低，但线阻引入分压误差，现场又要做非线性查表，线缆种类一换，标定全废。
• 温度变送器输出4-20mA/0-10V：线性好、抗干扰，但一个测温点一个变送器，成本翻倍，还要额外供电和配置通道。
• 总线式数字传感器：精度和抗干扰都不错，但多数是封闭探头，做嵌入式设备内部温度监测时体积过大。

三种方案的取舍其实是个老问题。直到后来我把本地和远程通道放进同一颗温度传感器芯片里，才意识到双通道方案在工程上能省掉非常多麻烦：PCB面积小、接线统一、固件只维护一个I2C驱动。

1.2 远程温度为什么用“PN结二极管”而不是热电阻

远程通道的原理说起来不复杂。PN结正向压降Vbe在恒定偏置电流下，会随温度升高而近似线性下降，约-2mV/°C。但单个Vbe的绝对值受芯片工艺、漏电流影响很大，不能用它直接换算出绝对温度。所以远程温度传感器通常采用“两点电流法”：先后用两个不同电流I1、I2给同一个二极管施加偏置，分别测下Vbe1、Vbe2，取差值ΔVbe。根据半导体物理，这个差值近似等于一个与温度成正比的量（PTAT），这样就摆脱了工艺离散的影响。

实际使用中，远端测温元件一般推荐小信号三极管，比如常见的2N3906之类，把基极和集电极短接后作为等效二极管使用。相比普通二极管，三极管的Vbe温度曲线更稳定，放大倍数对ΔVbe法造成的误差更小。整套测温链路只需要D+/D-两根线拉到远端再接三极管，从系统角度看，这比把模拟电压信号原样拉几十米要可靠得多。

1.3 为什么不让MCU直接采集模拟量

很多人第一反应是：STM32F101ZG自带ADC，自己驱动恒流源再接二极管，不也能测温吗？理论可以，实际工程里却很别扭。MCU内部ADC参考电压温漂大，做0.1°C分辨率级别的采集需要外部精密基准和仪表放大器；而且远程信号长距离传输后，微弱模拟电压非常容易被变频器、继电器干扰压制。专用温度传感器芯片把这些都集成好了：内部恒流源、精密ADC、数字滤波、报警阈值、I2C/SMBus接口一应俱全，读一个寄存器就够了。对暖通这种批量嵌入式项目，维护成本和现场调试成本才是大头，专用芯片省下来的远不止几颗料钱。

2. PJ85718DM 的通道架构与上手后我踩过的几个寄存器坑

2.1 本地与远程两个通道的职责划分

PJ85718DM 这类芯片的核心价值，是同时提供两个测温通道：本地通道测量芯片自身及其附近PCB温度，远程通道通过外接二极管测量远端温度点。在我的项目里，职责划分非常明确：

• 本地通道负责“设备健康监测”。控制器机柜内如果过热，说明散热失效或负载异常，需要及时保护变频器、封锁输出。这个通道响应快，数据直接进保护逻辑。
• 远程通道负责“过程量监测”。风管送风温度、回风温度、水管温度属于控制目标，参与PID闭环或者超限报警。这个通道允许有零点几度的滞后，但必须长期稳定。

把两个职责分到一颗芯片上还有个隐藏好处：即使远程二极管被误接、断路，本地通道依然在独立工作，设备保护逻辑不会因为远程故障而失效。这一点对HVAC项目尤其重要——现场维护人员不一定懂传感器接线，故障隔离做得好，系统才不容易被误操作搞停机。

2.2 关键参数取舍参考

不同批次、不同封装的具体数值以器件手册为准，我这里列的是选型时需要重点核对的维度，可以当一张核对表用：

选型时建议不要只看常温精度。暖通现场温差大，远程通道在低温高温两端的误差会明显拉开。有条件的情况下，用恒温槽或者一支精度更高的数字温度计做几个温度点的比对，比只看手册参数靠谱得多。

2.3 第一次调试时踩到的寄存器顺序问题

这块芯片本身不难驱动，但寄存器读写有几个“顺序陷阱”。我第一次上电时犯了个很低级的失误：写完配置寄存器后立刻去读温度，结果读回来的数值像是很久之前的旧值，连续读几次都不刷新。后来翻手册才意识到，每次配置转换周期、滤波模式之后，传感器需要一到两个转换周期才会把新配置生效，至少要等待一个转换周期再读才是正确的。这个坑在调试初期浪费了我将近一个下午。

另外一个容易翻车的地方是高字节和低字节的读取顺序。很多I2C数字温度传感器的寄存器是16位，但MCU读取时如果只读高字节，低字节落到下一组数据，就可能出现“高低字节不是同一次转换结果”的错位。正确做法是固定从高字节寄存器地址开始连续读两字节，或者直接用多字节组合读功能一次把两个通道的数据都取回来。量产固件里我用了一个简单的连续读函数，把本地、远程两个通道总共四个字节当成一组buf读回，再按通道拆解，稳定多了。

还有一个值得提醒的点：芯片的I2C地址位对齐。手册上写的地址往往是7位地址，比如0x4E，但发送时要左移一位变成0x9C/0x9D；直接拿0x4E当8位地址去发，总线会一直NACK。这种低级问题最容易出现在用逻辑分析仪抓波形发现地址不对的时候。

3. STM32F101ZG 驱动的集成细节：I2C初始化、读时序与上电顺序

3.1 MCU选型：为什么是STM32F101ZG而不是更小的芯片

STM32F101ZG 属于Cortex-M3内核的F1系列，LQFP144封装，引脚资源非常充裕，片内Flash和SRAM在这个任务里都绰绰有余。单看测温需求，用一颗8位单片机也能实现，但HVAC项目通常不是只测温：同一颗MCU还要控制风机、水泵、继电器，读写其他传感器，甚至预留通信接口给楼宇系统。用这颗芯片，主要是给方案留了扩展余地，温度采集只是其中一个外设任务。

实际使用中F101系列主频没有F103那么高，但对温度读取这种低频操作完全够用。I2C以100kHz标准速度运行，每次读两个通道温度也就几十个字节的通信量，CPU占用可以忽略。更重要的是144引脚封装的GPIO多，I2C、UART、PWM、外部中断都能同时铺开，不会为了省引脚去复用一些麻烦的功能。

3.2 I2C初始化代码与总线细节

我用标准外设库风格的代码做一个示意，实际项目里按自己的库版本调整函数名。I2C1默认映射到PB6/PB7，开漏输出，外部必须有上拉电阻。

void I2C1_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; I2C_InitTypeDef I2C_InitStructure; RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE); RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_6 | GPIO_Pin_7; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOB, &GPIO_InitStructure); RCC_I2C1CLKConfig(RCC_I2C1CLK_SYSCLK); I2C_DeInit(I2C1); I2C_InitStructure.I2C_Mode = I2C_Mode_I2C; I2C_InitStructure.I2C_DutyCycle = I2C_DutyCycle_2; I2C_InitStructure.I2C_OwnAddress = 0x30; I2C_InitStructure.I2C_Ack = I2C_Ack_Enable; I2C_InitStructure.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit; I2C_InitStructure.I2C_ClockSpeed = 100000; I2C_Init(I2C1, &I2C_InitStructure); I2C_Cmd(I2C1, ENABLE); }

总线速度我刻意设成100kHz，没有用400kHz。原因很实际：传感器和远端二极管之间是几十米的双绞线，总线上还可能再挂其他设备，总线电容偏大，快速模式会让波形边沿变缓，反而增加误码率。HVAC应用对温度数据刷新率要求不高，标准速度更稳。

上拉电阻的选择也有讲究。我最初用了常见的4.7kΩ，总线长度短时没问题，但接到几十米的延长线上，低电平驱动力会被分布电容拖慢。后来把上拉换成2.2kΩ，信号沿明显好了。这里要注意：上拉太小会增加灌电流，必须在芯片允许的范围内选择，最好按实际波形选。

3.3 读TMP数据的完整时序：轮询、超时与地址对齐

读取温度寄存器的基本流程是：起始条件、发送7位地址加写位、发送寄存器地址、重新发起起始条件、发送7位地址加读位、读高字节、读低字节并返回NACK、停止条件。代码示意：

uint16_t Sensor_ReadReg(uint8_t slave_addr, uint8_t reg_addr) { uint16_t value = 0; uint8_t buf[2] = {0}; while (I2C_GetFlagStatus(I2C1, I2C_FLAG_BUSY) == SET); I2C_GenerateSTART(I2C1, ENABLE); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)); I2C_Send7bitAddress(I2C1, slave_addr, I2C_Direction_Transmitter); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)); I2C_SendData(I2C1, reg_addr); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTED)); I2C_GenerateSTART(I2C1, ENABLE); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT)); I2C_Send7bitAddress(I2C1, slave_addr, I2C_Direction_Receiver); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_RECEIVER_MODE_SELECTED)); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_RECEIVED)); buf[0] = I2C_ReceiveData(I2C1); I2C_AcknowledgeConfig(I2C1, DISABLE); while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_RECEIVED)); buf[1] = I2C_ReceiveData(I2C1); I2C_AcknowledgeConfig(I2C1, ENABLE); I2C_GenerateSTOP(I2C1, ENABLE); value = (buf[0] << 8) | buf[1]; return value; }

用轮询方式最关键的一点是加超时。我见过太多同行在等待事件标志时没有超时判断，一旦传感器没上电、地址写错或者线缆断路，程序就卡死在while循环里，整个控制逻辑跟着瘫痪。实际固件里每个等待事件都加了一个超时变量，一旦超时立刻报I2C错误并重置总线状态，而不是无限等下去。

F1系列硬件I2C在业界有一些著名的“脾气”，尤其是在总线上出现异常时序时容易锁死BUSY。如果项目对稳定性要求很高，也可以考虑直接用GPIO模拟I2C——温度采集速度要求低，模拟时序完全跑得动，调试起来反而更直观。HVAC设备常年不断电运行，固件里多做一手总线恢复策略总是好的。

3.4 上电顺序、ALERT引脚和复位策略

传感器和MCU建议使用同一个3.3V电源域，上电时让I2C总线的SDA、SCL自然被上拉电阻拉高，避免出现低电平冲突。ALERT引脚要特别注意：有些传感器在配置初始化完成前，ALERT可能出现无效的报警脉冲，如果这个引脚直接接到MCU外部中断，很可能一上电就误触发保护逻辑。我的处理办法是初始化阶段先把ALERT中断屏蔽，完成传感器配置、清除状态寄存器之后再使能中断，并且用软件标志位过滤前几个周期的报警。

软件复位也是个实用的保险措施。当连续多次I2C通信超时，我会对传感器执行一次软复位，然后重新配置阈值和转换模式。这样的恢复动作在代码里是独立函数，不依赖人重启系统，能在无人值守的机柜里自动恢复通信。对HVAC这种长期在线设备来说，这个设计比单纯加看门狗更贴近问题本身。

4. 远端测温误差的五个来源：从二极管选型到几十米线缆

4.1 串联电阻：读数是会变高的

远程通道测量的是PN结正向压降，而线缆、端子、PCB走线本身都有电阻。这些串联电阻叠加在Vbe上，直接影响ΔVbe法算出来的温度，表现通常是远程读数偏高。不同芯片对串联电阻的容忍度不同，有的内部做了路径补偿，但补偿范围有限。

我在调试时先做过一个快速验证：把D+/D-直接短接，看芯片读出的“温度”；接着串入一个10Ω的电阻再读一次，两次读数的差值就是串联电阻引入的误差基线。之后测量实际的几十米线缆和接插件总电阻，心里就有数了。现场处理时，我尽量使用24AWG以上的双绞屏蔽线，接头也选阻值稳定的压接端子，尽量避免用长条接线排，否则每颗螺钉都是潜在的误差点。

4.2 二极管/三极管选型：型号换了读数就飘

远程PN结测温的精度很大程度上取决于远端器件的一致性。手册推荐的常用型号往往是某种小信号三极管，例如2N3906这类，把基极和集电极短接当两极管用。如果你换了另一种三极管，即便封装一样，电流增益、体电阻、工艺曲线都会有差异，读出的温度可能整体偏移零点几度甚至更多。

实际生产时，我的BOM清单里固定了一种三极管型号、一个品牌，并且要求采购不要随意替换替代料。样品阶段我对比过两个不同品牌的“同型号”管子，25°C时读数差了0.3°C左右，到了60°C差得更多。这种误差在HVAC控制里不算致命，但如果你要参与能耗计量或者做温度趋势分析，累积下来的偏差就很难看了。如果一个项目有多个远程通道，所有通道的远端器件必须统一，不能混着用。

远程二极管的接法也要严格遵守手册。一般情况是D+接PNP管的发射极，D-接基极和集电极的短接端；如果是普通二极管，通常阳极接D+、阴极接D-。但不同芯片内部电流源方向可能不同，我在第一次画板时翻手册确认了好几遍，这一步错了，读出来的温度会出现非常大的偏移或者跳变，不是靠滤波能救回来的。

4.3 线缆电容与滤波电容：能滤噪，也能滤掉精度

远程通道的两个引脚上通常会加一个小电容滤除高频噪声，但电容值非常敏感。我之前按常规思维直接放了0.1μF去耦电容，结果远程读数跳动变大，曲线变得迟钝，响应时间明显拉长。原因在于传感器内部是用电流脉冲驱动二极管的，过大的电容负载会让每次电流建立时间变长，ADC采样时电压还没稳定，数据自然不准。

后来我把D+/D-之间的滤波电容降到1000pF以下，效果就好多了。如果现场电磁环境特别恶劣，优先考虑用屏蔽层解决问题，而不是一味加大电容。屏蔽双绞线两端要处理好接地点：我习惯在控制器端单点接地，远端传感器端不接地，这样避免屏蔽层两端形成地环路电流，把共模干扰引入测量回路。这里得提醒一句，不同厂商的推荐电容值不一样，板子画之前一定先看手册里的Layout说明。

4.4 端子和温差带来的热电势问题

远程测温链路里，D+/D-两根线如果材质不同，或者经过不同的金属端子，在存在温差的环境里会产生微量热电势。这个原理类似热电偶，虽然数值很小，但在高精度远程测量时足以造成零点几度的偏移。

实际项目里不必追求实验室级的极端对称，但有几个现实问题要留意：不要用不同颜色的铜芯线接D+/D-，尽量用同一盘线的两根线芯；接线端子尽量用同种镀层材料；D+/D-走线在PCB上保持等长、对称，不要一根从板边走、另一根穿过干扰区。说穿了就是保证“两只眼睛”看到的环境尽量一致，这样远端二极管的信号才能被对称地传回芯片。

4.5 软件滤波和故障判断：不要把原始值直接丢给PID

远端温度信号经过几十米线缆后，难免混入一些脉冲干扰，数据上表现为个别跳变点。我一开始直接把原始温度值送去PID，结果送风温度偶发一个0.5°C的跳变，执行器就跟着抖一下。后来在数据进控制逻辑之前加了一级滑动平均，窗口取了8次，HVAC本身热惯性大，8次滤波引入的滞后在可接受范围。

滤波设计有个细节：参与报警和故障判断的数据最好用滤波前原始值。因为滑动平均会把短暂的传感器断路、短路现象“摊平”，报警反而触发不及时。我的做法是双路并存——原始值做故障识别和紧急保护，滤波值做PID和显示。这样既平滑了控制量，又不牺牲故障响应的实时性。报警阈值上还要加滞回，比如远程温度超过45°C告警，要降到43°C以下才解除，避免温度在临界点来回抖动导致继电器频繁吸合。

5. 把温度数据接进控制链：滤波、故障判别与HVAC联动

5.1 原始数据的有效性筛选

从I2C读回来的16位数据，并不是任何时候都能直接换算成温度。传感器内部转换尚未完成、配置寄存器被意外改写、电源纹波过大，都可能让读回来的数据出现极值或者跳变。固件里我加了一个“合理性检查”：判断温度是否落在物理和工程双重范围内，比如小于-70°C或大于170°C的直接丢弃，连续出现3次才判为错误。

工程范围的判断比物理范围更实用。HVAC系统里，风管送风温度一般在5°C到50°C之间，机柜内部温度在-20°C到85°C之间，超出这个范围就应该标记为可疑数据。可疑数据不能直接用于控制，但也不能立刻判故障，保持一个计数状态，连续异常再转故障。这种阶梯式状态判断，比简单丢弃数据更能抵抗瞬时干扰。

5.2 故障识别与“最后有效值”的使用

远程传感器最常见的故障是断线和短路。断线时芯片读到的温度往往跳到上限附近或明显不合逻辑，短路时读数会降到下限附近。我提炼出故障判据：高到离谱或者低到离谱的读值、连续多次I2C通信错误、配置寄存器读回值与写入值不一致，这三种情况任一出现，就认为该通道进入故障状态。

故障状态下，我把“最后有效温度值”缓存起来，提供给显示界面参考，但控制逻辑会切换到安全模式。安全模式的具体动作取决于系统风险：送风温度传感器故障时，不能盲目把风机开到最大或者停机，而是保持一个保守的默认输出，同时点亮报警灯并在通信帧里置故障标志。HVAC系统讲究持续运行，设备保护和控制稳定性要同时兼顾，不能在传感器故障时让整个空调系统“情绪化”。

5.3 与HVAC控制逻辑联动：本地保护、远程调节

本地通道和远程通道最终进入不同的控制链路。本地温度主要服务于设备保护：当柜内温度超过设定上限，说明散热风扇失效或负载异常，固件会逐渐限制变频器输出，避免功率器件过热损坏；等温度降到下限以下再逐步恢复。这个保护逻辑用的是大滞回，避免频繁启停损坏接触器。

远程通道则参与温度闭环。典型场景是送风温度控制：设定温度24°C，实际送风温度为24.8°C，PID输出增大风机转速或调节水阀开度。PID参数的整定我不是一开始就给定的，而是先用手动输出跑几组工况，记录温度阶跃响应的滞后时间，再粗略估算Kp、Ki、Kd。温度环的响应速度不快，积分项容易饱和，我在代码里还加了积分限幅，防止停风等情况导致风管温度长时间拉不回来，积分项越积越大。

ALERT引脚在联调阶段扮演的角色是“物理紧急通道”。正常情况下，我通过I2C周期性读状态寄存器做阈值判断；但遇到芯片检测到远端断线或者阈值越限，它会主动拉低ALERT引脚，触发MCU外部中断，立即进入处理流程。这样即使主程序忙于控制逻辑、I2C轮询被延迟，紧急故障也能在微秒级被察觉。

5.4 上位机上报的简单帧设计

温度数据除了控制指令用，还要送给触摸屏或者楼宇监控系统。我不建议直接暴露原始寄存器值，而是定义好一帧简单的应用层协议：帧头、功能码、通道号、温度值（放大10倍的整数）、状态字节、校验字节。

0xAA 0x55 | CH | T_INT | T_DEC | STATUS | CRC

状态字节里用位标志表示通道是否故障、是否超限、ALERT是否触发。CRC我用了一个简单的累加和，虽然强度不如CRC16，但对暖通这种数据量极低的场景足够发现偶发错位。这套帧结构后来也让售后调试变得很简单：用串口助手发一个读指令，回传一帧数据，现场一眼就看出是哪个通道、哪个温度参与控制，不用猜。

数据刷新周期我设成1秒。温度本身是慢变量，HVAC控制周期通常也在秒级别，1秒刷新既给滤波留足了时间，又不会让总线上产生多余流量。如果后续要多路传感器扩展，这个周期还能进一步调低。

6. 实测表现、可复现清单与调试验收时的几点体会

6.1 一组实际测量数据（样本结果）

先在实验室环境做了一轮对比测量。用一支精度较高的工业温度计作为参考，把传感器本地通道和参考探头放在同一恒温环境中；远程通道接一个2N3906组成的三极管，通过不同长度的双绞线引到同一个环境。摘取几个有代表性的数据点：

这个结果符合预期：短距离时本地和远程通道精度都很好；拉长线后，串联电阻和线缆寄生参数会把远程读数推高；加入软件平均和合理布线后，误差压回可接受范围。需要说明的是，这是某一批样片和某一种线缆配置下的样本数据，不代表器件指标上限，但已经能说明整个链路的设计方法是否可靠。

6.2 硬件/软件复现清单

如果你也想快速搭一套同样的系统，我建议按这个顺序准备：

1. 硬件准备：一块STM32F101ZG最小系统板、PJ85718DM模块或自研小板、几只小信号三极管（如2N3906）、2.2kΩ到4.7kΩ的I2C上拉电阻、一根至少几米长的双绞屏蔽线。
2. 接线确认：I2C总线接PB6/PB7，ALERT接一个带外部中断的GPIO，D+/D-通过双绞线接到远端三极管，三极管接法以传感器手册为准。
3. 基础固件：先写I2C扫描函数，把所有总线上挂着的传感器地址扫一遍，确认通信没问题；再读本地温度寄存器，验证数据随温度变化。
4. 远程通道验证：接上远端三极管，读取远程温度，用手捏住三极管看数值是否上升，松开后是否回落。这一步能快速确认极性、接线、通道配置是否正确。
5. 建立数据质量层：写合理性检查、连续错误计数、8次滑动平均，把这些模块封装成独立函数，方便后续换传感器时复用。
6. 接入控制逻辑：先本地保护后远程PID，逐步调试阈值、滞回、积分限幅，最后再做报警和状态上报。

6.3 调试验收时容易忽略的三件事

第一，远程通道的偏差不能靠软件硬拉。HVAC现场温差大，如果你发现远程读数在不同温度点偏差方向和大小不一致，多半是远端器件选型或布线问题，而不是一个固定偏移量能校准的。处理顺序永远是先查物理链路，再谈软件算法。

第二，寄存器初始化顺序要比你自己预期的更严谨。转换周期、滤波、阈值、ALERT模式这些参数，每一次上电都必须按固定顺序配置，中间不能跳过，也不能在配置未完成时读温度。把初始化函数写得冗长一些，多等待几个转换周期，能省掉后期很多偶发问题。

第三，故障恢复测试一定要做。就算硬件和固件都写完了，也要模拟一下“远端二极管拔掉”和“短路”两种场景，观察系统是否进入安全模式、界面是否出现故障提示、控制输出是否按预期动作。我在验收阶段做过多次反复插拔测试，才敢把设备放上现场。AS长期运行的设备不怕一两秒的响应延迟，怕的是故障时乱动作。

这套“本地+远程”双通道测温方案，本质上是把模拟链路的可靠性问题用数字接口化解掉了。PJ85718DM负责把复杂测量转成简单寄存器访问，STM32F101ZG负责把温度数据变成可靠的暖通控制动作，中间的物理层细节才是决定成败的关键。如果你也在做类似嵌入式测温或者HVAC项目，希望这篇记录能帮你少走点弯路。