AT 命令响应处理程序

Question

AT 命令通常会生成

OK

/

ERROR

响应

> AT\r
< \r\nOK\r\n

或两行响应，例如：

> AT+CIMI\r
< \r\n<IMSI>\r\n
< \r\nOK\r\n

在这两种情况下，当收到

OK

或

ERROR

时，主机中实现的响应处理程序都会检测响应的结束（通常是发送下一个 AT 命令的可能性）。

实际上我正在研究 SimCom 的 A7672E 4G 模块。它具有复杂且专有的 AT 命令，其响应是 2 行，但是......“反向”：

> AT+CNTP\r
< \r\nOK\r\n
...<delay>...
< \r\n+CNTP: 0\r\n

我认为第二行的延迟是由调制解调器在互联网上发出的真实 NTP 请求引起的（联系服务器并等待其答复）。因此调制解调器会立即回复

OK

，但需要一些时间才能发送最终结果。

我测试（即使使用示波器）调制解调器在

OK

之后再次真正可用于处理其他AT命令：

> AT+CNTP\r
< \r\nOK\r\n
> AT\r
< \r\nOK\r\n
...<delay>...
< \r\n+CNTP: 0\r\n

但是我不确定是否最好阻止响应处理程序，直到收到

+CNTP: <err>

消息（因此也阻止发送其他 AT 命令）或在

OK

之后立即解锁接收器，从而使应用程序可以发送同时执行其他命令。

Answer 1

我发现的第两个文档参考确实指定了对

AT+CNTP

的响应为

Response
OK
+CNTP: <code>

这意味着

+CNTP: ...

是一个未经请求的结果代码。 V.250 说：

5.7.1 回应

DCE 可能发出两种类型的响应：信息文本¹ 和结果代码。 ... 结果代码分为三种类型：最终代码、中间代码和主动代码。

中间出现在开始执行命令行和最终结果代码之间，而主动出现在最终结果代码和下一个命令行之间。

---

因此，为了回答您如何处理此问题的问题，我建议将其正确处理为未经请求的结果代码。如果您正在编写一些非常特殊用途的软件，在继续之前必须知道 ntp 结果是什么，您也许可以作为一种特殊情况，用等待这个未经请求的结果代码来替代等待最终结果代码，但我认为这是一种黑客行为与正常等待最终结果代码相比，并没有真正的好处，而是添加一个未经请求的结果处理程序来检查这一点。

---

¹（我的脚注）信息文本和中间结果代码之间的区别是模糊的，但出于实际目的，它们是相同的。