4. 无线模块驱动开发：AT指令集解析、模块初始化流程、数据收发API封装、错误处理机制

好，咱们进入第四章。前面几章我们把硬件连接、电源、时钟这些基础打牢了。这一章，才是真正跟无线模块“对话”的开始。

说白了，驱动开发就是让STM32学会用无线模块能听懂的语言去指挥它。大部分Wi-Fi、蓝牙、NB-IoT模块，都采用AT指令这种交互方式。你发一条“AT”，它回你“OK”，这就是最基础的握手。

4.1 AT指令集解析：模块的语言体系

AT指令，最早源于拨号调制解调器。现在无线模块把它继承了下来。每条指令以“AT”开头，以回车换行（\r\n）结束。模块收到后，会返回响应结果。

我个人习惯，拿到一个新模块，第一件事不是写代码，而是用USB转串口工具，在PC上通过串口助手手动敲几条AT指令，看看模块怎么回。这能帮你快速摸清模块的“脾气”。

4.1.1 指令分类与格式

举个例子，ESP8266模块设置Wi-Fi模式的指令：

AT+CWMODE=1          // 设置Station模式
响应：OK

AT+CWMODE?           // 查询当前模式
响应：+CWMODE:1
      OK

AT+CWMODE=?          // 查询支持的模式范围
响应：+CWMODE:(1-3)
      OK

嗯，这里要注意：模块返回的响应，有时会夹杂一些“URC”（Unsolicited Result Code），也就是模块主动上报的信息，比如Wi-Fi断连、收到数据等。你的解析代码必须能处理这种“意外”消息。

4.1.2 响应解析策略

我在项目中遇到过最头疼的问题，就是串口接收数据不完整。AT指令的响应是分帧的，但串口中断一次可能只收到几个字节。怎么办？

我的做法是：构建一个环形缓冲区 + 状态机解析器。

• 环形缓冲区：把串口中断收到的每个字节，依次存入缓冲区。
• 状态机：在主循环中，从缓冲区逐个取出字节，匹配“OK”、“ERROR”或“+...”等关键字。

核心代码片段：

// 简易AT响应状态机
typedef enum {
    AT_IDLE,
    AT_RECEIVING,
    AT_COMPLETE,
    AT_TIMEOUT
} AT_Status_t;

AT_Status_t AT_ParseResponse(uint8_t byte) {
    static uint8_t buffer[256];
    static uint16_t index = 0;
    
    buffer[index++] = byte;
    
    // 检查是否以 "\r\nOK\r\n" 结尾
    if (index >= 4 && 
        memcmp(&buffer[index-4], "\r\nOK\r\n", 4) == 0) {
        index = 0;
        return AT_COMPLETE;
    }
    
    // 检查是否以 "\r\nERROR\r\n" 结尾
    if (index >= 7 && 
        memcmp(&buffer[index-7], "\r\nERROR\r\n", 7) == 0) {
        index = 0;
        return AT_ERROR;
    }
    
    return AT_RECEIVING;
}

4.2 模块初始化流程：从冷启动到就绪

无线模块上电后，不会立刻就能用。它需要经历一个完整的初始化流程。我把它总结为“三步走”：

1. 硬件就绪：供电稳定、复位引脚拉高、等待模块启动完成（通常需要几百毫秒到几秒）。
2. AT握手：连续发送“AT\r\n”，直到收到“OK”。如果连续5次失败，判定模块异常。
3. 参数配置：设置工作模式、波特率、Wi-Fi账号密码、服务器地址等。

下面这张图，是我在实际项目中画的初始化状态机，你可以参考：

你想想看，如果模块还没启动完成，你就急着发AT指令，它肯定不理你。所以等待模块启动这一步，很多人会忽略，结果就是“为什么我的模块没反应？”

4.3 数据收发API封装：让上层调用更优雅

底层AT指令解析写好了，但你不能让应用层的同事去直接操作“AT+CIPSEND”这种字符串。你需要封装一套简洁的API。

我一般会设计这样几个接口：

// 模块初始化
int8_t WIFI_Init(void);

// 连接Wi-Fi热点
int8_t WIFI_Connect(const char *ssid, const char *password);

// 建立TCP连接
int8_t WIFI_TCPConnect(const char *host, uint16_t port);

// 发送数据
int8_t WIFI_Send(const uint8_t *data, uint16_t len);

// 接收数据（非阻塞）
int16_t WIFI_Recv(uint8_t *buffer, uint16_t max_len);

// 断开连接
int8_t WIFI_Disconnect(void);

每个函数内部，都封装了完整的AT指令拼装、发送、等待响应、解析结果的过程。返回值统一用int8_t，0表示成功，负数表示错误码。

举个例子，WIFI_Send的实现逻辑：

int8_t WIFI_Send(const uint8_t *data, uint16_t len) {
    char cmd[32];
    
    // 1. 发送AT+CIPSEND=len
    sprintf(cmd, "AT+CIPSEND=%d\r\n", len);
    UART_SendString(cmd);
    
    // 2. 等待模块返回 "> " 提示符
    if (AT_WaitPrompt(1000) != AT_OK) {
        return -1; // 发送超时
    }
    
    // 3. 发送实际数据
    UART_SendBytes(data, len);
    
    // 4. 等待 "SEND OK"
    if (AT_WaitResponse("SEND OK", 5000) == AT_OK) {
        return 0;
    } else {
        return -2; // 发送失败
    }
}

4.4 错误处理机制：让系统更健壮

无线通信，环境复杂，干扰多。模块随时可能掉线、丢包、死机。你的代码必须能优雅地处理这些异常。

我总结了一套“三级错误处理”策略：

嗯，这里有个关键点：不要无限重试。我曾经见过一个产品，模块掉线后，代码每隔10ms就发一次连接请求，结果模块没连上，反而把串口缓冲区塞满了，整个系统卡死。

正确的做法是：每次重试，间隔时间递增（退避策略）。比如第一次等100ms，第二次等200ms，第三次等400ms，直到最大间隔。

// 退避重试示例
int8_t AT_RetryCommand(const char *cmd, uint8_t max_retries) {
    uint32_t delay_ms = 100;
    
    for (uint8_t i = 0; i < max_retries; i++) {
        UART_SendString(cmd);
        
        if (AT_WaitResponse("OK", 1000) == AT_OK) {
            return 0; // 成功
        }
        
        // 退避等待
        HAL_Delay(delay_ms);
        delay_ms *= 2; // 指数退避
        if (delay_ms > 2000) delay_ms = 2000;
    }
    
    return -1; // 所有重试都失败
}

最后，别忘了处理模块的“URC”消息。比如ESP8266收到数据时，会主动上报：

+IPD,0,5:Hello

你的解析器必须能识别这种消息，把数据提取出来，放到接收队列里，然后通知应用层来取。这部分，我们会在后面的章节详细展开。

好，这一章的内容就是这些。AT指令解析、初始化流程、API封装、错误处理，这四个部分构成了无线模块驱动的骨架。把这套框架搭好，后面不管是换模块型号，还是加功能，都会轻松很多。