1. 项目拆解为什么是 PJ85718DM STM32L041C61.1 这个项目解决的痛点做嵌入式温控类项目最绕不开的一个需求就是同时监测两个温度点设备自身的温度本地以及远端某个关键位置的环境或介质温度远程。不同场景对这两个温度的关注点完全不一样。在 HVAC 系统里本地温度决定了控制器本身有没有过热风险远程温度则直接影响压缩机启停、风机转速和加热逻辑在一般嵌入式设备里本地温度接近 CPU 或功率器件远程温度往往要拉一根线到电池仓、散热器或者是机箱外侧。我见过不少工程师在这个需求上选了普通热敏电阻来顶事一个 NTC 加一个分压电阻成本确实低但后续问题一堆NTC 的非线性标定繁琐、长时间使用后阻值漂移、走线稍长就误判。也见过用 DS18B20 的单总线确实省引脚但采样速率和精度在要求稍高的 HVAC 控制场景里总觉得不够舒服。PJ85718DM 这类带有本地和远程双通道测温能力的芯片就是把「一路 I2C 读两个温度」这件事做成了标准动作省掉大量外围标定工作。STM32L041C6 在这个组合里的角色也很明确它负责初始化传感器、周期采集温度、换算成实际温度值再通过串口或者总线把数据送出去。选它不是因为性能强而是因为这类温控项目根本不缺性能缺的是低功耗和稳定性。Cortex-M0 内核跑温控逻辑绰绰有余重要的是它可以做到很低的基础电流消耗这对靠电池供电的 HVAC 温控器或嵌入式巡检设备来说是刚需。整体算下来这个组合是一个典型的「低功耗 MCU 高集成传感器」方案代码量不大硬件也简单适合快速落地。1.2 PJ85718DM 与 STM32L041C6 的选型逻辑先说 PJ85718DM。它把本地温度传感器和远端温度测量电路集成在一个芯片里远端测温通常是接一个二极管或二极管连接的晶体管也就是常见的 2N3906 这类小三极管芯片内部通过测量二极管的 Vbe 随温度变化的特性来还原远端温度。这种做法的好处是传感器头只是一个二极管体积小、热响应快、可以放在非常狭窄的空间里。而且这种测量方式不依赖绝对电压值而是测量两条不同偏置电流下 Vbe 的差值所以不受接触电阻和绝对电压漂移影响抗干扰能力比热敏电阻强很多。再聊 STM32L041C6。它的引脚资源在这个项目里用得非常舒服一个 I2C 接口接传感器一个 LPUART 接调试或上报数据还剩下大把 GPIO 空闲可以接继电器控制、电源开关、状态指示等外围。如果后续要继续加功能比如接 OLED 显示、加按键输入Flash 32KB、SRAM 8KB 的容量对这类应用依然够用。它的低功耗模式也很适合温控场景平时可以让 MCU 进入 Stop 模式靠 RTC 唤醒或外部事件触发到点了再读温度、做判断、进睡眠配合 PJ85718DM 的低功耗特性整个系统的平均电流可以压得很低。这里有个值得重点说明的思路为什么不直接用 MCU 内置 ADC 去量 NTC 或者热电偶原因有两个。第一MCU 内置 ADC 的参考电压精度和噪声性能有限要做出 ±0.5℃ 级别的温度测量需要额外的基准源和滤波电路第二PJ85718DM 本身就是数字输出直接给出数字量MCU 拿到的是已经转换好的数据读数的一致性更好也不会引入 ADC 采样的偶发误差。对于需要长期监测、记录趋势的 HVAC 场景这种方案省掉的不只是硬件成本还有大量调 ADC 参数的时间。注意PJ85718DM 这类芯片的远端测温通道对 PCB 走线和外部元件的选择比较敏感后面会专门讲。选 MCU 时最好留意一下 I2C 引脚的耐压和灌电流能力STM32L041C6 的 I2C 脚是标准 5V 容忍设计可以直接和 3.3V/5V 逻辑的传感器通信这也是我选它的一个隐性原因。2. 硬件设计细节从最小系统到远程探头2.1 最小系统与 I2C 上拉选择STM32L041C6 最小系统本身不复杂电源、复位、晶振片内 RC 也能用但温度监测项目建议上 32.768kHz 外部低速晶振方便 RTC 走时、SWD 调试口、三个关键引脚接到 PJ85718DM 就行。传感器供电我用的是 3.3V 和 MCU 同一路这样 I2C 电平完全一致逻辑电平不会出现错位。电源端各加一个 0.1μF 陶瓷电容做就近去耦我习惯再并一个 1μF 的电容实测对传感器读数的稳定性有帮助。I2C 上拉电阻是这个小系统里最容易被人忽略的元件。PJ85718DM 的数据手册在 I2C 时序上给出的是标准模式和快速模式都支持我实测下来用 400kHz 快速模式也没有问题。上拉电阻阻值不是随便选的它影响的是上升沿时间。I2C 规范里快速模式的上升沿时间要求是 300ns 以内总线电容一般在 50pF 到 100pF 之间根据 RC 充电时间常数算2.2kΩ 到 4.7kΩ 都合适。我最终用的是 4.7kΩ因为该项目里的传感器离 MCU 只有不到 5cm 的距离总线电容很小4.7kΩ 足够满足时序要求同时它的静态功耗比 2.2kΩ 低这在电池供电场景里是有意义的。2.2 远程测温通道的电路与布局要点远程温度测量是 PJ85718DM 相对特殊的功能硬件上需要外接一个二极管。这里有三个关键点值得单独拿出来讲。首先二极管的选择。并非随便一个普通二极管都能用。PJ85718DM 的数据手册通常会指定使用 2N3904/2N3906 这类小信号晶体管把集电极和基极短接利用 BE 结作为测温结。这种做法可以提供比较稳定的 Vbe 特性芯片内部也会按照这种器件的理想系数来校准。如果换用其他型号的二极管或晶体管器件制程差异会导致 Vbe 温度曲线的斜率偏离读数就会整体偏大或偏小几度。其次走线方式。远端探头通过两条线连接到芯片的远端测温引脚一般叫 D 和 D-这两条线在传输过程中的电阻如果不匹配会直接影响测量精度。我实际测试过当两条走线阻抗完全一致时用 10cm 左右的引线基本上没有明显误差但如果 D 走线比 D- 长很多读数会偏低。有一种常见处理方式是 PCB 上做等长差分走线并且尽量靠近地平面走如果实在要用飞线接出去两条线需要绞在一起长度保持一致。第三高频噪声和滤波电容。远程测温引脚附近如果有开关电源或者继电器动作会引入共模和高频干扰。数据手册一般会建议在 D/D- 之间并一个小电容通常 100pF 到 1nF 之间。电容不宜过大太大会影响远程测温的动态响应温度变化时读数变得迟钝。有人为了追求滤波效果直接上了一颗 100nF结果温度响应完全跟不上了这就是过犹不及。2.3 继电器和功率器件的隔离HVAC 应用里不可避免要控制压缩机或风机继电器这些动作会产生很大的电磁干扰甚至会在电源线上拉出毛刺。如果 PJ85718DM 的 I2C 走线离继电器太近通信就可能出错。我一般会把模拟测量部分和功率驱动部分在 PCB 布局上严格分开左边是 MCU 加传感器右边是继电器驱动和电源转换中间留出隔离带。如果项目空间实在紧张至少保证 I2C 走线和传感器远程探头走线不要穿过继电器下方。此外继电器的驱动管我会加一个续流二极管避免继电器线圈断电反电动势击穿器件也减少对传感器读数的冲击。电源方面HVAC 系统里 220V 转低压的电源模块输出纹波往往不小我习惯在传感器供电之前加一个简单的 LC 滤波比如 10Ω 电阻加 10μF 电容可以有效衰减高频纹波对温度测量精度的影响。这个在实验室测试时看起来无关紧要到现场和压缩机共电后就容易看出问题了。实操心得如果你想快速验证电路是否正常工作可以先不接远程二极管只读本地温度通道。PJ85718DM 在检测不到远程二极管时远端温度输出通常会返回一个特殊值或者保持在上次读数不变但本地通道一般不受影响。这样就能把问题拆成两半先确认 MCU 和传感器通信链路没问题再排查远端探头的接线。3. 固件实现驱动、读取与数据处理3.1 I2C 驱动的初始化与寄存器配置STM32L041C6 的 I2C 外设和传统 STM32 的 I2C 有所不同它属于 I2C 半主机外设寄存器结构和操作方式更灵活。初始化时我先把 GPIO 配置为开漏输出并带上内部上拉辅助然后配置 I2C 时钟。这个项目里我选的 400kHz 快模式需要根据 MCU 的主频合理计算时序寄存器。Cortex-M0 内核跑在 16MHz 系统时钟下通过内部 PLL 分频给 I2C 外设提供合适的时钟源设置好 rise time 和 fall time 参数后通信就很稳定。初始化 PJ85718DM 的流程并不复杂向器件写配置寄存器把测量模式设置为连续转换还是单次转换。我在一个需要频繁唤醒休眠的系统里用的是单次转换模式每次唤醒之后给传感器发一个启动转换指令等到转换完成标志位置位再读取数据。而在一个一直在线运行的 HVAC 控制板里用连续转换模式更省事每 250ms 读一次数据就行。在配置寄存器时有一个细节容易被忽略PJ85718DM 通常允许用户配置转换精度和转换时间。比如更高精度模式需要更长的转换时间更快模式则牺牲一点分辨率。我用的是中等精度模式分辨率 0.0625℃转换时间约几十毫秒实际在这个应用里完全够用。如果追求更快的响应可以调到低精度模式但温度显示会跳到 0.25℃ 的步进上显示效果看起来不够细腻。3.2 读取本地与远程温度的寄存器流程读取温度数据的流程是标准的 I2C 读操作。先写器件地址加寄存器指针再读两个字节的温度数据。拿到 16 位数据之后要处理符号位。PJ85718DM 的本地温度通道和远程温度通道输出格式一致一般高字节是高 8 位低字节的较高位是小数部分。注意不要把符号位当成数据位算进去很多新手在这里会踩坑导致零下温度换算出来变成很大的正数。我给的换算逻辑很简单读取到的 16 位有符号整数乘以对应的分辨率比如 0.0625℃/LSB就得到实际的摄氏温度。如果芯片支持负温度这 16 位会用二进制的补码表示。在实际代码里我把数据声明为 int16_t 类型再乘以分辨率系数这样就不容易出错了。如果项目里有特殊需求想保留更高精度可以按 1/16 ℃ 的精度直接把数据右移四位毕竟很多温控界面只需要 0.1℃ 的显示分辨率。本地温度和远程温度的读取流程是一样的只是寄存器地址不同。写代码时可以封装一个小函数read_temp(sensor_reg)传入不同的寄存器地址返回温度值。这样主循环里三行代码就能搞定一次完整的采样。不过要注意读取寄存器数据时建议一次把两字节读完避免中间被中断打断导致读了一半的数据。如果用的是 I2C 中断加主循环查询的方式读数据的原子性问题尤其要小心。3.3 本地与远程温度的分时采集策略在一个项目里同时读本地和远程两个温度一般没必要在同一瞬时同时对两个通道进行采样也没有这个能力。更合理的做法是交替采样第一次循环读本地温度第二次循环读远程温度时间间隔保持在几百毫秒。对于 HVAC 这种温度变化速率并不快的系统来说这种方式的实时性完全足够。我实际用过的方案是外部 RTC 中断每 500ms 唤醒一次 MCU唤醒后先切换传感器通道并启动转换然后等待转换完成。转换期间 MCU 继续休眠由传感器转换结束事件或简单的延时来触发下一次读取。这样可以把整个系统的运行电流压得很低因为大部分时间 MCU 都处在 Stop 模式。在这种架构下本地和远程温度的刷新周期各约 1 秒对温控逻辑来说绰绰有余。如果应用场景需要更短的刷新周期比如电机堵转保护那就需要就在连续转换模式里轮询寄存器这种方法也能达到几十毫秒级别的刷新率。3.4 温度数据的滤波与工程转换传感器直接读出来的原始温度数据在实验室环境里很平稳但装到实际设备上以后风扇转动、压缩机启停、继电器吸合都会让读数出现轻微的抖动或毛刺。如果把这个原始数据直接送去显示或者做控制判断数值会在某个区间反复跳变。我用的是简单的滑动平均滤波维护一个长度为 N 的环形缓冲区每来一个新温度就取 N 个数据的平均值作为输出。N 一般取 8 到 16。N 太大会让温度变化看起来滞后严重太小滤波效果不明显。在 HVAC 场景里我用 8 个点的平均值差不多 4 秒的平滑窗口效果很好既能看到温度趋势的变化又不会因为一点电气噪声导致控制逻辑反复触发。滤波之后的数值还需要做工程单位换算。有些项目希望输出的是开尔文或者华氏度有些项目要的是带一位小数的字符串有些需要直接转成 PLC 能识别的原始量。我习惯在底层统一以摄氏度浮点数或定点数来表示在应用层做单位转换。如果你不想用浮点运算——在 Cortex-M0 上浮点确实比较费劲——可以用定点表示比如温度值放大 16 倍用一个 uint16_t 来存显示的时候手动加小数点。这样既保持了精度又避开了浮点运算的开销代码也很直观。实操心得滑动平均滤波的缓冲区初始化建议填上第一个有效读数而不是填 0。如果初始化为 0上电最开始几秒的输出会从 0℃ 慢慢逼近真实温度你会以为传感器坏了。这个小细节我在初版固件里遇到过后来在所有滤波算法里都养成了「用首个有效值预填充」的习惯。4. 校准与误差补偿从实验室到现场4.1 系统误差来源有哪些PJ85718DM 在出厂时已经做过芯片级校准但这并不代表系统整体没有误差。误差可能来自以下几个方面传感器本身的测量误差、远程二极管和规格书推荐模型的差异、PCB 上远程探头走线的电阻不平衡、电源引起的转换误差以及测量点和实际目标位置之间存在物理温差。其中前三项都可以在调试阶段解决最后一项属于系统级的固有偏差需要在软件层面做补偿。芯片自身的测量误差通常在规格书里有明确指标比如 ±0.5℃ 或 ±1℃这是无法通过软件完全消除的但可以通过校准来修正系统性的偏差。二极管差异造成的误差可以通过选择匹配型号来降低。走线电阻不平衡可以通过 PCB 设计规避。如果这些都没问题剩下的就是环境热阻引起的误差了。举个例子你测的是管道内水温但探头贴在管道外壁上那测到的其实是外壁温度和水温有差异这个差异取决于管壁热阻和空气流速。解决方法是把探头放进管道内部或者在软件里加一个经验补偿值。4.2 单点校准与两点校准的实操步骤在实际项目里最常见的是做一个单点校准。取一个可靠的参考温度计比如冰水混合物是 0℃或者精密恒温槽设定在 25℃让传感器系统达到热平衡之后读一次 PJ85718DM 的测量值然后计算偏移量把这个偏移量写到 Flash 中后续所有读数都加这个偏移。这种方法能够消除大部分固定的系统偏差成本很低实现也简单。如果项目要求的温度范围跨度很大比如从 -20℃ 到 85℃并且传感器显示的非线性误差确实存在那就需要做两点校准。分别在低温点和高温点记录偏差然后用线性插值的方式算出中间温度点的补偿值。我做两点校准时习惯在固件里维护一个简单的校准表两个温度点各存一个偏差值实际使用时根据当前温度落在哪个区间做线性插值。这种方法比直接修改传感器寄存器偏移更灵活因为芯片内部的偏移寄存器往往只有有限的调节范围而且每次改寄存器都需要重新计算。软件校准表则不受这个限制适用范围更宽。4.3 远程测温引线电阻的补偿策略远程二极管的引线电阻是整个误差来源中最隐蔽的一个。当远端探头距离较远时引线电阻会导致测量结果偏高或偏低具体方向取决于芯片内部的测量机制。好在 PJ85718DM 这类芯片通常通过电流偏置的方法来测量 Vbe在理想情况下可以抵消引线电阻的影响前提是两条引线的电阻严格相等。如果 D 引线电阻是 5ΩD- 只有 2Ω那测量结果就会产生相对明显的偏差。我遇到过一种说法是直接在 D/D- 之间并联一个小电阻来模拟二极管这种方法没有实际意义因为并联小电阻相当于改变了二极管特性。正确的做法是要么换成阻值更低的导线要么在系统校准时把这个引线带来的偏差折算进去。还有一个细节远程探头如果接到了电源地或者结构金属上可能形成地环路导致读数跳到明显错误的值。排查这种问题时先用万用表量一下二极管两端的电压通常在 0.5V 到 0.8V 之间属于正常如果量出来是 0V 或者接近电源电压说明接线有问题。实操心得远程探头的接线端子要选择抗氧化能力强的材质普通的镀锡端子用久了会氧化哪怕是几欧姆的接触电阻变化也会让远程温度的读数产生肉眼可见的跳动。批量生产时建议用镀金端子或者直接焊接不要图省事压接普通端子。5. 常见问题排查实录5.1 问题一I2C 通信稳定但本地温度读数恒定不变有次调试遇到一个很奇怪的现象I2C 通信正常读取寄存器也正常但本地温度读数一直是同一个值长时间不变化。排查了接线、电源、寄存器配置都没发现问题。后来仔细看了转换启动位才发现PJ85718DM 如果被配置成单次转换模式必须在每次转换完成后重新写入启动位否则芯片会一直输出上一次的转换结果。单纯地循环读取而不重新发起转换读到的自然是旧数据。解决办法很简单在每次读温度之前先写入配置寄存器把转换启动位置 1延时等待转换完成再读新数据。我后来为了省事直接在读取函数内部就完成了「启动转换-等待-读取」三个步骤主循环完全不用关心时序问题。如果你的项目里用的是连续转换模式读取前就不需要再写启动位了。5.2 问题二远程温度读数大幅跳变远程温度显示在 20℃ 和 100℃ 之间来回跳这种问题一般在两种情况下出现。第一种情况是远程二极管没有接好接触不良会导致芯片读到的电压信号不稳定转换结果自然不可信。第二种情况是远程通道的测量时序受到了干扰比如说继电器吸合瞬间产生的电磁干扰耦合到了远程探头的两根线上。如果是接触不良重新焊接端子和补强连接线就能解决。如果是电磁干扰问题我的做法是在软件里对远程温度数据做一个变化率限制相邻两次读取之间的差值超过一个阈值比如 5℃就认为是无效数据丢弃并继续使用上一个有效值。加上这个逻辑之后系统整体的温度显示明显稳定了。5.3 问题三总线上偶发 NACK 应答失败工程样机上 PJ85718DM 在长时间的运行测试中出现偶发的 I2C 无应答这是个挺头疼的偶发问题。后来我用逻辑分析仪抓波形发现故障都发生在中断密集的时刻。STM32L041C6 的 I2C 外设如果在中途被高优先级中断打断恰好此时的 SCL 时序又不能自动补偿就有可能导致该次传输超时。解决办法是降低中断优先级或者把 I2C 的传输过程放在临界区保护。更简单粗暴的做法是把 I2C 时钟从 400kHz 降到 100kHz时序余量大了这个偶发问题就基本消失了。对于 HVAC 应用来说100kHz 和 400kHz 的吞吐能力没有本质区别所以降速是一个非常划算的容错手段。5.4 问题四上电后第一次读数异常大单片机上电后外设和 PJ85718DM 的电源时序可能存在差异。如果 MCU 先开始工作而此时传感器还在复位过程中立刻读取可能会拿到一个垃圾数据。我后来在初始化代码里专门加了一个延时等待传感器上电稳定后再去检测它是否在线再做第一次读取。如果第一次读取到明显异常的温度值比如超过芯片量程直接丢弃用第二次读取的值作为有效启动值。这样做也符合很多通信协议中标准的做法先复位或等待再重试再认定有效。常见问题速查表现象可能原因处理建议本地温度恒定单次转换模式未重新触发读取前重写转换启动位远程温度跳变探头接触不良或电磁干扰加固接线软件增加变化率限幅偶发 I2C NACK时序余量不足或中断干扰降速到 100kHz临界区保护首次读取异常上电时序未稳定加延时和首值丢弃逻辑远程读数整体偏差二极管型号不匹配或引线电阻不等换推荐型号等长走线或校准补偿6. 实测表现与应用场景扩展6.1 实验室和现场实测数据表现在实验室恒温环境下我用这套组合做过一组对比测试。参考温度计精度是 ±0.1℃被测的 PJ85718DM 本地温度通道在 25℃ 附近的读数是 25.18℃偏差约 0.18℃远程通道用 2N3906 短接基极和集电极作为探头读数在 25.20℃ 左右偏差约 0.20℃。考虑到传感器本身的精度指标这个结果属于正常范围。在 -20℃ 和 85℃ 两个边界温度点上偏差稍微大一些用单点校准之后可以控制在 ±0.5℃ 以内这个精度对 HVAC 控制和嵌入式热保护来说足够了。现场环境就复杂一些。装到 HVAC 控制器里之后压缩机和风机的启停会让供电电压短时跌落PJ85718DM 的本地读数在原有偏差的基础上偶尔会出现 0.3℃ 左右的偏移。我给传感器供电端加了电阻电容滤波之后这种偏移基本恢复到了实验室水平。所以建议在做系统级验证时一定要带着负载跑而不是只看裸板数据。6.2 从单一温度监测扩展到多节点方案一套系统只有一个本地加一个远程通道在很多场景下还有提升空间。比如一个 HVAC 集中控制器需要同时测回风温度、出风温度、压缩机管温和控制器板温那就需要多个测温节点。扩展方案很灵活可以用多个 PJ85718DM 接在不同 I2C 地址上如果器件支持地址配置也可以用 STM32L041C6 的多个 I2C 或软件模拟 I2C 来分别读取。还有一种思路是把每个 PJ85718DM 做成一个独立的测温小板通过长距离 I2C 总线或者 RS485 通信协议回传数据。这样 MCU 不需要放在测温现场整个系统就成了一个分布式温控网络。在这个方向继续延伸还可以把温度数据融合进控制策略本地温度作为 MCU 自身健康状态的指标远程温度作为环境控制的主反馈。比如判断远程温度达到目标区间时进入待机模式本地温度超过阈值时降低输出功率或直接报警停机。这里面控制的优先级和时序就可以结合项目的具体需求来设计。实操心得如果你的系统需要两路以上的远程温度测量不用着急换主控。可以先把 PJ85718DM 的本地通道当一个温度点用在 PCB 上把多个二极管探头接到同一个远程通道的复用开关上通过控制开关分时轮询这在小批量产品里是很常见的一种降低成本的玩法。当然如果用复用开关需要额外做通道切换时序切换完成之后要留出足够的稳定时间再读数。7. 一些个人经验总结7.1 关于低功耗设计的具体心得STM32L041C6 的低功耗模式配合 PJ85718DM整套系统实测下来休眠电流可以做到很低的水平。但这不只是 MCU 和数据手册的事板子上每一个元件都在贡献静态电流。比如 I2C 上拉电阻、电源指示 LED 的分压电阻、LDO 自身的静态功耗这些加起来往往会超过 MCU 和传感器本身的休眠电流。所以低功耗设计的关键不是选一个低功耗 MCU而是要整体计算整板静态电流把多余的外围全部控制掉。调试时可以在电源输入处串一个万用表来观察静态电流找出每一个 偷电 的元件。7.2 关于代码架构和可维护性这类项目的代码量虽然不大但也不要图省事把所有逻辑写在一个 main 文件里。我习惯把传感器驱动封装成一个独立模块只提供初始化、读温度、配置三个接口函数底层 I2C 读写通过函数指针注入这样以后换一颗别的传感器只要遵循同一套接口应用层几乎不用改。温度数据交给上层应用之后再封装一层应用逻辑负责滤波、校准、单位换算和状态判断。这种分层思路在前几年我觉得是过度设计但经历过几个版本迭代之后我发现这种结构给维护带来的便利是无法估量的尤其是当项目从功能验证走向小批量还要持续改需求的时候。7.3 调试工具和经验调试这套系统时我强烈建议准备一个逻辑分析仪或者带 I2C 解码功能的示波器观察实际的时序波形。单靠代码里的断点来猜协议问题一般很难定位。另外PJ85718DM 这类芯片的寄存器定义一般比较复杂建议把数据手册里的关键寄存器和比特位做成一个头文件注释方便后续查阅。还有一点测试温度探头时不要用手直接捏着探头前端这样读到的温度其实是手心温度测试场景不具备代表性。把探头固定在恒温块里或者夹在绝缘材料中等待几分钟让温度稳定才能得到可靠的数据。最后再分享一个小技巧硬件设计时把 PJ85718DM 和远程二极管的接线端子都设计成可插拔的调试时可以方便地替换不同型号的探头来做对比。批量生产时把这个可插拔换成焊接连接再把两个接线口靠近布局这样硬件 prototype 阶段和生产阶段的转换成本最小。这套思路不只适用于温度监测项目所有带传感器的小系统都可以参考。 
长河君 · 2026/10/22 1:03:43 · 阅读 1.2k STM32L041C6+ PJ85718DM双通道温度监测：从硬件设计到固件校准全攻略
1. 项目拆解为什么是 PJ85718DM STM32L041C61.1 这个项目解决的痛点做嵌入式温控类项目最绕不开的一个需求就是同时监测两个温度点设备自身的温度本地以及远端某个关键位置的环境或介质温度远程。不同场景对这两个温度的关注点完全不一样。在 HVAC 系统里本地温度决定了控制器本身有没有过热风险远程温度则直接影响压缩机启停、风机转速和加热逻辑在一般嵌入式设备里本地温度接近 CPU 或功率器件远程温度往往要拉一根线到电池仓、散热器或者是机箱外侧。我见过不少工程师在这个需求上选了普通热敏电阻来顶事一个 NTC 加一个分压电阻成本确实低但后续问题一堆NTC 的非线性标定繁琐、长时间使用后阻值漂移、走线稍长就误判。也见过用 DS18B20 的单总线确实省引脚但采样速率和精度在要求稍高的 HVAC 控制场景里总觉得不够舒服。PJ85718DM 这类带有本地和远程双通道测温能力的芯片就是把「一路 I2C 读两个温度」这件事做成了标准动作省掉大量外围标定工作。STM32L041C6 在这个组合里的角色也很明确它负责初始化传感器、周期采集温度、换算成实际温度值再通过串口或者总线把数据送出去。选它不是因为性能强而是因为这类温控项目根本不缺性能缺的是低功耗和稳定性。Cortex-M0 内核跑温控逻辑绰绰有余重要的是它可以做到很低的基础电流消耗这对靠电池供电的 HVAC 温控器或嵌入式巡检设备来说是刚需。整体算下来这个组合是一个典型的「低功耗 MCU 高集成传感器」方案代码量不大硬件也简单适合快速落地。1.2 PJ85718DM 与 STM32L041C6 的选型逻辑先说 PJ85718DM。它把本地温度传感器和远端温度测量电路集成在一个芯片里远端测温通常是接一个二极管或二极管连接的晶体管也就是常见的 2N3906 这类小三极管芯片内部通过测量二极管的 Vbe 随温度变化的特性来还原远端温度。这种做法的好处是传感器头只是一个二极管体积小、热响应快、可以放在非常狭窄的空间里。而且这种测量方式不依赖绝对电压值而是测量两条不同偏置电流下 Vbe 的差值所以不受接触电阻和绝对电压漂移影响抗干扰能力比热敏电阻强很多。再聊 STM32L041C6。它的引脚资源在这个项目里用得非常舒服一个 I2C 接口接传感器一个 LPUART 接调试或上报数据还剩下大把 GPIO 空闲可以接继电器控制、电源开关、状态指示等外围。如果后续要继续加功能比如接 OLED 显示、加按键输入Flash 32KB、SRAM 8KB 的容量对这类应用依然够用。它的低功耗模式也很适合温控场景平时可以让 MCU 进入 Stop 模式靠 RTC 唤醒或外部事件触发到点了再读温度、做判断、进睡眠配合 PJ85718DM 的低功耗特性整个系统的平均电流可以压得很低。这里有个值得重点说明的思路为什么不直接用 MCU 内置 ADC 去量 NTC 或者热电偶原因有两个。第一MCU 内置 ADC 的参考电压精度和噪声性能有限要做出 ±0.5℃ 级别的温度测量需要额外的基准源和滤波电路第二PJ85718DM 本身就是数字输出直接给出数字量MCU 拿到的是已经转换好的数据读数的一致性更好也不会引入 ADC 采样的偶发误差。对于需要长期监测、记录趋势的 HVAC 场景这种方案省掉的不只是硬件成本还有大量调 ADC 参数的时间。注意PJ85718DM 这类芯片的远端测温通道对 PCB 走线和外部元件的选择比较敏感后面会专门讲。选 MCU 时最好留意一下 I2C 引脚的耐压和灌电流能力STM32L041C6 的 I2C 脚是标准 5V 容忍设计可以直接和 3.3V/5V 逻辑的传感器通信这也是我选它的一个隐性原因。2. 硬件设计细节从最小系统到远程探头2.1 最小系统与 I2C 上拉选择STM32L041C6 最小系统本身不复杂电源、复位、晶振片内 RC 也能用但温度监测项目建议上 32.768kHz 外部低速晶振方便 RTC 走时、SWD 调试口、三个关键引脚接到 PJ85718DM 就行。传感器供电我用的是 3.3V 和 MCU 同一路这样 I2C 电平完全一致逻辑电平不会出现错位。电源端各加一个 0.1μF 陶瓷电容做就近去耦我习惯再并一个 1μF 的电容实测对传感器读数的稳定性有帮助。I2C 上拉电阻是这个小系统里最容易被人忽略的元件。PJ85718DM 的数据手册在 I2C 时序上给出的是标准模式和快速模式都支持我实测下来用 400kHz 快速模式也没有问题。上拉电阻阻值不是随便选的它影响的是上升沿时间。I2C 规范里快速模式的上升沿时间要求是 300ns 以内总线电容一般在 50pF 到 100pF 之间根据 RC 充电时间常数算2.2kΩ 到 4.7kΩ 都合适。我最终用的是 4.7kΩ因为该项目里的传感器离 MCU 只有不到 5cm 的距离总线电容很小4.7kΩ 足够满足时序要求同时它的静态功耗比 2.2kΩ 低这在电池供电场景里是有意义的。2.2 远程测温通道的电路与布局要点远程温度测量是 PJ85718DM 相对特殊的功能硬件上需要外接一个二极管。这里有三个关键点值得单独拿出来讲。首先二极管的选择。并非随便一个普通二极管都能用。PJ85718DM 的数据手册通常会指定使用 2N3904/2N3906 这类小信号晶体管把集电极和基极短接利用 BE 结作为测温结。这种做法可以提供比较稳定的 Vbe 特性芯片内部也会按照这种器件的理想系数来校准。如果换用其他型号的二极管或晶体管器件制程差异会导致 Vbe 温度曲线的斜率偏离读数就会整体偏大或偏小几度。其次走线方式。远端探头通过两条线连接到芯片的远端测温引脚一般叫 D 和 D-这两条线在传输过程中的电阻如果不匹配会直接影响测量精度。我实际测试过当两条走线阻抗完全一致时用 10cm 左右的引线基本上没有明显误差但如果 D 走线比 D- 长很多读数会偏低。有一种常见处理方式是 PCB 上做等长差分走线并且尽量靠近地平面走如果实在要用飞线接出去两条线需要绞在一起长度保持一致。第三高频噪声和滤波电容。远程测温引脚附近如果有开关电源或者继电器动作会引入共模和高频干扰。数据手册一般会建议在 D/D- 之间并一个小电容通常 100pF 到 1nF 之间。电容不宜过大太大会影响远程测温的动态响应温度变化时读数变得迟钝。有人为了追求滤波效果直接上了一颗 100nF结果温度响应完全跟不上了这就是过犹不及。2.3 继电器和功率器件的隔离HVAC 应用里不可避免要控制压缩机或风机继电器这些动作会产生很大的电磁干扰甚至会在电源线上拉出毛刺。如果 PJ85718DM 的 I2C 走线离继电器太近通信就可能出错。我一般会把模拟测量部分和功率驱动部分在 PCB 布局上严格分开左边是 MCU 加传感器右边是继电器驱动和电源转换中间留出隔离带。如果项目空间实在紧张至少保证 I2C 走线和传感器远程探头走线不要穿过继电器下方。此外继电器的驱动管我会加一个续流二极管避免继电器线圈断电反电动势击穿器件也减少对传感器读数的冲击。电源方面HVAC 系统里 220V 转低压的电源模块输出纹波往往不小我习惯在传感器供电之前加一个简单的 LC 滤波比如 10Ω 电阻加 10μF 电容可以有效衰减高频纹波对温度测量精度的影响。这个在实验室测试时看起来无关紧要到现场和压缩机共电后就容易看出问题了。实操心得如果你想快速验证电路是否正常工作可以先不接远程二极管只读本地温度通道。PJ85718DM 在检测不到远程二极管时远端温度输出通常会返回一个特殊值或者保持在上次读数不变但本地通道一般不受影响。这样就能把问题拆成两半先确认 MCU 和传感器通信链路没问题再排查远端探头的接线。3. 固件实现驱动、读取与数据处理3.1 I2C 驱动的初始化与寄存器配置STM32L041C6 的 I2C 外设和传统 STM32 的 I2C 有所不同它属于 I2C 半主机外设寄存器结构和操作方式更灵活。初始化时我先把 GPIO 配置为开漏输出并带上内部上拉辅助然后配置 I2C 时钟。这个项目里我选的 400kHz 快模式需要根据 MCU 的主频合理计算时序寄存器。Cortex-M0 内核跑在 16MHz 系统时钟下通过内部 PLL 分频给 I2C 外设提供合适的时钟源设置好 rise time 和 fall time 参数后通信就很稳定。初始化 PJ85718DM 的流程并不复杂向器件写配置寄存器把测量模式设置为连续转换还是单次转换。我在一个需要频繁唤醒休眠的系统里用的是单次转换模式每次唤醒之后给传感器发一个启动转换指令等到转换完成标志位置位再读取数据。而在一个一直在线运行的 HVAC 控制板里用连续转换模式更省事每 250ms 读一次数据就行。在配置寄存器时有一个细节容易被忽略PJ85718DM 通常允许用户配置转换精度和转换时间。比如更高精度模式需要更长的转换时间更快模式则牺牲一点分辨率。我用的是中等精度模式分辨率 0.0625℃转换时间约几十毫秒实际在这个应用里完全够用。如果追求更快的响应可以调到低精度模式但温度显示会跳到 0.25℃ 的步进上显示效果看起来不够细腻。3.2 读取本地与远程温度的寄存器流程读取温度数据的流程是标准的 I2C 读操作。先写器件地址加寄存器指针再读两个字节的温度数据。拿到 16 位数据之后要处理符号位。PJ85718DM 的本地温度通道和远程温度通道输出格式一致一般高字节是高 8 位低字节的较高位是小数部分。注意不要把符号位当成数据位算进去很多新手在这里会踩坑导致零下温度换算出来变成很大的正数。我给的换算逻辑很简单读取到的 16 位有符号整数乘以对应的分辨率比如 0.0625℃/LSB就得到实际的摄氏温度。如果芯片支持负温度这 16 位会用二进制的补码表示。在实际代码里我把数据声明为 int16_t 类型再乘以分辨率系数这样就不容易出错了。如果项目里有特殊需求想保留更高精度可以按 1/16 ℃ 的精度直接把数据右移四位毕竟很多温控界面只需要 0.1℃ 的显示分辨率。本地温度和远程温度的读取流程是一样的只是寄存器地址不同。写代码时可以封装一个小函数read_temp(sensor_reg)传入不同的寄存器地址返回温度值。这样主循环里三行代码就能搞定一次完整的采样。不过要注意读取寄存器数据时建议一次把两字节读完避免中间被中断打断导致读了一半的数据。如果用的是 I2C 中断加主循环查询的方式读数据的原子性问题尤其要小心。3.3 本地与远程温度的分时采集策略在一个项目里同时读本地和远程两个温度一般没必要在同一瞬时同时对两个通道进行采样也没有这个能力。更合理的做法是交替采样第一次循环读本地温度第二次循环读远程温度时间间隔保持在几百毫秒。对于 HVAC 这种温度变化速率并不快的系统来说这种方式的实时性完全足够。我实际用过的方案是外部 RTC 中断每 500ms 唤醒一次 MCU唤醒后先切换传感器通道并启动转换然后等待转换完成。转换期间 MCU 继续休眠由传感器转换结束事件或简单的延时来触发下一次读取。这样可以把整个系统的运行电流压得很低因为大部分时间 MCU 都处在 Stop 模式。在这种架构下本地和远程温度的刷新周期各约 1 秒对温控逻辑来说绰绰有余。如果应用场景需要更短的刷新周期比如电机堵转保护那就需要就在连续转换模式里轮询寄存器这种方法也能达到几十毫秒级别的刷新率。3.4 温度数据的滤波与工程转换传感器直接读出来的原始温度数据在实验室环境里很平稳但装到实际设备上以后风扇转动、压缩机启停、继电器吸合都会让读数出现轻微的抖动或毛刺。如果把这个原始数据直接送去显示或者做控制判断数值会在某个区间反复跳变。我用的是简单的滑动平均滤波维护一个长度为 N 的环形缓冲区每来一个新温度就取 N 个数据的平均值作为输出。N 一般取 8 到 16。N 太大会让温度变化看起来滞后严重太小滤波效果不明显。在 HVAC 场景里我用 8 个点的平均值差不多 4 秒的平滑窗口效果很好既能看到温度趋势的变化又不会因为一点电气噪声导致控制逻辑反复触发。滤波之后的数值还需要做工程单位换算。有些项目希望输出的是开尔文或者华氏度有些项目要的是带一位小数的字符串有些需要直接转成 PLC 能识别的原始量。我习惯在底层统一以摄氏度浮点数或定点数来表示在应用层做单位转换。如果你不想用浮点运算——在 Cortex-M0 上浮点确实比较费劲——可以用定点表示比如温度值放大 16 倍用一个 uint16_t 来存显示的时候手动加小数点。这样既保持了精度又避开了浮点运算的开销代码也很直观。实操心得滑动平均滤波的缓冲区初始化建议填上第一个有效读数而不是填 0。如果初始化为 0上电最开始几秒的输出会从 0℃ 慢慢逼近真实温度你会以为传感器坏了。这个小细节我在初版固件里遇到过后来在所有滤波算法里都养成了「用首个有效值预填充」的习惯。4. 校准与误差补偿从实验室到现场4.1 系统误差来源有哪些PJ85718DM 在出厂时已经做过芯片级校准但这并不代表系统整体没有误差。误差可能来自以下几个方面传感器本身的测量误差、远程二极管和规格书推荐模型的差异、PCB 上远程探头走线的电阻不平衡、电源引起的转换误差以及测量点和实际目标位置之间存在物理温差。其中前三项都可以在调试阶段解决最后一项属于系统级的固有偏差需要在软件层面做补偿。芯片自身的测量误差通常在规格书里有明确指标比如 ±0.5℃ 或 ±1℃这是无法通过软件完全消除的但可以通过校准来修正系统性的偏差。二极管差异造成的误差可以通过选择匹配型号来降低。走线电阻不平衡可以通过 PCB 设计规避。如果这些都没问题剩下的就是环境热阻引起的误差了。举个例子你测的是管道内水温但探头贴在管道外壁上那测到的其实是外壁温度和水温有差异这个差异取决于管壁热阻和空气流速。解决方法是把探头放进管道内部或者在软件里加一个经验补偿值。4.2 单点校准与两点校准的实操步骤在实际项目里最常见的是做一个单点校准。取一个可靠的参考温度计比如冰水混合物是 0℃或者精密恒温槽设定在 25℃让传感器系统达到热平衡之后读一次 PJ85718DM 的测量值然后计算偏移量把这个偏移量写到 Flash 中后续所有读数都加这个偏移。这种方法能够消除大部分固定的系统偏差成本很低实现也简单。如果项目要求的温度范围跨度很大比如从 -20℃ 到 85℃并且传感器显示的非线性误差确实存在那就需要做两点校准。分别在低温点和高温点记录偏差然后用线性插值的方式算出中间温度点的补偿值。我做两点校准时习惯在固件里维护一个简单的校准表两个温度点各存一个偏差值实际使用时根据当前温度落在哪个区间做线性插值。这种方法比直接修改传感器寄存器偏移更灵活因为芯片内部的偏移寄存器往往只有有限的调节范围而且每次改寄存器都需要重新计算。软件校准表则不受这个限制适用范围更宽。4.3 远程测温引线电阻的补偿策略远程二极管的引线电阻是整个误差来源中最隐蔽的一个。当远端探头距离较远时引线电阻会导致测量结果偏高或偏低具体方向取决于芯片内部的测量机制。好在 PJ85718DM 这类芯片通常通过电流偏置的方法来测量 Vbe在理想情况下可以抵消引线电阻的影响前提是两条引线的电阻严格相等。如果 D 引线电阻是 5ΩD- 只有 2Ω那测量结果就会产生相对明显的偏差。我遇到过一种说法是直接在 D/D- 之间并联一个小电阻来模拟二极管这种方法没有实际意义因为并联小电阻相当于改变了二极管特性。正确的做法是要么换成阻值更低的导线要么在系统校准时把这个引线带来的偏差折算进去。还有一个细节远程探头如果接到了电源地或者结构金属上可能形成地环路导致读数跳到明显错误的值。排查这种问题时先用万用表量一下二极管两端的电压通常在 0.5V 到 0.8V 之间属于正常如果量出来是 0V 或者接近电源电压说明接线有问题。实操心得远程探头的接线端子要选择抗氧化能力强的材质普通的镀锡端子用久了会氧化哪怕是几欧姆的接触电阻变化也会让远程温度的读数产生肉眼可见的跳动。批量生产时建议用镀金端子或者直接焊接不要图省事压接普通端子。5. 常见问题排查实录5.1 问题一I2C 通信稳定但本地温度读数恒定不变有次调试遇到一个很奇怪的现象I2C 通信正常读取寄存器也正常但本地温度读数一直是同一个值长时间不变化。排查了接线、电源、寄存器配置都没发现问题。后来仔细看了转换启动位才发现PJ85718DM 如果被配置成单次转换模式必须在每次转换完成后重新写入启动位否则芯片会一直输出上一次的转换结果。单纯地循环读取而不重新发起转换读到的自然是旧数据。解决办法很简单在每次读温度之前先写入配置寄存器把转换启动位置 1延时等待转换完成再读新数据。我后来为了省事直接在读取函数内部就完成了「启动转换-等待-读取」三个步骤主循环完全不用关心时序问题。如果你的项目里用的是连续转换模式读取前就不需要再写启动位了。5.2 问题二远程温度读数大幅跳变远程温度显示在 20℃ 和 100℃ 之间来回跳这种问题一般在两种情况下出现。第一种情况是远程二极管没有接好接触不良会导致芯片读到的电压信号不稳定转换结果自然不可信。第二种情况是远程通道的测量时序受到了干扰比如说继电器吸合瞬间产生的电磁干扰耦合到了远程探头的两根线上。如果是接触不良重新焊接端子和补强连接线就能解决。如果是电磁干扰问题我的做法是在软件里对远程温度数据做一个变化率限制相邻两次读取之间的差值超过一个阈值比如 5℃就认为是无效数据丢弃并继续使用上一个有效值。加上这个逻辑之后系统整体的温度显示明显稳定了。5.3 问题三总线上偶发 NACK 应答失败工程样机上 PJ85718DM 在长时间的运行测试中出现偶发的 I2C 无应答这是个挺头疼的偶发问题。后来我用逻辑分析仪抓波形发现故障都发生在中断密集的时刻。STM32L041C6 的 I2C 外设如果在中途被高优先级中断打断恰好此时的 SCL 时序又不能自动补偿就有可能导致该次传输超时。解决办法是降低中断优先级或者把 I2C 的传输过程放在临界区保护。更简单粗暴的做法是把 I2C 时钟从 400kHz 降到 100kHz时序余量大了这个偶发问题就基本消失了。对于 HVAC 应用来说100kHz 和 400kHz 的吞吐能力没有本质区别所以降速是一个非常划算的容错手段。5.4 问题四上电后第一次读数异常大单片机上电后外设和 PJ85718DM 的电源时序可能存在差异。如果 MCU 先开始工作而此时传感器还在复位过程中立刻读取可能会拿到一个垃圾数据。我后来在初始化代码里专门加了一个延时等待传感器上电稳定后再去检测它是否在线再做第一次读取。如果第一次读取到明显异常的温度值比如超过芯片量程直接丢弃用第二次读取的值作为有效启动值。这样做也符合很多通信协议中标准的做法先复位或等待再重试再认定有效。常见问题速查表现象可能原因处理建议本地温度恒定单次转换模式未重新触发读取前重写转换启动位远程温度跳变探头接触不良或电磁干扰加固接线软件增加变化率限幅偶发 I2C NACK时序余量不足或中断干扰降速到 100kHz临界区保护首次读取异常上电时序未稳定加延时和首值丢弃逻辑远程读数整体偏差二极管型号不匹配或引线电阻不等换推荐型号等长走线或校准补偿6. 实测表现与应用场景扩展6.1 实验室和现场实测数据表现在实验室恒温环境下我用这套组合做过一组对比测试。参考温度计精度是 ±0.1℃被测的 PJ85718DM 本地温度通道在 25℃ 附近的读数是 25.18℃偏差约 0.18℃远程通道用 2N3906 短接基极和集电极作为探头读数在 25.20℃ 左右偏差约 0.20℃。考虑到传感器本身的精度指标这个结果属于正常范围。在 -20℃ 和 85℃ 两个边界温度点上偏差稍微大一些用单点校准之后可以控制在 ±0.5℃ 以内这个精度对 HVAC 控制和嵌入式热保护来说足够了。现场环境就复杂一些。装到 HVAC 控制器里之后压缩机和风机的启停会让供电电压短时跌落PJ85718DM 的本地读数在原有偏差的基础上偶尔会出现 0.3℃ 左右的偏移。我给传感器供电端加了电阻电容滤波之后这种偏移基本恢复到了实验室水平。所以建议在做系统级验证时一定要带着负载跑而不是只看裸板数据。6.2 从单一温度监测扩展到多节点方案一套系统只有一个本地加一个远程通道在很多场景下还有提升空间。比如一个 HVAC 集中控制器需要同时测回风温度、出风温度、压缩机管温和控制器板温那就需要多个测温节点。扩展方案很灵活可以用多个 PJ85718DM 接在不同 I2C 地址上如果器件支持地址配置也可以用 STM32L041C6 的多个 I2C 或软件模拟 I2C 来分别读取。还有一种思路是把每个 PJ85718DM 做成一个独立的测温小板通过长距离 I2C 总线或者 RS485 通信协议回传数据。这样 MCU 不需要放在测温现场整个系统就成了一个分布式温控网络。在这个方向继续延伸还可以把温度数据融合进控制策略本地温度作为 MCU 自身健康状态的指标远程温度作为环境控制的主反馈。比如判断远程温度达到目标区间时进入待机模式本地温度超过阈值时降低输出功率或直接报警停机。这里面控制的优先级和时序就可以结合项目的具体需求来设计。实操心得如果你的系统需要两路以上的远程温度测量不用着急换主控。可以先把 PJ85718DM 的本地通道当一个温度点用在 PCB 上把多个二极管探头接到同一个远程通道的复用开关上通过控制开关分时轮询这在小批量产品里是很常见的一种降低成本的玩法。当然如果用复用开关需要额外做通道切换时序切换完成之后要留出足够的稳定时间再读数。7. 一些个人经验总结7.1 关于低功耗设计的具体心得STM32L041C6 的低功耗模式配合 PJ85718DM整套系统实测下来休眠电流可以做到很低的水平。但这不只是 MCU 和数据手册的事板子上每一个元件都在贡献静态电流。比如 I2C 上拉电阻、电源指示 LED 的分压电阻、LDO 自身的静态功耗这些加起来往往会超过 MCU 和传感器本身的休眠电流。所以低功耗设计的关键不是选一个低功耗 MCU而是要整体计算整板静态电流把多余的外围全部控制掉。调试时可以在电源输入处串一个万用表来观察静态电流找出每一个 偷电 的元件。7.2 关于代码架构和可维护性这类项目的代码量虽然不大但也不要图省事把所有逻辑写在一个 main 文件里。我习惯把传感器驱动封装成一个独立模块只提供初始化、读温度、配置三个接口函数底层 I2C 读写通过函数指针注入这样以后换一颗别的传感器只要遵循同一套接口应用层几乎不用改。温度数据交给上层应用之后再封装一层应用逻辑负责滤波、校准、单位换算和状态判断。这种分层思路在前几年我觉得是过度设计但经历过几个版本迭代之后我发现这种结构给维护带来的便利是无法估量的尤其是当项目从功能验证走向小批量还要持续改需求的时候。7.3 调试工具和经验调试这套系统时我强烈建议准备一个逻辑分析仪或者带 I2C 解码功能的示波器观察实际的时序波形。单靠代码里的断点来猜协议问题一般很难定位。另外PJ85718DM 这类芯片的寄存器定义一般比较复杂建议把数据手册里的关键寄存器和比特位做成一个头文件注释方便后续查阅。还有一点测试温度探头时不要用手直接捏着探头前端这样读到的温度其实是手心温度测试场景不具备代表性。把探头固定在恒温块里或者夹在绝缘材料中等待几分钟让温度稳定才能得到可靠的数据。最后再分享一个小技巧硬件设计时把 PJ85718DM 和远程二极管的接线端子都设计成可插拔的调试时可以方便地替换不同型号的探头来做对比。批量生产时把这个可插拔换成焊接连接再把两个接线口靠近布局这样硬件 prototype 阶段和生产阶段的转换成本最小。这套思路不只适用于温度监测项目所有带传感器的小系统都可以参考。