Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to use the serial port module in MCU to interact". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to use the serial port module in MCU to interact.

1. AT client Framework what is an AT client

When using the AT instruction, the end that sends the AT instruction directly is called the AT Client, and the end that receives the AT instruction and returns the response is called the AT Server.

Communication modules such as ESP8266, M26 and BC35-G receive the AT instructions sent by us, so they are called AT command server. MCU needs to actively send AT instructions to the module, called AT client. The communication architecture between them is as follows:

Why do you need an AT client framework

First, take a look at the three data streams in the figure above:

Send AT instruction: you can directly call the API provided by the HAL library to send, but the AT framework is not very useful.

Wait for the result to be received: you can directly call the API of the HAL library to receive it by interrupt.

Receive the data sent actively by the server: you can directly call the API of the HAL library to receive it by interrupt.

All three data streams can be directly implemented by calling the API of the HAL library, so why design an AT framework?

When directly calling the HAL library implementation, there is no guarantee that the data sent by the module to MCU can be received completely. therefore, we need to design a serial port driver to ensure that the data can be fully received into the buffer at any time.

Secondly, after receiving the data, the difficulty lies in the processing of the data, judging whether the data sent by the AT instruction is a normal return result, extracting valid information from the return result, and so on. If each instruction is received, the code is written in turn, not to mention the sudden increase in the amount of code, the difficulty of programming also increases directly, so we need to be based on serial port driver. On the premise of ensuring that the data is received completely, and then according to the characteristics of AT command communication, an AT framework is designed, which is specially responsible for parsing data and extracting effective information.

two。 Analysis of the implementation of Serial Port driver Framework

The serial port driver is directly implemented using the driver framework provided by LiteOS. Because of its particularity, the lowest driver framework implementation file is placed in the project directory, and the API implementation provided by the HAL library is called:

In the uart_at.c file, two main functions are completed:

Serial port initialization

Realize the reading and writing of the serial port driver framework, and register the serial port device to the system

2.1. Serial port initialization

The calling architecture of the serial initialization function is shown in the figure:

LPUART1 is initialized by default. If you use other serial ports as serial ports of AT instructions, you can modify these two lines of code:

2.2. Ring_buffer

Ring_buffer is a specially implemented buffer for users to store received data. Users only need to call read and write operation buffers. The implementation file is located in the IoT_LINK_1.0.0\ iot_link\ link_misc path of iot-link SDK:

Ring_buffer is called in the serial initialization function to initialize:

The buffer size is declared in the macro definition:

After initialization, the interrupt service function registered with LiteOS only needs to call ring_buffer_write to continuously write the received data to the buffer to ensure that the serial port data is fully received.

2.3. Implementation of Serial Port driver Framework

In the serial port driver framework, because you already have the initialization function, you only need to implement the read function and the write function. The function architecture is as follows:

Because all the data is stored in ring_buffer, the serial port-driven read API implementation can be implemented with the read function provided by the buffer.

After implementing the read and write functions, you can register the device and driver with the system by calling the following macro definition:

OSDRIV_EXPORT (uart_at_driv,CONFIG_AT_DEVICENAME, (los_driv_op_t *) & Null Magic Olympiad DWR)

CONFIG_AT_DEVICENAME is specified by the user and is not repeated. It will be explained later in the iot_link_config.h file.

3. Analysis of AT client Framework

The source code for the implementation of the AT client framework is under the IoT_LINK_1.0.0\ iot_link\ at folder of SDK:

The AT framework is structured as follows:

As shown in the figure, because the serial port device has been registered in the system, the underlying send and receive functions of the AT framework directly call the API implementation provided by the LiteOS device driver framework. In addition to these in the above figure, it also involves a large number of codes that use semaphore, mutex, string comparison and other functions to match AT instructions and extract the results, which is not the focus of understanding the AT framework, so it is not given in the figure.

After the implementation of the AT framework, there are only three interfaces left for users to use to complete the interaction of AT instructions, which is very concise:

At_init: initialize the AT framework and start the AT data receiving engine (priority 10)

At_command: sends an AT instruction and matches the specified return result

At_oobregister: monitor the data actively reported by AT

Next, we take the ESP8266 module as an example to describe how to use the concise API provided by the AT framework to interact with the module.

4. Use AT framework to enable and configure the AT client framework

After the above explanation, the complete AT framework actually includes two parts: the device driver framework and the AT framework implementation, so we first need to enable the driver framework and the AT framework in the configuration file.

Open the newly created HelloWorld project (if not, you can refer to the previous tutorial to create a new HelloWorld project), and configure it in .sdkconfig, as shown in the figure:

After enabling, not only the source code of the driver framework and the source code of the AT framework will be added to the project, but also will be initialized automatically.

Open the link_main.c file in the IoT_LINK_1.0.0\ iot_link directory under SDK, where you can see it in the link_main function:

The first is the initialization of the driver framework:

The second is the initialization of serial port hardware and AT framework.

During the automatic initialization, you can see that the serial communication baud rate is specified by the macro definition CONFIG_AT_BAUDRATE, and the name of the serial device registered to the system is specified by the macro definition CONFIG_AT_DEVICENAME, so where are the two macro definitions specified?

The baud rate of the unused module is different, and the device name is also different, so these two are set in the OS_CONFIG/iot_link_config.h in the project directory. Here we use the ESP8266 module to experiment, as shown in the figure:

Send AT command

The API prototype and parameters for sending AT instructions are described as follows:

/ * * @ brief:use this function to register a function that monitor the URC message * @ Param [in]: cmd, the command to send * @ Param [in]: cmdlen, the command length * @ Param [in]: index, the command index, if you don't need the response, set it to NULL This must be a string * @ paramin: respbuf, if you need the response, you should supply the buffer * @ paramin: respbuflen,the respbuf length * @ paramin: timeout, the time you may wait for the response;and the unit is ms * * @ return:0 success while-1 failed * / int at_command (const void * cmd, size_t cmdlen,const char * index,\ void * respbuf,size_t respbuflen,uint32_t timeout)

Next, we create a folder at_test_demo under the Demo folder to store the experimental files, and create a new experimental file at_esp8266_demo.c used in this section under this folder:

Then edit the following in the file:

# include # define SSID "FAST_88A6" # define PASSWD "18324701020" static bool_t esp8266_atcmd (const char * cmd,const char * index) {int ret = 0; ret = at_command ((unsigned char *) cmd,strlen (cmd), index,NULL,0,5000); if (ret > = 0) {return true;} else {return false }} static int at_esp8266_demo_entry () {char cmd [64]; int ret; / * Test whether AT is OK, timeout 5S * / memset (cmd,0,64); snprintf (cmd,64, "AT\ r\ n"); while (false = = esp8266_atcmd (cmd, "OK")) {printf ("AT Test fail, repeat.\ r\ n") } printf ("AT test ok.\ r\ n"); / * turn off echo * / memset (cmd,0,64); snprintf (cmd,64, "ATE0\ r\ n"); ret = esp8266_atcmd (cmd, "OK"); if (ret = = false) {printf ("ATE0 test fail.\ r\ n");} else {printf ("ATE0 test ok.\ r\ n") } / * set mode to AP+STA * / memset (cmd,0,64); snprintf (cmd,64, "AT+CWMODE=3\ r\ n"); ret = esp8266_atcmd (cmd, "OK"); if (ret = = false) {printf ("AT+CWMODE=3 test fail.\ r\ n");} else {printf ("AT+CWMODE=3 test ok.\ r\ n") } / * Connect router * / memset (cmd,0,64); snprintf (cmd,64, "AT+CWJAP=\"% s\ ",\" s\ "\ r\ n", SSID, PASSWD); while (false = = esp8266_atcmd (cmd, "OK") {printf ("try to join AP:%s fail, repeat.\ r\ n", SSID);} printf ("AT+CWMODE=3 test ok.\ r\ n") Return 0;} int standard_app_demo_main () {osal_task_create ("at_esp8266_demo", at_esp8266_demo_entry,NULL,0x800,NULL,12); return 0;}

Results:

Get the result returned by AT instruction and extract valid information

For the result returned by the AT command, if valid information is stored in it, we can pass in a buffer when calling at_command, as follows, send the ip address of the query module and extract the ip address:

After connecting to the router code, add the following code:

/ * get ip address * / const char cs_cmd [] = "AT+CIFSR\ r\ n"; char buffer [150]; char * str; uint8_t ip [4]; memset (buffer,0150); ret = at_command (cs_cmd,strlen (cs_cmd), "OK", buffer, 150,5000); if (ret < 0) {printf ("AT+CIFSR test fail.\ r\ n") } else {printf ("AT+CIFSR test ok.\ r\ n"); / * extract ip address * / str = strstr (buffer, "STAIP"); str = str + 7; sscanf (str, "% d.%d.%d.%d", & ip [0], & ip [1], & ip [2], & ip [3]) Printf ("ip:% d.%d.%d.%d\ r\ n", ip [0], ip [1], ip [2], ip [3]);}

The experimental results are as follows:

At this point, I believe you have a deeper understanding of "how to use the serial module interaction in MCU". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.