Bluetooth bridging module and communication method

Abstract

The embodiment of the invention provides a Bluetooth bridging module and a communication method thereof, the module is applied to an electric motorcycle controller, and the module comprises a Bluetooth communication unit which performs data interaction with a communication end according to a preset communication protocol; the multi-channel communication interface unit is connected with the electric motorcycle controller through the corresponding transmitting and receiving circuit; the handshake unit is used for sequentially sending handshake request frames on multiple paths of communication interfaces, traversing candidate baud rates, determining effective communication interface units and baud rates according to handshake response frames, and locking the effective communication interface units and baud rates as current communication configuration; and the protocol conversion unit performs bidirectional conversion on the preset communication protocol frame and the controller side protocol frame. Through the mode, the communication interface type and the baud rate of the electric motorcycle controller can be adaptively recognized, various controller side communication protocols are uniformly converted into the Bluetooth side preset communication protocol, the bridging function of multi-protocol normalization is achieved, user operation complexity is reduced, and parameter adjusting and upgrading efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of communication control, and more particularly to a Bluetooth bridging module and communication method. Background Technology

[0002] With the continuous improvement of the intelligence level of electric motorcycles, parameter tuning and upgrade technology has become an important means of electric motorcycle maintenance and performance optimization. Currently, parameter tuning and upgrades of electric motorcycle controllers usually require the use of special tools to establish a communication connection with the controller, thereby completing operations such as parameter reading and writing and firmware updates.

[0003] However, the communication methods used by electric motorcycle controllers of different brands and models vary significantly. Common communication interfaces include CAN, UART, and RS485. Furthermore, even with the same communication method, different controllers support different baud rates. This diversity in communication methods and baud rates directly leads to the fragmentation of parameter tuning and upgrade tools—each communication method often requires a dedicated tuning tool, such as a CAN analyzer or serial port debugger, with each tool having a different user interface and usage process.

[0004] The most significant problem arising from this situation is that users need to frequently switch between multiple tools and manually match communication methods and baud rates when adjusting and upgrading the parameters of different electric motorcycle controllers. This not only significantly increases operational complexity and the probability of errors, but also requires after-sales maintenance personnel to master the use of multiple tools simultaneously, significantly restricting maintenance efficiency. Summary of the Invention

[0005] This application aims to solve the problem of complex operation and low maintenance efficiency caused by the need to frequently switch between various special tools and manually match communication parameters during the parameter adjustment and upgrade process of existing electric motorcycle controllers due to the diversity of communication methods and baud rates.

[0006] In a first aspect, this application provides a Bluetooth bridging module applied to an electric motorcycle controller, comprising: a Bluetooth communication unit, which establishes a wireless connection with a communication terminal and is configured to perform data interaction with the communication terminal according to a preset communication protocol; a multi-channel communication interface unit, which is connected to the electric motorcycle controller through corresponding transceiver circuits; a handshake unit, configured to sequentially send handshake request frames on the multi-channel wired communication interfaces, and traverse multiple candidate baud rates on each interface, determine the valid communication interface unit and communication baud rate based on the handshake response frame returned by the electric motorcycle controller, and lock it as the current communication configuration; a protocol conversion unit, configured to convert the preset communication protocol frame received by the Bluetooth communication unit into a controller-side protocol frame corresponding to the current communication configuration, and to convert the controller-side protocol frame returned by the electric motorcycle controller into a preset communication protocol frame; the locked communication interface unit is used to send the controller-side protocol frame converted by the protocol conversion unit to the electric motorcycle controller; and the Bluetooth communication unit is used to send the preset communication protocol frame converted by the protocol conversion unit back to the communication terminal.

[0007] Optionally, the Bluetooth bridging module further includes a parameter caching unit, configured to read parameter data of the electric motorcycle controller through a locked communication interface unit at preset intervals after a successful handshake and cache it in local memory; when the communication terminal requests to read parameters, the cached parameter data is returned to the communication terminal.

[0008] Optionally, the Bluetooth bridging module further includes: a storage unit configured to temporarily store firmware data to be upgraded received via the Bluetooth communication unit; and an offline upgrade unit configured to read the firmware data to be upgraded from the storage unit in response to a physical trigger signal, and write the firmware data into the electric motorcycle controller via the protocol conversion unit and the locked communication interface unit.

[0009] Optionally, before temporarily storing firmware data, the storage unit first receives firmware information via the Bluetooth communication unit; wherein, the firmware information includes firmware checksum, firmware platform code, and firmware project code; the offline upgrade unit determines the upgrade target as the electric motorcycle controller or the Bluetooth bridging module itself based on the firmware platform code and firmware project code.

[0010] Optionally, the Bluetooth communication unit receives the firmware data to be upgraded in a packet-by-packet manner. After each packet is written to the storage unit, the Bluetooth communication unit replies with an acknowledgment message to the communication terminal. After all packets are received, the temporarily stored complete firmware data is verified and compared with the firmware verification value to confirm data integrity. The storage unit records the offset position of the successfully received data. When the transmission is terminated due to communication interruption and reconnected, the Bluetooth communication unit continues to receive firmware data from the data offset position.

[0011] Optionally, when the upgrade target is the Bluetooth bridging module itself, the offline upgrade unit sets the upgrade flag and triggers a reset after the firmware temporary storage is completed and the verification is passed. After the reset, the bootloader of the Bluetooth bridging module reads the firmware data from the non-volatile storage unit and writes it into the application storage area to complete its own firmware upgrade.

[0012] Optionally, when the offline upgrade unit performs firmware writing, it first sends a bootloader entry command to the electric motorcycle controller. After the electric motorcycle controller enters the bootloader mode, it sends firmware data in packets, with each packet waiting for write confirmation. The offline upgrade unit records the position of successfully sent data packets. If the upgrade process is interrupted, it will continue sending from the interrupted position when it is triggered again. If the firmware verification of the electric motorcycle controller fails, it will remain in the bootloader mode and wait for a re-upgrade.

[0013] Secondly, this application also provides a communication method applied to a Bluetooth bridging module including a multi-channel communication interface, a Bluetooth unit, and a memory, comprising the following steps: sequentially sending handshake request frames at multiple candidate baud rates on the multi-channel communication interface; determining the valid communication interface and communication baud rate based on the handshake response frame returned by the electric motorcycle controller, and locking it as the current communication configuration; receiving instruction frames sent by the communication terminal using a preset communication protocol through the Bluetooth unit; converting the instruction frames into controller-side protocol frames corresponding to the current communication configuration and sending them to the electric motorcycle controller; and converting the response data of the electric motorcycle controller into preset communication protocol frames and sending them back to the communication terminal; receiving firmware information and firmware data to be upgraded sent by the communication terminal through the Bluetooth unit; determining the upgrade target based on the firmware platform code and firmware project code in the firmware information; writing the firmware data into the memory in packets; performing integrity verification on the temporarily stored firmware data after receiving; and writing the temporarily stored firmware data into the electric motorcycle controller through the locked communication interface in response to a physical trigger signal.

[0014] Optionally, the step of sequentially sending handshake request frames at multiple candidate baud rates on the multiple communication interfaces, determining the valid communication interface and communication baud rate based on the handshake response frame returned by the electric motorcycle controller, and locking it as the current communication configuration includes: for each candidate baud rate of each communication interface, sending a handshake request frame and waiting for a preset time; if a valid handshake response frame is received within the preset time, locking the current communication configuration and stopping scanning; if no valid handshake response frame is received within the preset time, switching to the next candidate baud rate or the next communication interface to continue scanning.

[0015] Optionally, the step of writing the firmware data temporarily stored in the memory to the electric motorcycle controller in response to a physical trigger signal through a locked communication interface includes: sending a bootloader entry command to the electric motorcycle controller; after the electric motorcycle controller enters the bootloader mode, sending firmware data in packets and waiting for write confirmation for each packet; recording the position of successfully sent data packets to support resume transmission after interruption; when the upgrade target is the Bluetooth bridging module itself, after the firmware is temporarily stored and verified, setting the upgrade flag and performing a reset, and the bootloader of the Bluetooth bridging module completes its own firmware update.

[0016] At least one advantage of the Bluetooth bridging module and its communication method provided in this application is that it can adaptively identify the communication interface type and baud rate of the electric motorcycle controller, unify the communication protocols of multiple controllers into the preset communication protocol of the Bluetooth side, realize the bridging function of multiple protocols, reduce the complexity of user operation, and improve the efficiency of parameter adjustment and upgrade. Attached Figure Description

[0017] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0018] Figure 1 A schematic diagram of the structure of a Bluetooth bridging module provided for an embodiment of the present invention; Figure 2 A schematic diagram of another Bluetooth bridging module provided in an embodiment of the present invention; Figure 3 A schematic diagram of the structure of another Bluetooth bridging module provided for an embodiment of the present invention; Figure 4 This is a flowchart illustrating a communication method provided for an embodiment of the present invention. Detailed Implementation

[0019] To facilitate understanding of this application, a more detailed description is provided below with reference to the accompanying drawings and specific embodiments. It should be noted that when an element is described as being "fixed to" another element, it can be directly on the other element, or one or more intermediate elements may exist between them. When an element is described as being "connected" to another element, it can be directly connected to the other element, or one or more intermediate elements may exist between them. The terms "upper," "lower," "inner," "outer," "bottom," etc., used in this specification indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. Furthermore, the terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0020] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0021] Furthermore, the technical features involved in the different embodiments of this application described below can be combined with each other as long as they do not conflict with each other.

[0022] Please see Figure 1 , Figure 1 This is a schematic diagram of a Bluetooth bridging module provided for an embodiment of the present invention. Figure 1 As shown, this embodiment provides a Bluetooth bridging module 10, which is applied to an electric motorcycle controller 30.

[0023] The so-called Bluetooth bridging module refers to an intermediate bridging layer between the communication terminal 20 and the electric motorcycle controller 30. It communicates with the communication terminal 20 via Bluetooth uplink and with the electric motorcycle controller 30 via a wired communication interface downlink, realizing bidirectional conversion between different communication protocols.

[0024] The term "communication terminal" refers to a terminal device that establishes a Bluetooth wireless connection with the Bluetooth bridging module 10 and sends operation commands to it, such as a smartphone, tablet, or other mobile terminal running a parameter tuning and upgrade application (APP) or WeChat mini-program.

[0025] The so-called electric motorcycle controller refers to the core electronic control unit in an electric motorcycle that is responsible for the motor drive control. It stores readable and writable operating parameters and upgradeable firmware programs.

[0026] The Bluetooth bridging module 10 includes a Bluetooth communication unit 100, a handshake unit 200, a protocol conversion unit 300, and a multi-channel communication interface unit. In this embodiment, the multi-channel communication interface unit includes communication interface units 410, 420 to 4N0, which are connected to the communication bus of the electric motorcycle controller 30 through corresponding transceiver circuits 41, 42 to 4N, respectively. Here, N is a positive integer greater than 1, representing the number of communication interfaces.

[0027] The Bluetooth communication unit 100 establishes a wireless connection with the communication terminal 20 and is configured to interact with the communication terminal 20 according to a preset communication protocol.

[0028] The so-called preset communication protocol refers to the unified data frame format and command specifications agreed upon in advance between the Bluetooth bridging module 10 and the communication terminal 20. This protocol is independent of the communication protocol on the electric motorcycle controller 30 side, so that the communication terminal 20 does not need to care about the specific communication method on the controller side.

[0029] Specifically, the Bluetooth communication unit 100 adopts Bluetooth Low Energy (BLE) technology and defines a custom GATTService, which includes a transmit characteristic (TX Characteristic) and a receive characteristic (RX Characteristic). The transmit characteristic has a Notify attribute, which is used for data reporting from the Bluetooth bridging module 10 to the communication terminal 20; the receive characteristic has a Write attribute, which is used for issuing instructions from the communication terminal 20 to the Bluetooth bridging module 10.

[0030] The preset communication protocol frame format between Bluetooth communication unit 100 and communication terminal 20 is defined as follows:

[0031] Table 1 The frame header is a fixed two-byte identifier used to identify the start of a data frame; the command code identifies the function type of the frame, such as parameter read request, parameter write request, firmware data transmission, etc.; the sequence number increments with each request, and the response frame carries the same sequence number for matching requests and responses and matching timeout retransmissions; the data length is the number of bytes in the data field; the data field carries the specific business data; the check field uses the CRC16 algorithm to perform check calculations on all bytes from the frame header to the data field.

[0032] After the Bluetooth communication unit 100 establishes a connection with the communication terminal 20, they negotiate the transmission unit size through MTU (Maximum Transmission Unit). When a single frame of data exceeds the MTU payload, the Bluetooth communication unit 100 transmits the data in fragments according to the MTU size, and the communication terminal 20 reassembles the data based on the frame header and data length fields, thereby achieving reliable transmission of large amounts of data.

[0033] The multi-channel communication interface unit includes communication interface unit 410, communication interface unit 420 to communication interface unit 4N0, which are connected to the electric motorcycle controller 30 through corresponding transceiver circuits 41, 42 to 4N, respectively. Each communication interface unit corresponds to a communication mode, and the communication interface units are independent of each other and can be in the initialization state at the same time.

[0034] The so-called transceiver circuit refers to the circuit that converts the digital signals output by the communication interface unit into the electrical signals required by the communication bus of the electric motorcycle controller 30. Its specific form depends on the communication method adopted by the corresponding communication interface unit.

[0035] Taking a three-way communication interface as an example (i.e., N=3), the communication interface unit 410 is a CAN interface, and the corresponding transceiver circuit 41 includes an SPI to CAN controller (e.g., MCP2515) and a CAN transceiver (e.g., TJA1050), which outputs standard CAN_H / CAN_L differential signals; the communication interface unit 420 is a UART interface, and the corresponding transceiver circuit 42 is a level matching circuit. When the electric motorcycle controller 30 is at a 3.3V level, it can be directly connected, and when it is at a 5V level, it is matched through a level conversion chip; the communication interface unit 4N0 (i.e., 430) is an RS485 interface, and the corresponding transceiver circuit 4N (i.e., 43) includes an RS485 transceiver (e.g., MAX485), whose transmission and reception direction is controlled by the general-purpose input / output port of the main control chip of the Bluetooth bridge module 10, and outputs standard RS485 differential signals A / B.

[0036] It should be noted that the specific types of the three communication interfaces mentioned above are only illustrative examples. In practical applications, the number and type of multi-channel communication interface units can be increased, decreased, and adjusted according to the communication method of the electric motorcycle controller that needs to be adapted.

[0037] The handshake unit 200 is configured to send handshake request frames sequentially on multiple communication interfaces, traverse multiple candidate baud rates on each interface, determine the valid communication interface unit and communication baud rate based on the handshake response frame returned by the electric motorcycle controller 30, and lock it as the current communication configuration.

[0038] The current communication configuration refers to the combination of communication interface units and baud rates that are ultimately determined by the handshake unit 200 through the handshake process, used for subsequent communication between the Bluetooth bridging module 10 and the electric motorcycle controller 30. Once locked, subsequent protocol conversions and data transmission and reception are all performed through this communication configuration.

[0039] The specific workflow of the handshake unit 200 is as follows: Step S1: After the Bluetooth bridging module 10 is powered on, the handshake unit 200 initializes all communication interface units and configures each interface unit to the preset default baud rate. Continuing with the above three communication interfaces as an example, the default baud rate of the CAN interface is 250Kbps, and the default baud rates of the UART and RS485 interfaces are 115200bps.

[0040] Step S2: The handshake unit 200 selects a communication interface unit according to a preset order and sends a handshake request frame on that interface. Continuing with the above three communication interfaces as an example, the preset scanning order is communication interface unit 410 (CAN interface), communication interface unit 420 (UART interface), and communication interface unit 430 (RS485 interface). The format definition of the handshake request frame is as follows:

[0041] Table 2 Function code 0x01 indicates a handshake request, and the data field contains the unique identifier ID of the Bluetooth bridging module 10.

[0042] Step S3: After sending a handshake request frame, the handshake unit 200 waits for a preset timeout period. This preset timeout period is, for example, 200ms. If a correctly formatted handshake response frame is received from the electric motorcycle controller 30 within the preset timeout period, proceed to step S5; otherwise, if no valid response is received within the timeout period, proceed to step S4.

[0043] The format of the handshake response frame is defined as follows:

[0044] Table 3 Function code 0x81 is the result of the OR operation between handshake request function code 0x01 and 0x80, indicating a handshake response. The data field contains the identifier ID of the electric motorcycle controller 30, the version number of the controller-side communication protocol, and the bitmap of functions supported by the controller (such as whether parameter reading and writing is supported, whether firmware upgrades are supported, etc.).

[0045] Step S4: The handshake unit 200 determines whether there are any untried candidate baud rates for the current communication interface unit. If so, it switches the current communication interface unit to the next candidate baud rate and returns to step S2 to resend the handshake request frame. If all candidate baud rates for the current interface have been tried and no valid response has been received, the handshake unit 200 determines whether there are any unscanned communication interface units. If so, it switches to the next communication interface unit and starts from the default baud rate of that interface, returning to step S2. If all candidate baud rates for all interfaces have been scanned and no valid response has been received, the handshake fails, and the Bluetooth bridging module 10 enters standby mode.

[0046] Taking the three communication interfaces mentioned above as examples, the candidate baud rates for each interface are as follows: The candidate baud rates for the CAN interface include 125Kbps, 250Kbps, 500Kbps, and 1Mbps; the candidate baud rates for the UART and RS485 interfaces include 9600bps, 19200bps, 38400bps, 57600bps, 115200bps, 230400bps, and 460800bps.

[0047] Step S5: The handshake unit 200 receives a valid handshake response frame, determines that the communication interface unit that returned the response frame is a valid communication interface unit, determines that the currently used baud rate is a valid communication baud rate, locks the combination of the communication interface unit and the communication baud rate as the current communication configuration, and stops scanning other interfaces and baud rates.

[0048] In a preferred embodiment, after locking the current communication configuration, the handshake unit 200 saves the determined communication interface unit identifier and communication baud rate to the non-volatile memory of the Bluetooth bridging module 10. When the Bluetooth bridging module 10 powers on again, the handshake unit 200 prioritizes using the saved communication configuration to make a handshake request. If the handshake is successful, it locks the connection directly without needing to perform a full scan again, thereby accelerating the connection process. If the handshake fails with the saved configuration, the handshake unit 200 re-enters the full scan process that started in step S1 above.

[0049] To illustrate with a specific handshake process: Assume the electric motorcycle controller 30 uses UART communication with a baud rate of 57600bps. After the Bluetooth bridging module 10 is powered on, the handshake unit 200 first sends a handshake request frame at the default baud rate of 250Kbps on the communication interface unit 410 (CAN interface), and receives no response after 200ms. Subsequently, it sends handshake request frames at 125Kbps, 500Kbps, and 1Mbps, all without receiving a response. The handshake unit 200 switches to the communication interface unit 420 (UART interface) and sends a handshake request frame at the default baud rate of 115200bps, but receives no response. It then switches to 9600bps, 19200bps, and 38400bps, all without receiving a response. After switching to 57600bps, it receives a valid handshake response frame from the electric motorcycle controller 30 within 200ms. The handshake unit 200 then locks the communication interface unit 420 (UART interface) and baud rate 57600bps to the current communication configuration, stops scanning, and the Bluetooth bridging module 10 enters normal working mode.

[0050] Through the aforementioned adaptive handshake mechanism, users do not need to manually select the communication method and baud rate. The Bluetooth bridging module 10 can automatically identify and adapt the communication parameters of the electric motorcycle controller 30, thereby solving the problem of complex operation and high error rate caused by manually matching communication parameters as described in the background art.

[0051] The protocol conversion unit 300 is configured to convert the preset communication protocol frame received by the Bluetooth communication unit 100 into a controller-side protocol frame corresponding to the current communication configuration, and to convert the controller-side protocol frame returned by the electric motorcycle controller 30 into a preset communication protocol frame.

[0052] The so-called controller-side protocol frame refers to the data frame format of the communication protocol used by the electric motorcycle controller 30. Its specific format depends on the controller's communication method. The controller-side protocol frame formats of different communication methods may be different, and the function of the protocol conversion unit 300 is to shield these differences, so that the communication terminal 20 can interact with the electric motorcycle controller 30 of any communication method by using only a unified preset communication protocol.

[0053] The protocol conversion unit 300 maintains a protocol mapping table, which records the correspondence between the command codes in the preset communication protocol and the function codes of the controller-side protocol under each communication mode, as well as the field mapping rules between the frame formats on both sides.

[0054] Taking UART / RS485 communication as an example, the protocol frame format on the controller side is as follows:

[0055] Table 4 Taking CAN communication as an example, the controller-side protocol frame adopts the standard CAN frame format. In the 11-bit encoding of its arbitration field ID, the high 3 bits represent the priority, the middle 4 bits represent the function code, and the low 4 bits represent the device address; the data field contains 0 to 8 bytes of parameter data.

[0056] The following example, "reading controller parameters," illustrates the bidirectional conversion process of the protocol conversion unit 300: Uplink direction (electric motorcycle controller 30 → communication terminal 20): The electric motorcycle controller 30 returns a response frame containing parameter values ​​via the UART interface: AA [ADDR] 83 04 [Parameter ID 2 bytes][Parameter value 2 bytes] [CRC8]55, where function code 0x83 is a read parameter response. The locked communication interface unit 420 receives this frame and passes it to the protocol conversion unit 300. The protocol conversion unit 300 parses the controller-side function code 0x83, looks up the corresponding preset communication protocol command code 0x81 (read parameter response) in the protocol mapping table, extracts the parameter ID and parameter value from the data field, and re-encapsulates it into a preset communication protocol frame: 5A A5 81 [SEQ] 00 04 [Parameter ID 2 bytes][Parameter value 2 bytes] [CRC16]. The Bluetooth communication unit 100 transmits this frame back to the communication terminal 20 via the BLE transmission characteristic value using the Notify method.

[0057] Assuming the current communication configuration is a CAN interface, the above read parameter request will be converted into a CAN frame by the protocol conversion unit 300: the arbitration field ID is encoded as 0x030 | ADDR (the middle 4 bits are the function code 0x03, and the lower 4 bits are the device address), and the data field is [parameter ID 2 bytes]. The reverse conversion process is similar to the UART example above and will not be repeated here.

[0058] Through the bidirectional conversion mechanism of the protocol conversion unit 300, the communication terminal 20 always interacts with the Bluetooth bridging module 10 using a unified preset communication protocol. The Bluetooth bridging module 10 automatically completes the protocol format adaptation and conversion according to the current communication configuration, thereby realizing the bridging function of multiple protocols unifying. This eliminates the need for the application on the communication terminal 20 to develop multiple sets of communication logic for electric motorcycle controllers with different communication methods, reducing the complexity of software development and maintenance. It also solves the problem mentioned in the background art where users need to frequently switch between multiple tools due to tool fragmentation.

[0059] Please see Figure 2 , Figure 2 This is a schematic diagram of another Bluetooth bridging module provided for an embodiment of the present invention.

[0060] like Figure 2As shown, this embodiment further adds a parameter buffer unit 500 to the Bluetooth bridging module 10 described in the previous embodiments. That is, the Bluetooth bridging module 10 in this embodiment includes a Bluetooth communication unit 100, a handshake unit 200, a protocol conversion unit 300, a multiplex communication interface unit (communication interface unit 410, communication interface unit 420 to communication interface unit 4N0), and a parameter buffer unit 500. The structure and function of the Bluetooth communication unit 100, handshake unit 200, protocol conversion unit 300, and multiplex communication interface unit are as described in the previous embodiments and will not be repeated here.

[0061] The parameter caching unit 500 is configured to read the parameter data of the electric motorcycle controller 30 through the locked communication interface unit at a preset period after a successful handshake and cache it in the local memory; when the communication terminal 20 requests to read the parameters, it returns the cached parameter data to the communication terminal 20.

[0062] The so-called parameter cache refers to a copy of the parameters that the parameter cache unit 500 stores in the local memory (such as the RAM of the main control chip) of the Bluetooth bridging module 10, which stores the parameter data read from the electric motorcycle controller 30. When the communication terminal 20 reads parameters, it directly obtains them from this copy without having to query the electric motorcycle controller 30 in real time each time.

[0063] The parameter caching unit 500 internally maintains a parameter cache table, which stores the current value and data type of each parameter, indexed by the parameter ID. The specific workflow of the parameter caching unit 500 is as follows: Step S21: As described in the previous embodiment, after the handshake unit 200 completes the handshake and locks the current communication configuration, the parameter caching unit 500 automatically starts the parameter synchronization task.

[0064] Step S22: The parameter caching unit 500 sends a parameter reading command to the electric motorcycle controller 30 through the protocol conversion unit 300 and the locked communication interface unit according to a preset period (e.g., 500ms), and reads the current value of each parameter item in the electric motorcycle controller 30 in sequence.

[0065] Specifically, the parameter caching unit 500 generates a read parameter request in a preset communication protocol format. This request is converted into a controller-side protocol frame by the protocol conversion unit 300 and then sent to the electric motorcycle controller 30 through the locked communication interface unit. The parameter response frame returned by the electric motorcycle controller 30 is received by the locked communication interface unit, converted back into a preset communication protocol frame by the protocol conversion unit 300, and then passed to the parameter caching unit 500. The specific process of protocol conversion is as described in the aforementioned embodiments.

[0066] Step S23: The parameter caching unit 500 parses the received parameter data and writes it into the parameter cache table using the parameter ID as an index, completing one round of parameter synchronization. Thereafter, the parameter caching unit 500 repeats steps S22 and S23 according to a preset cycle, continuously keeping the data in the parameter cache table synchronized with the actual parameters of the electric motorcycle controller 30.

[0067] To illustrate with a specific example: Assume the electric motorcycle controller 30 has 20 readable parameters, with parameter IDs ranging from 0x0001 to 0x0014. In the first cycle after a successful handshake, the parameter cache unit 500 sequentially sends read requests for parameter IDs 0x0001 to 0x0014 to the electric motorcycle controller 30, writing the returned parameter values ​​one by one into the parameter cache table. Thereafter, the above read process is repeated every 500ms, ensuring that the data in the cache table remains consistent with the actual operating state of the electric motorcycle controller 30.

[0068] After the communication terminal 20 establishes a connection with the Bluetooth communication unit 100 via Bluetooth, the communication terminal 20 sends a preset communication protocol frame requesting a read parameter to the Bluetooth communication unit 100. Upon receiving the frame, the Bluetooth communication unit 100 passes it to the parameter cache unit 500. The parameter cache unit 500, based on the parameter ID in the request, directly retrieves the corresponding parameter value from the parameter cache table, encapsulates it into a preset communication protocol frame, and then sends it back to the communication terminal 20 via the Bluetooth communication unit 100.

[0069] Since the parameter caching unit 500 returns data directly from the local cache table, without needing to query the electric motorcycle controller 30 in real time through the protocol conversion unit 300, the parameter reading response latency of the communication terminal 20 is significantly reduced. In the above example, the time taken for the Bluetooth communication terminal 20 to receive a response for all 20 parameters from sending a request depends only on the transmission speed of Bluetooth communication, without waiting for multiple rounds of wired communication between the Bluetooth bridging module 10 and the electric motorcycle controller 30.

[0070] When the communication terminal 20 needs to modify the parameters of the electric motorcycle controller 30, it sends a preset communication protocol frame requesting a write parameter to the Bluetooth communication unit 100. This frame contains the target parameter ID and the parameter value to be written. After receiving the frame, the Bluetooth communication unit 100 passes it to the protocol conversion unit 300, which converts it into a controller-side protocol frame and sends it to the electric motorcycle controller 30 through the locked communication interface unit. The electric motorcycle controller 30 returns an acknowledgment after performing the parameter write. The parameter cache unit 500 rereads the parameter in the next synchronization cycle and updates the corresponding entry in the parameter cache table. The communication terminal 20 can then verify the success of the parameter write by comparing the read-back parameter value with the previously written target value during the next read operation.

[0071] In addition, the parameter writing process is also applicable to the issuance of special function commands such as motor self-learning, factory reset, and power-off data saving. These operations are similar to parameter writing in terms of process, in which the communication terminal 20 sends a preset communication protocol frame with the corresponding command code, which is then converted by the protocol conversion unit 300 and forwarded to the electric motorcycle controller 30. The difference is that the execution time of operations such as motor self-learning is relatively long (e.g., 5 to 30 seconds). During this period, the Bluetooth bridging module 10 sets a longer waiting timeout and can send a "running" status notification frame to the communication terminal 20 through the Bluetooth communication unit 100 at preset intervals (e.g., 1 second) until it receives a completion response from the electric motorcycle controller 30, and then sends the final result back to the communication terminal 20.

[0072] With the introduction of the parameter caching unit 500, the Bluetooth bridging module 10 has completed the local synchronization of parameters before the Bluetooth connection is established. After the communication terminal 20 is connected, it can obtain parameter data in real time, which improves the response speed of human-computer interaction and user experience.

[0073] Please see Figure 3 , Figure 3 This is a schematic diagram of another Bluetooth bridging module provided for an embodiment of the present invention.

[0074] like Figure 3 As shown, this embodiment, based on the Bluetooth bridging module 10 described in the previous embodiments, further adds a storage unit 600 and an offline upgrade unit 700. That is, the Bluetooth bridging module 10 in this embodiment includes a Bluetooth communication unit 100, a handshake unit 200, a protocol conversion unit 300, a multiplex communication interface unit (communication interface unit 410, communication interface unit 420 to communication interface unit 4N0), a parameter cache unit 500, a storage unit 600, and an offline upgrade unit 700. The structure and function of the Bluetooth communication unit 100, handshake unit 200, protocol conversion unit 300, multiplex communication interface unit, and parameter cache unit 500 are as described in the previous embodiments and will not be repeated here.

[0075] Storage unit 600 is configured to temporarily store firmware data to be upgraded received via Bluetooth communication unit 100. The storage unit refers to a non-volatile memory in Bluetooth bridging module 10 used for temporary storage of firmware data. Its characteristic is that data is not lost after power failure, thus supporting offline upgrades of firmware data at any time after temporary storage is completed. In one embodiment, storage unit 600 uses an external SPI NOR Flash chip (e.g., W25Q64, 8MB capacity), connected to the main control chip of Bluetooth bridging module 10 via an SPI interface.

[0076] The offline upgrade unit 700 is configured to read the firmware data to be upgraded from the storage unit 600 in response to a physical trigger signal, and write the firmware data to the electric motorcycle controller 30 through the protocol conversion unit 300 and the locked communication interface unit. The physical trigger signal refers to a trigger signal generated by a physical interaction element on the Bluetooth bridging module 10, such as a button signal generated by a user pressing a touch button on the module. The offline upgrade unit 700 initiates the upgrade process in response to this physical trigger signal; the entire upgrade process does not require the Bluetooth connection of the communication terminal 20.

[0077] The storage unit 600 and the offline upgrade unit 700 work together to complete the firmware upgrade function, which is divided into two stages: the firmware temporary storage stage and the offline upgrade stage. These will be explained in detail below.

[0078] The firmware temporary storage stage is completed under the Bluetooth connection between the communication terminal 20 and the Bluetooth communication unit 100. Its purpose is to transfer the firmware data to be upgraded from the communication terminal 20 to the storage unit 600 for temporary storage.

[0079] Specifically, the steps include the following: Step S31: Receive firmware information.

[0080] Before temporarily storing firmware data, the storage unit 600 first receives a firmware information frame sent by the communication terminal 20 via the Bluetooth communication unit 100. This firmware information frame uses a preset communication protocol format, and its data field includes the following fields:

[0081] Table 5 The firmware checksum is the CRC32 checksum obtained by performing a check on the complete firmware file. It is used to verify the integrity of the temporarily stored data after the firmware is temporarily stored. The firmware platform code is the encoding used to identify the target hardware platform to which the firmware is adapted. The firmware project code is the encoding used to identify the product project to which the firmware belongs. The firmware platform code and firmware project code together constitute the target identifier of the firmware.

[0082] Step S32: Determine the upgrade target.

[0083] The offline upgrade unit 700 determines the upgrade target based on the received firmware platform code and firmware project code. Specifically, the offline upgrade unit 700 compares the received firmware platform code and firmware project code with the platform code and project code pre-stored in the Bluetooth bridging module 10: if they match, the upgrade target is determined to be the Bluetooth bridging module 10 itself; if they do not match, the upgrade target is determined to be the electric motorcycle controller 30. The offline upgrade unit 700 marks and saves the determination result for use in subsequent upgrade stages.

[0084] To illustrate with a specific example: Assume the Bluetooth bridging module 10's platform code is 0x0100 and its project code is 0x0201. The firmware information sent by the communication terminal 20 contains a platform code of 0x0200 and a project code of 0x0301. The offline upgrade unit 700 compares the firmware information and finds that it does not match its own pre-stored platform code and project code, therefore determining the upgrade target to be the electric motorcycle controller 30. If the platform code in the firmware information is 0x0100 and the project code is 0x0201, then it matches its own information, and the upgrade target is determined to be the Bluetooth bridging module 10 itself.

[0085] Step S33: Space verification and confirmation.

[0086] Storage unit 600 checks whether its remaining storage space is sufficient to accommodate the total firmware size indicated in the firmware information frame. If there is sufficient space, Bluetooth communication unit 100 replies with an acknowledgment frame to communication terminal 20, carrying a flag indicating that transmission can begin and the agreed data size per packet; if there is insufficient space, it replies with an error code, and the temporary storage process terminates.

[0087] Step S34: Packet reception and writing.

[0088] The Bluetooth communication unit 100 receives the firmware data to be upgraded sent by the communication terminal 20 in a packet-based manner. Each data packet frame adopts a preset communication protocol format, and its data field includes a packet sequence number (4 bytes) and data within the packet (e.g., 512 bytes per packet). After receiving each data packet, the storage unit 600 writes it to the corresponding storage offset position. After each packet is written, the Bluetooth communication unit 100 replies with an acknowledgment message to the communication terminal 20, which carries the received packet sequence number and the current reception progress.

[0089] In one implementation, if the communication terminal 20 does not receive an acknowledgment for a packet within a preset waiting time (e.g., 500ms), the communication terminal 20 automatically retransmits the packet, retrying a maximum of a preset number of times (e.g., 3 times). If no acknowledgment is received after the number of retries is exhausted, the communication terminal 20 terminates the temporary storage process and reports an error to the user.

[0090] Step S35: Resume interrupted download.

[0091] Storage unit 600 records the offset position of successfully received data. When transmission is terminated due to communication interruption (e.g., Bluetooth disconnection), communication terminal 20 re-establishes Bluetooth connection with Bluetooth communication unit 100 and sends firmware information frames again. Storage unit 600 detects that it has temporarily stored part of the firmware data (matched by firmware platform code, firmware project code, and firmware version number). Bluetooth communication unit 100 carries the breakpoint resume offset (i.e., the offset position of successfully received data) in the acknowledgment frame. Communication terminal 20 continues transmission from the data packet corresponding to this offset position without starting from the beginning.

[0092] To illustrate with a specific example: Assume the firmware to be upgraded is 256KB in total, with each packet containing 512 bytes, requiring a total of 512 packets to be transmitted. After the 300th packet is transmitted, the Bluetooth connection is unexpectedly lost. At this point, the data offset recorded in storage unit 600 is the 300th packet. After reconnecting, communication terminal 20 sends a firmware information frame, and Bluetooth communication unit 100 returns the breakpoint offset as the 301st packet in the acknowledgment frame. Communication terminal 20 then continues transmission from the 301st packet until all 512 packets are transmitted.

[0093] Step S36: Integrity verification.

[0094] After all data packets are received, the storage unit 600 calculates the CRC32 checksum of the temporarily stored complete firmware data and compares it with the firmware checksum received in step S31. If they match, the data integrity check is confirmed to have passed, and the Bluetooth communication unit 100 replies to the communication terminal 20 with a result frame indicating successful temporary storage; if they do not match, an error code indicating verification failure is replied, and the communication terminal 20 can choose to clear the temporarily stored data and retransmit it.

[0095] After the firmware is temporarily saved, the user can initiate an offline upgrade at any time via a physical trigger signal. This stage does not require the Bluetooth connection of the communication terminal 20. Depending on the upgrade target determined in step S32, the specific process of the offline upgrade is divided into two scenarios.

[0096] Scenario 1: The upgrade target is the electric motorcycle controller 30.

[0097] Step S41: Trigger the upgrade.

[0098] When the user presses the physical button on the Bluetooth bridging module 10, the offline upgrade unit 700 detects the physical trigger signal and checks whether there is a temporary firmware that has passed the integrity check in the storage unit 600. If it exists, the upgrade process begins.

[0099] Step S42: Enter bootloader mode.

[0100] The offline upgrade unit 700 sends a bootloader entry command to the electric motorcycle controller 30 via the protocol conversion unit 300 and the locked communication interface unit. This command is converted into a controller-side protocol frame by the protocol conversion unit 300 and then sent to the electric motorcycle controller 30. Upon receiving the command, the electric motorcycle controller 30 jumps from the application program to the bootloader and returns a "bootloader ready" response frame.

[0101] The bootloader refers to the basic bootloader residing in a separate storage partition of the electric motorcycle controller 30. Its function is to receive firmware data and write it to the application storage area. The storage partition where the bootloader resides is independent of the application storage area and is not affected by firmware upgrade operations.

[0102] If the offline upgrade unit 700 does not receive a "bootloader ready" response within a preset waiting time, it will resend the bootloader entry command, retrying a maximum of a preset number of times (e.g., 3 times). If no valid response is received after the number of retries is exhausted, the offline upgrade unit 700 will abort the upgrade process.

[0103] Step S43: Send firmware data in packets.

[0104] The offline upgrade unit 700 reads the temporarily stored firmware data from the storage unit 600, divides it into packets according to a preset packet size, and sends each packet to the boot program of the electric motorcycle controller 30 through the protocol conversion unit 300 and the locked communication interface unit. After each packet is sent, the offline upgrade unit 700 waits for a write confirmation from the boot program.

[0105] In one implementation, for the CAN interface, since the maximum data field size per frame is 8 bytes, the data size per packet is set to a smaller value (e.g., 256 bytes) and transmitted through multiple CAN messages; for the UART and RS485 interfaces, the data size per packet can be set to a larger value (e.g., 512 bytes).

[0106] Step S44: Upgrade to resume interrupted downloads.

[0107] The offline upgrade unit 700 records the position of successfully sent data packets. If the upgrade process is interrupted (e.g., due to an unexpected power outage), after the Bluetooth bridging module 10 is powered on again, the offline upgrade unit 700 detects that there is still firmware data temporarily stored and marked as "upgrading" in the storage unit 600. When the user presses the button again to trigger the upgrade, the offline upgrade unit 700 continues to send from the next packet after the recorded data packet position. The boot program of the electric motorcycle controller 30 determines the breakpoint position based on the storage address of the received data, thereby realizing breakpoint resume transmission.

[0108] Step S45: Upgrade complete verification.

[0109] After all data packets have been sent, the offline upgrade unit 700 sends an upgrade completion command to the boot program of the electric motorcycle controller 30. The boot program calculates a CRC32 checksum for the received complete firmware data. If the checksum passes, it writes the checksum to the startup flag and jumps to the new firmware.

[0110] Step S46: Upgrade result confirmed.

[0111] After the electric motorcycle controller 30 boots with the new firmware, the handshake unit 200 re-executes the handshake process as described in the previous embodiments. If the handshake is successful and the read firmware version number matches the version number of the temporary firmware, the offline upgrade unit 700 determines that the upgrade is successful, clears the temporary firmware data in the storage unit 600, and the Bluetooth bridging module 10 is restored to the parameter caching mode as described in the previous embodiments.

[0112] Step S47: Upgrade failed, rollback.

[0113] If the bootloader of the electric motorcycle controller 30 fails to verify the received firmware data, or if the new firmware malfunctions after startup, causing the handshake unit 200 to fail to complete the handshake, the electric motorcycle controller 30 will remain in bootloader mode and wait for a re-upgrade. At this time, the offline upgrade unit 700 retains the temporary firmware data in the storage unit 600 without clearing it, and the user can press the button again to re-trigger the upgrade process. Because the bootloader resides in an independent storage partition and is unaffected by the firmware upgrade, the electric motorcycle controller 30 will not be unable to recover due to upgrade failure, ensuring the security of the upgrade process.

[0114] To illustrate with a complete upgrade process: Continuing with the example of the firmware temporary storage stage, storage unit 600 has temporarily stored 256KB of controller firmware, totaling 512 packets. After the user presses the button, offline upgrade unit 700 sends a bootloader entry command to the electric motorcycle controller 30. Upon receiving a ready response, it begins packet transmission. Assuming the current communication configuration is a UART interface with a baud rate of 57600bps and each packet is 512 bytes, offline upgrade unit 700 sends packets 1 through 512 sequentially, receiving write confirmation for each packet. After all transmissions are complete, the bootloader verification passes, and the electric motorcycle controller 30 jumps to the new firmware. Handshake unit 200 successfully re-handshakes, confirming the version number update, and the upgrade process is complete.

[0115] Scenario 2: The upgrade target is the Bluetooth bridging module 10 itself.

[0116] When the upgrade target is determined to be the Bluetooth bridging module 10 itself in step S32, the firmware temporary storage stage process is exactly the same as in scenario one, and the firmware data is also temporarily stored in the storage unit 600. The difference lies in the execution process of the offline upgrade stage, which is as follows: Step S51: Trigger self-upgrade.

[0117] After the firmware is temporarily stored and passes the integrity verification, the communication terminal 20 sends a module self-upgrade command frame to the Bluetooth communication unit 100.

[0118] Step S52: Set the upgrade flag and trigger a reset.

[0119] After receiving its own upgrade command, the offline upgrade unit 700 sets the upgrade flag in the internal non-volatile memory of the Bluetooth bridging module 10, and then triggers the Bluetooth bridging module 10 to perform a software reset.

[0120] Step S53: The bootloader performs a firmware update.

[0121] After the Bluetooth bridging module 10 is reset, its boot program detects the upgrade flag bit during startup, and then reads the temporarily stored firmware data from the storage unit 600 and writes it into the application storage area of ​​the main control chip of the Bluetooth bridging module 10, overwriting the original application firmware.

[0122] Step S54: Complete the self-upgrade.

[0123] After the write operation is complete, the bootloader verifies the firmware data in the application storage area. If the verification passes, the bootloader clears the upgrade flag and jumps to the new application firmware, allowing the Bluetooth bridging module 10 to complete its firmware upgrade. If the verification fails, the bootloader clears the upgrade flag but retains the original firmware, allowing the module to start normally with the original application firmware, ensuring that the Bluetooth bridging module 10 will not fail to function due to an upgrade failure.

[0124] Through the collaborative operation of storage unit 600 and offline upgrade unit 700, this embodiment decouples online firmware storage from offline upgrades. After firmware data is temporarily stored in storage unit 600 via Bluetooth, the upgrade operation can be completed independently via a physical button without a Bluetooth connection. This allows on-site maintenance personnel to pre-store the firmware in the Bluetooth bridging module 10 and complete the upgrade with a single click during subsequent on-site maintenance, without relying on a mobile phone or network environment. Simultaneously, the packet transmission confirmation and retransmission mechanism and the breakpoint resumption mechanism ensure the reliability of firmware data transmission, while the independent partition design of the bootloader and the verification rollback mechanism ensure the security of the upgrade process, mitigating the risk of device unrecoverability due to communication interruption or verification failure during firmware upgrades.

[0125] In one implementation, the hardware implementation of the multiplexed communication interface unit and the corresponding transceiver circuit is as follows: For the CAN interface, the transceiver circuit includes an SPI-to-CAN controller (e.g., MCP2515) and a CAN transceiver (e.g., TJA1050) connected to the main control chip via the SPI interface. The SPI-to-CAN controller completes the frame encapsulation and parsing of the CAN protocol, and the CAN transceiver completes the level conversion of the CAN signal and outputs CAN_H and CAN_L differential signals.

[0126] For the UART interface, the transceiver circuit is a level matching circuit. When the communication level of the electric motorcycle controller 30 is consistent with that of the main control chip (e.g., both are 3.3V), it can be directly connected. When the communication level of the electric motorcycle controller 30 is 5V, it is matched through a level conversion chip (e.g., TXB0102).

[0127] For RS485 interfaces, the transceiver circuit includes an RS485 transceiver (e.g., MAX485), whose data transceiver pins are connected to the UART peripheral of the main control chip. The transmit / receive direction switching pin (DE / RE) is controlled by the GPIO port of the main control chip, and outputs RS485 differential signals A and B.

[0128] In addition, the Bluetooth bridging module 10 also includes a power management circuit, which draws power from the power line on the side of the electric motorcycle controller 30. The input voltage range is compatible with common electric motorcycle battery voltages (e.g., 12V to 72V), and is converted to a 3.3V operating voltage by a DC-DC step-down converter chip (e.g., MP1584) to power the main control chip, transceiver circuit and storage unit 600.

[0129] In another embodiment, the power management circuit may also adopt an LDO linear regulator scheme or a multi-stage buck scheme, and the specific topology can be selected according to the input voltage range and power consumption requirements.

[0130] It should be noted that the Bluetooth bridging module 10 is equipped with a touch button and an indicator light. The touch button is connected to the GPIO port of the main control chip (configured as a pull-up input) to generate the physical trigger signal as described in the previous embodiments. In one embodiment, a short press of the button triggers the offline upgrade process, and a long press of the button (e.g., pressing continuously for more than 3 seconds) triggers the module reset.

[0131] The indicator light is used to indicate the working status of the Bluetooth bridging module 10. In one embodiment, the indicator light uses an RGB tri-color LED, which indicates different working statuses through different colors and flashing frequencies.

[0132] In another embodiment, the indicator light can also be a combination of multiple monochrome LEDs, or it can indicate different states by encoding the number of flashes. The specific indication scheme can be adjusted according to the module's size and cost requirements.

[0133] As defined in the foregoing embodiments, the communication terminal 20 refers to a terminal device that establishes a Bluetooth wireless connection with the Bluetooth bridging module 10 and sends operation commands to it. In one embodiment, the communication terminal 20 is a smartphone running a dedicated Bluetooth APP. This APP provides a unified graphical user interface through which users can perform operations such as parameter reading and display, parameter modification and writing, motor self-learning triggering, factory reset, firmware file selection and temporary storage transfer.

[0134] In another embodiment, the communication terminal 20 is a smartphone running a WeChat mini-program. Users do not need to install a separate app; they can access the parameter adjustment and upgrade interface by scanning a QR code with WeChat, thus lowering the barrier to entry. In yet another embodiment, the communication terminal 20 can also be a tablet computer, laptop computer, or other smart terminal device with Bluetooth functionality.

[0135] Regardless of the specific form of the communication terminal 20, it uses the preset communication protocol defined in the aforementioned embodiments to interact with the Bluetooth bridging module 10. The functional logic of the Bluetooth bridging module 10 does not change due to the different specific forms of the communication terminal 20.

[0136] In one implementation, in addition to reading and writing parameters of the electric motorcycle controller 30 through the Bluetooth bridging module 10, the communication terminal 20 can also directly read and write the parameters of the Bluetooth bridging module 10 itself. This operation is handled directly by the Bluetooth communication unit 100 without going through the protocol conversion unit 300 and the multiplex communication interface unit.

[0137] The readable module parameters include: the currently locked communication interface type and baud rate, Bluetooth broadcast name and MAC address, module firmware version number, firmware cache status in storage unit 600 (including whether there is temporary firmware, firmware size, firmware platform code, firmware project code, firmware version number and checksum), and the module's cumulative runtime and number of upgrades. The writable module parameters include: the default baud rate of each communication interface, Bluetooth broadcast name, and handshake scan timeout.

[0138] By reading and writing the module's own parameters, maintenance personnel can intuitively view the current working status and configuration information of the Bluetooth bridging module 10 on the communication terminal 20, and make adjustments according to actual needs, further improving the maintainability and flexibility of the Bluetooth bridging module 10.

[0139] Please see Figure 4 , Figure 4 This is a flowchart illustrating a communication method provided by an embodiment of the present invention. The communication method is applied to a Bluetooth bridging module including a multi-channel communication interface, a Bluetooth unit, and a memory. The Bluetooth bridging module can be the Bluetooth bridging module 10 described in any of the foregoing embodiments.

[0140] like Figure 4 As shown, the communication method specifically includes the following steps: Step S100: Sequentially send handshake request frames at multiple candidate baud rates on the multi-channel communication interface, determine the valid communication interface and communication baud rate based on the handshake response frame returned by the electric motorcycle controller, and lock it as the current communication configuration.

[0141] Specifically, after the Bluetooth bridging module powers on, it sequentially sends handshake request frames on multiple communication interfaces and iterates through multiple candidate baud rates on each interface. For each candidate baud rate on each communication interface, after sending a handshake request frame, it waits for a preset time. If a valid handshake response frame is received within the preset time, the current communication configuration is locked and scanning stops; if no valid handshake response frame is received within the preset time, it switches to the next candidate baud rate or the next communication interface to continue scanning.

[0142] Continuing with the example from the previous embodiments, the Bluetooth bridging module sequentially scans the CAN interface, UART interface, and RS485 interface, traversing its respective candidate baud rate list for each interface. It waits 200ms after each handshake request frame is sent. Assuming the electric motorcycle controller uses UART communication at a baud rate of 57600bps, if the Bluetooth bridging module does not receive a response after scanning all candidate baud rates on the CAN interface, it switches to the UART interface and attempts until it receives a valid handshake response frame at 57600bps. It then locks the UART interface and 57600bps as the current communication configuration.

[0143] Step S200: Receive the instruction frame sent by the communication terminal in the form of a preset communication protocol through the Bluetooth unit, convert the instruction frame into a controller-side protocol frame corresponding to the current communication configuration and send it to the electric motorcycle controller, and convert the response data of the electric motorcycle controller into a preset communication protocol frame and send it back to the communication terminal.

[0144] After establishing a connection with the communication terminal via Bluetooth, the Bluetooth bridging module receives command frames sent by the communication terminal using a preset communication protocol. The types of command frames include, but are not limited to, parameter read requests, parameter write requests, motor self-learning commands, factory reset commands, and power-off data saving commands.

[0145] The Bluetooth bridging module converts the received command frame into a controller-side protocol frame corresponding to the current communication configuration locked in step S100, and sends it to the electric motorcycle controller through the locked communication interface. The response data returned by the electric motorcycle controller after performing the corresponding operation is converted back into a preset communication protocol frame by the Bluetooth bridging module and then transmitted back to the communication end via Bluetooth.

[0146] In one implementation, after step S100 is completed, the Bluetooth bridging module reads the parameter data of the electric motorcycle controller through the locked communication interface at a preset period and caches it in the local memory. When the communication end requests to read the parameters, it directly returns the cached data.

[0147] Step S300: Receive firmware information and firmware data to be upgraded sent by the communication terminal through the Bluetooth unit, determine the upgrade target based on the firmware platform code and firmware project code in the firmware information, write the firmware data into the memory in packets, and perform integrity verification on the temporarily stored firmware data after receiving.

[0148] Specifically, the Bluetooth bridging module first receives firmware information sent by the communication terminal through the Bluetooth unit. This firmware information includes the total firmware size, firmware checksum, firmware platform code, firmware project code, and firmware version number. Based on the firmware platform code and firmware project code, the Bluetooth bridging module determines whether the upgrade target is the electric motorcycle controller or the Bluetooth bridging module itself.

[0149] Subsequently, the Bluetooth bridging module receives the firmware data to be upgraded from the communication terminal in packet form via the Bluetooth unit and writes it to the memory packet by packet. After each packet is written, an acknowledgment message is sent back to the communication terminal. The memory records the offset position of the successfully received data. If the transmission is interrupted due to communication interruption, it can resume receiving from the interrupted position after reconnection, realizing breakpoint resume transmission.

[0150] After all data packets are received, the Bluetooth bridging module calculates the CRC32 check value of the complete firmware data temporarily stored in the memory and compares it with the firmware check value in the firmware information to confirm the data integrity.

[0151] Continuing with the example from the previous embodiments, the 256KB firmware file is transmitted in 512 packets of 512 bytes each. Assume that Bluetooth connection is lost after the 300th packet is transmitted, and the memory records the offset position as the 300th packet. After the communication end reconnects, transmission continues from the 301st packet to the 512th packet. After all packets are received, the CRC32 check passes, and the firmware is temporarily stored.

[0152] Step S400: In response to the physical trigger signal, write the firmware data temporarily stored in the memory to the electric motorcycle controller through the locked communication interface.

[0153] Scenario 1: The upgrade target is an electric motorcycle controller.

[0154] Upon receiving a physical trigger signal, the Bluetooth bridging module sends a bootloader entry command to the electric motorcycle controller. Once the controller enters bootloader mode, the module reads firmware data from memory and sends it in packets, waiting for write confirmation for each packet. The Bluetooth bridging module records the position of successfully transmitted data packets. If the upgrade process is interrupted unexpectedly, it resumes transmission from the next packet at the recorded position upon the next trigger, achieving breakpoint resumption. After all transmissions are complete, the electric motorcycle controller's bootloader verifies the firmware data. If the verification passes, it jumps to the new firmware; if the verification fails, the controller remains in bootloader mode, waiting for a re-upgrade.

[0155] Continuing with the previous example, after the user presses the button, the Bluetooth bridging module sends a bootloader entry command to the electric motorcycle controller via the UART interface (57600bps). Upon receiving a ready response, it sends 512 packets of firmware data one by one, waiting for write confirmation for each packet. After all packets are sent, the bootloader CRC32 check passes, and the electric motorcycle controller jumps to the new firmware. The Bluetooth bridging module successfully re-handshakes, confirms the version number update, and the upgrade is complete.

[0156] Scenario 2: The upgrade target is the Bluetooth bridging module itself.

[0157] When the upgrade target is the Bluetooth bridging module itself, after the firmware is temporarily stored and verified, the Bluetooth bridging module sets the upgrade flag and performs a reset. The Bluetooth bridging module's bootloader then reads the firmware data from the memory and writes it to the application storage area to complete its own firmware update. If the bootloader verification fails, the upgrade flag is cleared, and the module starts normally with the original firmware.

[0158] This communication method enables the communication terminal to perform parameter reading, writing, and firmware upgrade operations on electric motorcycle controllers using different communication methods and baud rates through a unified preset communication protocol. This eliminates the need for users to manually match communication parameters or equip themselves with multiple special tools, thus achieving a unified communication bridging function for multiple protocols.

[0159] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A Bluetooth bridging module, applied to an electric motorcycle controller, characterized in that, include: The Bluetooth communication unit establishes a wireless connection with the communication terminal and is configured to interact with the communication terminal according to a preset communication protocol. A multi-channel communication interface unit is connected to the electric motorcycle controller through a corresponding transceiver circuit; The handshake unit is configured to sequentially send handshake request frames on the multiple wired communication interfaces, traverse multiple candidate baud rates on each interface, determine the valid communication interface unit and communication baud rate based on the handshake response frame returned by the electric motorcycle controller, and lock it as the current communication configuration. The protocol conversion unit is configured to convert the preset communication protocol frame received by the Bluetooth communication unit into a controller-side protocol frame corresponding to the current communication configuration, and to convert the controller-side protocol frame returned by the electric motorcycle controller into a preset communication protocol frame. The locked communication interface unit is used to send the controller-side protocol frame converted by the protocol conversion unit to the electric motorcycle controller; The Bluetooth communication unit is used to transmit the preset communication protocol frame converted by the protocol conversion unit back to the communication terminal.

2. The Bluetooth bridging module according to claim 1, characterized in that, Also includes: The parameter caching unit is configured to read the parameter data of the electric motorcycle controller through the locked communication interface unit at a preset period after a successful handshake and cache it in the local memory; When the communication terminal requests to read parameters, the cached parameter data is returned to the communication terminal.

3. The Bluetooth bridging module according to claim 1, characterized in that, Also includes: The storage unit is configured to temporarily store firmware data to be upgraded received via the Bluetooth communication unit; The offline upgrade unit is configured to read the firmware data to be upgraded from the storage unit in response to a physical trigger signal, and write the firmware data into the electric motorcycle controller through the protocol conversion unit and the locked communication interface unit.

4. The Bluetooth bridging module according to claim 3, characterized in that, Before temporarily storing firmware data, the storage unit first receives firmware information via the Bluetooth communication unit; wherein, the firmware information includes firmware checksum, firmware platform code, and firmware project code. The offline upgrade unit determines the upgrade target as the electric motorcycle controller or the Bluetooth bridging module itself based on the firmware platform code and firmware project code.

5. The Bluetooth bridging module according to claim 4, characterized in that, The Bluetooth communication unit receives the firmware data to be upgraded in a packet-by-packet manner. After each packet is written to the storage unit, the Bluetooth communication unit replies with confirmation information to the communication terminal. After all packets are received, the temporarily stored complete firmware data is verified and compared with the firmware verification value to confirm the data integrity. The storage unit records the offset position of successfully received data. When the transmission is terminated due to communication interruption and reconnected, the Bluetooth communication unit continues to receive firmware data from the data offset position.

6. The Bluetooth bridging module according to claim 4, characterized in that, When the upgrade target is the Bluetooth bridging module itself, the offline upgrade unit sets the upgrade flag and triggers a reset after the firmware temporary storage is completed and the verification is passed. After the reset, the boot program of the Bluetooth bridging module reads the firmware data from the non-volatile storage unit and writes it into the application storage area to complete its own firmware upgrade.

7. The Bluetooth bridging module according to claim 3, characterized in that, When the offline upgrade unit performs firmware writing, it first sends a boot program entry command to the electric motorcycle controller. After the electric motorcycle controller enters the boot program mode, it sends firmware data in packets, and each packet waits for write confirmation. The offline upgrade unit records the position of successfully sent data packets. If the upgrade process is interrupted, it will continue sending from the interrupted position the next time it is triggered. If the firmware verification of the electric motorcycle controller fails, it will remain in bootloader mode and wait for a re-upgrade.

8. A communication method applied to a Bluetooth bridging module including a multi-channel communication interface, a Bluetooth unit, and a memory, characterized in that, Includes the following steps: Handshake request frames are sent sequentially on the multi-channel communication interface at multiple candidate baud rates; The valid communication interface and communication baud rate are determined based on the handshake response frame returned by the electric motorcycle controller and locked as the current communication configuration. The Bluetooth unit receives instruction frames sent by the communication terminal using a preset communication protocol, converts the instruction frames into controller-side protocol frames corresponding to the current communication configuration, and sends them to the electric motorcycle controller. The response data of the electric motorcycle controller is then converted into preset communication protocol frames and sent back to the communication terminal. The Bluetooth unit receives firmware information and firmware data to be upgraded sent by the communication terminal. Based on the firmware platform code and firmware project code in the firmware information, the upgrade target is determined. The firmware data is divided into packets and written into the memory. After receiving the data, the integrity of the temporarily stored firmware data is verified. In response to a physical trigger signal, the firmware data temporarily stored in the memory is written to the electric motorcycle controller through a locked communication interface.

9. The method according to claim 8, characterized in that, The process of sequentially sending handshake request frames at multiple candidate baud rates on the multi-channel communication interface, determining the valid communication interface and communication baud rate based on the handshake response frame returned by the electric motorcycle controller, and locking it as the current communication configuration includes: For each candidate baud rate of each communication interface, send a handshake request frame and wait for a preset time; If a valid handshake response frame is received within the preset time, the current communication configuration is locked and scanning is stopped; If no valid handshake response frame is received within the preset time, the scan will switch to the next candidate baud rate or the next communication interface.

10. The method according to claim 8, characterized in that, The step of writing the firmware data temporarily stored in the memory into the electric motorcycle controller via a locked communication interface in response to a physical trigger signal includes: A boot program entry command is sent to the electric motorcycle controller. After the electric motorcycle controller enters the boot program mode, firmware data is sent in packets and waits for write confirmation for each packet. The position of the successfully sent data packets is recorded to support resume transmission after interruption. When the upgrade target is the Bluetooth bridging module itself, after the firmware is temporarily stored and verified, the upgrade flag is set and a reset is performed, and the Bluetooth bridging module's bootloader completes its own firmware update.

Images