4、AT指令交互超时：串口缓冲区溢出、波特率不匹配、以及指令响应解析的常见错误

AT指令，说白了就是咱们和模组对话的“普通话”。

但这条通话线路，经常出问题。我见过太多工程师，代码逻辑天衣无缝，最后栽在AT指令交互上。不是没响应，就是响应乱码，要么就是卡死。

今天咱们就把这几个坑，一个一个填平。

4.1 串口缓冲区溢出：你发得太快，模组来不及吃

模组不是电脑，它的串口缓冲区很小。很多低功耗模组，硬件FIFO只有16字节或32字节。

你想想看，一条AT指令“AT+CGDCONT=1,\"IP\",\"CMNET\"\r\n”，算上回车换行，快40个字节了。如果你一口气全塞进去，模组还没消化完，后面的数据就直接丢了。

我遇到过最典型的场景：

• MCU主频高，串口发送用DMA，瞬间把几十条AT指令怼进模组。
• 模组还在处理上一条，下一条的头部已经被覆盖。
• 结果就是：模组返回“ERROR”，或者干脆不响应。

解决方案：

1. 指令间加延时：每条AT指令发送后，至少等待100ms再发下一条。如果模组处理慢（比如网络注册），建议200-500ms。
2. 使用流控：硬件流控（RTS/CTS）是最可靠的。模组告诉你“我忙，别发”，你就乖乖等着。
3. 分段发送：如果指令太长，可以拆成两段。比如先发“AT+CGDCONT=1,\"IP\"”，等返回OK，再发“,\"CMNET\"”。

// 错误示范：连发两条，无间隔
uart_send("AT+CSQ\r\n");
uart_send("AT+CREG?\r\n");

// 正确做法：等待响应后再发
uart_send("AT+CSQ\r\n");
delay_ms(200);  // 给模组喘息时间
if (wait_response("OK", 1000)) {
    uart_send("AT+CREG?\r\n");
}

4.2 波特率不匹配：鸡同鸭讲

这个错误太基础了，但恰恰是最容易忽略的。

模组默认波特率通常是115200或9600。但很多开发板或者MCU的串口时钟有误差，尤其是内部RC振荡器，误差可能达到2%-3%。

波特率一 mismatch，你收到的就是一堆乱码。嗯，这里要注意，乱码不一定是硬件坏了，先查波特率。

我个人的排查习惯：

• 先用逻辑分析仪抓一下MCU发送的波形，量一下实际波特率。
• 再用串口助手，手动敲AT指令，看模组能不能正常回显。
• 如果模组回显正常，说明模组没问题，问题在MCU的波特率配置。

解决方案：

1. 使用外部晶振：如果MCU支持，尽量用外部晶振驱动串口，精度更高。
2. 校准波特率：在MCU代码里，根据实际时钟频率计算波特率寄存器值，不要用默认库函数。
3. 降低波特率：如果环境干扰大，或者线缆长，降到9600或19200，稳定性会好很多。

4.3 指令响应解析的常见错误

AT指令的响应格式，其实挺灵活的。模组可能返回“OK”，也可能返回“\r\nOK\r\n”，还可能前面带个空行。

很多工程师写解析代码时，只匹配“OK”两个字，结果遇到带换行的就失败了。

我总结了几种常见的解析陷阱：

• 硬匹配字符串：用strstr找“OK”，但没考虑前后可能有空格或换行。
• 忽略超时：一直死等响应，模组死机了，你的程序也卡死了。
• 缓冲区残留：上一条指令的响应没读完，下一条指令的响应混在一起。
• URC干扰：模组主动上报的数据（如+CMTI: "SM",0）混在响应里，导致解析失败。

正确的解析思路：

1. 逐字节接收：用环形缓冲区接收串口数据，不要用固定数组。
2. 按行解析：以“\r\n”为分隔符，提取每一行。
3. 匹配关键词：对每一行，用strstr匹配“OK”、“ERROR”、“+CMTI:”等关键词。
4. 设置超时：每条指令等待响应的时间，建议500ms-5s，超时后主动放弃。

// 伪代码：AT指令响应解析框架
int at_send_cmd(const char *cmd, const char *expect, int timeout_ms) {
    uart_send(cmd);
    uint32_t start = get_tick();
    
    while (get_tick() - start < timeout_ms) {
        char ch = uart_recv_byte();  // 非阻塞接收
        if (ch != 0xFF) {            // 0xFF表示无数据
            ring_buf_push(ch);
            if (ch == '\n') {        // 收到一行结束
                char line[128];
                ring_buf_get_line(line);
                if (strstr(line, expect)) {
                    return 0;        // 匹配成功
                }
                if (strstr(line, "ERROR")) {
                    return -1;       // 明确错误
                }
            }
        }
    }
    return -2;  // 超时
}

4.4 知识体系：AT指令交互的完整链路

下面这张图，是我自己总结的AT指令交互全流程。每次排查问题，我都会对着它走一遍。

4.5 实战建议：一个健壮的AT指令交互框架

说了这么多问题，最后给一套我一直在用的框架思路。

1. 初始化阶段：先发“AT”测试，等待“OK”，确认波特率和串口通路正常。
2. 指令发送：每条指令后，等待模组返回“OK”或“ERROR”，再发下一条。
3. 超时机制：每条指令设置独立超时，超时后重试3次，仍失败则上报错误。
4. URC处理：单独开一个缓冲区存放URC数据，不干扰指令响应的解析。
5. 日志输出：把每次AT指令的收发都打印出来，方便调试。

AT指令交互，看似简单，但细节决定成败。把上面这几个坑填平了，你的模组通信就能稳定一大半。