Data communication method and apparatus, electronic device, and storage medium

Abstract

Embodiments of the present application provide a data communication method and device, electronic equipment and storage medium. The method comprises: in response to a data transmission request, collecting a plurality of register data of a terminal device; according to the continuity of the plurality of register data, classifying and processing the plurality of register data to obtain a plurality of register data groups; encapsulating each register data group according to a type length value as a frame structure rule to obtain a plurality of data packets; splicing the plurality of data packets and a target protocol header to obtain a service message; and sending the service message to a receiving end. The above scheme classifies and structurally encapsulates register data, compresses register data originally requiring multiple rounds of message interaction into a single frame message, reduces the number of communications, and thus improves communication efficiency.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a data communication method, apparatus, electronic device and storage medium. Background Technology

[0002] In scenarios such as industrial IoT, smart homes, and energy management, the efficiency of data communication between terminal devices and business platforms is crucial.

[0003] In related technologies, terminal devices and service platforms follow the same message frames and conduct data communication under the constraints of fixed-format message frames.

[0004] However, this method is inefficient when reading and writing non-contiguous register data. Summary of the Invention

[0005] This application provides data communication methods, apparatus, electronic devices, and storage media to improve communication efficiency.

[0006] In a first aspect, embodiments of this application provide a data communication method, comprising: in response to a data transmission request, collecting multiple register data from a terminal device; classifying the multiple register data according to their continuity to obtain multiple register data groups; encapsulating each register data group according to a frame structure rule of type length value to obtain multiple data packets; concatenating the multiple data packets with a target protocol header to obtain a service message; and sending the service message to a receiving end.

[0007] In one possible implementation, the plurality of register data is classified to obtain a plurality of register data groups, including: determining the register address corresponding to each register data from the plurality of register data; merging register data with consecutive register addresses into a register data group; and dividing register data with discrete register addresses into independent register data groups to obtain the plurality of register data groups.

[0008] In one possible implementation, each register data group is encapsulated according to the type length value as a frame structure rule to obtain multiple data packets. This includes: determining the frame structure of the data packets based on the type length value, wherein the frame structure includes a start address identifier field, a register quantity field, and a service data payload field, wherein the register quantity field includes the most significant bit bit operation flag, the second most significant bit error response flag, and the remaining valid value bits; and encapsulating each register data group according to the frame structure to obtain the multiple data packets.

[0009] In one possible implementation, according to the frame structure, each register data group is encapsulated to obtain the plurality of data packets, including: configuring a bitmask field in the frame structure; establishing a mapping relationship between a plurality of bits in the bitmask field and a plurality of bits in the register; determining a target bit from the register, wherein the target bit takes a first logical value; and adding a target identifier to the bit of the bitmask field corresponding to the target bit according to the mapping relationship, wherein the target identifier is used by the receiving end to identify the bit to be interacted with.

[0010] In one possible implementation, concatenating the plurality of data packets and a target protocol header to obtain a service message includes: determining the target protocol header, which includes at least one of the following fields: version identifier, device type of the terminal device, device identifier of the terminal device, data length, and number of data packets; concatenating the plurality of data packets with the target protocol header as the header to obtain an initial message; and concatenating a cyclic redundancy check code at the end of the initial message to obtain the service message.

[0011] In one possible implementation, collecting data from multiple registers of a terminal device includes: identifying current state change events of multiple registers of the terminal device; determining a target register whose state has changed from the multiple registers based on the current state change events; and determining the data of the target register as the data of the multiple registers.

[0012] In one possible implementation, the method further includes: when generating an exception response data packet, retaining the starting address identifier field and the register quantity field; setting the error response flag bit in the register quantity field to a valid state, wherein the error response flag bit and the bit operation flag bit are independently isolated from each other; and setting an error code in the valid value bit, wherein the error code is used to indicate an exception scenario.

[0013] Secondly, embodiments of this application provide a data communication device, comprising: a data acquisition module, configured to acquire multiple register data of a terminal device in response to a data transmission request; a classification module, configured to classify the multiple register data according to the continuity of the multiple register data to obtain multiple register data groups; an encapsulation module, configured to encapsulate each register data group according to a frame structure rule of type length value to obtain multiple data packets; a splicing module, configured to splice the multiple data packets and a target protocol header to obtain a service message; and a sending module, configured to send the service message to a receiving end.

[0014] In one possible implementation, the classification module is specifically used to determine the register address corresponding to each register data from the plurality of register data; the classification module is also specifically used to merge register data with consecutive register addresses into a register data group, and divide register data with discrete register addresses into independent register data groups, thereby obtaining the plurality of register data groups.

[0015] In one possible implementation, the encapsulation module is specifically used to determine the frame structure of the data packet according to the type length value. The frame structure includes a start address identifier field, a register quantity field, and a service data payload field. The register quantity field includes the most significant bit bit operation flag, the second most significant bit error response flag, and the remaining valid value bits. The encapsulation module is also specifically used to encapsulate each register data group according to the frame structure to obtain the plurality of data packets.

[0016] In one possible implementation, the encapsulation module is further configured to configure a bitmask field in the frame structure; the encapsulation module is further configured to establish a mapping relationship between multiple bits of the bitmask field and multiple bits of the register; the encapsulation module is further configured to determine a target bit from the register, the target bit taking a first logical value; the encapsulation module is further configured to add a target identifier to the bits of the bitmask field corresponding to the target bit according to the mapping relationship, the target identifier being used by the receiving end to identify the bit to be used for data interaction.

[0017] In one possible implementation, the splicing module is specifically used to determine the target protocol header, which includes at least one of the following fields: version identifier, device type of the terminal device, device identifier of the terminal device, data length, and number of data packets; the splicing module is further used to splice the multiple data packets with the target protocol header as the header to obtain an initial message; the splicing module is further used to splice a cyclic redundancy check code to the end of the initial message to obtain the service message.

[0018] In one possible implementation, the acquisition module is specifically configured to identify current state change events of multiple registers of the terminal device; the acquisition module is further configured to determine the target register whose state has changed from the multiple registers based on the current state change events; the acquisition module is further configured to determine the data of the target register as the data of the multiple registers.

[0019] In one possible implementation, the apparatus further includes: a processing module, configured to retain the starting address identifier field and the register quantity field when generating an exception response type data packet; the processing module is further configured to set the error response flag bit in the register quantity field to a valid state, wherein the error response flag bit and the bit operation flag bit are independently isolated from each other; the processing module is further configured to set an error code in the valid value bit, wherein the error code is used to indicate an exception scenario.

[0020] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0021] The memory stores computer-executed instructions;

[0022] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0023] Fourthly, embodiments of this application provide a non-volatile computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0024] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0025] The data communication method, apparatus, electronic device, and storage medium provided in this application include: in response to a data transmission request, collecting multiple register data from a terminal device; classifying the multiple register data according to their continuity to obtain multiple register data groups; encapsulating each register data group using type-length values ​​as frame structure rules to obtain multiple data packets; concatenating the multiple data packets with a target protocol header to obtain a service message; and sending the service message to a receiving end. This solution classifies and structurally encapsulates register data, compressing register data that would otherwise require multiple rounds of message interaction into a single frame message, reducing the number of communication rounds and thus improving communication efficiency. Attached Figure Description

[0026] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0027] Figure 1 This is a schematic diagram illustrating an application scenario of a data communication method provided in an embodiment of this application;

[0028] Figure 2 A flowchart illustrating a data communication method provided in an embodiment of this application;

[0029] Figure 3 A flowchart illustrating another data communication method provided in an embodiment of this application;

[0030] Figure 4 A schematic diagram of the general structure of data packets provided in the embodiments of this application;

[0031] Figure 5 A schematic diagram illustrating the frame structure rules provided in an embodiment of this application;

[0032] Figure 6 A schematic diagram of a bit operation provided for an embodiment of this application;

[0033] Figure 7 A schematic diagram illustrating another bit operation provided in an embodiment of this application;

[0034] Figure 8 A schematic diagram of the protocol frame architecture provided in the embodiments of this application;

[0035] Figure 9 This is a schematic diagram of the structure of a data communication device provided in an embodiment of this application;

[0036] Figure 10 This is a schematic diagram of another data communication device provided in an embodiment of this application;

[0037] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0038] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0039] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0040] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0041] It should be noted that the phrase "at...time" in the embodiments of this application can refer to the instant at which a certain situation occurs, or to a period of time after the occurrence of a certain situation; the embodiments of this application do not specifically limit this. Furthermore, the display interface provided in the embodiments of this application is merely an example, and the display interface may include more or less content.

[0042] It should be noted that the data communication method, apparatus, electronic device and storage medium of this application can be used in the field of communication technology, or in any field other than communication. The application field of the data communication method, apparatus, electronic device and storage medium of this application is not limited.

[0043] Figure 1 This is a schematic diagram illustrating an application scenario of a data communication method provided in an embodiment of this application. An example is given based on the illustrated scenario: data communication occurs between a terminal device and a business platform, and the communication efficiency determines the business execution efficiency.

[0044] In practical applications, terminal devices and service platforms follow fixed-format message frames, including fields such as function code, starting address, number of registers, and data payload. For example, Modbus protocol message frames. These fixed-format message frames ensure that the message structure of both communicating parties can be uniformly parsed and that the data exchange timing is well-organized.

[0045] However, fixed-format message frames only support batch reads and writes of consecutive address registers. If non-consecutive registers need to be accessed, they must be split into multiple independent messages for transmission, resulting in low communication efficiency.

[0046] The data communication method provided in this application aims to solve the above-mentioned technical problems in related technologies.

[0047] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0048] Figure 2 This is a flowchart illustrating a data communication method provided in an embodiment of this application. The method includes the following steps:

[0049] S201. In response to a data transmission request, collect data from multiple registers of the terminal device.

[0050] For example, in a register data interaction scenario between a terminal device and a service platform according to an embodiment of this application, after receiving various data transmission trigger requests, the terminal device collects its own relevant register data, processes the register data into service messages, and sends them to the receiving end.

[0051] Registers are storage units that store the terminal device's operating parameters, status, control commands, and collected values. Register data is the data stored internally in real time.

[0052] Optionally, data transmission requests can be read commands issued by the business platform or host computer, timed reporting requests, or proactive reporting.

[0053] For example, by collecting register data corresponding to multiple different addresses inside the terminal device in a single batch, the data that needs to be exchanged can be read out in a unified manner, avoiding the problem of low communication efficiency caused by reading continuous data in a small range multiple times in related technologies.

[0054] S202. Based on the continuity of multiple register data, classify the multiple register data to obtain multiple register data groups.

[0055] For example, the device categorizes and organizes all the register data collected in batches according to whether the register addresses are consecutive.

[0056] For example, multiple register data that are adjacent to each other in physical address and without gaps are merged into a single register data group, while register points that are spaced apart, scattered, and discontinuous are each divided into an independent register data group.

[0057] With the help of scenario examples, the messy and discrete register data is organized into multiple groups of data units, which provides a data foundation for the subsequent encapsulation to accommodate multiple segments of non-contiguous register data in a single frame message.

[0058] S203. Using the type length value as the frame structure rule, each register data group is encapsulated to obtain multiple data packets.

[0059] For example, in the Type-Length-Value (TLV), the start address of the type identifier register corresponds to the service type, the length indicates the data length, and the value identifies the actual register data.

[0060] For example, each packet is independently encapsulated into a data packet, and each data packet has its own type, length, and data, which can be parsed and addressed independently by the receiving end.

[0061] Using type-length values ​​as the frame structure rule, when encapsulating each register data group, a modular structure design is employed to independently divide the start address identifier field, register quantity field, and service data payload field, giving each data packet self-contained characteristics. During parsing at the receiving end, the target data packet can be directly located without traversing the entire message.

[0062] Based on the above implementation method, by using single-frame batch interaction, the non-continuous register access that originally required multiple rounds of message interaction is compressed into a single frame, reducing the number of communication polling times.

[0063] S204. Concatenate multiple data packets and the target protocol header to obtain the service message.

[0064] For example, the target protocol header and multiple data packets are concatenated end-to-end to form a complete service message frame. The target protocol header stores global configuration information, providing the receiving end with the basic parsing basis. This allows the receiving end to clearly identify the number of data packets in the service message, which device it belongs to, and the message format version, thereby improving the receiving end's processing efficiency for the service message.

[0065] In related technologies, multi-segment register data with discontinuous addresses must be divided into multiple frames and multiple queries and responses to complete the transmission in the traditional mode.

[0066] The embodiments of this application use a protocol header and multiple data packets to be spliced ​​together in the same frame, which aggregates all continuous and discrete register data into a single frame message, fundamentally reducing the number of message frames sent.

[0067] S205. Send a service message to the receiving end.

[0068] For example, the receiving end can be a business platform, which manages multiple terminal devices based on data from multiple terminal devices.

[0069] For example, the terminal sends the spliced ​​whole frame of service message to the service platform at once. With just one transmission interaction, it completes the reporting of multiple register data that originally required multiple rounds of polling and multiple frame round trips, thereby improving data communication efficiency.

[0070] The data communication method provided in this application, in response to a data transmission request, collects multiple register data from a terminal device; classifies the multiple register data according to their continuity to obtain multiple register data groups; encapsulates each register data group using type-length values ​​as frame structure rules to obtain multiple data packets; concatenates the multiple data packets with a target protocol header to obtain a service message; and sends the service message to the receiving end. This scheme classifies and structurally encapsulates register data, compressing register data that would otherwise require multiple rounds of message interaction into a single frame message, reducing the number of communication rounds and thus improving communication efficiency.

[0071] Based on any of the above embodiments, the following, in conjunction with Figure 3 This section provides a detailed explanation of the data communication process.

[0072] Figure 3 This is a flowchart illustrating another data communication method provided in an embodiment of this application. Figure 3 As shown, the method includes:

[0073] S301. In response to a data transmission request, collect data from multiple registers of the terminal device.

[0074] One feasible implementation involves collecting data from multiple registers of a terminal device by: identifying current state change events of multiple registers of the terminal device; determining the target register whose state has changed from among the multiple registers based on the current state change events; and determining the data of the target register as multiple register data.

[0075] For example, during the normal and continuous operation of the device, the values ​​and states of some registers will remain stable for a period of time, while a small number of registers will experience value fluctuations and state reversals due to device operating condition switching, action triggering, and parameter adjustment.

[0076] If the full data acquisition method is used, all unchanged redundant register data and changed valid register data will be collected, encapsulated, and uploaded, resulting in invalid data occupying processing resources and communication bandwidth.

[0077] For example, the terminal device monitors the operating status of all its registers online and continuously identifies whether each register has generated a current state change event.

[0078] These events include substantive changes such as alterations to values ​​stored in registers, flips in switch states, and fluctuations in operating parameters. Real-time monitoring continuously captures the dynamic anomalies of each register, accurately identifying which register has undergone a substantial state change.

[0079] For example, after identifying the current state change event, the registers whose state has actually changed are precisely identified from all registers based on the substantial state change events among them, and these selected registers are defined as target registers.

[0080] For example, only the valid values ​​stored inside the target register are read, and these valid values, which only represent changes in operating conditions, are identified as multiple register data.

[0081] In this feasible implementation, register state change events are used as triggering and filtering conditions to collect register data that has actual operating condition changes. This eliminates static and redundant data that has not changed for a long time from the source, and avoids invalid data from participating in the subsequent grouping, encapsulation, and framing process. This greatly reduces the data volume of the entire communication link and improves communication efficiency.

[0082] S302. Determine the register address corresponding to each register data from multiple register data.

[0083] For example, the register data includes register addresses. Register addresses can be unique identifiers assigned to each register, arranged sequentially in a fixed encoding format, equivalent to a unique location number for each register.

[0084] S303. Merge register data with consecutive register addresses into one register data group, and divide register data with discrete register addresses into independent register data groups to obtain multiple register data groups.

[0085] For example, multiple register data sets with consecutive register addresses, no gaps in between, and consecutive sequence numbers are merged and grouped together to obtain a complete register data group.

[0086] For example, discrete register data with interspersed, scattered, and unconnected register addresses are not merged or grouped; each discrete register data is separately designated as an independent register data group.

[0087] With the help of scenario examples, after processing according to the rules of merging consecutive addresses and dividing discrete addresses separately, multiple register data groups with regular order and clear boundaries are finally formed.

[0088] S304. Determine the frame structure of the data packet based on the type length value.

[0089] The frame structure includes a start address identifier field, a register quantity field, and a service data payload field. The register quantity field includes the most significant bit bit of the bit manipulation flag, the second most significant bit bit of the error response flag, and the remaining valid value bits.

[0090] Below, in conjunction with Figure 4 The general structure of data packets is explained.

[0091] Figure 4 This is a schematic diagram illustrating the general structure of a data packet provided in an embodiment of this application. For example... Figure 4 As shown, the general structure of a data packet includes at least data packet A. When the register addresses are discrete and discontinuous, at least one data packet B can be appended. The start address identifier field is used to identify the first register position number corresponding to the current register data packet. The service data payload field is used to store the actual original register values ​​within the packet.

[0092] For example, the highest bit of the register quantity field is set as an operation flag to distinguish the type of service operation corresponding to the current data packet. The second highest bit is set as an error response flag to indicate whether any abnormal situations such as address out of bounds, parameter errors, or read / write errors have occurred during this register data exchange process. Apart from the highest and second highest bits, all remaining bits in the register quantity field are used as valid value bits to accurately represent the actual number of registers contained in the current data packet.

[0093] Below, in conjunction with Figure 5 The frame structure rules are explained.

[0094] Figure 5 This is a schematic diagram illustrating the frame structure rules provided in an embodiment of this application. For example... Figure 5 As shown, the highest bit is the bit manipulation flag F, and the second highest bit is the error response flag E. F=0 indicates register-level operation mode, where the entire register is read, written, and reported, and the message has no bitmask field. F=1 indicates fine-grained bit-level operation mode, where interaction is limited to specified bits within the register, and the message carries a dedicated bitmask field. E=0 indicates a normal service response; in this case, bits 13~bit0 store the number of register interactions. E=1 indicates an error / abnormal response; in this case, bits 13~bit0 store a custom error code, and the message has no subsequent payload field. Bits 13~bit0 are 14 significant bits, with a maximum addressing range of 16383. A normal frame displays the number of registers, while an error frame displays the abnormal error code.

[0095] With scenario examples, it is shown that by dividing the bits, it is compatible with operation type marking, abnormal status marking and register quantity value functions. Each bit is independent and the logic does not interfere with each other.

[0096] S305. Based on the frame structure, encapsulate each register data group to obtain multiple data packets.

[0097] For example, based on the frame structure, each register data group is populated with corresponding field content and format encapsulated to generate independent data packets with uniform structure and fixed field meanings, ultimately resulting in multiple regular and standardized data packets.

[0098] One feasible implementation can be encapsulated as follows: configuring a bitmask field in the frame structure; establishing a mapping relationship between multiple bits of the bitmask field and multiple bits of the register; determining the target bit from the register, with the target bit taking the first logical value; and adding a target identifier to the bits of the bitmask field corresponding to the target bit according to the mapping relationship, the target identifier being used by the receiving end to identify the bit to be used for data interaction.

[0099] For example, when encapsulating register data groups according to a defined frame structure, an additional bitmask field is configured to add a dedicated field for bit marking to the data packet frame structure.

[0100] For example, a bit mapping correspondence is established, which establishes a one-to-one mapping relationship between each bit in the bitmask field and each physical bit in the register, thus establishing a unified bit reference standard.

[0101] For example, among all the bits in the register, target bits with a first logical value (e.g., 1) are selected. These target bits represent valid bits that need to be read, configured, and exchanged with the receiving end. The remaining bits that hold another logical value (e.g., 0) are idle bits that do not require interaction.

[0102] For example, based on the established mapping relationship, in the bitmask field, the target identifier is written to the mask bit corresponding to the target bit, and the target identifier is used to make an explicit mark in the message.

[0103] With the example scenario, when the receiving end parses the data packet, it can accurately locate the specific bit in the register that needs to be used for data interaction by identifying the target identifier in the bitmask field, without having to parse and process the entire value of the register.

[0104] With the example scenario, let's illustrate the read request (from the receiving end to the terminal device):

[0105] Scenario where the receiver sends a register read command without an error frame:

[0106] F=0 indicates a register read, requesting to read a contiguous whole register. The data packet structure consists of an identifier field and the number of registers (no data segment).

[0107] F=1 indicates a bit-level read, requesting the reading of a specified bit from a register. The data packet structure consists of an identifier field, the number of registers, and a bit mask (no data segment).

[0108] Read the reply (from the terminal device to the receiving end):

[0109] The terminal device responds to the platform's read requests, covering both normal and error / abnormal response scenarios:

[0110] Normally, F=0 and E=0, and the data packet structure consists of an identifier field, the number of registers, and register data.

[0111] Normally, F=1 and E=0: The data packet structure consists of an identifier field, the number of registers, a bitmask, and register data.

[0112] Exception E=1: The data packet structure consists of an identifier field and the number of registers, with no subsequent payload. The lower 14 bits return the corresponding error code.

[0113] Write request (from receiver to terminal device):

[0114] Scenario where the receiver sends a register write command and there is no error frame:

[0115] F=0 Register Integer Write: The data packet structure consists of an identifier field, register quantity, and register data, and an integer register value is written.

[0116] F=1 bit-level precise write: The data packet structure consists of an identifier field, the number of registers, a bit mask, and register data. Only the bits that are hit by the mask are modified, while the remaining bits of the registers remain unchanged.

[0117] Write a reply (from the terminal device to the receiving end):

[0118] The terminal device responds to the receiving end's write request, overwriting normal responses and error / abnormal responses:

[0119] Normal F=0, E=0; F=1, E=0: Only the flag field and register count are returned, with no subsequent payload, and the flag writing is complete;

[0120] Exception E=1: The data packet structure consists of an identifier field and the number of registers, with no subsequent payload. The lower 14 bits return the corresponding write exception error code.

[0121] Below, in conjunction with Figure 6 The bitwise operation is explained.

[0122] Figure 6 This is a schematic diagram of a bit operation provided in an embodiment of this application. For example... Figure 6As shown, bit F being 0 indicates a register operation, and bit E being 0 indicates a normal response data packet. Original value: For example, the value in the register is 0x0004 (binary 00000000000000100), meaning bit 2 is 1, and the rest are 0. Bitmask: 0x0001 (binary 0000000000000001), only bit 0 is 1, meaning only bit 0 is modified. Write value: 0x0001, meaning bit 0 is to be set to 1. Result: The final register value becomes 0x0005 (binary 00000000000000101). Bit 0 was successfully set to 1, and the original 1 in bit 2 was preserved and not overwritten. It can be seen that the bitmask only modifies the specified bit, while the other bits remain unchanged.

[0123] Below, in conjunction with Figure 7 The bitwise operation is explained.

[0124] Figure 7 This is a schematic diagram illustrating another bit operation provided in an embodiment of this application. For example... Figure 7 As shown, in the write request sent from the receiving end to the terminal device, 00C8 represents the address of the register to be written. 8001 (binary 10000000000000001) indicates that the operation flag is 1, corresponding to the bit-level operation mode; the error response flag is 0, corresponding to a normal request frame; and the valid value bit is 1, indicating that the number of registers in this operation is 1. The bitmask 0001 (binary 00000000000000001) indicates that only bit 0 participates in this write operation, and all other bits remain unchanged. The service data payload field 0001 indicates that the bit 0 that is matched by the bitmask should be set to 1.

[0125] refer to Figure 7 Here's an example of the bitwise operations for a write operation:

[0126] The terminal device's original register value is 0x0004 (binary 0000000000000100).

[0127] Mask locking is only effective on bit0. Original bit0 is 0, and the target value is written as 1.

[0128] The register result after the operation is: 0x0005 (binary 0000000000000101). The original value of bit2 is completely preserved, and only bit0 is modified.

[0129] The device successfully wrote a response frame:

[0130] A normal bit-level response is received; the data packet structure includes a start address identifier field and a register count field, with no subsequent payload.

[0131] Frame content: 00C88001, the flag bit write operation has been completed.

[0132] Example of an abnormal scenario:

[0133] If the requested register address is out of bounds, the terminal device will reply with an error response frame. The data packet structure includes a start address identifier field and an error code field (bit 14 = 1), with no subsequent payload.

[0134] Example frame: 00C84001, where 0x4001 represents bit 14=1, and the lower 14 bits 0x0001 is a custom error code for register out of bounds.

[0135] In this feasible implementation, a bitmask field is added to the data packet frame structure. The receiving end can directly lock the bit to be exchanged by relying on the target identifier of the bitmask field, without having to traverse and parse the entire register data, thereby reducing the data parsing and computation overhead of the receiving end and improving communication efficiency.

[0136] One feasible implementation method for data communication may further include: when generating an exception response data packet, retaining the starting address identifier field and the register quantity field; setting the error response flag bit in the register quantity field to a valid state, wherein the error response flag bit and the bit operation flag bit are independently isolated from each other; and setting an error code in the valid value bit, wherein the error code is used to indicate an exception scenario.

[0137] For example, during the process of register data interaction between the terminal device and the receiving end, under normal circumstances, the terminal device can successfully read the corresponding register address, obtain the register value, and encapsulate it into a normal business data packet for uploading.

[0138] However, various failure scenarios may occur: for example, the accessed register address exceeds the device's actual addressing range, register read failure, illegal operation instructions issued, message parsing errors, and non-compliant parameter configurations. In these scenarios of communication failure, access errors, and invalid instructions, the terminal device no longer returns normal register service data. Instead, it generates a special data packet to inform the receiving end of the abnormality and explain the specific reason for the abnormality. This is the abnormal response data packet.

[0139] For example, in scenarios where it is necessary to generate exception response data packets, the starting address identifier field and register quantity field of the original normal data packets are retained, and the existing frame structure basic fields are used.

[0140] When generating an exception response data packet, the bits in the register count field are configured differently, and the error response flag is set to a valid state. At the same time, the corresponding error code is filled in the valid value bits of the register count field. Different error codes correspond to various actual exception scenarios such as register address out of bounds, register read / write failure, invalid parameters, and data parsing errors. The receiving end can accurately determine the specific exception type by recognizing the error code in the valid value bits.

[0141] In this feasible implementation, the original start address identifier field and register quantity field are used when generating abnormal response data packets. There is no need to design a completely new abnormal message frame structure. The existing frame structure system is reused, which simplifies the overall design complexity of the protocol and reduces the program development and protocol adaptation costs of the terminal and the receiving end.

[0142] S306. Concatenate multiple data packets and the target protocol header to obtain the service message.

[0143] One feasible implementation method is to generate a business message by: determining a target protocol header, which includes at least one of the following fields: version identifier, device type of the terminal device, device identifier of the terminal device, data length, and number of data packets; using the target protocol header as the header, concatenating multiple data packets to obtain an initial message; and concatenating a cyclic redundancy check code at the end of the initial message to obtain the business message.

[0144] For example, the constituent fields of the target protocol header are determined. The target protocol header integrates multiple global management information, including at least one of the following fields: version identifier, device type of terminal device, device identifier of terminal device, data length, and number of data packets.

[0145] Specifically, the version identifier is used to identify the protocol version specification followed by the current communication message, so as to achieve compatibility and differentiation between different version protocols.

[0146] Device type is used to distinguish the hardware model category of terminal devices.

[0147] The device identifier serves as a unique identification number for terminal devices, enabling precise addressing and differentiation among multiple terminal devices.

[0148] Data length is used to identify the total number of data bytes in the entire message frame.

[0149] The number of data packets indicates the total number of data packets encapsulated within this frame.

[0150] After determining the target protocol header, the packets are arranged according to a fixed framing order. The target protocol header is used as the starting header of the entire frame. All the encapsulated data packets are sequentially arranged and spliced ​​together to form a well-structured initial message.

[0151] With the illustration of a scenario, the protocol header integrates global fields such as version, device type, device identifier, data length, and number of data packets. When the receiving end parses the message, it can first quickly obtain key information such as protocol version, device identity, total message length, and number of sub-packets through the protocol header, thus defining the parsing boundary in advance and eliminating the need to blindly traverse the message content, thereby improving the efficiency of message parsing.

[0152] After the initial message is constructed, a Cyclic Redundancy Check (CRC) code is appended to the end of the initial message. The CRC algorithm is used to calculate the check value of the entire message frame. This check value is used as a fixed field at the end of the message, and finally a standard business message with complete format and check capability is generated.

[0153] The Cyclic Redundancy Check (CRC) code is generated covering the protocol header, all data packets, and the fields preceding the checksum. The receiving end determines the integrity of the message by calculating the consistency between the checksum and the message content.

[0154] Below, in conjunction with Figure 8 The protocol frame architecture is explained.

[0155] Figure 8 This is a schematic diagram of the protocol frame architecture provided in an embodiment of this application. Figure 8 As shown, different fields correspond to different byte counts. The version number indicates the protocol version. The device type can be the current device or a sub-device; for example, 'z' represents the current device, and '0x01' represents a sub-device. The device identifier is used to distinguish different devices; for example, when the device type is a sub-device, the device identifier distinguishes different sub-devices. The data length indicates the number of bytes in the data packet portion. The number of data packets indicates the number of data packets. The data packets are encapsulated according to the frame structure rules based on the type length value. The Cyclic Redundancy Check (CRC) code is used by the receiving end to verify the message.

[0156] In this feasible implementation, a cyclic redundancy check code is added to the end of the message. This code can detect and identify message bit errors and data distortions caused by channel interference and signal attenuation during transmission. The receiving end can determine whether the message is complete and reliable by comparing the check code, quickly eliminate damaged and abnormal messages, and improve message processing efficiency.

[0157] S307. Send service messages to the receiving end.

[0158] It should be noted that the execution process of S307 is the same as that of S205, and will not be repeated here.

[0159] Figure 9 This is a schematic diagram of the structure of a data communication device provided in an embodiment of this application. Figure 9As shown, the data communication device 90 may include: a data acquisition module 91, a classification module 92, a packaging module 93, a splicing module 94, and a transmission module 95.

[0160] The acquisition module 91 is used to acquire multiple register data of the terminal device in response to data transmission requests.

[0161] The classification module 92 is used to classify multiple register data according to the continuity of the data, and obtain multiple register data groups.

[0162] Encapsulation module 93 is used to encapsulate each register data group according to the frame structure rule of type length value, so as to obtain multiple data packets.

[0163] The splicing module 94 is used to splice multiple data packets and the target protocol header to obtain a service message.

[0164] The sending module 95 is used to send service messages to the receiving end.

[0165] Optionally, the acquisition module 91 can execute... Figure 2 S201 in the embodiment.

[0166] Optionally, the classification module 92 can be executed. Figure 2 S202 in the embodiment.

[0167] Optionally, the encapsulation module 93 can execute... Figure 2 S203 in the embodiment.

[0168] Optionally, the splicing module 94 can execute... Figure 2 S204 in the embodiment.

[0169] Optionally, the sending module 95 can perform... Figure 2 S205 in the embodiment.

[0170] It should be noted that the data communication device shown in the embodiments of this application can execute the technical solutions shown in the above method embodiments, and its implementation principle and beneficial effects are similar, so they will not be described again here.

[0171] In one possible implementation, the classification module 92 is specifically used for:

[0172] Determine the register address corresponding to each register data from multiple register data.

[0173] Register data with consecutive register addresses is merged into one register data group, and register data with discrete register addresses is divided into separate register data groups, resulting in multiple register data groups.

[0174] In one possible implementation, the encapsulation module 93 is specifically used for:

[0175] Based on the type length value, the frame structure of the data packet is determined. The frame structure includes the start address identifier field, the register quantity field, and the service data payload field. The register quantity field includes the most significant bit bit operation flag, the second most significant bit error response flag, and the remaining valid value bits.

[0176] Based on the frame structure, each register data group is encapsulated to obtain multiple data packets.

[0177] In one possible implementation, the encapsulation module 93 is specifically used for:

[0178] Configure bitmask fields in the frame structure.

[0179] Establish a mapping relationship between multiple bits of the bitmask field and multiple bits of the register.

[0180] The target bit is determined from the register, and the target bit is taken as the first logical value.

[0181] Based on the mapping relationship, the target identifier is added to the bits of the bitmask field corresponding to the target bit. The target identifier is used by the receiver to identify the bit to be exchanged for data.

[0182] In one possible implementation, the splicing module 94 is specifically used for:

[0183] Determine the target protocol header, which includes at least one of the following fields: version identifier, device type of the terminal device, device identifier of the terminal device, data length, and number of data packets.

[0184] Using the target protocol header as the header, multiple data packets are concatenated to obtain the initial message.

[0185] A cyclic redundancy check code is appended to the end of the initial message to obtain the service message.

[0186] In one possible implementation, the acquisition module 91 is specifically used for:

[0187] Identify current state change events of multiple registers in the terminal device.

[0188] Based on the current state change event, determine the target register whose state has changed from multiple registers.

[0189] The data in the target register is determined to be data from multiple registers.

[0190] Figure 10 This is a schematic diagram of another data communication device provided in an embodiment of this application. Figure 9 Based on the illustrated embodiments, as Figure 10 As shown, the data communication device 90 also includes a processing module 96.

[0191] Processing module 96 is used for:

[0192] When generating exception response data packets, retain the starting address identifier field and the register count field.

[0193] Set the error response flag in the register quantity field to the valid state. The error response flag and the bit operation flag are independent and isolated from each other.

[0194] Set the error code in the valid value bits. The error code is used to indicate abnormal scenarios.

[0195] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 11 As shown, the electronic device includes:

[0196] The electronic device includes a processor 291 and a memory 292; it may also include a communication interface 293 and a bus 294. The processor 291, memory 292, and communication interface 293 can communicate with each other via the bus 294. The communication interface 293 can be used for information transmission. The processor 291 can invoke logical instructions stored in the memory 292 to execute the methods of the above embodiments.

[0197] Furthermore, the logic instructions in the aforementioned memory 292 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0198] The memory 292, as a non-volatile computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this application. The processor 291 executes functional applications and data processing by running the software programs, instructions, and modules stored in the memory 292, that is, it implements the methods in the above-described method embodiments.

[0199] The memory 292 may include a program storage area and a data storage area. The program storage area may store the operating system and application programs required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 292 may include high-speed random access memory and may also include non-volatile memory.

[0200] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in the foregoing embodiments.

[0201] This application provides a computer program product, including a computer program that, when executed by a processor, implements the method as described in the foregoing embodiments.

[0202] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0203] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps; they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages, which do not necessarily complete at the same time but can be executed at different times. The execution order of these sub-steps or stages is also not necessarily sequential but can be alternated or carried out in turn with other steps or at least some of the sub-steps or stages of other steps.

[0204] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0205] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0206] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. The processor can be any suitable hardware processor, such as CPU, GPU, FPGA, DSP, and ASIC. The storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0207] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0208] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0209] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0210] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A data communication method, characterized in that, include: In response to a data transmission request, it collects data from multiple registers of the terminal device; Based on the continuity of the multiple register data, the multiple register data are classified and processed to obtain multiple register data groups; Using type length values ​​as frame structure rules, each register data is grouped and encapsulated to obtain multiple data packets; The multiple data packets and the target protocol header are concatenated to obtain the service message; Send the service message to the receiving end.

2. The method according to claim 1, characterized in that, The multiple register data are categorized to obtain multiple register data groups, including: From the plurality of register data, determine the register address corresponding to each register data; Register data with consecutive register addresses is merged into one register data group, and register data with discrete register addresses is divided into independent register data groups to obtain the multiple register data groups.

3. The method according to claim 1, characterized in that, Using type length values ​​as frame structure rules, each register data group is encapsulated to obtain multiple data packets, including: Based on the type length value, the frame structure of the data packet is determined. The frame structure includes a start address identifier field, a register quantity field, and a service data payload field. The register quantity field includes the most significant bit bit operation flag, the second most significant bit error response flag, and the remaining valid value bits. Based on the frame structure, each register data group is encapsulated to obtain the multiple data packets.

4. The method according to claim 3, characterized in that, Based on the frame structure, each register data group is encapsulated to obtain the multiple data packets, including: Configure a bitmask field in the frame structure; Establish a mapping relationship between multiple bits of the bitmask field and multiple bits of the register; The target bit is determined from the register, and the target bit takes a first logical value; According to the mapping relationship, a target identifier is added to the bit of the bitmask field corresponding to the target bit. The target identifier is used by the receiving end to identify the bit to be exchanged for data.

5. The method according to claim 1, characterized in that, The multiple data packets and the target protocol header are concatenated to obtain the service message, including: The target protocol header is determined, and the target protocol header includes at least one of the following fields: version identifier, device type of terminal device, device identifier of terminal device, data length, and number of data packets; Using the target protocol header as the header, the multiple data packets are concatenated to obtain an initial message; A cyclic redundancy check code is appended to the end of the initial message to obtain the service message.

6. The method according to claim 1, characterized in that, Collect data from multiple registers of the terminal device, including: Identify current state change events of multiple registers in the terminal device; Based on the current state change event, determine the target register whose state has changed from the plurality of registers; The data in the target register is determined to be the data in the plurality of registers.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: When generating exception response data packets, retain the starting address identifier field and the register count field; Set the error response flag in the register quantity field to the valid state. The error response flag is independent and isolated from the bit operation flag. An error code is set in the valid value bits, and the error code is used to indicate an abnormal scenario.

8. A data communication device, characterized in that, include: The acquisition module is used to acquire data from multiple registers of the terminal device in response to data transmission requests; The classification module is used to classify the multiple register data according to the continuity of the multiple register data to obtain multiple register data groups; The encapsulation module is used to encapsulate each register data group according to the frame structure rules of type length value, so as to obtain multiple data packets; The splicing module is used to splice the multiple data packets and the target protocol header to obtain the service message; The sending module is used to send the service message to the receiving end.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-7.

10. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

Images