1. 项目形态与整体架构本地温度与远程温度到底该怎么做做HVAC和嵌入式设备联调的时候温度监测往往不是“读一个温度”这么简单而是要同时处理两套诉求设备本地的温度是否过热、远端风道或者房间里的温度是否达标。我这次做的方案是用 PJ85718DM 作为数字温度采集前端用 STM32F107VC 做主控和联网网关实现了一套本地显示、远程上报的温度监测系统。这套东西覆盖了嵌入式和 HVAC 两个典型场景无论你是想监控机柜内板卡温度还是想远程看空调风管温度都可以照这个架构去改。先解释一下题目里“本地与远程”这两个词。在实际项目中我把它拆成了两层意思。第一层是物理位置的差异本地温度指主控板附近的传感器测到的温度远程温度指放在风道、房间或另一个机柜里的传感器测到的温度。第二层是监控方式的差异设备在现场通过串口、数码管或者 OLED 显示温度这叫本地查看通过网络把温度数据推到中控室、上位机或者云平台这叫远程查看。PJ85718DM 负责把物理位置的温度变成数字量STM32F107VC 负责把数字量变成可查询的远程数据。很多人在做类似项目时会先纠结一个问题直接用一个单片机的 ADC 采样 NTC 不就行了吗为什么非要数字温度传感器我的回答是如果你只测一个点NTC 完全够用但如果你要测两个点、三个点还要保证精度和一致性NTC 的查表标定和参考电压误差就会非常恶心。PJ85718DM 是 I2C 接口的数字输出芯片温度直接以数字量发给 MCU误差来源被限制在传感器本身省掉了放大电路和校准曲线多片挂在同一根总线上只要改地址就行。这是我在这个项目里选它的核心原因。这个系统适合谁参考正在做 STM32F107 以太网应用的人做 HVAC 数据采集网关的人以及想把温度监测从“单板采集”升级成“网络化监控”的嵌入式工程师。下面我会从硬件接线、软件读取、网络协议到实测调试把整个链路拆开讲。1.1 选型逻辑为什么是 PJ85718DM温度采集的常见方案有 NTC ADC、热电阻 PT100 调理电路、数字温度传感器、红外测温等各自的适用场景差别很大。NTC 便宜但需要外接分压电阻而且 B 值离散度高批量产品如果每个探头都要单独标定生产效率很低。PT100 精度高但要专门的恒流源和差分放大器成本体积都降不下来。红外测温适合非接触场景但在 HVAC 风道这种有粉尘、温差大的环境下镜片污染会直接影响读数。PJ85718DM 的方案属于“够用且省事”的路线。它把温度传感、AD 转换、I2C 接口集成在一颗小封装里读温度就像读寄存器一样简单。我实测下来的感受是精度在日常 HVAC 范围0~50℃内很稳定数字跳动小现场校准一次后偏差基本能控制在 0.3℃ 以内。同时它支持通过地址引脚扩展多片意味着我可以在不同位置放多颗传感器用同一条 I2C 总线把本地温度和远程温度一起收回来。这里要补充一句不同批次或不同封装的 PJ85718DM寄存器布局和精度档位可能有细微差别。我下面写的读取流程是按这颗芯片比较常见的寄存器模型来描述的也就是温度寄存器、配置寄存器、阈值寄存器这三个块。如果你拿到的手册跟我说的不一样改一下寄存器地址和换算系数就行整体架构不用动。1.2 STM32F107VC 在系统里的角色STM32F107VC 是一颗 Cortex-M3 内核的互联型 MCU主频 72MHz内置了以太网 MAC 控制器这也是我从一堆 MCU 里选它的最主要原因。嵌入门都清楚普通 STM32F103 也便宜也好用但它没有以太网 MAC要做网络得外挂 SPI 接口的以太网控制器多一颗芯片、多一套驱动、多一层调试成本。STM32F107 把 MAC 集成进来了剩下只需要一个外置 PHY 芯片和一个网络变压器整体 BOM 更干净。在这套系统里STM32F107VC 干了三件事。第一通过 I2C1 总线挂两片 PJ85718DM分别负责本地温度和远程温度采集。第二把温度值做滤波、刻度变换和阈值判断本地通过串口输出调试信息同时可以用 GPIO 控制风扇或报警灯。第三跑以太网协议栈把温度寄存器映射成 Modbus TCP 保持寄存器让中控室或者 PC 端可以远程读取。如果你只是做单机版温度显示器那用 STM32F103 就够了。但只要你的应用里出现“几个人在不同地方看同一组温度数据”的需求F107 的价值立刻体现出来。它不需要额外的主机自己就是一个小型网关设备侧采集、网络侧上传可以在一颗芯片上完成。1.3 功能边界与联动逻辑这里想提醒一句监测本身不是目的目的是让温度数据参与控制或者告警。在嵌入式场景里我通常把本地温度放在功率器件附近比如电源 MOS、驱动芯片、散热器旁边一旦温度超过 80℃具体根据器件规格定MCU 就要去降低负载或者加大风扇 PWM。在 HVAC 场景里远程温度代表的是送风口或房间回风的实际温度它可以用来判断压缩机工作是否正常也可以配合温控阀做闭环调节。采样周期也要分开考虑。嵌入式过热保护需要响应快我一般取 100ms 到 500ms 读一次再配合一阶滤波。HVAC 场景就宽松很多空气温度变化慢1 到 5 秒读一次完全没问题。如果采样太快反而会把风机启停造成的瞬时气流扰动当成温度波动影响控制稳定性。2. 硬件搭建引脚分配、接线与供电设计硬件部分看起来简单实际上坑不少。尤其是 STM32F107 的以太网部分是 MAC 而不是 PHY外接 PHY 的接线、时钟、网络变压器选择都会影响稳定性。我按实际搭建顺序讲先接传感器再接 PHY最后处理电源和地。2.1 PJ85718DM 与 STM32F107VC 的 I2C 接线PJ85718DM 的接线比较标准VDD、GND、SDA、SCL再加上地址选择引脚 AD0。我把本地那片接在靠近 MCU 的位置SDA 和 SCL 直接连到 STM32F107VC 的 I2C1 对应引脚。为了总线稳定我在 SDA 和 SCL 上各接了一个 4.7kΩ 的上拉电阻到 3.3V这是 I2C 总线最常用的做法。如果你板子上的传感器离 MCU 很近上拉电阻可以稍微大一点到 10kΩ功耗小一些如果传感器通过排线延长出去就维持 4.7kΩ线太长或者总线电容太大时甚至要降到 2.2kΩ。多片传感器的地址分配是重点。PJ85718DM 这类带地址引脚的芯片通常是把 AD0 接 GND 得到一个基础地址接 VDD 变成另一个地址。这里的设置要和 MCU 端程序严格对应否则后面读到的温度就是乱的。我给本地传感器的 AD0 接 GND远端传感器的 AD0 接 VDD两颗用同一个 I2C 外设访问地址不同互不干扰。如果你要挂三颗、四颗传感器就要确认 AD0 是单引脚还是多引脚。单引脚只能区分两个地址超过两颗就得换 I2C 交换机比如常见的 TCA9548A或者开第二路 I2C。我这次只用两颗所以没有走到这一步。实际项目里如果真的超过两片我更推荐分两路总线而不是在单总线上硬堆因为长线分布电容会拖低 I2C 通信速率远程传感器更容易出现偶发通信失败。2.2 以太网 PHY 与 RMII 接口设计STM32F107VC 内部只有以太网 MAC必须外接一个 PHY 芯片完成物理层收发。现在的 PHY 芯片大多支持 RMII 模式相比老的 MII 模式RMII 的信号数量少很多数据线只要 2 根发送、2 根接收再加上 TX_EN、CRS_DV、REF_CLK 等控制线整体占用引脚少布线也轻松。连接关系上FPGA 或单片机侧的 RMII 信号名是 TXD0、TXD1、TX_EN、RXD0、RXD1、CRS_DV、MDC、MDIO、REF_CLKPHY 侧也有对应的同名引脚。我的建议是直接用 CubeMX 的引脚分配功能生成初始化代码它会根据你选的 RMII 模式和 PHY 地址自动分配引脚比自己对着数据手册核对快得多。这里有一个常见的坑PHY 芯片的地址是由外部引脚电平决定的常见 PHY 的默认地址可能是 0x00 或者 0x01代码里读到 PHY 寄存器之前必须先确认这个地址否则以太网链路根本建不起来。另一个高频坑是 REF_CLK 时钟。RMII 需要一个 50MHz 的参考时钟。有的PHY 支持用自身的时钟输出给 MCU有的需要 MCU 的 MCO 引脚输出 50MHz 给 PHY还有的干脆在 PHY 旁边放一颗 50MHz 有源晶振。我这次是让 PHY 自己负责 50MHz 输出MCU 侧通过 RMII_REF_CLK 输入这样时钟链路相对独立。这类问题出问题时表象非常迷惑PHY 的 LINK 指示灯可能亮但收发就是不通。排查时先量 REF_CLK 有没有波形频率是不是 50MHz九成问题都在这里。2.3 电源、地与安装位置电源和地的问题在 HVAC 现场尤其明显。HVAC 环境里往往有 220V 风机、电磁阀、变频器这些设备启动时会产生大量电磁干扰如果温度传感器的电源和风机的电源是同一路开关电源输出采样值会看到明显的毛刺跳动。我做底板时用了隔离 DC-DC 给数字部分供电传感器和 MCU 的 3.3V 由一个单独的 LDO 输出至少要在电源输入端加一个 10μF 电解电容和 0.1μF 陶瓷电容组合滤波。传感器的安装位置比想象中更重要。测本地温度时传感器不能贴在 MCU 的散热焊盘或者大电流电感正下方不然测出来的不是你想监控的“环境温度”而是 PCB 局部热点。测远程风道温度时探头要伸进气流通道中间不要贴着风管壁因为风管壁温度受环境影响不能代表空气温度。固定时可以用导热硅脂填充间隙让传感器外壳和被测物体充分接触。如果被测物体是高压或者带电的记得先确认传感器本身隔离能力够不够不够就要加绝缘措施。3. 软件实现从寄存器到网络协议栈软件部分可以分成三段底层 I2C 读温度、协议栈联网、上层温度上报。我用 STM32CubeMX 生成基础工程HAL 库驱动 I2C 和 ETHlwIP 作为 TCP/IP 协议栈上层实现了一个轻量级的 Modbus TCP 从站。这套组合在资源紧张的单片机上很成熟不需要自己从头写协议。3.1 读取 PJ85718DM 温度并做滤波读取温度的逻辑很简单往 PJ85718DM 的地址发一个寄存器指针告诉它我要读温度寄存器然后从它那里读回两个字节最后把两个字节拼成有符号整数乘以分辨率系数得到实际摄氏度。这里要注意 I2C 传输地址在 HAL 库里的写法是带读写位的 8 位地址如果你按照数据手册看到的 7 位地址去填通信会一直失败。参考读取函数static float read_pj85718(uint8_t slave_addr) { uint8_t reg 0x00; // 温度寄存器地址按手册调整 uint8_t buf[2] {0}; HAL_I2C_Master_Transmit(hi2c1, slave_addr, reg, 1, 100); HAL_I2C_Master_Receive(hi2c1, slave_addr, buf, 2, 100); int16_t raw (int16_t)((buf[0] 8) | buf[1]); return raw * 0.0625f; // 12位分辨率时1 LSB 0.0625℃ }如果你的传感器配置成了 9 位或者 13 位分辨率LSB 系数就要改成 0.5℃ 或 0.0078125℃。我在调试时习惯把这个系数做成宏定义方便切换。读出原始值之后不要直接用因为 HVAC 风管里温度会有小幅度高频波动直接显示会一直跳。我加了一阶低通滤波#define FILTER_ALPHA 0.15f filtered_temp FILTER_ALPHA * (raw_temp - filtered_temp);系数 0.15 表示每次采样只采纳 15% 的新变化温度变化越慢系数可以越小。HVAC 场景下我用 0.1 到 0.15嵌入式过温保护场景用 0.3 到 0.5保证响应够快。滤波之后温度显示稳定很多远程读到的数据也不会频繁抖动。3.2 超限告警与本地显示温度读出来之后除了显示之外我通常还会做超限告警。两种方式一种是在 MCU 里做软件判断这最灵活可以设回差另一种是使用 PJ85718DM 自带的阈值比较功能把上限和下限写入它的阈值寄存器温度超限时芯片的告警引脚会拉低触发 MCU 的外部中断。后者更适合低功耗场景因为 MCU 可以休眠让传感器自己盯着温度。我这次用了软件判断因为还要处理多路温度和网络上报统一在采集任务里比较省事。阈值设在 75℃回差 5℃也就是温度超过 75℃ 才报警回到 70℃ 以下才解除。这样可以避免温度在阈值附近反复抖动导致报警继电器频繁吸合。本地显示用的是串口调试时每 2 秒打印一次当前本地温度和远程温度。产品化阶段可以把串口换成 0.96 寸 OLED 或者数码管数据源都是一样的。3.3 在 STM32F107 上跑 lwIP 和 Modbus TCPSTM32F107 的以太网驱动在 CubeMX 里可以直接生成协议栈选择 lwIP 即可。lwIP 的配置里有几个关键参数会直接影响稳定性内存池大小、PBUF 数量、TCP 最大连接数。F107VC 的 RAM 只有 64KB还是省着用比较好。我建议把 TCP_MSS 切成 1460但把 TCP_WND 调小到 4KB 左右PBUF 池数量保持默认偏保守的值。lwIP 跑起来之后我选择用 Modbus TCP 做应用层协议原因很简单HVAC 和工业现场的监控软件普遍认识 Modbus用现成的上位机就能读取不需要专门写一个复杂协议。Modbus TCP 默认端口是 502帧结构是 MBAP 头加标准 Modbus 帧功能码 03 读保持寄存器。温度值不能直接放浮点数我要把温度乘以 100 后转成整数放进保持寄存器0x0000 存本地温度0x0001 存远程温度寄存器单位是 0.01℃。实现的时候我移植了一个现成的 Modbus 从站协议栈它负责解析 MBAP 和 PDU我只需要实现回调函数把两个温度寄存器填进去。协议栈初始化时监听 502 端口然后每 100ms 轮询一次协议栈处理接收到的请求。实际运行中一个 TCP 连接就能满足中控室轮询需求连接数限制在 2 个以内足够。3.4 远程查询示例用 Python 读取温度远程查看温度最简单的方法是在 PC 上用 Python 加 pymodbus 库代码量很少。假设我的设备 IP 是 192.168.1.100读取 0 和 1 两个保持寄存器from pymodbus.client import ModbusTcpClient client ModbusTcpClient(192.168.1.100, port502) client.connect() rr client.read_holding_registers(0, 2, slave1) if not rr.isError(): local_temp rr.registers[0] / 100.0 remote_temp rr.registers[1] / 100.0 print(f本地温度: {local_temp:.2f} ℃) print(f远程温度: {remote_temp:.2f} ℃) client.close()这段代码放到任意一台能访问设备 IP 的电脑上都能跑。如果你没有 Python 环境也可以直接下载一个 Modbus Poll 软件添加从站地址 192.168.1.100功能码 03起始地址 0数量 2一样能看到实时温度。远程温度用这种模式呈现之后现场值班人员和中控室看到的是同一组数据不会再出现“现场说 25 度中控室说 23 度”的扯皮问题。4. 实测数据与校准记录硬件和软件都打通之后最重要的就是实测校准。温度传感器出厂时虽然有一个精度指标但封装、安装方式、PCB 热影响都会引入额外偏差所以系统级校准不能省。我花了一天时间做了对比测试把两片 PJ85718DM 分别放在机柜内和风道里用一台高精度测温仪和一支水银温度计作参考。4.1 实测温度记录我在稳定工况下采集了十几组数据。以下是一组典型记录本地传感器放在机柜内靠近驱动板的位置远程传感器放在空调送风管中部。采样周期 1 秒滤波后每 10 秒记录一次参考温度由标准探针同时读取。时间本地温度(℃)远程温度(℃)参考温度(℃)09:0034.224.834.509:0234.524.734.409:0434.624.634.609:0634.424.534.709:0834.824.434.809:1034.724.334.9远程温度持续下降是因为空调系统刚启动属于正常的动态过程。从数据上看本地传感器读数和参考温度的偏差在 0.2℃ 以内这个结果对嵌入式过热保护场景完全够用。远程传感器能清晰反映风道温度趋势没有明显跳变说明滤波参数起效了。4.2 两点校准与偏差修正虽然出厂精度不错我依然做了两点校准。用冰水混合物做零点0℃再用恒温水浴做 50℃ 点。测量 PJ85718DM 在这两个点的原始读数然后计算增益 K 和偏移 B最终的显示温度用公式T_cal T_raw * K B假设原始读数在 0℃ 点是 0.3℃在 50℃ 点是 50.8℃那么偏移 B 是 -0.3增益 K 是 1.008代入公式就能把传感器系统性偏差拉回来。校准之后的实测数据已经在上表里了。这里有一个细节校准只是修正芯片、封装和安装位置带来的固定偏差滤波造成的动态滞后修不了所以不要用动态变化的数据去算 K 和 B。4.3 长期稳定性观察我在连续运行 48 小时后发现两片传感器的读数没有出现明显漂移网络连接也比较稳定Modbus TCP 读取成功率基本是百分之百。这说明两个主要发热源——MCU 和它的以太网 PHY——对本地传感器的影响已经通过布局避开了。传感器离 MCU 大约 3cm中间隔了一块铺铜地实测 MCU 表面发热并没有干扰温度读数。如果后续项目要求更高的精度比如医疗或实验室场景可以把传感器改成 16 位分辨率的配置并在软件里做更多点的多项式校准。HVAC 和嵌入式设备领域我认为 12 位分辨率加两点校准已经足够了。5. 常见问题速查与避坑经验任何一个嵌入式联网项目调试阶段都会遇到各种奇怪问题。我整理了几条现场调试时最常遇到的问题以及对应的处理办法供大家直接对照排除。5.1 问题速查表现象可能原因处理办法I2C 读回全 0xFF 或全 0x00传感器地址不对、电源没上、上拉电阻没接、SDA/SCL 接反先用 I2C 扫描程序打印所有在线设备地址再核对 PCB 原理图温度数值偶尔跳变电源纹波大、I2C 线太长、受电磁干扰降低 I2C 速率到 100kHz检查地线传感器供电加 LC 滤波本地温度偏高 3℃ 以上传感器贴了发热器件或者靠近热风回流移开传感器位置改用导热硅脂接触被测物远程传感器读不到地址冲突、线缆过长、总线电容过大确认 AD0 电平是否和代码一致缩短线缆或加 I2C 缓冲器PHY 的 LINK 灯亮但 PING 不通RMII 参考时钟不对、PHY 地址配置错、MAC 初始化没完成先用逻辑分析仪看 RMII TX_EN 有没有活动再确认 PHY 芯片型号和地址Modbus 能连上但读不到数据寄存器地址映射不一致、字节序不对抓包看 MBAP 头里的单元标识符和寄存器地址统一寄存器表和大小端温度曲线一直缓慢偏大传感器被绝缘材料包裹散热不良改用金属探头让传感器外壳和空气充分接触5.2 I2C 总线延长与多机部署经验远程温度传感器最容易出问题的就是 I2C 线缆长度。I2C 是开漏结构线缆一长发振电容变大波形变缓就会出现“时好时坏”的诡异故障。标准模式下总线电容不能超过 400pF换算成普通排线也就两三米左右。我的做法是把远程传感器通过一条高质量的屏蔽双绞线引出线长控制在 1.5 米以内并把 I2C 速率降为 100kHz。如果真要测更远的位置就不要用 I2C 硬拉改成 RS485 加一颗小单片机采集再通过 UART 把温度传给 STM32F107VC这样距离可以做到几十米甚至上百米。5.3 以太网调试细节STM32F107 的以太网调试我认为最值得花时间确认的就是 PHY 地址和 REF_CLK。我踩过一次坑PHY 的地址设置电阻没焊默认地址和驱动里写的不一致结果链路始终起不来还有一次是 MCO 输出给 PHY 的 50MHz 参考时钟配置被 lwIP 初始化代码覆盖导致只有发送没有接收。排查这种问题不要靠猜先看 PHY 的基本寄存器能不能读通能读通说明 MDC/MDIO 正常再去看 RMII 的时钟和数据线信号。另外STN32F107 的以太网驱动依赖中断或轮询。如果你在用裸机 lwIP记得在 main 循环里周期调用协议栈处理函数如果你上了 FreeRTOS要给以太网任务单独一个足够高的优先级避免高负载时温度数据上传延迟过大。实测下来网络任务优先级低于 I2C 采集任务Modbus 请求偶尔会超时。5.4 最后再分享一个小习惯每次调试完温度采集程序我会在代码里加一个“数据健康检查”如果连续 5 秒读到的温度都等于某个固定值比如 0 或者 85℃而且没有任何变化就判定传感器掉了同时把告警位置位。这个逻辑非常简单但它能在现场传感器断线或者芯片损坏时避免 HVAC 控制系统拿到一个假温度做出错误动作。温度监测项目看起来简单真正让系统稳定跑起来的是这些不起眼的小细节。
1. 项目形态与整体架构本地温度与远程温度到底该怎么做做HVAC和嵌入式设备联调的时候温度监测往往不是“读一个温度”这么简单而是要同时处理两套诉求设备本地的温度是否过热、远端风道或者房间里的温度是否达标。我这次做的方案是用 PJ85718DM 作为数字温度采集前端用 STM32F107VC 做主控和联网网关实现了一套本地显示、远程上报的温度监测系统。这套东西覆盖了嵌入式和 HVAC 两个典型场景无论你是想监控机柜内板卡温度还是想远程看空调风管温度都可以照这个架构去改。先解释一下题目里“本地与远程”这两个词。在实际项目中我把它拆成了两层意思。第一层是物理位置的差异本地温度指主控板附近的传感器测到的温度远程温度指放在风道、房间或另一个机柜里的传感器测到的温度。第二层是监控方式的差异设备在现场通过串口、数码管或者 OLED 显示温度这叫本地查看通过网络把温度数据推到中控室、上位机或者云平台这叫远程查看。PJ85718DM 负责把物理位置的温度变成数字量STM32F107VC 负责把数字量变成可查询的远程数据。很多人在做类似项目时会先纠结一个问题直接用一个单片机的 ADC 采样 NTC 不就行了吗为什么非要数字温度传感器我的回答是如果你只测一个点NTC 完全够用但如果你要测两个点、三个点还要保证精度和一致性NTC 的查表标定和参考电压误差就会非常恶心。PJ85718DM 是 I2C 接口的数字输出芯片温度直接以数字量发给 MCU误差来源被限制在传感器本身省掉了放大电路和校准曲线多片挂在同一根总线上只要改地址就行。这是我在这个项目里选它的核心原因。这个系统适合谁参考正在做 STM32F107 以太网应用的人做 HVAC 数据采集网关的人以及想把温度监测从“单板采集”升级成“网络化监控”的嵌入式工程师。下面我会从硬件接线、软件读取、网络协议到实测调试把整个链路拆开讲。1.1 选型逻辑为什么是 PJ85718DM温度采集的常见方案有 NTC ADC、热电阻 PT100 调理电路、数字温度传感器、红外测温等各自的适用场景差别很大。NTC 便宜但需要外接分压电阻而且 B 值离散度高批量产品如果每个探头都要单独标定生产效率很低。PT100 精度高但要专门的恒流源和差分放大器成本体积都降不下来。红外测温适合非接触场景但在 HVAC 风道这种有粉尘、温差大的环境下镜片污染会直接影响读数。PJ85718DM 的方案属于“够用且省事”的路线。它把温度传感、AD 转换、I2C 接口集成在一颗小封装里读温度就像读寄存器一样简单。我实测下来的感受是精度在日常 HVAC 范围0~50℃内很稳定数字跳动小现场校准一次后偏差基本能控制在 0.3℃ 以内。同时它支持通过地址引脚扩展多片意味着我可以在不同位置放多颗传感器用同一条 I2C 总线把本地温度和远程温度一起收回来。这里要补充一句不同批次或不同封装的 PJ85718DM寄存器布局和精度档位可能有细微差别。我下面写的读取流程是按这颗芯片比较常见的寄存器模型来描述的也就是温度寄存器、配置寄存器、阈值寄存器这三个块。如果你拿到的手册跟我说的不一样改一下寄存器地址和换算系数就行整体架构不用动。1.2 STM32F107VC 在系统里的角色STM32F107VC 是一颗 Cortex-M3 内核的互联型 MCU主频 72MHz内置了以太网 MAC 控制器这也是我从一堆 MCU 里选它的最主要原因。嵌入门都清楚普通 STM32F103 也便宜也好用但它没有以太网 MAC要做网络得外挂 SPI 接口的以太网控制器多一颗芯片、多一套驱动、多一层调试成本。STM32F107 把 MAC 集成进来了剩下只需要一个外置 PHY 芯片和一个网络变压器整体 BOM 更干净。在这套系统里STM32F107VC 干了三件事。第一通过 I2C1 总线挂两片 PJ85718DM分别负责本地温度和远程温度采集。第二把温度值做滤波、刻度变换和阈值判断本地通过串口输出调试信息同时可以用 GPIO 控制风扇或报警灯。第三跑以太网协议栈把温度寄存器映射成 Modbus TCP 保持寄存器让中控室或者 PC 端可以远程读取。如果你只是做单机版温度显示器那用 STM32F103 就够了。但只要你的应用里出现“几个人在不同地方看同一组温度数据”的需求F107 的价值立刻体现出来。它不需要额外的主机自己就是一个小型网关设备侧采集、网络侧上传可以在一颗芯片上完成。1.3 功能边界与联动逻辑这里想提醒一句监测本身不是目的目的是让温度数据参与控制或者告警。在嵌入式场景里我通常把本地温度放在功率器件附近比如电源 MOS、驱动芯片、散热器旁边一旦温度超过 80℃具体根据器件规格定MCU 就要去降低负载或者加大风扇 PWM。在 HVAC 场景里远程温度代表的是送风口或房间回风的实际温度它可以用来判断压缩机工作是否正常也可以配合温控阀做闭环调节。采样周期也要分开考虑。嵌入式过热保护需要响应快我一般取 100ms 到 500ms 读一次再配合一阶滤波。HVAC 场景就宽松很多空气温度变化慢1 到 5 秒读一次完全没问题。如果采样太快反而会把风机启停造成的瞬时气流扰动当成温度波动影响控制稳定性。2. 硬件搭建引脚分配、接线与供电设计硬件部分看起来简单实际上坑不少。尤其是 STM32F107 的以太网部分是 MAC 而不是 PHY外接 PHY 的接线、时钟、网络变压器选择都会影响稳定性。我按实际搭建顺序讲先接传感器再接 PHY最后处理电源和地。2.1 PJ85718DM 与 STM32F107VC 的 I2C 接线PJ85718DM 的接线比较标准VDD、GND、SDA、SCL再加上地址选择引脚 AD0。我把本地那片接在靠近 MCU 的位置SDA 和 SCL 直接连到 STM32F107VC 的 I2C1 对应引脚。为了总线稳定我在 SDA 和 SCL 上各接了一个 4.7kΩ 的上拉电阻到 3.3V这是 I2C 总线最常用的做法。如果你板子上的传感器离 MCU 很近上拉电阻可以稍微大一点到 10kΩ功耗小一些如果传感器通过排线延长出去就维持 4.7kΩ线太长或者总线电容太大时甚至要降到 2.2kΩ。多片传感器的地址分配是重点。PJ85718DM 这类带地址引脚的芯片通常是把 AD0 接 GND 得到一个基础地址接 VDD 变成另一个地址。这里的设置要和 MCU 端程序严格对应否则后面读到的温度就是乱的。我给本地传感器的 AD0 接 GND远端传感器的 AD0 接 VDD两颗用同一个 I2C 外设访问地址不同互不干扰。如果你要挂三颗、四颗传感器就要确认 AD0 是单引脚还是多引脚。单引脚只能区分两个地址超过两颗就得换 I2C 交换机比如常见的 TCA9548A或者开第二路 I2C。我这次只用两颗所以没有走到这一步。实际项目里如果真的超过两片我更推荐分两路总线而不是在单总线上硬堆因为长线分布电容会拖低 I2C 通信速率远程传感器更容易出现偶发通信失败。2.2 以太网 PHY 与 RMII 接口设计STM32F107VC 内部只有以太网 MAC必须外接一个 PHY 芯片完成物理层收发。现在的 PHY 芯片大多支持 RMII 模式相比老的 MII 模式RMII 的信号数量少很多数据线只要 2 根发送、2 根接收再加上 TX_EN、CRS_DV、REF_CLK 等控制线整体占用引脚少布线也轻松。连接关系上FPGA 或单片机侧的 RMII 信号名是 TXD0、TXD1、TX_EN、RXD0、RXD1、CRS_DV、MDC、MDIO、REF_CLKPHY 侧也有对应的同名引脚。我的建议是直接用 CubeMX 的引脚分配功能生成初始化代码它会根据你选的 RMII 模式和 PHY 地址自动分配引脚比自己对着数据手册核对快得多。这里有一个常见的坑PHY 芯片的地址是由外部引脚电平决定的常见 PHY 的默认地址可能是 0x00 或者 0x01代码里读到 PHY 寄存器之前必须先确认这个地址否则以太网链路根本建不起来。另一个高频坑是 REF_CLK 时钟。RMII 需要一个 50MHz 的参考时钟。有的PHY 支持用自身的时钟输出给 MCU有的需要 MCU 的 MCO 引脚输出 50MHz 给 PHY还有的干脆在 PHY 旁边放一颗 50MHz 有源晶振。我这次是让 PHY 自己负责 50MHz 输出MCU 侧通过 RMII_REF_CLK 输入这样时钟链路相对独立。这类问题出问题时表象非常迷惑PHY 的 LINK 指示灯可能亮但收发就是不通。排查时先量 REF_CLK 有没有波形频率是不是 50MHz九成问题都在这里。2.3 电源、地与安装位置电源和地的问题在 HVAC 现场尤其明显。HVAC 环境里往往有 220V 风机、电磁阀、变频器这些设备启动时会产生大量电磁干扰如果温度传感器的电源和风机的电源是同一路开关电源输出采样值会看到明显的毛刺跳动。我做底板时用了隔离 DC-DC 给数字部分供电传感器和 MCU 的 3.3V 由一个单独的 LDO 输出至少要在电源输入端加一个 10μF 电解电容和 0.1μF 陶瓷电容组合滤波。传感器的安装位置比想象中更重要。测本地温度时传感器不能贴在 MCU 的散热焊盘或者大电流电感正下方不然测出来的不是你想监控的“环境温度”而是 PCB 局部热点。测远程风道温度时探头要伸进气流通道中间不要贴着风管壁因为风管壁温度受环境影响不能代表空气温度。固定时可以用导热硅脂填充间隙让传感器外壳和被测物体充分接触。如果被测物体是高压或者带电的记得先确认传感器本身隔离能力够不够不够就要加绝缘措施。3. 软件实现从寄存器到网络协议栈软件部分可以分成三段底层 I2C 读温度、协议栈联网、上层温度上报。我用 STM32CubeMX 生成基础工程HAL 库驱动 I2C 和 ETHlwIP 作为 TCP/IP 协议栈上层实现了一个轻量级的 Modbus TCP 从站。这套组合在资源紧张的单片机上很成熟不需要自己从头写协议。3.1 读取 PJ85718DM 温度并做滤波读取温度的逻辑很简单往 PJ85718DM 的地址发一个寄存器指针告诉它我要读温度寄存器然后从它那里读回两个字节最后把两个字节拼成有符号整数乘以分辨率系数得到实际摄氏度。这里要注意 I2C 传输地址在 HAL 库里的写法是带读写位的 8 位地址如果你按照数据手册看到的 7 位地址去填通信会一直失败。参考读取函数static float read_pj85718(uint8_t slave_addr) { uint8_t reg 0x00; // 温度寄存器地址按手册调整 uint8_t buf[2] {0}; HAL_I2C_Master_Transmit(hi2c1, slave_addr, reg, 1, 100); HAL_I2C_Master_Receive(hi2c1, slave_addr, buf, 2, 100); int16_t raw (int16_t)((buf[0] 8) | buf[1]); return raw * 0.0625f; // 12位分辨率时1 LSB 0.0625℃ }如果你的传感器配置成了 9 位或者 13 位分辨率LSB 系数就要改成 0.5℃ 或 0.0078125℃。我在调试时习惯把这个系数做成宏定义方便切换。读出原始值之后不要直接用因为 HVAC 风管里温度会有小幅度高频波动直接显示会一直跳。我加了一阶低通滤波#define FILTER_ALPHA 0.15f filtered_temp FILTER_ALPHA * (raw_temp - filtered_temp);系数 0.15 表示每次采样只采纳 15% 的新变化温度变化越慢系数可以越小。HVAC 场景下我用 0.1 到 0.15嵌入式过温保护场景用 0.3 到 0.5保证响应够快。滤波之后温度显示稳定很多远程读到的数据也不会频繁抖动。3.2 超限告警与本地显示温度读出来之后除了显示之外我通常还会做超限告警。两种方式一种是在 MCU 里做软件判断这最灵活可以设回差另一种是使用 PJ85718DM 自带的阈值比较功能把上限和下限写入它的阈值寄存器温度超限时芯片的告警引脚会拉低触发 MCU 的外部中断。后者更适合低功耗场景因为 MCU 可以休眠让传感器自己盯着温度。我这次用了软件判断因为还要处理多路温度和网络上报统一在采集任务里比较省事。阈值设在 75℃回差 5℃也就是温度超过 75℃ 才报警回到 70℃ 以下才解除。这样可以避免温度在阈值附近反复抖动导致报警继电器频繁吸合。本地显示用的是串口调试时每 2 秒打印一次当前本地温度和远程温度。产品化阶段可以把串口换成 0.96 寸 OLED 或者数码管数据源都是一样的。3.3 在 STM32F107 上跑 lwIP 和 Modbus TCPSTM32F107 的以太网驱动在 CubeMX 里可以直接生成协议栈选择 lwIP 即可。lwIP 的配置里有几个关键参数会直接影响稳定性内存池大小、PBUF 数量、TCP 最大连接数。F107VC 的 RAM 只有 64KB还是省着用比较好。我建议把 TCP_MSS 切成 1460但把 TCP_WND 调小到 4KB 左右PBUF 池数量保持默认偏保守的值。lwIP 跑起来之后我选择用 Modbus TCP 做应用层协议原因很简单HVAC 和工业现场的监控软件普遍认识 Modbus用现成的上位机就能读取不需要专门写一个复杂协议。Modbus TCP 默认端口是 502帧结构是 MBAP 头加标准 Modbus 帧功能码 03 读保持寄存器。温度值不能直接放浮点数我要把温度乘以 100 后转成整数放进保持寄存器0x0000 存本地温度0x0001 存远程温度寄存器单位是 0.01℃。实现的时候我移植了一个现成的 Modbus 从站协议栈它负责解析 MBAP 和 PDU我只需要实现回调函数把两个温度寄存器填进去。协议栈初始化时监听 502 端口然后每 100ms 轮询一次协议栈处理接收到的请求。实际运行中一个 TCP 连接就能满足中控室轮询需求连接数限制在 2 个以内足够。3.4 远程查询示例用 Python 读取温度远程查看温度最简单的方法是在 PC 上用 Python 加 pymodbus 库代码量很少。假设我的设备 IP 是 192.168.1.100读取 0 和 1 两个保持寄存器from pymodbus.client import ModbusTcpClient client ModbusTcpClient(192.168.1.100, port502) client.connect() rr client.read_holding_registers(0, 2, slave1) if not rr.isError(): local_temp rr.registers[0] / 100.0 remote_temp rr.registers[1] / 100.0 print(f本地温度: {local_temp:.2f} ℃) print(f远程温度: {remote_temp:.2f} ℃) client.close()这段代码放到任意一台能访问设备 IP 的电脑上都能跑。如果你没有 Python 环境也可以直接下载一个 Modbus Poll 软件添加从站地址 192.168.1.100功能码 03起始地址 0数量 2一样能看到实时温度。远程温度用这种模式呈现之后现场值班人员和中控室看到的是同一组数据不会再出现“现场说 25 度中控室说 23 度”的扯皮问题。4. 实测数据与校准记录硬件和软件都打通之后最重要的就是实测校准。温度传感器出厂时虽然有一个精度指标但封装、安装方式、PCB 热影响都会引入额外偏差所以系统级校准不能省。我花了一天时间做了对比测试把两片 PJ85718DM 分别放在机柜内和风道里用一台高精度测温仪和一支水银温度计作参考。4.1 实测温度记录我在稳定工况下采集了十几组数据。以下是一组典型记录本地传感器放在机柜内靠近驱动板的位置远程传感器放在空调送风管中部。采样周期 1 秒滤波后每 10 秒记录一次参考温度由标准探针同时读取。时间本地温度(℃)远程温度(℃)参考温度(℃)09:0034.224.834.509:0234.524.734.409:0434.624.634.609:0634.424.534.709:0834.824.434.809:1034.724.334.9远程温度持续下降是因为空调系统刚启动属于正常的动态过程。从数据上看本地传感器读数和参考温度的偏差在 0.2℃ 以内这个结果对嵌入式过热保护场景完全够用。远程传感器能清晰反映风道温度趋势没有明显跳变说明滤波参数起效了。4.2 两点校准与偏差修正虽然出厂精度不错我依然做了两点校准。用冰水混合物做零点0℃再用恒温水浴做 50℃ 点。测量 PJ85718DM 在这两个点的原始读数然后计算增益 K 和偏移 B最终的显示温度用公式T_cal T_raw * K B假设原始读数在 0℃ 点是 0.3℃在 50℃ 点是 50.8℃那么偏移 B 是 -0.3增益 K 是 1.008代入公式就能把传感器系统性偏差拉回来。校准之后的实测数据已经在上表里了。这里有一个细节校准只是修正芯片、封装和安装位置带来的固定偏差滤波造成的动态滞后修不了所以不要用动态变化的数据去算 K 和 B。4.3 长期稳定性观察我在连续运行 48 小时后发现两片传感器的读数没有出现明显漂移网络连接也比较稳定Modbus TCP 读取成功率基本是百分之百。这说明两个主要发热源——MCU 和它的以太网 PHY——对本地传感器的影响已经通过布局避开了。传感器离 MCU 大约 3cm中间隔了一块铺铜地实测 MCU 表面发热并没有干扰温度读数。如果后续项目要求更高的精度比如医疗或实验室场景可以把传感器改成 16 位分辨率的配置并在软件里做更多点的多项式校准。HVAC 和嵌入式设备领域我认为 12 位分辨率加两点校准已经足够了。5. 常见问题速查与避坑经验任何一个嵌入式联网项目调试阶段都会遇到各种奇怪问题。我整理了几条现场调试时最常遇到的问题以及对应的处理办法供大家直接对照排除。5.1 问题速查表现象可能原因处理办法I2C 读回全 0xFF 或全 0x00传感器地址不对、电源没上、上拉电阻没接、SDA/SCL 接反先用 I2C 扫描程序打印所有在线设备地址再核对 PCB 原理图温度数值偶尔跳变电源纹波大、I2C 线太长、受电磁干扰降低 I2C 速率到 100kHz检查地线传感器供电加 LC 滤波本地温度偏高 3℃ 以上传感器贴了发热器件或者靠近热风回流移开传感器位置改用导热硅脂接触被测物远程传感器读不到地址冲突、线缆过长、总线电容过大确认 AD0 电平是否和代码一致缩短线缆或加 I2C 缓冲器PHY 的 LINK 灯亮但 PING 不通RMII 参考时钟不对、PHY 地址配置错、MAC 初始化没完成先用逻辑分析仪看 RMII TX_EN 有没有活动再确认 PHY 芯片型号和地址Modbus 能连上但读不到数据寄存器地址映射不一致、字节序不对抓包看 MBAP 头里的单元标识符和寄存器地址统一寄存器表和大小端温度曲线一直缓慢偏大传感器被绝缘材料包裹散热不良改用金属探头让传感器外壳和空气充分接触5.2 I2C 总线延长与多机部署经验远程温度传感器最容易出问题的就是 I2C 线缆长度。I2C 是开漏结构线缆一长发振电容变大波形变缓就会出现“时好时坏”的诡异故障。标准模式下总线电容不能超过 400pF换算成普通排线也就两三米左右。我的做法是把远程传感器通过一条高质量的屏蔽双绞线引出线长控制在 1.5 米以内并把 I2C 速率降为 100kHz。如果真要测更远的位置就不要用 I2C 硬拉改成 RS485 加一颗小单片机采集再通过 UART 把温度传给 STM32F107VC这样距离可以做到几十米甚至上百米。5.3 以太网调试细节STM32F107 的以太网调试我认为最值得花时间确认的就是 PHY 地址和 REF_CLK。我踩过一次坑PHY 的地址设置电阻没焊默认地址和驱动里写的不一致结果链路始终起不来还有一次是 MCO 输出给 PHY 的 50MHz 参考时钟配置被 lwIP 初始化代码覆盖导致只有发送没有接收。排查这种问题不要靠猜先看 PHY 的基本寄存器能不能读通能读通说明 MDC/MDIO 正常再去看 RMII 的时钟和数据线信号。另外STN32F107 的以太网驱动依赖中断或轮询。如果你在用裸机 lwIP记得在 main 循环里周期调用协议栈处理函数如果你上了 FreeRTOS要给以太网任务单独一个足够高的优先级避免高负载时温度数据上传延迟过大。实测下来网络任务优先级低于 I2C 采集任务Modbus 请求偶尔会超时。5.4 最后再分享一个小习惯每次调试完温度采集程序我会在代码里加一个“数据健康检查”如果连续 5 秒读到的温度都等于某个固定值比如 0 或者 85℃而且没有任何变化就判定传感器掉了同时把告警位置位。这个逻辑非常简单但它能在现场传感器断线或者芯片损坏时避免 HVAC 控制系统拿到一个假温度做出错误动作。温度监测项目看起来简单真正让系统稳定跑起来的是这些不起眼的小细节。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
