CN116055578B

CN116055578B - Lightweight AT protocol stack, communication method and system

Info

Publication number: CN116055578B
Application number: CN202310200898.6A
Authority: CN
Inventors: 曹裕昌
Original assignee: Beijing Chaoge Digital Technology Co ltd
Current assignee: Beijing Chaoge Digital Technology Co ltd
Priority date: 2023-03-06
Filing date: 2023-03-06
Publication date: 2023-06-27
Anticipated expiration: 2043-03-06
Also published as: CN116055578A

Abstract

The embodiment of the application discloses a lightweight AT protocol stack, a communication method and a system, wherein the AT protocol stack comprises the following components: a main process and a sub-thread corresponding to the main process; the main process is used for receiving an external instruction; if the external instruction is an AT command, the AT command is sent to the terminal equipment through an AT serial port, and a first monitoring event aiming AT the reply content of the AT command is registered; if the external instruction is an event monitoring instruction, registering a second monitoring event aiming at the event monitoring instruction; the sub-thread is used for continuously reading the message received by the AT serial port, analyzing the message to confirm whether the message is matched with the first monitoring event, and if so, sending the message to an external process for issuing an AT command so as to reply the AT command; if the information is not matched with the information, whether the information contains the information monitored by the second monitoring event is confirmed, and if the information contains the information, reminding information is sent to an external process registering the second monitoring event.

Description

Lightweight AT protocol stack, communication method and system

Technical Field

The present document relates to the field of computer technologies, and in particular, to a lightweight AT protocol stack, a communication method, and a system.

Background

The AT command is widely used as an information communication method and communication standard in a wireless mobile communication system User Equipment (UE) or an internet of things embedded device (hereinafter referred to as a device) with a cellular module. The AT protocol stack analyzes, processes and responds to the received AT command, and can realize the control of the equipment and the interaction with network services, such as function setting, calling, short messages, telephone books, data services, supplementary services and the like.

Currently, the mainstream AT protocol stack development schemes are implemented either using the radio interface layer (Radio Interface Layer, RIL) of android or using the com tool in the linux development platform Openwrt, and the latter is implemented with scripts. The former or latter development scheme has less flexible functions and is not beneficial to the realization of complex business. For example, script-based instructions are generally not well handled for active result code (UnsolicitedResult Code, URC) events that occur upon command reply.

Therefore, it is desirable to develop a lightweight AT protocol stack to handle AT interface information to better implement complex services.

Disclosure of Invention

The embodiment of the application provides a lightweight AT protocol stack, a communication method and a system, so as to better realize complex services.

In order to solve the technical problems, the embodiment of the application is realized as follows:

in a first aspect, a lightweight AT protocol stack is provided, including: a main process and a sub-thread corresponding to the main process;

the main process is used for receiving external instructions; if the external instruction is an AT command, the AT command is sent to the terminal equipment through an AT serial port, and a first monitoring event aiming AT the reply content of the AT command is registered; if the external instruction is an event monitoring instruction, registering a second monitoring event aiming at the event monitoring instruction;

the sub-thread is used for continuously reading the message received by the AT serial port, analyzing the message to confirm whether the message is matched with the first monitoring event, and if so, sending the message to an external process for sending the AT command so as to reply to the AT command; if not, confirming whether the message contains the information monitored by the second monitoring event, if so, sending reminding information to an external process registering the second monitoring event, and if not, ignoring the message.

In a second aspect, a communication method based on a lightweight AT protocol stack is provided, where the AT protocol stack includes a main process and a sub-thread corresponding to the main process, and the method includes:

receiving an external instruction through the main process; if the external instruction is an AT command, the AT command is sent to the terminal equipment through an AT serial port, and a first monitoring event aiming AT the reply content of the AT command is registered; if the external instruction is an event monitoring instruction, registering a second monitoring event aiming at the event monitoring instruction;

continuously reading a message received by an AT serial port through the sub-thread, analyzing the message to confirm whether the message is matched with the first monitoring event, and if so, sending the message to an external process for sending the AT command so as to reply to the AT command; if not, confirming whether the message contains the information monitored by the second monitoring event, if so, sending reminding information to an external process registering the second monitoring event, and if not, ignoring the message.

In a third aspect, a communication system is provided, which includes: terminal device and AT protocol stack according to any of claims 1-8.

According to the AT least one technical scheme provided by the embodiment of the application, related services can be processed by correspondingly setting one main process and one sub-thread in the AT protocol stack, so that compared with a traditional development scheme, the AT protocol stack is lighter, the whole code is simpler, and the occupied space is less. In addition, the AT protocol stack can register the monitoring event through the reply of the main process to the AT command, can continuously read the message from the AT serial port through the sub-thread, and analyze whether the message is matched with the monitoring event registered before, if so, the AT command is replied pertinently or the reminding information is sent to the second monitoring event respectively, so that complex services such as URC event conflict when the AT command is replied can be better realized.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute an undue limitation to the application. In the drawings:

fig. 1 is a schematic structural diagram of a lightweight AT protocol stack according to an embodiment of the present application.

Fig. 2 is a schematic diagram of a detailed implementation procedure of a lightweight AT protocol stack according to an embodiment of the present application.

Fig. 3 is a schematic structural diagram of a lightweight AT protocol stack according to another embodiment of the present application.

Fig. 4 is a flow chart of a communication method based on a lightweight AT protocol stack according to an embodiment of the present application.

Fig. 5 is a schematic structural diagram of a communication system according to an embodiment of the present application.

Detailed Description

For the purposes, technical solutions and advantages of the present application, the technical solutions of the present application will be clearly and completely described below with reference to specific embodiments of the present application and corresponding drawings. It will be apparent that the described embodiments are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

Most of currently used cellular products are based on an android architecture, while an RIL library with the android can be used for realizing an AT protocol stack, the cellular products have two disadvantages, namely the RIL is complex in operation, large in volume and powerful in function, and meanwhile, the cellular products are not very convenient to use; the other is that only one socket is supported, the upper application needs to work together, and the upper application of android works in the java virtual machine, so that the architecture is difficult to use once the embedded device is separated from the android, and even the transplanting workload is huge. Not only does the AT protocol stack body need to rewrite the compiled content, but also for the companion application AT the upper layer either whole migration or rewriting is selected. The rewriting has workload, and the transplanting does not need the reconstruction workload, but the corresponding java virtual machine needs to be transplanted, so that the resource overhead is high. The RIL is a set of open source library in the android development framework and is specially used for managing the wireless module and processing services related to dial-up networking.

However, the traditional openwrt is simple to use, but only uses com, so that the monitoring of the device state actively reported by the AT serial port is weak. Moreover, script-based principles of operation also necessitate that message processing be initiated by com, which then obtains results that must be completely consistent with the preset results, and that errors be handled by com if URC events occur when the results are returned. In addition, if command execution fails, com needs to correspond to a preset command, and the script cannot recognize the result outside the preset command. Finally, when a plurality of commands are continuously called, the com can only be processed linearly according to the script, and the operations such as retry and the like are inconvenient for the error log. The Openwrt is an open source development platform of the linux, and functions are flexible; comgt is an open source management tool in openwrt, and can be used for inputting instructions in a serial port and acquiring a return result in the serial port according to a script.

Therefore, the mainstream AT protocol stack development scheme is not only inflexible in function, but also very limited, which is not beneficial to the realization of complex services, or the realization workload is very large.

In order to solve the above problem, the embodiments of the present application propose a lightweight AT protocol stack, which can be applied to any scenario requiring communication using the AT protocol stack. Based on a lightweight AT protocol stack, the embodiment of the application also provides a communication method and a communication system based on the lightweight AT protocol stack, which are described one by one.

First, a lightweight AT protocol stack provided in the embodiments of the present application is described.

As shown in fig. 1, a lightweight AT protocol stack 100 according to an embodiment of the present application may include: a main process 11 and a sub-thread 12 provided corresponding to the main process 11.

Specifically, the AT protocol stack 100 itself may be considered as a server whose functional area includes two threads, a main process 11 and a sub-thread 12.

Wherein, the main thread 11 is configured to receive an external instruction; if the external instruction is an AT command, the AT command is sent to the terminal equipment through an AT serial port 13, and a first monitoring event aiming AT the reply content of the AT command is registered; and if the external instruction is an event monitoring instruction, registering a second monitoring event aiming at the event monitoring instruction. I.e. the main thread 11 is responsible for actively issuing commands or registering monitoring events, wherein the first monitoring event is used for monitoring replies to AT commands and the second monitoring event is used for monitoring active result codes URC from the terminal device, which are of interest to external processes.

The external command generally refers to a command sent by an application layer on the terminal device to an AT protocol stack, and includes an AT command or an event monitoring command, where the AT command is generally used to control the terminal device, and the event monitoring command is generally used to monitor some state changes or events occurring on the terminal device or the network side, such as signal strength of a cellular network, battery power, and the like. The terminal device herein may include, but is not limited to, a mobile communication terminal, an embedded internet of things device, and the like.

In general, for an AT command sent by an application layer on a terminal device to an AT protocol stack, the AT protocol stack needs to reply to the corresponding AT command.

Specifically, messages received through an AT serial port can be divided into two categories:

one is a final result code (Final Result Code, abbreviated as FRC) for indicating whether the execution of the AT command is successful or not (i.e., the AT command response result), generally indicated by "OK" or "ERROR";

the other type is an active result code (UnsolicitedResult Code, abbreviated URC) that is actively reported by the terminal device for monitoring some state changes or events occurring at the terminal device or network side.

Because these two types of messages exist AT the AT serial port AT the same time, the content can be easily distinguished by naked eyes, but for the AT protocol stack, the distinguishing difficulty is high, especially when the AT protocol stack waits for the reply of the AT command, if a URC event occurs, the URC is inserted into the reply information of the AT command to a great extent, for example, the reply for the AT command is generally:

AT$MYGMR

1234

MX1234

1005

261112

1234

250910

OK

where AT$MYGMR is the command body and the portion of the middle 1234 to OK is the reply content.

But if a device drop occurs at this instant, a URC event may be incorporated: the message received by the AT serial port is:

AT$MYGMR

$MYURCACT: 1,0

1234

MX1234

1005

261112

1234

250910

OK

in the face of such a situation, the conventional AT protocol stack would consider the intermediate $myocact as part of the reply to the AT command, thereby making the acquired information erroneous, making the application layer misinterpret as an AT command issue failure, or deadlock. The device generally sets the AT serial port to close all event reporting and serial port back display when the AT protocol stack is initialized. However, according to the protocol, reporting of part of the events is necessary, and when this occurs extremely, it may cause incorrect information parsing. Or, because most of the messages received by the AT serial port are transmitted in an asynchronous manner, the messages received by the AT serial port are not necessarily replies to the AT command, and are likely to be just a certain URC event triggered AT the time, so that the acquired information is in error, and the application layer fails to issue the AT command or is in deadlock. However, this problem may be well addressed by the present embodiments through the sub-threads 12.

The sub-thread 12 is configured to continuously read a message received by the AT serial port 13, analyze the message to confirm whether the message is matched with the first monitoring event, and if so, send the message to an external process that issues the AT command to reply to the AT command; if not, confirming whether the message contains the information monitored by the second monitoring event, if so, sending reminding information to an external process registering the second monitoring event, and if not, ignoring the message. The continuous reading here may be continuous reading at small time intervals or periods.

In colloquially speaking, in a lightweight AT protocol stack 100 provided in the embodiments of the present application, a child thread 12 may be used as a daemon thread of a main process 11 to continuously read and analyze a message received by an AT serial port to solve the above-mentioned problem.

Specifically, if the host process 11, after registering the first monitoring event for the reply content of the AT command, stores the corresponding relationship among the AT command, the reply content of the AT command, and the first monitoring event (which may be stored in a linked list form), where the AT command and the reply content of the AT command conform to a preset convention, for example, when the user uses the AT protocol stack, the user needs to agree on the content and format of the AT command, and agree on the content and format of the reply for the AT command, specifically, may agree on a start symbol, an end symbol, an erroneous flag bit, a timeout time, and the like of the reply content. It will be appreciated that with these conventions, the AT protocol stack knows how to decide what content is the return value of the AT command and what is not, and for non-return values, it can enter the URC information decision to analyze what event was found.

Accordingly, the sub-thread 12 may be specifically configured to: and analyzing keywords in the message according to the corresponding relation table to confirm whether the message is matched with the first monitoring event. It can be appreciated that if there is a match, indicating that the message is a reply to the AT command, the message needs to be sent to an external process that issues the AT command to reply to the AT command; if the message does not match, it is further determined whether the message is related to the second monitoring event, if so, it is required to send the message as the content monitored by the second monitoring event to an external process registering the second monitoring event (because the external process is concerned with the message and needs to send the message), and if not, it is required to ignore or discard the message if it is likely to be a URC not concerned by the external process.

Fig. 2 is a schematic diagram illustrating a detailed implementation process of a lightweight AT protocol stack 100 according to an embodiment of the present application, which is described in detail below.

As shown in fig. 2, a detailed implementation procedure in the lightweight AT protocol stack 100 provided in the embodiment of the present application may include:

step 21, the external process issues an instruction (i.e. an external instruction).

Accordingly, the host process receives an instruction, if the instruction is an AT command, then step 22 is executed, and if the instruction is an event monitoring instruction, then step 23 is executed.

Step 22, the main process receives the instruction and proceeds to step 24 and step 25.

Step 23, the main process registers a second monitoring event.

And step 24, the main process replies to the external process.

The content of the reply of step 24 is different for different cases:

after the instruction is normally received, replying to the content aims at indicating that the instruction is normally received;

after the host process successfully issues the AT command, the reply content is aimed AT indicating that the AT command has been successfully issued;

after the preset timeout period is over, if the AT command fails to be successfully sent, the reply content aims AT indicating that the AT command fails to be issued.

Step 25, the main process issues an AT command to the AT serial port, starts a timer and registers a first monitoring event.

If the transmission is successful, the process proceeds to step 26, and if the transmission is timed out, the process proceeds to step 27.

In step 25, the main process registers the first monitoring event and stores the corresponding relation among the AT command, the reply content of the AT command and the first monitoring event, where the AT command and the reply content of the AT command conform to a preset convention, for example, when the user uses the AT protocol stack, the user needs to agree on the content and format of the AT command, and agree on the content and format of the reply to the AT command, and in particular, the user may agree on the elements such as a start symbol, a terminal symbol, an error flag bit, and a timeout time of the reply content. It will be appreciated that with these conventions, the AT protocol stack knows how to decide which contents are the return values of the AT command and which are not, and for non-return values, it can enter the URC information decision to analyze what event was found.

Step 26, normal reversion.

Step 27, overtime error reporting.

Step 28, the AT serial port asynchronously sends AT commands or receives messages.

While the main process is working, the sub-thread is continuously reading and analyzing messages from the AT serial port.

Step 29, the sub-thread continuously reads the message from the AT serial port and analyzes the message.

Specifically, the sub-thread may analyze the keywords in the message according to the correspondence table to confirm whether the message is matched with the first monitoring event, and if so, send the message to an external process that issues the AT command to reply to the AT command; if the message does not match, further judging whether the message is related to the second monitoring event, if so, sending the message to an external process registering the second monitoring event as the content monitored by the second monitoring event (the external process is concerned with the message and needs to send the message), and if not, omitting or discarding the message, wherein the message is possibly a URC which is not concerned by the external process.

It can be understood that, by registering the monitoring event for the reply of the AT command through the main process, continuously reading the message from the AT serial port through the sub-thread, analyzing whether the message is matched with the monitoring event registered previously, if so, replying the AT command or sending the reminding information for the second monitoring event, respectively, so that complex services such as the occurrence of the URC event conflict during reply of the AT command can be better realized, and that is, the reply of the actively issued AT command and the URC event monitoring can not conflict any more.

On the basis, optionally, after the AT protocol stack is initialized, the echo function of the AT serial port can be in an on state. That is, the echo function of the AT serial port may not be turned off when the AT protocol stack is initialized, so that the debug log may clearly record all data passing through the AT serial port. Wherein Debug is a Debug information switch of the AT protocol stack.

Optionally, as shown in fig. 1, a lightweight AT protocol stack 100 according to an embodiment of the present application may further include: an interface library 14 open to external processes.

Wherein the interface library 14 may include AT least one API interface (hereinafter referred to as an interface), the interface library 14 may be used for an external process to communicate with the AT protocol stack; accordingly, the main process 11 may be specifically configured to receive external instructions through an interface in the interface library 14, and the sub-thread 12 may be specifically configured to send reply of an AT command or reminder information of a monitoring event to an external process through an interface in the interface library 14.

Alternatively, in a lightweight AT protocol stack 100 according to the embodiments of the present application, the main process 11 and the sub-thread 12 may communicate with external processes based on respective sockets, respectively. It can be understood that standard socket communication is adopted, so that the compatibility and portability are high.

Alternatively, as shown in fig. 3, in a lightweight AT protocol stack 100 proposed in the embodiment of the present application, the number of main processes 11 may be more than two, and one main process 11 corresponds to one sub-thread 12; wherein one main process 11 and the corresponding sub-thread 12 of the main process 11 are used for realizing one service, different main processes are used for realizing different services, and an external process communicates with different main processes through different interfaces in an interface library of the AT protocol stack, for example, one main process is used for realizing a busy subscriber call completion supplementary service (Completion of Calls to Busy Subscriber, CCBS), and the other main process is used for realizing a dialing service.

Optionally, the lightweight AT protocol stack 100 provided in the embodiments of the present application may further include: a message queue; on the basis, the main process is specifically configured to send the AT command to the message queue first, so that the AT serial port sequentially reads the AT command from the message queue and sends the AT command to the terminal device. It can be understood that after the message queue is introduced, command collision can be prevented, so that a plurality of host processes can be simultaneously supported to respectively control the AT serial port, and the problem that the AT serial port is exclusively used by a process in the related technology is solved.

In summary, the lightweight AT protocol stack 100 provided in the embodiments of the present application may achieve one or more of the following technical effects:

1) Because the related service can be processed by correspondingly arranging a main process and a sub-thread in the AT protocol stack, compared with the traditional development scheme, the AT protocol stack is lighter, the whole code is simpler, and the occupied space is less. For example, compared with the development scheme based on android RIL, the resource cost and portability of the android RIL can be very small, and the same functions can be provided; compared with the development scheme based on com, the method has a much powerful function and can simultaneously meet the requirements of issuing AT commands and monitoring URC events.

2) Because the AT protocol stack can register the monitoring event through the reply of the main process to the AT command, the sub-thread can continuously read the message from the AT serial port and analyze whether the message is matched with the monitoring event registered before, if so, the AT command is replied pertinently or the reminding information is sent to the second monitoring event respectively, so that complex services such as URC event conflict when the AT command is replied, namely the reply of the AT command issued actively and the URC event monitoring are not in conflict any more can be better realized. Therefore, the display function of the AT serial port is not closed during initialization, and the debug log can clearly record all data passing through the AT serial port.

3) Because the main process and the sub-thread both adopt standard socket communication, the compatibility is strong and the portability is strong.

4) The abstraction of the functional modules into independent processes can be provided for use in any linux-based system.

5) After the processes are unified, the interfaces are flexible, and command collision can be prevented by utilizing the message queue, so that a plurality of main processes can be simultaneously supported to respectively control the AT serial ports, and the problem that the AT serial ports are exclusively used by a certain process in the related technology is solved.

5) Each external process can register an event (second monitoring event) concerned by itself, the AT protocol stack is independent and does not need to be modified, and the authority is furthest opened to an external developer.

6) Because the number of the main processes can comprise more than two, and one main process corresponds to one sub-thread, wherein one main process and the sub-thread corresponding to the main process are used for realizing one service, different main processes are used for realizing different services, and an external process communicates with different main processes through different interfaces in an interface library of the AT protocol stack, so that the ppp dial-up service can be processed. In the traditional scheme, after the ppp dialing service is triggered, the AT serial port is converted into a data port, but after the AT protocol stack provided by the embodiment of the application is used, more than two AT serial ports can be operated, so that even if dialing is performed, the issuing of other AT commands and event monitoring are not influenced.

Optionally, on the basis of the above-mentioned lightweight AT protocol stack, as shown in fig. 4, an embodiment of the present application further provides a communication method based on the lightweight AT protocol stack, which may include:

step 401, receiving an external instruction through a main process; if the external instruction is an AT command, the AT command is sent to the terminal equipment through an AT serial port, and a first monitoring event aiming AT the reply content of the AT command is registered; if the external instruction is an event monitoring instruction, registering a second monitoring event aiming at the event monitoring instruction;

step 402, continuously reading a message received by an AT serial port through a sub-thread, analyzing the message to confirm whether the message is matched with the first monitoring event, if so, sending the message to an external process which issues the AT command to reply to the AT command; if not, confirming whether the message contains the information monitored by the second monitoring event, if so, sending reminding information to an external process registering the second monitoring event, and if not, ignoring the message.

It should be noted that, because the communication method provided in the embodiment of the present application is based on a lightweight AT protocol stack provided in the embodiment of the present application, specific implementation details of the communication method are similar to those of the lightweight AT protocol stack provided in the embodiment of the present application, and the same technical effects can be achieved, so that the detailed description is omitted.

Optionally, based on the above-mentioned lightweight AT protocol stack, as shown in fig. 5, an embodiment of the present application further provides a communication system 500, which may include: an AT protocol stack 501 and a terminal device 502.

The AT protocol stack 501 may be a lightweight-based AT protocol stack 100 provided in the embodiments of the present application; the terminal device 502 may be any terminal device that employs an AT protocol stack for device control, such as a mobile terminal, an embedded internet of things device, and the like.

It should be noted that, since the communication system provided in the embodiment of the present application includes a lightweight AT protocol stack provided in the embodiment of the present application, specific implementation details thereof are similar to those of the lightweight AT protocol stack provided in the embodiment of the present application, and the same technical effects can be achieved, so that the detailed description thereof will not be repeated.

Optionally, an embodiment of the present application further provides an electronic device, including: the system comprises a processor, a memory and one or more programs stored on the memory and executable on the processor, wherein the one or more programs comprise instructions which, when executed by a portable electronic device comprising a plurality of application programs, can implement the steps of the lightweight AT protocol stack-based communication method provided by the embodiment of the application.

Optionally, the embodiment of the present application further proposes a computer readable storage medium storing one or more programs, the one or more programs including instructions, which when executed by a portable electronic device including a plurality of application programs, enable implementation of the steps of a lightweight AT protocol stack-based communication method provided by the embodiment of the present application.

The foregoing description is only of the preferred embodiments of the present application and is presented as a description of the principles of the technology being utilized. It will be appreciated by persons skilled in the art that the scope of the invention referred to in this application is not limited to the specific combinations of features described above, but it is intended to cover other embodiments in which any combination of features described above or equivalents thereof is possible without departing from the spirit of the invention. Such as the above-described features and technical features having similar functions (but not limited to) disclosed in the present application are replaced with each other.

The foregoing describes specific embodiments of the present application. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

All embodiments in the application are described in a progressive manner, and identical and similar parts of all embodiments are mutually referred, so that each embodiment mainly describes differences from other embodiments. In particular, for the device embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, and reference is made to the description of the method embodiments in part.

In summary, the foregoing description is only a preferred embodiment of the present application, and is not intended to limit the scope of the present application. Any modification, equivalent replacement, improvement, etc. that comes within the spirit and principles of one or more embodiments of the present application are intended to be included within the scope of one or more embodiments of the present application.

It should be noted that the terms "first," "second," and the like in the present application and in the claims are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments of the application are capable of operation in sequences other than those illustrated or otherwise described herein, and that the terms "first" and "second" are generally intended to be used in a generic sense and not to limit the number of objects, for example, the first character may be one or more.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

Claims

1. A communication system comprising a terminal device and an AT protocol stack, wherein the AT protocol stack comprises: a main process and a sub-thread corresponding to the main process;

the main process is used for receiving external instructions; if the external command is an AT command, the AT command is sent to a terminal device through an AT serial port, a first monitoring event aiming AT the reply content of the AT command is registered, and the corresponding relation among the AT command, the reply content of the AT command and the first monitoring event is saved, wherein the AT command and the reply content of the AT command accord with a preset agreement; if the external instruction is an event monitoring instruction, registering a second monitoring event aiming at the event monitoring instruction; the second monitoring event is used for monitoring an active result code URC from the terminal device, which is concerned by an external process;

the sub-thread is used for continuously reading the message received by the AT serial port, analyzing the keywords in the message according to the corresponding relation table to confirm whether the message is matched with the first monitoring event, and if so, sending the message to an external process for sending the AT command so as to reply to the AT command; if not, confirming whether the message contains the information monitored by the second monitoring event, if so, sending reminding information to an external process registering the second monitoring event, and if not, ignoring the message.

2. The communication system of claim 1, wherein the AT protocol stack further comprises: an interface library open to external processes;

the interface library is used for communicating with the AT protocol stack by an external process;

the main process is specifically configured to receive an external instruction through an interface in the interface library.

3. The communication system of claim 1, wherein,

after the AT protocol stack is initialized, the echo function of the AT serial port is in an on state.

4. The communication system of claim 1, wherein,

the main process and the sub-thread communicate with external processes based on respective sockets, respectively.

5. The communication system of claim 1, wherein,

the number of the main processes comprises more than two, and one main process corresponds to one sub-thread;

one main process and a sub-thread corresponding to the main process are used for realizing one service, different main processes are used for realizing different services, and an external process communicates with different main processes through different interfaces in an interface library of the AT protocol stack.

6. The communication system of any of claims 1-5, wherein the AT protocol stack further comprises: a message queue;

the main process is specifically configured to send the AT command to the message queue first, so that the AT serial port reads the AT command from the message queue and sends the AT command to the terminal device.

7. A communication method based on a lightweight AT protocol stack, wherein the AT protocol stack includes a main process and a sub-thread corresponding to the main process, the method comprising:

receiving an external instruction through the main process; if the external command is an AT command, the AT command is sent to a terminal device through an AT serial port, a first monitoring event aiming AT the reply content of the AT command is registered, and the corresponding relation among the AT command, the reply content of the AT command and the first monitoring event is saved, wherein the AT command and the reply content of the AT command accord with a preset agreement; if the external instruction is an event monitoring instruction, registering a second monitoring event aiming at the event monitoring instruction; the second monitoring event is used for monitoring an active result code URC from the terminal device, which is concerned by an external process;

continuously reading a message received by an AT serial port through the sub-thread, analyzing keywords in the message according to the corresponding relation table to confirm whether the message is matched with the first monitoring event, and if so, sending the message to an external process for sending the AT command so as to reply to the AT command; if not, confirming whether the message contains the information monitored by the second monitoring event, if so, sending reminding information to an external process registering the second monitoring event, and if not, ignoring the message.