1. ESP8266 WiFi模块在STM32无人机系统中的通信架构设计

在四轴飞行器的嵌入式开发中，实现飞控主控与上位机（PC或移动终端）之间的实时、可靠通信，是调试、参数调优与状态监控的关键环节。本节聚焦于基于ESP8266 WiFi模块构建的双向透明传输通道，其核心目标并非替代复杂的物联网云平台，而是为开发者提供一个轻量、可控、可调试的本地局域网通信基础设施。该方案将ESP8266配置为TCP服务器，STM32F103作为数据中继节点，承担协议解析、数据路由与外设交互的职责。整个通信链路剥离了应用层业务逻辑，专注于建立一个“字节流管道”，使上位机发送的任意指令能被飞控准确接收并执行，同时飞控的状态数据也能无损回传。

ESP8266之所以成为本项目首选，源于其高度集成的硬件特性和成熟的软件生态。它内部集成了Tensilica L106 32位RISC处理器、完整的IEEE 802.11 b/g/n WiFi基带与MAC、TCP/IP协议栈（LwIP）、以及丰富的外设接口。这意味着开发者无需在MCU端实现复杂的网络协议，所有底层握手、分片、重传、校验均由模块自身完成。开发者仅需通过标准的AT指令集进行配置与控制，将精力集中于飞行控制算法与传感器数据处理等核心任务。这种“硬件协议栈”的设计范式，显著降低了嵌入式系统接入无线网络的技术门槛与开发周期。

1.1 通信模式选型：AP+STA混合模式的工程权衡

ESP8266支持三种基础工作模式：Station（STA）、Access Point（AP）与SoftAP+Station（即AP+STA）。在无人机调试场景下，选择AP+STA混合模式具有明确的工程优势。

• Station（STA）模式 ：模块作为客户端，主动连接至现有的家庭或实验室WiFi路由器。此模式下，无人机可接入广域网，理论上支持远程监控。但其缺陷在于依赖外部网络稳定性，且在调试初期，飞控尚未接入路由器时，无法建立通信，丧失了最基础的调试能力。
• Access Point（AP）模式 ：模块自身创建一个WiFi热点，PC或手机直接连接该热点。此模式完全独立于外部网络，部署简单，是快速验证通信功能的首选。然而，其缺点是通信范围受限，且当上位机切换网络时，连接会中断，影响调试连续性。
• SoftAP+Station（AP+STA）模式 ：这是本项目采用的模式。模块同时运行两个网络接口：一个作为AP供调试设备（如手机）直连；另一个作为STA连接至主路由器，为后续扩展（如OTA升级、云端日志上传）预留接口。对于当前调试需求，我们主要利用其AP功能，构建一个封闭、可控、低干扰的本地调试子网。该模式在不增加额外硬件成本的前提下，提供了最大的灵活性与向后兼容性。

1.2 TCP/IP协议栈的简化认知：聚焦应用层与传输层

对于嵌入式开发者而言，深入OSI七层模型的全部细节既非必要，亦不现实。本项目仅需掌握TCP/IP五层模型（物理层、数据链路层、网络层、传输层、应用层）中与通信直接相关的两层。

• 网络层（IP层） ：负责主机到主机的寻址与路由。ESP8266在成功连接WiFi后，会通过DHCP协议从路由器获取一个IPv4地址（例如 192.168.1.107 ）。这个地址是上位机访问无人机的唯一标识。开发者需确保PC与手机处于同一局域网段（如 192.168.1.x ），否则网络层无法完成ARP地址解析，通信将失败。
• 传输层（TCP层） ：负责进程到进程的可靠数据传输。本项目选用TCP协议而非UDP，因其提供面向连接、有序、无差错、不重复的数据流服务。这对于飞行控制指令至关重要——丢失一个PID参数更新包，可能导致飞行器失控。TCP的三次握手建立连接、滑动窗口流量控制、超时重传等机制，均由ESP8266内部的LwIP协议栈自动完成，对上位机与STM32而言完全透明。

应用层在此架构中被极度简化。上位机（Python脚本或Android App）仅需创建一个TCP Socket，连接至ESP8266的IP地址与指定端口，并发送/接收原始字节流。STM32端则无需理解任何HTTP、MQTT等高级协议，只需将UART接收到的字节原样转发至WiFi模块，反之亦然。这种“透明传输”（Transparent Transmission）的设计哲学，是嵌入式物联网开发中追求效率与稳定性的典型体现。

2. 硬件连接与USB-TTL转换方案

在实际开发中，绝大多数STM32最小系统板（如基于STM32F103C8T6或STM32F103ZET6的开发板）均未直接集成ESP8266模块。因此，必须构建一个可靠的硬件连接链路，将PC的USB接口、STM32的UART外设与ESP8266的串行接口三者有机整合。本节详细阐述两种主流方案，并分析其适用场景与工程取舍。

2.1 方案一：专用USB-TTL转换器（推荐用于生产与调试）

这是最标准、最可靠的连接方式。使用一款成熟的CH340G或CP2102 USB-TTL转换器，其引出标准的 VCC 、 GND 、 TXD 、 RXD 四线。

• 连接拓扑 ：
• PC USB口 → USB-TTL转换器（ VCC , GND , TXD , RXD ）
• USB-TTL转换器 TXD → ESP8266 RXD
• USB-TTL转换器 RXD → ESP8266 TXD
• USB-TTL转换器 GND → ESP8266 GND
• （可选）USB-TTL转换器 VCC → ESP8266 VCC （若转换器支持3.3V输出且电流足够）

此方案的优点在于信号完整性高、隔离性好、驱动成熟、即插即用。开发者可直接使用串口调试助手（如Hercules、SSCOM）向ESP8266发送AT指令，进行初始配置，无需编写任何MCU固件。它适用于模块的首次烧录、固件升级及底层通信故障排查，是工程师的“黄金标准”。

2.2 方案二：STM32最小系统板作为USB-TTL中继（本项目采用）

当手头缺乏专用转换器，或希望将调试过程与飞控固件开发深度耦合时，可将STM32开发板“虚拟化”为一个USB-TTL桥接器。此方案充分利用了开发板上已有的USB转串口芯片（通常是CH340G）和一个空闲的UART外设（如USART2）。

• 硬件连接 ：
• PC USB口 → STM32开发板（通过板载CH340G，映射为 USART1 ）
• STM32 USART2_TX → ESP8266 RXD
• STM32 USART2_RX → ESP8266 TXD
• STM32 GND → ESP8266 GND

• （注意）ESP8266 VCC 必须由外部3.3V电源（如开发板的3.3V稳压输出）独立供电，因其峰值电流可达500mA，远超USB-TTL芯片的供电能力。

• 关键电气特性 ：

• ESP8266是纯3.3V器件，其 TXD 与 RXD 引脚电平为3.3V CMOS，严禁直接连接5V TTL电平，否则将永久损坏模块。
• STM32F103的UART引脚默认为5V tolerant，可安全接收3.3V信号，但其输出为3.3V，与ESP8266完全兼容。
• 所有连接必须共地（GND），这是串行通信稳定的物理基础。

此方案的工程价值在于：它迫使开发者深入理解UART的底层驱动与中断处理，为后续在飞控固件中集成WiFi通信功能奠定了坚实基础。你所编写的每一行中继代码，都是未来 wifi_send_command() 函数的雏形。

3. STM32固件实现：双UART中继引擎

将STM32F103配置为一个高效的UART-to-UART数据中继器，是本项目的核心固件任务。其本质是一个无状态的“管道”，在 USART1 （连接PC）与 USART2 （连接ESP8266）之间，实现字节流的零拷贝、低延迟转发。以下代码基于HAL库实现，严格遵循嵌入式实时系统的最佳实践。

3.1 硬件抽象层（HAL）初始化

// 在MX_GPIO_Init()中，配置USART1与USART2的TX/RX引脚为复用推挽输出
// 例如：USART1_TX -> PA9, USART1_RX -> PA10; USART2_TX -> PA2, USART2_RX -> PA3

// 在MX_USART1_UART_Init()中
huart1.Instance = USART1;
huart1.Init.BaudRate = 115200;          // 标准波特率，与PC端一致
huart1.Init.WordLength = UART_WORDLENGTH_8B;
huart1.Init.StopBits = UART_STOPBITS_1;
huart1.Init.Parity = UART_PARITY_NONE;
huart1.Init.Mode = UART_MODE_TX_RX;
huart1.Init.HwFlowCtl = UART_HWCONTROL_NONE;
huart1.Init.OverSampling = UART_OVERSAMPLING_16;
// 此处必须启用中断，以实现非阻塞接收
if (HAL_UART_Init(&huart1) != HAL_OK) { Error_Handler(); }
HAL_UART_Receive_IT(&huart1, &uart1_rx_byte, 1); // 启动单字节中断接收

// 在MX_USART2_UART_Init()中
huart2.Instance = USART2;
huart2.Init.BaudRate = 115200;          // 必须与ESP8266的AT指令波特率严格一致
huart2.Init.WordLength = UART_WORDLENGTH_8B;
huart2.Init.StopBits = UART_STOPBITS_1;
huart2.Init.Parity = UART_PARITY_NONE;
huart2.Init.Mode = UART_MODE_TX_RX;
huart2.Init.HwFlowCtl = UART_HWCONTROL_NONE;
huart2.Init.OverSampling = UART_OVERSAMPLING_16;
if (HAL_UART_Init(&huart2) != HAL_OK) { Error_Handler(); }
HAL_UART_Receive_IT(&huart2, &uart2_rx_byte, 1);

关键点解析 ：
- 波特率一致性 ： USART1 与 USART2 的波特率必须均为 115200 。这是ESP8266出厂默认的AT指令波特率，也是Windows/Linux串口工具的常用设置。任何偏差都将导致通信失败。
- 中断驱动接收 ： HAL_UART_Receive_IT() 启动中断接收模式，避免了轮询（Polling）带来的CPU资源浪费与响应延迟。每个字节到达时，硬件自动触发中断，进入 USARTx_IRQHandler 。
- 单字节接收 ： HAL_UART_Receive_IT(&huartx, &rx_byte, 1) 是最高效的方式。它只申请一个字节的缓冲区，一旦数据到达，立即触发中断，处理完后立刻重新开启下一次单字节接收。这保证了极低的接收延迟（通常<100us）。

3.2 中断服务程序（ISR）与环形缓冲区管理

// 全局变量定义（位于main.c顶部）
uint8_t uart1_rx_byte;
uint8_t uart2_rx_byte;
#define RX_BUFFER_SIZE 256
uint8_t uart1_rx_buffer[RX_BUFFER_SIZE];
uint16_t uart1_rx_head = 0;
uint16_t uart1_rx_tail = 0;
uint8_t uart2_rx_buffer[RX_BUFFER_SIZE];
uint16_t uart2_rx_head = 0;
uint16_t uart2_rx_tail = 0;

// USART1中断服务函数
void USART1_IRQHandler(void)
{
    HAL_UART_IRQHandler(&huart1);
}

// USART2中断服务函数
void USART2_IRQHandler(void)
{
    HAL_UART_IRQHandler(&huart2);
}

// HAL库回调函数：当USART1接收到一个字节时调用
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
    if (huart->Instance == USART1) {
        // 将接收到的字节存入环形缓冲区
        uint16_t next_head = (uart1_rx_head + 1) % RX_BUFFER_SIZE;
        if (next_head != uart1_rx_tail) { // 检查缓冲区是否已满
            uart1_rx_buffer[uart1_rx_head] = uart1_rx_byte;
            uart1_rx_head = next_head;
        }
        // 立即重新启动下一次单字节接收
        HAL_UART_Receive_IT(&huart1, &uart1_rx_byte, 1);
    } else if (huart->Instance == USART2) {
        uint16_t next_head = (uart2_rx_head + 1) % RX_BUFFER_SIZE;
        if (next_head != uart2_rx_tail) {
            uart2_rx_buffer[uart2_rx_head] = uart2_rx_byte;
            uart2_rx_head = next_head;
        }
        HAL_UART_Receive_IT(&huart2, &uart2_rx_byte, 1);
    }
}

关键点解析 ：
- 环形缓冲区（Ring Buffer） ：这是嵌入式系统处理异步数据流的标准模式。它使用一个固定大小的数组和两个指针（ head 与 tail ）来模拟一个首尾相连的队列。 head 指向下一个写入位置， tail 指向下一个读取位置。当 head == tail 时，缓冲区为空；当 (head + 1) % SIZE == tail 时，缓冲区为满。这种结构避免了内存动态分配，且读写操作均为O(1)时间复杂度。
- 缓冲区大小权衡 ： 256 字节是一个经验性选择。它足以应对大多数AT指令响应（通常<100字节）和短消息，又不会过度消耗宝贵的SRAM（STM32F103C8T6仅有20KB）。过小的缓冲区会导致数据溢出丢失；过大的缓冲区则挤占其他关键任务的内存空间。
- 中断内处理原则 ：ISR中只做最轻量级的工作——将字节存入缓冲区并重启接收。所有耗时的数据解析、命令匹配、转发逻辑，都必须在主循环（ while(1) ）中完成。这是保证中断响应实时性的铁律。

3.3 主循环中的数据转发逻辑

int main(void)
{
    HAL_Init();
    SystemClock_Config();
    MX_GPIO_Init();
    MX_USART1_UART_Init();
    MX_USART2_UART_Init();

    // 主循环
    while (1)
    {
        // 1. 检查USART1（PC）是否有新数据，并转发给USART2（ESP8266）
        if (uart1_rx_head != uart1_rx_tail) {
            uint8_t data = uart1_rx_buffer[uart1_rx_tail];
            uart1_rx_tail = (uart1_rx_tail + 1) % RX_BUFFER_SIZE;
            // 使用阻塞发送，因数据量小，且ESP8266接收能力远强于PC发送速度
            HAL_UART_Transmit(&huart2, &data, 1, HAL_MAX_DELAY);
        }

        // 2. 检查USART2（ESP8266）是否有新数据，并转发给USART1（PC）
        if (uart2_rx_head != uart2_rx_tail) {
            uint8_t data = uart2_rx_buffer[uart2_rx_tail];
            uart2_rx_tail = (uart2_rx_tail + 1) % RX_BUFFER_SIZE;
            HAL_UART_Transmit(&huart1, &data, 1, HAL_MAX_DELAY);
        }

        // 3. 可在此处添加其他飞控任务，如传感器读取、PID计算等
        // ...
    }
}

关键点解析 ：
- 非阻塞与阻塞的混合使用 ：接收使用中断（非阻塞），发送使用 HAL_UART_Transmit() （阻塞）。这是因为UART发送本质上是一个“慢速”操作（受波特率限制），而 HAL_MAX_DELAY 参数确保了发送完成前不会返回，从而避免了在发送中途被其他中断打断导致数据错乱的风险。对于115200波特率，发送一个字节耗时约87us，对实时性影响微乎其微。
- 严格的顺序执行 ：主循环中，先处理PC→ESP8266的下行链路，再处理ESP8266→PC的上行链路。这种确定性的顺序，是系统行为可预测的基础。若采用多任务（FreeRTOS），则需为每个方向分配独立的任务，并通过队列（Queue）进行同步。
- 零逻辑开销 ：该中继引擎不解析任何AT指令，不关心数据内容。它只是一个纯粹的字节搬运工。这种设计最大限度地降低了固件复杂度，提升了可靠性与可维护性。

4. ESP8266 AT指令配置详解

ESP8266的AT固件提供了丰富且标准化的指令集，用于配置其WiFi与TCP/IP功能。本节仅列出调试无人机所必需的核心指令，并深入解释其参数含义与工程考量。

4.1 基础配置与WiFi连接

AT指令	功能	参数说明	工程要点
AT	测试指令，检查模块是否在线及串口通信是否正常	无	返回 OK 表示模块已上电且串口链路通畅。这是所有配置的第一步。
AT+GMR	查询固件版本信息	无	返回类似 "0018000902-AI03" 的字符串。不同版本的AT固件在指令支持上可能有细微差异，建议记录此信息以便查阅对应手册。
AT+CWMODE=2	设置WiFi工作模式为AP模式	2 =SoftAP模式	这是本项目的核心指令。执行后，ESP8266将创建一个名为 ESP_XXXXXX 的WiFi热点，密码为 12345678 。PC或手机可直接搜索并连接此热点。
AT+CWSAP="MyDrone","12345678",5,4	配置AP热点参数	"MyDrone" =SSID名； "12345678" =密码； 5 =信道（1-13）； 4 =加密方式（0=OPEN, 4=WPA_WPA2_PSK）	信道 5 是2.4GHz频段的中间信道，干扰相对较小。WPA2加密是当前最安全的选择，必须与密码长度匹配（8-63个字符）。
AT+CIFSR	查询IP地址	无	最关键指令之一 。执行后返回 +CIFSR:APIP,"192.168.4.1" 和 +CIFSR:APMAC,"xx:xx:xx:xx:xx:xx" 。其中 192.168.4.1 即为ESP8266在AP模式下的默认IP地址，上位机必须连接其热点后，才能通过此IP与其通信。

4.2 TCP服务器配置与启动

AT指令	功能	参数说明	工程要点
AT+CIPMUX=1	启用多连接模式	1 =启用； 0 =单连接	必须首先执行 。无人机调试中，PC与手机可能同时连接， CIPMUX=1 允许ESP8266同时管理多个TCP客户端连接，是实现多终端调试的前提。
AT+CIPSERVER=1,21567	创建TCP服务器	1 =启动； 21567 =监听端口号	端口号 21567 的选择是经过深思熟虑的。 0-1023 为知名端口（如HTTP=80）， 1024-49151 为注册端口， 49152-65535 为动态/私有端口。 21567 位于注册端口范围内，避开了常见服务的冲突，且足够靠后，降低了被防火墙误拦截的概率。
AT+CIPSTO=0	设置TCP服务器超时	0 =永不超时	对于调试会话，连接应保持稳定。设置为 0 可防止因短暂网络抖动导致连接意外断开，提升调试体验。

4.3 配置验证与故障排查

执行完上述指令后，可通过以下指令验证配置是否生效：

• AT+CWLAP ：扫描周围WiFi信号。在AP模式下，此指令通常返回空列表，因为模块自身并未作为STA扫描，而是作为AP广播。
• AT+CWLIF ：查询当前连接到本AP的客户端列表。当PC或手机成功连接热点后，执行此指令，将返回类似 "192.168.4.2,xx:xx:xx:xx:xx:xx" 的条目，其中 192.168.4.2 即为客户端的IP地址。
• AT+CIPSTATUS ：查询TCP连接状态。在服务器启动后，它会显示 STATUS:2 （ TCP SERVER ）；当有客户端连接时，状态变为 STATUS:3 （ TCP CONNECTED ），并显示连接ID（如 0 ）。

常见故障与解决 ：
- 指令无响应 ：首先检查串口波特率是否为 115200 ；其次检查 VCC 与 GND 是否连接牢固；最后确认 CH_PD 引脚是否被拉高（通常通过10kΩ电阻接 VCC ）。
- CIFSR 返回 0.0.0.0 ：表明AP模式未正确启动。请重新执行 AT+CWMODE=2 和 AT+CWSAP ，并确保模块已上电至少1秒。
- 客户端无法连接服务器 ：检查客户端IP是否与ESP8266在同一网段（ 192.168.4.x ）；检查防火墙是否阻止了 21567 端口；使用 AT+CIPSTATUS 确认服务器确已启动（ STATUS:2 ）。

5. 上位机通信客户端开发

上位机客户端是开发者与无人机交互的“手柄”。本项目提供了两种客户端：一个基于Python的跨平台命令行工具（用于PC），一个基于Java/Kotlin的Android图形界面APP（用于手机）。二者共享相同的核心通信逻辑，仅在UI层存在差异。

5.1 Python TCP客户端（pc_client.py）

import socket
import sys

# 配置参数
HOST = '192.168.4.1'  # ESP8266 AP的IP地址
PORT = 21567           # TCP服务器端口
BUFFER_SIZE = 1024

def main():
    # 创建TCP Socket
    client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

    try:
        # 连接到ESP8266服务器
        client_socket.connect((HOST, PORT))
        print(f"[INFO] Connected to {HOST}:{PORT}")

        while True:
            # 提示用户输入消息
            message = input("Enter message (or 'quit' to exit): ")

            # 如果输入'quit'，则退出循环
            if message.lower() == 'quit':
                break

            # 发送消息，以'\r\n'结尾，符合AT指令规范
            client_socket.sendall((message + '\r\n').encode('utf-8'))

            # 接收服务器响应
            response = client_socket.recv(BUFFER_SIZE)
            if response:
                print(f"[RECV] {response.decode('utf-8', errors='ignore')}")
            else:
                print("[INFO] Server closed the connection.")
                break

    except ConnectionRefusedError:
        print("[ERROR] Connection refused. Is the ESP8266 server running?")
    except socket.timeout:
        print("[ERROR] Connection timed out.")
    except Exception as e:
        print(f"[ERROR] An error occurred: {e}")
    finally:
        client_socket.close()
        print("[INFO] Connection closed.")

if __name__ == "__main__":
    main()

关键点解析 ：
- \r\n 行尾约定 ：这是AT指令协议的基石。ESP8266固件将 \r\n 视为一条完整指令的结束标志。Python客户端严格遵守此约定，在每条消息后追加 \r\n ，确保STM32固件能正确识别消息边界。
- 错误处理健壮性 ：代码包含了对 ConnectionRefusedError （服务器未启动）、 socket.timeout （网络超时）等常见异常的捕获，提升了客户端的鲁棒性与用户体验。
- 编码与解码 ：使用 utf-8 编码发送，并在接收时使用 errors='ignore' 参数，可优雅地处理可能存在的非UTF-8字节（如二进制传感器数据），避免程序崩溃。

5.2 Android APP通信逻辑（Kotlin片段）

在Android端，通信逻辑封装在一个 WifiClientService 中，使用 AsyncTask 或 Coroutine 在后台线程执行，以避免阻塞UI主线程。

class WifiClientService(private val context: Context) {
    private var socket: Socket? = null
    private var reader: BufferedReader? = null
    private var writer: BufferedWriter? = null

    fun connect(host: String, port: Int) {
        Thread {
            try {
                socket = Socket(host, port)
                reader = BufferedReader(InputStreamReader(socket!!.getInputStream()))
                writer = BufferedWriter(OutputStreamWriter(socket!!.getOutputStream()))

                // 通知UI连接成功
                (context as MainActivity).runOnUiThread {
                    it.updateConnectionStatus(true)
                }
            } catch (e: Exception) {
                Log.e("WifiClient", "Connect failed", e)
                (context as MainActivity).runOnUiThread {
                    it.showToast("Connect failed: ${e.message}")
                }
            }
        }.start()
    }

    fun sendMessage(message: String) {
        Thread {
            try {
                // 同样以\r\n结尾
                writer?.write("$message\r\n")
                writer?.flush()
            } catch (e: Exception) {
                Log.e("WifiClient", "Send failed", e)
            }
        }.start()
    }

    fun disconnect() {
        writer?.close()
        reader?.close()
        socket?.close()
    }
}

关键点解析 ：
- 后台线程执行 ：所有网络I/O操作都在 Thread 中进行，这是Android开发的强制要求。在主线程中执行网络操作会触发 NetworkOnMainThreadException 异常。
- 生命周期管理 ： disconnect() 方法至关重要，必须在Activity销毁（如用户按返回键）时被调用，以释放Socket资源，防止内存泄漏与端口占用。
- UI线程回调 ： runOnUiThread 确保了对UI组件（如 TextView 、 Button ）的更新操作始终在主线程中执行，这是Android UI框架的安全要求。

6. 实际调试经验与性能优化

在将上述方案应用于真实的STM32四轴飞行器项目时，我遇到了几个典型的、教科书上不会提及的“坑”，这些经验对保证项目顺利推进至关重要。

6.1 电源噪声与通信稳定性

ESP8266在WiFi发射瞬间会产生高达500mA的峰值电流，这会在3.3V电源线上造成剧烈的电压跌落（ Vcc sag ）。如果STM32与ESP8266共用同一块LDO（如AMS1117-3.3），这个跌落会传导至STM32的VDD，导致其内部PLL失锁、UART时钟抖动，最终表现为串口通信丢包、乱码，甚至MCU复位。

解决方案 ：
- 为ESP8266配备独立的、大容量的滤波电容（ 100uF 电解电容 + 100nF 陶瓷电容）紧贴其 VCC 与 GND 引脚。
- 在STM32与ESP8266的电源路径之间，加入一个 10Ω 的磁珠（Ferrite Bead），形成LC滤波器，有效隔离两者间的电源噪声耦合。
- 在PCB布局时，确保ESP8266的电源走线宽而短，并拥有独立的、大面积的GND覆铜。

6.2 UART中断优先级与飞控实时性

在飞控固件中， USART1 与 USART2 的中断优先级必须被仔细设置。若将其优先级设置得过高（如 NVIC_IRQChannelPreemptionPriority = 0 ），则频繁的UART中断会严重抢占 TIM1 （用于PWM输出）和 TIM2 （用于IMU数据采集）的中断服务，导致电机PWM波形畸变、姿态解算频率下降，最终引发飞行器抖动甚至失控。

解决方案 ：
- 在 HAL_NVIC_SetPriority() 中，将 USART1_IRQn 与 USART2_IRQn 的抢占优先级（Preemption Priority）设置为 3 （假设总共有4级），低于 TIM1_UP_IRQn （ 0 ）和 TIM2_IRQn （ 1 ）。
- 采用DMA（Direct Memory Access）替代中断进行大数据量接收。虽然本项目中继数据量小，但在未来需要传输高清图像或大量传感器日志时，DMA是唯一可行的方案。

6.3 调试技巧：利用中继固件进行协议嗅探

本项目中继固件的最大价值，不仅在于转发，更在于其“可见性”。当上位机与ESP8266通信出现异常时，你可以将PC串口助手连接到 USART1 ，然后在 USART2 的TX/RX线上并联一个逻辑分析仪。这样，你就能同时看到：
- PC发送给STM32的原始指令（在 USART1 上）。
- STM32转发给ESP8266的指令（在 USART2 上）。
- ESP8266返回给STM32的响应（在 USART2 上）。
- STM32回传给PC的响应（在 USART1 上）。

这种端到端的全链路可视性，是定位通信故障（如指令格式错误、响应超时、数据截断）的终极利器。我曾用此方法，仅用5分钟就定位到一个因Android App未正确发送 \r\n 而导致ESP8266一直等待指令结束的Bug。

在实际项目中，我最终将这套WiFi通信模块集成到了飞控的主循环中，使其不再仅仅是一个调试工具，而是成为了飞行器的一部分。当遥控器信号丢失时，飞控会自动切换到WiFi遥控模式；当电池电量低于阈值时，它会通过WiFi向手机APP推送警报。这套看似简单的“透明传输”管道，最终演变成了一个功能完备的、可扩展的无线交互平台。