做嵌入式温控项目的时候温度采集这块听着最简单可一到现场就翻车的情况我见过太多次。拿 PJ85718DM 配上 PIC24FJ64GB004 这套组合来做嵌入式和 HVAC 环境下的本地与远程温度监测是我实际调试里比较稳的一套方案。PJ85718DM 负责把温度变成数字量PIC24FJ64GB004 则把所有读数汇总、换算、显示并上传两块芯片一配合就能在设备机柜附近测一路“本地温度”同时把另一路探头放到风道、室外机旁边甚至几十米外的远端房间解决暖通空调项目里最常见的多点测温需求。这篇文章我就从硬件选型、接线布局、I2C 驱动、固件状态机到现场常见坑完整讲一遍适合正在做温控器、传感器节点或者楼宇自控采集模块的朋友参考。1. 先理需求这套方案到底要解决什么问题1.1 “本地和远程温度”的工程含义很多人看到标题里“本地与远程温度”第一反应是“远程监控”也就是把温度数据传到云端或电脑上看。但在这个项目里真正的问题是物理层面上的两个测量点一个探头放在控制器本体附近测的是设备所在环境或回风温度另一个探头放在离控制器有一段距离的位置比如风管内部、送风口、室外冷凝器旁边、库房远端。两路温度数据只有同时拿到才能做温差计算、新风阀调节、防冻保护或者启停判断。以 HVAC 场景为例一台空气处理机组通常需要同时看回风温度和送风温度。回风温度可以理解为系统当前吸入的“本地温度”送风温度可以理解为经过处理和输送后的“远程温度”两者之间的差值直接反映盘管的制冷/制热效果。如果把室外环境温度也拉进来还要再挂第三只探头。这就要求主控 MCU 不只能读一个传感器而是能稳定地管理多个数字温度传感器。在嵌入式设备里“本地”和“远程”也可能指主板上贴片传感器测的板级温度以及通过排线引到外壳外部或机箱角落的探头温度。比如电池管理系统里保护板温度是本地电芯表面温度算远程在服务器机柜监控里控制板旁边温度是本地机柜顶部热点算远程。虽然应用不同但底层技术路径完全相同所以这套 PJ85718DM 加 PIC24FJ64GB004 的组合具备很强的迁移性。1.2 为什么我没有继续用热敏电阻方案早期做温控项目很多开发者习惯用一个 NTC 热敏电阻加上分压电阻接到 MCU 的 ADC 引脚上再用查表法或者 Steinhart-Hart 方程换算温度。这套做法不是不能做但工程现场越复杂问题越明显。首先是引线电阻问题NTC 探头拉长到十米导线本身的电阻会叠加到分压电路里读数可能偏好几度。其次是 ADC 参考电压波动HVAC 现场常有压缩机、风机启停电源电压跌落和纹波会直接干扰采样结果。再次是每个通道都要单独校准两路 NTC 的 B 值离散性不一样标定工作量大得惊人。换成 PJ85718DM 这类集成数字输出温度传感器之后温度到数字量的转换直接在探头端完成信号线上传输的是数字脉冲而不是模拟电压线长对精度的影响小得多也不用再担心分压电阻和 ADC 漂移。更关键的是数字传感器可以采用总线式多点挂接多个探头共用两根信号线MCU 通过地址区分设备硬件布线量大幅减少。我之前做过一个对比测试同样的两路测温需求模拟 NTC 方案成本虽然能低一两块钱但调试时间多花至少两天还要专门写校准表数字传感器方案一次性把硬件和驱动打通后换成新点位只需要改配置现场更换探头也不用重新标定。做产品如果出货量大省下的维护成本远大于那点物料差价。这里把两种方案的关键差异整理成一张表方便按项目需求取舍。对比项NTC 热敏电阻方案PJ85718DM 数字传感器方案输出形式模拟分压电压数字总线数据线长影响引线电阻会带来明显误差数字信号抗线阻干扰多路扩展每路占一个 ADC 通道多探头共享总线按地址区分标定工作量需要逐通道校准出厂校准直接读取抗电源波动依赖 ADC 参考易受影响数字转换在探头端完成适用场景短距离、低成本、单点HVAC、多点、较长走线这套对比并不是说 NTC 一无是处如果只是手边做一个演示板传感器离 MCU 不到五厘米也不求什么精度那 NTC 完全够用。但只要涉及 HVAC 这种需要长期稳定运行的场景我一般都直接用数字传感器省下来的时间足够做更重要的事。2. 硬件连接与系统布局2.1 引脚分配与电平匹配PIC24FJ64GB004 是一颗 16 位 MCU工作电压范围可以到 3.3V 左右内部外设丰富尤其适合做这种带通信接口的采集节点。我在项目里把 I2C1 模块作为传感器总线SCL 和 SDA 各选了一个可编程引脚映射引脚方便改版时重新分配引脚而不动 PCB 走线。传感器这一侧PJ85718DM 的不同批次或不同封装尾缀具体管脚会有差异但作为数字温度传感器核心一定是 VDD、GND、SDA、SCL 这四个管脚。我搭实验板时习惯这样连接PJ85718DM 引脚连接到 PIC24FJ64GB004说明VDD3.3V 电源传感器电源需要与 MCU 供电共地GNDGND公共地线SDA可配置的 I2C 数据引脚开漏输出接上拉电阻SCL可配置的 I2C 时钟引脚开漏输出接上拉电阻地址选择脚如有拉高/拉低或由拨码开关控制用于区分本地和远程传感器地址这里最容易踩坑的是电平匹配。PIC24FJ64GB004 的 I/O 是 3.3V 逻辑而某些版本的传感器模块支持更宽电源范围出厂时可能被接在 5V 供电上。为了避免 I2C 高电平冲突我的做法是传感器与 MCU 统一使用 3.3V 供电这样 SDA 和 SCL 都在同一个电平体系内不用额外加电平转换芯片。如果你手里的 PJ85718DM 必须用 5V 供电那么 I2C 上拉电阻建议接到 3.3V让总线高电平被限制在 3.3V再确认传感器引脚是否允许 5V 耐受一般开漏结构问题不大但一定要看手册确认。I2C 总线还必须接上拉电阻。单片机内部的 I2C 引脚是开漏输出只能把总线拉低不能主动拉高所以正常状态靠外部电阻把 SCL 和 SDA 拉到高电平。我常用的上拉电阻是 4.7kΩ适用于较短走线如果远程传感器线拉到 20 米以上上拉电阻可以降到 2.2kΩ以增强总线上拉能力但这样灌电流会稍微增加具体数值要结合器件手册算一下避免超出 I/O 绝对最大额定值。2.2 远程探头的布线与抗干扰“远程温度”这个词在实际项目中可能意味着探头离控制器只有几十厘米也可能意味着穿越整个楼层、沿着风管走到几十米外。距离一变电子设计的重点就完全不一样了。短距离布线的难点在于物理固定。本地传感器贴在控制器附近时我习惯用导热硅脂加铝箔胶带把传感器封装的一面贴在待测面上再用扎带固定保证探头和环境之间的热阻稳定。不要直接悬空放在空气中悬空探头读到的更多是探头自身附近局部空气的温度而不是你想测的表面温度。长距离布线的难点在信号完整性和电源压降。PJ85718DM 这类数字传感器工作电流通常不高几十米细线的压降不至于让芯片掉电但总线电容会明显增加导致 I2C 信号上升沿变缓、通信不稳定。我的处理思路有三点一是把 I2C 时钟频率从 100kHz 降到 10kHz 到 20kHz牺牲一点刷新速度换取稳定性二是选用带屏蔽的双绞线屏蔽层只在 MCU 端单点接地避免两端接地形成地环路三是数据线和电源线分开走至少不要跟 220V 动力线或者变频器输出线绑在同一个线槽里。还有一种更稳妥的做法远程距离实在太远比如超过 30 米就不要直接拉 I2C 了可以在远程端加一块小从机板把 PJ85718DM 接到另一颗低功耗 MCU 上再通过 RS485 传回主控。不过本文这套方案默认控制在二三十米内的 HVAC 现场用好屏蔽和低速 I2C 已经足够。2.3 电源与暖通现场常见干扰源HVAC 现场可以说是嵌入式系统最不友好的电气环境之一。压缩机启动瞬间电流很大母线电压可能被拉低变频器工作会产生丰富的谐波风机继电器动作时会产生浪涌。所有这些都会通过电源线和空间辐射耦合到传感器总线上。所以在电源设计上我建议主控板入口先加一个防反接二极管和保险丝然后经过 DC-DC 或者 LDO 把电压降到 3.3V。传感器供电不要跟继电器或风机驱动共享电源走线至少要从主电容之后单独引一路加 0.1μF 去耦电容条件允许再加一个 10μF 电解电容。曾经我遇到过现场温度读数每隔几秒就跳一次后来发现是传感器和继电器共用了同一组低压电源线继电器吸合瞬间产生的电流毛刺把传感器供电电压拉得波动导致转换结果异常。把这路供电单独分开后问题立刻消失。如果是室外安装的远程探头还建议加上简单的 TVS 瞬态抑制器件和串联限流电阻防止雷击感应和静电打坏传感器。HVAC 现场很多探头装在屋顶、外墙上雷电感应电压很容易通过长线进入总线只靠芯片内部的保护电路不太够。我这边一般是接口处加一个小封装 TVS几十伏的钳位电压对通信信号没有影响但能把浪涌憋住。3. 传感器驱动与温度换算3.1 I2C 读取流程PJ85718DM 的典型读取流程可以概括为“启动总线、发送设备地址、发起温度转换、等待转换结束、读回温度寄存器”。我按最常见的数字温度传感器操作方式来演示代码具体寄存器地址如果你手里的版本不同就对应替换成数据手册里的地址。先写一个初始化函数把 I2C1 配置成主模式并设置时钟频率。这里用抽象层 API 表示实际工程里可以根据你熟悉的底层库直接展开核心思路一致。void i2c_init(void) { // 配置引脚映射将 SCL/SDA 映射到目标引脚 i2c_remap_pins(I2C1_SCL_PIN, I2C1_SDA_PIN); // 初始化 I2C 控制器为主模式目标频率 100kHz i2c_master_enable(I2C1, 100000, I2C_PIN_MAP_OK); }然后写一个通用的温度读取函数。函数内部先向传感器写入温度寄存器地址然后重新发起起始信号切换为读方向连续读两个字节得到一个 16 位原始数据。static int read_temperature(uint8_t addr, float *temp_celsius) { uint8_t rx[2]; // 1. 起始 写地址 写入温度寄存器地址 if (i2c_start(I2C1, addr 1 | I2C_WRITE) ! I2C_OK) { return -1; } if (i2c_write_byte(I2C1, 0x00) ! I2C_OK) { i2c_stop(I2C1); return -2; } i2c_stop(I2C1); // 2. 等待转换完成通常需要 10ms 到 100ms delay_ms(50); // 3. 重新起始 读地址 读两个温度字节 if (i2c_start(I2C1, addr 1 | I2C_READ) ! I2C_OK) { return -3; } rx[0] i2c_read_byte(I2C1, I2C_ACK); rx[1] i2c_read_byte(I2C1, I2C_NACK); i2c_stop(I2C1); // 4. 合并为有符号 16 位原始值 int16_t raw (int16_t)((rx[0] 8) | rx[1]); *temp_celsius (float)raw * 0.0625f; return 0; }之所以要有等待转换这一步是因为数字温度传感器并非实时输出模拟量而是内部完成模数转换后再把结果放到寄存器里。如果你刚发完转换命令立刻去读读到的可能是上一次的旧值或者转换尚未完成时的无效数据。我调试时见过有人在这里栽跟头温度数据看起来在变但有规律地滞后一拍就是因为没等转换完成。3.2 原始值到摄氏度的换算与滤波PJ85718DM 如果采用 12 位温度分辨率那么每个最小单位对应 0.0625℃也就是 1/16℃这跟很多常见数字温度传感器一致。Hex 数据拼出来后先转成有符号 16 位整型再乘上 0.0625 就能得到摄氏度。举例来说如果读到的高字节是 0x01低字节是 0xE0拼起来是 0x01E0十进制是 480那么温度就是 480 × 0.0625 30.0℃。负温度用二进制补码表示0xFF38 作为有符号数等于 -200换算出来就是 -12.5℃这个量程对 HVAC 的防冻保护来说绝对够用。原始数据十六进制有符号十进制温度℃0x00A016010.000x01E048030.000x01F450031.250xFF38-200-12.500xFED0-304-19.00不过原始温度值读出来之后不要直接拿去用现场环境一定会给你“惊喜”。风机启动时气流扰动、压缩机停止时冷媒回流、阳光间歇性照射都会让温度读数毛刺不断。我一般做一个长度为 5 的滑动窗口取中值或者平均值作为最终显示值。中值滤波对尖峰毛刺抑制最好平均值滤波则让曲线更平滑。两者也可以结合先做一次中值剔除异常再对保留数据做轻量平均。float temp_filtered 0.0f; const int WINDOW_LEN 5; // 假设 raw_values 是环形缓冲区存最近 5 次换算后的温度 float median_filter(float *buf, int len) { // 对 buf 做插入排序取中间值 float tmp[5]; for (int i 0; i len; i) tmp[i] buf[i]; for (int i 0; i len - 1; i) { for (int j i 1; j len; j) { if (tmp[j] tmp[i]) { float t tmp[i]; tmp[i] tmp[j]; tmp[j] t; } } } return tmp[len / 2]; }滤波之后本地和远程温度就都变成了稳定可靠的数字可以放心交给上层逻辑去显示、上传、做温差判断了。4. 固件架构与数据上送4.1 状态机式采集主循环很多人写这种测温程序喜欢用一个大 while 循环里面先读本地、再读远程、再刷新屏幕、再发串口顺序执行全部写完再从第一行开始。这样写临时测试没问题但放到 HVAC 控制板上长期跑有一点隐患假如远程传感器通信卡住整个循环就会被阻塞在等待返回里导致显示不刷新、串口不发送、本地温度也没人读。我后来改成了状态机结构每一步只执行一个动作然后立刻跳出让主循环保持高速空转通过状态切换来推进整个流程。这样做的好处是单个传感器故障不会拖垮全部功能而且每个状态都可以加超时看门狗超时后强制跳转到下一个状态。typedef enum { ST_READ_LOCAL, ST_READ_REMOTE, ST_UPDATE_DISPLAY, ST_SEND_UART, ST_WAIT } AppState; AppState state ST_READ_LOCAL; uint32_t last_tick 0; while (1) { switch (state) { case ST_READ_LOCAL: if (read_temperature(LOCAL_ADDR, local_temp) ! 0) { local_temp_valid 0; } else { local_temp_valid 1; } state ST_READ_REMOTE; break; case ST_READ_REMOTE: if (read_temperature(REMOTE_ADDR, remote_temp) ! 0) { remote_temp_valid 0; } else { remote_temp_valid 1; } state ST_UPDATE_DISPLAY; break; case ST_UPDATE_DISPLAY: update_lcd(local_temp, remote_temp); state ST_SEND_UART; break; case ST_SEND_UART: send_temperature_frame(local_temp, remote_temp, local_temp_valid, remote_temp_valid); state ST_WAIT; break; case ST_WAIT: // 每 500ms 完成一个完整周期 state ST_READ_LOCAL; break; } // 喂看门狗防止状态卡死 wdt_clear(); }状态机的好处是每个分支都能独立判断成功失败。本地传感器读到远程传感器读取失败代码照样能显示本地温度串口照样能发一个带“远程无效”标记的帧。仪式感再强一点的话还可以为总线增加重连机制读失败三次后让 I2C 控制器完全复位一次很多时候总线被外部噪声干扰后复位就能恢复。4.2 USB、串口与 Modbus 数据上送PIC24FJ64GB004 自带 USB 控制器这是它很适合这类项目的原因之一。开发阶段的调试数据可以直接通过 USB CDC 虚拟串口传到电脑上电脑端用一个串口助手就能实时看到温度和健康状态。我习惯在调试固件里加一个简单的文本协议每一行输出本地温度、远程温度和状态标志比如LOCAL30.00 REMOTE22.50 DT7.50 VA1/1其中 VA1/1 表示两路传感器都有效如果远程坏了就是 VA1/0这样在调试现场瞄一眼串口日志就知道哪一路出了问题。但是真正进 HVAC 行业光是 USB 不够。楼宇自控系统里最常看到的还是 RS485 总线加 Modbus RTU 协议因为 RS485 传输距离远能挂几十个设备抗干扰能力比普通串口强太多而且老旧的现场监控平台普遍兼容 Modbus。做产品时我会在电路板上预留 RS485 接口用一个隔离收发器接到 MCU 的 UART 上固件里实现一个精简的 Modbus 从机。Modbus 上报温度的寄存器粗略设计如下寄存器地址内容格式0x0000本地温度有符号 16 位0.01℃ 分辨率0x0001远程温度有符号 16 位0.01℃ 分辨率0x0002状态字bit0本地传感器有效bit1远程传感器有效0x0003设备型号固定值如 0x0001这里的做法是把浮点温度乘 100 转成整数再放到寄存器里。比如 30.00℃ 存成 3000-12.50℃ 存成 -1250。上位机拿到寄存器值后除以 100 就是实际温度。这么做的好处是整数运算在 Modbus 协议里非常稳不用处理浮点字节序也方便老平台解析。4.3 本地显示与偏移校准无论数据是否上传我都建议在设备上加一个本地显示。HVAC 现场调试时调试员摸摸风管看看屏幕上的温度再对比远程探头位置的实际温度几秒钟就能判断探头是否安装合理。如果没有显示只能回机房接电脑看数据效率低很多。LCD 显示不复杂I2C 接口的字符屏或者段码屏都可以。我选显示内容时会同时显示三个值本地温度、远程温度、温差。温差就是本次实测的本地温度减去远程温度。HVAC 调试时温差这个数值非常直观当预期温差是 5℃ 而实际只有 1℃ 时基本可以断定盘管堵塞、风量不足或者水阀没打开比看两个原始温度再心算要省力得多。还要提供一个偏移校准功能。安装在现场的探头难免被局部环境干扰比如本地传感器靠近发热元件、远程传感器被太阳照射读数与实际温度有固定偏差。我不主张在固件里写死校准值而是预留两个可调的偏移量比如本地偏移 0.5℃远程偏移 -1.0℃通过按键或串口命令写入 EEPROM。这样现场修改参数时不用重新刷固件维护人员也能自己处理。5. 现场调试、常见故障与排查方法5.1 常见故障速查表现场跑过几个项目之后我把测得的问题整理成了速查表。每次遇到新报障先对号入座能省下很多时间。故障现象可能原因排查思路与解决完全读不到传感器地址配置错误、接线反了用逻辑分析仪看 I2C 波形确认地址和 ACK偶尔读不到重新插拔就好接插件接触不良改用带锁扣的插头或直接焊接远程读数跳变明显总线受干扰或上拉电阻不合适降速加屏蔽调整上拉电阻远程读数整体偏高探头靠近发热源或受太阳辐射调整安装位置增加遮阳罩本地读数比室温高很多MCU 发热影响探头尽量远离功率器件增加导热路径两路读数显示同一数值两个传感器地址相同检查地址引脚设置确保两路地址不同上电时正常几分钟后读数乱跳电路板局部温度过高或供电不稳用热成像看板温检查传感器电源波形这张表看起来简单但每一条背后都有真实案例。接下来挑三个我印象最深的展开聊聊。5.2 我实际调试中踩过的三个坑第一个坑是远程传感器线拉得特别长大概有 15 米用的是普通网线中的一对双绞线。初始配置 I2C 时钟 100kHz结果远程读数时不时就跳一次甚至直接丢失应答。后来我用示波器看 SDA 线上的波形发现上升沿明显变缓到了传感器端高电平阈值附近拖了很久。解决方案很简单把 I2C 时钟降到 20kHz并把上拉电阻从 4.7kΩ 换成 2.2kΩ。改了之后总线波形明显变得干净再也没有随机丢应答。第二个坑更隐蔽。现场显示板上本地温度一直比实际室温高 3℃而且非常稳定。一开始我怀疑传感器精度不行后来拆开设备才发现本地传感器被我固定得太靠近电源模块而且中间隔的铝板就是电源模块的散热片。电源模块的温升直接传导到了传感器位置。解决方法是把探头移到控制板边缘远离功率器件同时用一段导热硅胶把探头和外壳之间连接起来让热量更多导走而不是只停留在探头周围。调整后偏差降到了 0.2℃ 以内。第三个坑出现在一个湿度比较大的空调箱旁边远程探头装在回风口附近数据白天正常到了夜间湿度升高时读数偏高。检查发现探头封装表面已经结了一层水膜。水膜受气流蒸发时带走了探头表面的热量探头反而应该偏低但实际偏高是因为水膜形成后在探头周围形成了一个相对保温的微气候层。解决方法是给探头加了一个简易防辐射罩让传感器裸露端不和气流直接接触阻挡飞溅水滴同时保持通风问题就消失了。5.3 HVAC 场景不可忽略的温度测量细节HVAC 场景里传感器测量误差很多时候不是芯片本身带来的而是安装方式带来的。测空气温度时探头和风速之间关系很大。如果探头直接裸露在送风管道里高速气流吹过传感器底座带走部分热量读数可能偏低零点几度如果探头被隔热材料包得太严实热量散不出去读数又会偏高。所以在管道里测温度不能只看波动的瞬时值要在同一位置吹风和不吹风状态下分别读一次再判断系统的真实温度。测室外温度时要注意太阳辐射。同一只 PJ85718DM放在太阳直射的墙面上和放在百叶箱里读数能差 5℃ 以上。HVAC 项目里室外温度多用于节能策略计算差 5℃ 会导致整个控制逻辑跑偏。我现在的做法是室外探头必须装在背阴处外加一个白色防辐射罩让空气从小孔对流进罩内避免阳光直接辐射到传感器封装上。另外还要注意传感器自身发热的问题。任何数字温度传感器在工作时都会有一点自发热只不过电流小所以温升不明显。但如果你给传感器外壳包了很厚的保温材料同时读数间隔很短热量积累起来读数也会偏高。所以我一般把探头的转换周期控制在 250ms 到 1s 之间不让芯片一直处于高频率转换状态这样自发热对精度的影响可以忽略。6. 写在最后这套方案还能往哪走做完整套项目我最大的体会是温度监测的难点从来不在“把温度读出来”而在“把温度读得稳定、一致、可解释”。PJ85718DM 和 PIC24FJ64GB004 的组合在嵌入式测温领域算是非常经典的路子数字传感器负责把物理量前置数字化MCU 负责把数字变成信息和决策。只要把硬件布局、总线抗干扰和状态机架构做好这套系统可以很轻松地扩展到更多探头、更多控制逻辑。如果你想继续往深处做我建议留一路备用 GPIO 接一个继电器或者蜂鸣器当本地和远程温差超过设定值时发出报警也可以再接一个外部 EEPROM把过去 24 小时的温度曲线记录下来方便后期排查故障。甚至可以把采集周期和滤波算法做成参数化配置通过串口命令在线调整这样固件不用经常动现场适配能力会强很多。温度监测看起来是小功能但把它做扎实了整个嵌入式设备的可靠性和可维护性都会跟着上一个台阶。
做嵌入式温控项目的时候温度采集这块听着最简单可一到现场就翻车的情况我见过太多次。拿 PJ85718DM 配上 PIC24FJ64GB004 这套组合来做嵌入式和 HVAC 环境下的本地与远程温度监测是我实际调试里比较稳的一套方案。PJ85718DM 负责把温度变成数字量PIC24FJ64GB004 则把所有读数汇总、换算、显示并上传两块芯片一配合就能在设备机柜附近测一路“本地温度”同时把另一路探头放到风道、室外机旁边甚至几十米外的远端房间解决暖通空调项目里最常见的多点测温需求。这篇文章我就从硬件选型、接线布局、I2C 驱动、固件状态机到现场常见坑完整讲一遍适合正在做温控器、传感器节点或者楼宇自控采集模块的朋友参考。1. 先理需求这套方案到底要解决什么问题1.1 “本地和远程温度”的工程含义很多人看到标题里“本地与远程温度”第一反应是“远程监控”也就是把温度数据传到云端或电脑上看。但在这个项目里真正的问题是物理层面上的两个测量点一个探头放在控制器本体附近测的是设备所在环境或回风温度另一个探头放在离控制器有一段距离的位置比如风管内部、送风口、室外冷凝器旁边、库房远端。两路温度数据只有同时拿到才能做温差计算、新风阀调节、防冻保护或者启停判断。以 HVAC 场景为例一台空气处理机组通常需要同时看回风温度和送风温度。回风温度可以理解为系统当前吸入的“本地温度”送风温度可以理解为经过处理和输送后的“远程温度”两者之间的差值直接反映盘管的制冷/制热效果。如果把室外环境温度也拉进来还要再挂第三只探头。这就要求主控 MCU 不只能读一个传感器而是能稳定地管理多个数字温度传感器。在嵌入式设备里“本地”和“远程”也可能指主板上贴片传感器测的板级温度以及通过排线引到外壳外部或机箱角落的探头温度。比如电池管理系统里保护板温度是本地电芯表面温度算远程在服务器机柜监控里控制板旁边温度是本地机柜顶部热点算远程。虽然应用不同但底层技术路径完全相同所以这套 PJ85718DM 加 PIC24FJ64GB004 的组合具备很强的迁移性。1.2 为什么我没有继续用热敏电阻方案早期做温控项目很多开发者习惯用一个 NTC 热敏电阻加上分压电阻接到 MCU 的 ADC 引脚上再用查表法或者 Steinhart-Hart 方程换算温度。这套做法不是不能做但工程现场越复杂问题越明显。首先是引线电阻问题NTC 探头拉长到十米导线本身的电阻会叠加到分压电路里读数可能偏好几度。其次是 ADC 参考电压波动HVAC 现场常有压缩机、风机启停电源电压跌落和纹波会直接干扰采样结果。再次是每个通道都要单独校准两路 NTC 的 B 值离散性不一样标定工作量大得惊人。换成 PJ85718DM 这类集成数字输出温度传感器之后温度到数字量的转换直接在探头端完成信号线上传输的是数字脉冲而不是模拟电压线长对精度的影响小得多也不用再担心分压电阻和 ADC 漂移。更关键的是数字传感器可以采用总线式多点挂接多个探头共用两根信号线MCU 通过地址区分设备硬件布线量大幅减少。我之前做过一个对比测试同样的两路测温需求模拟 NTC 方案成本虽然能低一两块钱但调试时间多花至少两天还要专门写校准表数字传感器方案一次性把硬件和驱动打通后换成新点位只需要改配置现场更换探头也不用重新标定。做产品如果出货量大省下的维护成本远大于那点物料差价。这里把两种方案的关键差异整理成一张表方便按项目需求取舍。对比项NTC 热敏电阻方案PJ85718DM 数字传感器方案输出形式模拟分压电压数字总线数据线长影响引线电阻会带来明显误差数字信号抗线阻干扰多路扩展每路占一个 ADC 通道多探头共享总线按地址区分标定工作量需要逐通道校准出厂校准直接读取抗电源波动依赖 ADC 参考易受影响数字转换在探头端完成适用场景短距离、低成本、单点HVAC、多点、较长走线这套对比并不是说 NTC 一无是处如果只是手边做一个演示板传感器离 MCU 不到五厘米也不求什么精度那 NTC 完全够用。但只要涉及 HVAC 这种需要长期稳定运行的场景我一般都直接用数字传感器省下来的时间足够做更重要的事。2. 硬件连接与系统布局2.1 引脚分配与电平匹配PIC24FJ64GB004 是一颗 16 位 MCU工作电压范围可以到 3.3V 左右内部外设丰富尤其适合做这种带通信接口的采集节点。我在项目里把 I2C1 模块作为传感器总线SCL 和 SDA 各选了一个可编程引脚映射引脚方便改版时重新分配引脚而不动 PCB 走线。传感器这一侧PJ85718DM 的不同批次或不同封装尾缀具体管脚会有差异但作为数字温度传感器核心一定是 VDD、GND、SDA、SCL 这四个管脚。我搭实验板时习惯这样连接PJ85718DM 引脚连接到 PIC24FJ64GB004说明VDD3.3V 电源传感器电源需要与 MCU 供电共地GNDGND公共地线SDA可配置的 I2C 数据引脚开漏输出接上拉电阻SCL可配置的 I2C 时钟引脚开漏输出接上拉电阻地址选择脚如有拉高/拉低或由拨码开关控制用于区分本地和远程传感器地址这里最容易踩坑的是电平匹配。PIC24FJ64GB004 的 I/O 是 3.3V 逻辑而某些版本的传感器模块支持更宽电源范围出厂时可能被接在 5V 供电上。为了避免 I2C 高电平冲突我的做法是传感器与 MCU 统一使用 3.3V 供电这样 SDA 和 SCL 都在同一个电平体系内不用额外加电平转换芯片。如果你手里的 PJ85718DM 必须用 5V 供电那么 I2C 上拉电阻建议接到 3.3V让总线高电平被限制在 3.3V再确认传感器引脚是否允许 5V 耐受一般开漏结构问题不大但一定要看手册确认。I2C 总线还必须接上拉电阻。单片机内部的 I2C 引脚是开漏输出只能把总线拉低不能主动拉高所以正常状态靠外部电阻把 SCL 和 SDA 拉到高电平。我常用的上拉电阻是 4.7kΩ适用于较短走线如果远程传感器线拉到 20 米以上上拉电阻可以降到 2.2kΩ以增强总线上拉能力但这样灌电流会稍微增加具体数值要结合器件手册算一下避免超出 I/O 绝对最大额定值。2.2 远程探头的布线与抗干扰“远程温度”这个词在实际项目中可能意味着探头离控制器只有几十厘米也可能意味着穿越整个楼层、沿着风管走到几十米外。距离一变电子设计的重点就完全不一样了。短距离布线的难点在于物理固定。本地传感器贴在控制器附近时我习惯用导热硅脂加铝箔胶带把传感器封装的一面贴在待测面上再用扎带固定保证探头和环境之间的热阻稳定。不要直接悬空放在空气中悬空探头读到的更多是探头自身附近局部空气的温度而不是你想测的表面温度。长距离布线的难点在信号完整性和电源压降。PJ85718DM 这类数字传感器工作电流通常不高几十米细线的压降不至于让芯片掉电但总线电容会明显增加导致 I2C 信号上升沿变缓、通信不稳定。我的处理思路有三点一是把 I2C 时钟频率从 100kHz 降到 10kHz 到 20kHz牺牲一点刷新速度换取稳定性二是选用带屏蔽的双绞线屏蔽层只在 MCU 端单点接地避免两端接地形成地环路三是数据线和电源线分开走至少不要跟 220V 动力线或者变频器输出线绑在同一个线槽里。还有一种更稳妥的做法远程距离实在太远比如超过 30 米就不要直接拉 I2C 了可以在远程端加一块小从机板把 PJ85718DM 接到另一颗低功耗 MCU 上再通过 RS485 传回主控。不过本文这套方案默认控制在二三十米内的 HVAC 现场用好屏蔽和低速 I2C 已经足够。2.3 电源与暖通现场常见干扰源HVAC 现场可以说是嵌入式系统最不友好的电气环境之一。压缩机启动瞬间电流很大母线电压可能被拉低变频器工作会产生丰富的谐波风机继电器动作时会产生浪涌。所有这些都会通过电源线和空间辐射耦合到传感器总线上。所以在电源设计上我建议主控板入口先加一个防反接二极管和保险丝然后经过 DC-DC 或者 LDO 把电压降到 3.3V。传感器供电不要跟继电器或风机驱动共享电源走线至少要从主电容之后单独引一路加 0.1μF 去耦电容条件允许再加一个 10μF 电解电容。曾经我遇到过现场温度读数每隔几秒就跳一次后来发现是传感器和继电器共用了同一组低压电源线继电器吸合瞬间产生的电流毛刺把传感器供电电压拉得波动导致转换结果异常。把这路供电单独分开后问题立刻消失。如果是室外安装的远程探头还建议加上简单的 TVS 瞬态抑制器件和串联限流电阻防止雷击感应和静电打坏传感器。HVAC 现场很多探头装在屋顶、外墙上雷电感应电压很容易通过长线进入总线只靠芯片内部的保护电路不太够。我这边一般是接口处加一个小封装 TVS几十伏的钳位电压对通信信号没有影响但能把浪涌憋住。3. 传感器驱动与温度换算3.1 I2C 读取流程PJ85718DM 的典型读取流程可以概括为“启动总线、发送设备地址、发起温度转换、等待转换结束、读回温度寄存器”。我按最常见的数字温度传感器操作方式来演示代码具体寄存器地址如果你手里的版本不同就对应替换成数据手册里的地址。先写一个初始化函数把 I2C1 配置成主模式并设置时钟频率。这里用抽象层 API 表示实际工程里可以根据你熟悉的底层库直接展开核心思路一致。void i2c_init(void) { // 配置引脚映射将 SCL/SDA 映射到目标引脚 i2c_remap_pins(I2C1_SCL_PIN, I2C1_SDA_PIN); // 初始化 I2C 控制器为主模式目标频率 100kHz i2c_master_enable(I2C1, 100000, I2C_PIN_MAP_OK); }然后写一个通用的温度读取函数。函数内部先向传感器写入温度寄存器地址然后重新发起起始信号切换为读方向连续读两个字节得到一个 16 位原始数据。static int read_temperature(uint8_t addr, float *temp_celsius) { uint8_t rx[2]; // 1. 起始 写地址 写入温度寄存器地址 if (i2c_start(I2C1, addr 1 | I2C_WRITE) ! I2C_OK) { return -1; } if (i2c_write_byte(I2C1, 0x00) ! I2C_OK) { i2c_stop(I2C1); return -2; } i2c_stop(I2C1); // 2. 等待转换完成通常需要 10ms 到 100ms delay_ms(50); // 3. 重新起始 读地址 读两个温度字节 if (i2c_start(I2C1, addr 1 | I2C_READ) ! I2C_OK) { return -3; } rx[0] i2c_read_byte(I2C1, I2C_ACK); rx[1] i2c_read_byte(I2C1, I2C_NACK); i2c_stop(I2C1); // 4. 合并为有符号 16 位原始值 int16_t raw (int16_t)((rx[0] 8) | rx[1]); *temp_celsius (float)raw * 0.0625f; return 0; }之所以要有等待转换这一步是因为数字温度传感器并非实时输出模拟量而是内部完成模数转换后再把结果放到寄存器里。如果你刚发完转换命令立刻去读读到的可能是上一次的旧值或者转换尚未完成时的无效数据。我调试时见过有人在这里栽跟头温度数据看起来在变但有规律地滞后一拍就是因为没等转换完成。3.2 原始值到摄氏度的换算与滤波PJ85718DM 如果采用 12 位温度分辨率那么每个最小单位对应 0.0625℃也就是 1/16℃这跟很多常见数字温度传感器一致。Hex 数据拼出来后先转成有符号 16 位整型再乘上 0.0625 就能得到摄氏度。举例来说如果读到的高字节是 0x01低字节是 0xE0拼起来是 0x01E0十进制是 480那么温度就是 480 × 0.0625 30.0℃。负温度用二进制补码表示0xFF38 作为有符号数等于 -200换算出来就是 -12.5℃这个量程对 HVAC 的防冻保护来说绝对够用。原始数据十六进制有符号十进制温度℃0x00A016010.000x01E048030.000x01F450031.250xFF38-200-12.500xFED0-304-19.00不过原始温度值读出来之后不要直接拿去用现场环境一定会给你“惊喜”。风机启动时气流扰动、压缩机停止时冷媒回流、阳光间歇性照射都会让温度读数毛刺不断。我一般做一个长度为 5 的滑动窗口取中值或者平均值作为最终显示值。中值滤波对尖峰毛刺抑制最好平均值滤波则让曲线更平滑。两者也可以结合先做一次中值剔除异常再对保留数据做轻量平均。float temp_filtered 0.0f; const int WINDOW_LEN 5; // 假设 raw_values 是环形缓冲区存最近 5 次换算后的温度 float median_filter(float *buf, int len) { // 对 buf 做插入排序取中间值 float tmp[5]; for (int i 0; i len; i) tmp[i] buf[i]; for (int i 0; i len - 1; i) { for (int j i 1; j len; j) { if (tmp[j] tmp[i]) { float t tmp[i]; tmp[i] tmp[j]; tmp[j] t; } } } return tmp[len / 2]; }滤波之后本地和远程温度就都变成了稳定可靠的数字可以放心交给上层逻辑去显示、上传、做温差判断了。4. 固件架构与数据上送4.1 状态机式采集主循环很多人写这种测温程序喜欢用一个大 while 循环里面先读本地、再读远程、再刷新屏幕、再发串口顺序执行全部写完再从第一行开始。这样写临时测试没问题但放到 HVAC 控制板上长期跑有一点隐患假如远程传感器通信卡住整个循环就会被阻塞在等待返回里导致显示不刷新、串口不发送、本地温度也没人读。我后来改成了状态机结构每一步只执行一个动作然后立刻跳出让主循环保持高速空转通过状态切换来推进整个流程。这样做的好处是单个传感器故障不会拖垮全部功能而且每个状态都可以加超时看门狗超时后强制跳转到下一个状态。typedef enum { ST_READ_LOCAL, ST_READ_REMOTE, ST_UPDATE_DISPLAY, ST_SEND_UART, ST_WAIT } AppState; AppState state ST_READ_LOCAL; uint32_t last_tick 0; while (1) { switch (state) { case ST_READ_LOCAL: if (read_temperature(LOCAL_ADDR, local_temp) ! 0) { local_temp_valid 0; } else { local_temp_valid 1; } state ST_READ_REMOTE; break; case ST_READ_REMOTE: if (read_temperature(REMOTE_ADDR, remote_temp) ! 0) { remote_temp_valid 0; } else { remote_temp_valid 1; } state ST_UPDATE_DISPLAY; break; case ST_UPDATE_DISPLAY: update_lcd(local_temp, remote_temp); state ST_SEND_UART; break; case ST_SEND_UART: send_temperature_frame(local_temp, remote_temp, local_temp_valid, remote_temp_valid); state ST_WAIT; break; case ST_WAIT: // 每 500ms 完成一个完整周期 state ST_READ_LOCAL; break; } // 喂看门狗防止状态卡死 wdt_clear(); }状态机的好处是每个分支都能独立判断成功失败。本地传感器读到远程传感器读取失败代码照样能显示本地温度串口照样能发一个带“远程无效”标记的帧。仪式感再强一点的话还可以为总线增加重连机制读失败三次后让 I2C 控制器完全复位一次很多时候总线被外部噪声干扰后复位就能恢复。4.2 USB、串口与 Modbus 数据上送PIC24FJ64GB004 自带 USB 控制器这是它很适合这类项目的原因之一。开发阶段的调试数据可以直接通过 USB CDC 虚拟串口传到电脑上电脑端用一个串口助手就能实时看到温度和健康状态。我习惯在调试固件里加一个简单的文本协议每一行输出本地温度、远程温度和状态标志比如LOCAL30.00 REMOTE22.50 DT7.50 VA1/1其中 VA1/1 表示两路传感器都有效如果远程坏了就是 VA1/0这样在调试现场瞄一眼串口日志就知道哪一路出了问题。但是真正进 HVAC 行业光是 USB 不够。楼宇自控系统里最常看到的还是 RS485 总线加 Modbus RTU 协议因为 RS485 传输距离远能挂几十个设备抗干扰能力比普通串口强太多而且老旧的现场监控平台普遍兼容 Modbus。做产品时我会在电路板上预留 RS485 接口用一个隔离收发器接到 MCU 的 UART 上固件里实现一个精简的 Modbus 从机。Modbus 上报温度的寄存器粗略设计如下寄存器地址内容格式0x0000本地温度有符号 16 位0.01℃ 分辨率0x0001远程温度有符号 16 位0.01℃ 分辨率0x0002状态字bit0本地传感器有效bit1远程传感器有效0x0003设备型号固定值如 0x0001这里的做法是把浮点温度乘 100 转成整数再放到寄存器里。比如 30.00℃ 存成 3000-12.50℃ 存成 -1250。上位机拿到寄存器值后除以 100 就是实际温度。这么做的好处是整数运算在 Modbus 协议里非常稳不用处理浮点字节序也方便老平台解析。4.3 本地显示与偏移校准无论数据是否上传我都建议在设备上加一个本地显示。HVAC 现场调试时调试员摸摸风管看看屏幕上的温度再对比远程探头位置的实际温度几秒钟就能判断探头是否安装合理。如果没有显示只能回机房接电脑看数据效率低很多。LCD 显示不复杂I2C 接口的字符屏或者段码屏都可以。我选显示内容时会同时显示三个值本地温度、远程温度、温差。温差就是本次实测的本地温度减去远程温度。HVAC 调试时温差这个数值非常直观当预期温差是 5℃ 而实际只有 1℃ 时基本可以断定盘管堵塞、风量不足或者水阀没打开比看两个原始温度再心算要省力得多。还要提供一个偏移校准功能。安装在现场的探头难免被局部环境干扰比如本地传感器靠近发热元件、远程传感器被太阳照射读数与实际温度有固定偏差。我不主张在固件里写死校准值而是预留两个可调的偏移量比如本地偏移 0.5℃远程偏移 -1.0℃通过按键或串口命令写入 EEPROM。这样现场修改参数时不用重新刷固件维护人员也能自己处理。5. 现场调试、常见故障与排查方法5.1 常见故障速查表现场跑过几个项目之后我把测得的问题整理成了速查表。每次遇到新报障先对号入座能省下很多时间。故障现象可能原因排查思路与解决完全读不到传感器地址配置错误、接线反了用逻辑分析仪看 I2C 波形确认地址和 ACK偶尔读不到重新插拔就好接插件接触不良改用带锁扣的插头或直接焊接远程读数跳变明显总线受干扰或上拉电阻不合适降速加屏蔽调整上拉电阻远程读数整体偏高探头靠近发热源或受太阳辐射调整安装位置增加遮阳罩本地读数比室温高很多MCU 发热影响探头尽量远离功率器件增加导热路径两路读数显示同一数值两个传感器地址相同检查地址引脚设置确保两路地址不同上电时正常几分钟后读数乱跳电路板局部温度过高或供电不稳用热成像看板温检查传感器电源波形这张表看起来简单但每一条背后都有真实案例。接下来挑三个我印象最深的展开聊聊。5.2 我实际调试中踩过的三个坑第一个坑是远程传感器线拉得特别长大概有 15 米用的是普通网线中的一对双绞线。初始配置 I2C 时钟 100kHz结果远程读数时不时就跳一次甚至直接丢失应答。后来我用示波器看 SDA 线上的波形发现上升沿明显变缓到了传感器端高电平阈值附近拖了很久。解决方案很简单把 I2C 时钟降到 20kHz并把上拉电阻从 4.7kΩ 换成 2.2kΩ。改了之后总线波形明显变得干净再也没有随机丢应答。第二个坑更隐蔽。现场显示板上本地温度一直比实际室温高 3℃而且非常稳定。一开始我怀疑传感器精度不行后来拆开设备才发现本地传感器被我固定得太靠近电源模块而且中间隔的铝板就是电源模块的散热片。电源模块的温升直接传导到了传感器位置。解决方法是把探头移到控制板边缘远离功率器件同时用一段导热硅胶把探头和外壳之间连接起来让热量更多导走而不是只停留在探头周围。调整后偏差降到了 0.2℃ 以内。第三个坑出现在一个湿度比较大的空调箱旁边远程探头装在回风口附近数据白天正常到了夜间湿度升高时读数偏高。检查发现探头封装表面已经结了一层水膜。水膜受气流蒸发时带走了探头表面的热量探头反而应该偏低但实际偏高是因为水膜形成后在探头周围形成了一个相对保温的微气候层。解决方法是给探头加了一个简易防辐射罩让传感器裸露端不和气流直接接触阻挡飞溅水滴同时保持通风问题就消失了。5.3 HVAC 场景不可忽略的温度测量细节HVAC 场景里传感器测量误差很多时候不是芯片本身带来的而是安装方式带来的。测空气温度时探头和风速之间关系很大。如果探头直接裸露在送风管道里高速气流吹过传感器底座带走部分热量读数可能偏低零点几度如果探头被隔热材料包得太严实热量散不出去读数又会偏高。所以在管道里测温度不能只看波动的瞬时值要在同一位置吹风和不吹风状态下分别读一次再判断系统的真实温度。测室外温度时要注意太阳辐射。同一只 PJ85718DM放在太阳直射的墙面上和放在百叶箱里读数能差 5℃ 以上。HVAC 项目里室外温度多用于节能策略计算差 5℃ 会导致整个控制逻辑跑偏。我现在的做法是室外探头必须装在背阴处外加一个白色防辐射罩让空气从小孔对流进罩内避免阳光直接辐射到传感器封装上。另外还要注意传感器自身发热的问题。任何数字温度传感器在工作时都会有一点自发热只不过电流小所以温升不明显。但如果你给传感器外壳包了很厚的保温材料同时读数间隔很短热量积累起来读数也会偏高。所以我一般把探头的转换周期控制在 250ms 到 1s 之间不让芯片一直处于高频率转换状态这样自发热对精度的影响可以忽略。6. 写在最后这套方案还能往哪走做完整套项目我最大的体会是温度监测的难点从来不在“把温度读出来”而在“把温度读得稳定、一致、可解释”。PJ85718DM 和 PIC24FJ64GB004 的组合在嵌入式测温领域算是非常经典的路子数字传感器负责把物理量前置数字化MCU 负责把数字变成信息和决策。只要把硬件布局、总线抗干扰和状态机架构做好这套系统可以很轻松地扩展到更多探头、更多控制逻辑。如果你想继续往深处做我建议留一路备用 GPIO 接一个继电器或者蜂鸣器当本地和远程温差超过设定值时发出报警也可以再接一个外部 EEPROM把过去 24 小时的温度曲线记录下来方便后期排查故障。甚至可以把采集周期和滤波算法做成参数化配置通过串口命令在线调整这样固件不用经常动现场适配能力会强很多。温度监测看起来是小功能但把它做扎实了整个嵌入式设备的可靠性和可维护性都会跟着上一个台阶。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
