企业官网建设流程全解析

简介：面向STM32课程设计与物联网入门，这是一套整合ESP8266 Wi-Fi模块、STM32F103ZET6主控及LabVIEW上位机的温度采集项目，可完整实现数据采集、无线传输与实时显示。压缩包共288个文件，整体约2.03MB，涵盖C语言源码（70个.h头文件、58个.c源文件）、编译产物、工程配置与LabVIEW程序（.vi）等；其中源码基于标准外设库，含定时器、ADC、Flash、RCC等驱动模块，便于二次开发。项目提供STM32读取DS18B20等传感器的固件写法、ESP8266通过AT指令连接网络并上传数据的配置逻辑，以及LabVIEW接收解析并可视化温度的界面方案；同时覆盖硬件连接、串口通信、Wi-Fi透传、数据存储与分析等关键环节，从底层驱动到上位机界面均有完整工程对应，并附有调试与测试要点。已有2500余人学习下载，适合作为课设模板或物联网实战参考，有助于快速形成项目整体认知。

1. 一个课设项目能走多远：从串口屏到远程可视化

第一次见到这个项目时，我以为就是个普通的STM32温度计课设——单片机读个数，LCD屏显示一下，交差完事。但把源码完整过了一遍之后，我发现它比大多数课设多走了一步：把DS18B20采集的温度，通过STM32ZET6处理后交给ESP8266，再经WiFi传给上位机端的LabVIEW程序实时显示。换句话说，你人在隔壁实验室，不用蹲在板子前面盯着LCD，打开电脑就能看到当前温度和变化曲线。

适合谁用？两类人。一类是做STM32课程设计、毕业设计的学生，这套东西把传感器采集、串口通信、无线透传、上位机可视化全串起来了，一个项目覆盖四五个考点；另一类是刚接触嵌入式物联网的开发者，想看看一块裸机MCU怎么和WiFi模块配合，怎么定通信协议，怎么让数据从硬件一路跑到上位机界面。硬件成本压到几十块钱，核心代码都能在工程里直接找到，照着改就能出活儿。

2. 系统架构与通信链路：DS18B20到LabVIEW之间发生了什么

2.1 整体框架与硬件选型

先把这个项目的骨架画出来。数据源头是DS18B20数字温度传感器，它走单总线协议，一根线就能把温度数值传出来。主控是STM32ZET6，这是STM32F1系列里的高配型号，64KB RAM、512KB Flash，管脚多到用不完，课设用它属于杀鸡用牛刀，但也正因为管脚多，你想折腾什么外设几乎不用省着用。ESP8266负责无线传输，工作在透传模式——MCU把数据通过串口丢给它，它原封不动通过WiFi发出去。最上层是一台跑着LabVIEW的电脑，通过TCP/IP协议接收数据并画曲线。

DS18B20（温度采集）→ 单总线 → STM32ZET6（数据处理）→ UART → ESP8266（WiFi透传）→ 路由器/热点 → LabVIEW上位机（TCP接收＋可视化）

这个链路里有一个关键决策值得注意：ESP8266用的是AT指令固件，而不是SDK二次开发。很多人在这一步纠结要不要用ESP8266 RTOS SDK直接写固件，把采集和网络全塞进ESP8266里。这个项目的选择是让ESP8266只干透传的活儿，所有业务逻辑都留在STM32上。这么做的合理性在于，课设场景下你最熟悉的是STM32的开发流程，Keil MDK里写代码、下载、调试一条龙；而ESP8266的SDK开发需要另一套工具链，出了问题排查起来成本高。把复杂度压在一个你熟悉的芯片上，是这类项目最稳的路线。

2.2 串口通信分配与关键引脚

整个系统的通信角色划分非常清晰，两块芯片各司其职。STM32ZET6内部有三个主要通信通道：DS18B20挂在普通GPIO上，用单总线协议读写；USART1接ESP8266，用于透传温度数据；USART2预留作调试打印，方便在开发阶段看日志。这个分配方式的好处是调试通道和数据通道物理隔离，不会互相干扰。

引脚分配是照着这个项目的实际用法来说的，你拿到工程后可以根据自己板子的丝印调整：

• DS18B20数据脚：PA0，配置为开漏输出，外接4.7kΩ上拉电阻。
• ESP8266 TXD：接STM32的USART1_RX（PA10）；ESP8266 RXD：接STM32的USART1_TX（PA9）。
• ESP8266 CH_PD（使能脚）：接3.3V，拉高启用模组。
• 串口调试：USART2（PA2/PA3），通过USB转TTL连电脑。
• 电源：STM32板载3.3V稳压输出给ESP8266供电，但注意——如果ESP8266发射时电流骤增，板载LDO可能扛不住，这个问题后面避坑章节专门展开。

2.3 通信协议设计：每一帧数据的结构

一个很容易被课设忽略、但在这个项目里做得像样的地方是通信协议。如果STM32只是裸发温度值，比如发个"26.5"，一旦小数点和位数错位，上位机解析就很痛苦。这个项目定义了明确的帧结构，每一包数据由帧头、数据长度、温度整数部分、小数部分、校验和、帧尾组成。

帧格式定义如下，在STM32端的发送代码里可以看到对应的字节拼装逻辑：

• 帧头：0xAA 0x55，两个字节，用于上位机识别包起始位置。
• 长度字节：固定值0x04，表示后面有效数据的字节数。
• 温度整数：一个字节，取值范围0~125。
• 温度小数：一个字节，取值范围0~9，表示一位小数精度。
• 校验和：温度整数+温度小数+长度字节的和，取低八位。
• 帧尾：0x0D 0x0A，即回车换行。

上位机解析时会先找0xAA 0x55这对帧头，找不到就一直滑动窗口寻找，找到后再按固定偏移读取长度和温度字段，最后做校验和比对。这种协议看起来简单，但它在UDP/TCP传输中能有效防止粘包和半包问题——因为你总能用帧头定位，用帧尾确认，用校验和过滤脏数据。

3. STM32端核心代码拆解：从单总线读温度到串口发帧

3.1 DS18B20单总线驱动：时序是灵魂

DS18B20是单总线设备，所有通信都靠一根数据线上的时序来区分"0"和"1"。读温度看起来是个简单操作，但底层每一步都有严格的时间约束。这个项目的驱动文件（ds18b20.c）里，三个函数构成了完整读温流程：复位、写字节、读字节。

先看复位时序，这是每次通信的起点：

uint8_t DS18B20_Reset(void) { uint8_t presence = 1; GPIO_ResetBits(DS18B20_GPIO_PORT, DS18B20_GPIO_PIN); // 主机拉低总线 delay_us(480); // 至少拉低480us，产生复位脉冲 GPIO_SetBits(DS18B20_GPIO_PORT, DS18B20_GPIO_PIN); // 释放总线 delay_us(80); // 等待从设备应答 if (GPIO_ReadInputDataBit(DS18B20_GPIO_PORT, DS18B20_GPIO_PIN) == 0) { presence = 0; // 读到低电平说明DS18B20存在并应答 } delay_us(400); // 等待应答结束 return presence; }

逻辑说明：整个复位过程分三步——主机主动拉低总线480us以上，这是告诉DS18B20"我要开始通信了"；然后释放总线，DS18B20检测到上升沿后会等待15~60us，再拉低总线60~240us作为存在应答；主机在这段时间读到低电平，就确认设备在线。返回值presence是0表示设备存在，非0则说明总线上没挂设备或接线有问题。这个函数是整个驱动的地基，如果它总返回1，后面所有读温操作都会失败，排查时先量上拉电阻和接线，别急着改代码。

接着是写时序和读时序，这两个函数合在一起构成了单总线通信的字节传输层：

void DS18B20_WriteByte(uint8_t byte) { for (uint8_t i = 0; i < 8; i++) { GPIO_ResetBits(DS18B20_GPIO_PORT, DS18B20_GPIO_PIN); if (byte & 0x01) { delay_us(60); // 写1：拉低后延时60us GPIO_SetBits(DS18B20_GPIO_PORT, DS18B20_GPIO_PIN); } else { delay_us(10); // 写0：短延时后释放 GPIO_SetBits(DS18B20_GPIO_PORT, DS18B20_GPIO_PIN); delay_us(50); } byte >>= 1; } } uint8_t DS18B20_ReadByte(void) { uint8_t byte = 0; for (uint8_t i = 0; i < 8; i++) { byte >>= 1; GPIO_ResetBits(DS18B20_GPIO_PORT, DS18B20_GPIO_PIN); delay_us(2); // 拉低2us后释放 GPIO_SetBits(DS18B20_GPIO_PORT, DS18B20_GPIO_PIN); delay_us(10); // 在15us内读取电平 if (GPIO_ReadInputDataBit(DS18B20_GPIO_PORT, DS18B20_GPIO_PIN)) { byte |= 0x80; } delay_us(60); } return byte; }

读时序是重点：主机拉低总线2us后释放，然后必须在15us内采样电平。为什么？因为DS18B20在检测到主机释放总线后，会立刻决定是否拉低总线——如果它要传0，就在释放后约15us内拉低；如果传1，就保持高电平。你在10us处读电平，正好落在它的时隙窗口内。很多人在这里踩坑是因为用了普通的HAL_Delay毫秒级延时，时间精度不够，读到的是乱码。这个项目用的是自己封装的delay_us微秒级延时，实际是SysTick做的基础定时，精度有保证。

3.2 读取温度并转换：12位精度下的移位处理

DS18B20的温度寄存器是12位的，需要读取两个字节再拼成一个完整值。芯片上电后默认工作在9位精度，12位精度需要发送命令0x44启动温度转换，再等750ms（12位转换时间上限），才能读暂存器。不过更可靠的做法是不断读忙标志位——用0xBE命令读暂存器的第7字节（bit7是转换完成标志）。

这个项目的温度读取函数把这两步合并了，核心代码如下：

float DS18B20_GetTemperature(void) { uint8_t temp_l = 0, temp_h = 0; int16_t temp_raw = 0; float temperature = 0.0f; DS18B20_Reset(); DS18B20_WriteByte(0xCC); // 跳过ROM匹配，适用于单设备场景 DS18B20_WriteByte(0x44); // 启动温度转换 while (DS18B20_ReadByte() != 0xFF); // 等待转换完成，0xFF表示空闲 DS18B20_Reset(); DS18B20_WriteByte(0xCC); // 跳过ROM匹配 DS18B20_WriteByte(0xBE); // 读取暂存器 temp_l = DS18B20_ReadByte(); temp_h = DS18B20_ReadByte(); temp_raw = (temp_h << 8) | temp_l; temperature = (float)temp_raw * 0.0625f; // 12位精度下，LSB对应0.0625℃ return temperature; }

逻辑说明：第一段0xCC+0x44是启动转换，命令发出后芯片开始测量；while循环读总线状态，当读到0xFF说明转换结束——这是单总线协议里的一个巧妙设计：转换期间芯片会一直拉低总线，完成后释放，主机读到的就是高电平0xFF。第二段0xCC+0xBE是读取暂存器的前9个字节，其中前两个字节就是温度值。温度值是一个有符号数，高字节的bit15是符号位，正温度时高字节低四位为0，负温度时取反加一。乘以0.0625是因为12位精度下每个LSB代表1/16摄氏度。

如果你要用这个函数做扩展，注意两点。一是函数里没有处理负温度，环境温度低于零度时读出来的数值是错的，需要补一段判断temp_raw的bit15，若为1则先取反加一再乘以0.0625，最后加负号；二是0xCC跳过ROM的命令只适合总线上只有一个DS18B20的情况，如果扩展成多传感器并联，要改成发送各传感器唯一的64位ROM码。

3.3 数据帧打包与串口发送

温度值拿到之后，下一步是把它封成事先定好的帧格式，通过USART1发给ESP8266。这个项目在main函数的主循环里做了这么一件事：每500ms读一次温度，然后调用发送函数把温度帧推给ESP8266。看发送部分的实现：

void Temperature_SendFrame(float temp) { uint8_t buf[7]; int8_t int_part = (int8_t)temp; uint8_t dec_part = (uint8_t)((temp - int_part) * 10); buf[0] = 0xAA; // 帧头1 buf[1] = 0x55; // 帧头2 buf[2] = 0x04; // 有效数据长度 buf[3] = int_part; // 温度整数部分 buf[4] = dec_part; // 温度小数部分（一位精度） buf[5] = (buf[2] + buf[3] + buf[4]) & 0xFF; // 校验和 buf[6] = 0x0D; // 帧尾 CR buf[7] = 0x0A; // 帧尾 LF for (uint8_t i = 0; i < 8; i++) { while (USART_GetFlagStatus(USART1, USART_FLAG_TC) == RESET); USART_SendData(USART1, buf[i]); } }

这个函数做了三件事：把浮点温度拆成整数和小数两个字节，拼装出完整的帧，然后用查询方式逐字节发送。逐字节发送时每发一个字节都等发送完成标志位TC置位，如果这个标志位一直不置位，多半是串口没初始化成功或者引脚复用配置错了，可以回过来查GPIO和USART初始化。

帧格式值得再强调一点：为什么温度值不直接以ASCII字符串"26.5"发送？因为LabVIEW端解析字符串要处理变长问题，还得自己判断小数点的位置，容易出bug。而固定长度的二进制帧，解析逻辑就是按偏移取值，一个"找帧头→读长度→取值→校验"的过程，代码量小且不容易出错。这种设计思路在任何主从通信场景里都通用，你在做别的项目时也可以套用。

4. ESP8266透传配置与LabVIEW上位机：数据如何上云落地

4.1 ESP8266 AT指令配置流程

ESP8266在这里只用它的透传能力——STM32通过串口发什么，它就通过WiFi转发什么；WiFi收到的数据，它也原样通过串口交给STM32。要做成这样，需要给ESP8266发送一组AT指令来配置工作模式。项目里通常的做法是上电后在STM32的初始化代码里，或者在调试阶段直接用串口助手手动发指令，把ESP8266配好。下面这组指令是标准的透传配置序列：

AT // 测试模块是否响应，正常返回OK AT+CWMODE=1 // 设置为Station模式，连接外部路由器 AT+CWJAP="你的WiFi名","你的WiFi密码" // 连接WiFi热点 AT+CIPMUX=0 // 关闭多连接，单连接模式 AT+CIPSTART="TCP","192.168.1.100",8080 // 连接上位机IP和端口 AT+CIPMODE=1 // 开启透传模式 AT+CIPSEND // 进入透传发送状态

每组AT指令都有明确分工。AT+CWMODE=1是必须的，因为只有Station模式才能连别人的路由器，如果你用AP模式，那就是让ESP8266自己开热点，电脑连的是ESP8266的WiFi，这适合在没有路由器的场景下临时用，但传输稳定性不如走路由器。AT+CIPSTART是建立TCP连接，注意后面的IP地址必须是上位机（跑LabVIEW那台电脑）在局域网里的IP，端口随便定一个没被占用的就行，比如8080。AT+CIPMODE=1打开透传模式后，ESP8266成了一个透明管道，一条数据流直通上位机。

配置成功后，STM32每次调用Temperature_SendFrame发送帧，数据就会沿着UART进入ESP8266，再以TCP包的形式打到上位机的8080端口——硬件和网络两个世界在此打通。

4.2 LabVIEW上位机的接收与界面逻辑

LabVIEW是图形化编程，它的代码长得不像传统代码，而像流程图。这个项目的上位机部分在接收数据时用的是TCP监听模式：电脑上开一个TCP Listen VI，监听8080端口，一旦ESP8266连上来，就建立一个TCP连接，然后在一个while循环里不断读数据。

接收端的核心处理逻辑是：每次读到一批字节，先存入接收缓冲区，然后在缓冲区里逐字节扫描找0xAA 0x55帧头。找到帧头后，按帧格式取出长度字节，如果缓冲区剩余长度够，就读取温度整数和小数，再算校验和比对。校验通过则更新界面上的温度显示控件和波形图；校验失败则丢弃这一帧，继续找下一帧。这个设计对应了刚提到的粘包问题——TCP是流协议，底层可能会在一次读取里把两帧数据拼在一起传上来，也可能把一帧拆成两次传。找帧头的方式天然处理了这两种状况。

界面部分通常包含三个元素：一个数值显示控件用来显示当前温度，一个波形图控件用来画温度随时间的变化曲线，一个指示灯用来显示网络连接状态。如果你在自己机器上打开这个VI时发现界面和项目截图不太一样，大概率是LabVIEW版本不一致导致的控件外观差异，功能和数据绑定关系不变。

4.3 上位机参数配置的正确匹配关系

跑通上位机的前提是网络参数和硬件端完全匹配。三个要点如下：

• 上位机的TCP监听端口必须和AT+CIPSTART里写的端口一致，写错任何一个数字，ESP8266连接就会超时。
• 上位机电脑的防火墙要放行所选端口，否则数据包到了系统层面直接被拦，LabVIEW界面上的连接指示灯永远不亮。
• LabVIEW的TCP Read每次读取字节数要设置合理，建议设成64字节以上。因为ESP8266发送频率是每500ms一帧，每帧8字节，一次读太少会导致缓冲区积压，太多则可能跨帧读取，增加解析逻辑的复杂度。

我自己第一次跑通这类项目时，卡在防火墙那一步整整一个下午。现象是ESP8266已经显示连接成功，但LabVIEW端就是收不到数据为什么？因为Windows防火墙默认拦截所有入站TCP连接，LabVIEW的TCP监听被系统静默丢弃了。解决方式是在防火墙高级设置里添加入站规则，放行LabVIEW程序或直接放行8080端口。

5. 避坑指南：六个最容易翻车的环节与排查顺序

5.1 DS18B20读出来永远显示85℃

现象：STM32上电后，LabVIEW界面显示85.0℃不变，过多久都不刷新。

原因：DS18B20在上电瞬间，温度寄存器会有一个默认值0x0550，换算过来正是85℃。如果你程序里启动温度转换的命令没被正确执行，读到的就是上电默认值。这背后通常是单总线通信没成功——要么接线错了，要么时序不对，要么上拉电阻缺失。

解决：先量数据线的静态电平，正常情况下空闲状态应为高电平（3.3V或5V）。如果量到低电平，说明缺上拉电阻或者GPIO配置成了推挽输出而非开漏输出。如果电平正常，用示波器或逻辑分析仪看复位时序，确认主机拉低时间和释放后的应答脉冲是否出现。都没问题再把delay_us的延时精度核一遍，建议用逻辑分析仪实测时序参数。

5.2 ESP8266反复重启，WiFi连不上

现象：ESP8266上电后板载指示灯闪烁，串口调试窗口里不断打印乱码或者重复出现"ready"，但AT指令没反应。

原因：八成是供电不足。ESP8266在WiFi发射瞬间电流会冲到200~300mA以上，而很多STM32开发板的板载3.3V LDO最大输出电流只有100~150mA左右，根本喂不饱它。电压跌落时芯片自动复位，表现为无限重启。

解决：别用开发板板载3.3V给ESP8266供电，改用外部AMS1117-3.3稳压模块或者直接从USB电源取电，再并联一个10~100μF电解电容和0.1μF陶瓷电容稳住电源。这个项目在文档里特别标注了这一点，属于标准的血泪经验。接线时把CH_PD接3.3V也是容易漏的一步——这个引脚是芯片使能端，悬空或拉低都会导致芯片不工作。

5.3 串口接收乱码，LabVIEW解析不出正确温度

现象：LabVIEW上偶现温度值异常大或为负数，比如显示"208.7℃"，但查看打印日志时数据帧格式看起来是对的。

原因：帧校验失败导致解析串位。当一串数据里某一帧因干扰丢了一个字节，接收端在未检测到帧头的情况下，会从错误位置开始找下一帧。尤其当错误字节恰好是0xAA或0x55时，误判帧头，后续整个解析就全乱了。

解决：不要单纯依赖帧头定位，校验和必须参与裁决。这个项目的校验和是累加取低字节，强度只能算入门级。如果你发现高频丢包场景下误判率偏高，可以把校验升级为CRC8，代码量不大但效果立竿见影。另一个保险做法是连续收到两帧校验正确的数据才更新界面，可以过滤掉个别错误帧带来的毛刺。

5.4 LabVIEW端能连上但收不到数据

现象：ESP8266的AT指令里CIPSTART返回CONNECT OK，但LabVIEW的TCP Read一直返回超时。

原因：可能有两种。一是LabVIEW的TCP监听端口和ESP8266连接的目标端口不一致，这个纯属配置低级错误；二是Windows防火墙拦截了入站连接，这是最常见的原因。

解决：先确认端口一致，然后在Windows防火墙里添加一条入站规则，允许TCP 8080端口通过。如果是在公司或学校网络环境里跑，还要确认路由器没开AP隔离（AP隔离会让同一WiFi下的设备互相不可见），这是这类项目比较容易忽略的环境问题。

5.5 数据刷新太慢或太快，波形图不成样子

现象：波形图要么长时间平线，要么刷得太快没法看清趋势。

原因：STM32主循环里的发送间隔决定了数据刷新率。课设里常见做法是发送间隔调得太短，10ms一帧，导致WiFi透传的TCP包过于频繁，路由器缓冲队列溢出丢包；或者调得太长，10s一帧，看起来像死机了。

解决：500ms到1s发送一帧是比较合理的区间，既能看清温度变化趋势，又不会给传输链路太大压力。LabVIEW端也可以在波形图控件上设置X轴时间窗口，比如显示最近5分钟的范围，效果会更接近工业监控界面。

5.6 用ST-Link下载程序时串口数据丢失

现象：烧录完程序，拔掉ST-Link重新上电后，LabVIEW就收不到数据了；但在调试模式下一切正常。

原因：ST-Link的调试口（SWDIO/SWCLK）和USART1引脚冲突。很多STM32ZET6核心板的USART1_TX/RX刚好复用了PA9/PA10，而PA10同时也是SWDIO复用脚。调试器挂着时通信正常，拔掉后引脚浮空导致串口异常。

解决：下载完程序后不要急着拔调试器，先确认板子供电正常；如果必须拔掉，建议把USART1的引脚配置里GPIO_Mode改成复用推挽输出，并在代码里做一次引脚重映射，或者直接把ESP8266改接到USART2（PA2/PA3），避开调试引脚冲突。

6. 二次开发思路：从固定温度计到可扩展的物联采集终端

6.1 多路传感器扩展：改驱动与改协议

这个项目最初只挂了一路DS18B20，但实际上DS18B20是支持并联的，最多一条总线挂几十个，靠64位ROM码区分。如果你要做多点测温，改动路径很清晰：驱动层增加ROM匹配逻辑，改0xCC为0x55+ROM码命令；协议层在帧结构里增加传感器ID字段；LabVIEW端根据ID分发到不同波形图通道。

我一般会这么做：定义一个结构体数组，每个元素存一个传感器的ROM码和最近的温度值，主循环里轮询每个传感器，顺序发送多个帧。注意轮询间隔要乘上传感器数量，比如原来500ms发一帧，三路传感器就改成每个传感器间隔1.5s，避免总线占用太密集导致时序错乱。

6.2 数据上云：从局域网的LabVIEW到云平台

局域网方案的天花板是「换一台电脑，重新配IP」。如果想让温度数据在任何地方都能看，最简单的升级是让ESP8266走MQTT协议连云端物联网平台。做法是在ESP8266里刷支持MQTT的固件（比如用MQTT库示例），或者保留当前透传模式，在局域网内加一台跑着MQTT Broker的树莓派或云服务器做数据转发。

换成MQTT方案后，LabVIEW就不一定是必需的终端了——手机App、微信小程序、网页Dashboard都能订阅主题拿到数据。如果还想保留LabVIEW，可以在PC上装MQTT客户端库，让LabVIEW订阅同一个主题来显示曲线。这个改动相当于把传输层从TCP裸传升级到发布/订阅模式，架构上多了一层抽象，但换来的是终端解耦，数据不再绑定某一台特定主机。

6.3 增加超限报警与历史存储

把LabVIEW的显示界面升级成一个简易监控系统，可以从两个方向入手。一是报警逻辑——设定温度上下限，当数据帧校验通过且超限时，通过LabVIEW的蜂鸣器或弹窗提醒；二是历史存储——用一个TDMS文件格式记录每一帧的原始数据和时间戳，测量结束后用Excel或MATLAB做后处理。TDMS是LabVIEW原生的高速数据存储格式，写起来就是打开文件、写入数据、关闭文件三个VI，比直接用文本日志快很多。

6.4 协议层升级为JSON格式

当前的二进制帧格式优点是固定长度，但缺点是人不可读，你要在串口助手里看到"AA 55 04 1A 03 21 0D 0A"，才能反应过来是26.3℃。如果想让系统更通用、更易调试，可以换成JSON格式的ASCII字符串：{"id":1,"temp":26.3}。STM32端用sprintf拼JSON字符串，LabVIEW端用JKI JSON库解析，开发调试阶段肉眼可见数据内容，排查问题会快很多。不过代价是每帧的数据量增大了，传输频率不变的情况下，对带宽的占用会上升——在WiFi透传场景里这完全不是问题，如果你用的是低速Sub-1G或者窄带物联网，就要慎重权衡了。

6.5 验证一次跑的链路是否完整

每次改完代码，我都会强制走一遍这条验证链路：先用串口助手直连STM32的USART1调试口，确认温度帧格式正确、频率稳定；再在PC上用网络调试助手开一个TCP Server，仿真LabVIEW的监听端，确认ESP8266能打通网络链路；最后才启动LabVIEW看界面。如果中间任何一环不通，先看本机防火墙配置和IP地址是否变化——尤其是路由器重启后动态分配IP的场景，很多"昨天还好好的，今天就连不上"的故障，根因就是上位机IP变了，ESP8266连的还是那个写死的旧IP。

从那以后，我在ESP8266项目里都强制在初始化代码里加入AT+CIPSTART失败自动重连的逻辑，而不是靠上电手动配置。这种"自动重连+日志可追踪"的习惯，让系统从课设水准往前跨了一大步。希望这个项目的拆解对你跑通它、改出属于自己的版本有帮助。

本文还有配套的精品资源，点击获取