★ FEATURED ARTICLE 做嵌入式温度采集项目我第一件事一定是先把“本地”和“远程”这两个词拆开想清楚本地是传感器紧挨着设备、手边能看到的实时温度远程是通过网络从几公里外随时拉走的同一份温度数据。标题里这套 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需额外处理器中本方案PJ85718DMPIC18F97J60I2C数字传感器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 时钟引脚比如 RC3SDA 接到单片机的 I2C 数据引脚比如 RC4SDA 和 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 摄氏度标准源下传感器测得 T050 摄氏度标准源下测得 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 或 0xFFI2C 地址错误或上拉电阻没接确认器件地址与代码一致检查 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 的组合一次上电就能输出温度但让数据真正长期稳定可信需要从选型、接线、固件、校准到现场排查全链路盯住。如果只记住一件事我会劝所有做类似项目的工程师一开始就设计好诊断通道。串口日志、状态指示灯、参数寄存器、看门狗这些看起来不起眼的东西在设备运行半年以后会变成你唯一的救命稻草。做嵌入式温度监测本质上是在给系统装一套“身体检查仪器”自己先要健康才能长期替你值守现场。
阅读完成 · 觉得有帮助？
