2026/10/22 6:41:49

嵌入式温度采集实战:PJ85718DM与PIC18F86J16的本地远程测温方案

嵌入式温度采集实战:PJ85718DM与PIC18F86J16的本地远程测温方案 把温度测准这件事在嵌入式和 HVAC 项目里的难点从来不在“读寄存器”这一步而在怎么把一颗本地传感器和一根可能拉到十几米外的远程探头稳定、可靠、可维护地并进同一套系统里。最近一个项目里我用 PJ85718DM 搭配 PIC18F86J16同时做了本地温度和远程温度的监测跑了一段时间下来效果比较理想。这篇就把选型逻辑、硬件分工、固件流程、现场抗干扰和实测踩坑一次性写清楚给同样在折腾嵌入式温度采集的朋友做个参考。1. 为什么选这两个芯片选型逻辑与项目边界1.1 PJ85718DM 在系统里的角色PJ85718DM 在我看来就是这套方案的温度采集前端。它承担的任务很明确把物理环境里的温度信号变成主控能直接读到的数字量。它支持本地测温也就是直接测量传感器所在 PCB 附近的温度也支持挂远程探头通过延长线把温度采集点搬到设备外面去。这个特性刚好对应标题里“本地与远程温度”两个诉求。很多 HVAC 控制器就是这样主板上要监控制板自身环境温度又要在风管、回风口、冷冻水管这些位置布置远端测点。一颗芯片同时搞定两个测量维度比本地一路、远程一路分别用不同器件去实现要省事得多。这类传感器的寄存器配置、精度指标、测温范围不同批次和派生型号会有差异。实际用的时候拿到对应型号的手册先确认本地通道和远程通道的寄存器映射、报警阈值寄存器和转换结果格式再开始画板写驱动能省掉后面不少麻烦。1.2 PIC18F86J16 的平台价值PIC18F86J16 是一颗高引脚数的 8 位单片机选择它主要是因为接口资源足够宽裕。先说传感器通信。PJ85718DM 这类传感器通常走 I2C 或类似的两线接口PIC18F86J16 的 MSSP 模块可以配置成 I2C 主模式直接挂在总线上。再说 HVAC 控制器的其他职责比如开关量输入输出、模拟量采集、串口和后台通信这些引脚资源它都给够了。一颗芯片把温度采集、控制逻辑、对外通信全包下来没有为了一个温度功能单独加协处理器系统设计会简单很多。J 系列在功耗和外设整合度上做得不错长时间通电运行的项目里这个优势会慢慢体现出来。当然不是非它不可。但从方案的整体电气设计难度、开发周期、供应链稳定性和资料完善程度综合看这个选型在嵌入式温控和 HVAC 类项目里算是比较稳的一条路。1.3 这个组合覆盖的应用场景把这两颗芯片放一起能覆盖的场景比想象中宽泛。HVAC 机组控制器主板测控制箱内部温度远程探头测风管和回风温度。嵌入式设备热管理本地传感器监控 CPU 或功率器件附近的温升远程探头测机箱外部环境温度。工业与楼宇现场仪表多点温度巡检、温度越限告警、数据上报。物联网边缘节点传感器数据汇总后通过主控的串口或无线模块传到上位机。不管应用怎么变系统要解决的核心问题都差不多数据准、通信稳、现场扛得住干扰。下面的内容就围绕这三件事展开。2. 硬件架构设计本地测温与远程测温的分工2.1 本地测温回路的搭建本地测温相对简单但我见过不少人在细节上翻车。PJ85718DM 的电源脚和地脚之间要放一个 0.1uF 陶瓷旁路电容位置尽量贴着芯片引脚。这是所有传感器都适用的基本功别省。通信引脚的上拉电阻也很关键。I2C 总线的 SDA 和 SCL 都需要上拉到供电电压阻值根据总线电容选一般先取 4.7k 左右总线长了换 2.2k。上拉电阻太大总线上升沿变缓通信速率稍微一高就出错太小又会让输出级拉低困难。这个规律在调试台上可能不明显到了现场一挂几十米的线就立刻暴露。本地测温探头的位置更有讲究。如果目标是测环境温度传感器就要尽量远离板上的发热器件比如开关管、变压器、大电流走线并且不要放在出风口附近。如果目标是监控某颗芯片的散热状态那就把传感器靠近被测对象中间不要铺大铜皮避免热被铜皮导走。我在一块控制板上布 PJ85718DM 时晶体和传感器分放在板子的两端。第一次打样回来实测传感器明显偏高两度拿热像仪一看底下过孔里跑了一根电源线发热顺着过孔传上来了。改版把这根线绕开读数立刻正常。这类问题原理图上完全看不出来必须结合实际布局去查。2.2 远程测温探头的走线与隔离远程探头是整套系统里最容易出问题的一环。探头如果挂在风管、水管或者设备外侧引线通常要穿过端子排、线槽走线环境很复杂。我的设计习惯是探头的两根信号线从一开始就用双绞线双绞线能让两条导线感应到的共模干扰尽量一致方便后端差模方式抵消。如果现场电磁环境再恶劣一点比如附近有变频器就在探头端加一层屏蔽层屏蔽层采用单端接地。所谓单端接地就是屏蔽层只在主控板这一端接到系统地另一端悬空避免屏蔽层两端都接地形成地环路否则地线电位差反而会变成干扰源灌进信号里。远程探头线的长度对测温精度有直接影响。线越长导线电阻越大探头远端因为供电电压下降导致读数偏移。这里有一个实用经验线阻补偿的系数不是拍脑袋定的。先用一小段线把探头接好测得标准读数再换一条实际用的长线测试稳定下来后对比两个读数的差值在固件里把这个偏移量拟合进去。线的长度固定下来以后补偿值基本稳定效果很理想。2.3 供电、参考电压与地环路处理PIC18F86J16 的 ADC 参考电压选择直接影响本地模拟量的准确度。如果板子上直接用开关电源的 3.3V 给 ADC 当参考源温度下的纹波会直接折算成测量误差。建议参考电压用单独的基准源或者至少在主控电源入口加 LC 滤波把高频纹波压下去再进 ADC。远程探头还有一个容易忽略的问题——地环路。如果远端探头单独用一路电源供电而探头和主控之间只有信号线相连两边的地电位可能不一致电流会通过信号线回流造成读数飘。处理办法是在探头电源输入端加一级隔离或者干脆把远程探头也交给主控板的同一电源域供电用单点接地把回路断了。具体用哪种取决于现场探头和主控之间距离多远以及是否共地。3. 固件层面的温度读取流程从寄存器到校准3.1 通信协议初始化与读取时序硬件焊好之后第一步是把主控和 PJ85718DM 之间的链路打通。初始化时先把 PIC18F86J16 的 MSSP 模块配置成 I2C 主模式时钟频率这里用 400kHz。扫一下总线确认设备地址能正常 ACK再开始读温度。伪代码大概是这样的void sensor_init(void) { i2c_master_init(400000); // I2C 主模式400kHz set_sensor_address(0x48); // 按手册配置从机地址 sensor_write_reg(0x04, 0x00); // 配置转换模式/报警阈值等 } uint16_t read_temp_raw(uint8_t channel) { uint8_t reg (channel LOCAL) ? 0x00 : 0x01; i2c_start(); i2c_send_byte((sensor_addr 1) | WRITE); i2c_send_byte(reg); // 指向温度寄存器 i2c_restart(); i2c_send_byte((sensor_addr 1) | READ); uint8_t msb i2c_read_byte(ACK); uint8_t lsb i2c_read_byte(NACK); i2c_stop(); return (uint16_t)((msb 8) | lsb); }寄存器地址和读取方式以实际手册为准但整体流程就是这样写寄存器指针然后连续读两个字节。要注意的是 I2C 时序对延时有要求主频跑得太快时发送停止条件之后要留一点时间再发下一笔否则从机没反应过来下一笔就会 NACK。3.2 原始数据的滤波、线性化与校准读出来的原始值直接换算成温度往往会有小幅波动。HVAC 里温度变化本来就慢我习惯用滑动平均滤波。窗口大小按系统的热惯性来定比如风管温度需要快速响应窗口取 4 到 8 个样本水箱温度热惯性大取 16 个样本也问题不大。这个过滤别过头否则反应太慢控制逻辑会跟着迟钝。线性化要看传感器的固有曲线。如果厂家手册里给了非线性补偿表优先用查表插值没有表就用多项式拟合。把零下温度区间和高温区间的误差分别验证一遍误差允许范围内做一步线性补偿就够了。校准这一步强烈建议留到产线或者现场做不要只在实验室里校一次就完事。实用的做法是读到的温度在固件里加一个用户可调偏置默认 0校准值存到参数区。现场接标准温度计比对把偏差值写进去这样每台设备的细微个体差异都能覆盖掉。3.3 多通道轮询调度与数据整合本地和远程两个通道不要在同一时刻连着读。传感器每次转换需要时间读得太频繁数据反而来不及更新而且总线一直占着主控别的活都干不了。我的做法是设一个 250ms 的定时器节拍每个节拍切换一个通道。第一个节拍读本地第二个节拍读远程轮流来。两个通道的温度都放到一个结构体里上位机随时可以取省得每次要数据还要现场去发起通信。这里有一个容易被新手忽略的点传感器在内置报警模式下报警引脚可以在温度越界时直接拉中断。如果主控引脚够用别省这个功能。比轮询方式快得多而且主控不用一直盯着寄存器看死等场景会少很多。4. HVAC 场景的专项处理抗干扰与稳定性4.1 变频器和压缩机带来的共模干扰怎么压HVAC 现场最凶的干扰源就是变频驱动器和压缩机的开关电源。干扰从探头线耦合进来表现就是温度值偶尔跳一下或者通信偶发失败。处理手段按优先级排列探头线屏蔽层单端接地从物理上切断共模干扰进入数据区的路径。信号线上串小阻值磁珠或电阻比如 100Ω 到 1kΩ配合后端电容组成低通滤波器。传感器电源入口加强去耦用 10uF 电解加 0.1uF 陶瓷组合。真正的现场雷区是变频器和探头线走同一个线槽。布线要改的话早点和电气工程师协调别等到设备都装好了再返工。我见过一个项目远程探头读数每十几秒跳一下查了很久才发现是探头线贴着变频器的输出电缆走了几十厘米。把线槽分开之后问题立刻消失。这类问题示波器不一定每次都能复现但高频干扰的耦合路径就是这么直接现场排布比换芯片更管用。4.2 探头断线、短路的检测与异常上报HVAC 系统里探头长期处在震动、温差变化大的环境里接头老化、断线都是迟早的事。如果软件不管这些传感器读数可能漂到奇怪的值然后控制逻辑基于错误数据进行调节后果要么是压缩机不启动要么是电加热一直工作。判断故障最简单的方法是利用物理范围判断。读数低于 −55°C 或高于 150°C直接判定异常。靠谱的传感器芯片也会在状态寄存器里给标志位比如转换结果不更新、测量开路或者短路。固件里每次读温度之前先读状态出现异常就给控制器上报“传感器故障”而不是沿用上一次正常值。远程探头的断线检测还有一个电路技巧在探头的信号端加一个上拉或下拉偏置电阻让断线时读到的是一个确定的高电平或低电平数值从而被故障判断逻辑识别出来。这个偏置电阻的取值要兼顾正常测量时对信号的分压影响一般取几百千欧影响可以忽略。4.3 长时间运行的稳定性和参数保存策略HVAC 设备一通电就是连续几个月甚至几年。长期运行下的问题跟实验室里跑 48 小时的体验完全不一样。首先是看门狗。PIC18F86J16 的 WDT 窗口要避开传感器通信阻塞的时间窗口。I2C 读操作如果卡在半路比如从机一直等不到停止位主控就会停在忙等状态。正确的做法是给 I2C 操作加一个超时机制超过 100ms 就强制发停止位把总线释放掉然后喂狗进入下次重试。千万不能在临界区里喂狗否则看门狗失去了兜底的作用。其次是历史温度数据的保存。若要记录温度曲线注意不要用固定的 Flash 地址反复擦写否则寿命很快耗尽。用环形缓冲区加磨损均衡的思路把写指针在逻辑上循环移动Flash 物理地址也依次轮换这样每一块区域的擦写次数会被摊平。保存间隔可以放宽到一分钟一次HVAC 的温度变化不需要秒级存储。另外上电和掉电时序也要注意。掉电时如果主控正在和传感器通信重启后传感器内部的寄存器状态可能不是初始值。固件里每次启动都强制写一遍配置寄存器之前我吃过亏只初始化部分寄存器结果报警阈值还在旧值上导致实际温度没到阈值就报警了。5. 实测数据与调试踩坑记录5.1 本地测温精度的现场校验样机打出来之后必须做一次实打实的精度校验。方法不复杂把传感器探头和标准温度计绑在一起包上保温棉让环境温度稳定下来然后对比两者读数。我做过一批三块板子读数一致性还算好。只有第二块板子本地通道偏高明显把传感器周围的热源排查了一遍发现是传感器边上有一根大电流走线的过孔带电流流过的时候铜皮温升往上蹿。改版把走线移到板子另一面再测读数就和标准表对齐了。这类问题原理图上看不出来只能靠校验和热像仪定位。如果现场校出来偏差是一个固定值直接在固件参数里把偏置写进去就行。如果偏差随温度变化比如低温区差 0.3°C、高温区差 0.9°C就要分段做两点或三点校准把校准系数存进参数区。5.2 远程探头长线传输带来的读数偏差远程通道走线到了 10 米和 50 米读数完全不是一个概念。线长之后导线电阻和分布电容都会影响传感器前端的偏置和工作点尤其在用模拟量输出的传感器上表现明显。我们实测过同一颗探头短线接法读数 25.0°C换 50 米线后读数是 24.2°C差了 0.8°C。这个差异是恒定值和线长基本成正比关系。处理办法是把实际要用的线材裁好接上探头和标准表一起放进恒温环境做一次起点校准把偏移量存进固件的补偿参数里。另一种做法是干脆给探头端加一个小的信号调理电路先把信号放大到和线损无关的等级再传回主控。但这样探头的体积和成本都会上来大多数 HVAC 项目里做线阻偏移补偿就够了。5.3 调试中常见的几个坑与排查思路I2C 上拉电阻不匹配。原本用的 10k 上拉单片测试没问题接了远程板之后通信开始偶发失败。换成 2.2k 之后稳定了。原因就是总线负载变了上升沿斜率跟不上 400kHz 的时序。排查办法是拿示波器量 SCL 的上升时间超过手册规定限值就换更小的上拉。多个传感器地址冲突。如果系统里挂了两片 PJ85718DM地址引脚要分别接高接低或者分时供电。我遇到过因为地址冲突两片传感器交替出错的场景总线扫描又看着一切正常。最后是把两片分开供电一片一片地读才确认是地址重叠导致的。看门狗和长读取打架。前期调试我图省事看门狗设了 500ms而传感器一次完整读取加转换将近 400ms一旦连续读两个通道主控就喂不了狗导致复位。后来把看门狗窗口适当调大同时给通信流程加中途喂狗点问题才解决。看门狗更像是保底的策略不要把希望都押在它身上。最后说一点个人体会。做嵌入式和 HVAC 温度监测硬件选型往往不是最花时间的环节真正决定项目成败的是后面那些不起眼的细节探头怎么走线、地怎么接、寄存器怎么初始化、故障怎么上报。PJ85718DM 和 PIC18F86J16 这套组合给我感觉是把“硬件简单、软件踏实”这条路线走得很顺的选择。如果你正在纠结怎么在同一块板上兼顾本地温度和远程温度不妨按这个思路搭一版样机试试重点把现场的干扰和长线补偿验证清楚系统稳定性会比预想中好很多。