嵌入式HVAC双路温度监测：PJ85718DM与MK20DN128VFM5实战

1. 从一颗温度传感器说起：为什么本地与远程双路监测在嵌入式 HVAC 里绕不开

做嵌入式 HVAC 控制板的人都有一个共识：温度采样不准，后面所有控制逻辑都是空中楼阁。不管是压缩机启停、风机调速，还是电子膨胀阀开度调节，全都建立在"当前温度到底是多少"这个基础判断上。问题在于，HVAC 场景的温度监测从来不是单点的事——你既要知道控制板自己所在位置的温度（本地温度），也要知道被控区域或者远端出风口的温度（远程温度）。这两路温度如果只靠一颗传感器硬扛，要么布线成本高得离谱，要么采样精度被线路压降和噪声吃掉。

我手头这个项目用的组合是 PJ85718DM 加 MK20DN128VFM5。前者是一颗远程温度传感器接口芯片，后者是一颗带丰富外设的微控制器。这套搭配的核心思路很清晰：MK20DN128VFM5 负责本地温度采集和整体控制逻辑，PJ85718DM 负责把远端那颗测温器件的信号可靠地读回来，两者通过片上外设完成数据交互。说白了，就是让"本地"和"远程"各司其职，再由主控统一做融合判断。

这套方案适合谁看？如果你正在做 HVAC 控制板、嵌入式温度采集模块，或者任何需要同时监测板载温度和远端温度的场合，这篇内容可以直接拿去参考。我会把选型逻辑、硬件连接、寄存器配置、采样时序、滤波处理、常见故障排查这些环节全部拆开讲，尽量做到你照着做就能跑通。

先给一个整体判断：本地温度用 MCU 内部或板载传感器采，胜在响应快、成本低、不受长线干扰；远程温度用专用接口芯片配远端测温器件，胜在布线灵活、抗干扰强、可以覆盖几米甚至十几米的距离。两者结合，才是 HVAC 这种"控制板在机房、测温点在风道"场景的合理答案。

2. PJ85718DM 与 MK20DN128VFM5 的分工逻辑：谁采本地，谁管远程

2.1 为什么不让 MCU 一个人把两路都干了

很多人第一反应是：MK20DN128VFM5 本身就有 ADC，我直接拉两根长线到远端测温器件上不就行了？理论上可以，实际做起来问题一堆。长线传输的是模拟小信号，走几米之后，线阻、分布电容、工频干扰、地电位差全来了。你 ADC 分辨率再高，前端信号已经被污染，采回来的值漂得没法用。更麻烦的是，HVAC 设备里继电器、接触器、变频器一大堆，电磁环境相当恶劣，模拟长线基本等于给自己找罪受。

PJ85718DM 这类远程温度接口芯片的价值就在这里：它把远端测温器件的信号在本地做调理和数字化，MCU 拿到的是相对干净的数字量或者经过缓冲的稳定信号，不用直接面对长线模拟信号。这就好比你在嘈杂的车间里打电话，与其扯着嗓子喊（模拟长线），不如两边各放一个对讲机（接口芯片做信号调理），传过来的声音清楚得多。

2.2 本地温度通道的设计取舍

本地温度这块，MK20DN128VFM5 有几种做法。一是用 MCU 内部温度传感器，优点是零成本、零布线，缺点是精度一般，通常只能到正负几度，而且受芯片自身发热影响大。二是外挂一颗板载数字温度器件，比如常见的 I2C 或 SPI 接口测温芯片，精度能到零点几度，响应也快。三是用热敏电阻加分压，再进 ADC，成本最低但需要做线性化和校准。

在这个项目里，本地温度我倾向于用板载数字温度器件走 I2C。原因很直接：HVAC 控制板的本地温度通常用来做冷热补偿或者板级过温保护，精度要求比远程温度还高一点，因为它是控制算法的基准参考。MCU 内部传感器那点精度，做保护阈值判断勉强够，做精细控制就力不从心了。用 I2C 数字器件，读数直接是摄氏度，省掉 ADC 采样和换算，软件上也清爽。

2.3 远程温度通道的信号链路

远程这边，PJ85718DM 的角色是接口和调理。远端放一颗测温器件，通过双绞线或者屏蔽线连回控制板，PJ85718DM 负责激励、采样、线性化，最后把结果交给 MK20DN128VFM5。这条链路里，线材选择和接地方案比芯片本身还关键。我踩过的坑是：一开始图省事用了普通排线，结果远端读数每隔几秒就跳一下，后来换成屏蔽双绞线，屏蔽层单端接地，跳动立刻消失。这个细节后面会专门展开讲。

MK20DN128VFM5 和 PJ85718DM 之间的交互，可以用 SPI 或者 I2C，具体看接口芯片支持哪种。SPI 速度快、时序可控，适合对采样实时性要求高的场合；I2C 省引脚，适合多器件挂载。这个项目里我选 SPI，因为远程温度需要周期性高频采样，SPI 的时钟速率和全双工特性更合适。

3. 硬件连接与关键参数：把两颗芯片正确接起来

3.1 电源与去耦的细节

MK20DN128VFM5 和 PJ85718DM 的供电要分开考虑。MCU 通常 3.3V，接口芯片要看手册，有的支持 3.3V 有的要 5V。如果两者电压域不同，中间的电平匹配必须做，否则轻则通信不稳，重则烧引脚。我一般会在接口芯片电源脚旁边放一颗 0.1uF 陶瓷电容加一颗 10uF 钽电容，前者滤高频，后者稳低频。这个组合看起来老生常谈，但实测下来，省掉钽电容的那一版，远程读数在继电器动作瞬间会有明显毛刺。

去耦电容的摆放位置也有讲究。0.1uF 必须紧贴芯片电源引脚，走线越短越好，最好和地引脚形成最小回路。10uF 可以稍微远一点，放在电源入口附近。很多人把电容放在板子另一头，觉得反正连上了就行，结果高频噪声照样窜进芯片。

3.2 远程测温器件的接线方式

远端测温器件到 PJ85718DM 的接线，推荐用屏蔽双绞线。两根信号线绞在一起，能有效抵消共模干扰；屏蔽层只在控制板这一端接地，远端悬空。为什么远端不接地？因为两端接地会形成地环路，地电位差产生的环流反而引入噪声。单端接地是这类长线信号处理的常规做法。

线长方面，双绞屏蔽线走十米以内一般没问题，再长就要考虑加中继或者改用差分传输。线径不要太细，0.2 平方毫米以上比较稳妥，太细的线阻大，激励电流流过会产生压降，影响远端器件的工作点。

3.3 SPI 通信的引脚分配与走线

MK20DN128VFM5 和 PJ85718DM 之间的 SPI，四根线：SCLK、MOSI、MISO、CS。走线尽量短，尽量等长，尤其是 SCLK 和 MISO，时钟和数据之间的偏斜会影响采样窗口。如果板上空间允许，SCLK 和 MISO 之间可以走一根地线做隔离，减少串扰。

CS 片选线要注意上电默认电平。有些接口芯片 CS 浮空时会误触发，所以 CS 最好加一个上拉电阻，保证 MCU 还没初始化完成时芯片处于未选中状态。这个细节在调试阶段特别重要，我就遇到过因为 CS 浮空导致接口芯片上电后乱发数据，MCU 一读就死机的情况。

4. 寄存器配置与采样时序：让数据稳定读回来

4.1 MK20DN128VFM5 的 SPI 初始化

MK20DN128VFM5 的 SPI 配置，核心是时钟极性和相位。PJ85718DM 手册里会写明它支持哪种模式，通常是模式 0 或模式 3。模式选错，读回来的数据全是错位的。我一般先用低速时钟跑通，比如 1MHz，确认数据正确后再往上提。HVAC 场景对采样速率要求没那么极端，1MHz 到 4MHz 完全够用，没必要为了快而牺牲稳定性。

初始化顺序也有讲究：先配置 GPIO 复用为 SPI 功能，再配置 SPI 控制寄存器，最后使能 SPI。顺序反了，可能出现引脚状态未定义时 SPI 就已经开始工作，产生误码。这个坑我在早期项目里踩过，后来养成习惯，所有外设初始化都按"时钟使能、引脚复用、外设配置、外设使能"四步走。

4.2 PJ85718DM 的通道配置

PJ85718DM 内部一般有多个通道，可以接多个远端测温器件。配置时要明确：用哪个通道、激励电流多大、采样周期多长、是否开启断线检测。激励电流的选择和远端器件有关，电流太小信号弱，电流太大自身发热影响精度。通常手册会推荐一个范围，比如 100uA 到 1mA，我一般取中间值，兼顾信噪比和自热。

采样周期要和 HVAC 的热惯性匹配。温度变化本来就慢，没必要每秒采几百次。我通常设成 100ms 到 500ms 一次，既跟得上温度变化，又不给 MCU 增加无谓负担。如果做快速保护，可以单独开一路高速采样，但那是特例。

4.3 采样时序的完整流程

一次完整的远程温度采样，流程是这样的：MCU 拉低 CS，发送通道选择命令，等待接口芯片转换完成（可以查询状态位或者用固定延时），然后发送读命令，把转换结果读回来，最后拉高 CS。这个过程中，转换等待时间必须留够，手册里给的典型值要往上取，别卡着最小值用，温度、电压波动都会影响转换速度。

读回来的原始数据通常是 ADC 码值，需要按手册公式换算成温度。换算公式里一般有参考电压、增益、偏移这些参数，这些参数要么是固定值，要么需要校准。我强烈建议在量产前做一次两点校准，用一个高精度温度源，在低温和高温两个点各测一次，算出实际的增益和偏移，写进 MCU 的配置区。这样能把个体差异和批次差异都压下去。

// 伪代码示例：SPI 读取远程温度 uint16_t read_remote_temp(void) { uint16_t raw; uint16_t temp; CS_LOW(); spi_transfer(CMD_SELECT_CH0); // 选择通道 0 delay_ms(50); // 等待转换，按手册留足余量 raw = spi_transfer16(CMD_READ_RESULT); // 读转换结果 CS_HIGH(); // 换算：假设手册给出 temp = (raw * Vref / Gain - Offset) / Sensitivity temp = convert_to_celsius(raw); return temp; }

5. 本地与远程数据的融合处理：滤波、校准与故障判断

5.1 为什么原始数据不能直接用

不管是本地还是远程，采回来的原始温度值都带着噪声。本地数字器件好一点，但也不是绝对干净；远程经过长线，噪声更明显。直接拿原始值去做控制，执行机构会频繁抖动，压缩机启停过于频繁，寿命直接受影响。所以滤波这一步不能省。

滤波方法有很多，最简单的是算术平均，采 N 次求平均。缺点是响应慢，N 大了滞后明显。好一点的是滑动平均，维护一个队列，每次新数据进来挤掉最老的，既平滑又不会太滞后。再讲究一点可以用一阶低通滤波，公式是y = y + alpha * (x - y)，alpha 越小越平滑但越滞后。HVAC 温度这种慢变量，一阶低通配 alpha 在 0.1 到 0.3 之间，实测效果很好。

5.2 本地与远程的交叉校验

两路温度放在一起，还能做一件有价值的事：交叉校验。正常情况下，本地温度和远程温度的差值应该在一个合理范围内。如果差值突然超出预期，说明某一路可能出问题了。比如远程线断了，读数会跳到量程端点；本地器件坏了，读数可能卡死不变。通过监测两路温度的差值和变化率，可以做出初步的故障判断。

我一般会设两个阈值：一个是差值阈值，比如两路温差超过 15 度就报警；另一个是变化率阈值，比如单次采样变化超过 5 度就标记可疑。这两个条件同时满足，基本可以确定有故障，这时候系统可以切到安全模式，比如停压缩机、开风机、报故障码。

5.3 校准数据的存储与调用

校准参数要存在非易失存储器里，MK20DN128VFM5 内部一般有 Flash 或者 EEPROM 模拟区。存储时要注意：写入前先擦除，写入后做校验，最好存两份互为备份，防止写坏。读取时如果发现校验失败，就回退到默认参数，同时报一个校准丢失的警告。

校准的时机也有讲究。出厂校准一次，现场安装后如果条件允许，最好再校一次，因为现场的实际线长、环境温度和出厂测试台不一样。现场校准可以用一个已知温度点做单点偏移修正，简单有效。

6. 实测中遇到的坑与排查链路

6.1 远程读数周期性跳变

现象：远程温度每隔几秒跳一下，幅度一两度，本地温度稳定。排查链路是这样的：先看是不是电源问题，用示波器看接口芯片电源脚，发现继电器动作时有明显跌落，加了大电容后改善但没根除。再查接线，发现用的是普通排线，换成屏蔽双绞线后跳动消失。根因是长线耦合了继电器动作产生的干扰。这个坑告诉我，HVAC 板上的长线信号，屏蔽和接地比什么都重要。

6.2 SPI 通信偶发误码

现象：大部分时间读数正常，偶尔读回一个明显错误的值。排查时先降 SPI 时钟，误码率下降但没消除。后来用逻辑分析仪抓波形，发现 MISO 上的数据在 CS 拉高瞬间有毛刺，原因是 CS 和 SCLK 走线太近，串扰导致。把两根线拉开距离，中间加地线隔离，问题解决。这个经验是：SPI 走线别图省事，该隔离就隔离。

6.3 本地温度受 MCU 自热影响

现象：本地温度比实际环境温度高两三度，而且随 MCU 负载变化。原因是用了 MCU 内部温度传感器，芯片自身发热影响了读数。解决办法是改用板载独立温度器件，远离 MCU 和电源等发热源。如果非要用内部传感器，就要做负载补偿，但补偿模型很难做准，不如换器件省心。

7. 这套方案还能怎么扩展

把本地和远程温度监测跑通之后，扩展方向其实不少。一是增加远程通道数，PJ85718DM 如果支持多通道，可以同时监测多个区域的温度，做分区控制。二是把温度数据通过通信接口上传，接入更上层的监控系统，做集中管理。三是结合湿度、压力等其他传感器，做焓值计算，控制精度还能再上一个台阶。

我在实际项目里的体会是，温度监测这块，硬件选型和布线决定了上限，软件滤波和校准决定了实际效果。两者都做到位，读数才能既准又稳。如果只重视一边，要么硬件底子差怎么调都不行，要么硬件很好但软件粗糙，白白浪费了器件的性能。这套 PJ85718DM 加 MK20DN128VFM5 的组合，硬件底子是够的，剩下的就看你在配置和校准上花多少心思了。