4. AT指令通信建立：AT指令的发送方式、串口通信参数设置、AT指令的同步与异步模式
好，咱们正式开始聊AT指令的通信建立。
说实话，很多新手拿到NB-IoT模块，第一件事就是往串口里丢AT指令。结果呢？要么没反应，要么返回一堆乱码。我当年也踩过这个坑，折腾了一下午才发现是波特率没对上。所以这一节，咱们把通信建立这件事彻底讲透。
4.1 AT指令的发送方式
AT指令说白了就是一套文本命令。你发一串字符，模块回你一串字符。就这么简单。
但发送方式上，有几种常见的套路：
- 手动发送：用串口助手，一条一条敲。调试阶段最常用。
- 程序发送：MCU通过UART接口，按协议逐条发送。产品阶段必须用。
- 批量发送：把多条指令拼在一起发，中间用换行隔开。有些模块支持，有些不支持。
我个人习惯，调试阶段先用串口助手摸清模块的脾气。等指令流程跑通了，再移植到MCU代码里。你想想看，如果直接在代码里调试，出了问题你都不知道是模块没响应，还是代码逻辑有bug。
4.2 串口通信参数设置
串口参数设置是通信建立的第一步，也是最容易出问题的一步。
NB-IoT模块的串口参数，通常出厂默认是：
| 参数 | 默认值 | 说明 |
|---|---|---|
| 波特率 | 9600 或 115200 | 不同模块默认值不同，建议查手册确认 |
| 数据位 | 8 | 几乎都是8位，别乱改 |
| 停止位 | 1 | 1位停止位最常用 |
| 校验位 | 无 | NB-IoT场景很少用校验位 |
| 流控制 | 无 | RTS/CTS基本不用 |
嗯，这里要注意。波特率这个参数，不同模块的默认值可能不一样。比如移远的BC95默认是9600，而中移的M5310默认是115200。我建议你拿到模块后，先按9600试一下，没反应再换115200。
为什么会这样？因为有些模块出厂固件版本不同，波特率设置也会变。我有个项目，同一批模块，一半是9600，一半是115200，查了半天才发现是批次问题。
4.3 AT指令的同步与异步模式
这个知识点，说白了就是「你发指令后，是等着模块回你，还是先去干别的事」。
同步模式：发一条指令，等模块返回结果，再发下一条。简单、可靠，但效率低。
异步模式：发完指令不等待，直接发下一条。模块返回的结果通过中断或回调处理。效率高，但代码复杂。
我个人的经验是：调试阶段用同步模式，产品阶段用异步模式。
举个例子，你要查询信号强度：
// 同步模式伪代码
send("AT+CSQ");
wait_for_response(); // 阻塞等待
parse_response(); // 解析结果
// 异步模式伪代码
send("AT+CSQ");
// 不等待，继续执行其他任务
// 当UART收到数据时，触发中断
// 在中断处理函数中解析结果
你想想看，如果产品里所有指令都用同步模式，那MCU大部分时间都在傻等。NB-IoT模块的响应时间有时能到几秒，这几秒MCU啥也干不了，太浪费了。
但异步模式也有坑。我记得有个项目，用了异步模式后，模块返回的数据老是解析错。查到最后发现是UART接收缓冲区太小，数据被截断了。所以用异步模式时，一定要把接收缓冲区设大一点，至少256字节起步。
- 同步模式：简单可靠，适合调试和指令数量少的场景
- 异步模式：高效灵活，适合产品化和多指令并发场景
- 实际项目中，我通常把两种模式混用：关键指令（如入网）用同步，非关键指令（如查询状态）用异步
最后说一句，不管用哪种模式，一定要处理好超时机制。模块有时候会死掉，或者信号不好导致响应延迟。我一般设3秒超时，超时后重试3次，还不行就复位模块。这个策略在我做过的项目里，基本没出过问题。