1. 从一颗温度传感器说起为什么HVAC场景需要本地远程双路测温做嵌入式暖通空调HVAC项目的人都有一个共识温度采集看起来简单实际上是最容易翻车的环节之一。一颗传感器读数漂移两度可能就让整个楼层的温控策略跑偏远程测温链路多一个环节就可能引入几十毫秒的延迟和额外的噪声。我最近在做一个中小型商用空调控制器的方案验证核心需求很明确——既要监测设备本体的进风口温度本地又要通过有线链路读取远端房间的室温远程两路数据都要在同一个MCU上完成采集、处理和上报。选型的起点是PJ85718DM这颗温度传感芯片配合STM32F042K6这颗Cortex-M0内核的MCU。为什么是这两颗先说PJ85718DM它是一颗支持本地测温加远程二极管测温的传感器IC本地通道测的是芯片自身所处的PCB环境温度远程通道则通过外接一个二极管接法的三极管通常是低成本NPN如MMBT3904来感知远端位置的温度。这种一颗芯片管两路的架构在HVAC控制器里非常实用——主板上的本地温度用来做冷热源侧的补偿远程温度用来做房间侧的闭环控制。STM32F042K6这边48MHz主频、32KB Flash、6KB RAM带I2C和CAN外设封装小巧成本控制得住。对于只需要处理两路温度、几路继电器输出和一路通信的控制器来说资源刚好够用不会浪费。我试过用更高端的F1系列来做同样的事结果发现大部分外设都闲着纯属浪费BOM成本。这篇文章面向的是正在做HVAC控制器、嵌入式温度采集模块或者任何需要本地远程双路测温方案的工程师。我会把从硬件连接到寄存器配置、从温度换算到误差校准的完整链路拆开讲包括我在实测中踩过的几个坑。不管你是刚接触温度传感器的新手还是做过几轮项目想优化精度的老手应该都能找到有用的东西。2. PJ85718DM的测温机制本地通道和远程通道到底怎么工作2.1 本地测温的物理原理与数据格式PJ85718DM的本地温度通道本质上是一个带隙基准温度传感器。芯片内部有一个与绝对温度成正比PTAT的电流源这个电流经过一个高精度ADC转换成数字量。芯片出厂时会在室温下做一次校准把校准系数存在内部寄存器里所以上电后直接读寄存器就能拿到温度值不需要用户自己做两点校准。数据格式上本地温度寄存器是11位有效数据加符号位分辨率是0.125°C。什么意思呢就是最低位代表0.125度读出来的原始值乘以0.125就是摄氏度。比如读到0x0640换算成十进制是1600乘以0.125等于200但要注意符号位和补码的处理——如果是负温度高字节的最高位是1需要按补码规则转换。我见过有工程师直接把原始值当无符号数算结果零下环境测出来是两百多度排查了半天才发现是符号位没处理。本地通道的测温范围是-40°C到125°C精度在0°C到85°C区间内是±1°C全温区±2°C。这个精度对于HVAC应用足够了因为房间温度控制的死区通常都设在±0.5°C以上传感器本身±1°C的误差在系统层面可以通过软件补偿来收敛。2.2 远程通道的二极管测温法与串联电阻补偿远程通道是这颗芯片真正有意思的地方。它通过两个引脚D和D-外接一个二极管接法的三极管利用三极管基极-发射极电压VBE与温度的关系来测温。具体来说芯片会交替注入两个不同大小的电流比如10μA和100μA测量两次VBE的差值ΔVBE。根据半导体物理ΔVBE (kT/q) × ln(N)其中N是电流比k是玻尔兹曼常数q是电子电荷T是绝对温度。这个ΔVBE与温度成严格的正比关系而且因为是两个电流下的差值三极管本身的饱和电流Is被消掉了所以对三极管的个体差异不敏感。但这里有个坑D和D-引脚到三极管之间如果走线太长线路电阻会引入额外的压降导致测温偏高。PJ85718DM支持串联电阻补偿内部有一个补偿寄存器可以抵消掉一定范围的线路电阻影响。我实测过用0.1mm线径的走线拉两米线路电阻大约0.7欧姆如果不补偿读数会偏高约1.5°C。补偿的方法是在寄存器里写入估计的电阻值芯片会在计算时自动扣除。远程测温的范围是-40°C到150°C精度在25°C到100°C区间是±1°C比本地通道略宽但精度相当。HVAC场景里远程探头通常放在回风口或者房间墙壁上温度范围不会太极端这个指标完全够用。2.3 两路通道的采样时序与更新速率PJ85718DM内部有一个状态机按照配置的速率轮流采样本地和远程通道。转换速率可以通过配置寄存器设置从每秒1次到每秒8次不等。对于HVAC应用温度变化本身很慢每秒1次足够了设太快反而增加功耗和自热。这里要注意自热效应。芯片工作时自身会发热如果采样速率太高芯片温度会略高于环境温度导致本地通道读数偏高。我实测在每秒8次的速率下芯片自热大约0.3°C降到每秒1次自热降到0.1°C以内。所以如果不是需要快速响应的场景建议把速率设低一些。两路通道的数据分别存在不同的寄存器里MCU读取时要注意先读高字节再读低字节避免在读取过程中数据更新导致高低字节不匹配。PJ85718DM支持一种读锁存机制读取高字节时会锁存低字节读完低字节后自动解锁这样就能保证数据一致性。这个细节在数据手册里写得不太显眼但实际用起来很关键。3. STM32F042K6侧的I2C驱动与寄存器操作实战3.1 硬件连接与上拉电阻的取值计算PJ85718DM通过I2C接口和STM32F042K6通信标准模式100kHz或快速模式400kHz都支持。硬件连接上SDA和SCL各需要一颗上拉电阻接到3.3V。上拉电阻的取值不是随便选的要根据总线电容和通信速率来算。I2C总线的上升时间要求是标准模式不超过1000ns快速模式不超过300ns。上升时间t 0.847 × R × C其中R是上拉电阻C是总线总电容。假设总线电容估计为100pF包括PCB走线、引脚电容和器件电容快速模式下要求t ≤ 300ns则R ≤ 300ns / (0.847 × 100pF) ≈ 3.5kΩ。所以快速模式下上拉电阻不能超过3.5kΩ常用2.2kΩ或3.3kΩ。标准模式下可以放宽到10kΩ。我一般用4.7kΩ做标准模式2.2kΩ做快速模式。但要注意上拉电阻越小总线空闲时流过上拉的电流越大功耗越高。对于电池供电的场景需要在速率和功耗之间权衡。HVAC控制器通常是市电供电这点功耗无所谓所以直接用2.2kΩ跑400kHz。STM32F042K6的I2C引脚是PB6SCL和PB7SDA需要配置为复用开漏模式并且使能内部上拉虽然外部已经有上拉了内部上拉可以增加一点裕量但不要依赖内部上拉它的阻值太大约40kΩ驱动能力不够。3.2 初始化代码从时钟使能到I2C参数配置STM32F042K6的I2C初始化有几个关键参数时钟频率、占空比、自身地址、应答控制等。下面是我实际用的初始化代码基于标准外设库风格用寄存器操作的方式写方便理解每一步在做什么。// 使能GPIOB和I2C1时钟 RCC-AHBENR | RCC_AHBENR_GPIOBEN; RCC-APB1ENR | RCC_APB1ENR_I2C1EN; // 配置PB6(SCL)和PB7(SDA)为复用开漏模式 GPIOB-MODER ~(GPIO_MODER_MODER6 | GPIO_MODER_MODER7); GPIOB-MODER | (GPIO_MODER_MODER6_1 | GPIO_MODER_MODER7_1); // 复用模式 GPIOB-OTYPER | (GPIO_OTYPER_OT_6 | GPIO_OTYPER_OT_7); // 开漏输出 GPIOB-OSPEEDR | (GPIO_OSPEEDR_OSPEEDR6 | GPIO_OSPEEDR_OSPEEDR7); // 高速 GPIOB-AFR[0] | (1 4) | (1 8); // PB6-AF1(I2C1_SCL), PB7-AF1(I2C1_SDA) // I2C1复位 I2C1-CR1 | I2C_CR1_SWRST; I2C1-CR1 ~I2C_CR1_SWRST; // 配置时钟48MHz PCLK目标400kHz // CCR PCLK / (2 * 目标频率) 48MHz / (2 * 400kHz) 60 I2C1-CCR 60; // 上升时间最大300nsTRISE (300ns / (1/48MHz)) 1 15.4 - 16 I2C1-TRISE 16; // 使能I2C I2C1-CR1 | I2C_CR1_PE;这段代码里最容易出错的是CCR的计算。STM32F042的I2C是旧版外设CCR的计算公式是PCLK / (2 × 目标频率)而不是新版I2C的PCLK / 目标频率。我一开始按新版的公式算结果通信速率只有200kHz虽然也能通但没跑到预期速率。后来查了参考手册才发现这个差异。TRISE的计算也要注意它是以PCLK周期为单位的上升时间加1。48MHz下每个周期约20.8ns300ns对应约14.4个周期加1取整为16。如果TRISE设小了高速通信时波形会畸变导致通信失败。3.3 读写PJ85718DM寄存器的完整流程PJ85718DM的I2C从机地址是0x487位地址写操作时地址字节是0x90读操作是0x91。寄存器地址是8位的每个寄存器16位数据高字节在前。写寄存器的流程是发送起始条件 → 发送从机地址写 → 发送寄存器地址 → 发送数据高字节 → 发送数据低字节 → 发送停止条件。读寄存器的流程是发送起始条件 → 发送从机地址写 → 发送寄存器地址 → 发送重复起始条件 → 发送从机地址读 → 读取高字节 → 读取低字节 → 发送停止条件。下面是我封装的两个函数用轮询方式实现没有用中断或DMA因为温度采集对实时性要求不高轮询足够且代码简单。// 写16位寄存器 uint8_t PJ85718_WriteReg(uint8_t reg, uint16_t data) { uint32_t timeout; // 发送起始条件 I2C1-CR1 | I2C_CR1_START; timeout 10000; while (!(I2C1-SR1 I2C_SR1_SB)) { if (--timeout 0) return 1; } // 发送从机地址写 I2C1-DR 0x90; timeout 10000; while (!(I2C1-SR1 I2C_SR1_ADDR)) { if (--timeout 0) return 2; } (void)I2C1-SR2; // 清除ADDR标志 // 发送寄存器地址 I2C1-DR reg; timeout 10000; while (!(I2C1-SR1 I2C_SR1_TXE)) { if (--timeout 0) return 3; } // 发送数据高字节 I2C1-DR (data 8) 0xFF; timeout 10000; while (!(I2C1-SR1 I2C_SR1_TXE)) { if (--timeout 0) return 4; } // 发送数据低字节 I2C1-DR data 0xFF; timeout 10000; while (!(I2C1-SR1 I2C_SR1_BTF)) { if (--timeout 0) return 5; } // 发送停止条件 I2C1-CR1 | I2C_CR1_STOP; return 0; } // 读16位寄存器 uint8_t PJ85718_ReadReg(uint8_t reg, uint16_t *data) { uint32_t timeout; // 发送起始条件 I2C1-CR1 | I2C_CR1_START; timeout 10000; while (!(I2C1-SR1 I2C_SR1_SB)) { if (--timeout 0) return 1; } // 发送从机地址写 I2C1-DR 0x90; timeout 10000; while (!(I2C1-SR1 I2C_SR1_ADDR)) { if (--timeout 0) return 2; } (void)I2C1-SR2; // 发送寄存器地址 I2C1-DR reg; timeout 10000; while (!(I2C1-SR1 I2C_SR1_TXE)) { if (--timeout 0) return 3; } // 发送重复起始条件 I2C1-CR1 | I2C_CR1_START; timeout 10000; while (!(I2C1-SR1 I2C_SR1_SB)) { if (--timeout 0) return 4; } // 发送从机地址读 I2C1-DR 0x91; timeout 10000; while (!(I2C1-SR1 I2C_SR1_ADDR)) { if (--timeout 0) return 5; } (void)I2C1-SR2; // 准备接收两个字节 I2C1-CR1 | I2C_CR1_ACK; // 等待第一个字节 timeout 10000; while (!(I2C1-SR1 I2C_SR1_RXNE)) { if (--timeout 0) return 6; } *data (I2C1-DR 8) 0xFF00; // 清除ACK准备接收最后一个字节 I2C1-CR1 ~I2C_CR1_ACK; // 等待第二个字节 timeout 10000; while (!(I2C1-SR1 I2C_SR1_RXNE)) { if (--timeout 0) return 7; } *data | I2C1-DR 0xFF; // 发送停止条件 I2C1-CR1 | I2C_CR1_STOP; return 0; }这两个函数里超时机制是必须的。I2C总线如果因为干扰或者从机异常导致时钟被拉低轮询会死循环。加超时后函数会返回错误码上层可以决定重试还是报警。我实际项目中遇到过传感器上电时序不对导致I2C无应答的情况有了超时就能检测到并重新初始化。读函数里有一个细节接收最后一个字节前要清除ACK然后发停止条件。如果忘了清ACK从机会继续发下一个字节导致总线卡住。这个坑我在早期调试时踩过现象是读一次之后总线就死了必须断电重启。4. 温度换算、校准与误差处理从原始码到可信读数4.1 本地温度与远程温度的换算公式本地温度的换算前面提过原始值乘以0.125就是摄氏度。但要注意数据是13位还是11位的问题。PJ85718DM的本地温度寄存器是16位其中高13位有效低3位保留。实际有效数据是13位包括符号位。换算时先取高13位然后判断符号位如果是负数按补码转成有符号整数再乘以0.125。远程温度的换算稍微复杂一点。远程通道的原始数据是14位有效分辨率也是0.125°C但它的编码方式不同。远程温度寄存器的高14位是数据低2位保留。数据是以0.125°C为单位的无符号数但有一个偏移量。具体来说远程温度 原始值 × 0.125 - 64。这个偏移量是因为远程通道的测量范围从-64°C开始原始值0对应-64°C。我一开始没注意这个偏移直接把原始值乘以0.125结果室温25度测出来是89度差了64度。后来翻数据手册才发现这个偏移。所以远程温度的换算一定要记得减64。4.2 串联电阻补偿寄存器的实际配置方法远程通道的串联电阻补偿是通过一个叫远程电阻补偿的寄存器来配置的。这个寄存器写入的值代表估计的线路电阻单位是欧姆范围0到100欧姆步进约0.5欧姆。芯片在计算时会根据这个值扣除线路电阻引入的误差。怎么估计线路电阻如果你知道走线的长度、线径和材质可以算出来。铜的电阻率是0.0175 Ω·mm²/m假设走线长2米线径0.2mm截面积约0.0314mm²则单线电阻 0.0175 × 2 / 0.0314 ≈ 1.1欧姆。D和D-各一根总共约2.2欧姆。但实际影响测温的是D和D-之间的电阻差如果两根线等长同径差值为零理论上不需要补偿。但实际走线很难完全对称所以还是会有残余误差。更实用的方法是用已知温度校准。把远程三极管放在一个已知温度的恒温槽里比如25°C读出差值然后反推需要的补偿值。我一般先不补偿读一次然后根据偏差调整补偿寄存器迭代两三次就能收敛到±0.2°C以内。补偿寄存器的地址是0x0B写入的值是估计电阻的整数部分。比如估计2欧姆就写2。注意这个寄存器是8位的不是16位写的时候只写一个字节。4.3 实测中的噪声抑制与滑动平均滤波温度读数难免有噪声尤其是远程通道因为三极管的引线可能拾取环境噪声。我在实测中观察到不滤波的情况下远程温度读数会在±0.5°C范围内跳动。对于HVAC控制来说这个跳动会导致继电器频繁动作缩短寿命。最简单的滤波是滑动平均。我一般取8个采样点做平均这样噪声能降到±0.1°C以内而且响应延迟只有8秒按每秒1次采样算对温度控制来说完全可以接受。滑动平均的实现很简单用一个环形缓冲区存最近8次读数每次新数据进来就替换最旧的数据然后求平均。#define FILTER_SIZE 8 static int32_t temp_buf[FILTER_SIZE]; static uint8_t buf_idx 0; static uint8_t buf_full 0; int32_t Filter_Temperature(int32_t new_temp) { int32_t sum 0; uint8_t i; temp_buf[buf_idx] new_temp; buf_idx (buf_idx 1) % FILTER_SIZE; if (buf_idx 0) buf_full 1; uint8_t count buf_full ? FILTER_SIZE : buf_idx; for (i 0; i count; i) { sum temp_buf[i]; } return sum / count; }如果噪声特别大可以考虑中值滤波加滑动平均的组合。先取3个点取中值再做8点滑动平均。这样能同时抑制脉冲噪声和高频噪声。但中值滤波需要排序代码量稍大对于F042K6这种小资源MCU如果RAM紧张可以只用滑动平均。还有一个硬件层面的降噪技巧在远程三极管的D和D-引脚附近各加一颗100nF的电容到地能有效滤掉高频干扰。但电容不能太大否则会影响芯片注入电流的建立时间导致测温不准。100nF是我实测下来比较合适的值再大就开始影响精度了。5. 本地与远程数据的协同处理HVAC控制策略中的温度融合5.1 两路温度的角色分工与优先级在HVAC控制器里本地温度和远程温度不是简单的二选一而是各有分工。本地温度反映的是控制器安装位置的环境温度通常靠近回风口或者设备间用来做设备保护比如防止蒸发器结冰和冷热源侧的负荷估算。远程温度反映的是被控房间的实际温度是闭环控制的反馈量。我通常的策略是远程温度作为主控温度用于PID调节本地温度作为辅助用于限幅和保护。比如当远程温度传感器故障读数超范围或变化率异常时自动切换到本地温度作为后备同时上报故障。这样即使远程探头坏了系统还能降级运行不会完全失控。优先级上远程温度正常时权重100%本地温度只做监测远程温度异常时本地温度接管但控制精度会下降因为本地温度不等于房间温度。这时候可以给用户发一个维护提醒但不影响基本运行。5.2 远程传感器故障检测的三种判据远程传感器故障怎么判断我总结了三种判据实际项目中组合使用。第一种是范围判据。远程温度的合理范围是-40°C到125°C如果读数超出这个范围直接判故障。但要注意传感器开路时读数会跑到极端值比如150°C以上短路时可能读到-64°C偏移后的零点这两种情况都能被范围判据捕获。第二种是变化率判据。温度变化是连续的如果两次采样之间变化超过5°C很可能是干扰或故障。正常HVAC场景下温度变化率不会超过1°C每分钟。所以如果1秒内变化超过5°C可以判为异常连续3次异常则确认故障。第三种是合理性判据。本地温度和远程温度虽然不等但应该在同一气候区域内差值不会太离谱。如果本地25°C远程读到80°C那远程肯定有问题。我一般设差值阈值为30°C超过就报警。这三种判据组合起来能覆盖绝大多数故障场景。误报率也低我实测跑了三个月没有出现过误报。5.3 温度数据的上报格式与通信协议设计温度数据最终要上报给上位机或者云端。上报格式我一般用简单的二进制协议两个字节表示一个温度值高字节在前单位是0.1°C有符号数。比如25.3°C表示为0x00FD253-10.5°C表示为0xFF97-105的补码。为什么用0.1°C而不是0.125°C因为0.1°C更符合人的阅读习惯而且上位机解析时不用做额外的换算。虽然传感器分辨率是0.125°C但上报时四舍五入到0.1°C精度损失可以忽略。通信协议上如果是有线RS485可以用Modbus RTU温度寄存器直接映射到保持寄存器里。如果是CAN总线可以自定义报文每帧8字节前两字节是本地温度接着两字节是远程温度再两字节是状态字最后两字节保留。STM32F042K6自带CAN外设用起来很方便。我实际项目中用的是CAN因为HVAC控制器通常挂在同一个CAN网络上和风机、阀门控制器共享总线。CAN的差分信号抗干扰能力强适合楼宇环境的长距离通信。波特率设125kbps总线长度可以到500米足够覆盖一般楼层。6. 调试与验证几个让我印象深刻的踩坑记录6.1 上电后I2C无应答电源时序与复位引脚的处理第一批样板回来上电后MCU读PJ85718DM一直超时示波器看SDA和SCL都有波形但从机就是不拉低SDA应答。排查了半天最后发现是PJ85718DM的复位引脚RESET悬空了。这颗芯片的复位引脚是低电平复位内部有上拉但悬空时容易受干扰导致芯片一直处于复位状态。解决办法很简单在复位引脚上加一颗10kΩ上拉到3.3V再并一颗100nF到地。这样上电时复位引脚被可靠拉高芯片正常启动。这个坑让我养成了一个习惯任何芯片的复位引脚不管手册说内部有没有上拉都外部加一颗上拉电阻成本几分钱省去几小时的调试时间。还有一个相关的问题是电源时序。PJ85718DM的供电范围是2.7V到5.5VSTM32F042K6是2.0V到3.6V。如果两者用同一个3.3V电源上电时序基本一致没问题。但如果传感器用5V供电MCU用3.3V就要注意I2C电平匹配。PJ85718DM的I2C引脚是开漏的可以拉到5V但STM32F042K6的引脚不耐5V需要加电平转换或者用分压电阻。我一般统一用3.3V供电省去电平转换的麻烦。6.2 远程温度读数偏高从走线电阻到补偿寄存器的排查链路前面提到远程温度偏高的问题我实际遇到过一次偏差3°C的情况。排查过程是这样的先确认三极管本身没问题换了一颗新的偏差依旧然后检查走线发现D和D-的走线长度差了将近一倍D绕了一个大弯。这就导致两根线的电阻不对称引入了额外的误差。重新布线让D和D-等长且靠近偏差降到1°C左右。然后启用串联电阻补偿写入估计的电阻值偏差进一步降到0.3°C以内。最后用滑动平均滤波读数稳定在±0.1°C。这个排查链路的关键是先排除硬件不对称再考虑补偿。如果走线本身差太多补偿寄存器也救不回来因为补偿是假设两根线电阻相等、只补偿共模电阻的。所以PCB布局时一定要让D和D-等长最好并行走线减少不对称。6.3 长时间运行后的数据漂移自热效应与PCB布局的影响有一个项目跑了半年后客户反馈温度读数比实际偏高约1°C。我去现场排查发现控制器安装在密闭的电气柜里柜内温度比柜外高5°C。本地温度测的是柜内温度自然偏高。远程温度探头在柜外读数正常。但控制策略用的是本地温度做补偿导致整体控制偏高。解决办法是把本地温度只用于设备保护不参与房间温度控制。房间控制完全依赖远程温度。同时建议客户改善电气柜的通风降低柜内温升。调整后控制精度恢复到±0.5°C。这个案例说明本地温度虽然方便但它测的是控制器所在位置的温度不一定代表被控环境的温度。在HVAC应用里远程温度才是控制的核心本地温度是辅助。设计控制策略时一定要明确这一点否则容易出系统性偏差。还有一个自热效应的问题。PJ85718DM在连续工作时芯片自身会发热尤其是供电电压较高时。我实测在5V供电、每秒8次采样的情况下芯片自热约0.5°C。如果本地温度用于精密测量这个自热必须考虑。解决办法是降低采样速率、降低供电电压或者在软件里减去一个固定的自热偏移。我一般用3.3V供电、每秒1次采样自热控制在0.1°C以内基本可以忽略。6.4 用已知温度源做两点校准的实操步骤如果对精度要求特别高可以做两点校准。准备一个恒温槽或者冰水混合物0°C和沸水100°C注意海拔影响把远程三极管放进去读出差值然后计算校准系数。具体步骤先把三极管放在冰水混合物里等读数稳定后记录原始值R0再放到沸水里记录原始值R100。理论上R100 - R0应该等于100 / 0.125 800。如果实际差值不是800说明传感器的增益有偏差需要在校准系数里修正。修正公式是实际温度 (原始值 - R0) × (100 / (R100 - R0))。本地通道的校准类似但本地通道测的是芯片自身温度没法单独把芯片放进恒温槽。所以本地通道一般不做两点校准依赖出厂校准即可。如果一定要校准可以把整个板子放进恒温箱做多点校准但成本较高一般项目没必要。我在一个高精度项目里做过远程通道的两点校准校准后精度从±1°C提升到±0.3°C。但校准过程比较耗时需要稳定的温度源和足够长的稳定时间至少10分钟。对于大多数HVAC应用出厂校准加软件补偿已经足够不需要额外做两点校准。7. 方案扩展从单点测温到多点分布式监测7.1 用模拟开关扩展多路远程测温通道PJ85718DM只有一路远程通道如果要在多个房间布点怎么办一个办法是用模拟开关比如CD4051切换多个三极管分时复用同一路远程通道。CD4051是8选1的模拟开关导通电阻约100欧姆会引入额外的串联电阻需要在补偿寄存器里扣除。具体接法是8个三极管分别接到CD4051的8个输入通道CD4051的公共输出接到PJ85718DM的D和D-。MCU通过3根GPIO控制CD4051的通道选择。每次切换通道后等待一段时间让注入电流稳定再读取温度。8个通道轮询一遍按每秒1次的速率每个通道约8秒更新一次。对于房间温度监测来说8秒的更新周期完全可以接受。这个方案的优点是成本低一颗传感器加一颗模拟开关就能管8个点。缺点是分时复用不能同时测量而且模拟开关的导通电阻会引入误差需要仔细补偿。我在一个8房间的办公楼项目里用过这个方案实测各通道之间的一致性在±0.5°C以内满足需求。7.2 多颗传感器挂同一I2C总线的地址配置如果不想用模拟开关也可以挂多颗PJ85718DM在同一I2C总线上。这颗芯片的I2C地址可以通过地址引脚配置支持4个不同地址0x48、0x49、0x4A、0x4B。所以一条总线最多挂4颗实现4路本地加4路远程共8个测温点。地址配置是通过一个引脚A0、A1接高或接低来实现的。具体对应关系看数据手册的地址表。挂多颗时要注意总线电容每颗芯片的引脚电容约10pF4颗加起来40pF加上走线电容总电容可能超过100pF。这时候上拉电阻要相应减小保证上升时间满足要求。多颗传感器的读取流程和单颗一样只是每次要指定不同的从机地址。我一般把4颗传感器的数据放在一个结构体数组里轮询读取然后统一滤波和上报。这个方案比模拟开关方案更简单不需要额外的切换逻辑但成本稍高而且受限于4个地址。7.3 与上位机联动的温度报警与联动控制逻辑温度数据采集上来后最终要用于控制。我一般设三级报警预警、报警、紧急。预警是温度超过设定值2°C只上报不动作报警是超过5°C启动风机或阀门调节紧急是超过10°C直接切断设备并上报故障。联动控制逻辑上远程温度用于PID调节输出控制风机转速或阀门开度。本地温度用于限幅比如当本地温度超过60°C时强制降低风机转速保护设备。两路温度都参与逻辑判断但优先级不同。PID参数整定是个经验活。HVAC系统的热惯性大PID的积分时间要设长一些一般几分钟到十几分钟。微分时间可以设短一些或者不用因为温度噪声会影响微分项。我一般用PI控制不用D参数根据房间大小和风量来调。小房间响应快积分时间短一些大房间热惯性大积分时间长一些。实际调试时我先把积分时间设得很长比如30分钟只让比例项起作用观察系统响应。然后逐渐减小积分时间直到系统能在设定值附近稳定且超调不超过1°C。这个过程需要耐心一般要调几个小时。但调好之后系统能稳定运行温度波动控制在±0.5°C以内。温度监测这块从传感器选型到MCU驱动从数据换算到滤波校准再到控制策略和故障处理每个环节都有细节。PJ85718DM加STM32F042K6这个组合在HVAC应用里算是性价比很高的方案硬件成本低软件资源够用精度满足需求。我在多个项目里用过这个组合稳定性不错值得推荐给做类似应用的同行。