Communication method, device, medium and product based on general link layer frame format

Abstract

This invention provides a communication method, device, medium, and product based on a universal link layer frame format. The method includes: responding to data received by the physical communication interface, reading a fixed-length candidate frame header and determining whether it meets the link layer frame format requirements; if it does not meet the requirements and the data length is not zero, routing the candidate frame header data as command line data to the command line processing buffer, and continuing to read and append the remaining data to the command line processing buffer; if the requirements are met, reading data of the length corresponding to the field value of the data length field as a candidate data body and performing integrity verification; comparing the verification result with the verification value recorded in the verification field; if the comparison is consistent, determining the candidate data body as a valid data body, and outputting the length of the valid data body. This invention enables seamless automatic switching between protocol data and command line debugging data, improving the convenience and ease of use of on-site equipment debugging.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and specifically to a communication method, device, medium, and product based on a universal link layer frame format. Background Technology

[0002] In Internet of Things (IoT) devices, it is typically necessary to support multiple physical communication interfaces to enable flexible data exchange and device configuration. Common communication interfaces include: UART (Universal Serial Bus), USB (Universal Serial Bus), Bluetooth Low Energy (BLE), Near Field Communication (NFC), and onboard flash memory for pre-configured storage.

[0003] In existing technologies, each communication protocol typically maintains its own independent link-layer frame format and parsing logic, resulting in fragmented frame formats, high code redundancy, and a lack of a unified protocol identification and data distribution mechanism, significantly increasing system integration complexity. For example, UART communication uses one frame format, NFC transparent transmission uses another, NFC card mode uses completely different data organization and verification methods, BLE communication typically uses the GATT service to define a custom frame format, and Flash pre-configuration often uses raw data structures for direct access.

[0004] Furthermore, in equipment debugging scenarios, non-protocol data such as command line data may be overlaid and transmitted with normal protocol frame data through the same physical channel. Existing solutions lack automatic differentiation and diversion mechanisms, and usually require additional mode switching signaling or manual switching of working modes, resulting in extremely poor usability for on-site debugging. Summary of the Invention

[0005] This invention provides a communication method, device, medium, and product based on a universal link layer frame format.

[0006] According to one aspect of the present invention, a communication method based on a general link layer frame format is provided, comprising: responding to data received by a physical communication interface, reading data of a fixed length through a low-level receiving function corresponding to the physical communication interface as candidate frame header data; determining whether the candidate frame header data meets the link layer frame format requirements; if the candidate frame header data does not meet the link layer frame format requirements and the length of the received data is not zero, routing the candidate frame header data as command line data to a command line processing buffer, and continuing to read the remaining data through the low-level receiving function and appending it to the command line processing buffer; if the candidate frame header data meets the link layer frame format requirements, extracting the field value of the data length field in the candidate frame header data, and reading data of the length corresponding to the field value through the low-level receiving function as candidate data body; performing integrity verification on the candidate data body to obtain a verification result, and comparing the verification result with the verification value recorded in the verification field in the candidate frame header data; if the comparison is consistent, determining the candidate data body as a valid data body, and outputting the length of the valid data body so that an upper-layer application can obtain the content of the valid data body from the receiving buffer corresponding to the physical communication interface.

[0007] A communication method based on a general link layer frame format according to at least one embodiment of the present invention determines whether the candidate frame header data meets the link layer frame format requirements, including: determining whether the byte length of the read candidate frame header data is equal to the fixed length; determining whether the value of the identifier field in the candidate frame header data falls within the valid value range of the protocol corresponding to the physical communication interface; determining whether the value of the version number field in the candidate frame header data matches a preset protocol version number; determining whether the byte length corresponding to the data length field in the candidate frame header data is less than or equal to the maximum capacity of the receive buffer corresponding to the physical communication interface; if all four determinations are yes, the candidate frame header data is determined to meet the link layer frame format requirements; if any one determination is no, the candidate frame header data is determined not to meet the link layer frame format requirements.

[0008] A communication method based on a general link layer frame format according to at least one embodiment of the present invention further includes: determining the communication protocol type corresponding to the data to be sent; constructing a frame header based on the link layer frame format, wherein the link layer frame format includes a frame header and a data body, and the frame header includes an identifier field, a version number field, a data length field, and a check field; wherein, according to the type of the communication protocol, a corresponding semantic value is set for the identifier field; the field value of the data length field is set according to the data length of the data to be sent, and a check value is calculated based on the data to be sent and filled into the check field; the data to be sent is used as the data body, and concatenated with the frame header in the order of the frame header first and the data body last to form a link layer frame; and the link layer frame is sent through the physical communication interface corresponding to the communication protocol type.

[0009] According to at least one embodiment of the present invention, a communication method based on a general link layer frame format, after continuing to read remaining data through the underlying receiving function and append it to the command line processing buffer, includes: continuously reading remaining data through the underlying receiving function and appending it to the command line processing buffer until the reception duration reaches a time threshold, or the remaining available space of the command line processing buffer is zero; parsing the command line data in the command line processing buffer to generate corresponding response data; simultaneously sending the response data through a UART physical serial port and a USBCDC virtual serial port; and clearing the command line processing buffer to wait for the next round of data reception.

[0010] According to at least one embodiment of the present invention, a communication method based on a universal link layer frame format, when the physical communication interface is in NFC card mode, further includes: an NFC card mode atomic writing step, comprising: constructing an empty frame header with the identification field marked as invalid, writing the empty frame header into the header storage area of ​​the NFC tag chip, and clearing the data storage area of ​​the NFC tag chip; compressing the data to be sent using a compression algorithm to obtain compressed data and a compressed length; encrypting the compressed data using an encryption algorithm to obtain encrypted compressed data; writing the encrypted compressed data as the data body into the data storage area of ​​the NFC tag chip starting from an offset address after the header storage area; after the encrypted compressed data is written, constructing a complete frame header based on the encrypted compressed data and the compressed length, and writing it into the header storage area of ​​the NFC tag chip to cover the empty frame header; and outputting the data length of the data to be sent so that the upper layer application can determine that the data to be sent has been successfully written.

[0011] According to at least one embodiment of the communication method based on the universal link layer frame format of the present invention, when the physical communication interface is in NFC card mode, the candidate data body is encrypted compressed data; when the verification result matches the verification value, the method further includes: decrypting the encrypted compressed data using a decryption algorithm to recover the compressed data; decompressing the compressed data using a decompression algorithm, and using the decompressed data as the valid data body.

[0012] According to at least one embodiment of the present invention, a communication method based on a general link layer frame format, when the physical communication interface is a non-streaming storage interface, further includes a structured access step for the non-streaming storage medium, comprising: a validity check step: reading the frame header from a preset fixed address of the non-streaming storage medium and determining whether the frame header meets the link layer frame format requirements; if the link layer frame format requirements are met, performing integrity verification on the data body corresponding to the frame header to obtain a verification result, and comparing the verification result with the verification value recorded in the verification field of the frame header; if the comparison is consistent, marking the data body corresponding to the frame header as valid; a data reading step: in response to receiving a special offset value marker, returning the frame header; or in response to receiving... Based on the target offset and target read length, data indicating the number of bytes to be read is read from the offset address following the preset fixed address in the non-streaming storage medium; wherein, if the sum of the target offset and the target read length is greater than the byte length corresponding to the data length field, the target read length is truncated to a length within the valid range; data writing step: in response to receiving the special offset value marker, the frame header to be written is written to the header area of ​​the non-streaming storage medium; or in response to receiving the target offset and target write length, the data to be written is written to the corresponding offset address in the non-streaming storage medium; closed-loop verification step: after the data writing step is completed, the validity check step is re-executed.

[0013] According to another aspect of the present invention, an electronic device is provided, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, causing the processor to perform a communication method based on a general link layer frame format according to any embodiment of the present invention.

[0014] According to another aspect of the present invention, a readable storage medium is provided, wherein the readable storage medium stores executable instructions, which, when executed by a processor, are used to implement a communication method based on a general link layer frame format according to any embodiment of the present invention.

[0015] According to another aspect of the present invention, a computer program product is provided, comprising a computer program that, when executed by a processor, implements a communication method based on a general link layer frame format according to any embodiment of the present invention.

[0016] The present invention has the following beneficial effects: (1) By adopting a unified link layer frame format for data parsing, code redundancy is significantly reduced. This invention defines a unified frame header structure, enabling multiple communication protocols such as UART, USB, BLE, NFC pass-through, NFC card mode, and Flash pre-configuration to reuse the same frame verification algorithm. Compared with existing technologies, code reuse rate can be increased by more than 70%, significantly reducing the system complexity and development cost of multi-protocol integration.

[0017] (2) Automatic protocol identification and seamless data routing driven by preamble are realized. This invention innovatively utilizes the validity judgment of the first field (preamble / tag / status byte) in the frame header to simultaneously realize the triple functions of communication protocol type identification, continuity marking, and mode switching. When the received data does not meet the expected protocol frame format requirements, the received data can be automatically routed as command line data to the command line processing channel, realizing seamless automatic switching between protocol service data and non-protocol command line debugging data. This mechanism does not rely on any additional external mode switching signaling or out-of-band control instructions, greatly improving the ease of use of IoT devices in field debugging scenarios and the convenience of multi-terminal concurrent debugging.

[0018] (3) Effectively ensures the integrity of data transmission and system robustness. Through strict frame header validity judgment and data body integrity verification, it ensures that only valid and complete data bodies are delivered to the upper layer application, effectively intercepting erroneous frames and dirty data in physical transmission, and significantly improving the data reliability of IoT devices in complex multi-protocol transmission scenarios. Attached Figure Description

[0019] The accompanying drawings illustrate exemplary embodiments of the invention and, together with the description thereof, serve to explain the principles of the invention. These drawings are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification.

[0020] Figure 1 This is a flowchart illustrating a link layer frame encapsulation method according to an embodiment of the present invention.

[0021] Figure 2 This is a flowchart illustrating a communication method based on a general link layer frame format according to an embodiment of the present invention.

[0022] Figure 3This is a flowchart illustrating a multi-channel command-line data automatic routing and output method according to an embodiment of the present invention.

[0023] Figure 4 This is a flowchart illustrating a communication method based on a universal link layer frame format according to another embodiment of the present invention.

[0024] Figure 5 This is a flowchart illustrating an NFC card mode data reading method according to an embodiment of the present invention.

[0025] Figure 6 This is a flowchart illustrating a communication method based on a general link layer frame format according to another embodiment of the present invention.

[0026] Figure 7 This is a schematic structural block diagram of an electronic device employing a processor-based hardware implementation according to an embodiment of the present invention. Detailed Implementation

[0027] The present invention will now be described in further detail with reference to the accompanying drawings and examples. It should be understood that the specific examples described herein are for illustrative purposes only and are not intended to limit the scope of the invention. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present invention are shown in the accompanying drawings.

[0028] It should be noted that, unless otherwise specified, the embodiments and features described in this invention can be combined with each other. The technical solution of this invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0029] The following technical problems often exist in existing IoT communications: (1) Frame format fragmentation and high code redundancy: Each communication interface has its own custom frame header structure, verification algorithm and processing flow, resulting in a large amount of duplicate code. For example, the UART frame header needs to include a preamble, length and verification field. The NFC transparent transmission frame header needs the same fields as the UART frame header, but the two are defined completely independently and cannot be reused.

[0030] (2) Lack of a unified protocol identification and distribution mechanism: When a device listens to multiple communication channels at the same time, it is impossible to quickly identify the protocol type of the data source through a unified mechanism. Existing solutions usually rely on polling or independent interrupt handling for each channel, and upper-layer applications need to interface with different parsing interfaces, which increases the complexity of system integration.

[0031] (3) Difficulty in handling the mixing of non-protocol data and protocol data: In debugging scenarios, command line data (such as AT commands) input through serial port or NFC channel may be transmitted through the same physical channel as normal protocol frame data. Existing solutions lack an automatic differentiation mechanism, requiring additional mode switching signaling or manual mode switching, resulting in poor usability.

[0032] To address the aforementioned technical problems, the present invention proposes the following technical solutions.

[0033] Figure 1 A flowchart illustrating a link-layer frame encapsulation method according to one embodiment of the present invention is shown. Figure 1 The method shown includes steps S110 to S150.

[0034] S110: Determine the communication protocol type corresponding to the data to be sent.

[0035] For example, the communication protocol type may include UART, USB, BLE pass-through, NFC pass-through, NFC card mode, Flash pre-configuration, etc.

[0036] S120: Construct the frame header based on the link layer frame format.

[0037] The link layer frame format includes a frame header and a data body. The frame header contains an identification field, a version number field, a data length field, and a checksum field. The identification field is assigned a corresponding semantic value based on the type of communication protocol.

[0038] For example, the identifier field occupies 1 byte and is used for communication protocol identification and pattern marking. The version number field occupies 1 byte and is used for protocol evolution compatibility judgment. The data length field occupies 2 bytes and is used to record the byte length of the data body, with a maximum support of 65535 bytes. The checksum field occupies 4 bytes and can be the checksum calculated using the standard CRC32 algorithm for the entire data body.

[0039] Different types of communication protocols all use the same frame structure template (determined based on the link layer frame format), but the identification field is semantically differentiated according to the characteristics of the communication protocol. This design maintains format uniformity while providing necessary flexibility for each communication protocol.

[0040] As one possible implementation, based on the type of communication protocol, corresponding semantic values ​​are set for the identifier field, including: When the communication protocol type is UART, BLE transparent transmission, or NFC transparent transmission, the identification field is a preamble, used to identify frame continuity. For example, a field value of 0x00 indicates a complete frame, and a field value of 0xFF indicates an intermediate frame in segmented transmission (to be continued).

[0041] When the communication protocol is in NFC card mode, the identification field is a label, used for data change detection and status indication. For example, a field value of 0xFF indicates that the identification field is not initialized, and a field value of 0x00 indicates that the identification field is invalid or cleared.

[0042] When the communication protocol type is Flash pre-configuration, the identifier field is Status, which is used to indicate whether the pre-configuration data is enabled or disabled.

[0043] S130: Set the field value of the data length field according to the data length of the data to be sent, and calculate the check value based on the data to be sent to fill the check field.

[0044] S140: The data to be sent is treated as the data body and concatenated with the frame header in the order of frame header first and data body last to form a link layer frame.

[0045] S150: Send link layer frames through the physical communication interface corresponding to the communication protocol type.

[0046] The above implementation method, by employing a unified link-layer frame format for data encapsulation, achieves a high degree of reuse of encapsulation logic across multiple communication interfaces, significantly reducing system code redundancy and development costs. Simultaneously, it innovatively sets differentiated semantic values ​​for the identification field in a unified frame header, ensuring both the uniformity of the underlying frame structure and flexibly meeting the specific business requirements of different communication protocols. Furthermore, the introduction of version number and checksum fields effectively guarantees data integrity and protocol version compatibility during cross-physical link transmission, enabling transparent transmission of upper-layer application data on any supported physical channel, significantly improving the scalability and robustness of multi-protocol integration in IoT devices.

[0047] As one possible implementation, when the communication protocol type is NFC transparent transmission or BLE transparent transmission, after sending the link layer frame through the physical communication interface corresponding to the communication protocol type, the method further includes: sending a zero-length data frame through the physical communication interface to refresh the internal buffer of the communication chip corresponding to the physical communication interface. This implementation, by reusing the existing channel to send a zero-length data frame after data transmission, can trigger the refresh of the underlying communication chip's internal buffer and the reset of the state machine without defining additional dedicated control instructions. This effectively prevents residual data or suspended states from interfering with subsequent communication, significantly improving the reliability of data transmission and system stability in communication scenarios such as NFC and BLE.

[0048] Figure 2This diagram illustrates the overall flow of a communication method based on a universal link layer frame format according to one embodiment of the present invention, applicable to streaming physical communication interfaces such as UART, BLE pass-through, and NFC pass-through. Figure 2 The method shown includes steps S210 to S260.

[0049] S210: In response to receiving data through the physical communication interface, read a fixed length of data through the underlying receiving function corresponding to the physical communication interface as candidate frame header data.

[0050] For example, the fixed length is 8 bytes.

[0051] S220: Determine whether the candidate frame header data meets the requirements of the link layer frame format (i.e., meets the requirements of the frame header in the link layer frame format).

[0052] S230: If the candidate frame header data does not meet the link layer frame format requirements and the length of the received data is not zero, the candidate frame header data is routed to the command line processing buffer as command line data, and the remaining data is continued to be read and appended to the command line processing buffer through the underlying receiving function.

[0053] S240: If the candidate frame header data meets the link layer frame format requirements, extract the field value of the data length field in the candidate frame header data, and read the data of the length corresponding to the field value as the candidate data body through the underlying receiving function.

[0054] S250: Perform integrity verification (such as CRC32 verification) on the candidate data body to obtain the verification result, and compare the verification result with the verification value recorded in the verification field in the candidate frame header data.

[0055] S260: If the comparison is consistent, determine the candidate data body as the valid data body, and output the length of the valid data body so that the upper layer application can obtain the content of the valid data body from the receive buffer corresponding to the physical communication interface.

[0056] The above implementation innovatively utilizes a frame header format verification mechanism to achieve automatic data identification and routing. When received data does not meet the protocol frame format requirements, it is automatically routed to the command-line processing buffer. Seamless automatic switching between protocol data and command-line debugging data can be achieved without additional mode switching signaling, greatly improving the convenience and ease of use of on-site device debugging. In addition, through strict frame header validity judgment and data body integrity verification, it ensures that only legal and complete valid data bodies are delivered to the upper-layer application, effectively intercepting erroneous frames and dirty data, and significantly improving the data reliability and system robustness of IoT devices in complex multi-protocol transmission scenarios.

[0057] As one possible implementation, determining whether the candidate frame header data meets the link layer frame format requirements includes: determining whether the byte length of the read candidate frame header data is equal to a fixed length (e.g., 8 bytes); determining whether the value of the identifier field in the candidate frame header data falls within the valid value range of the protocol corresponding to the physical communication interface; determining whether the value of the version number field in the candidate frame header data matches a preset protocol version number; and determining whether the byte length corresponding to the data length field in the candidate frame header data is less than or equal to the maximum capacity of the receive buffer corresponding to the physical communication interface (e.g., 65535 bytes). If all four determinations are true, the candidate frame header data is determined to meet the link layer frame format requirements. If any one of the determinations is false, the candidate frame header data is determined to not meet the link layer frame format requirements.

[0058] As one possible implementation, fixed-length data is read through the underlying receive function corresponding to the physical communication interface. This includes: when the physical communication interface is a UART physical serial port, reading fixed-length data through the underlying receive function (uart_parser_read()) corresponding to the serial communication interface. If the underlying receive function fails to read (returns 0), the fixed-length data is automatically read from the USB CDC virtual serial port. The fallback mechanism used in this implementation allows the device to simultaneously receive data from both the UART physical serial port and the USB virtual serial port without the upper-layer application needing to be concerned with the data source.

[0059] As one possible implementation, when the physical communication interface is a UART physical serial port, after continuing to read the remaining data through the underlying receive function and appending it to the command line processing buffer, including... Figure 3 Steps S310 to S340 are shown.

[0060] S310: Continuously reads the remaining data through the underlying receive function and appends it to the command line processing buffer until the receive duration reaches the time threshold, or the remaining available space in the command line processing buffer is zero.

[0061] The time threshold can be preset according to requirements and is not limited here.

[0062] S320: Parses the command line data in the command line processing buffer and generates the corresponding response data.

[0063] S330: Sends response data simultaneously via the UART physical serial port and the USB CDC virtual serial port to achieve dual-channel output.

[0064] S340: Clears the command line processing buffer to wait for the next round of data reception.

[0065] Through the above implementation methods, non-protocol command line data can be automatically cached and output synchronously through dual channels. It can meet the needs of multi-terminal concurrent debugging without any external mode switching signaling, which can greatly improve the convenience of on-site equipment debugging and the ease of system use.

[0066] Existing communication methods lack an integrated data compression and encryption pipeline in NFC card mode. When transmitting configuration data via NFC card mode, the storage space of NFC tag chips (such as the NTAG series) is extremely limited (typically only a few hundred bytes to a few KB). Existing solutions either do not perform compression (resulting in low space utilization) or treat compression and encryption as separate steps called separately by the upper-layer application, lacking a unified atomic processing pipeline and exhibiting data consistency issues. If power is lost or the card is removed during the writing process, the configuration data may become incomplete or corrupted. To address this technical problem, Figure 4 A flowchart illustrating another embodiment of the communication method based on a universal link layer frame format, applicable to NFC card mode, is shown. Figure 4 The method shown includes steps S410 to S460.

[0067] S410: Construct an empty frame header with an invalid identifier field (such as 0x00), write the empty frame header into the header storage area of ​​the NFC tag chip, and clear the data storage area of ​​the NFC tag chip.

[0068] S420: Compresses the data to be sent using a compression algorithm to obtain compressed data and compressed length.

[0069] For example, the compression algorithm can be the LZSS lossless compression algorithm.

[0070] An error is returned if compression fails or the length of the compressed data exceeds the effective storage capacity of the NFC tag chip.

[0071] S430: Encrypt compressed data using an encryption algorithm to obtain encrypted compressed data.

[0072] For example, the encryption algorithm can be the AES-128-CTR encryption algorithm. During encryption, the compressed data can be encrypted according to a preset 16-byte key and a 16-byte initialization vector IV.

[0073] S440: Encrypted compressed data is written as the data body to the data storage area of ​​the NFC tag chip, starting from the offset address after the header storage area.

[0074] S450: After the encrypted compressed data is written, a complete frame header is constructed based on the encrypted compressed data and the compressed length, and written to the header storage area of ​​the NFC tag chip to cover the empty frame header.

[0075] Step S450 must be executed after step S440 is completed. If a power outage or the NFC tag chip is removed during the execution of steps S420 to S440, the invalid mark written in step S410 will still be retained in the header storage area of ​​the NFC tag chip, and will be judged as invalid data during subsequent reading.

[0076] S460: Outputs the length of the data to be sent, so that the upper-layer application can confirm that the data to be sent has been successfully written.

[0077] The above implementation integrates data compression and encryption pipelines, combined with an atomic write order strategy of "writing an invalid tag header first, then overwriting the complete valid header after data writing is complete." This significantly improves the utilization rate of the limited storage space of NFC tags and data security, while effectively avoiding dirty data problems caused by power outages or accidental card removal during the writing process, ensuring the absolute integrity and consistency of configuration data. Simultaneously, the NFC card mode, through its self-incrementing tag mechanism, allows the reader to easily determine whether data has changed by simply comparing tag values.

[0078] As one possible implementation, a complete frame header is constructed based on the encrypted compressed data and the compressed length, including: The identifier field in the empty frame header is incremented (e.g., 0x00+1=0x01), and the incremented value (0x01) is filled into the identifier field in the complete frame header; Set the version number field in the full frame header to the current card mode protocol version.

[0079] Set the data length field in the full frame header to the compressed length.

[0080] Calculate the checksum for the encrypted compressed data and fill the calculated checksum into the checksum field in the header of the complete frame.

[0081] Figure 5 A flowchart illustrating an NFC card mode data reading method according to one embodiment of the present invention is shown, applicable to NFC card mode. Figure 5 The method shown includes steps S510 to S560.

[0082] S510: Reads the frame header from the header storage area of ​​the NFC tag chip.

[0083] S520: Determine whether the frame header meets the link layer frame format requirements.

[0084] The specific judgment method can be the same as step S220, and will not be repeated here.

[0085] S530: Reads encrypted compressed data of the length corresponding to the data length field from the data storage area of ​​the NFC tag chip as a candidate data body.

[0086] S540: Perform integrity verification on the candidate data body to obtain the verification result, and compare the verification result with the verification value recorded in the verification field in the candidate frame header data.

[0087] S550: If the comparison is consistent, the encrypted compressed data is decrypted using a decryption algorithm to recover the compressed data.

[0088] For example, the decryption algorithm is the same as the encryption algorithm, both being AES-128-CTR.

[0089] S560: Decompresses compressed data using a decompression algorithm, uses the decompressed data as the valid data body, and outputs the length of the valid data body so that upper-layer applications can obtain the content of the valid data body.

[0090] For example, the decompression algorithm is the same as the compression algorithm, both being LZSS.

[0091] The above implementation method, by adopting a decryption and decompression pipeline that is strictly reverse-symmetrical to the writing process, not only significantly improves the storage space utilization of the NFC tag chip, but also effectively ensures the confidentiality and anti-tampering capability of the data, and achieves secure and reliable data restoration.

[0092] As one possible implementation, an error is returned in the event of a discrepancy (indicating that the data has been tampered with or is incomplete).

[0093] Existing Flash pre-configuration methods in communication solutions lack structured version verification and integrity protection. They typically write raw data directly to a fixed address without version identification or integrity checks. When the pre-configuration data structure changes after a firmware upgrade, the old pre-configuration data cannot be automatically recognized as invalid, leading to system startup anomalies. To address this technical problem, Figure 6 This diagram illustrates the overall flow of a communication method based on a universal link layer frame format, according to another embodiment of the present invention, applicable to non-streaming storage media (such as Flash). Figure 6 The method shown includes steps S610 to S640.

[0094] S610: Validity Check Step: Read the frame header from the preset fixed address of the non-streaming storage medium and determine whether the frame header meets the link layer frame format requirements. If the link layer frame format requirements are met, perform integrity verification on the data body corresponding to the frame header to obtain the verification result, and compare the verification result with the verification value recorded in the verification field in the frame header. If the comparison is consistent, mark the data body corresponding to the frame header as valid.

[0095] S620: Data Reading Steps - Supports Two Reading Modes: Mode 1: In response to receiving a special offset value marker (such as 0xFFFFFFFF), return the frame header.

[0096] Mode 2: In response to receiving the target offset and target read length, read the data indicating the target read length in bytes from the non-streaming storage medium at an offset address after a preset fixed address. If the sum of the target offset and the target read length is greater than the byte length corresponding to the data length field, the target read length is truncated to a length within the valid range.

[0097] For example, if the target offset is offset and the target read length is length, then the offset address is frame header address + 8 + offset, where 8 represents the fixed length corresponding to the frame header. The length bytes of data are read from the offset address (frame header address + 8 + offset).

[0098] S630: Data Writing Steps - Supports Two Writing Modes: Mode 1: In response to receiving a special offset value marker, the frame header to be written is written to the header area of ​​the non-streaming storage medium.

[0099] Mode 2: In response to receiving the target offset and target write length, the data to be written is written to the corresponding offset address in the non-streaming storage medium.

[0100] S640: Closed-loop verification step: After the data writing step is completed, the validity check step is re-executed to ensure that the writing is correct and the verification passes.

[0101] The above implementation method uses a unified frame format for structured access to non-streaming storage media, and combines special offset value interface reuse, automatic truncation protection against out-of-bounds access, and a closed-loop verification mechanism after writing. This simplifies the calling logic of upper-layer applications, effectively avoids system anomalies caused by out-of-bounds storage reads, and ensures the absolute security and reliability of pre-configured data in terms of version compatibility, integrity verification, and physical storage.

[0102] According to a further embodiment of the present invention, an electronic device is also provided. Figure 7This diagram illustrates a schematic block diagram of an electronic device employing a processor-based hardware implementation according to an embodiment of the present invention. The hardware structure of the electronic device of the present invention can be implemented using a bus architecture. The bus architecture can include any number of interconnect buses and bridges, depending on the specific application and overall design constraints of the hardware. Bus 1100 connects various circuits including one or more processors 1200, memory 1300, and / or hardware modules. Bus 1100 can also connect various other circuits 1400 such as peripheral devices, voltage regulators, power management circuits, external antennas, etc. Bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Component (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one connecting line is used in this diagram, but this does not imply that there is only one bus or one type of bus. Memory 1300 stores a computer program, and when processor 1200 executes the computer program, processor 1200 can perform the methods of the above embodiments of the present invention.

[0103] The present invention also provides a readable storage medium storing a computer program, which, when executed by a processor, is used to implement the methods described above. A "readable storage medium" can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples of a readable storage medium include: an electrical connection (electronic device) having one or more wires, a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM), etc.

[0104] This invention also provides a computer program product. The method of this invention can be implemented wholly or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, the processes or functions of this invention are performed wholly or partially.

[0105] Computer programs or instructions can be stored in a readable storage medium or transferred from one readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The readable storage medium can be any available medium capable of access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or it can include both volatile and non-volatile types of storage media.

[0106] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0107] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus, and computer program products according to the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0108] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0109] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0110] In the description of this specification, the references to terms such as "one embodiment / mode," "some embodiments / modes," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, or characteristic described in connection with that embodiment / mode or example is included in at least one embodiment / mode or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment / mode or example. Moreover, the specific features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments / modes or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments / modes or examples described in this specification, as well as the features of different embodiments / modes or examples.

[0111] Those skilled in the art should understand that the above embodiments are merely for illustrating the present invention and are not intended to limit the scope of the invention. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present invention.

Claims

1. A communication method based on a universal link layer frame format, characterized in that, include: In response to receiving data through the physical communication interface, a fixed length of data is read through the underlying receiving function corresponding to the physical communication interface and used as candidate frame header data. Determine whether the candidate frame header data meets the link layer frame format requirements; If the candidate frame header data does not meet the link layer frame format requirements and the length of the received data is not zero, the candidate frame header data is routed to the command line processing buffer as command line data, and the remaining data is continued to be read and appended to the command line processing buffer through the underlying receiving function. If the candidate frame header data meets the link layer frame format requirements, the field value of the data length field in the candidate frame header data is extracted, and the data of the length corresponding to the field value is read as the candidate data body through the underlying receiving function; The integrity of the candidate data body is verified to obtain the verification result, and the verification result is compared with the verification value recorded in the verification field in the candidate frame header data. If the comparison is consistent, the candidate data body is determined to be a valid data body, and the length of the valid data body is output so that the upper layer application can obtain the content of the valid data body from the receive buffer corresponding to the physical communication interface.

2. The communication method based on the general link layer frame format as described in claim 1, characterized in that, Determining whether the candidate frame header data meets the link layer frame format requirements includes: Determine whether the byte length of the read candidate frame header data is equal to the fixed length; Determine whether the value of the identifier field in the candidate frame header data falls within the valid value range of the protocol corresponding to the physical communication interface; Determine whether the value of the version number field in the candidate frame header data matches the preset protocol version number; Determine whether the byte length corresponding to the data length field in the candidate frame header data is less than or equal to the maximum capacity of the receive buffer corresponding to the physical communication interface; If all four judgment results are yes, the candidate frame header data is determined to meet the link layer frame format requirements; if any judgment result is no, the candidate frame header data is determined to not meet the link layer frame format requirements.

3. The communication method based on the general link layer frame format as described in claim 1, characterized in that, Also includes: Determine the communication protocol type corresponding to the data to be sent; The frame header is constructed based on the link layer frame format, which includes a frame header and a data body. The frame header includes an identifier field, a version number field, a data length field, and a checksum field. The identifier field is assigned a corresponding semantic value according to the type of the communication protocol. Set the field value of the data length field according to the data length of the data to be sent, and calculate the verification value based on the data to be sent to fill the verification field; The data to be sent is used as the data body, and concatenated with the frame header in the order of the frame header first and the data body last to form a link layer frame; The link layer frame is sent through the physical communication interface corresponding to the communication protocol type.

4. The communication method based on the general link layer frame format as described in claim 1, characterized in that, After continuing to read the remaining data through the underlying receive function and appending it to the command-line processing buffer, the process includes: The remaining data is continuously read through the underlying receiving function and appended to the command line processing buffer until the receiving duration reaches the time threshold, or the remaining available space of the command line processing buffer is zero. The command-line data in the command-line processing buffer is parsed to generate corresponding response data; The response data is sent simultaneously via the UART physical serial port and the USB CDC virtual serial port; Clear the command-line processing buffer to wait for the next round of data reception.

5. The communication method based on the general link layer frame format as described in claim 3, characterized in that, When the physical communication interface is in NFC card mode, the method further includes: an NFC card mode atomic write step, comprising: Construct an empty frame header with the identification field set to invalid, write the empty frame header into the header storage area of ​​the NFC tag chip, and clear the data storage area of ​​the NFC tag chip. The data to be sent is compressed using a compression algorithm to obtain compressed data and compressed length. The compressed data is encrypted using an encryption algorithm to obtain encrypted compressed data; The encrypted and compressed data is used as the data body and written into the data storage area of ​​the NFC tag chip, starting from the offset address after the header storage area. After the encrypted compressed data is written, a complete frame header is constructed based on the encrypted compressed data and the compressed length, and written to the header storage area of ​​the NFC tag chip to cover the empty frame header. Output the length of the data to be sent so that the upper-layer application can confirm that the data to be sent has been successfully written.

6. The communication method based on the general link layer frame format as described in claim 5, characterized in that, When the physical communication interface is in NFC card mode, the candidate data body is encrypted and compressed data; If the verification result matches the verification value, the method further includes: The encrypted compressed data is decrypted using a decryption algorithm to recover the compressed data. The compressed data is decompressed using a decompression algorithm, and the decompressed data is used as the valid data body.

7. The communication method based on the general link layer frame format as described in claim 1, characterized in that, When the physical communication interface is a non-streaming storage interface, the method further includes a structured access step for the non-streaming storage medium, including: Validity check steps: Read the frame header from the preset fixed address of the non-streaming storage medium and determine whether the frame header meets the link layer frame format requirements; if the link layer frame format requirements are met, perform integrity verification on the data body corresponding to the frame header to obtain the verification result, and compare the verification result with the verification value recorded in the verification field in the frame header; if the comparison is consistent, mark the data body corresponding to the frame header as valid. Data reading steps: In response to receiving a special offset value marker, return the frame header; or in response to receiving a target offset and a target read length, read data indicating the number of bytes of the target read length from the offset address after the preset fixed address in the non-streaming storage medium; wherein, if the sum of the target offset and the target read length is greater than the byte length corresponding to the data length field, the target read length is truncated to a length within the valid range; Data writing steps: In response to receiving the special offset value marker, the frame header to be written is written to the header area of ​​the non-streaming storage medium; or in response to receiving the target offset and target write length, the data to be written is written to the corresponding offset address in the non-streaming storage medium. Closed-loop verification step: After the data writing step is completed, the validity check step is re-executed.

8. An electronic device, characterized in that, include: The memory stores execution instructions; as well as A processor that executes execution instructions stored in the memory, causing the processor to perform the communication method based on the general link layer frame format as described in any one of claims 1 to 7.

9. A readable storage medium, characterized in that, The readable storage medium stores execution instructions, which, when executed by a processor, are used to implement the communication method based on the general link layer frame format as described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the communication method based on the general link layer frame format as described in any one of claims 1 to 7.

Images