AT instruction processing system and method based on modular class inheritance

Through the modular class inheritance design of the AT instruction processing system, the complexity and adaptation cost of the AT instruction processing system in embedded communication devices are solved, efficient AT instruction analysis and response processing are realized, and the stability and adaptation capabilities of the system are improved.

CN120295668APending Publication Date: 2025-07-11ANHUI LIANMAN ELECTRIC CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510340140.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-03-21
Publication Date
2025-07-11

AI Technical Summary

Technical Problem

In the prior art, the AT instruction processing system of embedded communication devices has problems such as complex code logic, low inter-module reuse rate, high maintenance iteration cost, easy state machine conflicts, and high communication module switching adaptation cost.

Method used

The modular class inheritance design is adopted, including the basic analysis layer, the interaction control layer, the network function layer and the device management layer. The dynamic analysis and response processing of AT instructions are realized through class inheritance and regular expression matching, and the multi-device communication thread isolation and exception recovery mechanism are supported.

Benefits of technology

简化了AT指令的解析和响应处理,提高了代码的稳定性和通用性,降低了开发和维护成本,支持快速适配不同通信模块。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120295668A_ABST
    Figure CN120295668A_ABST
Patent Text Reader

Abstract

The invention discloses an AT instruction processing system and method based on modular class inheritance. According to the system, a basic analysis layer comprises an AtCmd class for packaging a basic AT instruction and an AtURC class inheriting and expanding the AtCmd class; the interaction control layer comprises an AtCop class for sending an AT instruction to equipment through a serial port and analyzing a response, and an AtUrcCoP class for inheriting the AtCop class and calling an AtURC class to realize real-time analysis and response of a URC command; the network function layer comprises an AtSocket class and an AtSockCoP class, wherein the AtSocket class is used for basic operation of network socket connection and data transmission, and the AtSockCoP class inherits an AtUrcCoP class and integrates socket state detection and URC analysis; the equipment management layer comprises an AtHost class and an AtDaemon class, wherein the AtHost class is bound with a serial port driver so as to receive equipment data and forward the equipment data to the AtCop class for analysis, and the AtDaemon class is used for packaging an operating system thread interface so as to asynchronously manage the AT equipment communication process. Universal logic is packaged through the layered architecture, and different communication modules are dynamically adapted, so that the development efficiency is remarkably improved, the maintenance cost is reduced, and meanwhile, the system stability and the resource utilization rate are improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of embedded communication technologies, and particularly to an AT command processing system and method based on modular class inheritance. Background Art

[0002] AT commands, as a text protocol for an AT command processing system and method based on modular class inheritance, are widely used in embedded communication devices (such as 4G networking modules, Wi-Fi modules, and Bluetooth modules), and undertake the core functions of device control, network connection, and data transmission. In actual development scenarios, in addition to basic AT commands, there are a large number of custom instruction sets in communication modules of different manufacturers, and device-to-device communication needs to simultaneously handle two interaction modes: master control end inquiry response and device end active reporting. The complexity of this instruction system and the diversity of interaction methods result in developers needing to write specific instruction parsing, state machine management, and exception handling codes for different modules, forming a large amount of repetitive development work.

[0003] The deficiencies of the prior art are as follows: Under the traditional development mode, AT command parsing and response processing highly rely on manual coding implementation, resulting in high code logic complexity, low module reuse rate, and rising maintenance and iteration costs. Specifically, (1) dedicated parsers need to be repeatedly developed for custom AT commands of each manufacturer, and the code redundancy is significant; (2) in a multi-threaded environment, it is necessary to manually maintain the instruction sending and receiving timing, which is prone to state machine conflicts; (3) the exception handling logic is scattered and embedded in the business code, reducing the system stability; (4) when switching communication modules, it is necessary to reconstruct the underlying driver, and the adaptation cost is high. These technical bottlenecks severely restrict the development efficiency and maintainability of embedded communication systems. Summary of the Invention

[0004] The purpose of the present invention is to overcome the deficiencies of the prior art. To achieve the above purpose, an AT command processing system and method based on modular class inheritance are adopted to solve the problems raised in the above background art.

[0005] An AT command processing system based on modular class inheritance, the system includes a basic parsing layer, an interaction control layer, a network function layer, and a device management layer;

[0006] The basic parsing layer includes an AtCmd class that encapsulates the parsing logic and state update method of basic AT commands, and an AtURC class that inherits from the AtCmd class and extends the storage and parsing of device active reporting commands;

[0007] The interaction control layer includes an AtCop class that sends AT commands to the device through the serial port and parses the response to update the instruction state, and an AtUrcCoP class that inherits from the AtCop class and calls the AtURC class to implement real-time parsing and response of URC commands;

[0008] The network function layer includes the AtSocket class for basic operations such as network socket connection and data transmission, and the AtSockCoP class that inherits the AtUrcCoP class and integrates socket status detection and URC parsing;

[0009] The device management layer includes the AtHost class that binds to the serial port driver to receive device data and forward it to the AtCop class for parsing, and the AtDaemon class that encapsulates the operating system thread interface to asynchronously manage the AT device communication process.

[0010] As a further solution of the present invention: the parsing function of the AtURC class is dynamically extended through secondary inheritance. Developers inherit the AtURC class and rewrite the parsing method for the URC command sets of different devices to adapt to the differential formats of device-initiated reporting commands.

[0011] As a further solution of the present invention: the AtDaemon class realizes the independent operation and resource isolation of multi-device communication threads by instantiating and configuring the target serial port and the AT module type.

[0012] As a further solution of the present invention: when the AtSockCoP class detects a network anomaly, it automatically triggers the instruction retransmission mechanism of the AtCop class, and parses the exception status code returned by the device through the AtURC class to update the socket connection status.

[0013] As a further solution of the present invention: the parsing process of URC commands includes:

[0014] Matching the instruction prefix of the device-reported data through regular expressions;

[0015] Extracting the instruction parameters and storing them in the circular buffer;

[0016] Calling the pre-registered class function to notify the interaction control layer for processing.

[0017] As a further solution of the present invention: the AtHost class parses the data when receiving device data.

[0018] As a further solution of the present invention: the socket operation interfaces of the AtSocket class include:

[0019] Dynamically generating TCP / UDP connection commands according to the AT instruction set;

[0020] Monitoring data transmission timeouts and retransmitting lost data packets;

[0021] Parsing the IP address and port number returned by the device to update the socket configuration.

[0022] As a further solution of the present invention: By inheriting the AtSockCoP class and implementing the exclusive AT instruction set of the target module, the rapid adaptation of the communication module is completed, and the code logic of the basic parsing layer and the interaction control layer does not need to be modified during the adaptation process.

[0023] As a further solution of the present invention: When the instruction sending of the AtCop class fails, it automatically records the error type and the number of retries, and notifies the service layer to execute the degradation strategy through the AtDaemon class.

[0024] The technical solution of the second aspect: A method applied to an AT instruction processing system based on modular class inheritance as described in any one of the above, including the following steps:

[0025] S1. Instruction sending and response parsing: Send an AT instruction to the target device through the AtCop class, monitor the data received by the serial port, parse the response data returned by the device to judge the instruction execution status, and update the instruction state machine in the AtCmd class;

[0026] S2. Real-time URC command detection: Regularly match the received data stream through the AtURC class, identify the URC command prefix actively reported by the device, extract the command parameters and store them in the buffer queue;

[0027] S3. Dynamic parsing extension: When an unknown URC command is detected, call the subclass parsing method implemented by the developer inheriting the AtURC class to dynamically extend the URC command parsing logic;

[0028] S4. Network socket management: Monitor the network connection status through the AtSockCoP class, and respond to the URC command to trigger socket operations;

[0029] S5. Threaded data processing: Create an independent thread through the AtDaemon class to run the data receiving method of the AtHost class, and use a double buffer to separate the data receiving and parsing processes;

[0030] S6. Exception recovery mechanism: When the AtCop class detects that the instruction execution times out or the verification fails, it automatically records the error log and triggers the retransmission of the instruction a preset number of times. If the retransmission fails, it notifies the service layer to execute the alternative strategy.

[0031] Compared with the prior art, the present invention has the following technical effects:

[0032] By adopting the above technical solution, the problem of repeated development caused by the communication of devices with AT commands is solved. The parsing and response processing of AT instructions usually require writing a large amount of code. The AtCOP processor designed by us encapsulates the parsing and response processing of AT instructions, which greatly simplifies the software development cost of the product.

[0033] Adopting a modular design, supporting multiple communication modules, facilitating switching and adaptation, and improving the stability and generality of the code

[0034] It has scalability and can write corresponding AT command parsing and data processing logics according to the AT commands of different modules. Brief Description of the Drawings

[0035] The following will describe in detail the specific implementation manners of the present invention in conjunction with the accompanying drawings:

[0036] Figure 1 It is a schematic diagram of the AT command processing system according to the disclosed embodiment of the present application;

[0037] Figure 2 It is an example schematic diagram of an ESP8266 with an AT command set according to the disclosed embodiment of the present application Figure 1 ;

[0038] Figure 3 It is an example schematic diagram of an ESP8266 with an AT command set according to the disclosed embodiment of the present application Figure 2 ;

[0039] Figure 4 It is a flowchart of the AT command processing method according to the disclosed embodiment of the present application. Specific Implementation Manner

[0040] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0041] Please refer to Figure 1 , in the embodiment of the present invention, an AT command processing system based on modular class inheritance, the system includes a basic parsing layer, an interaction control layer, a network function layer, and a device management layer;

[0042] The basic parsing layer includes an AtCmd class that encapsulates the parsing logic and status update method of basic AT commands, and an AtURC class that inherits from the AtCmd class and extends the storage and parsing of device active reporting commands;

[0043] In this embodiment, the parsing function of the AtURC class is dynamically extended through secondary inheritance. Developers inherit from the AtURC class and rewrite the parsing method for the URC command sets of different devices to adapt to the differential formats of device active reporting commands.

[0044] In this embodiment, the parsing process of URC commands includes:

[0045] Match the instruction prefix of the device-reported data through a regular expression;

[0046] Extract the instruction parameters and store them in the circular buffer;

[0047] Call the pre-registered class function to notify the interaction control layer for processing.

[0048] The interaction control layer includes the AtCop class that sends AT commands to the device through the serial port and parses the response to update the instruction status, and the AtUrcCoP class that inherits the AtCop class and calls the AtURC class to implement the real-time parsing and response of URC commands;

[0049] The network function layer includes the AtSocket class for basic operations such as network socket connection and data transmission, and the AtSockCoP class that inherits the AtUrcCoP class and integrates socket status detection and URC parsing;

[0050] In this embodiment, when the AtSockCoP class detects a network exception, it automatically triggers the instruction retransmission mechanism of the AtCop class, and parses the exception status code returned by the device through the AtURC class to update the socket connection status.

[0051] The device management layer includes the AtHost class that binds the serial port driver to receive device data and forwards it to the AtCop class for parsing, and the AtDaemon class that encapsulates the operating system thread interface to asynchronously manage the AT device communication process.

[0052] In this embodiment, the AtDaemon class realizes the independent operation and resource isolation of multi-device communication threads by instantiating and configuring the target serial port and AT module type.

[0053] In this embodiment, when the AtHost class receives device data, it parses the data to avoid parsing errors caused by data competition.

[0054] In this embodiment, the socket operation interfaces of the AtSocket class include:

[0055] Dynamically generate TCP / UDP connection commands according to the AT instruction set;

[0056] Monitor data transmission timeouts and retransmit lost data packets;

[0057] Parse the IP address and port number returned by the device to update the socket configuration.

[0058] In this embodiment, by inheriting the AtSockCoP class and implementing the exclusive AT instruction set of the target module, the communication module is quickly adapted, and the code logic of the basic parsing layer and the interaction control layer does not need to be modified during the adaptation process.

[0059] In this embodiment, when the AtCop class fails to send an instruction, it automatically records the error type and the number of retries, and notifies the service layer to execute the degradation strategy through the AtDaemon class.

[0060] In the specific implementation, it is written in C / C++ language, and an AtCOP processor is encapsulated to handle the interaction of devices carrying AT commands.

[0061] As Figure 2 and Figure 3 shown, the diagrams are respectively schematic diagrams of instances of ESP8266 with an AT command set Figure 1 and Two ;

[0062] An AtCmd class is encapsulated in the AtCOP processor, which is used to handle the basic parsing of basic AT instructions and update the status of basic AT instruction parsing.

[0063] An AtURC class is encapsulated in the AtCOP processor, which inherits the attributes and methods of the AtCmd class and enables it to store and parse URC (AT commands actively reported by the device) commands. Developers can inherit this class again according to the URC commands of the module to handle different URC commands.

[0064] An AtCop class is encapsulated in the AtCOP processor, which is used to implement the parsing of basic AT commands through the AtCmd class. First, the AT commands to be sent are sent to the device through the serial port, and the AT commands replied by the device are received to analyze whether the sent AT commands are successful, and the AT command processing status is updated if successful.

[0065] An AtUrcCoP class is encapsulated in the AtCOP processor, which inherits the attributes and methods of the AtCop class and enables it to parse and respond to URC (AT commands actively reported by the device) commands through the AtURC class, and update the AT command status.

[0066] An AtSocket class is encapsulated in the AtCOP processor, which inherits the attributes and methods of the DAL_Socket class and realizes the basic functions of connecting, closing, sending, and receiving network sockets after the AT device is connected to the network.

[0067] An AtSockCoP class is encapsulated in the AtCOP processor. It inherits the attributes and methods of the AtUrcCoP class, enabling it to have the ability to parse URC data and the basic command parsing ability of the AtCop class. It also adds functions such as closing, connecting, sending, and receiving for network sockets (Scoket). When developers use different AT commands for development, they can directly inherit this class to write different AT modules.

[0068] An AtHost class is encapsulated in the AtCOP processor. It associates the AT processor with a specific device with an AT command set through a serial port driver. Specifically, it receives and stores the data sent by the device with the AT command set to the MCU through the serial port, and after receiving it, it sends it to the AtCop for parsing.

[0069] An AtDaemon class is encapsulated in the AtCOP processor. It inherits the OSthread thread encapsulation function of the operating system and becomes a thread for processing At devices. When developers instantiate it in the program, they can configure the serial port through methods and communicate with which AT module device to achieve fast networking and socket management.

[0070] Technical solution of the second aspect: A method applied to an AT instruction processing system based on modular class inheritance as described in any one of the above, including the following steps:

[0071] S1. Instruction sending and response parsing: Send an AT instruction to the target device through the AtCop class, monitor the data received by the serial port, parse the response data returned by the device to judge the instruction execution status, and update the instruction state machine in the AtCmd class;

[0072] S2. Real-time URC command detection: Perform regular matching on the received data stream through the AtURC class, identify the URC command prefix actively reported by the device, extract the command parameters and store them in the buffer queue;

[0073] S3. Dynamic parsing extension: When an unknown URC command is detected, call the subclass parsing method implemented by the developer inheriting the AtURC class to dynamically extend the URC command parsing logic;

[0074] S4. Network socket management: Monitor the network connection status through the AtSockCoP class, and respond to URC commands to trigger socket operations, including:

[0075] Automatically receive TCP / UDP data packets according to the +IPD class URC command;

[0076] Call the AtCop class to resend the connection instruction when a connection exception is detected;

[0077] S5. Threaded data processing: Create an independent thread through the AtDaemon class to run the data reception method of the AtHost class, and use a double buffer to separate the data reception and parsing processes to avoid thread competition;

[0078] S6. Exception recovery mechanism: When the AtCop class detects that the instruction execution times out or the verification fails, it automatically records the error log and triggers the retransmission of the instruction a preset number of times. If the retransmission fails, it notifies the business layer to execute the alternative strategy.

[0079] As Figure 4 shown, the figure is a flowchart of the AT instruction processing method; specifically:

[0080] According to the model of the communication module and the corresponding AT communication instruction set, package the AtCOP processor of the communication module. At least the operating system, MCU, serial port driver, AtCOP processor, string operation, and error handling are required;

[0081] Screen out the AT instructions required for networking in the AtCOP processor of the communication module and write the corresponding AT instruction parsing function. The specific steps are:

[0082] The AtCOP processor formats the instructions input by the developer into standard AT instructions, actively sends them to the communication module, waits for the communication module to respond, and times. If successful, continue the communication. If it times out or there is an error, retry or restart the module according to the configuration until the networking is successful. The URC commands actively reported by the communication module also perform corresponding instruction parsing and logical processing. Among them, for the actively sent AT instructions, the AtCmd is used to operate the AT instructions, and the AtUrc is used to parse the URC commands actively reported by the communication module;

[0083] Instantiate the AtCOP processor of the communication module and the power enable GPIO;

[0084] Instantiate the AtDaemon class thread, configure the serial port required for communicating with the communication block according to the hardware interface, and load the AtCOP processor driver of the communication module into the thread, thereby connecting the communication module and the MCU;

[0085] Create a thread to process the networking operation function in the AtCOP processor of the communication module and the subsequent network layer data processing after the socket connection.

[0086] Although embodiments of the present invention have been shown and described, it will be understood by those of ordinary skill in the art that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents and should be included within the scope of protection of the present invention.

Claims

1. An AT command processing system based on modular class inheritance, characterized in that, The system includes a basic parsing layer, an interaction control layer, a network function layer, and a device management layer; The basic parsing layer includes the AtCmd class that encapsulates the parsing logic and status update method of basic AT commands, and the AtURC class that inherits the AtCmd class and extends the storage and parsing of device active reporting commands; The interaction control layer includes the AtCop class that sends AT commands to the device through the serial port and parses the response to update the command status, and the AtUrcCoP class that inherits the AtCop class and calls the AtURC class to implement the real-time parsing and response of URC commands; The network function layer includes the AtSocket class for basic operations such as network socket connection and data transmission, and the AtSockCoP class that inherits the AtUrcCoP class and integrates socket status detection and URC parsing; The device management layer includes the AtHost class that binds the serial port driver to receive device data and forwards it to the AtCop class for parsing, and the AtDaemon class that encapsulates the operating system thread interface to asynchronously manage the AT device communication process.

2. The AT command processing system based on modular class inheritance according to claim 1, wherein The parsing function of the AtURC class is dynamically extended through secondary inheritance. Developers inherit the AtURC class and rewrite the parsing method for the URC command sets of different devices to adapt to the differential formats of device active reporting commands.

3. The AT command processing system based on modular class inheritance according to claim 1, wherein The AtDaemon class instantiates and configures the target serial port and AT module type to achieve independent operation and resource isolation of multi-device communication threads.

4. The AT command processing system based on modular class inheritance according to claim 1, characterized in that, When the AtSockCoP class detects a network anomaly, it automatically triggers the instruction resending mechanism of the AtCop class and parses the exception status code returned by the device through the AtURC class to update the socket connection status.

5. The AT command processing system based on modular class inheritance according to claim 2, wherein, The parsing process of URC commands includes: Matching the instruction prefix of the device reporting data through regular expressions; Extracting instruction parameters and storing them in a circular buffer; Calling the pre-registered class function to notify the interaction control layer for processing.

6. The AT command processing system based on modular class inheritance according to claim 1, characterized in that, The AtHost class parses the data when receiving device data.

7. The AT command processing system based on modular class inheritance according to claim 1, wherein The socket operation interfaces of the AtSocket class include: Dynamically generating TCP / UDP connection commands according to the AT instruction set; Monitoring data transmission timeouts and resending lost data packets; Parsing the IP address and port number returned by the device to update the socket configuration.

8. The AT command processing system based on modular class inheritance according to claim 1, characterized in that By inheriting the AtSockCoP class and implementing the exclusive AT instruction set of the target module, the communication module is quickly adapted, and the code logic of the basic parsing layer and the interaction control layer does not need to be modified during the adaptation process.

9. The AT command processing system based on modular class inheritance according to claim 1, characterized in that, When the instruction sending of the AtCop class fails, it automatically records the error type and the number of retries, and notifies the service layer to execute the degradation strategy through the AtDaemon class.

10. A method applied to an AT command processing system based on modular class inheritance as described in any one of claims 1 to 9, characterized in that, It includes the following steps: S1. Instruction sending and response parsing: Sending an AT instruction to the target device through the AtCop class, listening for data received by the serial port, parsing the response data returned by the device to judge the instruction execution status, and updating the instruction state machine in the AtCmd class; S2, URC command real-time detection: Regularly match the received data stream through the AtURC class, identify the URC command prefix actively reported by the device, extract the command parameters and store them in the buffer queue; S3, Dynamic parsing extension: When an unknown URC command is detected, call the subclass parsing method implemented by the developer inheriting the AtURC class to dynamically extend the URC command parsing logic; S4, Network socket management: Monitor the network connection status through the AtSockCoP class and respond to socket operations triggered by URC commands; S5, Threaded data processing: Create an independent thread through the AtDaemon class to run the data reception method of the AtHost class, and use a double buffer to separate the data reception and parsing processes; S6, Exception recovery mechanism: When the AtCop class detects that the instruction execution times out or the verification fails, automatically record the error log and trigger the retransmission of the instruction a preset number of times. If the retransmission fails, notify the business layer to execute the alternative strategy.