Multi-communication protocol adapted apparatus, method and storage medium

Abstract

The present disclosure provides a multi-communication protocol adaptation apparatus, method and storage medium. A multi-communication protocol adaptation apparatus comprises: a data transceiver module configured to transmit and / or receive data; one or more hardware universal function modules connected with the data transceiver module, wherein each hardware universal function module of the one or more hardware universal function modules comprises a corresponding configuration register group, wherein each configuration register group is configured to store configuration parameters, and wherein each hardware universal function module operates based on the configuration parameters in the corresponding configuration register group; and a control unit connected with the one or more hardware universal function modules and configured to write configuration parameters to the corresponding configuration register group based on protocol feature information corresponding to a currently adapted target communication protocol.

Description

Technical Field

[0001] This disclosure relates to the field of communication chip design, and more specifically, to an apparatus, method, and storage medium for multi-communication protocol adaptation. Background Technology

[0002] The 2.4GHz ISM (Industrial, Scientific, and Medical) band is currently the most widely used unlicensed wireless communication band globally. In recent years, wireless communication protocols operating in this band have experienced explosive growth, primarily including Bluetooth Classic, Bluetooth Low Energy, Zigbee, Thread, Matter, StarFlash, Aliro, and various proprietary 2.4GHz protocols. Currently, chip solutions for multi-protocol adaptation suffer from poor flexibility, wasted hardware resources, high power consumption, and high cost. Therefore, there is an urgent need for a chip architecture solution that can flexibly support multiple communication protocol adaptations through software configuration while maintaining low power consumption and low cost advantages. Summary of the Invention

[0003] Embodiments of this disclosure provide an apparatus for adapting to multiple communication protocols, comprising: a data transceiver module configured to send and / or receive data; one or more hardware general-purpose function modules connected to the data transceiver module, wherein each of the one or more hardware general-purpose function modules includes a corresponding configuration register group, wherein each configuration register group is configured to store configuration parameters, wherein each hardware general-purpose function module operates based on the configuration parameters in the corresponding configuration register group; and a control unit connected to the one or more hardware general-purpose function modules and configured to write configuration parameters to the corresponding configuration register group based on protocol feature information corresponding to the currently adapted target communication protocol, wherein the protocol feature information includes information related to at least one of timing control, security algorithm, data verification, data packet processing, physical layer transmission, and data preprocessing of the target communication protocol.

[0004] According to embodiments of this disclosure, the one or more general-purpose hardware modules include at least one of the following: a timing control module configured to control the operating timing and data transmission / reception mode of the data transceiver module based on configuration parameters in a corresponding configuration register group; a security processing module configured to perform at least one of encryption, decryption, or hash operations on the data based on configuration parameters in a corresponding configuration register group; a verification processing module configured to perform cyclic redundancy check on the data based on configuration parameters in a corresponding configuration register group; a data packet processing module configured to perform hardware-level assembly or parsing of data packets based on configuration parameters in a corresponding configuration register group; a physical layer transmission control module configured to control the physical layer transmission of the data based on configuration parameters in a corresponding configuration register group; and a data preprocessing module configured to perform whitening or dewhitening processing on the data based on configuration parameters in a corresponding configuration register group.

[0005] According to embodiments of this disclosure, the configuration register group of the timing control module includes at least one of the following: a data transceiver mode configuration register, configured to store configuration parameters related to the data transceiver mode of the data transceiver module, wherein the data transceiver mode includes at least one of a transmit mode, a receive mode, an idle mode, a continuous transmit mode, or a continuous receive mode; a timed transmit start time configuration register, configured to store configuration parameters related to the start time of timed transmit; a timed receive start time configuration register, configured to store configuration parameters related to the start time of timed receive; a receive timeout threshold configuration register, configured to store configuration parameters related to a time threshold used to determine whether data reception has timed out; and a transmit frame interval configuration register, configured to store configuration parameters related to the frame interval used to transmit the data.

[0006] According to embodiments of this disclosure, the configuration register group of the security processing module includes at least one of the following: an algorithm configuration register configured to store configuration parameters related to the type of the selected encryption and / or decryption algorithm; a key length configuration register configured to store configuration parameters related to the key length; and a working mode configuration register configured to store configuration parameters related to the working mode of the encryption and / or decryption algorithm, wherein the working mode includes at least one of Electronic Codebook (ECB) mode, Cipher Block Linking (CBC) mode, and Counter (CTR) mode.

[0007] According to embodiments of this disclosure, the configuration register group of the verification processing module includes at least one of the following: an initial value configuration register, configured to store configuration parameters related to the initial value used for cyclic redundancy check (CRBC); a polynomial configuration register, configured to store configuration parameters related to the polynomial used for CRBC; a check code length configuration register, configured to store configuration parameters related to the length of the CRBC code; a byte order mode configuration register, configured to store information related to the byte order mode of the CRBC result, wherein the byte order mode includes at least one of big-endian or little-endian; an input data inversion enable register, configured to store configuration parameters related to whether the inversion function of the input data for CRBC is enabled; and an output result inversion enable register, configured to store configuration parameters related to whether the inversion function of the output result for CRBC is enabled.

[0008] According to embodiments of this disclosure, the configuration register group of the packet processing module includes at least one of the following: a preamble length configuration register, configured to store configuration parameters related to the length of the preamble of the packet; a preamble content configuration register, configured to store configuration parameters related to the content of the preamble of the packet; a synchronization word length configuration register, configured to store configuration parameters related to the length of the synchronization word of the packet; a synchronization word content configuration register, configured to store configuration parameters related to the content of the synchronization word of the packet; a header length configuration register, configured to store configuration parameters related to the length of the header of the packet; a payload length configuration register, configured to store configuration parameters related to the length of the payload of the packet; a packet format configuration register, configured to store configuration parameters related to the format of the packet; and an address matching enable configuration register, configured to store configuration parameters related to whether the address matching function of the packet is enabled.

[0009] According to embodiments of this disclosure, the configuration register group of the physical layer transmission control module includes at least one of the following: a transmission rate configuration register configured to store configuration parameters related to the transmission rate used for physical layer transmission; a modulation scheme configuration register configured to store configuration parameters related to the modulation scheme used for physical layer transmission; a frequency offset configuration register configured to store configuration parameters related to the frequency offset used for physical layer transmission; a transmit power configuration register configured to store configuration parameters related to the transmit power used for physical layer transmission; and a channel selection configuration register configured to store configuration parameters related to the channel selection used for physical layer transmission.

[0010] According to embodiments of this disclosure, the configuration register group of the data preprocessing module includes at least one of the following: a whitening enable configuration register, configured to store configuration parameters related to whether the whitening function is enabled; a whitening seed configuration register, configured to store configuration parameters related to the whitening seed used for the whitening function; and a whitening polynomial configuration register, configured to store configuration parameters related to the whitening polynomial used for the whitening function.

[0011] According to embodiments of this disclosure, the target communication protocol includes at least one of the following: Bluetooth protocol, Bluetooth Low Energy (BLE) protocol, Zigbee protocol, Thread protocol, Matter protocol, SparkLink protocol, Aliro protocol, and proprietary 2.4G protocol.

[0012] According to embodiments of this disclosure, the one or more general-purpose hardware modules do not have hardware wiring logic dedicated to any of the multiple communication protocols, and the configuration parameters are configured by the control unit via software.

[0013] This disclosure provides a method for multi-communication protocol adaptation, comprising: acquiring protocol feature information corresponding to the target communication protocol to be adapted; writing configuration parameters to one or more configuration register groups corresponding to one or more hardware general-purpose function modules based on the protocol feature information, wherein the configuration parameters correspond to the protocol feature information, wherein the one or more hardware general-purpose function modules operate based on the configuration parameters in the corresponding configuration register groups, wherein the protocol feature information includes information related to at least one of the following of the target communication protocol: timing control, security algorithm, data verification, data packet processing, physical layer transmission, and data preprocessing.

[0014] Embodiments of this disclosure provide a computer-readable storage medium having computer-readable instructions stored thereon, which, when executed by a processor, can be used to implement a method for multi-communication protocol adaptation according to embodiments of this disclosure.

[0015] This disclosure proposes an apparatus and method that supports multiple communication protocol adaptations, which can flexibly support multiple communication protocol adaptations through software configuration while maintaining the advantages of low power consumption and low cost. Attached Figure Description

[0016] The accompanying drawings are not necessarily drawn to scale. In all the drawings, for illustrative purposes, elements with similar structures or functions are often indicated by the same reference numerals or portions thereof. The drawings are merely for the purpose of facilitating the description of the various embodiments described herein. The drawings do not describe every aspect of the teachings disclosed herein and do not limit the scope of the claims. To prevent obscurity, not all components, connections, etc., are shown, and not all components have reference numerals. However, the pattern of component configuration can be readily discerned from the drawings. The drawings, together with the specification, illustrate exemplary embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. The above and other aspects, features, and advantages of certain embodiments of the present disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings, wherein:

[0017] Figure 1 A schematic diagram of a multi-communication protocol adaptation apparatus according to an embodiment of the present disclosure is shown;

[0018] Figure 2 Examples of one or more general-purpose hardware functional modules determined based on one or more functional domains common to multiple communication protocols, according to embodiments of this disclosure, are shown.

[0019] Figure 3 A schematic diagram of a method for adapting multiple communication protocols according to an embodiment of the present disclosure is shown. Detailed Implementation

[0020] Before proceeding with the detailed description below, it may be advantageous to define certain words and phrases used throughout this patent document. The terms “coupled,” “connected,” and their derivatives refer to any direct or indirect communication or connection between two or more elements, regardless of whether those elements are physically in contact with each other. The terms “transmit,” “receive,” and “communicate,” and their derivatives cover both direct and indirect communication. The terms “comprising” and “including,” and their derivatives refer to, but are not limited to, those including, those including, those including, those including. The term “or” is inclusive, meaning and / or. The phrases “associated with,” “corresponding to,” and their derivatives refer to, including, being contained within, interconnected, containing, being included in, connected or connected to, coupled or coupled to, communicating with, cooperating, intertwined, juxtaposed, proximate, bound or bound to, having, having attributes, having a relationship or being related to, etc. The term “controller” refers to any device, system, or part thereof that controls at least one operation. Such a controller may be implemented in hardware, or a combination of hardware and software and / or firmware. The functionality associated with any particular controller may be centralized or distributed, local or remote. The phrase "at least one" when used with a list of items means that different combinations of one or more of the listed items may be used, and that only one item from the list may be required. For example, "at least one of A, B, and C" includes any of the following combinations: A, B, C, A and B, A and C, B and C, A and B and C.

[0021] Definitions of other specific words and phrases are provided throughout this patent document. Those skilled in the art will understand that, in many, if not most, cases, such definitions apply to the prior and future use of the words and phrases thus defined.

[0022] In this patent document, the application combination of modules and the hierarchical division of submodules are for illustrative purposes only. Without departing from the scope of this disclosure, the application combination of modules and the hierarchical division of submodules can be implemented in different ways. The embodiments of this disclosure can be implemented in different forms and should not be construed as being limited to the embodiments set forth herein. Rather, these embodiments are provided to make this disclosure thorough and complete, and to fully convey exemplary implementation methods to those skilled in the art. The embodiments of this disclosure can be combined in any way to form other embodiments.

[0023] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this disclosure.

[0024] The 2.4 GHz ISM (Industrial, Scientific, and Medical) band is currently the most widely used unlicensed wireless communication band globally. In recent years, wireless communication protocols operating in this band have experienced explosive growth, primarily including:

[0025] Bluetooth Classic is primarily used for audio transmission, file transfer, and other similar scenarios.

[0026] Bluetooth Low Energy (BLE) is widely used in IoT terminals, wearable devices, smart homes, and other fields.

[0027] Zigbee, based on the IEEE 802.15.4 standard, is widely used in smart homes and industrial automation.

[0028] Thread, also based on the IEEE 802.15.4 standard, supports IP-based mesh networks;

[0029] Matter, a unified application layer protocol launched by the Connectivity Standards Alliance (CSA), can run on top of various underlying transmissions such as BLE, Thread, and Wi-Fi.

[0030] SparkLink is a new generation of short-range wireless communication standard led by China.

[0031] Aliro is a protocol used in near-field communication scenarios such as digital keys.

[0032] Various proprietary 2.4G protocols, which are proprietary protocols developed by various manufacturers for specific application scenarios.

[0033] Currently, the mainstream 2.4G multi-protocol chip solutions in the industry mainly fall into the following technical categories. The first is a multi-chip discrete solution, which uses different RF chips for different protocols, with each chip independently handling the transmission, reception, and processing of its corresponding protocol. While this solution offers functional independence, it suffers from drawbacks such as high hardware costs, large printed circuit board (PCB) area, high power consumption, and complex coordination and switching between different protocol chips. The second is a fixed multi-protocol system-on-a-chip (SoC) solution, which integrates the protocol stacks of multiple protocols onto a single chip, allowing switching between different protocols via software configuration. This approach reduces hardware costs to some extent, but it has significant technical drawbacks: First, the supported protocol types must be predetermined during the chip design phase. Once tape-out is complete, the protocol types are fixed, making it impossible to add unsupported protocols after tape-out. Second, protocol upgrades or the addition of new protocol features require hardware modifications, which cannot be achieved through software updates. Third, different protocols have varying requirements for packet formats, synchronization word lengths, cyclic redundancy check (CRC) algorithms, encryption algorithms, etc., making it difficult for a fixed architecture to adapt flexibly. Finally, the chip contains a large amount of hard-coded logic specific to certain protocols, resulting in wasted resources. The third approach is Software Defined Radio (SDR), which digitizes radio frequency signals using a high-speed analog-to-digital converter (ADC) / digital-to-analog converter (DAC), with modulation, demodulation, and protocol parsing all handled by software. This approach offers the highest flexibility, but it has extremely high processor performance requirements, consumes a lot of power, and is expensive, making it unsuitable for power- and cost-sensitive IoT terminal devices.

[0034] Based on the above analysis, existing 2.4G multi-protocol chip solutions have the following technical shortcomings:

[0035] Poor flexibility and fixed protocol types: Fixed-protocol SoC solutions determine the supported protocol types during the chip design phase, making it impossible to add unsupported protocols after tape-out. With the continuous emergence of new protocols in the 2.4G band (such as StarFlash, Aliro, etc.), terminal manufacturers who need to support new protocols can only wait for the next generation of chips or add additional chips, resulting in long product iteration cycles.

[0036] Upgrades are difficult and cannot keep up with protocol evolution: Each 2.4G protocol is constantly evolving, with new features being added continuously. In existing solutions, protocol-related data packet formats, synchronization address lengths, CRC algorithm parameters, encryption algorithms, etc., are typically implemented using hard-wired logic. After a protocol upgrade, the hardware cannot be updated accordingly, causing the chip to malfunction under the new protocol version.

[0037] Wasted hardware resources and high costs: To support multiple protocols, existing SoC solutions need to integrate dedicated processing logic for multiple protocols inside the chip. The reusability between modules of different protocols is poor, and a large number of hardware resources are idle, resulting in a waste of chip area and power consumption.

[0038] Low development efficiency: Different protocols have different requirements for physical layer parameters (modulation method, rate, whitening algorithm, etc.), data link layer parameters (data packet format, synchronization word, CRC, etc.), and security layer parameters (encryption algorithm, key length, etc.). Developers need to write a large amount of low-level driver code for each protocol, resulting in long development cycles and high maintenance costs.

[0039] Complex supply chain management: To meet the needs of different customers and markets for protocol support, terminal manufacturers need to stock various chip models with different protocol configurations, which complicates inventory management and increases supply chain costs and risks.

[0040] Therefore, there is an urgent need for a chip architecture solution that can flexibly support multiple communication protocol adaptations through software configuration while maintaining the advantages of low power consumption and low cost.

[0041] To address the problems of poor flexibility, difficulty in upgrading, waste of resources, low development efficiency, and complex supply chain in the existing technologies mentioned above, this disclosure proposes a modular multi-protocol SoC chip architecture and its implementation method.

[0042] According to embodiments of this disclosure, the wireless communication function of a chip can be decomposed into a series of standardized, configurable, and composable basic hardware modules, such as: a timing control module, a security processing module, a verification processing module, a data packet processing module, a physical layer transmission control module, and a data preprocessing module. Each module can expose a configuration interface to the software through a register interface, allowing for flexible parameter configuration via software. The software (protocol stack) can combine and call these basic hardware modules to build complete transmit and receive processes required for different protocols, much like "building blocks." Differences between different protocols can be achieved through combinations of different configuration parameters of the modules, rather than through different hardwired logic for different protocols. When a protocol is upgraded or a new protocol is added, only the software configuration or firmware needs to be updated; no hardware modification is required.

[0043] The core advantages of this disclosure are: extremely high flexibility, for example, the same chip can support any 2.4G protocol through software configuration, without being limited by the type of protocol at the time of tape-out; upgradeability, for example, when the protocol evolves or new features are added, only the software needs to be upgraded, without replacing the chip; efficient reuse of hardware resources, for example, all protocols can share the same set of basic hardware modules, avoiding redundant design and reducing chip area and power consumption; and lower development threshold, for example, providing a unified and concise hardware abstraction interface, so that software developers can quickly implement support for new protocols without having to deeply understand the hardware details.

[0044] Next, exemplary embodiments of this disclosure will be further described with reference to the accompanying drawings.

[0045] Figure 1 A schematic diagram of a multi-communication protocol adaptation device 100 according to an embodiment of the present disclosure is shown.

[0046] like Figure 1 As shown, the device 100 may include a data transceiver module 110, one or more general-purpose hardware modules 120, and a control unit 130.

[0047] The data transceiver module 110 can be configured to send and / or receive data. In some embodiments, the data transceiver module 110 may be a radio frequency front-end module and / or a corresponding data transceiver included in a wireless communication device.

[0048] One or more general-purpose hardware modules 120 can be connected to the data transceiver module 110.

[0049] Each of the one or more hardware general-purpose function modules 120 may include a corresponding configuration register set. Each configuration register set can be configured to store configuration parameters. Each hardware general-purpose function module can operate based on the configuration parameters in the corresponding configuration register set.

[0050] The control unit 130 can be connected to the data transceiver module 110 and / or one or more general-purpose hardware modules. The control unit 130 can be configured to write configuration parameters to the corresponding configuration register set based on protocol feature information corresponding to the currently adapted target communication protocol. In some embodiments, the control unit 130 can be a CPU for controlling the overall operation of the control device 100.

[0051] In some implementations, the protocol feature information may include at least one of the following related to the target communication protocol: timing control, security algorithm, data verification, packet processing, physical layer transmission, data preprocessing, etc.

[0052] For example, protocol feature information may include parameters or information required by the target communication protocol related to at least one of the following configurations: data transmission / reception mode, timed transmission start time, timed reception start time, reception timeout threshold, transmission frame interval, encryption / decryption algorithm, hash algorithm, key length, operating mode of encryption and / or decryption algorithm, initial value for CRC, polynomial for CRC, length of cyclic redundancy check code, byte order mode, input data inversion enable, output result inversion enable, preamble length of data packet, content of preamble of data packet, length of synchronization word of data packet, content of synchronization word of data packet, length of packet header, length of packet payload, format of data packet, whether address matching function of data packet is enabled, transmission rate of physical layer transmission, modulation method of physical layer transmission, frequency offset of physical layer transmission, transmit power of physical layer transmission, channel selection of physical layer transmission, whether whitening function is enabled, whitening seed for whitening function, whitening polynomial for whitening function, etc.

[0053] In some implementations, one or more hardware general function modules 120 may include one or more of the following: timing control module 121, security processing module 122, verification processing module 123, data packet processing module 124, physical layer transmission control module 125, and data preprocessing module 126.

[0054] In some implementations, one or more hardware general-purpose functional modules 120 may be determined based on one or more functional domains common to multiple communication protocols (e.g., shared by all).

[0055] For example, Figure 2 Examples of one or more general-purpose hardware functional modules determined based on one or more functional domains common to multiple communication protocols are shown according to embodiments of this disclosure.

[0056] like Figure 2 As shown, taking Bluetooth protocol 211, BLE protocol 212, Zigbee protocol 213, and Thread protocol 214 as examples, based on their respective protocol characteristics, these four protocols can share one or more functional domains. For example, one or more of the following: timing control functional domain 221 related to timing control and / or data transmission mode; security processing functional domain 222 related to data encryption / decryption processing; verification processing functional domain 223 related to data integrity / error verification (e.g., CRC verification); data packet processing functional domain 224 related to data link layer processing of data packets; physical layer transmission control functional domain 225 related to physical layer transmission rate, modulation method, and transmit power control of data packets; and data preprocessing functional domain 226 related to data preprocessing (e.g., whitening / dewhitening).

[0057] In this scenario, one or more corresponding hardware basic function modules can be set up for each of these functional domains. For example, timing control module 121, security processing module 122, verification processing module 123, data packet processing module 124, physical layer transmission control module 125, and data preprocessing module 126 can correspond to timing control functional domain 221, security processing functional domain 222, verification processing functional domain 223, data packet processing functional domain 224, physical layer transmission control functional domain 225, and data preprocessing functional domain 226, respectively. These hardware basic function modules may not have dedicated hardware wiring logic for any of the multiple communication protocols. When running different protocols, these hardware basic function modules can be reused, and only different configuration parameters need to be configured in the corresponding register groups.

[0058] In some implementations, the configuration parameters can be configured by the control unit 130 via software.

[0059] In some implementations, the timing control module 121 can be configured to control the operating timing and data transmission / reception mode of the data transceiver module 110 based on the configuration parameters in the corresponding configuration register group.

[0060] In some implementations, the security processing module 122 may be configured to perform at least one of encryption, decryption, or hash operations on the data based on configuration parameters in the corresponding configuration register set.

[0061] In some implementations, the verification processing module 123 may be configured to perform cyclic redundancy check (CRC) on the data based on the configuration parameters in the corresponding configuration register set.

[0062] In some implementations, the packet processing module 124 can be configured to perform hardware-level assembly or parsing of data packets based on configuration parameters in the corresponding configuration register set.

[0063] In some implementations, the physical layer transport control module 125 can be configured to control the physical layer transport of data based on configuration parameters in a corresponding configuration register set.

[0064] In some implementations, the data preprocessing module 126 can be configured to preprocess the data based on configuration parameters in the corresponding configuration register set, such as whitening or dewhitening.

[0065] In some implementations, the configuration register set of the timing control module 121 may include at least one of the following:

[0066] The data transceiver mode configuration register is configured to store configuration parameters related to the data transceiver mode of the data transceiver module, wherein the data transceiver mode includes at least one of the following: transmit mode, receive mode, idle mode, continuous transmit mode, or continuous receive mode.

[0067] The timed transmission start time configuration register is configured to store configuration parameters related to the start time of the timed transmission;

[0068] The timed receive start time configuration register is configured to store configuration parameters related to the start time of timed receive;

[0069] The receive timeout threshold configuration register is configured to store configuration parameters related to the time threshold used to determine whether data reception has timed out;

[0070] The transmit frame interval configuration register is configured to store configuration parameters related to the frame interval used to transmit the data.

[0071] In some implementations, the configuration register set of the security processing module 122 may include at least one of the following:

[0072] The algorithm configuration register is configured to store configuration parameters related to the type of encryption and / or decryption algorithm selected;

[0073] The key length configuration register is configured to store configuration parameters related to the key length.

[0074] The operating mode configuration register is configured to store configuration parameters related to the operating mode of the encryption and / or decryption algorithm, wherein the operating mode includes at least one of Electronic Codebook (ECB) mode, Cipher Block Linking (CBC) mode, and Counter (CTR) mode.

[0075] In some implementations, the configuration register set of the verification processing module 123 may include at least one of the following:

[0076] The initial value configuration register is configured to store configuration parameters related to the initial value used for cyclic redundancy check;

[0077] The polynomial configuration register is configured to store configuration parameters related to the polynomial used for cyclic redundancy check;

[0078] The check code length configuration register is configured to store configuration parameters related to the length of the cyclic redundancy check code.

[0079] A byte order mode configuration register is configured to store information related to the byte order mode of the cyclic redundancy check result, wherein the byte order mode includes at least one of big-endian or little-endian.

[0080] The Input Data Inversion Enable Register is configured to store configuration parameters related to whether the inversion function of the input data for Cyclic Redundancy Check is enabled.

[0081] The Output Inversion Enable Register is configured to store configuration parameters related to whether the inversion function of the output result of Cyclic Redundancy Check is enabled.

[0082] In some implementations, the configuration register set of the packet processing module 124 may include at least one of the following:

[0083] The preamble length configuration register is configured to store configuration parameters related to the length of the preamble in a data packet.

[0084] The preamble content configuration register is configured to store configuration parameters related to the content of the preamble of the data packet.

[0085] The synchronization word length configuration register is configured to store configuration parameters related to the length of the synchronization word in the data packet;

[0086] The synchronization word content configuration register is configured to store configuration parameters related to the content of the synchronization word in the data packet;

[0087] The header length configuration register is configured to store configuration parameters related to the length of the packet header;

[0088] The payload length configuration register is configured to store configuration parameters related to the length of the packet's payload.

[0089] The packet format configuration register is configured to store configuration parameters related to the packet format;

[0090] The address matching enable configuration register is configured to store configuration parameters related to whether the address matching function for data packets is enabled.

[0091] In some implementations, the configuration register set of the physical layer transmission control module 125 may include at least one of the following:

[0092] The transmission rate configuration register is configured to store configuration parameters related to the transmission rate used for physical layer transmission;

[0093] The modulation scheme configuration register is configured to store configuration parameters related to the modulation scheme used for physical layer transmission;

[0094] The frequency offset configuration register is configured to store configuration parameters related to the frequency offset used for physical layer transmission;

[0095] The transmit power configuration register is configured to store configuration parameters related to the transmit power used for physical layer transmission;

[0096] The channel selection configuration register is configured to store configuration parameters related to channel selection used for physical layer transmission.

[0097] In some implementations, the configuration register set of the data preprocessing module 126 may include at least one of the following:

[0098] The whitening enable configuration register is configured to store configuration parameters related to whether the whitening function is enabled.

[0099] The whitening seed configuration register is configured to store configuration parameters related to the whitening seed used for the whitening function;

[0100] The whitening polynomial configuration register is configured to store configuration parameters related to the whitening polynomial used for the whitening function.

[0101] The methods provided in the embodiments of this disclosure will now be described in further detail with specific examples.

[0102] The modular multi-protocol SoC chip architecture described in this disclosure may include an RF front-end module and one or more general-purpose hardware functional modules (also referred to as basic hardware functional modules). Each module has a built-in dedicated register set, and all protocol-related configuration parameters can be flexibly configured by software through one or more registers included in the register set, thereby realizing the "hardware-provided capability, software-defined protocol" operating mechanism.

[0103] In one example implementation, the specific hardware components, register definitions, and core functions of each module are as follows:

[0104] 1. Timing control module

[0105] The timing control module (also known as the timing transceiver control module) is the core scheduling unit of the timing control functional domain of the chip described in this disclosure. It is responsible for controlling the working timing and / or data transceiver mode and / or state switching of the RF front-end module and / or the corresponding data transceiver.

[0106] The core functions of the timing control module 121 may include at least one of the following:

[0107] Transceiver switching control: Through register configuration, the software can specify the operation of the RF front-end module and / or the corresponding data transceiver in transmit mode (PTX), receive mode (PRX), or idle mode, etc.

[0108] Continuous transmission mode: After configuring continuous transmission enable, the hardware automatically sends data packets continuously according to the set frame interval, supporting scenarios such as protocol testing and beacon broadcasting;

[0109] Continuous reception mode: After configuring continuous reception enable, the hardware continuously monitors air signals, supporting scenarios such as scanning and sniffing;

[0110] Scheduled Transmit / Receive (Mode): Through the built-in timer, the radio frequency is precisely controlled to start transmitting or receiving at a specified time, which can meet the needs of scenarios with strict time accuracy requirements such as BLE connection events and Zigbee beacons;

[0111] Timeout control: Configure a receive timeout threshold. After the timeout, the hardware will automatically terminate the reception and generate an interrupt to avoid the CPU waiting in vain.

[0112] The RF front-end module and / or the corresponding data transceiver can switch between these modes.

[0113] The core registers of the timing control module 121 may include at least one of the following:

[0114] Data transceiver mode configuration register MODE_CTRL: is configured to store configuration parameters related to the data transceiver mode of the data transceiver module, wherein the data transceiver mode includes at least one of the following: transmit mode, receive mode, idle mode, continuous transmit mode, continuous receive mode, transmit-to-receive mode, receive-to-transmit mode, etc.

[0115] The scheduled transmission start time configuration register TX_START_TIME is configured to store configuration parameters related to the start time of the scheduled transmission.

[0116] The timed receive start time configuration register RX_START_TIME is configured to store configuration parameters related to the start time of timed receive.

[0117] The receive timeout threshold configuration register RX_TIMEOUT is configured to store configuration parameters related to the time threshold used to determine whether data reception has timed out.

[0118] Transmit Frame Interval Configuration Register TX_INTERVAL: Configured to store configuration parameters related to the frame interval used to transmit the data.

[0119] In addition, the timing control module 121 may also include a status register STATE_STATUS, which is configured to store information related to the current operating status identifier.

[0120] 2. Security Processing Module

[0121] The security processing module (also known as the encryption / decryption algorithm module) is the core computing unit of the security processing functional domain of the chip described in this disclosure, and is responsible for completing various encryption, decryption, and hash operations in wireless communication.

[0122] The algorithms supported by the security processing module 122 include:

[0123] AES (Advanced Encryption Standard): Supports AES-128, AES-192, AES-256, etc., and supports multiple working modes such as Electronic Codebook (ECB), Cipher Block Chaining (CBC), and Cipher Counter (CTR);

[0124] SHA (Secure Hash Algorithm): Supports hash algorithms such as SHA-1 and SHA-256;

[0125] SM4 (Chinese national standard block cipher algorithm): Supports SM4 encryption / decryption, meeting national standard compliance requirements;

[0126] Scalable algorithm interface: Reserves algorithm expansion registers to support the addition of new algorithms through subsequent hardware microcode updates.

[0127] The core registers of the security processing module 122 may include at least one of the following:

[0128] The algorithm configuration register ALG_SEL is configured to store configuration parameters related to the type of encryption and / or decryption algorithm selected (e.g., AES / SHA / SM4 / extended algorithms, etc.).

[0129] The key length configuration register KEY_LEN is configured to store configuration parameters related to the key length.

[0130] The operating mode configuration register MODE_SEL is configured to store configuration parameters related to the operating mode of the encryption and / or decryption algorithm, wherein the operating mode includes at least one of Electronic Codebook (ECB) mode, Cipher Block Linking (CBC) mode, and Counter (CTR) mode.

[0131] In addition, the security processing module 122 may also include one or more of the following registers:

[0132] The key buffer register KEY_BUF is configured as a buffer for key data (e.g., loadable via DMA).

[0133] The input data buffer register DATA_IN_BUF is configured as a buffer for data to be encrypted / decrypted.

[0134] The output data buffer register DATA_OUT_BUF is configured as a buffer for the encryption / decryption results;

[0135] The Algorithm Busy Flag Register ALG_BUSY is configured to store the algorithm busy status flag.

[0136] The Algorithm Completion Interrupt Flag Register ALG_DONE is configured to store the algorithm completion interrupt flag.

[0137] 3. Verification Processing Module

[0138] The verification processing module (also known as the CRC algorithm module) is the core computing unit of the verification processing functional domain of the chip described in this disclosure, and is responsible for completing the cyclic redundancy check (CRC) calculation and verification of data packets.

[0139] The configurable parameters supported by the verification processing module 123 include at least one of the following:

[0140] Configurable initial value: The initial value for CRC calculation can be set by software through a register to adapt to the different requirements of different protocols for the initial value of CRC.

[0141] Configurable checksum length: The CRC checksum length can be configured from 1 to 4 bytes to adapt to different protocols (such as BLE using 24-bit CRC, Zigbee using 16-bit CRC, etc.).

[0142] Configurable byte order mode: The byte order mode of the CRC result can be configured to big-endian or little-endian mode via registers;

[0143] Configurable polynomials: Supports multiple CRC polynomials (such as CRC-16, CRC-32, etc.), which can be selected via registers;

[0144] Configurable input / output inversion function: Supports input data inversion, output result inversion and other modes.

[0145] The core registers of the verification processing module 123 may include at least one of the following:

[0146] The initial value configuration register CRC_INIT is configured to store configuration parameters related to the initial value used for cyclic redundancy check;

[0147] The polynomial configuration register CRC_POLY is configured to store configuration parameters related to the polynomial used for cyclic redundancy check.

[0148] The check code length configuration register CRC_LEN is configured to store configuration parameters related to the length of the cyclic redundancy check code (e.g., 1 to 4 bytes).

[0149] The byte order mode configuration register CRC_ENDIAN is configured to store information related to the byte order mode of the cyclic redundancy check result, wherein the byte order mode includes at least one of big-endian mode or little-endian mode.

[0150] The Input Data Inversion Enable Register CRC_INV_IN is configured to store configuration parameters related to whether the inversion function of the input data for cyclic redundancy check is enabled.

[0151] The output result inversion enable register CRC_INV_OUT is configured to store configuration parameters related to whether the inversion function of the cyclic redundancy check output result is enabled.

[0152] In addition, the verification processing module 123 may also include one or more of the following registers:

[0153] The CRC_RESULT register is configured to store the CRC calculation results.

[0154] 4. Data packet processing module

[0155] The packet processing module (also known as the packet assembly / parsing module) is the core processing unit of the packet processing functional domain of the chip described in this disclosure, and is responsible for completing the hardware-level assembly (transmission direction) and / or parsing (reception direction) of wireless packets.

[0156] The packet processing module 124 supports flexible configuration of the format and length of each field of the data packet through registers, for example:

[0157] (1) Synchronization address (preamble + sync word / access address)

[0158] Configurable preamble length (e.g., 1 to 4 bytes);

[0159] Configurable Sync Word / Access Address length (e.g., 2~5 bytes);

[0160] Configurable word content for synchronization;

[0161] Supports automatic hardware verification of address matching.

[0162] (2) Baotou (Header)

[0163] Configurable header length (e.g., 0~3 bytes);

[0164] The bit width and meaning of each field in the packet header can be defined by software and transparently transmitted by hardware.

[0165] (3) Payload

[0166] Configurable payload length (e.g., 0~255 bytes);

[0167] Supports automatic loading of data to be sent from the FIFO;

[0168] Supports automatic writing of received data to the FIFO.

[0169] (4) CRC check field

[0170] The CRC field length can be configured in conjunction with the verification processing module;

[0171] It supports automatic appending (sending) and automatic verification (receiving) of the CRC field.

[0172] The core registers of the packet processing module 124 may include at least one of the following:

[0173] The Preamble Length Configuration Register PREAMBLE_LEN is configured to store configuration parameters related to the length of the preamble in a data packet.

[0174] The Preamble Content Configuration Register PREAMBLE_VAL is configured to store configuration parameters related to the content of the preamble in a data packet.

[0175] The SYNC_LEN synchronization word length configuration register is configured to store configuration parameters related to the length of the synchronization word in the data packet.

[0176] The SYNC_VAL register, which contains the synchronization word configuration, is configured to store configuration parameters related to the content of the synchronization word in the data packet.

[0177] The header length configuration register HEADER_LEN is configured to store configuration parameters related to the length of the packet header;

[0178] The payload length configuration register PAYLOAD_LEN is configured to store configuration parameters related to the length of the packet's payload (e.g., a maximum of 255 bytes).

[0179] The packet format configuration register PKT_FORMAT is configured to store configuration parameters related to the packet format (supporting multiple preset formats and custom formats).

[0180] The address matching enable configuration register ADDR_MATCH_EN is configured to store configuration parameters related to whether address matching functionality for data packets is enabled.

[0181] In addition, the packet processing module 124 may also include one or more of the following registers:

[0182] The address filter register ADDR_FILTER is configured to store address filter values.

[0183] 5. Physical Layer Transmission Control Module

[0184] The physical layer transmission control module (also known as the PHY rate and modulation module) is the core configuration unit of the physical layer transmission control functional domain of the chip described in this disclosure, and is responsible for controlling the physical layer transmission parameters of radio frequency.

[0185] The configurable parameters supported by the physical layer transmission control module 125 include at least one of the following:

[0186] Configurable transmission rates: For example, it supports multiple data rates such as Coded-125kbps, Coded-500kbps, 1Mbps, 2Mbps, and 250kbps;

[0187] Coded PHY support: For example, BLE Coded PHY (125kbps, 500kbps long-distance mode, etc.) is supported.

[0188] Configurable modulation schemes: For example, it supports multiple modulation schemes, such as Gaussian Frequency Shift Keying (GFSK) and Offset Quadrature Phase Shift Keying (O-QPSK).

[0189] Configurable frequency offset: Supports frequency offset parameter configuration;

[0190] Configurable transmit power: Supports multi-level transmit power adjustment.

[0191] The core registers of the physical layer transmission control module 125 may include at least one of the following:

[0192] The transmission rate configuration register RATE_SEL is configured to store configuration parameters related to the transmission rate used for physical layer transmission (e.g., 1M / 2M / Coded-125k / Coded-500k / 250kbps, etc.).

[0193] The modulation scheme configuration register MOD_SEL is configured to store configuration parameters related to the modulation scheme used for physical layer transmission;

[0194] The frequency offset configuration register FREQ_DEV is configured to store configuration parameters related to the frequency offset used for physical layer transmission.

[0195] The transmit power configuration register TX_POWER is configured to store configuration parameters related to the transmit power used for physical layer transmission;

[0196] The Channel Selection Configuration Register CHANNEL_SEL is configured to store configuration parameters related to channel selection used for physical layer transmission.

[0197] 6. Data Preprocessing Module

[0198] The data preprocessing module (e.g., the whitening module) is the core unit of the data preprocessing functional domain (or data auxiliary processing domain) of the chip described in this disclosure. It is responsible for preprocessing the data such as whitening / dewhitening to improve the spectral characteristics of the signal.

[0199] The configurable parameters supported by the data preprocessing module 126 include at least one of the following:

[0200] Whitening Enable: Enable or disable the whitening function via a register;

[0201] Configurable whitening seeds: Supports configuring multiple initial seed values ​​for various whitening algorithms to adapt to the whitening requirements of different protocols;

[0202] Configurable whitening polynomials: Supports configuring different whitening polynomials to adapt to different protocols.

[0203] The core registers of the data preprocessing module 126 may include at least one of the following:

[0204] The whitening enable configuration register WHITEN_EN is configured to store configuration parameters related to whether the whitening function is enabled.

[0205] The whitening seed configuration register WHITEN_SEED is configured to store configuration parameters related to the whitening seed used for the whitening function.

[0206] The whitening polynomial configuration register WHITEN_POLY is configured to store configuration parameters related to the whitening polynomial used for the whitening function.

[0207] More generally, each of the one or more general-purpose hardware modules described above may include processing hardware capable of supporting any one of multiple communication protocols and corresponding configuration registers, and may support configuration parameters adaptable to any one of the multiple communication protocols. When it is necessary to adapt to a specific target communication protocol, configuration parameters corresponding to the target communication protocol can be written to the corresponding configuration register group based on the protocol feature information corresponding to the target communication protocol, thereby controlling one or more general-purpose hardware modules to operate in a working mode that matches the target communication protocol.

[0208] In some implementations, one or more general-purpose hardware modules can be connected to the CPU via a register bus (e.g., Advanced Peripheral Bus (APB) / Advanced High-performance Bus (AHB)). Modules can coordinate with each other via hardware handshake signals. A typical protocol data packet transmission and reception process is as follows:

[0209] 1) Sending process:

[0210] The CPU configures the parameters of each module (e.g., packet format, rate, CRC parameter, encryption parameter, whitening parameter, etc.) through registers according to the currently running protocol type.

[0211] The CPU writes the data to be sent into the FIFO of the data packet processing module;

[0212] The CPU is configured with a timing control module to set the transmission start time (e.g., it can be sent immediately or sent at a set time).

[0213] Once the transmission time is reached, the timing control module initiates the transmission process;

[0214] The whitening module whitens the data (if enabled).

[0215] The verification processing module calculates and appends the CRC checksum;

[0216] The security processing module encrypts the data (if enabled);

[0217] The data packet processing module assembles the complete data packet according to the configured format;

[0218] The physical layer transmission control module completes radio frequency transmission according to the configured rate and modulation method;

[0219] Once the transmission is complete, the hardware generates a transmission completion interrupt to notify the CPU.

[0220] 2) Receiving process:

[0221] The CPU is configured with a timing control module to set the receive window start time and timeout threshold.

[0222] Once the receiving window is reached, the radio frequency enters the receiving state;

[0223] Upon receiving the data packet, the hardware automatically performs the following: synchronization word matching and verification, whitening / dewhitening processing, CRC verification, data decryption (if enabled), data packet parsing, and extraction of each field.

[0224] Valid data that passes verification is written to the FIFO, and a receive completion interrupt is generated to notify the CPU.

[0225] The CPU reads the FIFO to obtain valid data and performs subsequent processing according to the protocol stack software.

[0226] In the entire process described above, the CPU only participates in two stages: process startup configuration and data reading after interruption. The assembly, sending, receiving, parsing, verification, encryption and decryption of data packets are all completed autonomously by the hardware module, realizing an efficient division of labor of "software-defined protocol and hardware execution of sending and receiving".

[0227] The methods of embodiments of this disclosure are further described below with reference to several example scenarios.

[0228] First example scenario: Achieving BLE protocol adaptation through module configuration.

[0229] This example scenario uses the implementation of the BLE protocol on a single chip via software configuration to illustrate the parameter configuration methods for each module.

[0230] 1. Timing control module configuration

[0231] For BLE broadcast events: Configure a timed sending mode, and the broadcast interval can be controlled by software;

[0232] For BLE connection events: Configure timed receive / send mode, strictly following the connection anchor timing.

[0233] 2. Security processing module configuration

[0234] The AES-128 algorithm and ECB mode, which are compatible with the BLE protocol, are selected.

[0235] The key is generated and configured by the protocol stack during the pairing phase.

[0236] 3. Verification Processing Module Configuration

[0237] The BLE protocol uses a 24-bit CRC, with an initial value of 0x555555 (3 bytes in length).

[0238] Therefore, the checksum length CRC_LEN can be configured as 3, with an initial value of CRC_INIT=0x555555.

[0239] 4. Packet Processing Module Configuration

[0240] For BLE broadcast channel packets: Preamble length PREAMBLE_LEN = 1 byte (e.g., 0xAA), Synchronization word length SYNC_LEN = 4 bytes (e.g., 0x8E89BED6).

[0241] For BLE data channel packets: the preamble length PREAMBLE_LEN = 1 byte (e.g., 0xAA), and the access address and / or its length can be negotiated and configured at connection time;

[0242] The header length HEADER_LEN is 2 bytes (fields such as Link Layer Identifier (LLID), Next Expected Sequence Number (NESN), Sequence Number (SN), and More Data Flag (MD) are passed through by the hardware).

[0243] The payload length is variable (e.g., 0 to 255 bytes), for example, PAYLOAD_LEN can be set to the maximum value of 255;

[0244] The CRC field is automatically appended by the verification processing module.

[0245] 5. Physical Layer Transmission Control Module Configuration

[0246] For BLE 1M mode: RATE_SEL=1M, and the modulation method MOD_SEL is configured as GFSK modulation;

[0247] For BLE 2M mode: RATE_SEL=2M;

[0248] For BLE encoding mode: RATE_SEL=Coded-125k or Coded-500k.

[0249] 6. Whitening module configuration

[0250] BLE uses a data whitening function, and the corresponding whitening seed is 0x00;

[0251] Therefore, WHITEN_EN=1 and WHITEN_SEED=0x00 can be configured.

[0252] Once the above configuration is completed, the chip can work normally in BLE mode, realizing all BLE functions such as broadcasting, scanning, connecting, and data transmission and reception.

[0253] Second example scenario: Achieving Zigbee protocol adaptation through module configuration

[0254] This example scenario illustrates the flexibility of this disclosure by demonstrating how the Zigbee protocol can be implemented on the same chip by reconfiguring the parameters of each module.

[0255] 1. Timing control module configuration

[0256] Zigbee uses the CSMA-CA mechanism, with software controlling backoff and retransmission, and hardware providing timing references and CCA (Channel Clearance) support.

[0257] 2. Security processing module configuration

[0258] Zigbee uses AES-128 encryption and shares the same encryption engine as BLE, differing only in key and mode configuration, which can be customized through registers.

[0259] 3. Verification Processing Module Configuration

[0260] Zigbee uses a 16-bit CRC (IEEE 802.15.4 standard), with an initial value of 0x0000 (2 bytes in length).

[0261] Therefore, the checksum length CRC_LEN=2 can be configured, the initial value CRC_INIT=0x0000, and the polynomial CRC_POLY can be configured to the corresponding polynomial, for example, 0x1021.

[0262] 4. Packet Processing Module Configuration

[0263] Zigbee data packets: Preamble length PREAMBLE_LEN = 4 bytes, and the synchronization word length can be configured to 4 bytes (starting with 0xA7).

[0264] The header contains frame control fields, sequence numbers, address information, etc.

[0265] The payload length is variable (e.g., 0 to 255 bytes), for example, PAYLOAD_LEN can be set to the maximum value of 255.

[0266] 5. Physical Layer Transmission Control Module Configuration

[0267] Zigbee has a fixed transmission rate of 250kbps and uses Offset Quadrature Phase Shift Keying (O-QPSK) modulation.

[0268] 6. Whitening module configuration

[0269] Zigbee does not use whitening, so you can configure WHITEN_EN=0.

[0270] By switching the configuration as described above, the same chip can be switched from BLE mode to Zigbee mode, and all basic hardware modules can be reused.

[0271] Third example scenario: Achieving rapid adaptation of private protocols through module configuration

[0272] This example scenario illustrates the rapid development advantages of this disclosure, using the example of a terminal manufacturer needing to implement a proprietary 2.4G protocol.

[0273] Suppose a manufacturer needs to implement a custom 2.4G proprietary protocol with the following data packet format: 4-byte preamble + 3-byte synchronization word + 1-byte length field + variable-length payload + 2-byte CRC.

[0274] In traditional solutions, manufacturers need to develop the entire codebase, including RF drivers, baseband processing, and protocol stacks, from scratch. In this disclosure, manufacturers only need to:

[0275] Configure the packet processing module: Preamble length PREAMBLE_LEN=4, Synchronization word length SYNC_LEN=3, SYNC_VAL=custom synchronization word, Header length HEADER_LEN=1 (length field), Checksum length CRC_LEN=2;

[0276] Configure the verification processing module: CRC_INIT = custom initial value, CRC_POLY = custom polynomial;

[0277] Configure the physical layer transmission control module: RATE_SEL, select 1M or 2M as needed;

[0278] Configure the whitening module: Enable or disable whitening as needed;

[0279] Develop upper-layer protocol stack software: Implement the application layer logic of the private protocol on top of the unified transmit and receive interface provided by the hardware.

[0280] The multi-protocol adaptation architecture provided in this disclosure may have at least one of the following advantages:

[0281] One chip for multiple uses, reducing hardware costs: The same chip can support multiple protocols such as BLE, Zigbee, Thread, Matter, StarFlash, Aliro, and proprietary 2.4G through software configuration, and terminal manufacturers only need to stock one chip model.

[0282] New protocols can be supported through software upgrades: With the continuous emergence of new protocols in the 2.4G band, chips using this open architecture can support new protocols through software upgrades without the need for re-tape-out, significantly shortening the product launch cycle.

[0283] Protocol evolution can be seamlessly followed: As various protocol standards continue to evolve (such as BLE from 5.0 to 5.4), chips using this open architecture can support the features of new version protocols through firmware upgrades, protecting the hardware investment of terminal manufacturers.

[0284] High-efficiency reuse of hardware resources: All protocols share the same set of basic hardware modules (timed transmission and reception, encryption, CRC, data packet assembly, PHY, whitening, etc.), avoiding the need to design separate hardware logic for each protocol, and significantly reducing chip area and power consumption.

[0285] Significantly lowers the development threshold: Provides a unified and concise hardware abstraction interface and register configuration interface, allowing software developers to quickly implement new protocol support without having to deeply understand the details of RF hardware.

[0286] Simplified supply chain management: Terminal manufacturers only need to manage the inventory of one chip model, and can meet the needs of different customers by burning different protocol stack firmware, which significantly reduces the complexity of the supply chain.

[0287] Next, Figure 3 A schematic diagram of a method 300 for adapting multiple communication protocols according to an embodiment of the present disclosure is shown.

[0288] like Figure 3 As shown, method 300 may include: in step S301, obtaining protocol feature information corresponding to the currently adapted target communication protocol; in step S302, based on the protocol feature information, writing configuration parameters to one or more configuration register groups corresponding to one or more hardware general function modules, wherein the configuration parameters correspond to the protocol feature information.

[0289] In some implementations, the one or more general-purpose hardware modules operate based on configuration parameters in their respective configuration register sets.

[0290] In some implementations, the protocol feature information includes information related to at least one of the following: timing control, security algorithm, data verification, packet processing, physical layer transmission, and data preprocessing of the target communication protocol.

[0291] Method 300 can be applied to apparatus 100 and its variations as described above according to embodiments of this disclosure.

[0292] In addition, method 300 may also include any other methods or steps as described above, without limitation by this disclosure.

[0293] Embodiments of this disclosure also provide a computer-readable medium having instructions stored thereon that, when executed, can be used to implement any method according to embodiments of this disclosure.

[0294] It should be understood that the methods described above in conjunction with various embodiments or accompanying drawings are merely examples. Embodiments of this disclosure may also allow for any additions, deletions, substitutions, or combinations of steps or elements in the methods shown above. The steps in the methods of the embodiments of this disclosure may be performed in parallel or in any other order not shown, and this document does not impose any limitations.

[0295] Although this disclosure has been described with reference to exemplary embodiments, various changes and modifications may be suggested to those skilled in the art. This disclosure is intended to cover such changes and modifications that fall within the scope of the appended claims.

[0296] Nothing described in this disclosure should be construed as implying that any particular element, step, or function is an essential element that must be included within the scope of the claims. The scope of the patent subject matter is defined only by the claims.

[0297] Exemplary embodiments according to this disclosure have been disclosed herein, and although specific terminology has been used, it is used and interpreted in a general and descriptive sense only and not for limiting purposes. In some instances, features, characteristics, and / or elements described in connection with particular embodiments may be used alone or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise stated. Therefore, those skilled in the art will understand that various changes in form and detail may be made to this disclosure without departing from the spirit and scope of the claims.

Claims

1. A device for adapting to multiple communication protocols, comprising: The data transceiver module is configured to send and / or receive data; One or more general-purpose hardware modules are connected to the data transceiver module, wherein each of the one or more general-purpose hardware modules includes a corresponding configuration register group, wherein each configuration register group is configured to store configuration parameters, and wherein each general-purpose hardware module operates based on the configuration parameters in the corresponding configuration register group; and The control unit, connected to the one or more general-purpose hardware modules, is configured to write configuration parameters to the corresponding configuration register group based on protocol feature information corresponding to the currently adapted target communication protocol. The protocol feature information includes information related to at least one of the following: timing control, security algorithm, data verification, data packet processing, physical layer transmission, and data preprocessing of the target communication protocol.

2. The apparatus according to claim 1, wherein, The one or more general-purpose hardware modules include at least one of the following: The timing control module is configured to control the working timing and data transmission / reception mode of the data transceiver module based on the configuration parameters in the corresponding configuration register group; The security processing module is configured to perform at least one of encryption, decryption, or hash operations on the data based on configuration parameters in the corresponding configuration register group; The verification processing module is configured to perform cyclic redundancy check on the data based on the configuration parameters in the corresponding configuration register group; The data packet processing module is configured to perform hardware-level assembly or parsing of the data packets based on the configuration parameters in the corresponding configuration register group; The physical layer transmission control module is configured to control the physical layer transmission of the data based on the configuration parameters in the corresponding configuration register group; The data preprocessing module is configured to perform whitening or dewhitening processing on the data based on the configuration parameters in the corresponding configuration register group.

3. The apparatus according to claim 2, wherein, The configuration register group of the timing control module includes at least one of the following: The data transceiver mode configuration register is configured to store configuration parameters related to the data transceiver mode of the data transceiver module, wherein the data transceiver mode includes at least one of the following: transmit mode, receive mode, idle mode, continuous transmit mode, or continuous receive mode. The timed transmission start time configuration register is configured to store configuration parameters related to the start time of the timed transmission; The timed receive start time configuration register is configured to store configuration parameters related to the start time of timed receive; The receive timeout threshold configuration register is configured to store configuration parameters related to the time threshold used to determine whether data reception has timed out; The transmit frame interval configuration register is configured to store configuration parameters related to the frame interval used to transmit the data.

4. The apparatus according to claim 2, wherein, The configuration register group of the security processing module includes at least one of the following: The algorithm configuration register is configured to store configuration parameters related to the type of encryption and / or decryption algorithm selected; The key length configuration register is configured to store configuration parameters related to the key length. The operating mode configuration register is configured to store configuration parameters related to the operating mode of the encryption and / or decryption algorithm, wherein the operating mode includes at least one of Electronic Codebook (ECB) mode, Cipher Block Linking (CBC) mode, and Counter (CTR) mode.

5. The apparatus according to claim 2, wherein, The configuration register group of the verification processing module includes at least one of the following: The initial value configuration register is configured to store configuration parameters related to the initial value used for cyclic redundancy check; The polynomial configuration register is configured to store configuration parameters related to the polynomial used for cyclic redundancy check; The check code length configuration register is configured to store configuration parameters related to the length of the cyclic redundancy check code. A byte order mode configuration register is configured to store information related to the byte order mode of the cyclic redundancy check result, wherein the byte order mode includes at least one of big-endian or little-endian. The Input Data Inversion Enable Register is configured to store configuration parameters related to whether the inversion function of the input data for Cyclic Redundancy Check is enabled. The Output Inversion Enable Register is configured to store configuration parameters related to whether the inversion function of the output result of Cyclic Redundancy Check is enabled.

6. The apparatus according to claim 2, wherein, The configuration register group of the packet processing module includes at least one of the following: The preamble length configuration register is configured to store configuration parameters related to the length of the preamble in a data packet. The preamble content configuration register is configured to store configuration parameters related to the content of the preamble of the data packet. The synchronization word length configuration register is configured to store configuration parameters related to the length of the synchronization word in the data packet; The synchronization word content configuration register is configured to store configuration parameters related to the content of the synchronization word in the data packet; The header length configuration register is configured to store configuration parameters related to the length of the packet header; The payload length configuration register is configured to store configuration parameters related to the length of the packet's payload. The packet format configuration register is configured to store configuration parameters related to the packet format; The address matching enable configuration register is configured to store configuration parameters related to whether the address matching function for data packets is enabled.

7. The apparatus according to claim 2, wherein, The configuration register group of the physical layer transmission control module includes at least one of the following: The transmission rate configuration register is configured to store configuration parameters related to the transmission rate used for physical layer transmission; The modulation scheme configuration register is configured to store configuration parameters related to the modulation scheme used for physical layer transmission; The frequency offset configuration register is configured to store configuration parameters related to the frequency offset used for physical layer transmission; The transmit power configuration register is configured to store configuration parameters related to the transmit power used for physical layer transmission; The channel selection configuration register is configured to store configuration parameters related to channel selection used for physical layer transmission.

8. The apparatus according to claim 2, wherein, The configuration register group of the data preprocessing module includes at least one of the following: The whitening enable configuration register is configured to store configuration parameters related to whether the whitening function is enabled. The whitening seed configuration register is configured to store configuration parameters related to the whitening seed used for the whitening function; The whitening polynomial configuration register is configured to store configuration parameters related to the whitening polynomial used for the whitening function.

9. The apparatus according to claim 1, wherein, The target communication protocol includes at least one of the following: Bluetooth protocol, Bluetooth Low Energy (BLE) protocol, Zigbee protocol, Thread protocol, Matter protocol, SparkLink protocol, Aliro protocol, proprietary 2.4G protocol.

10. The apparatus according to claim 1, wherein, The one or more general-purpose hardware modules do not have hardware wiring logic dedicated to any of the multiple communication protocols, and the configuration parameters are configured by the control unit via software.

11. A method for adapting multiple communication protocols, comprising: Obtain the protocol feature information corresponding to the target communication protocol currently being adapted; Based on the protocol feature information, configuration parameters are written to one or more configuration register groups, each corresponding to one or more general-purpose hardware modules, wherein the configuration parameters correspond to the protocol feature information. The one or more general-purpose hardware modules operate based on the configuration parameters in their respective configuration register groups. The protocol feature information includes information related to at least one of the following: timing control, security algorithm, data verification, data packet processing, physical layer transmission, and data preprocessing of the target communication protocol.

12. A computer-readable storage medium having stored thereon computer-readable instructions, which, when executed by a processor, are used to implement the method of claim 11.

Images