做嵌入式温度采集项目，我第一件事一定是先把“本地”和“远程”这两个词拆开想清楚：本地是传感器紧挨着设备、手边能看到的实时温度，远程是通过网络从几公里外随时拉走的同一份温度数据。标题里这套 PJ85718DM 加 PIC18F97J60 的组合，正好把这两条链路塞进了一块板子。PJ85718DM 干温度采集的粗活，把物理温度变成数字量；PIC18F97J60 自带以太网控制器和物理层收发器，负责把数字量打包成网络报文，让本地设备的数据在远程主机、上位机或楼宇自控平台上随时可读。
这篇文章不适合只想抄两行代码的人，它适合正在做嵌入式温控、暖通空调控制器或者楼宇自控采集网关的工程师。我按整个系统的推进顺序来写：先讲为什么选这两个器件，再讲硬件接线、固件框架、精度校准，最后把我在现场排查过的典型故障列成速查表。你能直接照着搭，也知道每一步背后的原因。
1. 需求拆解与选型思路：为何 PJ85718DM 加 PIC18F97J60 能同时覆盖本地和远程温度
1.1 “本地温度”和“远程温度”的真实含义
先说清楚一个容易绕晕的概念。温度本身没有本地和远程之分，温度传感器测得的就是一个物理量。所谓“本地”，指的是采集节点所在位置，也就是测温对象旁边；所谓“远程”，指的是数据最终被读取的位置，也就是监控中心、服务器或者云端平台。
很多项目把这两个概念混在一起，结果做成一个只有探头的测温器：现场能看到温度，但后端系统拿不到数据。这种方案在 HVAC 应用里几乎没有意义，因为暖通系统的温度数据最终都是要进入控制逻辑的，比如根据回风温度调节冷水阀开度，根据供水回水温差判断换热器效率。所以这套系统的核心价值不是“测到温度”，而是“把温度送出去”。
在我做的这类采集节点里，架构可以拆成三段：物理温度采集、本地处理与存储、网络远程访问。PJ85718DM 对应第一段，PIC18F97J60 对应第二段和第三段。后面的选型逻辑，完全围绕这三段展开。
1.2 自带以太网控制器，省掉的远不止一颗 PHY 芯片
早期做嵌入式网络设备，最常见的做法是“单片机加外部以太网控制器”。外置方案需要一颗独立控制芯片、一颗网络变压器、一堆无源器件，电路板面积直接翻倍，而且控制器和单片机之间的通信接口往往是 SPI 或并行总线，数据吞吐稍有压力就会卡。
PIC18F97J60 这颗芯片不一样，它把以太网的 MAC 层和 PHY 层直接集成在单片机内部。换句话说，单片机可以直接通过内部总线访问以太网寄存器、DMA 缓冲区和收发 FIFO，不再需要外部芯片。从硬件设计角度讲，省下的不只是 BOM 成本，更重要的是布线和信号完整性风险。以太网差分对是高速信号，放在芯片内部相当于缩短了走线路径，抗干扰能力比板级方案高不少。
这颗芯片另一个特点是内存映射设计。它专门给网络缓冲区划出了一块 DMA 区域，收发数据包可以直接在这块区域内搬移，不用像外部控制器那样每发一个包都要通过 SPI 先读进自己的缓冲区，再解析再转发。对于温度监测这种数据量不大但要求稳定的应用，这种架构尤其舒服。
1.3 传感器选型：PJ85718DM 的接口、量程与适配性
温度传感器选型时，我最看重三样东西：接口是否通用、量程是否覆盖应用场景、标定是否方便。
PJ85718DM 是一颗数字式温度传感模块，内部集成了测温核心和数字接口，通过 I2C 总线直接输出温度字。文档上给出的典型量程是 -40 到大概 150 摄氏度，对 HVAC 用途绰绰有余，不管是冬季防冻监测、夏季送风温度，还是机房环境温度，都在这个范围里。分辨率是 12 位，每个数字量对应 0.0625 摄氏度，做制冷判断误差足够小。
接口上它支持 I2C 和 SPI 两种模式，通过模块上的配置引脚选择。我建议使用 I2C，因为两根线就能挂载多个传感器，后续如果想扩展温度采集点，不用改动主控板。I2C 地址可以通过模块的地址引脚设置，一块板上同时挂四五个 PJ85718DM 没有任何压力。
还有一个容易被忽略的细节：模块供电范围是 2.7 伏到 5.5 伏，可以直接跟 PIC18F97J60 的 IO 电平匹配。这意味着不需要额外的电平转换电路，传感器和单片机之间只要接上拉电阻就能跑，简化了整个后面板的供电设计。
1.4 方案对比：为什么不用现成的温度记录仪或者网关
经常有人问我，市面上几百块钱的温度记录仪、Modbus 温度采集模块一大把，为什么还要自己用单片机做？答案在于控制边界。
现成温度记录仪能测能存，但它不能把温度数据直接联动到控制器里做闭环调节；Modbus 采集模块能上报，但它是独立设备，无法嵌入到设备的主控板上，也不能运行自定义逻辑。对我这个场景来说，PIC18F97J60 本身同时扮演温度采集主控和网络服务器的角色，上位机拿到的是一类已经处理过的温度值，设备自带逻辑也可以根据温度直接做本地保护动作，比如超温报警、防冻切断。这才是真正把数据变成应用。
下面是一个简明的选型对照，供你在立项阶段快速判断：
| 方案 | 测温方式 | 远程访问 | 与控制逻辑联动 | 改造灵活性 |
|---|---|---|---|---|
| 温度记录仪 | 自带探头 | 多数不支持或需连电脑 | 无 | 低 |
| 独立Modbus采集模块 | 外接变送器 | 支持Modbus | 需额外处理器 | 中 |
| 本方案（PJ85718DM+PIC18F97J60） | I2C数字传感器 | HTTP/Modbus TCP | 主控直接判断 | 高 |
2. 硬件连接实操：PJ85718DM 与 PIC18F97J60 的接口设计
2.1 PJ85718DM 的典型引脚与最小电路
按照数据手册的常见接法，PJ85718DM 模块一般会引出 VDD、GND、SDA、SCL 以及地址配置引脚。如果模块配置为 I2C 模式，则不需要额外的时钟线，接线极其简单。
我把最小电路的几个关键点列一下：
- 供电：VDD 接 3.3 伏，GND 公共地，在模块电源引脚旁放一颗 0.1 微法陶瓷电容，滤掉高频噪声。如果 HVAC 现场变频器多，建议再加一颗 10 微法电解电容，靠近端子放置。
- I2C 上拉：SDA 和 SCL 必须外接上拉电阻，阻值从 2.2 千欧到 4.7 千欧都可以。手头没有精密电阻时用 4.7 千欧最保险，高速模式下也能跑。
- 地址配置：如果需要挂多个传感器，用地址引脚组合出不同地址。单个节点就保持默认，直接用硬件地址读取。
这里一定要记住，I2C 总线的上拉电阻不是可选项，没有上拉电阻时总线会一直处于低电平，单片机读到的温度数据永远是 0 或者错误值。我在现场见过太多人因为忘接上拉翻车。
2.2 与 PIC18F97J60 的 IO 连接与电平匹配细节
PIC18F97J60 的通用 IO 口大多支持 5 伏耐压，而 PJ85718DM 在 3.3 伏供电时 SDA 和 SCL 的输出高电平接近 3.3 伏。给 PJ85718DM 也供 3.3 伏，两边都在同一电平域下工作，不需要电平转换电路。
具体引脚分配我建议留出一个完整的 I2C 外设通道。PIC18F97J60 的 MSSP 模块可以工作在 I2C 模式，直接用硬件寄存器控制时钟和数据时序。虽然也可以用普通 IO 模拟 I2C，但硬件外设更稳定，还省 CPU 周期。实际接线如下：
- SCL 接到单片机的 I2C 时钟引脚，比如 RC3
- SDA 接到单片机的 I2C 数据引脚，比如 RC4
- SDA 和 SCL 各接一颗 4.7 千欧上拉电阻到 3.3 伏
- 模块 GND 与单片机 GND 单点相连
需要特别注意的是，如果模块和单片机之间有较长飞线，比如超过 20 厘米，建议采用双绞线结构，两组信号线相互绞合，减少电感耦合。对于机房内的短线连接，普通杜邦线或 PCB 走线都没问题。
2.3 HVAC 现场布线与电源保护的几个实战细节
HVAC 现场最恶劣的环境是强电干扰和感性负载启停。压缩机一启动，电流冲击能达到正常工作电流的数倍，附近的弱电采集电路如果没有保护，温度读数就会出现瞬间跳变甚至单片机复位。
我在设计这块电路板时，把温度采集电路和功率驱动电路从电源入口处分开了。电源进线先经过共模电感，再经过线性稳压器给单片机供电；传感器的供电也从稳压器出，而不是直接从功率驱动的电源轨上取。
更稳妥的做法是在传感器信号线上加一级 RC 低通滤波。I2C 是数字信号，直接加 RC 会影响时序，所以更合理的方案是在模块电源引脚处并联 100 欧姆电阻加 0.1 微法电容的小滤波网络，滤掉电源线上的毛刺。这个方法成本极低，但能解决很大的麻烦。
如果设备要接入工业现场总线或者以太网，现场接地也是一个值得关注的环节。PIC18F97J60 内置以太网 PHY，但外部还需要接隔离变压器和 RJ45 座，变压器中心抽头通过一对电阻接到电源地或者直接接大地。我的习惯是让 RJ45 的金属外壳通过电容接到机壳地，然后整个板子的数字地单独引出，避免地环路噪声串进温度采集端。
3. 固件实现：本地读数与远程上报的全链路
3.1 初始化顺序与 I2C 读取时序
固件初始化顺序看起来简单，其实有很多坑。我给这套系统定的初始化顺序是：关闭看门狗和全局中断、配置振荡器、初始化 IO、初始化 I2C、初始化以太网、注册占用 IP、打开网络服务。
重点是 I2C 读取时序。PJ85718DM 的典型温度寄存器读取流程是先写寄存器地址，再读取两个字节的数据。用硬件 I2C 的 MSSP 模块操作时，需要连续调几个状态机步骤，期间要注意 ACK 信号的处理。
代码层面，伪代码如下：
void read_temperature(uint16_t *temp_raw) { i2c_start(); i2c_write(PJ85718DM_WRITE_ADDR); i2c_write(0x02); // 温度寄存器地址 i2c_start(); i2c_write(PJ85718DM_READ_ADDR); *temp_raw = (uint16_t)(i2c_read(ACK) << 8); *temp_raw = ((*temp_raw) & 0xFF00) | i2c_read(NAK); i2c_stop(); }读取到的原始值是一个 16 位寄存器值，但 PJ85718DM 只用低 12 位作为温度数据。换算公式很直接：等于原始值乘以 0.0625 再减去 40 摄氏度。这个偏移量是用来表示负温度用的，千万不要漏掉。
3.2 温度换算与数字滤波策略
原始码值换算成摄氏度很简单，但直接把这个值送出去，远程端看到的曲线会很难看。HVAC 环境里温度变化本身是一个慢过程，传感器也会受到微小扰动，所以数字滤波是必须的。
我最常用的两招：
- 平均值滤波：连续取 8 次采样，去掉最大值和最小值，然后对剩余的 6 个数求平均。这个组合既能滤掉脉冲干扰，又能保持响应速度。
- 滑动窗口：维护一个长度为 16 的 FIFO，每次有新值时弹出最老值，窗口内求平均。适合用来做实时曲线监控，CPU 开销小。
在 HVAC 控制应用中，我强烈建议做一次“死区”处理。温度波动小于 0.3 摄氏度时，保持上一次上报值不变。这样可以避免远程监控界面上出现高频抖动，也能减少网络报文数量，降低上位机的负载。
3.3 在 PIC18F97J60 上跑轻量 TCP/IP 服务
PIC18F97J60 为什么适合做网络设备，关键就在于它内部集成了以太网收发模块。固件里要做的事，是把 TCP/IP 协议栈跑起来，让单片机能够响应网络请求。
这个芯片上有 DMA 缓冲区，所有收发以太网帧都经过这块内存。单片机的工作流程是：以太网模块收到帧，通过 DMA 搬运到指定缓冲区，然后协议栈解析数据、执行处理函数，生成响应帧再通过 DMA 发回 PHY。
在室内 HVAC 应用里，我一般只开 TCP 服务，不开 UDP，因为温度采集不需要广播发现，用 TCP 更可靠。占用端口根据应用选择：Web 方式用 80 端口，Modbus 用 502 端口，两者可以同时开。
协议栈跑起来之后，还要配置好 MAC 地址和静态 IP。MAC 地址建议从厂商范围里取一段写入 EEPROM，每次上电读出来用，避免因为忘记保存导致网络冲突。
3.4 Modbus TCP 和 HTTP 两种远程上报方式
远程上报我最常用的是两种协议，各有利弊。
第一种是 HTTP JSON。PIC 把温度值通过一个简单的 HTTP 响应输出，例如返回{"temperature": 23.45, "unit": "C"}。这种格式好处是可视化平台、Node-RED、Python 脚本直接就能解析，调试浏览器也能看。缺点是 HTTP 报文开销大，而且无状态，不太适合频繁轮询。
第二种是 Modbus TCP 从站。这是工业现场标准的接入方式，上位机组态软件、PLC、触屏都能直接访问。做法是把温度值映射到保持寄存器区，比如地址 40001 存温度整数值乘以 100 后的结果，40002 存传感器状态标志。上位机只需要用标准的 Modbus 读寄存器命令，非常简单。
Modbus TCP 报文格式相对固定，其中单元标识符可以用作设备地址，在一台网关上挂多个温度节点时特别有用。每个节点分配一个单元编号，上位机就能通过同一个 IP 读出所有温度。
我自己的做法是同时开两个服务：先用 HTTP 做本地调试，快速验证传感器和网络链路通不通；正式部署时切换成 Modbus TCP。这样既不耽误现场开发，也不影响最终接入。
3.5 主循环状态机与喂狗策略
单片机固件不能写成“从头跑到尾”的顺序流程，因为以太网收发是异步事件，传感器读取也得按固定周期执行。我用一个简单状态机来组织主循环：
typedef enum { STATE_READ_TEMP, STATE_FILTER_TEMP, STATE_UPDATE_REG, STATE_ETH_PROCESS, STATE_WAIT } app_state_t;系统上电后先进入读温度状态，完成一次温度采样，切换滤波状态；滤波完成后更新 Modbus 保持寄存器和 HTTP 缓存，再进入以太网处理状态，处理收到的 TCP 请求；一切结束后短暂等待，进入下一轮循环。
这个状态机的关键点在于，以太网处理不能阻塞太久。协议栈的监听、收发操作都应该是非阻塞的，一旦发现缓冲区没有数据就立即退出，把 CPU 时间让给其他任务。否则在 TCP 握手时阻塞一次，整个温度采集周期就被拖了。
同时一定要用看门狗。超时时间设置成主循环周期的 3 到 5 倍，比如主循环 100 毫秒，看门狗设置 300 到 500 毫秒。这样即使程序异常死循环，设备也能自动重启恢复，不会在无人值守的机房里死掉。
4. 数据可靠性设计：精度、误差与校准
4.1 误差来源拆解：不能只信传感器标称精度
很多人只盯着传感器的标称精度，却忽略了系统里别的误差来源。以 PJ85718DM 为例，手册上写着典型精度是正负 0.5 摄氏度，但这是传感器本身的误差。系统级误差还包括 I2C 时序抖动、电源纹波、参考电压漂移、数字滤波引入的响应滞后，以及现场线缆长度带来的信号衰减。
如果传感器的测量位置离控制板很近，那电源噪声和信号衰减的影响就很低。但 HVAC 设备中，温度传感器经常要拉到风管、水管的远端，连接线一长，线电阻和线间电容就会起作用。对 I2C 数字传感器来说，线缆超过十米，信号沿线的压降和电容充放电都可能导致数据不稳定。
所以我一般建议：远端传感器尽量采用数字输出方式，不要用模拟电压输出。PJ85718DM 的数字 I2C 输出已经比模拟输出抗干扰能力强得多，但极限距离下最好还是加中继或者改成 Modbus 链路。
4.2 两点校准与偏差修正公式
我自己的校准流程不依赖昂贵的恒温槽，而是用最常用的冰水混合物和恒温箱做一个两点校准。做法是在 0 摄氏度和 50 摄氏度附近采两个点，记下传感器读数，然后建立一个线性修正公式，把实际温度换算成最终上报温度。
假设 0 摄氏度标准源下传感器测得 T0，50 摄氏度标准源下测得 T50，那么修正系数 K 等于 (50 减 0) 除以 (T50 减 T0)，修正偏移量 B 等于 0 减 K 乘 T0。最终温度 Tfinal 等于 K 乘 Traded 加 B。
把这个修正参数写在 EEPROM 里，每次上电自动装载。多块板卡之间参数不一致也不怕，因为每块板最终上报的温度都经过自己的修正。
这里提醒一句：校准前先给设备通电至少 15 分钟，让板卡自身温度稳定。如果传感器和 PIC 在同一块板上，单片机发热会影响被测温度，这也是为什么在精度要求高的场合会给传感器加一根延长线，让它离开板卡的热源。
4.3 HVAC 场景下的测温位置与响应延迟
HVAC 应用里，测温位置和探头热惯量对控制效果的影响甚至比传感器精度还大。比如把传感器放在风管弯头后面，气流会产生涡流，温度读数波动明显；放在直管段中央且距弯头足够远的地方，读数才稳定。冷水管表面测温时，必须保证探头和管壁温度尽量接近，并做好保温隔热，否则测出来的只是环境温度。
另一个容易忽视的问题是响应延迟。传感器的热质量越大，反应越慢。PJ85718DM 这种小型数字传感器的热时间常数通常只有几秒到几十秒，但包裹它的金属套管、导热硅脂和管壁热阻，会把整个响应时间拉长到几分钟。做联动控制之前，一定要实测系统延迟，否则控制回路会振荡。
我处理这个问题的方法是在软件里加一个动态响应补偿：根据最近几个周期的变化率预估当前真实温度，提前修正控制逻辑的输入。这个不是必要项，但能让 HVAC 的联动控制更平稳。
5. 现场调试与故障排查实录
5.1 排查思路总表
在现场被温度采集问题困住时，我一般是按照“供电、总线、网络、数值”四层排查。下面把常见症状、原因和修复手段整理成速查表，直接照着做就行：
| 症状 | 可能原因 | 排查与修复 |
|---|---|---|
| 温度固定读 0 或 0xFF | I2C 地址错误，或上拉电阻没接 | 确认器件地址与代码一致，检查 SDA/SCL 对地电阻 |
| I2C 通信偶发失败 | 飞线过长或线序不对 | 缩短线缆，改用双绞线，加 100 欧姆串联电阻 |
| 上电后设备网络不通 | MAC 地址重复或静态 IP 配置错误 | 重新分配 MAC 和 IP，用串口日志确认初始化结果 |
| 远程可以 ping 通但读不到数据 | 端口没开或防火墙拦截 | 确认 502/80 端口监听状态，先在本机浏览器测试 |
| 温度数据跳变明显 | 电源噪声或传感器靠近干扰源 | 给传感器电源加滤波电容，调整安装位置 |
| 设备运行一段时间后无响应 | 主循环死循环或看门狗没复位 | 打开看门狗，检查以太网处理函数是否阻塞 |
| 多个传感器数据互相串扰 | I2C 地址冲突 | 重新设置每个模块的地址引脚，确保全局唯一 |
这个表我在好几个项目里都用过，基本上覆盖了八成以上的现场问题。剩下一成是硬件焊接和线缆接触不良，需要万用表逐点量。
5.2 一次典型的读数异常排查记录
有一次我在现场调试一套风管温度采集，PIC18F97J60 能通电，以太网也能通，但温度值每隔几十秒就跳一次，跳幅达到 2 到 3 摄氏度。拆开面板后，发现 PJ85718DM 的供电线是从一个 24 伏交流转直流的电源模块上拉过来的，而那个电源模块同时给风阀执行器供电。
风阀动作时电流变化剧烈，导致 3.3 伏电压纹波飙升。处理方式很简单：把传感器的稳压器单独改到主电源入口的二次稳压侧，并在传感器电源引脚上并联一个 1000 微法电容，问题立刻消失。
这个案例给我的启发是，现场温度跳变不一定是传感器本身的问题，一定要先看供电质量，再谈读数干扰。
5.3 网络不稳定时的关键定位手段
PIC18F97J60 内置 PHY，但网线质量和 RJ45 连接器接触问题依然经常出现。我现场调试时先用一个简单的办法：不跑协议栈，只写一个循环让单片机不断发送固定的以太网帧，然后用电脑的抓包工具看是否稳定收到。
如果抓包正常，说明 PHY 和变压器都通；如果抓包随机丢包，基本可以确定是网线压接不良、网口接触问题或变压器虚焊。再往下就要拿示波器测差分信号幅度。
注意，不要在没排除硬件链路之前就怀疑协议栈代码，那样会浪费很多时间。
6. 调试工具与工程化扩展建议
6.1 串口日志：远程网络设备必备的“眼睛”
单片机接显示器不现实，远程调试没有显示器也没有键盘，所以串口日志就是最重要的观察窗口。我在固件初始化时固定输出一段完整启动信息，包括传感器初始化结果、MAC 地址、IP 地址、协议栈启动状态和温度轮询频率。
日志格式不必复杂，一行文本足够。关键是每次状态切换和错误触发都要输出标识符。比如传感器读失败时输出T_ERR 0x01，端口请求超时时输出NET_TIMEOUT。管理员只需要在电脑上打开串口终端，几百毫秒内就能判断故障层级。
我自己习惯把日志数据和 Modbus 寄存器分开，日志只走 UART，温度走网络。这样两个通道互不干扰，排查问题时各看各的。
6.2 远程升级预留与数据存储扩展
温度监测节点最大的环保难题是：设备装在那以后，固件有问题没法一键升级。PIC18F97J60 支持在线编程，但不到万不得已不要在产品里做全量在线升级，因为数据一旦中断，设备就直接断电变砖。
我权衡之后选择了一个折中方案：把关键参数存放在外部 EEPROM，固件本身不经常动。参数包括传感器地址、校准系数、上报周期、报警阈值。这样即使远程平台变更，也只需要通过预留的调试串口改写 EEPROM，不用反复烧录固件。
如果后续需要更长的历史数据，我会在板卡上再挂一个小型 SPI Flash，把温度数据按小时打包写入，网络崩溃时也不丢数据。这样整个系统就从“实时采集”升级成了“有存储的分布式记录仪”。
6.3 从单机温度节点到群组监控网的扩展路径
文章开头聊的是单块板卡，但把 PIC18F97J60 同时配置为 HTTP 服务器和 Modbus TCP 从站后，扩展能力就很强了。多块板卡可以各自接入交换机，由上位机统一轮询，也可以再接一块 Modbus 网关，让 PLC 直接读寄存器。
在嵌入式应用里，我建议把温度数据上报周期设置成每 5 秒一次，HHVAC 场景下没必要太频繁，避免占用网络。要接入云端时，可以增加定时 TCP 主动连接云平台的机制，由设备作为客户端向服务器推送数据。这个方向和单纯的 Modbus 从站模式恰好互补。
我常常在项目里做两种远程模式的结合：对内给本地上位机提供 Modbus TCP 说，对外通过管理平台接口定时上报 JSON。只要在固件里保留两种协议栈分支，后续扩展不需要改动硬件。
6.4 我最后想分享的一点个人心得
硬件平台做到最后，发现最难的不是代码，不是电路，而是“温度数据就会不可信”的信任成本。这套 TJ85718DM 和 PIC18F97J60 的组合，一次上电就能输出温度，但让数据真正长期稳定可信，需要从选型、接线、固件、校准到现场排查全链路盯住。
如果只记住一件事，我会劝所有做类似项目的工程师：一开始就设计好诊断通道。串口日志、状态指示灯、参数寄存器、看门狗，这些看起来不起眼的东西，在设备运行半年以后会变成你唯一的救命稻草。做嵌入式温度监测，本质上是在给系统装一套“身体检查仪器”，自己先要健康，才能长期替你值守现场。
