Message processing method, device and equipment

Abstract

The embodiment of the invention discloses a message processing method, device and equipment, which are applied to embedded equipment, the embedded equipment comprises a service process, a universal bus (UBUS) and an attention (AT) engine, the service process is in communication connection with the UBUS, and the AT engine is in communication connection with the UBUS; the method comprises the following steps: the service process sends a first message to the AT engine through the UBUS, wherein the first message comprises an AT command; and the AT engine processes the first message from the UBUS, and sends a processed result to the service process through the UBUS. By adopting the embodiment of the invention, a universal method for sending the AT command on the UBUS can be provided, so that the efficiency of sending the AT command is improved.

Description

Technical Field

[0001] This application relates to the field of embedded technologies, and in particular, to a message processing method, apparatus, and device. Background Art

[0002] Open Wireless Run-Time (OpenWRT) is an embedded Linux distribution designed for embedded devices (such as wireless routers), with highly modular and automated features, and powerful network components and scalability. The Open Computing Processing Unit (OpenCPU) project is usually used for embedded device development, especially in scenarios that require complex calculations and communication control. OpenWRT can provide a running environment for the OpenCPU project. Note that the AT (Attention) command is an instruction for connecting and communicating between a terminal device and a personal computer application. The AT engine is a program that processes AT command line requests, executes corresponding actions, and makes responses.

[0003] Currently, there is an OpenCPU project inside the modem running on the OpenWRT system. Since multiple processes may run in the OpenCPU project of the modem simultaneously, these processes need to cooperate with each other to complete the task of sending AT commands. When a process needs to send an AT command, it generally uses an inter-process communication (IPC) interface combined with Transmission Control Protocol (TCP) shared memory. The process that sends an AT command in this way will use the TCP connection or shared memory as the source of input data to the AT engine. Therefore, in most OpenCPU projects, an IPC router specifically developed for the AT engine is generally used to send AT commands to ensure that the AT commands can be effectively transmitted to the AT engine. However, in this way of sending AT commands, different users need to customize different private communication protocols, lacking universality.

[0004] Therefore, in the OpenWRT system, how to provide a general method for sending AT commands urgently needs to be solved. Summary of the Invention

[0005] Embodiments of this application provide a message processing method, apparatus, and device, which can provide a general method for sending AT commands on a Universal Bus (UBUS), thereby improving the efficiency of sending AT commands.

[0006] The present application will be introduced from different aspects below. It should be understood that the implementation manners and beneficial effects of the different aspects below can be referred to each other.

[0007] In a first aspect, an embodiment of the present application provides a message processing method. This method can be applied to an embedded device, which includes a service process, a general bus UBUS, and an attention AT engine. The service process is connected to the UBUS, and the AT engine is communicatively connected to the UBUS. The method includes:

[0008] The service process sends a first message including an AT command to the AT engine through the UBUS. The AT engine processes the first message received from the UBUS and sends the processed result to the service process through the UBUS.

[0009] In the embodiment of the present application, in the embedded device, the service process is communicatively connected to the UBUS. After the AT engine is communicatively connected to the UBUS, the service process can send a first message including an AT command to the AT engine through the UBUS. Moreover, after the AT engine processes the first message received from the UBUS, it sends the processing result back to the service process through the UBUS. Therefore, all service processes mounted on the UBUS can send AT commands to the AT engine through the UBUS, and the service process can obtain the response result of the AT engine, thereby providing a general method for sending AT commands on the UBUS bus and improving the efficiency of sending AT commands.

[0010] In combination with the first aspect, in a feasible implementation manner, the first message further includes the number of the AT engine. Before the service process sends the first message to the AT engine through the UBUS, the AT engine registers on the UBUS to obtain the number of the AT engine. The service process sending the first message to the AT engine through the UBUS includes: the service process sending the AT command to the AT engine through the UBUS according to the number of the AT engine. It can be realized that the service process can send an AT command to the AT engine through the UBUS according to the number corresponding to the AT engine, and the number corresponding to the AT engine can be broadcast to other task processes, thereby realizing a general method for sending AT commands.

[0011] In combination with the first aspect, in a feasible implementation manner, before the service process sends the first message to the AT engine through the UBUS, the service process obtains an AT command; the service process processes the AT command according to a predefined request message format to obtain a first message, and the format of the first message is the predefined request message format. Defining the format of the request message sent by the process can convert the message format sent to the UBUS into a request message format recognizable by the AT engine, which is beneficial to achieving data transmission compatibility.

[0012] In combination with the first aspect, in a feasible implementation manner, the embedded device further includes a user interface, and the user interface is communicatively connected to the service process; the service process receives an instruction from the user interface and processes the instruction to obtain the AT command, and the instruction includes the AT command. It can be added that the AT command is directly sent to the UBUS through the user interface, and the operation is more intuitive and concise.

[0013] In combination with the first aspect, in a feasible implementation manner, the AT engine extracts the command line in the first message from the UBUS to obtain the AT command; the AT engine parses the AT command and executes the operation corresponding to the AT command to obtain the processing result of the AT command.

[0014] In combination with the first aspect, in a feasible implementation manner, the AT engine processes the processing result of the AT command according to a predefined response message format to obtain a second message, and the format of the second message is the predefined response message format, and the second message includes the processing result; the AT engine sends the second message to the service process through the UBUS. The AT engine performs format conversion on the response message obtained after processing the AT command and returns it to the requester of the UBUS, which can achieve data transmission compatibility.

[0015] In combination with the first aspect, in a feasible implementation manner, the first message further includes the name of the AT engine; the second message further includes a boolean value of the asynchronous result code reporting status corresponding to the processing result.

[0016] In a second aspect, an embodiment of the present application provides a message processing device for executing the method in the first aspect or any possible implementation manner of the first aspect. The message processing device includes:

[0017] An input / output module for sending a first message including an AT command to an AT engine through the UBUS;

[0018] A processing module for processing the first message from the UBUS;

[0019] The input / output module is further configured to send the processed result to the service process through the UBUS.

[0020] In combination with the second aspect, in a feasible implementation manner, the first message further includes the number of the AT engine. The above message processing device further includes an acquisition module, and the acquisition module is configured to register on the UBUS to obtain the number of the AT engine; the input / output module is specifically configured to send the AT command to the AT engine through the UBUS according to the number of the AT engine.

[0021] In combination with the second aspect, in a feasible implementation manner, the acquisition module is further configured to: acquire an AT command, process the AT command according to a predefined request message format to obtain a first message, and the format of the first message is the predefined request message format.

[0022] In combination with the second aspect, in a feasible implementation manner, the input / output module is further configured to receive an instruction from the user interface; the processing module is further configured to process the instruction to obtain the AT command, and the instruction includes the AT command.

[0023] In combination with the second aspect, in a feasible implementation manner, the processing module is specifically configured to extract a command line from the first message from the UBUS to obtain the AT command; the processing module is specifically configured to parse the AT command and execute an operation corresponding to the AT command to obtain a processing result of the AT command.

[0024] In combination with the second aspect, in a feasible implementation manner, the processing module is further configured to process the processing result of the AT command according to a predefined response message format to obtain a second message, and the format of the second message is the predefined response message format, and the second message includes the processing result; the input / output module is further specifically configured to send the second message to the service process through the UBUS.

[0025] In combination with the second aspect, in a feasible implementation manner, the first message further includes the name of the AT engine; the second message further includes a Boolean value of the asynchronous result code reporting status corresponding to the processing result.

[0026] In a third aspect, an embodiment of the present application provides a message processing device. Here, the message processing device may be an embedded device, and the message processing device may include a processor and a memory, and the processor is connected to the memory. The memory is used to store a computer program, and the processor is used to call the computer program so that the message processing device executes the message processing method provided in the first aspect or any feasible implementation manner of the first aspect, and can also achieve the beneficial effects of the message processing method provided in the first aspect.

[0027] In combination with the third aspect, in a feasible implementation, the message processing device may further include a network interface. The network interface is coupled to the processor and the memory, and the network interface can be used to implement data communication functions.

[0028] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium for storing a computer program. When the computer program runs on the message processing device, the message processing device is caused to execute the message processing method provided by any one of the possible implementations of the first aspect or any aspect thereof, and can also achieve the beneficial effects of the message processing method of the first aspect. Description of the Drawings

[0029] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0030] Figure 1 is a schematic diagram of a system architecture provided by an embodiment of the present application;

[0031] Figure 2 is a schematic flowchart of a message processing method provided by an embodiment of the present application;

[0032] Figure 3 is a schematic diagram of the communication design between an AT engine and UBUS provided by an embodiment of the present application;

[0033] Figure 4 is a schematic flowchart of processing an AT command through UBUS provided by an embodiment of the present application;

[0034] Figure 5 is a schematic diagram of the structure of a message processing device provided by an embodiment of the present application;

[0035] Figure 6 is a schematic diagram of the structure of a message processing device provided by an embodiment of the present application. Detailed Embodiments

[0036] The following will clearly and completely describe the technical solutions in the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are some, but not all, of the embodiments of the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts fall within the scope of protection of the present application.

[0037] In the description of this application, unless otherwise specified, " / " means "or". For example, A / B can mean A or B. The "and / or" in this document is merely a relational description of associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, "at least one" means one or more, and "multiple" means two or more. "At least one of the following" or its similar expressions refer to any combination of these items, including any combination of single item or plural items. For example, at least one of a, b, or c can mean: a, b, c; a and b; a and c; b and c; or a and b and c. Where a, b, and c can be single or multiple.

[0038] In this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary", "for example", or "such as" in this application should not be construed as more preferred or more advantageous than other embodiments or design solutions. Rather, the use of words such as "exemplary", "for example", or "such as" is intended to present relevant concepts in a specific manner.

[0039] It should be understood that in this application, "when", "if", and "in case" all refer to the device making corresponding processing under certain objective circumstances, not limited to time, and it is not required that the device must have a judgment action when implemented, nor does it mean there are other limitations.

[0040] In this application, elements represented in the singular are intended to mean "one or more", rather than "one and only one", unless otherwise specified.

[0041] It can be understood that in the embodiments of this application, "B corresponding to A" means that there is a corresponding relationship between A and B, and B can be determined according to A. However, it should also be understood that determining B according to A does not mean determining B only according to A, and B can also be determined according to A and / or other information.

[0042] Currently, the ways for the device to send AT commands include Universal Asynchronous Receiver / Transmitter (UART), Universal Serial Bus (USB), Local Area Network / Wide Area Network (LAN / WAN), and TCP. Among them, UART is a serial communication protocol used for asynchronous data transmission between two devices. It is commonly found in embedded systems such as microcontrollers for communicating with external devices, and AT commands can be sent through UART in character form. USB is an external bus standard widely used in the computer field to standardize the connection and communication between a computer and external devices. It has features such as hot plugging and plug-and-play, and is commonly used to connect devices such as USB flash drives, external hard drives, mice, and keyboards. AT commands can be encapsulated in USB data frames for transmission. In the LAN / WAN environment, AT commands can be encapsulated in the data packets of network protocols for transmission. To send AT commands via TCP, a TCP connection first needs to be established between the sending device and the receiving device. The sending device acts as the client, and the receiving device acts as the server (or vice versa). The client initiates a TCP connection request by specifying the IP address and port number of the server. AT commands are transmitted as application layer data over the TCP connection. To send AT commands via TCP, a TCP connection first needs to be established between the sending device and the receiving device. The sending device acts as the client, and the receiving device acts as the server (or vice versa). The client initiates a TCP connection request by specifying the IP address and port number of the server. AT commands are transmitted as application layer data over the TCP connection.

[0043] In the development of some embedded systems, the OpenCPU project is a relatively common architecture model. OpenCPU allows developers to utilize the CPU resources of the chip to run custom software, rather than just relying on the original functions of the chip. Most OpenCPU projects develop an IPC router (Inter-Process Communication Router) for the AT engine in order to effectively send AT commands from one module to the AT engine for processing. In the OpenWRT environment, UBUS is an important communication mechanism. Most tasks are attached to UBUS, which means that UBUS has become the core hub for communication between various tasks or modules in the system. Since most tasks in the OpenWRT system already rely on UBUS for communication, it is necessary to design the function of sending AT commands based on UBUS as well.

[0044] The embodiments of the present application will be described below with reference to the accompanying drawings in the embodiments of the present application.

[0045] This application can be applied to Figure 1 the system architecture shown in, such as Figure 1 shown, the AT engine is communicatively connected to the UBUS. There are multiple functional modules (which can be referred to as service processes, application processes, etc.) on the UBUS. These functional modules can communicate with other functional modules on the UBUS through the UBUS. The UBUS is a logical bus and an Inter-Process Communication (IPC) mechanism, similar to a message bus and can also be called a general bus. The UBUS daemon interacts with the UBUS and can be responsible for managing and coordinating the communication between various processes. The bottom layer of the system is the Kernel, which is the core of the operating system and can be responsible for managing system resources such as hardware devices, memory, processes, etc., and can provide basic system services and resource access for the upper-layer UBUS daemon and functional modules.

[0046] Exemplarily, the functional modules may include the UBUS Command-Line Interface (Ubus-cli), the Network Interface Daemon (netifd), the Process Management Daemon (procd), the Lua Unified Configuration Interface (luci), luna (the execution body of the user interface for script interaction), or the Hypertext Transfer Protocol Daemon (httpd), etc. Among them, Ubus-cli is a command-line tool for interacting with UBUS. Through Ubus-cli, users can send requests, obtain system status information, etc. in the command line, facilitating system administrators or developers for debugging and management. Netifd is responsible for managing and configuring network interfaces. In network devices, netifd can handle tasks such as initialization of network interfaces, IP address allocation, and monitoring of network connection status to ensure the normal operation of network interfaces. Procd can be used to manage processes in the system, responsible for starting, stopping, restarting processes, and monitoring the running status of processes. In embedded systems or network devices, procd helps to ensure the stable operation of each process in the system. In network devices (such as routers), luci can provide an intuitive web user interface (WebUI) for configuring and managing various functions of the device, such as network settings, firewall rules, etc., and realizes the configuration function by reading and writing Unified Configuration Interface (UCI) configuration files. As the execution body of the Web UI, luna can be a key part in converting the operations of users on the web interface into actual execution actions. Luna contains a set of script mechanisms that allow different scripts to run and interact in the system. Httpd is a server program for implementing the Hypertext Transfer Protocol (HTTP). In a network environment, httpd can be responsible for receiving and processing HTTP requests from clients (such as browsers), and providing services such as web content and file downloads.

[0047] The user interface (User Interface, UI) is communicatively connected to the functional module (such as Figure 1As shown, the UI is communicatively connected to luci, Luna, and httpd respectively. The UI can interact with these functional modules, which can be by sending instructions through these functional modules to achieve user operation and control of the system. Exemplarily, the working process of this system architecture can be: when the user operates through the UI, the UI can interact with relevant functional modules (such as luci, Lua, or httpd). These functional modules can send AT commands to the AT engine through UBUS. The UBUS daemon process is responsible for coordinating and managing these communication processes.

[0048] It should be noted that Figure 1 the above system architecture or scenario is only an exemplary implementation manner in the embodiments of this application. The system architecture or scenario in the embodiments of this application includes but is not limited to the above system architecture or scenario.

[0049] I. UBUS

[0050] UBUS is a communication mechanism developed specifically for OpenWRT (an open-source operating system for embedded devices, mainly applied to network devices such as routers). UBUS can be used to implement communication between daemon processes and application programs in OpenWRT, aiming to provide system-level inter-process communication (IPC) or remote procedure call (RPC) functions. It is similar to the commonly used Desktop Bus (DBUS) in desktop systems, which is an inter-process communication mechanism widely used for software interaction in desktop environments. The design concept of UBUS is basically the same as that of DBUS, both aiming to solve the problem of inter-process communication. However, UBUS has a simplified application programming interface (API) and a more concise model. This design is to adapt to the special operating environment of embedded routers because the resources of embedded routers (such as memory, processing power, etc.) are relatively limited and require a simple and efficient communication method. Like DBUS, UBUS also uses Socket (a socket, which is an abstract representation of a network communication endpoint used for communication between different processes) to achieve communication.

[0051] The core part of UBUS is the UBUS daemon. This daemon provides an interface through which other daemons can register themselves and send messages. This interface is implemented by using Unix socket (a type of socket for inter - process communication in Unix systems). The message format adopts the Type - Length - Value (TLV, a data encoding format used to clearly represent the type, length, and actual value of data in communication). Inside UBUS, structures such as Blob_buf (a structure for storing data blocks) and Blob_attr (a structure for storing data block attributes) are used to represent messages and related data.

[0052] There are two calling methods in UBUS. One is the method call, and the other is the notification. The method call includes two cases. One is the calling method that waits for the function to return a result, just like a regular function call waiting for a return value; the other is the calling method that does not wait for a return, similar to an asynchronous call. The notification method is similar to the signal in DBUS and is a broadcast - style communication method used to send messages to multiple receivers without requiring the receivers to reply. The first step in using UBUS is to establish a connection, which can create a communication channel between different processes. After the connection is established, add this connection to the epoll set (epoll is an input / output (I / O) multiplexing mechanism in Linux used to efficiently handle I / O events of multiple file descriptors, and epoll set is the structure used to store the set of file descriptors) so that the state of the connection and the read - write events of data can be effectively monitored.

[0053] II. AT Commands

[0054] AT commands (Attention) are instructions specifically used to establish a connection and communicate between terminal devices (such as mobile phones, Internet of Things devices, etc.) and personal computer applications. It is like a special language through which terminal devices and personal computer applications transmit information and perform operations. Each AT command line can only contain one AT instruction, which ensures the clarity and accuracy of the instruction and avoids confusion and incorrect execution that may be caused by mixing multiple instructions.

[0055] AT commands were originally invented by Hayes. Hayes played a key role in the development of the communication field, especially in the development of dial-up modems (devices used to convert digital signals into analog signals for data transmission over telephone lines). In the era of dial-up modems, AT commands were mainly used to control various operations of the modems. For example, users could control the modem to dial, answer calls, hang up calls, etc. by entering AT commands on terminal devices (such as computers), and could also set communication parameters of the modem, such as baud rate (data transmission rate), parity bits, etc. With the continuous progress of technology, the network bandwidth has been greatly upgraded. Although modern communication technologies have changed dramatically compared with the early dial-up modem era, AT commands are still retained. In embedded development (a development method of integrating computer systems into other devices, which are usually not traditional computers, such as smart home devices, industrial control devices, etc.), AT commands play an important role. It is widely used to control various communication modules. In embedded systems, AT commands provide developers with a simple and effective way to control communication modules, enabling these modules to work according to predetermined requirements, thus realizing communication between devices and external networks or other devices.

[0056] III. AT Engine

[0057] In communication devices such as modems running the OpenWRT system, the AT engine is a key component. It is mainly used to process AT commands, just like a dedicated "interpreter" and "executor". When a process in the device needs to interact with an external communication module, especially when sending and receiving AT commands to control communication functions, the AT engine plays a core role. The AT engine receives AT command lines through a specific input source. After receiving the AT command lines, the AT engine parses and executes the AT command lines.

[0058] In a modem running the OpenWRT system, there is an internal OpenCPU project ("Open" means open. In this project, OpenCPU opens the system interfaces outward. This enables external developers, other software systems or devices to access and use these interfaces). In the prior art, in the inter-process communication (IPC) scenario of the OpenCPU project, when an AT command needs to be sent, the AT engine is like a transfer station or execution hub, responsible for receiving AT command lines sent from processes using TCP or shared memory as input sources and processing these AT commands.

[0059] The following further describes a message processing method, device and equipment provided by the embodiments of the present application:

[0060] Please refer to Figure 2 , Figure 2 which is a schematic flowchart of a message processing method provided by an embodiment of the present application. The method includes steps S201 - S202. Figure 2 The method shown can be applied to an embedded device, which includes a service process, UBUS, and an AT engine. The service process is communicatively connected to the UBUS, and the AT engine is communicatively connected to the UBUS;

[0061] Wherein:

[0062] S201. The service process sends a first message including an AT command to the AT engine through the UBUS.

[0063] In a possible implementation, the service process is the sender of the first message, and the AT engine is the receiver of the first message. The service process can be a functional module connected to the UBUS and capable of message transmission through the UBUS. For example, such as Figure 1 Ubus-cli, netifd, procd, luci, luna, or httpd shown

[0064] In a possible implementation, the first message further includes the name of the AT engine. In the embodiments of the present application, before the service process sends the first message to the AT engine through the UBUS, the first message is processed according to a predefined request message format. The predefined request message format of the first message may be in the (JavaScript Object Notation, JSON) format. JSON is a lightweight data exchange format. It is based on a subset of JavaScript but can be used by multiple programming languages, including Python, Java, C#, etc. JSON represents structured data in a text format that is easy for humans to read and write and is also easy for machines to parse and generate. Exemplarily, the JSON format definition of the first message may be {"engine":"String","atcmd":"String"}, where "engine" may represent the name sent to the AT engine, existing in the form of string encoding, and is used to distinguish different AT engines. "atcmd" may represent the content of a specific AT command line. It may be a simple single "AT" character (usually used to test whether the device responds), or a complex composite command line string. For example, "AT+CMGS=\"138xxxx5678\",\"Hello World\"" is a composite AT command for sending the short message "Hello World" to the mobile phone number "138xxxx5678". When the system needs to perform the operation of sending a short message, this command will be included in "atcmd" and then sent to the corresponding AT engine for execution. The predefined request message format may be a predefined standard data structure, used to ensure accurate and orderly communication and interaction between different modules. It can stipulate the order, content type, and specific representation form of each part in the message, etc.

[0065] In a possible implementation, the first message further includes the number of the AT engine; before the service process sends the first message to the AT engine through the UBUS, the AT engine registers on the UBUS to obtain the number of the AT engine; the service process sending the first message to the AT engine through the UBUS includes: the service process sending the AT command to the AT engine through the UBUS according to the number of the AT engine. Exemplarily, the AT engine registering on the UBUS can be understood as the AT engine registering an operation object on the UBUS. For the AT engine, this operation object becomes the "identity identifier" for communication of the AT engine on the UBUS, facilitating other functional modules to send request messages or request services to the AT engine. After the AT engine registers on the UBUS, the AT engine can obtain a unique number (i.e., the number of the AT engine). This number can be generated according to certain rules when the AT engine registers, such as sequential numbering or generation based on a certain hash algorithm. Then, when the service process sends an AT command to the AT engine, it can locate the AT engine in the UBUS according to the obtained number of the AT engine. The service process can utilize the communication mechanism provided by the UBUS to establish a connection with the AT engine through the number of the AT engine. Among them, the UBUS can be responsible for handling the underlying communication details to ensure that the data in the first message can be accurately transmitted from the service process to the AT engine. For example, the service process can encapsulate the AT command to be executed into a data format conforming to the UBUS protocol and then send it to the AT engine through the connection established with the AT engine through the number of the AT engine.

[0066] In a possible implementation, the AT engine is registered on UBUS and communicates with UBUS. The API interfaces available on UBUS that can be called may include uloop_init(); fdubus_connect(); ubus_add_uloop(); ubus_add_object(); uloop_run(); ubus_free(); uloop_done(), etc. Among them, the uloop_init() function can be used to create an epoll handle. Epoll is an I / O event notification mechanism in the Linux kernel and is used to monitor file descriptors (fds) in this scenario. Here, it is set to monitor up to 32 fds, which means that in the system of an embedded device, the status changes of 32 different I / O sources (such as network connections, file reads and writes, etc.) can be simultaneously monitored. The uloop_init() function is the basis for the entire registration and connection process. In the communication environment of an embedded device, the AT engine requires an efficient way to handle multiple possible I / O events, and the epoll handle provides such a mechanism. By restricting the number of monitored fds, the use of resources can be controlled to a certain extent to avoid over-occupying system resources and causing performance degradation. The role of the ubus_connect() function is to create a UBUS connection. Through this connection, the AT engine can access UBUS. The AT engine establishes a communication bridge with UBUS through this connection, enabling subsequent data exchange and interaction with other functional modules connected to UBUS. The ubus_add_uloop() can register the previously created UBUS connection into epoll. The epoll mechanism monitors the status of the registered connections. When an I / O event occurs on this UBUS connection, epoll can sense it. When a message is transmitted to the AT engine or sent out from the AT engine through the UBUS connection, epoll can detect it in time and notify the relevant handling functions for processing. The ubus_add_object() function is used to register an object on the UBUS connection. This object can contain various attributes, methods, or data structures of the AT engine. By registering this object, other functional modules can access and operate on this object through the UBUS connection and interact with it according to the rules defined by the object. For example, other modules may call the functional functions of the AT engine through this object to execute AT commands or obtain the status information of the AT engine, etc. The uloop_run() function can put the system into a state of waiting for I / O events to occur. Once an I / O event occurs, such as a request message arriving on the UBUS connection or other modules requesting access to the object registered by the AT engine, the system in the embedded device can call the functional functions of the corresponding object to handle these events. The ubus_free() function is used to close the UBUS connection.This function can be called when the AT engine no longer needs to communicate with UBUS, or when the system wants to end the connection between the AT engine and UBUS. The uloop_done() function is used to close the epoll handle. After the UBUS connection has been closed, there is no longer a need for epoll to monitor the relevant fds, so the epoll handle needs to be closed. This can release the system resources occupied by the previously created epoll, restoring the system to its initial state or preparing it to enter the next task phase.

[0067] In a possible implementation, before the service process sends the first message to the AT engine via UBUS, the service process obtains an AT command, and there are various ways for the service process to obtain the AT command. For example, a staff member directly sends an AT command to the service process, or the service process receives an AT command converted from an operation instruction from the user interface. The service process processes the AT command according to a predefined request message format to obtain the first message, and the format of the first message is the predefined request message format. The service process first needs to determine which AT engine to send the AT command to. For example, if the name of the AT engine is "AT_Engine_001", the service process can fill the name "AT_Engine_001" into the "engine" field according to the predefined request message format ({"engine":"String","atcmd":"String"}). The service process puts the obtained AT command into the "atcmd" field. For example, if the AT command obtained by the service process is "AT+CMGS=\"138xxxx5678\",\"Hello World\"" (a command for sending a text message), this command string will be completely put into the "atcmd" field. The service process constructs the first message that conforms to the predefined format by combining the values of the determined "engine" and "atcmd" above. For example, the constructed first message can be {"engine":"AT_Engine_001","atcmd":"AT+CMGS=\"138xxxx5678\",\"Hello World\""}. This first message can be sent to the corresponding AT engine via UBUS, and after receiving the message, the AT engine can parse out the target engine name and the AT command to be executed according to this format.

[0068] In a possible implementation, the embedded device further includes a user interface, which is communicatively connected to the service process; the service process receives an instruction from the user interface, processes the instruction to obtain the AT command, and the instruction includes the AT command. The user interface and the service process can be communicatively connected in an event-driven manner. For example, in a graphical user interface, when the user clicks a button, selects a menu option, or enters content in a text box, etc., operations that include the AT command, the user interface will generate corresponding events, and these events will be passed to the service process associated with the user interface. For example, the service processes associated with the user interface may include luci, luna, and httpd, etc. After the service process receives the instruction from the user interface, it parses the instruction and extracts information related to the AT command from it. Then the service process encapsulates the information related to the AT command in JSON format to obtain the above-mentioned first message.

[0069] S202. The AT engine processes the first message from the UBUS and sends the processed result to the service process through the UBUS.

[0070] In a possible implementation, the AT engine extracts the command line from the first message from the UBUS to obtain the AT command; the AT engine parses the AT command and executes the operation corresponding to the AT command to obtain the processing result of the AT command. Exemplarily, the first message is sent in a predefined request message format of {"engine":"String","atcmd":"String"}. After the AT engine receives the first message from the UBUS, it can access the "atcmd" field in the first message through a JSON parsing library, and this field contains the AT command line. The content extracted by the AT engine can be a simple "AT" command or a complex composite command, such as "AT+CMGS=\"138xxxx5678\",\"Hello World\"". In addition, the AT engine can perform syntax analysis on the extracted AT command and classify it according to the type of the AT command. There can be multiple types of AT commands for different operations, such as device configuration, data sending / receiving, status query, etc. For example, "AT+CSQ" can be a command for querying signal strength, and "AT+CGMI" can be a command for querying device manufacturer information. According to the command type, the AT engine can call the corresponding internal functional modules or functions to execute the operation. For example, if it is a command for sending a short message, the AT engine can call the module related to short message sending. This module can interact with the modem of the embedded device, pass information such as the short message content and the receiving number to the modem, and then send the short message through the communication network.

[0071] In a possible implementation, the AT engine processes the processing result of the AT command according to a predefined response message format to obtain a second message. The format of the second message is the predefined response message format, and the second message includes the processing result. The AT engine sends the second message to the service process through the UBUS. Exemplarily, the predefined response message format can be {"Response":"String","URC":"bool"}, where "Response" can be used to store the synchronous return result of the AT command line, and its data type is a string. Exemplarily, when the AT engine finishes executing the AT command, it can obtain the synchronous return result. For example, for the AT command "AT+CSQ" to query the signal strength, the modem may return a result in the form of a string, such as "+CSQ:20,0", indicating the values related to the signal strength. The AT engine can directly fill this synchronous return result into the "Response" field. "URC" can be used to represent the reporting status of the Unsolicited Result Code (URC) of the AT command, and its data type is a boolean value. False (error) means that no URC data arrives; true (correct) means that it is necessary to wait for the URC, and the subscribed object will send a URC message. During the process of the AT engine executing the AT command, in addition to the synchronous response to the command (i.e., the immediately returned execution result), some asynchronous event notifications can also be generated. These asynchronous event notifications appear in the form of URCs. They are not the results actively requested by the embedded device, but the status information automatically sent by the embedded device during certain operations. For example, in the scenario of sending a short message, when the short message is sent successfully or fails to be sent, the modem may send a URC to notify the relevant system components of the sending status of the short message. This notification is not obtained because the system actively queries the sending status of the short message, but is actively sent by the modem according to its own operation result. In the system, there may be multiple functional modules or components interested in the URC message. To receive the URC message, these functional modules or components can become subscribed objects. When a functional module (subscribed object) wants to receive the URC message, it first registers to indicate which types of URC messages it is interested in. For example, a module for monitoring the sending status of short messages may register a subscription to the URC messages related to the sending of short messages.

[0072] In a possible implementation, the second message further includes a boolean value indicating the reporting status of the asynchronous result code corresponding to the processing result. The AT engine can determine the reporting status of the URC based on the nature and execution of the AT command. If, after completing the current synchronous operation, it is expected that no other asynchronous messages will be generated for the executed AT command, the URC field is set to false. For example, for a simple query command (such as "AT+CGMI" to query the device manufacturer information), usually no other asynchronous messages will follow after the synchronous result is returned, so the URC is set to false. If the executed AT command can trigger subsequent asynchronous events, for example, a command to send a short message ("AT+CMGS="138xxxx5678","Hello World""), there will be an asynchronous status report during or after the short message is sent (such as a notification of successful or failed short message sending). In this case, the URC field needs to be set to true. And if there are objects in the system that subscribe to relevant asynchronous messages (such as a business process may subscribe to the notification of the short message sending status), then these subscribed objects will receive the URC message. According to the above judgment of the AT engine, the corresponding boolean value (true or false) can be assigned to the "URC" field (a boolean value indicating the reporting status of the asynchronous result code corresponding to the processing result).

[0073] In a possible implementation, the AT engine can combine the filled "Response" and "URC" fields to construct the second message in the predefined response message format. For example, if the value of the Response field is "+CSQ:20,0" and the value of the "URC" field is false, then the constructed second message is {"Response":"+CSQ:20,0","URC":false}. Using the communication connection with UBUS, the AT engine can send the constructed second message back to the business process. This sending process is similar to the mechanism of receiving messages through UBUS before, and the sending of this second message is completed by calling the interface provided by UBUS. After receiving the second message, the business process can parse the predefined response message format to obtain the processing result and the boolean value indicating the reporting status of the asynchronous result code corresponding to the processing result.

[0074] In the embodiments of the present application, the embedded device includes a business process, a general bus UBUS, and an AT engine. The business process is communicatively connected to the UBUS, and the AT engine is communicatively connected to the UBUS. The business process sends the first message including the AT command to the AT engine through the UBUS. The AT engine processes the first message received from the UBUS and sends the processed result to the business process through the UBUS. A general method for sending AT commands on the UBUS can be provided, thereby improving the efficiency of sending AT commands.

[0075] Exemplarily, see Figure 3 , Figure 3 which is a schematic diagram of the communication design between an AT engine and UBUS provided by an embodiment of the present application. As Figure 3 shown, UBUS 310 is communicatively connected to the AT engine 320. The AT engine 320 may include an AT command parser (ATParser) 323 and a UBUS task polling module (Uloop) 321. Communication between the Uloop 321 and the AT Parser 323 is performed through a socketpair (socket channel) or other message channels, and the processes of AT command requests and responses are processed. The core is to pass the request message (i.e., the first message) received from the UBUS 310 to the AT Parser 323 for processing and return the processing result to the requester of the UBUS 310. Among them, the JSON format defined by the request message (i.e., the first message) is the content in the request (Request) message body module 322: {"engine": "String", "atcmd": "String"}, where "engine" specifies the name of the AT engine, and "atcmd" is the specific AT command line. The Uloop 321 is a module that waits for the arrival of the request message. Its main function is to wait for the request message (i.e., the first message) transmitted from the UBUS 310. When the request message (i.e., the first message) arrives, the request message (i.e., the first message) is stored as a Binary Large Object (BLOB). The request message from the UBUS 310 arrives together with a callback function, and the Uloop 321 will receive the JSON data string from the BLOB message body. After obtaining the AT command line from the first message, the AT engine 320 performs data conversion on the AT Parser 323 and sends the obtained AT command line to the AT Parser 323 for processing. During this process, a pair of socketpairs is created simultaneously for communication between the Uloop 321 and the AT Parser 323. The socketpair consists of two sockets, namely Sockfd[0] and Sockfd[1], as Figure 3As shown, Sockfd[0] is connected to Uloop321, and Sockfd[1] is connected to ATParser323. Uloop321 can send the first message to ATParser323 through Sockfd[0]. The AT engine 320 can extract the AT command line from the first message, and ATParser323 receives the AT command line through Sockfd[1]. Therefore, ATParser323 has external input and output interfaces (input and output), and docks the data interface through a pair of anonymous connectionless sockets (Sockfd[0] and Sockfd[1] in socketpair). After processing the data, ATParser323 can generate response data (processing result) and send the response data back to UBUS310 through Sockfd[0] and Sockfd[1]. Uloop321 receives the response message (i.e., the second message) sent from Sockfd[1] of ATParser323 through Sockfd[0]. Among them, the response module 324 is used to feedback the processing result of ATParser323, and the processing result is in the JSON format of the response message: {"Response":"String","URC":"bool"}. The receiving response module 325 is used to receive the response message (i.e., the second message) sent from Sockfd[1] of ATParser323. After receiving the response message, Uloop321 can convert it into the JSON format and push it into the BLOB data block. Finally, the BLOB data block containing the response message (i.e., the second message) is returned to the requester of UBUS310.

[0076] Figure 3 The entire communication process is that Uloop321 receives and processes the request message (i.e., the first message) from UBUS310. Through the socketpair communication mechanism, the AT command line extracted from the request message (i.e., the first message) is passed to ATParser323 for processing. ATParser323 converts the processed result into an appropriate response format message (i.e., the second message) and returns it to the requester of UBUS310. It can achieve effective processing and communication of AT commands in the UBUS environment.

[0077] Exemplarily, please refer to Figure 4 , Figure 4 which is a schematic diagram of the process of processing AT commands through UBUS provided by an embodiment of the present application. As Figure 4As shown, starting from system initialization, after socket allocation by the AT engine and UBUS object registration, it enters the Uloop loop to wait for and process UBUS request data blocks. It reads the request data through Blob, extracts AT commands, parses and executes operations through ATparser. After receiving the operation response, it encapsulates the response result into JSON format and returns it to the requester on UBUS.

[0078] Init represents initialization. In this stage, the system performs initialization operations and powers on, including system kernel initialization, initialization of various functional modules, AT engine initialization, etc. "The AT engine allocates sockfd[1]" can mean that the AT engine obtains a channel number. After initialization, the system can allocate a socket file descriptor (sockfd[1]) for the AT engine, and the socket file descriptor can be used for communication between various modules inside the AT engine. "UBUS object registration" can mean that the AT engine registers an operation object on UBUS, enabling other functional modules or service processes on UBUS to send messages to the AT engine through UBUS, and the AT engine can obtain request messages from UBUS. The AT engine includes "Uloop (UBUS task polling module)", Uloop is connected to UBUS, and the AT engine starts the task polling of UBUS. UBUS can check the status of each task in a certain order and time interval to see if there are tasks or events that need to be processed. In addition, the AT engine has a corresponding operation object on UBUS, and this operation object is an abstract representation of the AT engine in the UBUS communication system, which can contain various attributes, methods, and data related to the AT engine. Uloop polls the operation object corresponding to the AT engine to check if the tasks associated with this operation object need to be executed. "UBUS requests a data block" can be understood as sending a request to other functional modules or service processes on UBUS to obtain a specific data block. This data block can be understood as the first message, containing the AT command to be executed. "Blob reads the request data" can mean reading the request data from a binary data object. After obtaining the data block through UBUS, the AT engine can read the relevant request data from this data block (stored in the form of Blob). "Extract ATCMD from JSON" means that during the system processing, data can be encapsulated and transmitted in JSON format. The AT engine can parse the specific AT command line from the JSON data and pass the extracted AT command line to "ATparser (AT command parser)". This AT command parser can parse and understand the meaning of the AT command and perform corresponding processing. After the AT command parser parses the command, it executes the corresponding AT operation (AT exec). This step actually performs specific operations according to the obtained AT command line, which can include interactions with hardware devices, data processing, etc. During or after the execution of the AT operation, data is received through the socket file descriptor (Sockfd[0]receive). This data can be the result of the AT engine operation or other relevant feedback information. The received data is used as the response of the AT engine operation (AT response), and this response can contain the execution result, status information, etc. of the AT engine operation.Then, encapsulate the AT response data into JSON format, which can facilitate data transmission and processing, and wrap the response data in standard JSON format (referring to encapsulating JSON). Finally, return the encapsulated JSON-formatted response data to the requester. Figure 4 Shows the entire process from receiving a request message to processing the request message and returning a response message.

[0079] Exemplarily, the UBUS task object can be defined as: object_name: atcmd; the task object operation method can be defined as: exec (indicating that the client executes the command line parameter for sending AT of exec); the URC subscription object can be defined as: atcmd_urc (indicating that the client subscribes to the URC object atcmd_urc and receives the execution result of the asynchronous command). The JSON format of the request message can be defined as: {"engine": "String", "atcmd": "String"}, where engine represents the name sent to the AT engine, encoded as a string. atcmd represents the AT command line, the command line string of a single-word AT or a composite AT. The JSON format of the response message can be defined as: {"Response": "String", "URC": "bool"}, where Response represents the synchronous return result of the AT command line. URC represents the reporting status of the asynchronous URC of the AT command. False represents that no URC data has arrived, and true means waiting for URC, and subscribing to the object will send URC messages.

[0080] Exemplarily, the following code can be used to define objects, object types, and methods related to AT commands in a UBUS-based system. Specifically, it can define how to handle messages related to AT commands (through atcmd_policy), define the method for performing operations related to AT commands (the "exec" method in atcmd_methods), and define related UBUS objects and object types (atcmd_type and atcmd_obj). The above definitions can be used to implement a module (such as an AT engine) that can handle AT commands in a UBUS system. For example, in the OpenWRT system of an embedded device, control and execute AT command operations through UBUS.

[0081]

[0082]

[0083]

[0084] Exemplarily, assume a terminal command line interface in a Unix-like system (such as Linux). The following commands are for interacting with the atcmd object using the UBUS command line tool.

[0085] / dev#ubus - v list atcmd

[0086] / / Lists the detailed information of the atcmd object. The - v option indicates to display detailed information

[0087] ‘atcmd’@da732439

[0088] / / Represents the identifier of the atcmd object

[0089] "exec":{"engine":"String","atcmd":"String"}

[0090] / / Here, a method named "exec" is defined. This method accepts two parameters: "engine" and "atcmd", both of which are of the string data type.

[0091] / dev#ubus call atcmd exec '{"engine":"ffv","atcmd":"ati"}'

[0092] / / Uses ubus to call the exec method of the atcmd object and passes parameters.

[0093] "response":"ati\r\nManufacturer:XXX.\r\nModel:XXX\r\nRevision:XXX\r\nIMEI:\r\n+GCAP:+CGSM\r\nOK\r\n"

[0094] / / The call result shows information such as the manufacturer, model, revision, IMEI, and network capabilities of the device. The response has "response" as the key, followed by the information returned by the device

[0095] / dev#ubus call atcmd exec '{"engine":"ffv","atcmd":"at+ops?"}'

[0096] / / Calls the exec method of the atcmd object again, passing different atcmd parameters

[0097] "response":"at+ops?\r\n+OPS:0\r\nOK\r\n"

[0098] / / This call returned information about the operation status (+OPS).

[0099] / dev#ubus call atcmd exec '{"engine":"ffv","atcmd":"at+cgmr"}'

[0100] / / Continue to call the exec method of the atcmd object, passing different atcmd parameters

[0101] "response":"at+cgmr\r\nXXX\r\nOK\r\n"

[0102] / / Returned the software version information of the device

[0103] / dev#ubus call atcmd exec '{"engine":"ffv","atcmd":"at+creg"}'

[0104] / / Call the exec method of the atcmd object, passing different atcmd parameters

[0105] "response":"at+creg\r\nERROR\r\n"

[0106] / / This call returned an error message

[0107] / dev#ubus call atcmd exec '{"engine":"ffv","atcmd":"at+creg?"}'

[0108] / / Call the exec method of the atcmd object again, passing different atcmd parameters

[0109] "response":"at+creg?\r\n+CREG:0,255\r\nOK\r\n"

[0110] / / Returned information about the registration status (+CREG)

[0111] In the above script of the embodiments of the present application, it shows how to use the UBUS tool to interact with the atcmd object. By calling the exec method and passing different atcmd parameters, various status information, version information, etc. of the device can be obtained, and at the same time, it also exemplarily shows that error situations may be encountered.

[0112] The method of the embodiments of the present application is elaborated in detail above. Below, the device of the embodiments of the present application is provided.

[0113] Please refer toFigure 5 , Figure 5 is a schematic structural diagram of a message processing device provided by an embodiment of the present application. The message processing device may include:

[0114] An input / output module 501, configured to send a first message including an AT command to the AT engine through the UBUS;

[0115] A processing module 502, configured to process the first message from the UBUS;

[0116] The input / output module 501 is further configured to send the processed result to the service process through the UBUS.

[0117] In a feasible implementation, the first message further includes the number of the AT engine. The above message processing device further includes an acquisition module 503, configured to register on the UBUS to obtain the number of the AT engine; the input / output module 501 is specifically configured to send the AT command to the AT engine through the UBUS according to the number of the AT engine.

[0118] In a feasible implementation, the acquisition module 503 is further configured to: the service process acquires an AT command, processes the AT command according to a predefined request message format to obtain a first message, and the format of the first message is the predefined request message format.

[0119] In a feasible implementation, the input / output module 501 is further configured to receive an instruction from the user interface; the processing module 502 is further configured to process the instruction to obtain the AT command, and the instruction includes the AT command.

[0120] In a feasible implementation, the processing module 502 is specifically configured to extract a command line from the first message from the UBUS to obtain the AT command; the processing module 502 is specifically configured to parse the AT command and execute an operation corresponding to the AT command to obtain a processing result of the AT command.

[0121] In a feasible implementation, the processing module 502 is further configured to process the processing result of the AT command according to a predefined response message format to obtain a second message, and the format of the second message is the predefined response message format, and the second message includes the processing result; the input / output module 501 is further specifically configured to send the second message to the service process through the UBUS.

[0122] In a feasible implementation, the first message further includes the name of the AT engine; the second message further includes a Boolean value of the asynchronous result code reporting status corresponding to the processing result.

[0123] In a specific implementation, the above message processing device may execute the above Figure 2 steps or methods executed in the illustrated embodiments to implement the functions implemented in the above method embodiments. For specific details, please refer to the Figure 2 corresponding descriptions provided in each step of the illustrated method embodiments above, which will not be elaborated here.

[0124] In the embodiments of the present application, the input / output module 501 is used to send a first message including an AT command to the AT engine through the UBUS. The processing module 502 is used to process the first message from the UBUS. The input / output module 501 is further used to send the processed result to the service process through the UBUS. A general method for sending AT commands on the UBUS can be provided, thereby improving the efficiency of sending AT commands.

[0125] Please refer to Figure 6 , Figure 6 which is a schematic structural diagram of a message processing device provided by an embodiment of the present application. It can be used to implement the steps of the message processing method described in any of the above embodiments. The message processing device may include: a processor 601, a memory 602, a network interface 603, and a bus system 604.

[0126] The memory 602 includes, but is not limited to, RAM, ROM, EPROM, or CD-ROM. The memory 602 is used to store relevant instructions and data. The memory 602 stores the following elements, executable modules, or data structures, or subsets thereof, or extended sets thereof:

[0127] Operation instructions: including various operation instructions for implementing various operations.

[0128] Operating system: including various system programs for implementing various basic services and processing hardware-based tasks.

[0129] The memory 602 further includes a network communication module, a user interface module, a device control application program, etc.

[0130] Figure 6 Only one memory is shown in [[ ]], and of course, the memory can also be set to multiple according to needs.

[0131] The processor 601 may be a controller, a CPU, a general-purpose processor, a DSP, an ASIC, an FPGA, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logic blocks, modules, and circuits described in connection with the disclosed content of the embodiments of the present application. For example, in Embodiment 1, the AT engine processes the first message from the UBUS. The processor 601 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and so on.

[0132] The network interface 603 can provide network communication functions and may optionally include a standard wired interface, a wireless interface (such as a WI-FI interface). For example, it can be applied to a router in the embodiments of the present application.

[0133] In a specific application, the various components of the message processing device are coupled together through a bus system 604. The bus system 604 may include, in addition to a data bus, a power bus, a control bus, a status signal bus, and so on. However, for the sake of clarity, in Figure 6 all kinds of buses are labeled as the bus system 604. For ease of representation, Figure 6 it is only schematically shown in

[0134] It should be noted that in practical applications, the processor in the embodiments of the present application may be an integrated circuit chip with signal processing capabilities. In the implementation process, the steps of the above method embodiments can be completed by the hardware integrated logic circuit or software-form instructions in the processor. The above-mentioned processor may be a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application.

[0135] It can be understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable ROM (PROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM), and direct rambus RAM (DRRAM). It should be noted that the memory described in the embodiments of the present application is intended to include but not limited to these and any other suitable types of memory.

[0136] Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0137] In summary, the above description is only a preferred embodiment of the technical solution of the present application, and is not intended to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A message processing method, characterized in that: Applied in an embedded device, the embedded device includes a business process, a universal bus UBUS and an AT engine, the business process is connected to the UBUS for communication, and the AT engine is connected to the UBUS for communication; the method includes: The service process sends a first message to the AT engine through the UBUS, where the first message includes an AT command; The AT engine processes the first message from the UBUS, and sends the processed result to the service process through the UBUS.

2. The method according to claim 1, characterized in that The first message also includes the serial number of the AT engine; before the service process sends the first message to the AT engine through the UBUS, the method includes: The AT engine is registered on the UBUS to obtain the number of the AT engine; The service process sends the first message to the AT engine through the UBUS, including: The service process sends the AT command to the AT engine through the UBUS according to the number of the AT engine.

3. The method according to claim 1, characterized in that Before the service process sends the first message to the AT engine through the UBUS, the method further includes: The service process obtains an AT command; The service process processes the AT command according to a predefined request message format to obtain a first message, where the format of the first message is the predefined request message format.

4. The method according to claim 3, characterized in that The embedded device further includes a user interface, and the user interface is communicatively connected with the business process; the business process acquires an AT command, including: The service process receives an instruction from the user interface, processes the instruction, and obtains the AT command, wherein the instruction includes the AT command.

5. The method according to any one of claims 1 to 4, characterized in that The AT engine processes the first message from the UBUS, including: The AT engine extracts the command line in the first message from the UBUS to obtain the AT command; The AT engine parses the AT command, executes an operation corresponding to the AT command, and obtains a processing result of the AT command.

6. The method according to claim 5, characterized in that The sending the processed result to the business process via the UBUS includes: The AT engine processes the processing result of the AT command according to a predefined response message format to obtain a second message, where the format of the second message is the predefined response message format, and the second message includes the processing result; The AT engine sends the second message to the service process through the UBUS.

7. The method according to claim 6, characterized in that The first message also includes the name of the AT engine; the second message also includes a Boolean value of the asynchronous result code reporting status corresponding to the processing result.

8. A message processing device, characterized in that: include: An input / output module, configured to send a first message to an AT engine via UBUS, wherein the first message includes an AT command; A processing module, configured to process the first message from the UBUS; The input / output module is also used to send the processed result to the business process through the UBUS.

9. A message processing device, characterized in that: include: Processor and memory; The processor is connected to the memory, wherein the memory is used to store a computer program, and the processor is used to call the computer program so that the message processing device executes the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which is loaded and executed by a processor, so that a message processing device having the processor executes the method according to any one of claims 1 to 7.

Images