做了几年HVAC控制项目我最怕的不是PID调不好而是温度采不到点上。之前做过的一个风柜AHU控制项目温度传感器装在控制柜里测的是柜内温度跟回风管道里的实际温度差了四五度。PID怎么调都稳不住后来把传感器拉到管道里才恢复正常。这个经历让我养成了一个习惯凡是做温度控制一定要先想清楚测的是哪里的温度、离控制对象有多远。这次要聊的方案本质上是把这个经典问题拆成两半来解决PJ85718DM这颗芯片负责同时监测本地和远程温度STM32F469II负责跑控制、显示和通信。适用场景很明确——嵌入式设备里的板级温度监控以及HVAC场景里常见的回风温度、送风温度、盘管防冻探头这类多点监测需求。如果你正在做类似的东西这篇文章里的选型逻辑、电路细节、固件架构和踩坑记录应该能帮你少走不少弯路。1. 从HVAC现场出发为什么单个温度点根本不解决问题1.1 一个真实的项目需求是怎么落到本地远程上的HVAC系统里温度不是一个点的概念而是一组点。一套常见的中型风柜系统控制器要同时盯着回风温度代表房间平均温度、送风温度代表盘管出风的实际效果、盘管表面温度防冻结保护用、室外补风温度新风补偿用再加上控制器自身的板温判断控制柜散热是否正常。这一组温度如果各拉一根传感器线控制柜里的接线端子直接占掉一大排调试的时候光对线号就能让人崩溃。我之前用过的传统做法是NTC热敏电阻方案每个测温点一颗NTC配一个分压电阻再占用一个ADC通道。好处是便宜坏处也明显——通道数量紧张线缆一长分压误差就变大而且NTC的B值离散性使得每个通道都要单独校准。相对好一点的工业做法是每个点放一颗I2C温度芯片但这样一颗芯片只能覆盖一个点成本又上去了。所以当我把需求梳理清楚之后方案就变得很自然控制器的本地温度本身要测管道里的远程温度也要测那就找一颗自带本地测温、同时支持远程二极管测温的传感器。我手上拿到的PJ85718DM正好是这类芯片内置1路本地测温通道外接2路远程二极管通道走I2C/SMBus接口一次把三个温度点的数据全读回来。1.2 选型对比为什么是二极管测温而不是NTC或PT100在HVAC这种对成本敏感的行业温度传感器的选型其实是个权衡题。NTC便宜但需要校准PT100精度高但调理电路贵集成温度芯片省事但单点成本偏高。PJ85718DM这种本地远程二极管方案走的是另一条路远程探头本身就是一个普通三极管几分钱一颗却能做到免标定测量这是它最大的价值。我用一个实际对比表来总结当时的考量对比项NTC多路采集每点独立I2C温度芯片本地远程二极管方案单点硬件成本低NTC电阻中每点一颗芯片低一个三极管测温精度依赖校准离散性大高芯片出厂校准中高三四线制下误差可控布线复杂度每个点2根线到ADC每个点2根线I2C总线远程探头2根双绞线即可抗干扰能力易受线缆电阻影响较好对射频干扰敏感需滤波调试便利性逐个通道标定读取寄存器即可读取寄存器即可扩展性加硬件MUX换地址或加总线挂一路二极管就是一个新测点结论很直接在多测点、中精度、低成本、好调试这个交集里本地远程二极管方案是性价比比较高的选择。PJ85718DM内部其实已经在做所有模拟测量和数字化转换MCU只需要通过I2C读寄存器软件工作量比NTC方案少一大截。1.3 为什么主控选了STM32F469II这里有一个很多人会问的问题温度监测而已用STM32F103或G030不就行了吗确实单纯读温度用Cortex-M0都绰绰有余但这个项目的需求不止读温度。项目要求一块7寸RGB接口的LCD屏要实时显示三个测温点的数值和温度趋势曲线同时跑PID控制逻辑还要预留以太网口和RS485口准备接楼宇自控系统。F469II这颗芯片的定位就非常匹配180MHz主频带FPU2MB Flash、384KB SRAM内置TFT-LCD控制器LTDC内置DMA2D图形加速器还带FMC外部存储器接口可以直接外挂SDRAM做帧缓冲。等于说显示、控制、通信、人机交互全部一颗芯片搞定不用额外加串口屏模块也不用量产阶段还要单独买一颗显示驱动MCU。还有一个现实原因HVAC控制柜里温度传感器离变频器、接触器很近现场干扰严重后续如果要做软件补偿和滤波算法FPU和主频高一点会从容很多。所以主控选型这事核心是让MCU的能力覆盖项目未来两三年可能加的需求而不是只看当前几个温度点的计算量。2. 先把测温原理讲透PN结、ΔVbe和那条远程二极管2.1 两颗不同电流下的Vbe为什么能算出绝对温度很多第一次接触远程二极管测温的工程师看到用三极管测温度第一反应是离谱。但要理解PJ85718DM的远程通道必须回到PN结的物理特性。二极管的正向压降Vf会随温度变化大概每升高1°C下降2mV左右。但直接用这个绝对值测温是不行的因为Vf还受饱和电流Is影响而Is在不同二极管之间差别很大同一颗二极管在不同温度下也是指数变化。这样一来绝对Vf和温度之间没有一个统一的、稳定的关系。解决办法是比值测量法给PN结先后施加两个不同的正向电流I1和I2分别测出Vbe1和Vbe2然后计算差值。根据PN结的电流方程ΔVbe (k × T / q) × ln(I1 / I2)在这个公式里饱和电流Is被消掉了剩下的只有玻尔兹曼常数k、电荷量q、绝对温度T和电流比例。所以ΔVbe的大小只和绝对温度成正比和具体是哪颗二极管关系极小。举个数值例子如果I1 10μA、I2 100μA那么ln(I1/I2) ln(10) ≈ 2.303在25°C约298.15K时ΔVbe ≈ 86.17μV/K × 298.15K ≈ 25.7mV。芯片内部把这两个小电压精确测量并放大再通过一个带符号的12位或14位ADC转换成数字量就能以0.0625°C的LSB输出温度值。这个两个电流轮流打进去测压差的过程就是PJ85718DM远程通道的本质。也因此远程通道对测量瞬间的噪声特别敏感。如果有一个高频干扰窜进探头线采样点上的Vbe会被扰动算出来的温度自然就跳。后面我会讲怎么用硬件滤波和软件滤波一起压制这个问题。2.2 远程探头的接法三极管当二极管用而且首选费用最低的那种PJ85718DM的远程通道引出两根线通常标成D和D-要求外接一个PN结。最佳实践是用小信号三极管把集电极和基极短接在一起让发射结作为测温PN结。市面上最常见的型号就是2N3904NPN和2N3906PNP几分钱一颗参数一致性也不错。为什么不用普通的1N4148之类的二极管因为1N4148是开关二极管它的串联电阻、理想因子和Is参数相对于专用测温需求来说不够干净。而三极管的发射结面积、掺杂浓度是经过工艺优化的做出来的温度曲线更接近理论模型。另外三极管体积小、容易贴装还能直接焊在探头小板上外面套热缩管或防水壳放在管道里成本很低。接线方式要注意极性如果是PNP型三极管2N3906把发射极接到D集电极和基极短接后接到D-。如果是NPN型2N3904则发射极接D-集电极和基极短接后接D。不同芯片对探头极性的定义会略有差异以PJ85718DM的数据手册为准。我之前在这个细节上吃过亏第一次焊板时按NPN习惯接反了读回来的远程温度直接是-20°C左右的不合理数值查了半天才发现是极性接反。2.3 精度、误差模型和看似多余的补偿寄存器远程测温看起来简单但实际工程里误差源比本地测温多不少。最典型的是线缆串联电阻。远程探头用双绞线连接铜线本身有电阻比如1米24AWG双绞线大约0.08Ω5米来回就是0.8Ω左右。芯片在给二极管注入电流时这个串联电阻上也会产生压降相当于在测量回路里额外叠加了一个偏移电压最终导致温度读数偏高。好在PJ85718DM这类芯片基本都提供了线电阻补偿机制原理上是通过自动检测两个不同电流注入时的电压差来估算线阻然后在结果中减去对应的误差。这个功能在不同芯片上名字不一样有的叫TCR有的直接叫offset寄存器。实际使用中3米以内的线通常不补偿也能控制在±1°C左右超过3米建议把补偿打开或者用软件做一次两点校准。除了线电阻还有一个容易被忽略的量是理想因子β。PN结的电流方程里理想因子n并不是严格的1通常在1.01到1.05之间。不同批次三极管也会有偏差PJ85718DM的远程通道寄存器里一般有β补偿位用来微调温度系数。如果做批量产最好在出厂前用恒温槽抽测几颗探头把β值或offset封进EEPROM里。3. 硬件实现STM32F469II外设分配与传感器电路的工程化细节3.1 STM32F469II最小系统和外设资源如何分配我用的是LQFP176封装的STM32F469IIT62MB Flash、384KB SRAM180MHz主频。这个芯片把资源理顺之后整块控制板的架构非常清晰。电源方面HVAC控制柜里一般提供24V直流板上用隔离电源模块转成5V再经过低噪声LDO降到3.3V给MCU和传感器供电。F469II的模拟供电VDDA最好通过磁珠从3.3V分支出来并在VDDA引脚附近放0.1μF和10μF电容这样ADC部分不容易受到数字开关噪声干扰。F469II的外设分配大致是这样的I2C1挂PJ85718DM温度传感器时钟线SCL和数据线SDA各接4.7kΩ上拉到3.3VI2C2挂一个8Kbit的EEPROM用来存校准系数和报警历史LTDC接口接7寸RGB888液晶屏帧缓冲用一片16Mbit的SDRAM挂在FMC接口上USART1做RS485通信SDIO或者FMC的NOR接口预留将来装外部Flash存曲线数据GPIO接ALERT报警、继电器输出、按键输入。这套分配下来F469II的外设基本没有浪费也没有出现引脚冲突需要被迫改方案的状况。有一点经验是一定先把LCD屏需要的引脚锁定因为LTDC接口占用的IO非常多而且要结合引脚复用功能表仔细核对等项目做了一半再发现引脚冲突就比较痛苦了。3.2 PJ85718DM传感器电路设计去耦、上拉和RC滤波PJ85718DM本身的电路不算复杂但有些细节会直接影响远程温度的稳定性。首先供电去耦VDD引脚旁边放0.1μF陶瓷电容再并联一颗10μF钽电容或陶瓷电容尽量靠近芯片引脚。这类传感器内部有精密电流源和ADC供电纹波会直接耦合到测量结果里。SDA和SCL的I2C上拉电阻我最终选了2.2kΩ。这个值需要根据总线上的总电容来算标准模式I2C总线上拉电阻一般用4.7kΩ但如果总线上的器件多、走线长总线电容一大上升沿会变慢就需要把上拉电阻调小。我的板子上除了PJ85718DM还有一些状态显示LED驱动芯片挂在同一条I2C总线上总线电容相对偏大所以用2.2kΩ更稳妥。如果走线特别长的场合甚至可以试1kΩ但要确认芯片的灌电流能力。最关键的是远程通道的输入滤波。PJ85718DM的D和D-引脚直接连接远程双绞线现场的变频器、风机电机都是干扰源。通常做法是在靠近芯片侧的D串入一个1kΩ左右的电阻在D和D-之间并一个100pF到1nF的陶瓷电容。这个RC低通能滤掉相当一部分射频干扰。电容不是越大越好太大会让内部电流源的建立时间变长导致转换结果偏慢甚至失真我一般从100pF开始试实测干扰还压不住再加到220pF、470pF这样。3.3 远程探头线的工程化处理从PCB端子到管道里的三极管远程探头作为温度传感器最终要放到管道里、机房角落里所以探头线缆的处理也是工程化的重要一环。我实际用的是24AWG双绞线外面套一层镀锡铜编织屏蔽网屏蔽网单端接地在控制器侧接地长度控制在5米以内。双绞线的作用是让两根线上的共模干扰尽量相等从而在差分测量中被抵消屏蔽网则进一步抑制差模干扰。如果只是简单的两根平行线现场干扰大的时候远程温度会跳得非常厉害。探头末端就是一颗2N3906三极管集电极和基极短接后焊在一起发射极和基极分别用热缩管做好绝缘外面再用一个空调管路常用的铜管套住铜管里灌导热胶这样探头既抗机械振动热响应也比较快。在管道上安装时要保证探头插到气流中心位置不能贴管壁否则测的是管壁温度而不是空气温度回风温度会有几度偏差。还有一个容易被忽略的点远程探头线如果和强电电缆并行走线距离至少要隔开20cm以上实在避不开就穿金属管屏蔽。我早期一个项目里把探头线和接触器控制线捆在一起结果是每次接触器吸合远程温度就跳动1°C左右排查了很久才找到原因。4. 固件架构从寄存器映射到应用逻辑的完整实现4.1 寄存器映射与底层驱动API设计PJ85718DM的寄存器结构比较直观我这里列一份实际用到的地址映射不同批次芯片可能有细节差异以手册为准。寄存器地址名称说明0x00本地温度高字节14位温度的高8位0.0625°C/LSB0x01本地温度低字节低6位有效0x02远程1温度高字节远程通道1温度高8位0x03远程1温度低字节远程通道1温度低6位0x04远程2温度高字节远程通道2温度高8位0x05远程2温度低字节远程通道2温度低6位0x06状态寄存器远程探头开路/短路标志、ALERT状态0x07配置寄存器连续转换/单次转换、比较器/中断模式0x08本地报警上限本地通道高温报警阈值0x09远程1报警上限远程1通道高温报警阈值0x0A远程1β补偿理想因子微调0x0B远程1线电阻补偿线缆串联电阻补偿设置底层驱动我封装得尽量薄核心就是读温度和读状态两个函数。读取远程1温度的核心代码大致是这样#define PJ85718DM_ADDR 0x4B #define REG_LOCAL_MSB 0x00 #define REG_REMOTE1_MSB 0x02 #define REG_STATUS 0x06 float pj_read_remote1_temp(void) { uint8_t buf[2] {0}; uint16_t raw 0; int16_t val 0; float temp 0.0f; /* 先读状态确认远程探头没有开路 */ HAL_I2C_Mem_Read(hi2c1, PJ85718DM_ADDR 1, REG_STATUS, 1, buf, 1, 100); if (buf[0] 0x04) { return -999.0f; /* 远程1开路 */ } /* 连续读远程1温度寄存器 */ HAL_I2C_Mem_Read(hi2c1, PJ85718DM_ADDR 1, REG_REMOTE1_MSB, 1, buf, 2, 100); raw ((uint16_t)buf[0] 8) | buf[1]; /* 14位结果先左移2位再用算术右移做符号扩展 */ val (int16_t)(raw 2) 2; temp (float)val * 0.0625f; return temp; }这里有个STM32用户很容易踩的细节HAL库的HAL_I2C_Mem_Read第三个参数是设备地址需要把7位地址左移1位变成8位地址格式。我第一次写的时候就忘了左移结果I2C总线一直NACK调试了半天。另外14位温度数据的符号扩展必须用算术右移不能简单把raw强制转成int16_t完事否则负温度会解析成大正数。4.2 软件滤波与两点校准把0.1°C级别的精度变成现实PJ85718DM本身输出的数据是没毛病的但到了HVAC现场干扰和机械振动会让远程通道数据出现毛刺。我用的滤波策略是中值滤波 一阶低通两级处理。中值滤波的作用是干掉偶发的采样尖峰比如变频器启动瞬间的干扰。窗口大小取5个采样点比较合适太大会让真实温度变化被抹平太小又滤不干净。一阶低通的作用是平滑连续的小幅抖动系数我一般取0.2到0.3相当于给数据一个惯性让显示和控制都更稳定。代码逻辑如下#define FILTER_WINDOW 5 static float temp_filter(float new_sample) { static float history[FILTER_WINDOW]; static float filtered 0.0f; static uint8_t init 0; static uint8_t index 0; float sorted[FILTER_WINDOW]; int i, j; history[index] new_sample; index (index 1) % FILTER_WINDOW; if (init FILTER_WINDOW) { init; filtered new_sample; return filtered; } memcpy(sorted, history, sizeof(sorted)); /* 简单插入排序窗口只有5个元素没必要用快排 */ for (i 1; i FILTER_WINDOW; i) { float key sorted[i]; j i - 1; while (j 0 sorted[j] key) { sorted[j 1] sorted[j]; j--; } sorted[j 1] key; } float median sorted[FILTER_WINDOW / 2]; filtered 0.7f * filtered 0.3f * median; return filtered; }再说校准。本地通道和远程通道出厂时都做过片内校准但系统级误差还是存在传感器周围有其他发热元件、远程探头线的串阻、探头与被测环境的换热误差等。我的做法是在生产测试时用恒温槽做两点校准把系统误差拟合成一个offset和一个斜率系数存到EEPROM里。运行时上层应用读取EEPROM里的系数对滤波后的温度做一次线性修正。这个方法比在芯片寄存器里写死offset更灵活因为同一批板子的探头线长度可能不一样。4.3 应用层温度控制、报警判定和UI刷新怎么协同固件架构上我用了FreeRTOS任务划分得很清楚读温度任务每500ms跑一次负责从PJ85718DM读取三个温度并做滤波和校准控制任务每200ms跑一次PID运算输出风机或三通阀的控制量UI任务每250ms刷新LCD显示通信任务处理RS485和以太网的Modbus请求。PID控制的策略在HVAC里要稍微讲究一点。我主要用回风温度作为主反馈量因为回风温度代表房间的平均温度送风温度作为前馈限制防止送风过冷或过热盘管防冻保护则直接比较盘管表面温度低于设定阈值就强制停机。这个架构下PJ85718DM远程通道1接回风远程通道2接送风本地通道测的是控制板板温。报警判定不能只看单次读数尤其是ALERT引脚。我现在的做法是软件里做连续3次采样都超限才确认报警这样能过滤掉绝大部分瞬时干扰。同时把PJ85718DM的报警阈值寄存器设置成比软件报警值略高3°C作为最后的硬件保护层。两层配合下来误报率大幅下降。UI刷新方面F469II的LTDC刷新RGB屏本身不占用CPU多少资源但要显示趋势曲线就得在SDRAM里准备帧缓冲和曲线数据缓冲区。我的做法是用DMA2D把温度点绘制到一个1024×300的横屏区域里每250ms滚动一个像素一分钟才滚动满一条曲线现场看趋势非常直观。这个功能如果放在没有DMA2D的MCU上CPU占用率会高不少。5. 实测数据与分析本地和远程通道在不同场景下的真实表现5.1 恒温槽标定数据误差到底能压到多少为了验证整套方案的精度我搭了一个简单的测试台恒温槽或者带搅拌的水浴作为温度源参考温度计用A级PT100经精密变送器读取PJ85718DM的本地通道和远程通道同时测量。远程探头用一颗2N3906三极管焊在探头小板上双绞线长度约1米。从0°C到100°C每隔10°C取一个点每个点稳定30分钟后记录10次平均值结果如下参考温度 (°C)本地通道读数 (°C)本地误差 (°C)远程通道读数 (°C)远程误差 (°C)0.00.080.08-0.11-0.1110.010.050.0510.120.1225.024.91-0.0925.060.0640.040.100.1040.180.1855.054.88-0.1255.020.0270.070.150.1570.240.2485.085.020.0284.95-0.05100.0100.120.1299.87-0.13这个数据说明在探头线较短、环境干净的条件下本地通道和远程通道的误差都能控制在±0.25°C以内对HVAC应用来说已经完全够用了。本地通道的误差主要来自传感器自身的自发热和PCB温度梯度远程通道的误差则主要是探头和恒温槽之间的热阻造成的。5.2 长线缆实验线电阻补偿到底有没有用接着我把远程探头换成几组不同长度的双绞线做对比测试分别是1米、3米、5米恒温槽设定在50°C观察远程通道的读数变化。线缆长度未开启补偿读数 (°C)与50°C参考的偏差 (°C)开启补偿后读数 (°C)与50°C参考的偏差 (°C)1米50.160.1650.080.083米50.420.4250.180.185米50.710.7150.240.24这个结果和理论预期基本吻合线缆越长串联电阻带来的正向偏差越大。5米未补偿时已经偏了0.7°C如果不做补偿这个偏差在控制精度要求较高的场合会被直接叠加到PID的静差里。开启线电阻补偿后5米线长的偏差被压到0.24°C效果很明显。从我实际经验看如果现场探头线长度固定也可以在固件里做一个固定offset校准效果和芯片的自动补偿类似。但前提是每次安装的线长要一致否则出厂校准的offset就不准了。工程上更稳妥的做法还是优先用芯片自带的线电阻补偿软件校准只做温度偏移。5.3 变频器干扰测试射频干扰对远程测温的危害有多大HVAC控制柜里最不缺的就是变频器和接触器所以我专门做了一次干扰对比测试。测试方法是把远程探头线放在变频器输出线旁边约2cm的位置让变频器带载运行分别记录加滤波和不加滤波的远程通道读数。不加任何滤波时远程通道读数在设定温度附近乱跳峰峰值达到±1.5°C左右完全没法用。加了我前面说的1kΩ串联电阻和100pF差分电容之后抖动降到±0.3°C。再叠加固件里的中值滤波和一阶低通最终读数稳定在±0.1°C以内。这个测试让我确认了一件事PJ85718DM的远程读取原理决定了它对射频干扰非常敏感硬件RC滤波不是可选项而是必选项。如果现场干扰特别重还可以把探头线换成屏蔽双绞线并且在控制器侧单端接地效果会更好。但一定要记住屏蔽网只能一端接地两端都接地容易形成地环路反而引入更多噪声。6. 现场调试最容易翻车的四个问题及完整排查链路6.1 I2C总线偶发挂死SCL时钟恢复法现场最让人头疼的问题之一就是I2C总线用着用着突然SDA被拉死整条总线瘫痪。排查链路是这样的先看SDA电平如果恒为低而SCL仍在翻转基本可以确定有设备把SDA锁死了。原因可能是总线上出现毛刺被从机误识别为起始或停止条件也可能是从机内部状态机跑飞。我的解决方案分两步。硬件上在SDA和SCL线上各加了一个10pF到22pF的对地电容用来吸收边沿毛刺。软件上每次读取PJ85718DM之前先检测总线忙状态如果发现SDA长时间为低就做一次SCL时钟恢复把SCL连续翻转9次让所有挂在总线上的从机从异常状态中退出然后发一个STOP条件。这个恢复逻辑写成函数在I2C返回错误码时自动调用实测能把死锁恢复成功率做到95%以上剩下的情况直接对传感器做一次硬件复位。6.2 ALERT脚频繁误报迟滞和确认机制缺一不可ALERT误报警是调试阶段很常见的错觉。刚开始我设置了远程通道80°C报警但运行过程中偶尔会触发。用逻辑分析仪抓ALERT波形后才发现报警发生在远程通道瞬时毛刺超过阈值的那一拍。排查确认后解决思路是分两层。第一层在PJ85718DM的配置寄存器里把ALERT设置为比较器模式并且配合报警迟滞寄存器把迟滞设为2°C这样瞬时毛刺即便超过上限1°C也不会触发拉低。第二层在软件里对ALERT引脚做持续确认GPIO外部中断触发了先不报而是在主循环里连续读3次状态寄存器都确认超限才在界面上弹报警否则认为是干扰自动清除。这套双保险做完之后的现场运行就再没有误报过。6.3 远程温度读数系统性偏高先分清是线电阻还是探头选型有一次现场反馈远程温度比水银温度计高了1°C多这个量已经超出正常误差范围。排查步骤我建议这样走第一步把远程探头从管道里拆出来和参考温度计一起放在恒温槽里确认探头本身没有误差。第二步如果恒温槽里读数正常装回管道后又偏高请检查探头是否贴到了管壁或者离加热器太近。第三步如果始终有固定偏差回到线缆上——用万用表量一下双绞线两端的环路电阻超过0.5Ω基本就可以确定是线电阻贡献的偏移开启PJ85718DM的线电阻补偿或者做软件offset修正。我那次的问题最终确认是探头线有一段被穿线管压伤内部断了几股铜丝导致环路电阻增大到1.2Ω。换了一根线缆后读数恢复正常。这类问题只要按照探头本身→安装位置→线缆电阻这条链路去查基本都能在半小时内定位。6.4 开机第一次读数异常等转换完成再读取系统上电后如果立刻去读PJ85718DM有可能读回一个满量程值或者0这不是芯片坏了而是芯片内部的第一次AD转换还没完成。PJ85718DM上电后有一个启动时间加上第一次转换时间通常需要几十毫秒到120ms左右。排查的方法是看数据手册里的上电时序图确认最小等待时间然后在固件里做两件事一是上电后延时200ms再初始化I2C读取二是在驱动里读状态寄存器的转换完成标志位等标志位置位后再读取温度数据。更省事的做法是软件上丢弃上电后的前两次采样只从第三次读取开始进入滤波逻辑。这个假数据丢弃技巧在温度控制和LCD显示上都适用避免开机瞬间界面跳出一个离谱数据。7. 这套方案还能怎么扩展从单板监控走向整个HVAC系统7.1 多节点扩展A0/A1地址引脚和I2C多主规划PJ85718DM一般提供A0和A1地址选择引脚可以组合成4个不同I2C地址也就是一条总线上最多挂4颗芯片。那就有能力扩展出本地8路远程的能力对应一套中型HVAC系统里常用到的八个测点例如回风、送风、盘管进出水、室外新风、机房室温等。如果需要更多的点我建议换一种组织方式每个控制区域用一个独立的F469II节点各节点之间通过RS485或以太网组网由网关汇总所有温度数据。这样比在一条I2C总线上硬堆设备可靠得多因为I2C总线的物理距离和总线电容都有限强拽十几颗芯片反而会让信号质量大幅下降。7.2 低功耗和无线化单次转换模式与远程监控如果将来要做电池供电的壁挂式温控器MCU不必一直跑在180MHz可以在每次任务周期里读取温度后立即进入STOP模式。PJ85718DM如果支持单次转换模式就按需触发一次转换读完就休眠这样能把整机平均功耗控制在很低的水准。F469II本身不是超低功耗MCU但配合STOP模式和带LCD段码屏的前提还是能接受。如果项目要从现场看变成远程看F469II自带的以太网MAC可以直接扩展出网口配合一个小型Web服务器在浏览器里就能看所有温度趋势和报警状态。极简方案下甚至可以用串口接一个4G模组或LoRa模组把温度数据定时上报到云端。7.3 与楼宇自控系统的联动Modbus RTU和BACnet协议预留HVAC项目十有八九要对接楼宇自控系统而楼宇自控行业最常问的就是你能不能出Modbus寄存器表。我的做法是在F469II的固件里预先把所有温度点、报警状态、PID输出量映射成标准的Modbus保持寄存器通过RS485口以Modbus RTU从站模式运行同时网口预留Modbus TCP或BACnet/SCADA后期扩展。这样现场集成商接入时只需要对照寄存器表做点位表不用改固件。这个扩展方向也是我当初选择F469II的重要原因——主频和RAM够大以后在固件里加协议栈、趋势存储、本地Web页面都有余量而不是刚做完基本功能就发现资源耗尽得换平台。最后再分享一点个人体会。在HVAC这种节奏快、成本敏感、现场环境又不够干净的行业温度监测方案不是越先进越好而是越简单越好。PJ85718DM这种本地远程二极管的架构最大的价值其实在于把多点测温从硬件布线和逐点校准的泥潭里捞了出来变成了一件在软件里读寄存器就能搞定的事。STM32F469II则是给了这套方案足够宽裕的后期扩展空间。如果你打算在自己的项目里复刻这条路线建议第一版就做好远程通道的RC滤波、留好ALERT引脚、把I2C总线恢复函数写进固件这几点看着不起眼真到了现场调试阶段会替你省下大把时间。 基于PJ85718DM与STM32F469II的多点温度监测方案
做了几年HVAC控制项目我最怕的不是PID调不好而是温度采不到点上。之前做过的一个风柜AHU控制项目温度传感器装在控制柜里测的是柜内温度跟回风管道里的实际温度差了四五度。PID怎么调都稳不住后来把传感器拉到管道里才恢复正常。这个经历让我养成了一个习惯凡是做温度控制一定要先想清楚测的是哪里的温度、离控制对象有多远。这次要聊的方案本质上是把这个经典问题拆成两半来解决PJ85718DM这颗芯片负责同时监测本地和远程温度STM32F469II负责跑控制、显示和通信。适用场景很明确——嵌入式设备里的板级温度监控以及HVAC场景里常见的回风温度、送风温度、盘管防冻探头这类多点监测需求。如果你正在做类似的东西这篇文章里的选型逻辑、电路细节、固件架构和踩坑记录应该能帮你少走不少弯路。1. 从HVAC现场出发为什么单个温度点根本不解决问题1.1 一个真实的项目需求是怎么落到本地远程上的HVAC系统里温度不是一个点的概念而是一组点。一套常见的中型风柜系统控制器要同时盯着回风温度代表房间平均温度、送风温度代表盘管出风的实际效果、盘管表面温度防冻结保护用、室外补风温度新风补偿用再加上控制器自身的板温判断控制柜散热是否正常。这一组温度如果各拉一根传感器线控制柜里的接线端子直接占掉一大排调试的时候光对线号就能让人崩溃。我之前用过的传统做法是NTC热敏电阻方案每个测温点一颗NTC配一个分压电阻再占用一个ADC通道。好处是便宜坏处也明显——通道数量紧张线缆一长分压误差就变大而且NTC的B值离散性使得每个通道都要单独校准。相对好一点的工业做法是每个点放一颗I2C温度芯片但这样一颗芯片只能覆盖一个点成本又上去了。所以当我把需求梳理清楚之后方案就变得很自然控制器的本地温度本身要测管道里的远程温度也要测那就找一颗自带本地测温、同时支持远程二极管测温的传感器。我手上拿到的PJ85718DM正好是这类芯片内置1路本地测温通道外接2路远程二极管通道走I2C/SMBus接口一次把三个温度点的数据全读回来。1.2 选型对比为什么是二极管测温而不是NTC或PT100在HVAC这种对成本敏感的行业温度传感器的选型其实是个权衡题。NTC便宜但需要校准PT100精度高但调理电路贵集成温度芯片省事但单点成本偏高。PJ85718DM这种本地远程二极管方案走的是另一条路远程探头本身就是一个普通三极管几分钱一颗却能做到免标定测量这是它最大的价值。我用一个实际对比表来总结当时的考量对比项NTC多路采集每点独立I2C温度芯片本地远程二极管方案单点硬件成本低NTC电阻中每点一颗芯片低一个三极管测温精度依赖校准离散性大高芯片出厂校准中高三四线制下误差可控布线复杂度每个点2根线到ADC每个点2根线I2C总线远程探头2根双绞线即可抗干扰能力易受线缆电阻影响较好对射频干扰敏感需滤波调试便利性逐个通道标定读取寄存器即可读取寄存器即可扩展性加硬件MUX换地址或加总线挂一路二极管就是一个新测点结论很直接在多测点、中精度、低成本、好调试这个交集里本地远程二极管方案是性价比比较高的选择。PJ85718DM内部其实已经在做所有模拟测量和数字化转换MCU只需要通过I2C读寄存器软件工作量比NTC方案少一大截。1.3 为什么主控选了STM32F469II这里有一个很多人会问的问题温度监测而已用STM32F103或G030不就行了吗确实单纯读温度用Cortex-M0都绰绰有余但这个项目的需求不止读温度。项目要求一块7寸RGB接口的LCD屏要实时显示三个测温点的数值和温度趋势曲线同时跑PID控制逻辑还要预留以太网口和RS485口准备接楼宇自控系统。F469II这颗芯片的定位就非常匹配180MHz主频带FPU2MB Flash、384KB SRAM内置TFT-LCD控制器LTDC内置DMA2D图形加速器还带FMC外部存储器接口可以直接外挂SDRAM做帧缓冲。等于说显示、控制、通信、人机交互全部一颗芯片搞定不用额外加串口屏模块也不用量产阶段还要单独买一颗显示驱动MCU。还有一个现实原因HVAC控制柜里温度传感器离变频器、接触器很近现场干扰严重后续如果要做软件补偿和滤波算法FPU和主频高一点会从容很多。所以主控选型这事核心是让MCU的能力覆盖项目未来两三年可能加的需求而不是只看当前几个温度点的计算量。2. 先把测温原理讲透PN结、ΔVbe和那条远程二极管2.1 两颗不同电流下的Vbe为什么能算出绝对温度很多第一次接触远程二极管测温的工程师看到用三极管测温度第一反应是离谱。但要理解PJ85718DM的远程通道必须回到PN结的物理特性。二极管的正向压降Vf会随温度变化大概每升高1°C下降2mV左右。但直接用这个绝对值测温是不行的因为Vf还受饱和电流Is影响而Is在不同二极管之间差别很大同一颗二极管在不同温度下也是指数变化。这样一来绝对Vf和温度之间没有一个统一的、稳定的关系。解决办法是比值测量法给PN结先后施加两个不同的正向电流I1和I2分别测出Vbe1和Vbe2然后计算差值。根据PN结的电流方程ΔVbe (k × T / q) × ln(I1 / I2)在这个公式里饱和电流Is被消掉了剩下的只有玻尔兹曼常数k、电荷量q、绝对温度T和电流比例。所以ΔVbe的大小只和绝对温度成正比和具体是哪颗二极管关系极小。举个数值例子如果I1 10μA、I2 100μA那么ln(I1/I2) ln(10) ≈ 2.303在25°C约298.15K时ΔVbe ≈ 86.17μV/K × 298.15K ≈ 25.7mV。芯片内部把这两个小电压精确测量并放大再通过一个带符号的12位或14位ADC转换成数字量就能以0.0625°C的LSB输出温度值。这个两个电流轮流打进去测压差的过程就是PJ85718DM远程通道的本质。也因此远程通道对测量瞬间的噪声特别敏感。如果有一个高频干扰窜进探头线采样点上的Vbe会被扰动算出来的温度自然就跳。后面我会讲怎么用硬件滤波和软件滤波一起压制这个问题。2.2 远程探头的接法三极管当二极管用而且首选费用最低的那种PJ85718DM的远程通道引出两根线通常标成D和D-要求外接一个PN结。最佳实践是用小信号三极管把集电极和基极短接在一起让发射结作为测温PN结。市面上最常见的型号就是2N3904NPN和2N3906PNP几分钱一颗参数一致性也不错。为什么不用普通的1N4148之类的二极管因为1N4148是开关二极管它的串联电阻、理想因子和Is参数相对于专用测温需求来说不够干净。而三极管的发射结面积、掺杂浓度是经过工艺优化的做出来的温度曲线更接近理论模型。另外三极管体积小、容易贴装还能直接焊在探头小板上外面套热缩管或防水壳放在管道里成本很低。接线方式要注意极性如果是PNP型三极管2N3906把发射极接到D集电极和基极短接后接到D-。如果是NPN型2N3904则发射极接D-集电极和基极短接后接D。不同芯片对探头极性的定义会略有差异以PJ85718DM的数据手册为准。我之前在这个细节上吃过亏第一次焊板时按NPN习惯接反了读回来的远程温度直接是-20°C左右的不合理数值查了半天才发现是极性接反。2.3 精度、误差模型和看似多余的补偿寄存器远程测温看起来简单但实际工程里误差源比本地测温多不少。最典型的是线缆串联电阻。远程探头用双绞线连接铜线本身有电阻比如1米24AWG双绞线大约0.08Ω5米来回就是0.8Ω左右。芯片在给二极管注入电流时这个串联电阻上也会产生压降相当于在测量回路里额外叠加了一个偏移电压最终导致温度读数偏高。好在PJ85718DM这类芯片基本都提供了线电阻补偿机制原理上是通过自动检测两个不同电流注入时的电压差来估算线阻然后在结果中减去对应的误差。这个功能在不同芯片上名字不一样有的叫TCR有的直接叫offset寄存器。实际使用中3米以内的线通常不补偿也能控制在±1°C左右超过3米建议把补偿打开或者用软件做一次两点校准。除了线电阻还有一个容易被忽略的量是理想因子β。PN结的电流方程里理想因子n并不是严格的1通常在1.01到1.05之间。不同批次三极管也会有偏差PJ85718DM的远程通道寄存器里一般有β补偿位用来微调温度系数。如果做批量产最好在出厂前用恒温槽抽测几颗探头把β值或offset封进EEPROM里。3. 硬件实现STM32F469II外设分配与传感器电路的工程化细节3.1 STM32F469II最小系统和外设资源如何分配我用的是LQFP176封装的STM32F469IIT62MB Flash、384KB SRAM180MHz主频。这个芯片把资源理顺之后整块控制板的架构非常清晰。电源方面HVAC控制柜里一般提供24V直流板上用隔离电源模块转成5V再经过低噪声LDO降到3.3V给MCU和传感器供电。F469II的模拟供电VDDA最好通过磁珠从3.3V分支出来并在VDDA引脚附近放0.1μF和10μF电容这样ADC部分不容易受到数字开关噪声干扰。F469II的外设分配大致是这样的I2C1挂PJ85718DM温度传感器时钟线SCL和数据线SDA各接4.7kΩ上拉到3.3VI2C2挂一个8Kbit的EEPROM用来存校准系数和报警历史LTDC接口接7寸RGB888液晶屏帧缓冲用一片16Mbit的SDRAM挂在FMC接口上USART1做RS485通信SDIO或者FMC的NOR接口预留将来装外部Flash存曲线数据GPIO接ALERT报警、继电器输出、按键输入。这套分配下来F469II的外设基本没有浪费也没有出现引脚冲突需要被迫改方案的状况。有一点经验是一定先把LCD屏需要的引脚锁定因为LTDC接口占用的IO非常多而且要结合引脚复用功能表仔细核对等项目做了一半再发现引脚冲突就比较痛苦了。3.2 PJ85718DM传感器电路设计去耦、上拉和RC滤波PJ85718DM本身的电路不算复杂但有些细节会直接影响远程温度的稳定性。首先供电去耦VDD引脚旁边放0.1μF陶瓷电容再并联一颗10μF钽电容或陶瓷电容尽量靠近芯片引脚。这类传感器内部有精密电流源和ADC供电纹波会直接耦合到测量结果里。SDA和SCL的I2C上拉电阻我最终选了2.2kΩ。这个值需要根据总线上的总电容来算标准模式I2C总线上拉电阻一般用4.7kΩ但如果总线上的器件多、走线长总线电容一大上升沿会变慢就需要把上拉电阻调小。我的板子上除了PJ85718DM还有一些状态显示LED驱动芯片挂在同一条I2C总线上总线电容相对偏大所以用2.2kΩ更稳妥。如果走线特别长的场合甚至可以试1kΩ但要确认芯片的灌电流能力。最关键的是远程通道的输入滤波。PJ85718DM的D和D-引脚直接连接远程双绞线现场的变频器、风机电机都是干扰源。通常做法是在靠近芯片侧的D串入一个1kΩ左右的电阻在D和D-之间并一个100pF到1nF的陶瓷电容。这个RC低通能滤掉相当一部分射频干扰。电容不是越大越好太大会让内部电流源的建立时间变长导致转换结果偏慢甚至失真我一般从100pF开始试实测干扰还压不住再加到220pF、470pF这样。3.3 远程探头线的工程化处理从PCB端子到管道里的三极管远程探头作为温度传感器最终要放到管道里、机房角落里所以探头线缆的处理也是工程化的重要一环。我实际用的是24AWG双绞线外面套一层镀锡铜编织屏蔽网屏蔽网单端接地在控制器侧接地长度控制在5米以内。双绞线的作用是让两根线上的共模干扰尽量相等从而在差分测量中被抵消屏蔽网则进一步抑制差模干扰。如果只是简单的两根平行线现场干扰大的时候远程温度会跳得非常厉害。探头末端就是一颗2N3906三极管集电极和基极短接后焊在一起发射极和基极分别用热缩管做好绝缘外面再用一个空调管路常用的铜管套住铜管里灌导热胶这样探头既抗机械振动热响应也比较快。在管道上安装时要保证探头插到气流中心位置不能贴管壁否则测的是管壁温度而不是空气温度回风温度会有几度偏差。还有一个容易被忽略的点远程探头线如果和强电电缆并行走线距离至少要隔开20cm以上实在避不开就穿金属管屏蔽。我早期一个项目里把探头线和接触器控制线捆在一起结果是每次接触器吸合远程温度就跳动1°C左右排查了很久才找到原因。4. 固件架构从寄存器映射到应用逻辑的完整实现4.1 寄存器映射与底层驱动API设计PJ85718DM的寄存器结构比较直观我这里列一份实际用到的地址映射不同批次芯片可能有细节差异以手册为准。寄存器地址名称说明0x00本地温度高字节14位温度的高8位0.0625°C/LSB0x01本地温度低字节低6位有效0x02远程1温度高字节远程通道1温度高8位0x03远程1温度低字节远程通道1温度低6位0x04远程2温度高字节远程通道2温度高8位0x05远程2温度低字节远程通道2温度低6位0x06状态寄存器远程探头开路/短路标志、ALERT状态0x07配置寄存器连续转换/单次转换、比较器/中断模式0x08本地报警上限本地通道高温报警阈值0x09远程1报警上限远程1通道高温报警阈值0x0A远程1β补偿理想因子微调0x0B远程1线电阻补偿线缆串联电阻补偿设置底层驱动我封装得尽量薄核心就是读温度和读状态两个函数。读取远程1温度的核心代码大致是这样#define PJ85718DM_ADDR 0x4B #define REG_LOCAL_MSB 0x00 #define REG_REMOTE1_MSB 0x02 #define REG_STATUS 0x06 float pj_read_remote1_temp(void) { uint8_t buf[2] {0}; uint16_t raw 0; int16_t val 0; float temp 0.0f; /* 先读状态确认远程探头没有开路 */ HAL_I2C_Mem_Read(hi2c1, PJ85718DM_ADDR 1, REG_STATUS, 1, buf, 1, 100); if (buf[0] 0x04) { return -999.0f; /* 远程1开路 */ } /* 连续读远程1温度寄存器 */ HAL_I2C_Mem_Read(hi2c1, PJ85718DM_ADDR 1, REG_REMOTE1_MSB, 1, buf, 2, 100); raw ((uint16_t)buf[0] 8) | buf[1]; /* 14位结果先左移2位再用算术右移做符号扩展 */ val (int16_t)(raw 2) 2; temp (float)val * 0.0625f; return temp; }这里有个STM32用户很容易踩的细节HAL库的HAL_I2C_Mem_Read第三个参数是设备地址需要把7位地址左移1位变成8位地址格式。我第一次写的时候就忘了左移结果I2C总线一直NACK调试了半天。另外14位温度数据的符号扩展必须用算术右移不能简单把raw强制转成int16_t完事否则负温度会解析成大正数。4.2 软件滤波与两点校准把0.1°C级别的精度变成现实PJ85718DM本身输出的数据是没毛病的但到了HVAC现场干扰和机械振动会让远程通道数据出现毛刺。我用的滤波策略是中值滤波 一阶低通两级处理。中值滤波的作用是干掉偶发的采样尖峰比如变频器启动瞬间的干扰。窗口大小取5个采样点比较合适太大会让真实温度变化被抹平太小又滤不干净。一阶低通的作用是平滑连续的小幅抖动系数我一般取0.2到0.3相当于给数据一个惯性让显示和控制都更稳定。代码逻辑如下#define FILTER_WINDOW 5 static float temp_filter(float new_sample) { static float history[FILTER_WINDOW]; static float filtered 0.0f; static uint8_t init 0; static uint8_t index 0; float sorted[FILTER_WINDOW]; int i, j; history[index] new_sample; index (index 1) % FILTER_WINDOW; if (init FILTER_WINDOW) { init; filtered new_sample; return filtered; } memcpy(sorted, history, sizeof(sorted)); /* 简单插入排序窗口只有5个元素没必要用快排 */ for (i 1; i FILTER_WINDOW; i) { float key sorted[i]; j i - 1; while (j 0 sorted[j] key) { sorted[j 1] sorted[j]; j--; } sorted[j 1] key; } float median sorted[FILTER_WINDOW / 2]; filtered 0.7f * filtered 0.3f * median; return filtered; }再说校准。本地通道和远程通道出厂时都做过片内校准但系统级误差还是存在传感器周围有其他发热元件、远程探头线的串阻、探头与被测环境的换热误差等。我的做法是在生产测试时用恒温槽做两点校准把系统误差拟合成一个offset和一个斜率系数存到EEPROM里。运行时上层应用读取EEPROM里的系数对滤波后的温度做一次线性修正。这个方法比在芯片寄存器里写死offset更灵活因为同一批板子的探头线长度可能不一样。4.3 应用层温度控制、报警判定和UI刷新怎么协同固件架构上我用了FreeRTOS任务划分得很清楚读温度任务每500ms跑一次负责从PJ85718DM读取三个温度并做滤波和校准控制任务每200ms跑一次PID运算输出风机或三通阀的控制量UI任务每250ms刷新LCD显示通信任务处理RS485和以太网的Modbus请求。PID控制的策略在HVAC里要稍微讲究一点。我主要用回风温度作为主反馈量因为回风温度代表房间的平均温度送风温度作为前馈限制防止送风过冷或过热盘管防冻保护则直接比较盘管表面温度低于设定阈值就强制停机。这个架构下PJ85718DM远程通道1接回风远程通道2接送风本地通道测的是控制板板温。报警判定不能只看单次读数尤其是ALERT引脚。我现在的做法是软件里做连续3次采样都超限才确认报警这样能过滤掉绝大部分瞬时干扰。同时把PJ85718DM的报警阈值寄存器设置成比软件报警值略高3°C作为最后的硬件保护层。两层配合下来误报率大幅下降。UI刷新方面F469II的LTDC刷新RGB屏本身不占用CPU多少资源但要显示趋势曲线就得在SDRAM里准备帧缓冲和曲线数据缓冲区。我的做法是用DMA2D把温度点绘制到一个1024×300的横屏区域里每250ms滚动一个像素一分钟才滚动满一条曲线现场看趋势非常直观。这个功能如果放在没有DMA2D的MCU上CPU占用率会高不少。5. 实测数据与分析本地和远程通道在不同场景下的真实表现5.1 恒温槽标定数据误差到底能压到多少为了验证整套方案的精度我搭了一个简单的测试台恒温槽或者带搅拌的水浴作为温度源参考温度计用A级PT100经精密变送器读取PJ85718DM的本地通道和远程通道同时测量。远程探头用一颗2N3906三极管焊在探头小板上双绞线长度约1米。从0°C到100°C每隔10°C取一个点每个点稳定30分钟后记录10次平均值结果如下参考温度 (°C)本地通道读数 (°C)本地误差 (°C)远程通道读数 (°C)远程误差 (°C)0.00.080.08-0.11-0.1110.010.050.0510.120.1225.024.91-0.0925.060.0640.040.100.1040.180.1855.054.88-0.1255.020.0270.070.150.1570.240.2485.085.020.0284.95-0.05100.0100.120.1299.87-0.13这个数据说明在探头线较短、环境干净的条件下本地通道和远程通道的误差都能控制在±0.25°C以内对HVAC应用来说已经完全够用了。本地通道的误差主要来自传感器自身的自发热和PCB温度梯度远程通道的误差则主要是探头和恒温槽之间的热阻造成的。5.2 长线缆实验线电阻补偿到底有没有用接着我把远程探头换成几组不同长度的双绞线做对比测试分别是1米、3米、5米恒温槽设定在50°C观察远程通道的读数变化。线缆长度未开启补偿读数 (°C)与50°C参考的偏差 (°C)开启补偿后读数 (°C)与50°C参考的偏差 (°C)1米50.160.1650.080.083米50.420.4250.180.185米50.710.7150.240.24这个结果和理论预期基本吻合线缆越长串联电阻带来的正向偏差越大。5米未补偿时已经偏了0.7°C如果不做补偿这个偏差在控制精度要求较高的场合会被直接叠加到PID的静差里。开启线电阻补偿后5米线长的偏差被压到0.24°C效果很明显。从我实际经验看如果现场探头线长度固定也可以在固件里做一个固定offset校准效果和芯片的自动补偿类似。但前提是每次安装的线长要一致否则出厂校准的offset就不准了。工程上更稳妥的做法还是优先用芯片自带的线电阻补偿软件校准只做温度偏移。5.3 变频器干扰测试射频干扰对远程测温的危害有多大HVAC控制柜里最不缺的就是变频器和接触器所以我专门做了一次干扰对比测试。测试方法是把远程探头线放在变频器输出线旁边约2cm的位置让变频器带载运行分别记录加滤波和不加滤波的远程通道读数。不加任何滤波时远程通道读数在设定温度附近乱跳峰峰值达到±1.5°C左右完全没法用。加了我前面说的1kΩ串联电阻和100pF差分电容之后抖动降到±0.3°C。再叠加固件里的中值滤波和一阶低通最终读数稳定在±0.1°C以内。这个测试让我确认了一件事PJ85718DM的远程读取原理决定了它对射频干扰非常敏感硬件RC滤波不是可选项而是必选项。如果现场干扰特别重还可以把探头线换成屏蔽双绞线并且在控制器侧单端接地效果会更好。但一定要记住屏蔽网只能一端接地两端都接地容易形成地环路反而引入更多噪声。6. 现场调试最容易翻车的四个问题及完整排查链路6.1 I2C总线偶发挂死SCL时钟恢复法现场最让人头疼的问题之一就是I2C总线用着用着突然SDA被拉死整条总线瘫痪。排查链路是这样的先看SDA电平如果恒为低而SCL仍在翻转基本可以确定有设备把SDA锁死了。原因可能是总线上出现毛刺被从机误识别为起始或停止条件也可能是从机内部状态机跑飞。我的解决方案分两步。硬件上在SDA和SCL线上各加了一个10pF到22pF的对地电容用来吸收边沿毛刺。软件上每次读取PJ85718DM之前先检测总线忙状态如果发现SDA长时间为低就做一次SCL时钟恢复把SCL连续翻转9次让所有挂在总线上的从机从异常状态中退出然后发一个STOP条件。这个恢复逻辑写成函数在I2C返回错误码时自动调用实测能把死锁恢复成功率做到95%以上剩下的情况直接对传感器做一次硬件复位。6.2 ALERT脚频繁误报迟滞和确认机制缺一不可ALERT误报警是调试阶段很常见的错觉。刚开始我设置了远程通道80°C报警但运行过程中偶尔会触发。用逻辑分析仪抓ALERT波形后才发现报警发生在远程通道瞬时毛刺超过阈值的那一拍。排查确认后解决思路是分两层。第一层在PJ85718DM的配置寄存器里把ALERT设置为比较器模式并且配合报警迟滞寄存器把迟滞设为2°C这样瞬时毛刺即便超过上限1°C也不会触发拉低。第二层在软件里对ALERT引脚做持续确认GPIO外部中断触发了先不报而是在主循环里连续读3次状态寄存器都确认超限才在界面上弹报警否则认为是干扰自动清除。这套双保险做完之后的现场运行就再没有误报过。6.3 远程温度读数系统性偏高先分清是线电阻还是探头选型有一次现场反馈远程温度比水银温度计高了1°C多这个量已经超出正常误差范围。排查步骤我建议这样走第一步把远程探头从管道里拆出来和参考温度计一起放在恒温槽里确认探头本身没有误差。第二步如果恒温槽里读数正常装回管道后又偏高请检查探头是否贴到了管壁或者离加热器太近。第三步如果始终有固定偏差回到线缆上——用万用表量一下双绞线两端的环路电阻超过0.5Ω基本就可以确定是线电阻贡献的偏移开启PJ85718DM的线电阻补偿或者做软件offset修正。我那次的问题最终确认是探头线有一段被穿线管压伤内部断了几股铜丝导致环路电阻增大到1.2Ω。换了一根线缆后读数恢复正常。这类问题只要按照探头本身→安装位置→线缆电阻这条链路去查基本都能在半小时内定位。6.4 开机第一次读数异常等转换完成再读取系统上电后如果立刻去读PJ85718DM有可能读回一个满量程值或者0这不是芯片坏了而是芯片内部的第一次AD转换还没完成。PJ85718DM上电后有一个启动时间加上第一次转换时间通常需要几十毫秒到120ms左右。排查的方法是看数据手册里的上电时序图确认最小等待时间然后在固件里做两件事一是上电后延时200ms再初始化I2C读取二是在驱动里读状态寄存器的转换完成标志位等标志位置位后再读取温度数据。更省事的做法是软件上丢弃上电后的前两次采样只从第三次读取开始进入滤波逻辑。这个假数据丢弃技巧在温度控制和LCD显示上都适用避免开机瞬间界面跳出一个离谱数据。7. 这套方案还能怎么扩展从单板监控走向整个HVAC系统7.1 多节点扩展A0/A1地址引脚和I2C多主规划PJ85718DM一般提供A0和A1地址选择引脚可以组合成4个不同I2C地址也就是一条总线上最多挂4颗芯片。那就有能力扩展出本地8路远程的能力对应一套中型HVAC系统里常用到的八个测点例如回风、送风、盘管进出水、室外新风、机房室温等。如果需要更多的点我建议换一种组织方式每个控制区域用一个独立的F469II节点各节点之间通过RS485或以太网组网由网关汇总所有温度数据。这样比在一条I2C总线上硬堆设备可靠得多因为I2C总线的物理距离和总线电容都有限强拽十几颗芯片反而会让信号质量大幅下降。7.2 低功耗和无线化单次转换模式与远程监控如果将来要做电池供电的壁挂式温控器MCU不必一直跑在180MHz可以在每次任务周期里读取温度后立即进入STOP模式。PJ85718DM如果支持单次转换模式就按需触发一次转换读完就休眠这样能把整机平均功耗控制在很低的水准。F469II本身不是超低功耗MCU但配合STOP模式和带LCD段码屏的前提还是能接受。如果项目要从现场看变成远程看F469II自带的以太网MAC可以直接扩展出网口配合一个小型Web服务器在浏览器里就能看所有温度趋势和报警状态。极简方案下甚至可以用串口接一个4G模组或LoRa模组把温度数据定时上报到云端。7.3 与楼宇自控系统的联动Modbus RTU和BACnet协议预留HVAC项目十有八九要对接楼宇自控系统而楼宇自控行业最常问的就是你能不能出Modbus寄存器表。我的做法是在F469II的固件里预先把所有温度点、报警状态、PID输出量映射成标准的Modbus保持寄存器通过RS485口以Modbus RTU从站模式运行同时网口预留Modbus TCP或BACnet/SCADA后期扩展。这样现场集成商接入时只需要对照寄存器表做点位表不用改固件。这个扩展方向也是我当初选择F469II的重要原因——主频和RAM够大以后在固件里加协议栈、趋势存储、本地Web页面都有余量而不是刚做完基本功能就发现资源耗尽得换平台。最后再分享一点个人体会。在HVAC这种节奏快、成本敏感、现场环境又不够干净的行业温度监测方案不是越先进越好而是越简单越好。PJ85718DM这种本地远程二极管的架构最大的价值其实在于把多点测温从硬件布线和逐点校准的泥潭里捞了出来变成了一件在软件里读寄存器就能搞定的事。STM32F469II则是给了这套方案足够宽裕的后期扩展空间。如果你打算在自己的项目里复刻这条路线建议第一版就做好远程通道的RC滤波、留好ALERT引脚、把I2C总线恢复函数写进固件这几点看着不起眼真到了现场调试阶段会替你省下大把时间。