1

我即将实现一个适用于 GPRS 调制解调器（尤其是 SIM800L）的 PC 控制台程序。

我刚刚了解到由于 UCR（未经请求的结果代码）的出现而难以解析响应。

所以我用谷歌搜索了一下，发现了这篇文章：

https://embeddedfreak.wordpress.com/2008/08/19/handling-urc-unsolicited-result-code-in-hayes-at-command/

报价：

打开 ECHO (ATE1) 我见过的大多数应用程序示例都会关闭 ECHO（通过发送 ATE0）。原因未知，但他们中的大多数人都说减少串口通信（因此减少了解析器的工作量）。但这是不正确的。

如果您想建立强大的通信，您应该打开 ECHO。原因很简单，您可以检测调制解调器接收到的命令/URC 的顺序。这是上图的实际顺序（从调制解调器的回声看）：

application>AT+CMGL=4 # List all of SMS inside the ME
ME> OK # There's no SMS inside the ME
ME> RING # Incoming call
ME> RING # Incoming call

我很困惑。我想它应该可以工作，但前提是响应总是在相应命令之后进行。

但我找不到它的强项。AT 命令的描述和 SIM800L 数据表都没有包含该声明。

或者，也许我只是以错误的方式理解它？

4

1 回答 1

0

我想它应该可以工作，但前提是响应总是在相应命令之后进行。

是的。至少对于大多数 u-blox 蜂窝模块：

在 AT 命令接口繁忙的情况下，模块通过延迟 URC 的呈现来避免这种冲突。AT 命令接口可能在以下情况下处于忙碌状态：

• 在数据通话期间（数据模式）

• 在命令或在线命令模式下执行 AT 命令期间

当命令行由命令行终止字符完成并且模块中的AT解释器接受它时，命令执行开始；当命令的最终结果代码发出时，命令执行结束。在此期间，不允许模块发送未缓冲的 URC。对于大部分消息，都需要配置 DCE 是否发送 URC。启用后，对于大多数 URC，如果 AT 命令接口忙，则缓存未决的 URC，并延迟它们向 DCE 的发送。

https://www.u-blox.com/sites/default/files/u-blox-CEL_ATCommands_UBX-13002752.pdf

于 2021-08-31T15:13:54.777 回答