企业官网建设流程全解析

这两年经手过不少暖通空调的监控板子，最头疼的往往不是控制逻辑，而是温度怎么采、怎么送出去。一块PJ85718DM数字温度传感器，加一颗TM4C129XNCZAD网络MCU，基本能把“本地温度采集+远程温度上报”这条路走通：传感器在设备端直接出数字量，主控既做本地逻辑，也通过以太网把温度推到上位机或者云端。这篇文章就写我把这套组合从选型、读数、联网到现场排错的全过程，适合正在做嵌入式温控、HVAC监控、楼宇自控的朋友参考。

这里说的“远程温度”，在实际工程里通常有两种理解：一是把远端风道或者房间里的温度探头送回主控，二是把现场测好的温度发到远程监控中心。这套方案两种场景都能覆盖，核心还是先把本地读数做扎实，再把以太网通道做稳。

1. 从HVAC现场的测温痛点，看PJ85718DM和TM4C129XNCZAD各自该干什么

1.1 这块板子在整个空调监控方案里的位置

先还原一下典型的HVAC监控现场。一套新风机组通常要看送风温度、回风温度，复杂点还要看冷冻水管供/回水温度，机房里还要看环境温度。这些测点分布在几十米范围内，过去最常见做法是PT100铂电阻配上模拟量采集模块，再用RS485总线拉回中控室。这种方案能用，但安装和调试成本高得离谱：每路传感器要配变送器、要校对线序、要处理模拟量漂移，出问题还不好查。

换成PJ85718DM加TM4C129XNCZAD这套组合后，架构一下简单了。PJ85718DM是末端温度感知器件，负责把真实的物理温度转成数字量；TM4C129XNCZAD是中间主控，负责轮询传感器、做温度补偿和控制逻辑，再通过自带的以太网接口把数据往外送。主控到上位机之间走网络，省掉了一层RS485转以太网的网关，整个链路从“传感器-变送器-采集模块-网关-上位机”缩短成“传感器-主控-上位机”。

选这颗主控还有个容易忽略的好处：它带浮点单元，跑PID或者温度线性化换算的时候不用自己写定标小数运算，代码写起来省力很多。固件里一般拆成三个任务：采集任务专门读PJ85718DM，协议任务负责TCP或MQTT发送，控制任务按PID周期输出阀门调节量。三个任务各管各的，后期加功能不会牵一发动全身。

1.2 为什么选数字传感器而不是NTC或PT100

做测温选型时，很多工程师第一反应是NTC，便宜、到处能买到。但NTC有个绕不开的问题：它只是一颗随温度变化的电阻，要变成温度数字，板子上得配精密基准、分压电阻、运放跟随，再塞进MCU的ADC通道。每路ADC的电源噪声、参考电压温度漂移、分压电阻温漂都会叠加进去，最后成品精度可能比标称的分辨率差一大截。

PT100精度好，但电路更麻烦，三线制四线制都得用恒流源或高精度仪表放大器，一套调理电路比传感器本身贵好几倍。HVAC这种行业，温度范围也就是-20℃到100℃左右，精度要求通常±1℃足够，用PT100属于杀鸡用牛刀。

我把三种方案对比列在下面，方便做选型时对照：

数字传感器的短板也很明显：I2C总线不适合拉太长，传感器本身也比NTC贵。但HVAC里大多数测点离主控不远，走线长度在几米以内，用数字方案的收益远大于成本，所以PJ85718DM这类芯片在这个场景里非常合适。

1.3 为什么要把以太网控制器集成选在MCU里

以前给设备加网络功能，惯用路线是主控MCU外面挂一颗SPI接口的以太网控制器，再加PHY芯片、网络变压器和RJ45座。这样做最大的问题是从设备多、驱动复杂，SPI吞吐量也受限制。TM4C129XNCZAD直接把MAC和PHY都做进MCU里了，板子上只需要一颗网络变压器加RJ45就能把网口跑起来，BOM物料少了，layout面积也小了。

100M以太网对温度上报这种小数据量来说带宽完全剩余，但这颗芯片真正的价值不是速度，而是让设备以标准网络身份接入局域网。上位机不管是写TCP客户端还是订阅MQTT主题，都能直接拿到温度数据，不需要再上一套协议转换器。硬件上省掉的中继设备少了，故障点自然就少了。

要补一句的是，集成PHY带来的封装压力也不小。BGA封装对PCB打样和小批量焊接都不太友好，引脚密、电源引脚多，画板时必须按参考设计布置去耦电容，否则网络部分容易出现怪问题。这一点在后面的调试部分会专门讲。

2. 本地温度采集侧的寄存器配置与一整套读数流程

2.1 PJ85718DM的I2C读写框架

本地温度采集是整个系统里最基础也最不能出错的环节。PJ85718DM用的是标准I2C接口，器件地址一般通过芯片的地址引脚配置，我这边固定在基地址0x48上。读取过程很简单：先发送一个字节的寄存器指针，然后做一次重复起始信号，再连续读两个字节的温度数据。每一步都必须确认ACK，如果某一步总线从机没应答，一定要按错误处理，不能继续往下走。

实际电路里，I2C上拉电阻是第一个坑。标准模式100kHz速率下，用4.7kΩ上拉基本没问题，但如果传感器线束比较长，总线电容变大，4.7kΩ会让上升沿变得很慢，数据就容易出错。我后来在处理长距离走线时把上拉降到了2.2kΩ，同时把SCL速率从400kHz降回100kHz，问题明显改善。凡是传感器离主控板超过30厘米的应用，建议直接按100kHz设计。

下面这段是我常用的读取函数框架，写得很直白，方便按项目裁剪：

#define PJ85718DM_ADDR 0x48 #define PJ85718DM_REG_TEMP 0x00 static int pj85718dm_read_temperature(float *temp_c) { uint8_t reg = PJ85718DM_REG_TEMP; uint8_t buf[2]; if (i2c_write(PJ85718DM_ADDR, &reg, 1) != 0) return -1; /* 写寄存器指针失败 */ if (i2c_read(PJ85718DM_ADDR, buf, 2) != 0) return -1; /* 读温度数据失败 */ int16_t raw = (int16_t)((buf[0] << 8) | buf[1]); *temp_c = (float)raw * 0.0078125f; /* 按16位温度数据换算 */ return 0; }

2.2 温度原始码如何换算成摄氏度

数字温度传感器的输出通常是一串补码形式的原始ADC值。以我用的PJ85718DM为例，数据手册上标明温度寄存器是16位，最低有效位LSB对应的温度分辨率是0.0078125℃。这个数值是怎么来的呢？16位数据最高位是符号位，正温度范围下满量程对应约32767×0.0078125，也就是256℃左右，覆盖HVAC需求绰绰有余。

换算本身很简单：把两个字节拼成一个16位有符号整数，再乘上LSB对应的温度值，就是摄氏度。温度为零下时也不需要特殊处理，用有符号整数直接计算，C语言里用int16_t类型自然处理补码。

部分传感器默认输出的是14位有效数据，温度寄存器读取后需要先右移两位再换算，移位操作千万别漏。我一般会在上电自检时读取一下ID寄存器或状态寄存器，确认传感器通信正常，再进入正常读取循环。

HVAC的温度变化很慢，1秒钟读一次足够。采集任务里把每次读到的原始值放进一个长度为8的滑动窗口，窗口填满后取平均，作为控制逻辑使用的最终温度。这样既能把随机噪声抹掉，又不会引入太多延迟。

2.3 传感器误差的两点校准与滤波处理

数字传感器出厂时精度不错，但现场安装位置五花八门，有的贴在金属风管上，有的放在阳光直射的窗边，误差会变大。我每次装完都会做一次两点校准：用一支经过标定的精密温度计，和传感器探头放在同一个热平衡环境里，记录两组温度点，然后用线性校正把实际曲线拉直。

校准公式可以写成：

T_cal = (T_raw - T1_raw) / (T2_raw - T1_raw) × (T2_ref - T1_ref) + T1_ref

T1_raw和T2_raw是传感器在两个稳定工况下的读数，T1_ref和T2_ref是标准温度计在同工况下的真值。算出来的系数存进主控的Flash或外部EEPROM，开机时加载，随时可以做软件修正。对HVAC这种应用，两点校准已经能拉到±0.3℃以内。

滤波我推荐一阶低通，效果比单纯滑动平均更平滑，代码也只有一行：

filtered_temp = 0.85f * filtered_temp + 0.15f * new_temp;

系数0.15决定了对新值的响应速度，调大更灵敏，调小更平稳。HVAC热惯性大，温度本来就不需要瞬时响应，可以往小里调。但要注意，任何滤波都会有滞后，如果项目之后要做低温冻库或者高精度工艺空调，滞后就必须在控制参数里补偿回来。

3. 远程温度上报链路：从MCU网口到上位机的三种务实玩法

3.1 最省事的TCP/HTTP上报方式

网口启动后，PJ85718DM测到的温度就只差最后一步送出去了。最简单的做法是主控开一个TCP服务器，监听固定端口，上位机随时可以连进来主动查询温度。适合调试阶段，打开电脑上的TCP调试工具输个端口号就能看到数据。

再进一步可以做成HTTP GET上报。设备作为客户端，每隔一段时间主动向服务器发一条请求，把温度挂在URL参数里，服务端收到后写进数据库或日志。报文简单朴素，服务器端完全不用额外开发，例如：

GET /api/temp?dev=AHU01&val=23.56 HTTP/1.1 Host: 192.0.2.10 Connection: close

这个方式的优点是直观，浏览器直接访问设备IP就能看到当前温度；缺点是报文里绝大部分是HTTP头，数据效率低，同时HTTP是短连接，每次上报都要重新建连，现场设备多时服务器压力不小。我一般只拿它做联调和早期原型，正式项目很少长期用。

3.2 MQTT上报，适合多设备集中监控

如果现场设备不止一台，我建议直接上MQTT。MQTT本质上是基于TCP长连接的消息协议，设备通过发布主题把温度推给服务器，上位机或者其他订阅端可以同时收到数据。第一次上线时做一轮CONNECT握手，之后一直保持连接，数据的实时性和服务器压力都优于短轮询。

常见的主题规划是分层级的，比如hvac/site01/ahu01/temperature，消息体用JSON字符串承载温度值和时间戳：

{"temp_c": 23.56, "temp_cal": 23.42, "err": 0, "ts": 1714567890}

设备端要实现的不只是发布消息，还要处理心跳和重连。MQTT有保活机制，设备每隔一段时间要发PINGREQ报文，不然服务器会判定连接失效。一旦断网，必须按退避策略重连，不能每两秒硬连一次把服务器拖死。我这边用的是递增退避：失败后等3秒、6秒、12秒，最大到30秒，连续成功后再把退避时间重置。

3.3 与上位机、云端的数据格式约定

远程数据能不能用，一半取决于两边对字段的约定。我强烈建议不要直接发裸float字节，一方面大小端不好处理，另一方面后续加字段很痛苦。统一用JSON虽然报文长一点，但可读性好、调试方便，MCU端解析工作量也不大。

如果设备端资源实在紧张，或者温度数据量大，可以用固定二进制帧：

无论哪种格式，时间戳必须统一。主控没配外部RTC时，可以先发设备启动后的秒数，由上位机换算成绝对时间；配了网络时间同步就更好。另外还要在帧结构里留一个“补报”标志位，后面断线缓存补报时会用到。

4. HVAC工况下，本地与远程两个环节都在吃的“可靠性格外要求”

4.1 网络断线时如何缓存温度并自动补报

HVAC设备装在楼顶、配电间、室外机组周围的概率很高，这些地方Wi-Fi或有线网络经常会因跳闸、拔插、交换机重启而断掉。如果设备断网就把数据丢了，后台的曲线图就会缺一块，几个星期后对账时很难解释。我的做法是在主控内存里维护一个环形缓冲区，按30秒一条的节奏把温度和本地时间戳存进去，容量1000条，大概能盖住8小时的数据。

断线期间消息照常往缓冲区写，同时把补报标志置位。网络恢复并完成MQTT重连后，设备把缓冲区里所有带补报标志的消息按时间先后发出去，发完再清标志。上位机看到补报字段就知道这批数据不是实时推送，而是离线补传。

要注意RingBuffer别写满还不处理，写满后要覆盖最旧数据，并且把“发生过溢出”的状态位上报。对大多数HVAC现场，8小时缓存足够覆盖临时断网，再长时间断网就需要上位机端做容错，而不是一味加大设备内存。

4.2 温度传感器故障检测

传感器接线松动、线路断裂、I2C总线被干扰，都会导致温度变成无意义的值。最现实的检测策略是三层判断：

• 连续N次I2C读取失败，直接判定传感器离线；
• 温度值超出传感器物理范围，比如读数小于-50℃或大于150℃，判定超限；
• 温度变化率异常，比如1秒内跳变超过10℃，大概率是探头脱落或者接触不良。

这三类故障都要在状态寄存器里置位，网络上报时把err字段置成对应的错误码，而不是把一条错误读数当成正常温度发出去。上位机看到设备状态异常可以主动告警，值班人员再去现场检查。这个流程不复杂，但很多项目就是没做，最后后台存了一堆-40℃的假数据，排查方向全被打乱。

4.3 看门狗、掉电保存与PID采样周期

HVAC设备经常无人值守，看门狗不是可选项。独立看门狗要喂，但不能在主循环末尾顺手喂，否则死循环照样能过。我习惯在任务级喂狗：采集任务成功完成一轮读到数据后喂一次，协议任务每次处理完网络事件再喂一次。这样单个任务卡死，看门狗会复位，才知道系统卡在哪。

掉电保存方面，HVAC设备掉电后重新上电，最好能把掉电前的温度状态恢复出来。利用MCU的掉电检测引脚，检测到电压跌落时把当前工作模式、PID积分值、最后一次有效温度写进备份寄存器。注意Flash不能频繁写，一般只在掉电瞬间写一次，正常运行时写的是RAM中的镜像。

PID控制周期的设计也有一层讲究。HVAC热惯量大，水泵、阀门、风机执行到位需要时间，PID控制周期太短只会让执行机构来回折腾，阀门寿命损耗很快。温度传感器1秒读一次没问题，但PID计算和执行输出放到5到30秒一次更合理。采集任务负责把最新温度放进共享变量，控制任务每N秒取一次，两个任务的时间解耦。

5. 一次真实调试中的三个坑：波形、时序、纹波

5.1 I2C总线过长导致的偶发FF

第一个坑出现在一台现场测试机上。设备运行几小时后，PJ85718DM偶尔会读回0xFF，重新上电又恢复正常，非常难复现。一开始怀疑是I2C寄存器写错，翻代码没发现问题，后来用示波器抓波形才看到真相：SDA线上的上升沿很缓慢，在总线电容较大的情况下，时钟高电平持续时间缩短，数据就来不及稳定。

排查路径是量总线电容。传感器线束走了大约60厘米，中间还过了一组接插件，总线电容明显超标。最后我做了三件事：SCL速率降到100kHz、上拉电阻从4.7kΩ改成2.2kΩ、线束换成屏蔽线并把屏蔽层单端接地。改完以后连续跑了两天，再没有出现过FF值。这个坑提醒我一个原则：I2C问题不能只在协议栈里找，要先确认电气波形合格。

5.2 以太网PHY连接不稳定的问题

第二个坑是网口偶发连不上。设备有时上电后几十秒就能被Ping通，有时要等几分钟，甚至Link指示灯亮着也一直断连。我用MDIO总线直接读PHY寄存器，发现PHY的状态寄存器里的链路状态位和实际网络行为不一致，基本可以判断是PHY上电时序有问题。

最后定位到主控复位信号上。MCU复位后立刻初始化以太网，PHY其实还没完成上电自检，导致初始化参数没有被正确写入。解决方法是把初始化过程拆成两步：先等PHY上电稳定几百毫秒，再执行以太网驱动的PHY配置。后来的板子干脆把PHY复位引脚也接到了MCU的GPIO上，软复位时序完全由固件控制，Link状态稳定多了。这个问题如果只看软件不看硬件手册，很可能被带偏。

5.3 电源纹波让温度读数周期跳动

第三个坑最隐蔽。温度读数每隔几十秒就会发生一次小幅波动，幅度大概±1℃，一开始我怀疑是传感器自热，但把探头悬空测试又很稳定。后来用示波器同时量传感器电源引脚和板内5V，才发现电控柜里变频器启动时会在电源上叠加明显的共模干扰，干扰传导到传感器供电，带歪了内部ADC的参考电压。

处理方法是给传感器供电加一级RC滤波：100Ω电阻串进电源线，后面并联10μF和0.1μF电容，滤掉高低频噪声。同时把传感器信号线和变频器动力线拉开距离，不许共用线槽。改完后温度曲线平得像一条直线。这里也给一个通用的排查表：

6. 再扩充到更多路温度和联动控制时，硬件上要预留什么

6.1 扩展第二颗传感器与远程探头布置建议

PJ85718DM这一类传感器一般支持多个I2C地址可选，同一根I2C总线上挂多颗就能测多路温度。如果原来只留了一个测点，后面要加回风温度或水管温度，只要走线长度控制好，软件加几行轮询代码就够了。比较远的路建议单独走屏蔽线，必要时加I2C总线缓冲器，不要让长线直接挂到总线上。

远程探头安装时要注意热接触。风管里的探头不能悬在空中，要用卡扣或扎带固定到风管壁或水管表面，否则测到的只是管道内的空气温度，不是设备实际工况温度。传感器和被测表面之间最好涂一层导热硅脂，减少接触热阻。

6.2 继电器、风机与风阀的驱动预留

温度监测送给谁都不如本地直接控温有意义。MCU的GPIO不能直接驱动继电器，需要光耦隔离加三极管或达林顿管驱动，线圈要并反向续流二极管。多路输出时用现成的ULN2803之类的驱动芯片最省事，一路一个继电器，外围元件很少。

硬件上记得给继电器输出预留常开/常闭跳线，现场接线可以灵活选择“断电开阀”还是“断电关阀”。HVAC里断水断电的安全模式各不一样，这个跳线不起眼，但现场调试时特别有用。电源地和数字地单点连接，避免继电器吸合瞬间的电流跳动干扰到传感器读数。

6.3 个人复盘

这套方案在我实际测试环境里跑了大半年，本地I2C读取在排除电气问题后，连续读数十万次没有一次失败；远程MQTT上报最长断线四小时，恢复后缓存数据全部补发到位，后台曲线唯一缺口来自服务器端重启。如果要再往前推一步，可以在固件里增加Modbus从机模式，让设备直接接入现有的楼宇自控系统；或者搞个Bootloader做远程固件升级，不然以后改协议全得靠现场拆机刷写，运维成本太高。

做HVAC嵌入式项目，我的体会一直是先把温度数据本身做扎实，再谈联网和智能控制。温度读数不可信，后面的计算、告警、能效分析全都是建立在沙子上。这套PJ85718DM加TM4C129XNCZAD的组合，正好把传感器可靠性和网络通路这两件最基础的事一次解决掉，值得在实际项目里试一试。