PJ85718DM与PIC18F85J10协同的HVAC远程温度采集方案

1. 项目要解决的核心问题本地温度为什么不能当远程温度来用接到这个项目需求时客户的要求只有一句话在嵌入式控制板上测本地温度同时把远端探头位置的温度也测出来用于 HVAC 设备联动。听起来简单可一旦细化到“本地”和“远程”这两个词工程细节就完全不一样了。距离、线缆、电磁干扰、传感器供电、总线拓扑每一环都可能让温度数据从“看着对”变成“根本没法用”。这套方案的核心器件是 PJ85718DM 和 PIC18F85J10。PIC18F85J10 属于高性能 8 位单片机引脚多、片上外设全适合作为整个 HVAC 控制器的主控PJ85718DM 则作为前端温度采集模块负责规整本地传感器和远程总线传感器。把“采集温度”这件事从前端到主控做成一条清晰通路后续的显示、风机控制、压缩机启停才有可靠的数据依据。为什么要特意区分本地和远程因为两者的电气环境差别很大。本地传感器贴着主板放线缆短、信号稳直接用 I2C 或者 SPI 读最快。远程传感器可能部署在风管、室外机、房间角落线长几米甚至几十米如果用普通 I2C 拉长线时序会被线缆电容拖垮通信错误率猛增。这种场景必须换思路用带收发驱动、能容忍长线传输的总线方式或者是带远端地址的传感器节点方案。PJ85718DM 的价值就是把这些差异封装起来主控统一通过寄存器去操作底层协议的变化尽量被屏蔽。1.1 HVAC 场景里最常见的两组温度测点结合我实际做过的类似项目HVAC 设备的温度测点大体可以分成两组。第一组在主板附近比如控制板进风口温度、电源模块表面温度、通讯模块周围温度。这组测点离 MCU 很近几厘米到几十厘米适合用板载传感器或者 I2C 总线上挂着的小封装传感器。第二组则分布在需要被控温的真实环境里比如回风温度、送风温度、室外环境温度、管道内温度它们通常位于设备壳体外侧甚至单独拉线到房间中间去。第一组测数据的目的多半是保护电子硬件防止板级过热第二组才是真正的空调控制依据。在调试现场我发现很多新手只接了一路回风温度就把压缩机控制写死了结果送风温度没检测冬天热风直接把房间烤过头。设计架构时至少要预留两路以上远程测点而且远程通道要具备扩展能力方便后续增加探头。用 PJ85718DM 做前端管理的好处是它天然自带多通道采集逻辑把本地传感器的轮询和远程传感器节点的地址管理放在一个模块里主控不需要频繁中断去处理位时序。这样在 HVAC 主循环里温度刷新可以做到毫秒级稳定不太影响其他控制任务。1.2 PIC18F85J10 和 PJ85718DM 各自承担什么角色PIC18F85J10 这颗片子最大的优势是资源均衡。它有充足的外部引脚可以同时接 PJ85718DM 的数字接口、LCD 显示、按键、风机调速 PWM、继电器控制预留 UART 口做通讯调试也不显得拥挤。片上自带多个定时器和硬件串行外设不需要全部用 GPIO 模拟时序。如果换成一颗小封装单片机引脚规划和中断优先级就会很痛苦HVAC 这种需要多种外设协同的场景很容易翻车。PJ85718DM 在我这里扮演的是“采集前端”的角色。它可以连接若干个本地数字温度传感器同时管理一条远程传感器总线把不同物理位置的传感器统一编址。主控只需通过标准寄存器接口下发指令比如“读取 2 号通道温度”PJ85718DM 内部就会完成启动转换、等待读数、错误重试最后把结果放到数据寄存器里。主控利用 I2C 或 SPI 把数据取回来就行。这种“主控前端”的分工比让主控直接操作一堆传感器更稳。主要原因在于主控的工作负担不只是读温度还要跑 PID 算法、处理通讯协议、驱动继电器如果把传感器时序细节都堆到主控里一旦线缆干扰导致时序重试主控实时性就会崩。PJ85718DM 挡在中间脏活累活它干了主控只拿到干净的结果。2. 硬件链路搭建主控、PJ85718DM、传感器三者怎么接2.1 系统拓扑结构整体链路设计上我分了三层。最底层是传感器层包括板边沿的本地传感器和多处远程探头中间层是 PJ85718DM负责采集和总线调度最顶层是 PIC18F85J10负责控制逻辑与人机交互。链路的物理连接大致是这样PIC18F85J10 通过一组 SPI 或 I2C 与 PJ85718DM 连接这属于主控与前端模块之间的高速内部总线。PJ85718DM 向下本地传感器接入其 I2C 扩展口远程传感器则接到它的串行总线接口上。远程总线上可以挂多个地址不同的探头具体数量由 PJ85718DM 的地址空间决定实际项目中我通常挂 4~8 个太多会增加轮询周期降低实时性。有一点要明确PJ85718DM 承担的是“采集并整理”PIC18F85J10 承担的是“决策并使用”。温度数据不是拿来显示的而是用来风机调速、压缩机通断、报警输出的。因此软件上必须把温度读取函数设计成同步阻塞还是异步轮询要提前想清楚。我建议用轮询方式因为采集周期本身只有几十毫秒在 HVAC 这种毫秒级控制场景里阻塞几百微秒完全可接受状态机反而能简化。2.2 电源、上拉电阻与布线规范硬件布线是整个项目里看似不起眼、实际上最容易出问题的部分。PJ85718DM 和传感器的供电我建议统一用 3.3V 稳压轨前提是传感器本身支持 3.3V。远程探头如果距离长则需要考虑线上压降必要时用 5V 供电、信号接口加电平转换。远程传感器在现场经常遇到的问题是供电不足导致转换结果偏移不是传感器坏了而是远端电压跌到了传感器的最低工作电压以下。总线电阻方面本地 I2C 接口上拉电阻我习惯选 4.7kΩ 到 10kΩ这要看挂载数量。但远程总线延长之后线缆电容会变大4.7kΩ 上拉带来的上升沿可能不够换成 1kΩ~2.2kΩ 通常会改善。不过上拉太小会增加静态功耗长线反射和振铃也可能出现需要示波器实测。我在自动化测试平台实测过15 米双绞线、2.2kΩ 上拉、波特率 9600波形还比较干净如果波特率拉到 38400 以上远端设备基本就很难稳定同步。在 PCB 布局上建议把 PJ85718DM 靠近 PIC18F85J10 放置中间信号线不要太长避免高速 SPI 信号形成环形天线。传感器走线远离继电器和压缩机驱动电路尤其是感性负载切换时会产生高压尖峰地线处理不好会把温度数据干扰得跳来跳去。输出级加 RC 吸收或者压敏电阻传感器走线加磁珠隔离这些措施对 HVAC 现场设备来说不是可选项是必要项。2.3 关键引脚分配参考具体引脚分配上每个项目会有差异但大的思路是一致的。我提供一个实际用过的规划作为参考PIC18F85J10 的 SPI 片选接给 PJ85718DM作为模块的唯一控制入口另一组普通 GPIO 用于 PJ85718DM 的中断输出和复位控制。本地传感器如果挂在 PJ85718DM 的 I2C 通道上这个通道仅限板内不延伸出去远程总线则单独占用一组带收发器驱动的 UART 或者专用 1-Wire 端口具体看传感器类型。主控侧的 PWM 通道预留至少两路一路给风机一路备用水泵或电加热不要在后期才想起没有多余 PWM。LCD 显示可以用并行或 SPI 方式能省引脚就省引脚。所有预留的 UART 至少留一个给调试器用这在后期排查问题时能省大量时间。3. 软件驱动实现初始化、读取、换算和出错重试3.1 PJ85718DM 寄存器操作流程PJ85718DM 对外的工作方式我按寄存器来理解上手会很快。模块内部主要有控制寄存器、状态寄存器、数据寄存器、地址配置寄存器几类。操作流程通常是这样先通过 SPI 写控制寄存器选择要读取的通道并启动温度转换然后轮询状态寄存器看转换是否完成完成后读取数据寄存器的高低位。如果是远程多通道节点还需要先写通道地址再发出读取命令等待节点返回结果。给一段我实际调试过的初始化代码框架可以直接作为参考模板#define PJ_CS_PIN LATBbits.LATB2 #define PJ_SPI_CLK LATBbits.LATB1 #define PJ_SPI_SDO LATCbits.LATC6 void pj_write_reg(uint8_t addr, uint8_t val) { PJ_CS_PIN 0; spi_write_byte(PJ_CMD_WRITE | addr); spi_write_byte(val); PJ_CS_PIN 1; __delay_us(10); } uint8_t pj_read_reg(uint8_t addr) { uint8_t tmp; PJ_CS_PIN 0; spi_write_byte(PJ_CMD_READ | addr); tmp spi_read_byte(); PJ_CS_PIN 1; return tmp; }初始化阶段我习惯先复位模块然后读取模块 ID 寄存器确认通信建立正常。这一步一定要做很多看似“传感器读数不对”的问题其实是主控和前端模块之间的 SPI 时序都没对齐地址和数据全都错位。读模块 ID 等于给整套通信链路做一个心跳检查虽然浪费几个毫秒但能大大缩短硬件排错时间。读取温度的逻辑我封装成了独立函数返回原始值和处理后的温度值。主控主循环里只管调用这个函数不用关心底层时序。每轮采集结束把数据放到公共变量区供显示刷新和控制算法使用。3.2 温度数据解码与线性换算不同的温度传感器原始数据格式会不一样。比较常见的是 12 位二进制补码单位为 0.0625°C高位字节在前低位字节在后的组织方式。真实温度的计算公式是这样实际温度 (原始值 4) × 0.0625°C当原始值为负数时需要按补码先取反再加 1再换算。用代码表示float temp_raw_to_celsius(int16_t raw) { float t (float)raw * 0.0625f; return t; }在 HVAC 控制里这个 0.0625°C 的精度基本够用。现场控制精度要求通常在 ±0.5°C 以内毕竟空调系统本身的滞后效应很大。如果对精度要求更高可以做两点校准。把传感器放在冰水浴和沸水浴里记录原始值然后建立线性校正公式把偏移和斜率修正到代码里。批量生产时每个通道的校准参数建议存储在外部 EEPROM 或 PIC18F85J10 的数据 EEPROM 里这样换板不换探头校准值不丢。这里要说个容易被忽略的点温度换算结果不要频繁做浮点运算。主循环每 100ms 读一次温度每次都做浮点换算虽然单个耗时不大但累积起来会影响其他实时任务。我的做法是先把原始值保存下来只在显示和控制计算时再做一次换算中间过程尽量用整数运算。3.3 数据校验与异常值剔除温度和电流、电压不同它的变化趋势是缓慢的正常情况下相邻两次采样之间的差值不会很大。利用这个特点可以做一个简单的异常值剔除如果某次采样值和上一次数值之差超过阈值比如 5°C先不要立刻采用而是连续再读两次两次结果互相接近才采信否则上报传感器故障。这种软件滤波在 HVAC 现场特别管用。工业环境里变频器、接触器吸合瞬间会产生强烈的电磁干扰传感器线如果恰好靠近动力线ADC 转换结果就可能出现毛刺。做过一次软件滤波之后毛刺对控制逻辑的影响能降到很低。虽然 PJ85718DM 本身带有一些数字滤波能力但双保险总归没坏处。远程探头返回超时也是常见问题。PJ85718DM 在内部会做重试但主控也应当在规定时间内没有得到结果时把该通道标记为故障而不是一直死等。在 HVAC 设备中某个探头掉了不能导致整机停机正确做法是转用备用传感器或固定输出一个安全温度值保证压缩机不会因为缺数据而误判断。4. HVAC 控制逻辑把温度值变成执行器动作4.1 滞后比较实现风机与压缩机控制温度采集只是手段控制动作才是目的。HVAC 控制里最常用的一招是滞后比较也叫回差控制。假设制冷模式下回风温度目标值是 25°C如果探头测得 26°C 就启动压缩机降到 24°C 才停止那这中间 2°C 的回差可以避免压缩机频繁启停。直接用代码判断#define TARGET_COOL 25.0f #define HYSTERESIS 2.0f if (temp_room (TARGET_COOL HYSTERESIS / 2.0f)) { comp_on(); } else if (temp_room (TARGET_COOL - HYSTERESIS / 2.0f)) { comp_off(); }这类逻辑用文字描述很容易但放到真实设备里要结合多个温度源。我认为制冷模式至少要看回风温度和蒸发器管温回风温度决定压缩机是否运行管温用于防止蒸发器结霜。如果只靠单一探头夏天高湿环境很容易把蒸发器冻住然后冷风送不出去房间温度根本降不下来。PJ85718DM 的多通道能力在这里就体现出来了一个模块接多路探头主控算法可以综合判断。风机的转速也可以根据温差做无级调节。温差大时风机高速运转温差接近目标时降速既省电又安静。具体的调速曲线我建议现场实测调整先把采集到的温度通过串口打出来再对照设备实际风速决定占空比映射。想一次性调出一个完美的 PID 参数很难从滞后控制和分段控制起步是更稳妥的做法。4.2 远程探头故障时的降级策略投运一段时间后远程探头损坏是必然事件不是会不会坏而是什么时候坏。每路远程通道在软件中都应当有健康状态标志位。主控读取失败若干次后将故障探头的温度值替换成备用通道数值或者用最近一次有效值冻结。如果所有远程探头同时故障HVAC 设备要进入强制保护模式。压缩机如果继续工作而没有温度反馈可能导致蒸发器结霜或冷凝器压力过高。实际项目中我见过因为探头脱落压缩机硬生生把空调冻成冰坨的情况。所以故障降级的底线是宁可停机不要瞎运行。控制逻辑里必须有明确的“无有效温度数据则停止相应执行器”分支这是安全优先级最高的一条不能因为担心误停机而不跳转。5. 实测记录架构调整前后对比以及需要注意的事项5.1 第一版方案的失败教训刚开始我图省事让 PIC18F85J10 直接通过 I2C 去读板外的所有远程传感器传感器节点用手工搭的电路没有经过 PJ85718DM 统一管理。样机在实验室里跑得很欢一到现场就出问题。客户现场的强电柜距离设备不到两米线缆长度接近十米I2C 时钟信号变形严重数据读取经常超时偶尔还会读出一会儿 15°C、一会儿 85°C 这种跳变值。后来把架构改成现在的样子远程传感器统一接到 PJ85718DM 管理的总线上模块本身承担了波形成型和重试工作主控只从模块寄存器取结果。再把传感器走线重新规划避开动力线加了屏蔽层通信稳定性和读数一致性立竿见影。实测连续运行三天温度波动基本保持在 0.2°C 以内实验室和现场的数据基本一致。这里也反映出一个经验嵌入式系统实验室环境过得太顺往往是因为没有真实干扰源。温度采集这类对噪声敏感的功能必须在带负载、带线缆的条件下测试而不是只测一块裸板。5.2 优化前后的数据对比观察项我整理了几项最重要的实测观察点落地项目时可以按这个思路去做验证一是在满载和空载两种工况下分别读取本地与远程温度确认读数不随供电波动乱跳二是人为拔掉一路远程探头确认故障标志在 3 秒内能上报三是用示波器观察远程总线波形确认波特率和上拉匹配合理四是长时间运行监控温度曲线的连续性不能有周期性毛刺。用这批指标跑数据整套系统是否可靠会有一个非常直观的判断。不要只看某一次的绝对值反而要关注变化趋势和跳变概率。温度采集系统真正难的不是测准一次而是连续几个小时稳定可复现。哪个通道偶尔跳一下、哪个通道线一松就复位这些才是真问题。6. 常见问题与排查表6.1 现场常见故障速查现象可能原因检查与处理办法本地温度正常远程全部无数据远程总线供电缺失、收发器方向控制错误用万用表测探头端电压确认总线使能引脚电平正确单个远程通道读数跳变接头氧化、线缆过长、上拉电阻不匹配重新压接端子缩短线缆改用双绞屏蔽线并降低波特率读到的温度始终为固定值传感器已损坏或总线地址冲突确认传感器地址有无重复用模块自检命令单点读测压缩机频繁启停温度更新周期太慢或回差设置过小缩短轮询周期扩大回差或者加入数据平滑上电后 PJ85718DM 通信失败SPI 相位极性配置错误、复位时序不满足对照模块手册确认 SPI Mode检查复位引脚时序示波器抓波形确认这套速查表基本把我在现场遇到的高频问题都覆盖了适合直接打印出来当调试小抄。很多问题表面上是传感器坏了实际是通信配置和现场线缆布局的问题优先排查链路再怀疑器件本体。6.2 依我来看最终必须避开的坑主要在几个地方。第一远程传感器线径不要太细24AWG 以上的屏蔽线是底线太细的线不仅压降大抗干扰能力也弱。第二主控和前端模块之间不要用杜邦线长期跑调试可以产品阶段必须用焊接或者压接杜邦线氧化后接触电阻增大偶尔会出现随机通信错误排查起来极其痛苦。第三不要在设计里把所有通道都当成必须在线一定要预设探头故障路径否则现场任何一个探头失效整套设备都会跟着出问题。第四温度校准不要只在室温做一次最好能在低温、常温和高温三个点做校验确认传感器在量程内没有明显非线性。PIC18F85J10 的看门狗配置也值得一提。HVAC 设备要求长期无人值守运行看门狗必须开启而且看门狗超时后要能把故障状态记录下来。温度采集模块如果在看门狗复位后没有重新初始化会一直报错。我习惯把“模块重新初始化”写进复位向量后的自检流程里这样即使系统被杀掉重启整个采集链也能快速恢复。做这套系统最大的体会就是温度监测不是功能是所有 HVAC 控制决策的地基。地基想打稳前端采集模块要分担复杂度主控要留足资源软件要提前考虑异常降级。按照这个思路用 PJ85718DM 配合 PIC18F85J10 去搭整个项目的稳定性和可维护性都会比临时拼的电路好很多。如果后续想扩到更多测点或者改成无线采集这套框架的接口划分也能平滑过渡不需要推翻重来。