本帖最后由 我是土匪 于 2015-10-10 14:19 编辑
第二章 浅谈AT用法
一、 扔砖很多人都觉得AT很简单，一个字符串发过去，剩下就是喝茶等结果。 土匪今天再次小题大做，单独引出篇幅讲解AT。
首先，何为AT？ 本人觉得可以简单的认为:以AT开头的一个能够被模块识别的字符串。模块收到AT命令，会做解析并执行。
二、 开胃菜先看一段代码，很多人都会这样去做： SendString("AT+CSCS=\"UCS2\"\r\n"); delayms(100); SendString("AT+CMGS=19\r\n");
这样做合理吗？ 上述代码，从功能角度来讲没有问题，100mS等待时间足够了。 如果你是激活移动场景或者向服务器发数据，延时100ms够吗？这样的命令返回时间就不确定了，和网络环境关系很大。 AT返回值时间有长有短，也许三五秒，甚至三五分钟，因此用延时去等待是不合理的，各家模块的超时时间也不尽相同，况且这样等待程序结构也不好。
三、 上酒几点关于AT的建议如下： 1、 AT发过去，要等待返回值，要判断返回值。 很多人说数据发不成功，连接服务器失败，等等，如果逐条AT判断返回值，每个csae针对性的处理，就不会出无法掌控的意外情况。 比如激活移动场景，尚未等到返回结果，就执行数据连接业务，一定是出问题的。
2、 AT发送是有顺序的，前一条AT发送结束，等到返回值后再发下一条，否则容易出现串口不通等意外情况。甚至把模块搞死。
3、 不要忘记处理URC URC，指的是没有主动发送AT给模块，模块主动上报的信息， 比如开机：RDY 比如电话拨入：RING 常见的URC并不是很多，通过查阅AT命令手册可以查到全部的URC,对关心的URC要做分析和处理
如果在设备发起数据业务的时候出现了掉卡，这样数据业务永远无法建立，如果解析到掉卡主动上报的URC,事情就会变得主动了。 4、 如何解析AT返回值和URC 个人用串口的超时中断，通过字符串解析区分URC和判断AT返回内容。 5、 具体的AT参数和返回值的解析，请阅读AT手册，配合实际测试。
四、 伏笔综上所述： 有没有好的程序架构来发送AT？ 有没有好的程序架构来解析URC？ 有没有好的程序架构来解析AT返回值？ 这就是个人灵活发挥了，土匪整理一下代码，测试后上传和大家一起交流。
| 
楼主
