做 HVAC 控制和嵌入式设备的朋友，应该都有过类似的折腾经历：一个系统里既要盯主控板上那一路温度，又要在十几米外的风管、盘管、回风口再放上几个测温点，而且这两类温度还不能简单混为一谈。我最近完成的某一个控制器项目，就是围绕 PIC18F57K42 这颗 MCU 和 PJ85718DM 温度前端来统一处理本地与远程温度监测，覆盖嵌入式设备自身的过热保护，以及 HVAC 场景里的送风、回风、盘管温度采集。这篇文章会把硬件接线、固件配置、校准方法和现场干扰处理完整串一遍，适合正在做环境控制器、风机盘管控制器、空气处理机组控制器的工程师参考。
需要先说明的是，PJ85718DM 从应用定位来看属于数字温度测量前端，常见实现是内部带隙测温核加上数字比较器，通过 I2C 这类接口直接输出温度数据和报警状态。这类器件最大的价值是把模拟量就地数字化，信号抗耦合噪声的能力远强于长距离走模拟信号，这也是我在远程测点上坚持用它而不是直接拉 NTC 线的原因。
1. 这个组合解决的是 HVAC 与嵌入式里最容易被低估的两类测温需求
1.1 本地温度，保护的是主控板与功率器件
本地温度测点在控制器上承担的角色，和远程测点完全是两回事。你现在打开任意一台风机盘管控制器或者空气处理机组控制器的电路板，能看到 MCU、电源 DCDC、通信芯片，有时还有 BLDC 风机的预驱和功率管，这些都是实打实的发热源。如果温度超过器件规格，轻则运行不稳定，重则烧板。
所以本地测温的第一目标不是舒适性，而是保护。在 PIC18F57K42 所在的主控板上，我通常会在以下位置预留测温点：电源芯片附近、功率管或预驱附近、主控芯片封装附近。每个测温点关注的对象不一样，对应的保护动作也不同。功率管附近温度高了，可以先降 PWM 频率或减小占空比；电源芯片附近温度继续上升，就说明散热或负载有问题；主控附近温度异常，多半是机箱风道堵了或环境温度超标。
这里容易犯的错是：把本地传感器设计成只测一个"板温"，然后靠经验漂移估算功率器件温度。实际上功率器件温度变化很快，和板温之间可能差出 20~30 摄氏度，尤其在风机启动和负载突变瞬间。我在另一个项目里就吃过这个亏，板温传感器放在主控附近，功率管已经到 100 摄氏度了，主控周围还在 55 摄氏度，等到报警触发，器件寿命已经受到影响。
1.2 远程温度，才是控制环路的真实反馈
远程温度测点是 HVAC 控制系统真正依赖的控制反馈。回风温度决定室内负荷估算，送风温度用来判定系统有没有满足设定需求，盘管温度则是除霜、防冻和冷媒过热度判断的关键输入。这些测点离主控板少则半米，多则十几米，而且分布在风道、水管的物理边界上。
我接触过的 HVAC 项目里，最典型的一组测点是："回风温度 + 送风温度 + 盘管温度"。回风温度代表空间内实际空气状态，送风温度反映处理后的空气状态，两者差值可以看出空调系统有没有在正常做工。盘管温度则是制冷制热循环里变化最灵敏的信号，结霜、防冻保护都得靠它。
有一个工程问题是很多新手不太注意的：盘管温度和空气温度之间的响应速度差异非常大。盘管表面温度在压缩机启动后几十秒就会掉下来，但送风温度可能要几分钟才稳定。如果你把两类温度同时拿去参与同一套控制逻辑，又用了相同的滤波时间常数，系统会出现剧烈的振荡。正确做法是给不同测点配不同的滤波系数和采样周期，盘管温度这种快变量采样周期可以到 200ms 左右，空气温度 1s 左右即可。
1.3 为什么是 PIC18F57K42 与 PJ85718DM 搭档
PIC18F57K42 是 PIC18 增强型系列里的实用选择，工作电压范围宽，温度等级符合工业需求，外设比较全：ADCC 带计算功能、MSSP 支持 I2C/SPI、UART、DMA、可配置逻辑单元 CLC、PWM 生成器 COG/CWG 都有。这意味着它既能接模拟 NTC 做本地测温，也能通过 I2C 总线挂多片数字温度传感器做远程测温，一套固件里同时管理两类测温架构完全可行。
PJ85718DM 这类数字温度前端，我相中的是两点。第一，数据就地数字化，抗干扰强。远程测点的走线大概率要经过强电区域，模拟小信号会被变频器、接触器干扰得一塌糊涂，数字信号只要保证电平不被严重破坏就行。第二，多个传感器可以挂同一总线上，主控通过地址区分测点，不用为每个远程传感器单独铺线到主控的 ADC 引脚，省下来的 IO 和 PCB 面积很可观。
当然，这个组合也有一个必须先认清的短板：I2C 总线不适合直接做超远距离传输。这个问题我在第二章会专门展开，因为它不是靠调整软件就能解决的，必须在硬件设计阶段就处理掉。
2. 硬件链路设计：远端传感器不是插根线就能跑
2.1 传感器地址与上拉电阻，先给每路测温点分配好身份
在同一组系统里，我会安排两个甚至三个 PJ85718DM 测点，比如主控板上一个作为本地温度，风管盘管各一个作为远程温度。它们挂在同一条 I2C 总线上，靠地址区分。这种数字传感器通常都有地址配置引脚，三根引脚可以组合出多个地址，实际项目中先把地址规划好再画原理图，能省掉后面不少麻烦。
地址规划这件事看起来简单，踩过坑才明白它的重要性。我有一次做样机调试，两个传感器地址配置完全相同，结果读到的数据一会儿是主板温度一会儿是盘管温度，控制逻辑完全混乱，查了整整半天。后来在 PCB 上把地址引脚的接法做成可配置，通过 0 欧电阻或者跳线帽选择地址，基础型号固定用默认地址，升级型号再换地址，生产阶段就很少出错了。
I2C 上拉电阻也是容易被忽略的细节。总线上拉电阻的取值要综合考虑总线上挂了多少器件、走线多长、通讯速率多高。上拉太小，低电平拉不下去，信号被压住；上拉太大，高电平上升沿太慢，高速时就出错。一般做法是先估算总线电容，再选 4.7k 或 2.2k。如果远程线缆比较长，总线电容增加，我会把上拉电阻调小一些，但不能小于驱动能力允许的范围。
此外，传感器的电源不能直接扔给一片式供电就完事。远程传感器所在的线缆如果比较长，有可能会被雷击浪涌或设备启停的电压跌落干扰，我在每个传感器电源引脚旁边都放了 100nF 和 1uF 两个电容，距离超过 3 米的测点还在传感器板上加了一个小功率 LDO。这样传感器的供电噪声降下来，读数的稳定性明显提升。
2.2 远程线缆的电气边界：电容、屏蔽与总线缓冲
我见过不少工程师拿到 I2C 数字传感器后，直接把传感器甩到 10 米外的管道上，结果通讯时好时坏，最后归结为"芯片不稳定"。实际上 I2C 标准规定总线电容通常不能超过 400pF，普通线缆每米分布电容就有 50 到 150pF，算上传感器和主控输入电容，10 米线早就超限了。信号在这种环境下边沿变形，通讯失败是迟早的事。
要解决远程数字测温的 I2C 总线问题，有几种成熟路线。第一是降速，把总线从 400kHz 降到 100kHz 甚至 50kHz，有一定缓解作用，但不治本，距离稍微一长仍然会偶发错误。第二是加总线缓冲器，这类芯片能把 I2C 总线电容隔离成两段，主控侧保持短走线低电容，远程侧线缆电容只要缓冲器能驱动就行，适合几十米内的应用。第三是干脆不用 I2C 做远程传输，改成 RS485 加带远程通讯功能的温度模块，或者用电流输出型测温模块，逻辑上更稳但硬件成本和复杂度都上去了。
我做这类设计的时候习惯设一个分界线：传感器距主控板 1 米以内，直接 I2C；1 到 5 米，降速加总线缓冲器；超过 5 米，就认真考虑 RS485 或 4-20mA 的模块方案。这个分界值不是拍脑袋定的，而是多次实测后得到的经验。远程线缆我一般用屏蔽双绞线，屏蔽层单端接地，并且规定远程线缆必须和动力线分层走线、不要共用线槽。光这一点就能解决掉现场一半以上的偶发通讯故障。
2.3 本地测点的热设计与 ADC 参考选择
本地测点如果只用数字传感器，那就简单很多。但我通常还会留一路 NTC 作为冗余或者做快速响应的板温监测，PIC18F57K42 的 ADCC 模块用来采集 NTC 分压信号。这里先讲一个热设计上的要点：本地温度传感器不要贴在 PCB 边缘，也不要直接放在大铜箔散热区中央，这些位置的温度和主控感知到的实际环境温度差距很大。传感器放在需要保护的功率器件附近，但要留一点距离，避免热源直接辐射导致读数腰斩。
NTC 分压电阻的选型直接决定测温量程和精度。我习惯用 10k 的 NTC，配 10k 精密电阻做分压，工作电流小，自热效应可以忽略。分压电阻的精度建议选 1% 甚至更高，因为电阻本身的温漂会直接叠加到测温误差里。如果项目预算允许，ADC 参考电压用内部固定参考电压 FVR 而不是直接用 VDD，可以避免供电电压波动时产生读数偏移。PIC18F57K42 的 ADCC 支持多个参考源选择，我在实际项目里把 FVR 配置成固定参考电压，后续校准的工作量小了不少。
ADC 参考电压的选择其实藏着一个小坑：如果参考源电压噪声大，所有通道的转换结果都会跟着抖。即便传感器本身很准，ADC 结果也会像心电图一样上下跳。因此硬件设计上，参考源的去耦电容不能省，而且要高精度低温漂的电容。固件上再配合 ADCC 的硬件均值功能，才能拿到稳定的原始值。
3. PIC18F57K42 侧固件：让采集尽量不占主循环
3.1 ADCC 计算模块：自动扫描、累加平均、阈值比较
PIC18F57K42 的 ADCC 计算功能是我比较喜欢的一个外设特性，它可以在后台自动完成多次采样累加平均，而且能在结果超过阈值的时候直接产生中断。这意味着温度采集不需要 CPU 全程盯着，采集任务完全可以后台化。
以本地 NTC 通道为例，我会把 ADCC 配置成 12 位分辨率，开启自动采样功能，在每次转换完成后自动重新触发下一次转换，并且按照设定的次数累加。内部累加单元把多次转换结果加起来再取平均，得到的值已经被硬件滤了一遍，主循环不用每毫秒去服务 ADC 中断。阈值比较功能还可以用来做温度越限报警：配置一个高阈值，当完成后的结果超过阈值时，ADCC 模块自动产生中断，主控快速进入过热保护逻辑。
我先给一段配置思路的示意识别代码，实际寄存器名以 PIC18F57K42 数据手册为准：
// ADCC 初始化示意：12位分辨率，内部FVR参考，自动累加平均 ADCON0 = 0x00; // 关闭ADCC，进入配置阶段 ADCON1 = 0b10000000; // 结果右对齐，累加平均使能 ADCON2 = 0x02; // 采样保持配置，时钟分频 ADREF = 0b00110000; // 正参考选择 FVR ADACQL = 0x1F; // 采样时间设置，保证NTC信号稳定 // 选择模拟通道并启动自动转换 ADCHS = 0x01; // 通道1：本地NTC ADCON0 |= 0x80; // 开启ADCC模块这段配置的核心思路就是把 NTC 的阻值变化尽量平滑、稳定地变成可用的原始数据。ADCC 的自动转换可以在后台持续运行，转换完成后如果要读取结果，直接读取结果寄存器即可，代码非常简单。
还有一个值得用的点是 DMA。PIC18F57K42 支持 DMA 把 ADC 结果直接搬到 RAM 变量里，不需要 CPU 写读取动作。如果项目里面有多个模拟量要采集，比如 NTC 温湿度、压力传感器、电流采样，DMA 加 ADCC 的组合可以把 CPU 负载压得很低，留更多时间给控制算法和通讯处理。
3.2 I2C 状态机轮询：把远程读数做成不阻塞的后台任务
远程数字传感器的读取不能写成阻塞式轮询。如果你的主循环在 I2C 总线等待应答时卡住几百微秒，对控制周期的影响可能不大，但传感器数量一多、通讯偶尔出错需要重试时，阻塞时间会不断叠加。另一个项目里用阻塞读写挂了三路传感器，结果其中一路线缆接触不良时，整个系统的控制周期被拖慢，压缩机保护都差点失效。
正确的做法是用定时器驱动一个状态机，每个时间片只处理一条总线上的一次通讯步骤。比如每 10ms 触发一次调度，主控按顺序处理：发送传感器地址、写命令、等转换完成、读数据。单路操作没有完成就退出状态机，等下一个时间片继续。这样即使一路通讯卡住，主循环永远不会被阻塞。
我这里给出一个简洁的读取流程示意：
typedef enum { SEN_WRITE_ADDR, SEN_WRITE_REG, SEN_READ_DATA, SEN_DONE, SEN_ERROR } sensor_step_t; void sensor_poll(void) { switch (sensor_state) { case SEN_WRITE_ADDR: // 发启动位和传感器地址，写温度寄存器 status = i2c_master_write_byte(dev_addr); break; case SEN_WRITE_REG: // 写寄存器地址和/或触发转换 break; case SEN_READ_DATA: // 读两个字节，组装成温度值，并做完整性校验 break; case SEN_DONE: // 存入滤波缓冲区，切换下一路传感器 break; case SEN_ERROR: // 记录错误计数值，不把异常数据写入变量 break; } }这里最容易被新手忽略的一点是：当 I2C 通讯出现 NACK 或者超时时，绝对不要把旧数据清掉或者直接填入一个 "FFFF" 之类的异常值。我会让上一次有效温度值继续保留，同时给该测点的故障计数加一。只有连续多次失败，才真正认定这个传感器离线。否则现场一次短暂的干扰脉冲，就会让控制系统把温度当成几十度的异常值参与运算，后果可能比传感器离线还严重。
3.3 滤波、超限报警与故障后的 fail-safe 策略
温度数据进入控制逻辑之前，滤波是必须做的一步。即使是数字传感器，远程线缆经过强电区域后，偶尔也会读到跳变的毛刺。如果不过滤直接送到 PID 或保护逻辑里，很容易让执行机构来回动作。
一阶低通滤波是性价比最高的做法，公式是y += (x - y) / N，N 根据采样周期和系统时间常数来定。对空气温度这类慢变量，N 可以取大一点，让响应平缓；盘管温度这类快变量，N 取小一点，让保护逻辑能及时响应。还有一个更实用的方法是滑动中值滤波：把最近 5 次读数排序取中值，能非常干净地去掉单点毛刺，代价是内存多一点。
超限报警要分优先级。HVAC 里的盘管防冻属于安全级别，一旦盘管温度低于阈值，必须立即执行防冻动作或者停机警告。回风温度传感器失效，则是一个运行质量问题，系统可以不立即停机，但要把控制模式切换到安全默认值，比如按设定容量运行并报警。不同测点的 fail-safe 策略一定要提前设计好，不能在故障发生时才临时决定。
我在这类系统里配置了三级故障状态：传感器正常、传感器可疑、传感器离线。可疑状态是连续 3 次读取异常，这时继续使用上一次有效值但提高巡检频率；离线状态是连续 10 次读取异常，此时切换安全模式并上报故障码。这样既能容忍瞬间干扰，又不会让传感器彻底失效时系统毫无察觉。
4. 从寄存器读数到可信温度：校准、实测与 HVAC 干扰
4.1 多点校准：把传感器偏差和安装误差拆开看
数字温度传感器一般出厂前做过校准，但具体到某一颗器件、某一种安装方式，仍然会有偏差。更关键的是安装误差，比如传感器套管里没填导热硅脂、探头和被测表面之间有空气缝隙，都可能造成几摄氏度的误差。因此在系统联调阶段，校准不是可选项。
我做校准的方法是先建一个目标温度表，覆盖这个测点在真实工况里的范围。以 HVAC 应用为例，通常会校准 0 摄氏度（盘管防冻点附近）、25 摄氏度（环境温度附近）、50 摄氏度（送风或排风高温点）。使用恒温槽或者干体炉设定稳定温度，把传感器放进去等读数稳定后，记录当前计算出的显示温度和标准温度之间的偏差。
对数字传感器来说，偏移校准通常就是写入一个 offset 参数。但如果跨三个点校完发现偏差不是恒定的，即是线性度问题，这时不能只做零点偏移。常用的做法是线性两点校准，算出增益和偏移，固件里calib_temp = raw_temp * A + B。如果三个点之间的残余误差还很大，就得怀疑探头安装方式或者传感器本身选型是否正确，而不是继续加高阶曲线拟合，否则会把安装问题的责任混淆掉。
4.2 强电场合下的远程读数问题：从实测数据看对策
HVAC 设备现场是出了名的干扰密集场所：接触器吸合、压缩机堵转、变频器 PWM 输出，每一个动作都会通过电源线、动力线向周围辐射噪声。远程温度线缆如果和动力线平行走线几米，线上感应出的共模电压会直接打进 I2C 总线，导致读数跳变甚至通讯失败。
我在实际项目中做过一次对比测试。远程传感器经 3 米屏蔽双绞线连接主控，附近开启一台变频风机。刚开始总线速率设在 400kHz，持续几分钟后就会出现偶发 NACK，读回来的温度偶尔跳到 127 度。把速率降到 100kHz 之后，连续运行半小时没有报错。后来又把线缆改成从动力线另一侧单独走线槽，速率恢复到 200kHz 也没再出现过通讯错误。这说明干扰问题往往是物理布局和电气速率共同作用的结果，单靠软件改哪一头都只能缓解，不能根治。
远程传感器的供电也要重点处理。干扰最容易从供电线进来，我会在远程传感器板上放一个 LDO 或 LC 滤波，在电源引脚附近放 TVS 管。对于高可靠场合，传感器供电还可以单独用一路受控电源，出现故障时主控可以断开传感器电源复位它，比单纯发送总线 reset 命令更有效。
关于干扰防护，我最想提醒的一点是：远程线缆屏蔽层接地的位置不能乱接。一般做法是屏蔽层单端接地，也就是靠近主控一端接地，传感器端不接地，避免形成地环路。如果你把两端都接地，屏蔽层里反而会有工频环流，干扰更严重。现场排查过几次通讯异常，最后发现就是屏蔽层两端接地引起的。
5. 这套方案落地时值得注意的经验
5.1 从原型到样机的几个典型坑
原型阶段大家喜欢用杜邦线接传感器，距离短、环境干净，什么问题都没有。一到样机，线缆变长、走线靠近动力线、现场环境温升一上来，问题集中爆发。我见过最典型的几个坑，列出来供参考。
第一个坑是 I2C 上拉电阻重复。有的传感器评估板上自带 4.7k 上拉，主控板上又放了一组，两块一接，上拉电阻并联后总阻值太低，导致总线低电平都拉不下去，通讯更不稳定。我现在的习惯是原理图评审时明确：只有主控板放上拉电阻，传感器子板不加上拉，或者通过跳线决定是否安装。
第二个坑是地址冲突。多个远程传感器如果型号相同又没配地址，数据会串位。这个问题如果放在现场才发现，拆设备改跳线的成本非常高，所以我在固件里加了传感器地址自检，上电后逐个读取传感器 ID 和地址，发现重复就报错并拒绝进入运行模式。
第三个坑是异常温度值参与控制。有一次现场报告空调系统明明很热还在不停制冷，查到最后发现是回风温度传感器线缆接头松动，偶发读到 5 摄氏度，控制逻辑认为室内过冷就继续制冷。后来我在所有温度进入控制逻辑前加了一道合法性检查：超过合理范围直接拒绝并走 fail-safe 分支，类似问题彻底不再出现。
5.2 把温度数据用起来：从采集到风机与加热控制
温度监测如果只是把结果显示在界面上，价值很有限。在 HVAC 控制器里，温度数据的尽头是风机转速、压缩机启停、加热器 PWM 输出这些执行动作。PIC18F57K42 的 COG/CWG 模块可以生成互补 PWM，用来驱动半桥或全桥，把温度控制映射到变频风机非常自然。
我做了一个比较通用的温度到 PWM 映射：采样回风温度与设定温度，得到偏差，经过温度 PID 计算后输出占空比给 COG。温度变化慢，控制周期设在 500ms 到 1s，PWM 频率放在 20kHz 左右避开人耳可听范围。温度环的输出再级联到风机转速环，实现无级调速。
这个架构里有一个容易犯的问题：把温度环的控制周期和 PWM 周期混淆。温度环周期长没问题，但 PWM 周期必须足够快才能让风机平滑转动。两者是独立的定时器资源，不能放在同一个中断里处理。PIC18F57K42 的定时器资源足够多，完全可以把温度环、通讯轮询、PWM 再生分成三个不同的时间片。
5.3 固件架构上给传感器换型留好退路
不同项目对传感器精度的要求不一样，有的用普通数字温度传感器就够，有的需要更高精度型号，有的现场就认 NTC 加 AD 的模拟方案。固件架构上如果不做抽象，产品换代时驱动逻辑要重写一大片。
我现在的习惯是在固件里定义统一的测点接口，比如sensor_read(point_id, &temperature)、sensor_status(point_id)，外部控制逻辑完全不感知底层是 I2C 数字传感器还是 ADCC 采集 NTC。底层驱动做成两套，通过一个配置表把每个测点映射到不同的驱动实现。这样以后想换传感器型号，只需要新增一个驱动文件，改配置表，控制逻辑完全不用动。
另外，校准参数、传感器地址、滤波系数这类参数不要写死在代码里，而是放在数据存储区，生产时通过串口或工装写入。这样同一套固件可以支持不同器件的微调，现场替换传感器也不必重新烧录程序。我最初把传感器地址直接定义成宏，后来发现每片板的地址要单独区分，只能频繁改宏重编译，浪费了很多时间，现在统一改成运行配置管理。
最后再分享一个我反复用到的技巧：在校验台上给同一测点做校准后，把校准日期、校准人员、校准系数一并存回去，现场维护时可以直接读出传感器的校准历史。这套做法花不了多少工作量，但能把现场排查时间压缩一大截。温度链路看起来只是"读寄存器-算温度"两件事，真正让它稳定的，往往是你在这个链路上做过多少预防性的设计。
