基于PJ85718DM与PIC18F96J65的嵌入式本地/远程温度监测方案

做嵌入式的小伙伴应该都有同感：凡是沾到暖通空调（HVAC）的项目，测温永远是绕不开的环节。这几年我陆陆续续接过几个和环境监测、冷链运输、风机盘管控制相关的活儿，系统里最核心的一块基本都是温度采集，而且往往不只是测一个点，而是“本地一个温度、远端几个温度”同时要。最近一个模拟项目里，我用 PJ85718DM 搭配 PIC18F96J65 重新搭了一套本地与远程温度监测方案，从传感器接线到单片机上读取，再到把数据送监控端，整个过程踩了不少坑，也沉淀了不少可以直接复用的经验。这篇文章我完整整理一遍，给正在做嵌入式测温或者 HVAC 控制的小伙伴一个参考。

PJ85718DM 负责把本地和远程两个温度通道的数据转成数字量，PIC18F96J65 则承担主控、协议解析和数据上报的活儿。整套方案的核心难点其实不在“读温度”本身——随便一个单片机加热敏电阻也能读温度——而在于：远程传感器怎么接才准、I2C 读到的一堆寄存器怎么换算成真正能用的温度值、以及数据怎么稳定地送到上位机或者现场显示屏。这篇内容适合刚接触这类数字温度传感器的开发者，也适合已经在做 HVAC 组网、想优化测温链路的老手，后面所有代码和排查思路都是我在实际调试中验证过的。

1. 方案在哪儿用：嵌入式与 HVAC 的温度监测场景

1.1 本地测温，到底测什么

很多人一想到“本地温度”，第一反应就是“板上环境温度”。这个理解没错，但放在嵌入式系统里，本地测温的含义比表面看起来要细得多。

在一套 HVAC 控制器中，本地温度通常指控制板所在位置的空气温度，或者紧贴加热/制冷模块表面测得的温度。比如风机盘管控制器的 PCB 安装在回风箱附近，周围空气的温度就是本地温度；又比如冷库控制器的主控板装在库体外侧，本地温度反映的是设备间环境温度，用于判断控制板自身的工作环境是否过热。

PJ85718DM 这类器件的好处是，它把本地点温度直接做到芯片内部——也就是硅片温度。你不需要额外接热敏电阻或热电偶，只要给芯片通电，它内部的本地通道就会持续测量自身的结温。这个结温在多数应用里可以等同为 PCB 附近的环境温度，因为它离板上其他发热器件很近，对散热和温度漂移非常敏感。

不过要提醒一句：本地通道测的是“芯片自己感受到的温度”，不是空气的精确温度。如果 PCB 上有大功率电源芯片或者驱动电路，本地温度会明显偏高。我做过一个项目，板子上的继电器一吸合，PJ85718DM 的本地温度读数 2 秒内跳了 3°C，就是因为继电器线圈和触点发热影响了芯片局部环境。这种情况就需要做软件滤波，或者把测温点尽量布置在远离大功率器件的区域。

1.2 远程测温，HVAC 里的“远程”绝不是网络远程

这里要先区分一个概念。很多做物联网的朋友看到“远程温度”第一反应是“通过网络远程查看温度”，但在这个标题的语境下，远程温度指的是“传感器布置在离主控板有一定距离的位置，通过线缆把信号引回主控板”。

HVAC 场景里这种需求太常见了：送风管道内的温度、回风管道内的温度、冷凝水管温度、室外新风温度、水系统供回水温度……这些测点不可能都放在控制器旁边，传感器的位置离主控板可能隔着 0.5 米到几米甚至十几米。用 PJ85718DM 这样的远程通道方案，远端不需要再接一颗完整的传感器芯片，而是通过一根线缆连接一个远端温度传感元件（通常是二极管或热敏结构），主控板上的芯片负责激励、采样和计算，这比“远端放一个完整传感器 + 单独供电 + 单独通信线”要省很多成本和布线空间。

实际项目中，我把远程通道接到风管内的一个探头上，探头和主控板之间用了大约 3 米的双绞屏蔽线。早期没加屏蔽层的时候，旁边一台变频器一启动，远程温度读数就会跳动。后来换成屏蔽线并单端接地，再把采样时间拉长，数据才稳定下来。远程测温的精度，很大程度取决于这一段模拟链路的抗干扰能力，这一点后面我会详细展开。

1.3 为什么选择 PJ85718DM + PIC18F96J65

先说 PJ85718DM。我选它主要是因为三个点：第一，它自带本地和远程两个测温通道，一颗器件解决“现场 + 远端”两种需求，不用再外挂第二颗传感器；第二，它走 I2C 接口，寄存器结构清晰，单片机端驱动写起来不复杂；第三，它带 ALERT 报警输出引脚，可以在温度越限时直接拉中断，不用主控轮询读取，对功耗和实时性都友好。

再说 PIC18F96J65。这颗 MCU 在我这个方案里承担的任务是：轮询 PJ85718DM、做数据换算和滤波、驱动 LCD 显示、把数据通过串口或者以太网口上报。它的优势在于片上资源对这类中等复杂度的应用刚好够用，IO 数量充足，I2C 硬件模块可以很大程度上简化软件模拟 I2C 的时序折腾。而且 PIC18F 系列的开发环境成熟，调试工具也便宜，国内做工业控制的老工程师基本都熟。

这里有个选型思路可以分享：很多新手喜欢用功能更强的 32 位 MCU 来做这类活，但在这个项目里，8 位的 PIC18F96J65 反而更合适。原因很简单——HVAC 控制器对成本和长期供货稳定性非常敏感，8 位机成熟、稳定、功耗可控，而且这个方案里的温度采集本身不是高算力任务，I2C 读取频率 1Hz 也绰绰有余。算力不是越多越好，而是够用、可靠、好维护才算好。

2. 硬件搭建：PJ85718DM 与 PIC18F96J65 的连接要点

2.1 PJ85718DM 的关键引脚与 I2C 地址

要快速让 PJ85718DM 跑起来，先要搞清楚它的引脚和通信方式。我手头这颗器件的封装是标准 8 脚贴片，但不同批次可能会有引脚兼容差异，做板子前务必对照数据手册确认。核心引脚大致是：

• VCC / GND：供电和地。工作电压范围我用的这一颗是 3.0V 到 5.5V，直接和 PIC18F96J65 共用 3.3V 电源，I2C 电平一致，不需要额外电平转换。
• SCL / SDA：I2C 时钟和数据线，需要外部上拉电阻。上拉电阻我取值 4.7kΩ，配合 100kHz 标准模式没问题。
• ALERT：报警输出引脚，开漏结构，越限时拉低，主控端接一个上拉电阻并把引脚配置为输入中断。
• DXP / DXN：远程温度传感元件的正负端，也就是接远端探头的地方。

I2C 地址方面，PJ85718DM 的地址由引脚电平决定，常见配置是 0x48 或者 0x49。具体是哪一个，要看你的 ADDR 引脚接法。我用的板子把 ADDR 接地，读地址就是 0x48。调试时如果发现 I2C 无应答，先检查的不应该是代码，而是这个引脚电平——我调试时大概有一半的“I2C 不通”问题最后都发现是地址没对。

连接上 PIC18F96J65 之后，硬件上其实没有太多其他东西了。VDD 和 VSS 照常接，SCL/SDA 接到单片机的对应 I2C 引脚，ALERT 接一个普通 IO，远程探头接到 DXP/DXN。整个测温前端就这样搭完了，硬件上真正需要花心思的是远程探头那边。

2.2 远程传感器接线：走线、屏蔽与滤波

远程测温是一个看似简单、实际最容易出幺蛾子的环节。PJ85718DM 的远程通道本质上是通过测量远端测温元件的电压特性来反推温度，信号幅度很小，一旦走线环境不理想，读数就会受到影响。

我踩过的第一个坑就是：把远程通道的线和其他大电流线走在了同一个线槽里。结果 DOAS 新风机一启动，温度读数直接跳了差不多 5°C。排查了很久才怀疑到干扰，后来把远程线单独走了一个线槽，读数立刻稳了。这个经验让我后来做布局时，始终把远程测温线当成“模拟敏感信号”来处理，绝不在它旁边走 PWM、继电器控制线或者 220V 交流线。

第二个坑和线长有关。远程测温线拉的越长，线缆电阻和分布电容的影响越明显。PJ85718DM 的数据手册通常会给出远程通道的建议线长和线缆类型，一般双绞屏蔽线可以拉到几米甚至更长。但注意：线越长，你需要在软件里做的滤波就越重，否则瞬态干扰很容易叠加进去。我做 3 米线缆时，软件里加了滑动平均滤波，窗口长度取 8 次采样，实际效果比较理想。

第三个点要在硬件上处理干净：远程线进入 PCB 的地方，建议加一个小电容做差模滤波。我习惯在 DXP/DXN 引脚对地各放一个 1nF 的电容，效果是高频噪声被压下去不少。但电容值不能太大，太大会影响远程测温元件上的激励信号，造成读数偏差。

2.3 供电与 PCB 布线的避坑

PJ85718DM 的供电看起来简单，实际很讲究。它内部的测温精度和供电稳定性直接相关，如果 VCC 上叠加了高频纹波，温度读数会出现不易察觉的漂移。我通常会在 VCC 引脚附近放一个 0.1μF 陶瓷电容加一个 1μF 钽电容，小电容滤高频，大电容扛瞬态。这个组合成本很低，但对读数稳定性的改善非常明显。

另外，PIC18F96J65 和 PJ85718DM 之间的 I2C 走线也不能太长。I2C 总线如果拉得太远，线间电容变大，会造成信号边沿变缓甚至读不到 ACK。同一块板上 I2C 线路我一般控制在 10cm 以内，如果确实需要跨板连接，就用带屏蔽的排线，并且把 I2C 速率降到 100kHz 以下以保证上升沿有足够的余量。

还有一点很多人忽略：PJ85718DM 的本地测温通道对 PCB 上的热源分布非常敏感。如果传感器旁边刚好是 MCU 的晶振或者 DC-DC 电感，本地温度读数会明显偏离实际环境温度。我之前做过一版板子，把 PJ85718DM 放在了主控芯片的正下方，两者之间只隔了 2mm 的板层，结果本地温度读数比旁边同一个箱体里的水银温度计高了 4°C。后来把器件挪到板边，加开槽隔热，读数才恢复正常。这个问题的根源是热传导，不是传感器质量问题，布局阶段就该避开。

3. 软件初始化与温度读取实操

3.1 I2C 驱动与初始化

整个软件的核心就是 I2C 读取 PJ85718DM 的寄存器。PIC18F96J65 自带 MSSP 模块，可以直接用硬件 I2C，不需要自己模拟时序。初始化代码比较简单，重点是把波特率配置在合理范围内、使能 I2C 模块并让器件进入正常工作状态。

以下是我在某个模拟项目里用的初始化流程，参考了器件手册的 recommended power-up sequence：

void sensor_init(void) { // 初始化 PIC18F96J65 的 MSSP 模块，100kHz 标准模式 SSPCON1 = 0x28; // 使能 I2C 主模式 SSPCON2 = 0x00; SSPADD = 0x4F; // 假设 Fosc = 16MHz，对应 100kHz SSPSTAT = 0x80; // 禁用 SMBus 电平 // 将 PJ85718DM 配置为连续转换模式，12-bit 分辨率 write_register(0x01, 0x60); // 0x01 是配置寄存器，0x60 表示连续转换 + 12-bit // 读取一次配置做确认 uint8_t cfg = read_register(0x01); if ((cfg & 0x60) != 0x60) { // 初始化失败，进入错误处理 } }

注意：PJ85718DM 的寄存器映射里，配置寄存器的地址和各 bit 的含义必须以数据手册为准，不同厂商的器件即使引脚兼容，寄存器位定义也可能不同。我这里给出的 0x01/0x60 是通用参考值，你在实际项目里不能直接照抄，先拿手册翻一遍再填。

写入配置寄存器之后，建议再读回来做一次校验。这种做法看起来多余，但能提前暴露 I2C 通信异常。比如有时候芯片进入了低功耗模式，写配置后芯片不会立即响应，如果不做回读，后续读温度数据会一直读到旧值。

3.2 读取本地与远程温度的计算过程

PJ85718DM 的温度数据是 12-bit 数字量，存存放在两个寄存器里，低字节的低 4 位是小数部分，其余 8 位是整数部分。读取流程是：先读高字节，再读低字节，然后把两个字节拼成一个 16 位有符号数，最后乘以分辨率。

我这里先贴自己常用的读取函数：

typedef struct { float local_temp; float remote_temp; } temp_data_t; temp_data_t read_temperatures(void) { temp_data_t result; int16_t raw_local; int16_t raw_remote; raw_local = (int16_t)(read_register(0x00) << 8); raw_local |= read_register(0x01); raw_local >>= 4; raw_remote = (int16_t)(read_register(0x02) << 8); raw_remote |= read_register(0x03); raw_remote >>= 4; result.local_temp = raw_local * 0.0625f; result.remote_temp = raw_remote * 0.0625f; return result; }

分辨率 0.0625°C 是怎么来的？12-bit ADC 的量程对应 0 到满量程，每个 LSB 对应的温度步进就是 0.0625°C。这个数值在手册里会明确写出来，我提前替你算好：1/16 = 0.0625。所以代码里乘 0.0625 就行了。

要注意的是拼接顺序。I2C 读寄存器通常先读高字节地址，再连续读低字节地址，两次读到的数据必须合成。如果中间插入了其他操作，或者低字节没读到导致边沿错位，计算出来的温度会变成离谱的负值或 200°C 以上的异常值。我在调试时遇到过一次读远程温度始终是 -127°C，查了半天，发现是我在两次字节读取之间插入了一个串口发送操作，导致 I2C 总线空闲时间过长、从机状态被重置。

另外，远程通道的原始数据有时会出现“负数跳变”，不要急着当故障处理。先看看是不是线缆接触不良导致的偶发读数错误。我习惯在软件里做一个基本有效性判断：如果读到的温度超出 -55°C 到 +150°C 的范围，就丢弃本次数据并用上一次的数值，同时把错误计数加一。这个范围比器件的有效量程稍微放宽一点，避免传感器靠近热源时读到的边缘值被误杀。

3.3 报警阈值与中断处理

PJ85718DM 支持设置温度上限和下限，超出后会拉低 ALERT 引脚。这在中大型 HVAC 系统里很实用，比如风管送风温度超过 45°C 或者回风温度低于 10°C 时，直接触发主控中断，不需要主控一秒钟轮询好几次。

我一般把 ALERT 接到 PIC18F96J65 的一个外部中断引脚，并在初始化时配置：

void alert_init(void) { TRISBbits.TRISB0 = 1; // ALERT 接入 RB0，设置输入 INTCON2bits.INTEDG0 = 1; // 上升沿触发，因为 ALERT 是低有效 INTCONbits.INT0E = 1; // 使能外部中断 INTCONbits.GIE = 1; // 开总中断 }

中断服务程序里不要做太多事情，标记一个报警标志位，置位当前温度状态，然后把具体的阈值判断放到主循环里处理。因为 ALERT 引脚是低有效，中断触发边沿要根据电路上拉后的默认电平来确定。我通常是 INIT 后强制读一次状态寄存器，把中断边沿设置成和实际拉低时序匹配的那个边沿，免得一上电就一直进中断。

报警阈值也要注意“回差”概念。比如设置高温报警阈值 50°C，温度到 50°C 报警，回落到 49°C 就解除报警，这样可能在阈值附近反复进入退出。PJ85718DM 的报警寄存器支持设置报警温度偏置/滞回，但不同器件叫法不同，建议在配置寄存器里找 hysteresis 字段，设一个 2°C 左右的回差，能有效避免继电器频繁通断。

4. 数据走向：串口、显示器与以太网上报

4.1 在 HVAC 组网中怎么选协议

温度数据在 MCU 内部算出来后，最终得送给外部设备。现场调试阶段，我一般先用串口输出，接个 USB-TTL 转接器直接在电脑上看数据。这时候数据的价值在于验证传感器准确性，并不需要复杂的协议，每秒钟打印一行“本地温度=xx.x，远程温度=xx.x”就足够了。

真正接入 HVAC 系统时，就要考虑通讯协议了。现场最常见的方案是 Modbus RTU，因为它简单、稳定、被各种触摸屏和组态软件支持得最好。把 PJ85718DM 的温度数据映射成 Modbus 寄存器，主站直接读寄存器就能拿到实时温度。这个方案在很多已投入运行的楼宇自控项目里都属于标配。

如果是做成组网设备，PIC18F96J65 自带的以太网接口就有用武之地了。它可以把本地和远程温度直接封装成 TCP 或 MQTT 数据上报到中控平台，走网络巡检的方式替代传统拔插头查看数据。MQTT 的好处是发布订阅模式对海量节点友好，而且中控端通过主题订阅就能按房间、按机组分类读取温度数据。不过 MQTT 对协议栈内存有一定要求，PIC18F96J65 的 Flash 和 RAM 跑一个精简 MQTT 客户端是够用的，但如果还要同时跑 Web Server，就要仔细评估资源占用。

4.2 用 PIC18F96J65 的以太网外设发送温度数据

以太网这块我单独拿出来说一下。PIC18F96J65 内部集成了以太网控制器和物理层收发器，硬件上只需要一个带网络变压器的 RJ45 座子和少量外围元件，就能接网线通信了。这在早期方案里是非常大的成本节省，因为很多 MCU 还需要外部挂一颗 PHY 芯片，布线和调试成本都会上升。

软件流程上，首先初始化以太网模块，配置好 MAC 地址和 IP 地址。然后根据自己的业务逻辑，每 1 秒读取一次温度，把温度值填入发往监控端的数据包中。一个最简单的 UDP 上报函数可以这样写：

void send_temp_over_udp(float local, float remote) { uint8_t frame[16]; uint16_t temp_int; frame[0] = 0xAA; // 帧头 frame[1] = 0x01; // 命令：温度上报 temp_int = (uint16_t)(local * 100); // 扩大 100 倍，保留两位小数 frame[2] = (temp_int >> 8) & 0xFF; frame[3] = temp_int & 0xFF; temp_int = (uint16_t)(remote * 100); frame[4] = (temp_int >> 8) & 0xFF; frame[5] = temp_int & 0xFF; frame[6] = 0x55; // 帧尾 // 调用协议栈发送 ethernet_send(frame, 7); }

用整型传输温度可以避免浮点数在跨设备传输时的解析问题。放大 100 倍后，接收端收到 2355 就是 23.55°C，简单可靠。

串口和网口最好同时保留。HVAC 现场工程师调试时未必带笔记本网线，很多时候就是用一根串口线打开串口助手看数据。设备上保留串口调试口，网口负责正常业务，两者并行不冲突，出了问题也方便排查。

4.3 掉电与数据记录

温度监测系统还有一个容易被忽视的需求：数据记录。HVAC 设备在调试阶段，需要连续跑好几天验证温控逻辑是否正常；运行阶段也需要了解设备一天的温升曲线。如果只在上位机软件里存数据，掉电就全没了。做主控固件时，我建议在 PIC18F96J65 的外部 Flash 里以固定间隔存一组温度记录，比如每 5 分钟存一组（本地温度 + 远程温度 + 时间戳），存满后覆盖最旧的一条。这样即使现场断网，也能从设备里把历史温度取出来分析。

存储方面有个小细节：PIC18F96J65 的片内 EEPROM 容量有限，频繁擦写会影响寿命，不要直接拿它来存历史温度。外挂一颗 SPI NOR Flash 更加靠谱，容量选 1MB 就够记录很长时间。写入时按页写入，注意磨损均衡，否则 Flash 会在几个月内就报坏块。

5. 调试记录：典型问题与排查技巧

5.1 我踩过的一些坑

接着说调试过程中最头疼的几个问题。第一个就是 I2C 读不到数据。曾经有整整半天卡在 PJ85718DM 无应答的问题上，最后发现是因为 I2C 上拉电阻没焊——PCB 打样时漏了两个 0402 电阻。这个教训让我养成了一个习惯：板子回来第一件事不是写代码，而是先用万用表测 SCL/SDA 对 VCC 的电阻，确认上拉存在且阻值合理。

第二个坑是远程温度串入本地温度数据。有一次调试，远程通道接的是管道温度探头，回风温度显示和环境温度几乎一样，排查到最后，发现问题出在 I2C 读地址上。远程通道的寄存器地址和本地通道的寄存器地址只有一位之差，我在读远程温度时把寄存器地址写错了，读回来的是本地的数据。这个问题如果不仔细看数据手册，光靠肉眼很难发现，最好的办法是在固件里加一个可读的“设备状态寄存器”，连续读几次，确认寄存器地址映射正确。

第三个坑和 ALERT 中断有关。我把 ALERT 配置成上升沿触发，但器件在温度越限时拉低，我一开始没有读状态寄存器清除报警标志，结果温度恢复正常后 ALERT 还是一直保持低电平，单片机始终进中断，整个系统被中断风暴拖死。后来在中断服务程序里加了清中断操作，并且回读状态寄存器确认报警被清除，问题才解决。

5.2 常见问题速查表

下面这个表格是我在实际项目中整理出来的，直接拿去对照排查可以省不少时间：

5.3 提高测量精度的土办法

如果你对温度精度有更高要求，比如要求误差在 ±0.3°C 以内，光靠 PJ85718DM 的默认配置还不够，要配合校准。

最常见的就是偏移校准：把传感器和标准温度计放在同一个恒温恒湿箱里，稳定后记录标准温度和 PJ85718DM 读数之间的差值，把差值作为偏移量写进固件。比如标准温度是 25.0°C，传感器读数是 24.7°C，偏移量就是 +0.3°C，以后所有读数统一加上这个偏移。这是我做冷柜项目时常用的做法，简单直接，效果稳定。

两点校准比单点校准更专业：分别在低温点和高温点各测一次，比如 0°C 和 60°C，用一个线性函数 y = a*x + b 来修正。因为 PT 类测温元件的误差通常是线性的，这样补偿后精度明显高于单点偏移。注意校准用的温度环境和实际使用环境尽量保持一致，否则校准系数会带进额外的误差。

软件滤波也很重要。我一般先用滑动平均滤波做一次平滑，窗口长度取 8 到 16 次采样，如果系统里有变频器或大功率开关器件，再用中值滤波把突跳值过滤掉。两个滤波组合使用，既压了高频噪声，又不至于让温度响应变得太迟钝。HVAC 的控温本来就不是毫秒级响应，温度数据滞后一两秒完全不影响控制性能，反而能让系统更稳定。

还有一个小技巧：每隔一段时间简单自校准一次。PJ85718DM 本地通道的 ADC 漂移长期来看很小，但远程通道受线缆老化和端子氧化影响，可能逐渐偏离基准。我就在设备里加了一个远程通道偏移量的寄存器，现场运维人员可以通过串口命令修正确认过的偏差，不用重新烧录固件。

最后再说一个实际体会

做完这个项目，我最大的感受是：温度监测系统的坑大多不在“读寄存器”这一步，而在硬件布置、线缆处理和软件鲁棒性上。PJ85718DM 和 PIC18F96J65 这套组合，硬件成本可控、开发周期短，尤其中间的 I2C 链路和以太网上报逻辑非常透明，出了问题容易定位。如果你也是第一次用它俩，我建议先把硬件最小系统搭起来，远程探头暂时用短的屏蔽线接好，写一个最简单的串口打印程序跑到稳定输出，再逐步扩展报警、存储和网络功能。每一步都确认没问题再进行下一步，Debug 效率会是最高——这比我见过的大多数“一口气写完所有功能再联调”的失败案例可靠得多。最后留个习惯性的检查项：每次焊接完远程探头，先用万用表量一下 DXP/DXN 之间的阻值是否在合理范围，再上电跑程序。这个十几秒的操作，能帮你避开不少玄学问题。