企业官网建设流程全解析

前一阵子朋友问我要一套能同时看本地控制板和远端风管温度的小方案，我顺手用 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 模式和单总线模式的引脚分布如下表，有兴趣直接照抄也行。

I2C 总线的上拉电阻阻值需要根据总线长度和节点数量选。板内走线很短，两个传感器直接焊在主板上，我用 2.2k 上拉到 3.3V，实测波形干净。如果总线上挂的设备变多，比如超过 4 个，建议把电阻降到 1.5k 左右，避免边沿太缓影响通信时序。

单总线模式则注意 DQ 线上接 4.7k 上拉。远程线缆比较长时，总线电容变大，上拉电阻太小会把低电平拉不低，太大又会让上升沿变慢，具体阻值要根据线长微调。3 米以内的线缆用 4.7k 基本稳妥，5 米以上建议换 2.2k 并在远端并一个小电容，下面会细说。

2.2 本地监测的最小电路与 PCB 布板

本地传感器和 MCU 在同一块板上，电路很简单。PJ85718DM 的 VCC 接 3.3V，GND 接系统地，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 读不到数据最常见的原因是忘了给 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 用起来，让温度数据直接参与风机转速闭环控制，到时候再分享一版带控制算法的升级实现。