STM32+4G+WiFi实现物联网设备远程无线配置服务器地址-编程实验室

简介：本资源是一套面向物联网嵌入式开发者的STM32F103单片机实战工程，聚焦于通过ESP8266 WiFi模块远程配置EC800-4G模块的目标服务器IP与端口，解决多网络模组协同通信中的参数动态下发难题，适用于智能终端、远程数据采集等典型物联网场景，适合具备C语言基础与STM32外设开发经验的中级工程师快速集成。压缩包共256个文件，含46个头文件（.h）、41个源码文件（.c）、44个编译中间文件（.d）、43个依赖信息（.crf）及多个可执行镜像（.axf/.hex）、链接脚本（.sct）和配套APK配置工具，总大小9.34MB；其中APK为WiFi热点式图形化配置工具，.c/.h文件均带详细注释，KEIL工程结构完整，支持J-Link或ST-Link下载。已有141人学习下载，提供从硬件接线定义、AT指令交互逻辑到4G联网调试的全流程参考，代码适配F103全系列芯片，仅需微调KEIL芯片型号与FLASH配置即可迁移使用。

1. 项目概述与核心价值

最近在做一个物联网项目，需要让一个基于STM32F103的设备通过4G网络，把采集到的数据稳定地发送到远方的服务器上。听起来是个很常见的需求，对吧？但实际做起来，你会发现一个挺麻烦的问题：服务器的IP地址或者端口号要是变了怎么办？难道每次都要派人去现场，用USB线连上电脑，重新烧录一次固件吗？这成本和时间都耗不起。

我这次折腾的项目，就是为了解决这个痛点。它的核心是：让设备在部署后，能够通过一种便捷的方式，远程、无线地更新其需要连接的目标服务器IP和端口。我选择的方案是STM32F103 + EC800 4G模块的组合作为主控和通信核心，然后额外增加了一个ESP8266 WiFi模块作为“配置通道”。简单来说，平时设备用4G模块兢兢业业地干活、传数据；当需要修改服务器地址时，运维人员可以走到设备附近（比如在同一WiFi覆盖范围内），用手机或电脑连上ESP8266创建的热点，通过一个简单的网页界面，输入新的IP和端口，点击提交，就完成了配置的更新。整个流程，完全不需要物理接触设备。

这个方案的价值在于极大地提升了物联网设备后期运维的灵活性。无论是测试环境切换、服务器迁移，还是负载均衡导致的地址变更，都能快速响应。对于部署在偏远地区、高处或者密封机箱内的设备来说，这种“无线配置”的能力简直就是救星。下面，我就把整个实现过程，从硬件选型、通信协议设计到代码实现的坑与技巧，毫无保留地分享出来。

2. 硬件架构与核心模块选型解析

2.1 主控芯片：为什么是STM32F103C8T6？

在资源有限的嵌入式设备里做功能叠加，主控芯片的选型是第一道坎。我选择了经典的“蓝桥杯”核心板同款——STM32F103C8T6。原因很实在：

性价比与生态：作为ARM Cortex-M3内核的入门级芯片，它价格低廉，资料浩如烟海，社区支持极好。任何你遇到的问题，几乎都能找到中文论坛的讨论帖。对于这种功能明确、逻辑不算极端复杂的应用，它的性能绰绰有余。
串口资源：这是本项目最关键的外设需求。我们需要至少三个独立的UART（通用异步收发传输器）：
- UART1：用于连接ESP8266 WiFi模块，进行AT指令交互和接收配置数据。通常接PA9(TX)、PA10(RX)。
- UART2：用于连接EC800 4G模块，发送AT指令控制其联网、建立TCP连接等。通常接PA2(TX)、PA3(RX)。
- UART3：用于打印调试信息到PC，方便开发阶段观察日志。通常接PB10(TX)、PB11(RX)。 STM32F103C8T6正好有3个USART，完美匹配需求。如果选用UART资源更少的芯片，可能就需要用软件模拟串口，会增加CPU负担和代码复杂度。
Flash与RAM：64KB Flash，20KB RAM。我们的固件需要包含HTTP服务器解析（用于处理WiFi配置页面的请求）、JSON解析（用于解析配置数据）、以及两个模块的AT指令驱动。精心优化后，这个容量是足够的。但如果未来要加入更复杂的网页或协议，就需要选更大容量的型号，如F103CB或F103RC。

注意：STM32F103系列不同型号引脚可能不兼容，比如C8T6和RCT6的封装和资源差异很大。画原理图和打板前，务必在STM32CubeMX里确认好所选型号的引脚分配。

2.2 通信模块：EC800 4G与ESP8266的角色分工

这是本项目的双核心，它们各司其职，不能互相替代。

EC800 4G模块（移远通信）：这是设备的“正式通信通道”。它负责在设备部署现场，通过插入SIM卡，接入运营商网络（4G Cat.1），最终与公网上的目标服务器建立TCP或UDP连接，进行可靠的数据传输。它的特点是：

永远在线：只要供电正常、有信号，它就努力保持网络连接。
功耗相对较高：比2G/NB-IoT高，但比WiFi持续连接可能略低或持平，尤其在进行数据传输时。
依赖外部网络：需要SIM卡和运营商信号。

ESP8266 WiFi模块（乐鑫）：这是设备的“临时配置通道”。它只在需要配置时才被激活。它的角色是：

接入点模式（AP）：上电后，ESP8266启动并进入AP模式，创建一个WiFi热点（如Device_Config_XXXX）。
内置HTTP服务器：在热点内，ESP8266运行一个简单的Web服务器，提供配置页面。
串口桥接：用户通过网页提交配置后，ESP8266通过串口将配置信息发送给STM32。

按需工作，用完即走：配置完成后，STM32可以命令ESP8266进入深度睡眠，极大降低整体功耗。
配置便捷：用户无需知道设备的串口参数，只需用手机/电脑连上热点，打开浏览器即可操作。
不依赖外部网络：整个配置过程在设备自建的局域网内完成，即使设备所在位置完全没有运营商信号，也不影响配置。

为什么不直接用ESP8266连接远程服务器？这是一个关键问题。ESP8266本身具备STA模式，可以连接路由器上互联网。但在很多工业现场、户外设备中，并没有可用的WiFi网络。ESP8266的信号覆盖和穿透能力也远不如4G。因此，用4G模块作为主通道保证了通信的普遍性和可靠性，而ESP8266仅作为一个临时的、近距离的人机交互接口。

2.3 电路设计要点与避坑指南

硬件连接看起来简单，但细节决定成败。

电平匹配：STM32F103是3.3V供电，ESP8266和EC800模块的IO口电压通常也是3.3V（务必查阅具体型号的数据手册确认）。因此可以直接连接，无需电平转换芯片。
电源设计：这是最容易出问题的地方。
- 电流需求：EC800 4G模块在发射功率最大时，瞬时电流峰值可能超过2A。ESP8266在发射WiFi信号时，峰值电流也能达到300mA以上。STM32本身耗电很小。
- 电源方案：绝对不能用一个普通的LDO（如AMS1117-3.3）给整个系统供电，会瞬间压降导致复位。必须使用开关电源（DC-DC），例如MP1584EN、LM2596等，其持续输出电流能力需要在2A以上，并留有充足余量。输入电压根据你的整体供电设计来选择（如12V或5V）。
- 去耦电容：在每个模块的电源引脚附近，严格按照数据手册建议，放置足够容量的钽电容或电解电容（如100uF）进行储能，并搭配0.1uF的陶瓷电容滤除高频噪声。STM32的每个电源引脚也需要0.1uF的退耦电容。
串口连接：除了基本的TX、RX交叉连接，一定要连接GND，确保共地。对于EC800这类模块，通常还需要连接其复位引脚（RST）和开关机引脚（PWRKEY）到STM32的GPIO，以便MCU可以对其进行硬复位和开关机控制，这在模块死机时是救命的功能。
天线接口：EC800模块需要焊接4G天线，ESP8266需要焊接WiFi天线（板载PCB天线或外接天线）。天线周围要严格按照设计指南留出净空区，否则信号质量会大打折扣。

3. 软件逻辑与通信协议设计

3.1 系统状态机设计

整个设备的软件运行逻辑，用一个清晰的状态机来描述是最合适的。这能保证代码结构清晰，行为可预测。

typedef enum { SYS_STATE_INIT = 0, // 系统初始化 SYS_STATE_WIFI_CONFIG, // WiFi配置模式：启动ESP8266 AP，等待配置 SYS_STATE_4G_CONNECTING, // 4G连接中：配置EC800，附着网络，获取IP SYS_STATE_SERVER_CONNECTING, // 服务器连接中：根据配置的IP/端口建立TCP连接 SYS_STATE_RUNNING, // 运行状态：定时采集数据，并通过4G发送 SYS_STATE_ERROR, // 错误状态：某环节失败，等待恢复或重启 } SystemState_t;

上电后的流程：

系统进入SYS_STATE_INIT，初始化所有外设、GPIO、串口、定时器，读取Flash中保存的服务器配置（IP和端口）。
检查是否存在“配置触发信号”。这个信号可以是一个专用的按键，或者是我在代码里设置的一个“如果连续3次连接服务器失败，则自动进入配置模式”的逻辑。如果有触发信号，则进入SYS_STATE_WIFI_CONFIG。
如果没有触发信号，则直接使用Flash中的配置，进入SYS_STATE_4G_CONNECTING，开始连接4G网络和服务器。
在SYS_STATE_RUNNING状态下，设备正常作业。同时，STM32会持续监听UART1（连接ESP8266），如果收到特定的“进入配置模式”的串口指令（比如在网页上点击了“重新配置”按钮），则保存当前状态，跳转到SYS_STATE_WIFI_CONFIG。

3.2 STM32与ESP8266的交互协议

ESP8266在这里被塑造成一个“串口转WiFi配置服务器”的桥梁。交互需要双方约定好协议。

方案一：AT指令模式（推荐）这是最通用和灵活的方式。STM32将ESP8266视为一个标准的AT指令设备进行控制。

STM32发送：通过UART1发送AT指令，让ESP8266重启并进入AP模式：AT+CWMODE=2（设置为AP模式），然后AT+CWSAP="Device_Config","password",1,4（设置热点名和密码）。
STM32发送：启动ESP8266的多连接TCP服务器：AT+CIPMUX=1，然后AT+CIPSERVER=1,80（在80端口开启服务器）。
网页交互：用户连接热点，访问192.168.4.1，提交表单。ESP8266会通过串口，以特定格式将收到的HTTP POST请求数据透传给STM32。格式例如：+IPD,0,123:{"ip":"192.168.1.100","port":8080}。其中0是连接ID，123是数据长度，后面是HTTP Body。
STM32解析：STM32需要编写代码来解析这个字符串，提取出JSON格式的配置信息。解析成功后，STM32将新的IP和端口保存到Flash，然后通过AT指令AT+CIPSEND=0,xx向连接0发送一个HTTP 200 OK的响应网页，告知用户配置成功。最后发送AT+CIPCLOSE=0关闭连接，并可能发送AT+GSLP让ESP8266进入深度睡眠。

方案二：固件烧录模式你可以自己编写ESP8266的固件（使用Arduino或ESP-IDF），让它上电后自动执行上述步骤，并通过一个更精简的二进制协议与STM32通信。这可以减少STM32的代码解析复杂度，但增加了ESP8266侧的开发工作量。

实操心得：对于快速原型，强烈建议使用AT指令模式。乐鑫提供的AT固件非常稳定，而且有详尽的指令集文档。虽然STM32侧需要解析字符串稍微麻烦点，但避免了双固件开发的调试地狱。你可以利用strstr、sscanf等标准库函数来解析数据。

3.3 STM32与EC800 4G模块的交互

与EC800的交互是标准的AT指令流程，相对成熟。核心步骤包括：

模块初始化：发送AT测试，等待OK；发送ATE0关闭回显，让输出更清晰。
SIM卡与网络注册：发送AT+CPIN?查询SIM卡状态；发送AT+CREG?和AT+CGREG?查询网络注册状态，直到返回1或5（已注册）。
激活PDP上下文：发送AT+QIACT=1激活数据业务。成功后可以用AT+QIACT?查询获得的IP地址。
建立TCP连接：使用保存的服务器IP和端口，发送AT+QIOPEN=1,"TCP","192.168.1.100",8080,0,1。连接成功后，模块会返回+QIOPEN: 1,0。
发送数据：发送AT+QISEND=1,<length>，模块返回>提示符后，紧接着发送你的实际数据。数据发送完成后，模块会返回SEND OK。
接收数据：当服务器有数据下发时，EC800会通过串口发送+QIURC: "recv",1或类似格式的通知，随后你需要发送AT+QIRD=1,<len>来读取数据。

注意事项：EC800模块的AT指令集与常见的SIM800系列不同，务必使用移远官方提供的《EC800_AT_Commands_Manual》文档。重点注意其多路连接（QIOPEN）和数据收发（QISEND/QIRD）的指令格式。网络状态查询（CREG/CGREG）的响应格式也可能有差异。

3.4 配置数据的存储与管理

服务器IP和端口是核心配置，必须安全、可靠地存储。STM32F103C8T6内部Flash的最后一页（Page）通常被用来存储这些参数。

Flash扇区规划：查阅芯片手册，明确Flash的扇区大小。对于C8T6，主存储器容量64KB，每页1KB或2KB（不同型号有差异）。我们选择最后一个扇区（例如从0x0800F800开始）作为参数区。

数据结构定义：定义一个结构体来存放所有需要保存的参数。

typedef struct { char server_ip[16]; // 如 "192.168.1.100" uint16_t server_port; uint32_t crc32; // 校验值，防止数据损坏 } SystemConfig_t;

写入操作：Flash写入前必须先擦除整个扇区。使用HAL库的HAL_FLASHEx_Erase()和HAL_FLASH_Program()函数。关键点：计算结构体的CRC32校验码，并将其一并写入。写入完成后，最好再读出来验证一遍。
读取与验证：上电初始化时，从参数区地址读取数据到SystemConfig_t结构体变量中，重新计算CRC32，与存储的CRC32值比对。如果一致，说明数据有效；如果不一致，则使用默认的配置（例如一个测试服务器地址），并可能触发系统进入配置模式。

踩坑记录：Flash编程必须以**半字（16位）或字（32位）**为单位进行操作，并且地址必须对齐。直接对结构体指针进行memcpy式的写入是行不通的。必须将结构体中的每个uint32_t类型的成员（或转换为uint32_t的数组）单独调用HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, address, data)来写入。对于char数组，需要打包成32位字再写。

4. 关键代码实现与调试技巧

4.1 串口驱动与数据接收解析

三个串口都需要高效、可靠的非阻塞式接收。这里使用**DMA+空闲中断（Idle Interrupt）**的方式是业界最佳实践。

配置：在CubeMX中，为每个接收串口开启DMA（循环模式），并开启串口的空闲中断。
原理：DMA负责将接收到的数据自动搬运到指定的缓冲区，不占用CPU。当串口总线上一段时间没有新数据（产生空闲中断）时，意味着一个“数据包”接收完毕。

中断处理：

// 在stm32f1xx_it.c的USART1_IRQHandler中 void USART1_IRQHandler(void) { if(__HAL_UART_GET_FLAG(&huart1, UART_FLAG_IDLE) != RESET) { __HAL_UART_CLEAR_IDLE_FLAG(&huart1); // 清除空闲中断标志 HAL_UART_DMAStop(&huart1); // 暂停DMA，此时DMA_CNDTR寄存器保存了未传输的数据量 uint16_t recv_len = BUFFER_SIZE - __HAL_DMA_GET_COUNTER(&hdma_usart1_rx); // 计算已接收长度 // 调用处理函数，处理uart1_rx_buffer中长度为recv_len的数据 Process_UART1_Data(recv_len); // 重新设置DMA指针和计数器，准备下一次接收 HAL_UART_Receive_DMA(&huart1, uart1_rx_buffer, BUFFER_SIZE); } }

数据解析：在Process_UART1_Data函数中，你需要解析来自ESP8266的数据。由于是AT指令响应和HTTP数据透传，内容是多行的、文本格式的。你需要一个状态机来解析。例如，先判断是否包含+IPD前缀，如果是，则提取连接ID和数据长度，然后等待后续的JSON数据，并调用JSON解析器（如cJSON）或自己编写简单的字符串查找函数来提取ip和port字段。

调试技巧：在开发初期，务必先让STM32将所有从ESP8266和EC800收到的原始数据，通过第三个调试串口（UART3）打印到PC端的串口助手（如Putty、SecureCRT）。这能让你最直观地看到模块究竟返回了什么，是调试AT指令交互的利器。记得给打印的数据加上清晰的标签，如[ESP]<和[4G]<。

4.2 AT指令发送状态机

简单地用HAL_UART_Transmit发送一条AT指令然后死等回应是不可靠的。必须设计一个非阻塞的AT指令状态机。

指令队列：创建一个指令结构体数组作为队列。

typedef struct { char *cmd; // 指令字符串，如 "AT+CREG?\r\n" uint32_t timeout; // 等待回应的超时时间（ms） At_Resp_Handler handler; // 回应处理函数指针 } At_Cmd_t;

执行引擎：主循环中维护一个状态机。状态包括：AT_IDLE（空闲）、AT_SENDING（已发送指令）、AT_WAITING_RESP（等待回应/超时）、AT_PROCESSING_RESP（处理回应）。
流程：
- 从队列中取出一个指令，设置状态为AT_SENDING，通过串口发送。
- 转入AT_WAITING_RESP状态，启动一个定时器（用HAL_GetTick()）。
- 在串口接收中断中，将数据填入解析缓冲区。当收到完整的预期回应（如OK、ERROR或特定数据）或超时定时器触发，则退出AT_WAITING_RESP状态。
- 调用该指令对应的handler函数处理回应。根据处理结果（成功/失败），决定是发送下一条指令，还是重试当前指令，或是上报错误。
优势：这种结构使得MCU在等待模块回应时，可以处理其他任务（如扫描按键、闪烁LED指示灯），系统响应更灵敏。也便于实现指令的重试机制和超时错误处理。

4.3 简易HTTP服务器与JSON解析

在ESP8266的AT模式下，STM32需要处理一个最简单的HTTP POST请求。

HTTP请求解析：从+IPD透传的数据中，提取出HTTP Body。你需要找到\r\n\r\n（空行）之后的部分，那就是POST提交的表单数据或JSON数据。一个最简单的表单提交，Body可能是ip=192.168.1.100&port=8080。而更通用的做法是使用JSON，如{"ip":"192.168.1.100","port":8080}。

JSON解析：如果使用JSON，我强烈建议引入一个轻量级的解析库，如cJSON。虽然它会增加一些代码体积，但健壮性和便利性远超自己手写字符串解析。将cJSON的源文件（cJSON.c和cJSON.h）加入工程，在解析函数中：

#include "cJSON.h" void Parse_Config_Json(char *json_str) { cJSON *root = cJSON_Parse(json_str); if (root == NULL) { // 解析失败，可能是格式错误 return; } cJSON *ip_item = cJSON_GetObjectItem(root, "ip"); cJSON *port_item = cJSON_GetObjectItem(root, "port"); if (cJSON_IsString(ip_item) && cJSON_IsNumber(port_item)) { strncpy(config.server_ip, ip_item->valuestring, sizeof(config.server_ip)-1); config.server_port = port_item->valueint; Save_Config_To_Flash(); // 保存新配置 } cJSON_Delete(root); // 释放内存 }

HTTP响应：解析成功后，STM32需要命令ESP8266发送HTTP 200响应。你需要组装一个完整的HTTP响应头和数据。
```
char response[] = "HTTP/1.1 200 OK\r\n" "Content-Type: text/html\r\n" "Connection: close\r\n" "\r\n" "<html><body><h1>Configuration Saved!</h1></body></html>"; // 通过AT指令 AT+CIPSEND=0,strlen(response) 发送此响应
```
注意：响应头中的Content-Length可以精确计算，但为了简单，这里用了Connection: close，发送完数据后服务器会主动关闭连接。你也可以计算长度并发送Content-Length头。

5. 系统集成、测试与问题排查

5.1 分模块调试流程

不要试图一次性集成所有模块。务必遵循“分而治之”的原则。

第一步：调试STM32基础系统。让调试串口能打印日志，点亮一个LED，测试按键扫描。确保MCU本身工作正常。
第二步：单独调试ESP8266。用USB转TTL工具直接连接ESP8266，在PC上用串口助手发送AT指令，手动测试创建热点、开启服务器、连接热点并访问网页的全过程。记录下所有正确的指令和响应。
第三步：STM32驱动ESP8266。将ESP8266接回STM32，编写代码让STM32自动执行你手动测试成功的AT指令序列。通过调试串口观察交互过程，确保STM32能正确控制ESP8266进入AP模式并开启服务器。
第四步：实现配置网页与数据解析。编写一个简单的HTML配置页面（可以硬编码在STM32，作为字符串常量，通过ESP8266发送；或者更高级点，让ESP8266从Flash读取）。测试STM32能否正确接收并解析网页提交的数据。
第五步：单独调试EC800 4G模块。同样，先用USB转TTL手动测试，确保SIM卡正常，能注册网络、获取IP、连接一个已知的TCP测试服务器（如网络调试助手）。
第六步：STM32驱动EC800。编写代码实现4G模块的初始化、联网、TCP连接流程。使用Flash中存储的（或默认的）服务器地址进行测试。
第七步：系统联调。将两部分结合起来。先通过WiFi配置一个新的服务器地址，然后触发设备重启或状态切换，观察4G模块是否能用新地址成功连接。

5.2 典型问题与排查实录

在实际焊接和调试中，我遇到了不少问题，这里记录几个最有代表性的：

问题一：ESP8266热点手机搜不到，或者连接上却打不开192.168.4.1。

排查：
1. 电源：首先用万用表测量ESP8266的VCC引脚电压，在发射信号时是否跌落到3.0V以下？如果跌落严重，说明电源功率不足，需要检查DC-DC电路和储能电容。
2. 天线：检查天线是否焊接牢固？ESP8266模块的板载PCB天线区域下方有没有敷铜或走线？这会被坏阻抗匹配。确保天线下方是净空区。
3. AT指令：通过调试串口确认STM32发送的AT指令序列是否正确？ESP8266是否返回了OK？热点名称是否含有特殊字符？密码是否太短？指令AT+CWSAP的参数是否正确（通道号、加密方式）？
4. 服务器端口：确认开启服务器的指令是AT+CIPSERVER=1,80（端口80）。有些手机浏览器对非80端口访问有限制。

问题二：EC800模块无法注册网络，一直返回+CREG: 0,2（正在搜索）。

排查：
1. SIM卡：确认SIM卡已开通数据业务，且没有欠费。尝试将SIM卡插入手机，看能否正常上网。
2. 天线：4G天线是否接好？可以用手暂时触碰天线焊点，观察AT+CSQ查询的信号强度值是否有变化。没有天线或天线损坏，信号强度会非常差（如CSQ: 0或CSQ: 99）。
3. APN设置：有些物联网卡或特定运营商需要手动设置APN。发送指令AT+QICSGP=1,"3GNET","","",1（以中国移动为例）进行设置，然后再激活PDP上下文。
4. 模块版本：使用ATI和AT+CGMR查询模块型号和固件版本，核对是否支持当前区域的网络频段。

问题三：WiFi配置成功后，4G连接服务器失败。

排查：
1. 数据读取：首先在调试信息中，打印出刚从Flash读取出来的IP和端口，确认解析和存储过程无误，没有出现乱码或截断。
2. 网络可达性：这个新配置的服务器IP和端口，在公网是否真的可访问？可以先用电脑上的网络调试工具创建TCP服务器测试，或者使用AT+QPING指令（如果模块支持）进行ping测试。
3. 防火墙：目标服务器的防火墙是否放行了这个端口？很多云服务器需要手动在安全组规则中开启端口。
4. 指令时序：检查连接服务器的AT指令AT+QIOPEN是否在成功激活PDP上下文（AT+QIACT返回OK）之后才发送？网络附着和PDP激活是两个步骤，必须按顺序进行。

问题四：系统运行一段时间后死机。

排查：
1. 看门狗：务必启用STM32的独立看门狗（IWDG）或窗口看门狗（WWDG）。在main函数的while循环中定期喂狗。这能解决大部分因程序跑飞导致的死机。
2. 堆栈溢出：检查在串口中断、定时器中断回调函数中是否进行了耗时的操作或调用了可能阻塞的函数（如HAL_Delay）。中断服务函数应尽量简短。
3. 内存泄漏：如果使用了cJSON等动态分配内存的库，确保每次cJSON_Parse后，都有对应的cJSON_Delete。
4. 电源干扰：在设备接上真实传感器或执行器（如电机、继电器）测试时，开关瞬间可能会引入电源毛刺，导致MCU复位。检查电源电路的滤波和隔离是否做好。

5.3 功耗优化考虑

对于电池供电的设备，功耗至关重要。

ESP8266的睡眠：配置完成后，立即通过AT指令AT+GSLP=<time>让ESP8266进入深度睡眠。在睡眠模式下，其电流可降至20uA以下。需要唤醒时，通过STM32控制一个GPIO连接到ESP8266的RST或EN引脚，拉低再拉高实现硬件复位唤醒。
EC800的省电模式：查阅EC800手册，看是否支持AT+QSCLK等进入低功耗模式的指令。在数据发送间隔很长时，可以让4G模块进入睡眠，定期唤醒查询。但这通常需要服务器配合支持唤醒包，实现复杂。
STM32的低功耗模式：在数据采集间隔期，STM32可以进入Stop模式，此时大部分外设关闭，功耗极低。通过RTC定时器或外部中断（如按键）唤醒。进入Stop模式前，需要妥善配置好所有串口、GPIO的状态，避免漏电。

整个项目从构思到调试完成，花费了不少时间，但收获巨大。它不仅仅是一个功能的实现，更是一套针对物联网设备远程运维的实用解决方案。最大的体会是，嵌入式开发中，“先分后合”的调试策略和**“大胆假设，小心求证”的排查思路**无比重要。每一个模块都要先确保它能独立工作，再去考虑集成。遇到问题，从电源、时钟、接线这些最底层的地方查起，往往能事半功倍。最后，代码的模块化、状态机设计，以及详尽的日志输出，是后期调试和维护的最佳伴侣。希望这份详细的总结，能帮你绕过我踩过的那些坑。

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