在使用AT指令的时候,直接发送AT指令的一端称为客户端(AT Client),接收AT指令并返回响应的一端称为服务端(AT Server)。
ESP8266、M26、BC35-G这些通信模组都是接收我们发送的AT指令,所以称为AT命令服务端,MCU 需要向模组主动发送AT指令,称为AT客户端,它们之间的通信架构如下:
20200207120042758.png
为什么需要AT客户端框架
首先来看上图中的三个数据流:三条数据流都可以调用HAL库的API直接实现呀,为什么要设计一层AT框架呢?
      在直接调用HAL库实现的时候,首先无法保证每次模组向 MCU 发送的数据都能完整的被接收,所以,我们需要设计一层串口驱动以保证数据在任何时候都可以被完整的接收进缓冲区。  其次,在接收数据之后,难点在于对数据的处理,判断AT指令发送的数据是不是正常的返回结果,从返回结果中提取有效信息等等,这些如果每条指令接收之后,都去写代码依次判断,代码量陡增暂且不说,编程的难度也是直接上升,所以,我们需要基于串口驱动,在保证数据被完整接收的前提之上,再根据AT命令通信的特点,设计一层AT框架,专门负责解析数据,提取有效信息。
       发送AT指令:可以直接调用HAL库提供的API发送,AT框架并无太大作用;等待接收返回结果:可以直接调用HAL库的API使用中断方式接收;接收服务端主动发送的数据:可以直接调用HAL库的API使用中断方式接收;
总的来说框架分为三部分:
1. 初始化;
微信截图_20210320175119.png
2.发送;
微信截图_20210320175119.png
3.接收;
微信截图_20210320175346.png
有了这三大件,接下来的事情就是填坑了,需要什么,就填什么.
微信图片_20210320175529.png
我顺便用板子测试了几接口,都是很OK的。
测试效果如图:
微信图片_20210320175841.png
    微信图片_20210320175833.jpg
需要代码的朋友可以下载附件:
游客,如果您要查看本帖隐藏内容请回复