这套温度监测方案，核心是把PJ85718DM这颗数字温度传感器挂在TM4C1294KCPDT的I2C总线上做本地采集，同时利用TM4C1294KCPDT自带的以太网接口把数据发布出去，实现远程查看。PJ85718DM负责把环境温度变成数字信号，TM4C1294KCPDT则承担了系统控制和网络传输的重任。整套方案既能用于嵌入式设备的板级测温，也能直接嵌入HVAC控制器，让我在办公室打开浏览器就能看到设备机房的实时温度，还能顺手控制风机和加热设备。

我最初做这套设计，是因为一个HVAC项目里必须同时采集多个位置的温度，包括控制器本地的进风温度和安装在风管末端的回风温度。传统的模拟热敏电阻虽然便宜，但需要ADC采样和查表校准，抗干扰能力也一般。换成数字传感器之后，接线简单、误差明确，配合带网络功能的MCU，整个系统的信息流就顺了。这篇文章会从器件选型、原理图连接、驱动代码、远程Web访问到常见问题排查，完整走一遍整个开发流程，适合正在做嵌入式温度采集或者刚接触网络化传感器控制的朋友参考。

1. 方案拆解：为什么是这两颗芯片搭档

很多人在选择温度采集方案时会纠结：用模拟传感器还是数字传感器？用无线还是走网线？用单片机自己搭TCP协议栈还是外挂Wi-Fi模块？我给出的答案是，不要只考虑传感器的精度等级，要先想清楚系统的供电环境、通信距离和数据要送到哪里去。这套方案的选型逻辑，完全是从HVAC和嵌入式应用的实际约束出发的。

1.1 TM4C1294KCPDT：自带网络的MCU才是首选

TM4C1294KCPDT是一颗基于ARM Cortex-M4F内核的微控制器，主频可以跑到120MHz，带硬件浮点单元。这类芯片的外部资源非常丰富，Flash和RAM的容量都很充足，运行小型嵌入式系统绰绰有余。但真正吸引我的是它的网络相关特性：这颗芯片内部集成了以太网MAC控制器，并且把PHY也做进了封装里，也就是说，外部只需要接一个带隔离变压器的RJ45连接器，再加几个电阻电容，就能获得一个可用的10M/100M以太网接口。

在以往做嵌入式联网项目时，很多人习惯外挂一个串口转Wi-Fi模块或者SPI接口的以太网芯片，这样确实能快速联网，但会增加物料成本，也不可避免地引入通信链路上的不稳定因素。TM4C1294KCPDT把网络协议栈跑在芯片内部，CPU直接访问以太网控制器，数据吞吐能力更强，调试起来也能直接在寄存器层面观察问题。对于HVAC控制器这种需要长期稳定运行的设备来说，少一颗外部PHY芯片，就少一个故障点，也简化了PCB布局。

另外，我在项目里还需要同时采集多个PJ85718DM温度传感器，TM4C1294KCPDT提供了多组I2C接口，完全可以一条总线上挂多颗从机。它还有足够多的GPIO能驱动继电器、控制风扇、点亮状态灯。如果换一颗单纯的MCU，网络功能就得额外扩展，后续固件升级也会更麻烦。所以这颗芯片在我这里并不是很多人想象中的“高端货”，反而是一个非常适合“一脑多用”的控制核心。

1.2 PJ85718DM：一颗“会说话的体温计”

PJ85718DM是一颗数字温度传感器，通信接口是标准的I2C，输出的是已经数字化的温度值。它的典型分辨率能做到12位，最小刻度是0.0625摄氏度。这颗传感器的寄存器结构跟市面上常见的LM75系列比较接近，所以学习成本和移植成本都不高。把它理解成一颗“会说话的体温计”就很直观：你把温度计贴在目标位置，然后通过SCL和SDA两根线，就能把温度读数“读”出来。

在嵌入式系统中使用数字传感器最大的好处，是不再需要关心模拟前端的设计。过去用热敏电阻，要先搭电桥、再接运放、最后走ADC采样，每一个环节都会引入误差。PJ85718DM内部的感温元件和ADC都封装在芯片内，出厂时也做了基本的校准，用户只需要拿到寄存器里的原始数据，乘以分辨率系数，就能换算成实际温度。这样既节省了校准工作量，也让多个传感器节点之间的读数一致性好了很多。

这颗芯片的供电范围宽，在3.3V系统里面可以直接由MCU的稳压输出供电，不需要额外的电源轨。它的待机电流也很低，适合做低功耗嵌入式的休眠唤醒测温。更重要的是，I2C设备地址可以通过硬件引脚来配置，这意味着同一块板上可以挂多颗PJ85718DM而不会产生地址冲突。我在HVAC应用里就是这么干的：控制板附近一颗管本地进风温度，风管远端再挂一颗管回风温度，虽然挂着在同一条总线上，但各自有独立的地址，互不干扰。

1.3 本地与远程温度的完整数据链路

所谓“本地温度”，通常是安装在设备本体上的PJ85718DM采集到的读数，例如控制器外壳内部的空气温度。这个数据主要用于设备自身的过温保护、散热风扇启停控制，以及作为控制逻辑的输入。所谓“远程温度”，在HVAC系统里常见的实现方式有两种：一种是把另一颗PJ85718DM放在几十米外的风管内，通过长距离I2C线程或者独立采集板回传；另一种是利用TM4C1294KCPDT的网络能力，把本机采集到的温度数据发送到上位机或云端平台。

我这套设计里同时用到了两种“远程”手段。第一种，本地控制器通过Modbus或者简单的UART协议，从远端采集板获取温度，并把它当成远程温度变量参与逻辑运算。第二种，TM4C1294KCPDT把本地温度和远端回传的温度封装成JSON数据，通过以太网发送给浏览器端，这样我坐在办公位就能看到机房的实时温度曲线，不用专门跑到设备旁边。

整个数据链路可以归纳为：PJ85718DM温度寄存器 → I2C驱动读取 → MCU内部换算成摄氏度 → 参与阈值比较和控制逻辑 → 通过网络协议栈打包 → 浏览器或上位机展示。每一步都不复杂，难点在于把这条链路上的逻辑理顺，让温度数据的采集、传输和展示都在严格的时间周期内完成。下面几个章节，我会从硬件连接开始，一步步展开。

2. 硬件连接与板级设计要点

电路板设计直接决定了这套方案能不能稳定工作。很多人在软件上花了很多精力，结果硬件上犯了低级错误，导致I2C总线上拉电阻缺失、电源纹波偏大、传感器布线离干扰源太近，最后数据乱跳或者通信失败。这些问题有时候比软件还难排查，所以我先把硬件部分单独拿出来讲。

2.1 最小系统搭建与电源处理

TM4C1294KCPDT虽然功能很多，但最小系统的搭建并不复杂。它需要一颗主晶振提供时钟基准，我建议直接用25MHz的无源晶振配合两颗负载电容，频率由程序配置PLL来倍频到120MHz。复位电路用一个按键加上RC延迟就能满足开发需求。芯片有几个专门给模拟部分供电的引脚，最好用小磁珠把模拟电源和数字电源隔开，在噪声敏感的HVAC现场，这么做可以明显减少ADC和以太网PHY的抖动。

PJ85718DM的供电电压范围比较宽，但如果和MCU共用一个3.3V电源，需要注意稳压芯片的输出电流。TM4C1294KCPDT本身正常工作时的电流大概在几十毫安到一百毫安之间，加上以太网PHY的功耗也不会特别夸张，选一颗500mA以上的低压差稳压器通常就够用了。我在项目里还特地在传感器电源引脚旁边并联了一颗0.1uF和一颗10uF的电容，分别用来滤除高频纹波和稳定低频波动，实测下来温度读数的稳定性好了很多，这是一个性价比极高的操作。

还有一个容易被忽略的点：数字地和模拟地的分割。很多入门用户喜欢把板子上的地做成一整块，但我建议在传感器、网络变压器和MCU模拟电源附近做适当的分隔处理，然后在单点连接区域汇合。HVAC设备往往靠近强电线路，大功率继电器的动作会产生瞬间冲击，如果板子的地平面处理不好，温度数据可能会在继电器切换的瞬间跳变好几度。

2.2 I2C接口连接与上拉电阻选择

PJ85718DM的I2C接口只有两根线：SCL和SDA，两根线都必须接上拉电阻。这是I2C协议的开漏特性决定的，芯片只负责把线拉低，拉高是需要靠外部电阻完成的。上拉电阻的阻值选择有讲究：太小会增大灌电流，太大则会让信号上升沿变缓，在长距离通信时直接导致误码。

根据我实际的调试经验，标准模式100kHz下，上拉电阻选择4.7kΩ到10kΩ比较合适。如果传感器和MCU在同一块PCB上，距离很短，10kΩ完全够用。如果像我这样把第二颗传感器通过较长的线缆接出去，线缆本身有寄生电容，可以适当把上拉电阻下调到2.2kΩ左右，以保证边沿足够陡峭。我遇到过板子上的I2C总线上拉了4.7kΩ，接上长线后偶尔读不到数据的情况，换成2.2kΩ之后问题没有再出现过。如果总线上的设备很多，还可以通过增加总线电容预算来逐一估算，但对这种传感器数量不超过5颗的场景，用经验值快速调整会更高效。

PJ85718DM的从机地址由一个或两个地址引脚决定。把这几个引脚配置成高电平或低电平，就能得到不同的7位I2C地址。地址冲突这个问题，在设计阶段就应该规划好：板载传感器设一个地址，远端传感器设另一个地址，代码里固定读取这两个地址即可。调试时可以搞一个基础的I2C扫描程序，开机时枚举总线上所有存在的从机地址，这样能够快速确认硬件连接是否正常。

2.3 以太网部分与布线注意

TM4C1294KCPDT把PHY集成在片内，硬件上要做的事情就是接出一个带网络变压器的RJ45连接器。选择RJ45时最好带内置网络变压器和共模电感，这样可以省好多外部元件，还能提高防护等级。HVAC现场设备的网线可能和电源线走在同一个线槽里，偶发性的浪涌冲击必须要防。带变压器的连接器能隔离外界干扰，保护芯片。

以太网变压器的中心抽头一般要通过电阻或者电容连接到电源，具体接法要看PHY的参考设计手册。这里举一个常见做法：发送差分对的中心抽头接一个1kΩ电阻到3.3V，接收差分对的中心抽头通过0.1uF电容接地。如果用的是一体化RJ45模块，模块内部通常会给出参考电路，照着做就好。首次焊接完成后，最好用示波器看一下TX和RX引脚上的差分信号，确认幅度和波形都正常，再去写网络初始化代码。

布线时，差分对要尽量平行走线、保持等长，并且远离时钟线和其他高频信号线。说起来这些都是老生常谈，但我在改版过程中发现，同样的程序，之前莫名丢包，重新调整了网络相关走线并且拉远了继电器控制线的距离之后，通信质量立刻稳定了。所以硬件上多花一点心思，软件调试阶段会省很多事。

3. 温度采集核心：从寄存器到工程代码

硬件连接完成后，最核心的部分就是软件驱动了。温度采集虽然看起来只是一个“读寄存器”的过程，但其中包含了I2C时序处理、数据解析、异常判断等多个环节。我会以PJ85718DM的通用寄存器布局为例写一套可移植的驱动代码，并且在关键位置解释为什么这样处理。

3.1 传感器寄存器结构与读取顺序

PJ85718DM采集温度的核心寄存器是一个16位的数据寄存器，存放当前温度值。在标准模式下，温度寄存器的高字节存放温度的整数部分和低小数的高位，低字节的对应比特位存放剩余的小数位。具体格式是：12位温度数据中，最高位是符号位，接下来的11位是数据位。读取时需要先发送寄存器地址，然后连续读取两个字节。

我在写驱动时，最喜欢用的方法是先确认从机地址，再发送寄存器指针，然后以重复起始条件发起读操作。这里要特别强调“重复起始条件”的重要性：如果中间发一个停止条件再重新发送起始条件，虽然大多数从机也能接受，但在高速通信或从机状态机要求严格的场景下容易出错。TM4C1294KCPDT的I2C控制器支持连续读多个字节，所以正确的做法是：第一次写入从机地址和寄存器指针后，不要发送停止位，直接再发一次起始条件并带上读标志位的从机地址，然后连续接收两个数据字节。

温度数据的符号扩展也是新手容易忽略的地方。如果当前温度是零下，比如-5.5摄氏度，那么温度寄存器里的数据是以补码形式存放的。12位有符号数据换算到16位时，必须判断符号位是否为1，如果是，就需要把高4位全部填成1。否则，负数会被当成一个很大的正数，显示出来的结果完全不对。这一步理解透了，后面换算公式才不会出错。

3.2 完整驱动代码与温度换算

下面给出一段在TM4C1294KCPDT平台上读取PJ85718DM温度的核心函数。这里假设I2C外设时钟已经初始化，从机地址为0x48。代码里我故意把时序控制函数拆开，方便移植到不同平台。

#define SENSOR_ADDR_LOCAL 0x48 #define SENSOR_ADDR_REMOTE 0x49 #define TEMP_REG_ADDR 0x00 static uint32_t read_sensor_raw(uint8_t slave_addr) { uint8_t reg_cmd = TEMP_REG_ADDR; uint8_t data[2] = {0, 0}; // 发送寄存器地址 MAP_I2CMasterSlaveAddrSet(I2C0_BASE, slave_addr, false); MAP_I2CMasterDataPut(I2C0_BASE, reg_cmd); MAP_I2CMasterControl(I2C0_BASE, I2C_MASTER_CMD_BURST_SEND_START); while (MAP_I2CMasterBusy(I2C0_BASE)) ; // 重复起始条件，切换为读模式 MAP_I2CMasterSlaveAddrSet(I2C0_BASE, slave_addr, true); MAP_I2CMasterControl(I2C0_BASE, I2C_MASTER_CMD_BURST_RECEIVE_START); while (MAP_I2CMasterBusy(I2C0_BASE)) ; data[0] = MAP_I2CMasterDataGet(I2C0_BASE); MAP_I2CMasterControl(I2C0_BASE, I2C_MASTER_CMD_BURST_RECEIVE_CONT); while (MAP_I2CMasterBusy(I2C0_BASE)) ; data[1] = MAP_I2CMasterDataGet(I2C0_BASE); MAP_I2CMasterControl(I2C0_BASE, I2C_MASTER_CMD_BURST_RECEIVE_FINISH); while (MAP_I2CMasterBusy(I2C0_BASE)) ; // 合并为12位原始值 int16_t raw = ((int16_t)data[0] << 8) | data[1]; raw = raw >> 4; return (uint32_t)raw; } float convert_to_celsius(uint32_t raw) { int16_t signed_raw = (int16_t)raw; if (signed_raw & 0x0800) { signed_raw |= 0xF000; } return signed_raw * 0.0625f; }

我在这段代码里把原始数据右移了4位，丢弃低字节里用不到的低4位。如果不等数据移位就直接乘以0.0078125，也能得到结果，但很多器件的低4位并没有实际意义，提前移位可以避免把无效位带进符号判断，逻辑更清晰。对于零下温度需要先做符号扩展，再做乘法运算，这样才能得到正确的负值。

实际工程里，我通常会在read_sensor_raw里面加上超时和错误判断。如果总线上没有从机响应，I2C控制器会产生错误中断或者处于忙状态，读出来的数据毫无意义。一个简单的处理办法是设置超时变量，循环等待时如果超时就立刻放弃本次读取，返回一个明显异常的值（比如0x8000），上层逻辑看到这个值就知道传感器掉线了。如果让程序卡死在空中等待里，整个系统的控制循环就断了。

3.3 轮询、滤波与实时性取舍

温度变化本身是缓慢的物理过程，所以温度采集并不需要像控制环路那样毫秒级刷新。在HVAC应用中，我一般把采样周期设置为1秒。主循环里每1秒钟调用一次读取函数，两次读取之间MCU可以处理网络通信、继电器逻辑等任务。这样既保证了温度响应足够及时，也不会因为I2C占用太长时间而影响其他模块。

考虑到PJ85718DM的12位分辨率在最低有效位上会有±1个LSB左右的噪声，直接显示原始值的话，最后一位小数可能会跳动。解决办法是加滑动平均滤波。我习惯把最近8次采样值保存在一个环形缓冲区里，每次显示时取平均值。这种滤波对稳态温度几乎没有延迟，对于HVAC这种时间常数很长的系统来说完全足够。如果应用需要更快的响应，可以把滤波窗口缩小到4次，或者采用中值滤波来剔除异常尖峰。

在软件架构上，我把“读温度”和“用温度”两个环节解耦。读到的原始值经过滤波后，存入一个全局结构体，控制逻辑和网络服务都从这个结构体里取数。好处是后续增加传感器节点或者改成DMA采集，都不需要改动上层逻辑，维护便利性提升不少。

4. 远程温度数据对外服务

单独把温度读出来其实只是完成了半个项目。标题里强调“本地和远程温度监测”，意味着这套系统必须让数据“走出去”。TM4C1294KCPDT最大的优势就是能直接接入以太网，我利用这个特性开了一个TCP服务，让浏览器端能够看到实时温度数据。

4.1 远程温度的来源与数据格式约定

我设计的系统里有两类温度来源。一类是本地的PJ85718DM传感器，地址为0x48，它测量的是控制器所在位置的环境温度；另一类是远端挂在长线上的PJ85718DM传感器，地址为0x49，它测量的可能是风管末尾或者室外机附近的温度。对于远端传感器，如果距离太长，直接在总线上挂传感器可能不稳定，更稳妥的方案是让远端采集板先把温度通过RS485发送过来。我在代码里预留了一个解析项，可以从UART中断服务里收取类似“TEMP:R25.37”的字符串，解析后放入远程温度变量。

这样系统内有两个温度变量：local_temp和remote_temp。为了让网络端方便处理，我统一把它们转换成JSON格式。JSON的好处是浏览器端解析几乎没有门槛，上位机系统也大多支持。数据格式约定如下：

{ "local_temp": 23.875, "remote_temp": 25.312, "timestamp": 1699123456 }

timestamp字段我习惯用设备开机后的秒数来表示，方便做历史曲线图的横轴。这里要小心浮点数的格式化，在嵌入式设备上最好避免用printf打印浮点数，因为会占用不小的代码空间。更简单的做法是把温度放大100倍转成整数输出，或者用整数部分和小数部分分开写入字符串，我这里为了演示清晰用了浮点占位符，实际项目里建议根据编译器优化情况来做取舍。

4.2 在TM4C1294上拉起TCP/HTTP服务

TM4C1294KCPDT官方提供的网络库中集成了TCP/IP协议栈，使用方式和常见的BSD Socket接口接近。先初始化网络设备，然后创建一个socket，绑定80端口，监听连接请求，最后在循环里accept客户端的连接。每次连接后读取HTTP请求，回复一段最精简的JSON响应。下面给出核心逻辑：

static void temperature_http_server(void) { int server_sock; int client_sock; struct sockaddr_in server_addr; char rx_buf[256]; char tx_buf[512]; server_sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_addr.s_addr = htonl(INADDR_ANY); server_addr.sin_port = htons(80); bind(server_sock, (struct sockaddr *)&server_addr, sizeof(server_addr)); listen(server_sock, 4); while (1) { client_sock = accept(server_sock, NULL, NULL); if (client_sock >= 0) { recv(client_sock, rx_buf, sizeof(rx_buf), 0); snprintf(tx_buf, sizeof(tx_buf), "HTTP/1.1 200 OK\r\n" "Content-Type: application/json\r\n" "Connection: close\r\n" "\r\n" "{\"local_temp\":%.2f,\"remote_temp\":%.2f,\"timestamp\":%lu}\n", local_temp, remote_temp, (unsigned long)system_uptime_secs()); send(client_sock, tx_buf, strlen(tx_buf), 0); closesocket(client_sock); } } }

这段代码在实际运行时要注意两个问题。第一，recv获取到的请求数据里包含了HTTP头，但我们不需要关心请求内容，无论客户端请求根路径还是favicon.ico，统一返回温度数据即可。第二，浏览器并发连接数虽然不多，但每次建立TCP连接都会占用socket资源，如果客户端异常断开而没有正常收到数据，旧连接的清理可能遗漏。所以我在主循环里加了一个简单的长时间无活动连接清理机制，定期关闭超时连接，避免socket资源耗尽。

网络服务不要放在main函数里和主逻辑串行执行，最好放到单独的任务线程中，或者依赖操作系统的调度。TivaWare的例程里有些用轮询方式，有些用信号量方式。如果只有一个TCP服务，我倾向于采用低优先级轮询任务，不影响1秒周期的温度采样。

4.3 页面端实时显示与刷新机制

有了TCP/HTTP服务，浏览器访问设备的IP地址就能看到JSON数据。为了让展示更直观，我写了一个简单的HTML页面，用JavaScript定时去请求温度接口，然后更新页面上的数字。很多嵌入式工程师不熟悉前端，但其实这里只需要几十行代码就能完成。

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>HVAC Temperature Monitor</title> <script> function fetchTemp() { fetch('/').then(function(resp) { return resp.json(); }).then(function(data) { document.getElementById('local_temp').innerText = data.local_temp.toFixed(2); document.getElementById('remote_temp').innerText = data.remote_temp.toFixed(2); document.getElementById('update_time').innerText = new Date().toLocaleTimeString(); }).catch(function(err) { document.getElementById('local_temp').innerText = '--'; document.getElementById('remote_temp').innerText = '--'; }); } setInterval(fetchTemp, 3000); </script> </head> <body> <h2>HVAC 温度监测面板</h2> <p>本地温度: <span id="local_temp">--</span> °C</p> <p>远程温度: <span id="remote_temp">--</span> °C</p> <p>更新时间: <span id="update_time">--</span></p> </body> </html>

为了追求更快的调试速度，我一般不在代码里固化这个HTML页面，而是让HTTP服务在收到请求时，如果请求路径是根路径直接返回这个页面，请求路径是/data时返回JSON接口。这样可以省去每次改页面都要重新编译固件的麻烦。开发阶段的页面可以直接放在服务器文件系统，也可以用程序生成，看项目需要。

实际部署时，浏览器和设备在同一个局域网内，直接访问IP地址即可。如果想做跨公网访问，需要在网关设备上做端口转发，或者设备主动连接到云平台。对于工业HVAC系统，我更推荐后者，因为设备主动对外连接比网关做端口映射更安全，远程维护也更方便，但这部分涉及云平台接口，这里不再展开。

5. HVAC场景下的联动与阈值处理

温度监测的意义不在于把数字显示出来，关键在于如何利用温度数据做控制。HVAC系统里最常见的控制逻辑是：温度超过某个阈值时启动风机，低于某个阈值时开启加热，同时对于多个监测点进行温度差比较，判断设备运行是否正常。我在这一节里讲讲如何把采集到的温度数据变成一个可执行的控制逻辑。

5.1 阈值比较逻辑与去抖设计

很多新手写阈值控制时，会直接在主循环里比较温度值，然后立刻切换继电器状态。这样做的后果是，在阈值附近温度小幅波动时，继电器会频繁启停。继电器触点如果每天频繁开合，寿命会大打折扣。解决方法是引入回差控制，也就是常说的滞回比较。比如启动风机的温度阈值是35摄氏度，关闭风机的温度阈值设为33摄氏度，中间的2摄氏度就是回差。温度升到35摄氏度以上时才启动，降到33摄氏度以下时才停止，这样在35摄氏度附近的小跳动就不会引起频繁切换回差。

代码实现上，可以定义一个状态机的结构体：

#define HYSTERESIS_ON_TEMP 35.0f #define HYSTERESIS_OFF_TEMP 33.0f static uint8_t fan_state = 0; void update_fan_control(float local_temp) { if (fan_state == 0) { if (local_temp >= HYSTERESIS_ON_TEMP) { fan_state = 1; gpio_write(GPIO_PIN_FAN, 1); } } else { if (local_temp <= HYSTERESIS_OFF_TEMP) { fan_state = 0; gpio_write(GPIO_PIN_FAN, 0); } } }

除了回差，还可以增加时间延时保护。温度刚超过阈值时，先计时30秒再启动风机，这样能避免瞬间的传感器毛刺触发动作。这种去抖逻辑在HVAC和工业控制中是非常普遍的做法，值得在代码里认真处理。

5.2 报警和风扇控制执行示例

我用一个GPIO直接控制继电器模块，继电器接的是风机电源。GPIO驱动能力有限，不能直接驱动继电器线圈，所以中间加了一个三极管或MOS管，并在线圈两端反向并联一个续流二极管。这是最基本的防反电动势措施，如果漏掉，继电器释放瞬间产生的反向电压很可能损伤MCU引脚。

报警逻辑包括两路：本地温度过高报警和远程温度超限报警。当两个传感器中任何一个读数超出正常范围，状态灯单独点亮，并且会把报警状态写入一个全局标志位。网络服务里把这个标志位也放进JSON响应中，这样远程监控页面上就能看到报警状态，不需要再去机房巡检。报警阈值可以做成可配置项，通过网页传参来调整，但这里为了方便，我直接写死在配置结构体里。实际生产时，配置参数最好存到Flash的模拟EEPROM区域，这样掉电不丢失。

现场遇到的一个典型案例是：远程传感器所在的风管末端温度远比控制板温度高，但系统报的是本地温度故障。排查后发现，远程传感器断线了，读取到的是全1的无效值。所以控制逻辑里必须增加对无效数据的判断，一旦发现读数异常，就停止该通道的阈值比较，同时输出报警，避免设备做出错误决策。

5.3 传感器断线时的安全策略

传感器断线是HVAC设备上非常常见的故障。PJ85718DM如果从总线消失，I2C读操作会一直得不到ACK，最终在超时后返回一个单位置标记。我在驱动函数里把异常返回值设置为0x8000，同时在读取外层做一个合理性判断：如果温度读数大于150摄氏度或者小于-55摄氏度，就认为采集异常，把该通道标记为离线。

离线时的策略要分成两个层面。首先，控制系统不再依赖这个温度值进行调节，风扇或者加热器应该进入一个安全的开环模式。例如在夏季制冷工况下，如果回风温度传感器失效，我可以选择基于固定的最低运行时间周期切换设备，而不是完全关停，防止设备因传感器故障导致整个区域失去冷气。其次，网络服务要能反映当前传感器的状态，页面显示“离线”而不是一个假数字，避免运维人员被误导。

6. 常见问题与调试实录速查

开发过程中我踩过不少坑，有些坑看着不大，但排查起来相当费时间。下面把几个典型问题整理成实用笔记，希望对读者有帮助。

6.1 I2C读不到数据

从机地址不对是最常见的原因。PJ85718DM的地址引脚如果悬空，某些器件默认值可能取决于内部下拉电阻，产生不确定地址。排查办法是先写一个I2C扫描程序，遍历0x08到0x77范围内的所有地址，看看哪些地址有ACK响应。如果扫描不到任何从机，大概率是硬件问题：SCL或SDA没有上拉，或者两根线接反，或者MCU的I2C引脚没有正确复用。

还有一个隐蔽的问题：TM4C1294KCPDT的I2C引脚复用需要同时配置GPIO功能和外设时钟。如果只打开了I2C外设时钟而忘记调用GPIOPinConfigure函数，引脚仍然处于GPIO模式，当然不会有数据。我习惯把所有外设初始化放在独立函数中，统一调用，并且每次修改引脚定义后都会重新检查数据手册里对应的引脚号和复用值。

6.2 温度读数波动与校准

温度读数在小数位上跳动，首先要确认是传感器噪声还是环境确实在变。用手握住传感器，温度会快速上升，这可以验证读数逻辑是否正确。如果读数在正常状态下仍有明显波动，排查顺序是先看滤波是否开启，再看电源纹波，最后看传感器周围是否有强热源。

校准方面，数字传感器出厂精度通常已经满足0.5摄氏度的系统要求，但如果你需要更高精度，可以用恒温槽或者简单的冰水混合物做单点校准。对于恒温状态，读取到的偏移量可以作为一个修正值保存。更严谨的做法是把标准温度计和被测传感器放在同一环境，读取多组数据做线性拟合，得到系数a和b，最终显示温度为a乘以原始读数加b。

6.3 网络访问异常与连接卡死

TCP连接卡死通常不是单片机协议栈的问题，而是资源管理不到位。常见的表现是设备工作几天后网页打不开，重启之后恢复。我用langsys分析过这类问题，多半是socket没有正确关闭，文件描述符耗尽。

解决方案是严格控制服务端的并发连接数，accept之后如果发现连接超过设定上限，立即拒绝。同时，每次recv的数据不必等待完整的请求，只要拿到了第一行就能返回响应，然后主动关闭连接。这样即使客户端软件行为怪异，也不会占用额外资源。

还有一种情况是局域网内可以访问，但跨网段不行。先确认网关和子网掩码配置是否正确，接着检查设备是否能ping通网关。TM4C1294KCPDT的以太网PHY从复位到链接稳定需要一小段时间，如果初始化完成后立刻去ping，可能因为PHY还未完全就绪而失败。我在网络初始化代码后面加了一个等待函数，确保PHY工作状态正常后再启动协议栈，问题瞬间解决了。

我在调试这段温度监测系统时，最大的感受是：硬件连接、I2C驱动、网络协议三块内容都不算高不可攀，难的是把它们组合起来运行在真实环境中。特别是PJ85718DM这类数字传感器，表面上只是一个I2C从机，但它的寄存器读取时序、符号位处理、以及长线连接下的信号完整性，都会直接影响系统表现。TM4C1294KCPDT作为控制器，把数据采集和网络服务整合在单颗芯片里，让原型开发周期缩短了很多。

最后分享一个很实用的技巧：在正式安装到HVAC设备之前，我把这套系统放在办公室桌面上跑了整整一周，通过网络界面每天记录温度曲线，和房间实际温度感受做对比。这样做的目的是在实验室环境里先发现潜在问题，而不是到了现场再去改代码。等到设备真正上线的时候，固件已经经过长时间连续运行的考验，后面省下的调试时间，远远超过了开发时多花的那几天。