STM32F334R8与PJ85718DM双路温度监测方案详解

前一阵子朋友问我要一套能同时看本地控制板和远端风管温度的小方案我顺手用 STM32F334R8 和 PJ85718DM 搭了一版。这颗 MCU 很多人只把它当数字电源控制器其实用在嵌入式和 HVAC 温度监测场景下也很顺手。整套东西不复杂但把本地温度和远程温度分开处理时有不少细节值得记下来。这篇文章就是这次实操过程的完整记录从需求拆解、硬件连法、固件处理到踩坑排查一条线讲清楚适合正在做温控、HVAC 控制器、设备状态监测的开发者参考也适合刚接触数字温度传感器和 STM32 的入门朋友抄作业。1. 项目需求与方案架构1.1 本地温度与远程温度差的不只是距离先说清楚为什么要在同一个系统里同时测本地和远程两个温度。本地温度通常指控制板所在位置的温度比如嵌入式设备的机箱内部、MCU 附近的空气温度或者是 HVAC 控制器的线路板温度。这个值主要用来做设备自身保护板子附近温度过高时要及时告警或降频避免元器件老化加速。远程温度则是离控制器有一定距离的测温点比如风管内部、回风口、送风口、室外补偿温度或者某个设备表面的运行温度。这个值才是 HVAC 系统真正关心的环境参数用来判断制冷/制热负载、调节风机转速、控制阀门开度。在实际项目中本地温度和远程温度往往变化规律完全不同。控制板附近因为有电源、驱动器和 MCU 自身发热温度可能比环境高好几度而且散热条件差时升温很快远程测温点则更接近真实环境温度波动平缓滞后明显。如果只装一个传感器放在板端就测不准环境拉到远端就丢了设备保护数据。所以最省事又可靠的做法就是一颗 MCU 同时管理两路传感器一路放在本地一路通过线缆延伸到远端。方案选型时也考虑过用热敏电阻加上 MCU 内置 ADC但那样每个通道都要做分压电阻匹配、线性化校准、ADC 参考电压换算环境温度变化范围一大精度就不好保证。数字温度传感器把模拟前端、ADC、校准逻辑都封装进去了MCU 只需要通过通信接口读寄存器精度由器件本身保证代码和维护成本低很多。这个项目最终确定用 PJ85718DM 做传感器一颗放在板端做本地监测一颗通过单总线模式拉到远程两颗型号相同连驱动代码都可以复用。1.2 一颗 MCU 吃下两路采集STM32F334R8 靠什么STM32F334R8 这颗芯片在圈子里通常被归到数字电源控制方向因为它集成了一组高分辨率定时器 HRTIM做 LLC、PFC、电机控制很合适。但它的通用外设也很全多路 I2C、SPI、UART、CAN还有丰富的 GPIO、12 位 ADC 和比较器Cortex-M4F 内核带浮点单元主频最高 72MHz。把它的 HRTIM 放在一边单纯跑温度采集、逻辑控制、通信上报性能绰绰有余。选它还有几个实际考虑。第一工作温度范围宽工业级版本能在比较恶劣的环境长期跑符合 HVAC 控制器的应用场景。第二GPIO 耐压是 5V 容忍的远程单总线传感器如果线路较长、存在感应干扰IO 口不容易一上来就烧坏。第三它有完整的低功耗模式用电池供电的温控面板也能做休眠唤醒。第四HAL 库和底层代码生态成熟调 I2C、配定时器、做串口打印都很快。很多人会问测个温度为什么要用带浮点单元和高级定时器的 MCU我的理解是设计硬件不用把资源压到极限。F334R8 价格并不离谱留出 HRTIM 资源意味着后续可以用它驱动风机 PWM、做比例阀控制甚至扩展成一套完整的 HVAC 控制器而不是只做温度采集就废掉一颗芯片。这也是嵌入式方案里很常见的思路——预留扩展能力给产品迭代留空间。1.3 PJ85718DM 在方案里的角色与选型思考PJ85718DM 是一颗数字温度传感器我用的这颗支持两种通信模式本地通道走 I2C远程通道走单总线模式。同一颗芯片做两用物料清单上只存在一种传感器采购和管理都方便。器件测量范围覆盖 -40 到 125 摄氏度分辨率做到 0.0625 摄氏度典型精度在正负 0.5 摄氏度以内对 HVAC 应用来说完全够用。I2C 模式下它挂在总线上有自己的地址适合板内短距离通信单总线模式下只需要一根数据线加电源和地远程布线非常好拉。选型时其实考虑过几种方案。PT100 铂电阻精度最高但要外加恒流源和调理电路成本高、占面积不适合这种双通道低成本监测板。NTC 热敏电阻成本极低但每个温度区间都要查表或者拟合公式批量生产时要逐个校准麻烦。常见的单总线温度传感器方案也能做但我这次因为手里正好有 PJ85718DM 的样品功耗指标又比同类略好一些就定了它。如果你的项目里用其他数字温度传感器思路是完全一致的只需要改驱动层命令和寄存器地址。这里想提醒一句数字温度传感器的数据手册里通常有两类参数最值得关注一是工作温度范围和精度曲线二是转换时间。转换时间决定了读取频率上限比如单总线模式转换时间 750ms那么 1 秒刷新一次是比较合理的调度节奏强行读得再快也拿不到新数据反而浪费总线带宽。2. 硬件连接与采样链路搭建2.1 引脚规划与通信接口细节STM32F334R8 有 64 个引脚管脚资源充裕但布局时还是要有意识地把接口分开方便走线和后期调试。我这版规划是这样的本地 PJ85718DM 用 I2C1 接口数据线 SDA 和时钟线 SCL 挂在 PB7 和 PB6 上这是 I2C1 的默认复用功能省去复杂的 AF 重映射配置远程 PJ85718DM 用单总线模式数据线 DQ 接到 PA1设置为开漏输出。串口调试用 PA2/PA3预留 UART1方便打印温度数据和调试信息。I2C 模式和单总线模式的引脚分布如下表有兴趣直接照抄也行。功能引脚模式说明本地传感器 SCLPB6复用开漏I2C1 时钟外接 2.2k 上拉本地传感器 SDAPB7复用开漏I2C1 数据外接 2.2k 上拉远程传感器 DQPA1GPIO 开漏单总线数据线外接 4.7k 上拉调试串口 TXPA2复用推挽UART1 发送调试串口 RXPA3复用上拉输入UART1 接收I2C 总线的上拉电阻阻值需要根据总线长度和节点数量选。板内走线很短两个传感器直接焊在主板上我用 2.2k 上拉到 3.3V实测波形干净。如果总线上挂的设备变多比如超过 4 个建议把电阻降到 1.5k 左右避免边沿太缓影响通信时序。单总线模式则注意 DQ 线上接 4.7k 上拉。远程线缆比较长时总线电容变大上拉电阻太小会把低电平拉不低太大又会让上升沿变慢具体阻值要根据线长微调。3 米以内的线缆用 4.7k 基本稳妥5 米以上建议换 2.2k 并在远端并一个小电容下面会细说。2.2 本地监测的最小电路与 PCB 布板本地传感器和 MCU 在同一块板上电路很简单。PJ85718DM 的 VCC 接 3.3VGND 接系统地SDA 和 SCL 各自通过上拉电阻到 VCC。VCC 和 GND 之间靠近传感器引脚放 100nF 的滤波电容这个电容非常重要能滤掉电源线上的高频噪声避免温度数据跳变。布板时有几个经验值得分享。首先传感器不要直接挨着 MCU 的晶振或者 DC-DC 电感这些器件工作时会产生局部热点和磁干扰导致本地温度读数偏高且不稳定。其次I2C 的两条线要尽量平行且等长中间不要穿过大功率走线否则容易串扰。再一个如果板子上有继电器或者大电流输出传感器区域要留出足够距离必要时在底层铺地铜皮做屏蔽。有人会问温度传感器到底要不要做热隔离这取决于本地温度的用途。如果是测板子自身的真实温度官方不建议加导热垫去刻意隔开直接接触测量更真实。如果是想让它代表环境温度那就得把传感器放到远离热源的板边位置甚至用延长线引出到外壳。我在这个项目里就是把本地传感器放在板子角落既避免了 MCU 热量的直接影响又能模拟外壳内部的空气温度兼顾了设备保护功能。2.3 远程节点的线缆布局与抗干扰细节远程温度监测在实际项目里最容易出问题的地方就是线缆。单总线的数据传输拓扑很简单MCU 的 PA1 通过一根数据线连到远端 PJ85718DM 的 DQ传感器和 MCU 共地再拉一根 VCC 过去。三根线搞定但怎么把这三根线铺好学问不少。我最开始图省事用普通的杜邦线拉了两米结果读出来的温度偶尔会跳到离谱值比如从 24 度直接跳成 -30 度。排查下来就是线缆干扰。后来换成双绞线把 DQ 和 GND 绞在一起VCC 单独走问题立刻消失。原因是双绞结构让数据线和地线形成一个较小面积的电流回路抑制了外界的共模干扰尤其当线缆靠近 220V 电线或继电器触点时效果很明显。如果你的现场必须走金属线槽或者穿管优先选择屏蔽双绞线屏蔽层单端接地不要两端都接避免形成地环路。远程线缆的长度也直接影响通信稳定性。单总线协议本身能支持较长距离但工程上不能只看理论。我这次控制在 3 米以内时序稳定不需要额外加驱动芯片。如果超过 5 米建议在总线末端对地并联一个 100pF 到 220pF 的电容它对高频噪声有抑制作用但注意不要加太大否则会使上升边沿变得太缓影响时序判定。另外一个容易忽略的点是传感器供电电压线长了之后线路压降明显特别是用 5V 给传感器供电又把 MCU 的 IO 上拉到 3.3V 时电平匹配容易出问题。最稳妥的做法是远程传感器和 MCU 使用同一路 3.3V电源走线尽量粗或者中间加一颗低功耗 LDO 给传感器单独供电。3. 固件实现与数据处理3.1 驱动初始化和时序基带固件部分先从初始化讲起。STM32F334R8 用 STM32CubeMX 生成工程很方便但有几个点要手工确认。I2C1 选择 I2C 模式将 PB6、PB7 设为开漏复用速率设置为 100kHz 标准模式因为温度传感器不是高频器件100kHz 足够稳定而且线缆较长时慢速更可靠。单总线的 PA1 不需要任何特殊外设直接设为 GPIO 输出开漏初始电平为高由上拉电阻维持总线空闲状态。初始化代码大致如下基于 HAL 库GPIO_InitTypeDef gpio {0}; __HAL_RCC_GPIOB_CLK_ENABLE(); __HAL_RCC_GPIOA_CLK_ENABLE(); __HAL_RCC_I2C1_CLK_ENABLE(); // I2C1 引脚配置 gpio.Pin GPIO_PIN_6 | GPIO_PIN_7; gpio.Mode GPIO_MODE_AF_OD; gpio.Pull GPIO_PULLUP; gpio.Speed GPIO_SPEED_FREQ_HIGH; gpio.Alternate GPIO_AF4_I2C1; HAL_GPIO_Init(GPIOB, gpio); // 单总线 DQ 引脚初始化为开漏输出且输出高 gpio.Pin GPIO_PIN_1; gpio.Mode GPIO_MODE_OUTPUT_OD; gpio.Pull GPIO_PULLUP; gpio.Alternate 0; HAL_GPIO_Init(GPIOA, gpio); HAL_GPIO_WritePin(GPIOA, GPIO_PIN_1, GPIO_PIN_SET); // I2C1 初始化 hi2c1.Instance I2C1; hi2c1.Init.ClockSpeed 100000; hi2c1.Init.DutyCycle I2C_DUTYCYCLE_2; hi2c1.Init.OwnAddress1 0; hi2c1.Init.AddressingMode I2C_ADDRESSINGMODE_7BIT; HAL_I2C_Init(hi2c1);单总线的时序不能用 HAL 库现成接口需要用延时函数精确控制高低电平宽度。我基于 SysTick 写了一套微秒延时实测在 72MHz 主频下比较准确。单总线的复位时序是整个通信的起点。主设备把 DQ 拉低至少 480 微秒再释放传感器收到复位脉冲后会拉低总线约 60 到 240 微秒表示存在应答。如果这个应答没有出现可以直接判定传感器不在线。这段代码不复杂但要注意开漏模式下释放总线后要稍微延迟再读取电平因为线电容会导致电平爬升需要时间。3.2 读取温度与 CRC 校验PJ85718DM 的单总线读取流程和常见单总线温度芯片很像。每一步顺序都固定复位、存在检测、发送跳过 ROM 命令、发送启动转换命令、等待转换完成、复位、存在检测、发送跳过 ROM、发送读暂存器命令、连续读出两字节温度数据。我调试时习惯把每一步都封装成小函数方便加打印。核心读取代码类似下面这样float remote_temp_read(void) { uint8_t data[2]; if (ow_reset() 0) { // 低电平表示存在应答 ow_write_byte(0xCC); // 跳过ROM ow_write_byte(0x44); // 启动温度转换 delay_ms(750); // 等待转换完成 ow_reset(); ow_write_byte(0xCC); ow_write_byte(0xBE); // 读暂存器 data[0] ow_read_byte(); // 温度低字节 data[1] ow_read_byte(); // 温度高字节 return raw_to_celsius(data); } return INVALID_TEMP; // 约定错误值比如 -127 }这里最容易踩的坑是等待转换时间。数据手册写了最大转换时间我一开始为了赶速度只等了 500 毫秒结果读出来的数值一直是上一个周期的旧值偶尔还会读到 0 或者跳变。后来老老实实等满 750 毫秒数据就稳定了。如果你的系统对刷新率要求高可以改成读一下传感器的转换完成标志位但不推荐在 HVAC 这种慢变场景里给自己找麻烦。CRC 校验很多人会跳过我觉得远程布线环境下这步不能省。PJ85718DM 的暂存器里除了温度值外还有一个 CRC 字节可以用来验证前面 8 个字节在传输过程中有没有被干扰改写。实际测试中线缆靠近继电器动作时偶发数据跳动靠 CRC 直接就能识别并丢弃坏数据而不是把错误温度送进控制逻辑里。CRC 计算采用多项式 X^8 X^5 X^4 1软件实现用查表法最省事表格只有 256 个字节放在 Flash 里不心疼。3.3 从原始值到摄氏度算清楚单位换算温度寄存器的原始值是一个有符号数低 11 位有效每一位代表 0.0625 摄氏度。这个换算有几种写法我见过有人简单地把寄存器值除以 16这在正温度下是对的但负温度时会出问题。正确做法是先把两个字节拼成一个 16 位有符号整数再乘以 0.0625或者先除以 16 再保持浮点运算。本地 I2C 模式的 PJ85718DM 读取更直接HAL 库一行就能拿到两字节数据uint8_t temp_reg[2]; HAL_I2C_Mem_Read(hi2c1, PJ_LOCAL_ADDR, 0x00, 1, temp_reg, 2, 1000); int16_t raw (int16_t)((temp_reg[0] 8) | temp_reg[1]); float local_celsius raw * 0.0625f;负温度的处理容易错是因为如果用无符号整数拼接再乘零下温度会变成很大的正数。务必先把 raw 声明成 int16_t编译器才会做正确的符号扩展。I2C 空闲时可以每秒钟读一次这个频率对 HVAC 控制完全够了读数稳定不抖动。转换后的单位也可以直接输出成整数形式比如把 0.0625 摄氏度当作 1/16 摄氏度那么在传协议、显示时可以直接用温度值乘以 16的整数上行避免浮点格式在不同平台间的兼容问题。我在实际代码里保留浮点用于计算但发送到协议栈时统一转为定点格式见位清楚、不会因为小数位不同导致收发双方对不上。3.4 滤波、离线判断与调度策略单次读取的温度值直接拿来用偶尔会出现一个明显的跳变毛刺可能是线缆瞬态干扰引起也可能是转换边界电噪声。我用了一阶低通滤波来平滑公式很简单filtered filtered alpha * (new_sample - filtered);alpha 取 0.2 到 0.3 之间比较合适。alpha 太大滤波不明显太小则会延迟反映真实温度变化。HVAC 系统温度变化本来就慢所以我取 0.2既能滤掉毛刺又不会让控制响应迟钝。注意滤波只针对有效数据如果读到的是错误值或离线标志千万别拿进去滤波否则会把滤波器状态污染掉。本地和远程两个通道的调度我采用轮询加定时器节拍。主循环里建一个 1 秒的软件定时器标志位每秒触发一次采样任务。任务里先读本地 I2C 温度再读远程单总线温度各重试三次。远程通道连续五次都读不到就把该通道标记为离线上报温度值为 -127并点亮故障指示灯。这个离线阈值不能太小否则单次干扰就被误判成传感器故障也不能太大不然真的坏了要等半天才发现五次是我调出来比较平衡的值。读取任务放在主循环里还有一个好处单总线时序比较长整个过程大约几百毫秒如果全用阻塞方式读会拖累其他任务的执行。我在设计中用定时器把采样任务分成两个半场前半场启动远程转换然后立刻执行其他非紧迫任务后半场再来读结果。虽然温度应用本身不追求高实时性但这个习惯能避免后续给系统加显示、通信功能时回头重构。4. 常见问题与排查技巧实录4.1 四个典型故障现象与根因这套系统跑下来我遇到过的典型故障基本可以分成四类。把这些现象和原因整理成表格方便大家对照着排查。故障现象可能原因处理办法I2C 通道完全读不到 sensor上拉电阻没焊、地址写错、I2C 引脚被占用先用示波器测 SCL/SDA 波形确认总线空闲且每个 ACK 是否正常单总线远程读数偶尔出现 -127线缆干扰、接插件氧化、转换时间不足改用双绞线检查接头把转换等待时间加到 750ms远程读数比实际温度高 3 到 5 度传感器靠近发热源、供电线压降过大传感器加延长线避开设备热源检查 VCC 实际电压两路温度在工作一段时间后逐渐漂高MCU 或电源发热导致本地温度升高本地传感器移到板边或者用延时读取的数值做热模型补偿第一类故障里I2C 读不到数据最常见的原因是忘了给 SDA/SCL 接上拉电阻。STM32 内部虽然有上拉但内部上拉阻值很大对 I2C 这种推挽开漏总线来说不够可靠波形上升沿会非常缓。用示波器测量如果看到时钟线上升沿呈圆弧形而不是接近直角基本就是上拉问题。第二类故障单总线跳变除了线缆干扰还要看线头是否氧化。远程线缆如果长期工作在湿度高的风管环境里建议用带防水接头的端子不要把裸铜线直接拧在端子上。第三类故障容易让人一头雾水。有次我在测试台上测得读数稳定偏高找半天找不到原因后来用万用表量传感器端 VCC发现只有 3.12V。线缆一端接 3.3V经过两米长细导线后压降快 0.2V传感器的工作电压倒是还在范围内但内部参考电压可能受到影响精度就偏移了。解决方法是把供电走线加粗或者让传感器端的滤波电容加大到 10uF减少动态压降。第四类故障就更微妙了。温度传感器工作一段时间后读数缓慢爬升不是传感器坏了而是板子整体在升温。MCU 跑起来后发热加上电源转换效率损耗机箱内部温度本来就比环境高。如果本地温度就是用来做设备热保护的这个读数其实挺真实如果要用它来补偿环境温差就要在代码里减去一个经验偏移值或者把传感器挪到远离热源的位置。4.2 精度校准的土办法PJ85718DM 出厂有标称精度但实际应用中总会有系统误差比如远程线缆压降、本地热源影响。校准其实不需要昂贵的设备我用的方法是双温度点校准法。准备两个条件一个是冰水混合物标准 0 摄氏度一个是你手头最可靠的参考温度计比如水银温度计或已经校准过的工业温度计测量当前室温。把传感器探头分别放进两个环境中等待读数稳定后记录实际读数和参考值之差。然后在代码里做一次线性修正float calibrated_temp (raw_temp - offset0) * scale;其中 offset0 是零点偏移scale 是斜率修正系数。如果 0 摄氏度时读了 0.4 度室温 25 度时读了 25.6 度说明零偏 0.4 度增益偏差 0.8%那么修正公式就是(raw - 0.4) / 1.008左右。把算出的 offset 和 scale 存在 MCU 内部 Flash 里每次上电读出来再修正。批量生产时每块板都做校准不现实一般抽 3 到 5 块板算平均修正值写进固件就行。校准过程最容易忽略的是让探头充分热平衡。温度传感器有热惰性放进冰水混合物后要等一两分钟读数完全稳定下来再记录。如果急急忙忙读会得到一个在变化中的数值校准系数自然也是错的。另外请勿把传感器电子部分直接泡进水里一般只把探头金属部分浸入导线部分保持干燥否则可能短路。4.3 功耗、实时性与代码体积的取舍如果这套系统用电池供电功耗控制是个绕不开的话题。PJ85718DM 在工作模式下的转换电流是毫安级别虽然单次转换时间不长但加上 MCU 保持运行、总线轮询如果一直满速跑整体功耗还是可观。我做了一个简单的低功耗策略MCU 每秒钟醒来一次完成两路温度采集后立刻重新进入睡眠模式其余时间传感器也可以进入关断状态或降低采样频率。这样平均功耗从毫安级降到微安级电池供电的温控面板就能撑很久。实时性和功耗是一对矛盾。HVAC 应用里温度变化以分钟计根本不需要每毫秒去刷新所以 1 秒采样一次已经是很好的平衡点。但要注意 STM32 从睡眠到唤醒的启动时间唤醒后系统时钟稳定需要几十个微秒如果刚好在单总线时序中被打断容易产生毛刺。我的经验是低功耗唤醒后先做一次总线复位让链路重新建立连接再做正式的温度读取宁可多花几毫秒也保证错误的数据不会进入控制逻辑。代码体积方面HAL 库本身比较大如果只是做温度采集可以关掉没用到的外设模块。I2C 用 HAL 库没问题单总线直接手写 GPIO 模拟不占用多余外设。CRC 表 256 字节也不大放在常量区即可。F334R8 的 Flash 有 64KB完整编译下来大概占用不到一半空间比较宽裕。如果后续要加图形界面、协议栈也有升级空间。5. 扩展方向与个人经验5.1 从只测温度到控制风机与阀门温度监测做出来以后很自然的下一步就是控制。STM32F334R8 的 HRTIM 高分辨率定时器这时候就能派上用场了。远程温度作为反馈值MCU 通过 PWM 控制风机的转速或者通过比例阀调节水流量构成一个闭环控制系统。最简单的是滞回控制温度高于设定值加回差就开风机低于设定值减回差就关风机代码就一个比较逻辑要求高一点的可以用 PID 算法把温度误差经过比例、积分、微分运算后输出到 PWM 占空比。F334R8 的 HRTIM 精度很高做普通风机 PWM 甚至有点大材小用不过好处是可以用比较高的 PWM 频率去驱动静音风扇减少电机啸叫。如果项目后续要从单风机扩展到多路风机联动HRTIM 多路输出可以直接支持不需要额外加定时器扩展芯片。我实际试过在 20kHz 频率下驱动无刷风机噪声明显比 10kHz 小而且 F334 的定时器资源扛得住。5.2 多节点组网与上云单总线的天然优势是可以在一根总线上挂多个传感器。当前方案只挂了一个远程节点如果现场需要多点测温比如一个风管上要测入口、中部、出口三个位置还是只用一条总线每个 PJ85718DM 配置不同的 ROM 地址MCU 端循环遍历即可。每增加一个节点总线电容和通信时序负载都会增加所以单总线挂超过 8 个节点时建议把总线分成两路分别由不同 GPIO 驱动。更上层的数据汇聚可以用 STM32F334R8 的 UART 或 CAN 接口把这些温度帧上报给楼宇自控系统或云网关。我建议在协议里带上传感器编号、数据类型、温度原始值和修正后的浮点值方便解析方直接使用。如果走串口最简单的做法是输出 JSON 文本帧调试方便对 PLC 或 PC 上位机也友好如果走 CAN则建议定义紧凑的 DBC 信号减少总线带宽占用。温度上报周期 5 到 10 秒一次就够频繁上报意义不大。5.3 写在最后的几条实操心得这次做完最大的感受是温度采集看着简单真正把本地和远程两路数据做到稳定、准确、可维护需要关注的地方一点不少。整理几条我自己会记在心里的小经验第一远程传感器能用电隔离的场合尽量不要省。如果现场存在强烈共模干扰比如变频器附近温度数据和地电位会抖得很难看单总线读错率飙升。预算允许时在总线链路中加一个数字隔离器效果立竿见影。第二上拉电阻的阻值不要照抄参考设计要根据实际线长和节点数调整。我一开始用 10k 上拉单总线近距离工作正常线一拉长就开始丢数据换成 4.7k 之后就稳了。手头没示波器的时候可以用连续读取一万次统计错误率来判断如果错误率低于十万分之一说明时序裕量基本够用。第三本地传感器一定要留一个校准口。硬件设计时给本地传感器预留一颗电阻焊盘或者 0 欧跳线用来切换传感器跟 MCU 之间是否断开的测量模式。这种小设计平时用不上真到了产品温度超差要排查时能省很多焊接时间。第四如果让我重新规划我会在 PCB 上预留第二颗 PJ85718DM 的位置方便产品升级时从单路本地温度扩成双路本地温度或者把其中一路改成远程接入。多一颗传感器成本不高但给软件和产品形态带来的灵活性很值。这套方案目前已经跑了一段时间远程读数稳定本地保护逻辑也正常。接下来我打算把 HRTIM 用起来让温度数据直接参与风机转速闭环控制到时候再分享一版带控制算法的升级实现。