A program loading system and method based on USB interface

By using a USB-based program loading system and leveraging information transmission between interrupt endpoints and block endpoints, the problem of simultaneous application loading in existing technologies is solved, enabling a highly efficient and intelligent program loading process while ensuring the accuracy of program data.

CN121209992BActive Publication Date: 2026-03-17HEFEI HEXAGON SEMICON CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202511725470.9
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-11-24
Publication Date
2026-03-17
Estimated Expiration
2045-11-24

AI Technical Summary

Technical Problem

Existing program loading methods cannot load related applications onto multiple electronic devices simultaneously, resulting in low efficiency and low intelligence levels.

Method used

By using a USB-based program loading system, information is transmitted between the source and target devices via interrupt endpoints and block endpoints to achieve parallel loading. This includes program loading queries, status feedback, handshake requests, verification, and retransmission detection, ensuring accurate transmission and execution of program code.

Benefits of technology

It enables simultaneous program loading on multiple electronic devices, improving loading efficiency and intelligence, and ensures the correctness of program data through a verification mechanism.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121209992B_ABST
    Figure CN121209992B_ABST
Patent Text Reader

Abstract

The present application relates to the technical field of electric digital data processing, and especially relates to a program loading system and method based on a USB interface. The system comprises a source device and N target devices; the source device is connected with the N target devices through a USB interface, the target devices contain block endpoints and interrupt endpoints; after receiving start loading commands fed back by each target device, the source device extracts retransmission detection byte numbers in parallel, establishes a connection with each target device through handshake request packets and handshake response packets, transmits to-be-loaded program codes to each target device through start address request packets and write command packets, detects whether retransmission is performed through check request packets and check response packets in the transmission process, and controls each target device to run the to-be-loaded program codes after the transmission process is completed. The embodiment of the present application can intelligently implement simultaneous loading of programs into multiple electronic devices based on information transmitted through interrupt endpoints and block endpoints, and detect whether retransmission is performed.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, and in particular to a program loading system and method based on a USB interface. Background Technology

[0002] When enterprises mass-produce electronic devices to provide specific business functions, they need to load relevant applications into each electronic device. These specific business functions can refer to features such as image processing, voice processing, or text processing. The relevant applications are those that the electronic devices need to use during operation. Loading these applications into the electronic devices involves transferring the application's program code to the devices, and then using the program code that controls the electronic devices to run the applications after the transfer is complete.

[0003] In related technologies, a common program loading scheme involves a server sequentially transmitting the program code of relevant applications to various electronic devices in a specified order. After the program code transmission is complete, the electronic devices are instructed to run the application's program code, thereby loading the application onto each device. However, this method requires loading applications sequentially to each electronic device, making simultaneous loading impossible. Consequently, the efficiency and intelligence of the program loading process are relatively low. Summary of the Invention

[0004] This invention provides a program loading system and method based on a USB interface to solve the problems of related program loading schemes being unable to load related applications onto various electronic devices simultaneously, and the low efficiency and intelligence level of the program loading process.

[0005] According to one aspect of the present invention, a program loading system based on a USB interface is provided, comprising: a source device and N target devices;

[0006] The source device is connected to N target devices via a USB interface, and each target device contains a block endpoint and an interrupt endpoint.

[0007] The source device periodically sends program loading query commands to each target device through the interrupt endpoints of each target device.

[0008] After receiving the program loading query command, each target device determines the current program loading status and feeds back the status representation information corresponding to the current program loading status to the source device through the interrupt endpoint of each target device; wherein, the status representation information is a stop loading command, a start loading command, or a loading command.

[0009] After receiving the start loading command from each target device via the interrupt endpoint, the source device extracts the retransmission detection byte count from the start loading command from each target device in parallel. It determines the establishment of a connection with each target device by transmitting handshake request packets and handshake response packets based on the block endpoints of each target device. It transmits the program code to be loaded to each target device by transmitting start address request packets and write command packets based on the block endpoints of each target device. During the transmission process, it detects whether to retransmit by transmitting the retransmission detection byte count, verification request packets, and verification response packets based on the block endpoints of each target device. After the transmission process of the program code to be loaded is completed, it controls each target device to run the program code to be loaded.

[0010] The source device is a portable device, and the target device is a development board.

[0011] According to another aspect of the present invention, a program loading method based on a USB interface is provided, applied to a program loading system based on a USB interface as described in the embodiments of the present invention, comprising:

[0012] The source device periodically sends program loading query commands to each target device through the interrupt endpoints of each target device.

[0013] After receiving the program loading query command, each target device determines the current program loading status and feeds back the status representation information corresponding to the current program loading status to the source device through the interrupt endpoint of each target device; wherein, the status representation information is a stop loading command, a start loading command, or a loading command.

[0014] After receiving the start loading command from each target device via the interrupt endpoint, the source device extracts the retransmission detection byte count from the start loading command from each target device in parallel. It determines the establishment of a connection with each target device by transmitting handshake request packets and handshake response packets based on the block endpoints of each target device. It transmits the program code to be loaded to each target device by transmitting start address request packets and write command packets based on the block endpoints of each target device. During the transmission process, it detects whether to retransmit by transmitting the retransmission detection byte count, verification request packets, and verification response packets based on the block endpoints of each target device. After the transmission process of the program code to be loaded is completed, it controls each target device to run the program code to be loaded.

[0015] In the technical solution of this invention embodiment, the source device periodically sends program loading query instructions to each target device through the interrupt endpoints of each target device. Upon receiving the program loading query instructions, each target device determines its current program loading status and feeds back status representation information corresponding to the current program loading status to the source device through its interrupt endpoints. This status representation information includes a stop loading command, a start loading command, or a loading command. After receiving the start loading commands from each target device through its interrupt endpoints, the source device extracts the number of retransmission detection bytes from the start loading commands fed back by each target device in parallel. It then determines the establishment of a connection with each target device through handshake request packets and handshake response packets transmitted based on the block endpoints of each target device, and sends the program to be loaded to the target device through start address request packets and write command packets transmitted based on the block endpoints of each target device. The program code is transmitted to various target devices. During transmission, retransmission is detected based on the number of bytes transmitted via the block endpoints of each target device, as well as verification request packets and verification response packets. After the transmission of the program code to be loaded is completed, each target device is controlled to run the program code. This solves the problem that related program loading schemes cannot simultaneously load related applications onto various electronic devices, resulting in low efficiency and intelligence in the program loading process. Based on the information transmitted via the interrupt endpoints and block endpoints of the electronic devices that need to load related applications, the program can intelligently load related applications onto multiple electronic devices simultaneously, improving the efficiency and intelligence of the program loading process. Retransmission can be detected based on verification request packets and verification response packets, thereby maximizing the verification of the correctness of program data while ensuring program loading efficiency.

[0016] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of a program loading system based on a USB interface provided in Embodiment 1 of the present invention.

[0019] Figure 2 This is a schematic diagram of a target device provided in Embodiment 1 of the present invention.

[0020] Figure 3 This is a schematic diagram of a source device provided in Embodiment 1 of the present invention.

[0021] Figure 4 This is a schematic diagram of a program loading system based on a USB interface provided in Embodiment 1 of the present invention.

[0022] Figure 5 This is a flowchart of a program loading method based on a USB interface provided in Embodiment 2 of the present invention. Detailed Implementation

[0023] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0024] It should be noted that the terms "target," "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising," "including," and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0025] It should be noted that all information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data comply with the relevant laws, regulations and standards of the relevant regions.

[0026] Example 1

[0027] Figure 1 This is a schematic diagram of a program loading system based on a USB interface provided in Embodiment 1 of the present invention. This embodiment is applicable to situations where, during the mass production of electronic devices for providing specific business functions, relevant applications are loaded into various electronic devices. Figure 1As shown, the USB interface-based program loading system may specifically include: a source device 101 and N target devices 102. Its structure and function are described below.

[0028] The source device 101 is connected to N target devices 102 via USB interfaces, and each target device 102 includes a block endpoint and an interrupt endpoint.

[0029] The source device 101 periodically sends program loading query instructions to each target device 102 through the interrupt endpoints of each target device 102.

[0030] After receiving the program loading query instruction, each target device 102 determines the current program loading status and feeds back the status representation information corresponding to the current program loading status to the source device 101 through the interrupt endpoint of each target device 102; wherein, the status representation information is a stop loading command, a start loading command, or a loading command.

[0031] After receiving the start loading command from each target device 102 via the interrupt endpoint, the source device 101 extracts the retransmission detection byte count from the start loading command from each target device 102 in parallel. It determines the establishment of a connection with each target device 102 by transmitting the handshake request packet and handshake response packet based on the block endpoint of each target device 102. It transmits the program code to be loaded to each target device 102 by transmitting the start address request packet and write command packet based on the block endpoint of each target device 102. During the transmission process, it detects whether to retransmit by transmitting the retransmission detection byte count, verification request packet, and verification response packet based on the block endpoint of each target device 102. After the transmission process of the program code to be loaded is completed, it controls each target device 102 to run the program code to be loaded.

[0032] Optionally, during the mass production of electronic devices used to provide specified business functions, enterprises need to load relevant applications into each electronic device. The specified business function can refer to functions such as image processing, voice processing, or text processing. The relevant application can refer to the application that the electronic device needs to use during operation. N is a positive integer greater than or equal to 2. The N target devices 102 are N electronic devices that need to load the relevant applications. The source device 101 can be an electronic device used to load the relevant applications into the target devices 102.

[0033] Optionally, the source device 101 is a portable device, and the target device 102 is a development board. A portable device can refer to a portable electronic device. For example, a portable device could be a mobile phone or tablet. A development board can refer to a circuit board manufactured by an enterprise to provide specific business functions. In actual production, the source device 101 can be moved freely to any location, without being limited by fixed equipment such as computers or servers, greatly facilitating program loading.

[0034] Optionally, each target device 102 is equipped with a Universal Serial Bus (USB) interface. The source device 101 extends N USB interfaces via a USB hub. Each of the N extended USB interfaces from the source device 101 is connected to one of the USB interfaces of the target devices 102. The block endpoint in the target device 102 can be a data transmission channel established based on the USB interface of the target device 102 and the USB interface of the source device 101 connected to the USB interface of the target device 102, used to transmit handshake request packets, handshake response packets, start address request packets, write command packets, verification request packets, and verification response packets between the target device 102 and the source device 101. The interrupt endpoint in the target device 102 can be a data transmission channel established based on the USB interface of the target device 102 and the USB interface of the source device 101 connected to the USB interface of the target device 102, for transmitting information such as program loading query commands, stop loading commands, start loading commands, and loading commands between the target device 102 and the source device 101.

[0035] Optionally, the source device 101 periodically sends a program load query instruction to each target device 102 via the interrupt endpoints of each target device 102. The program load query instruction may be pre-set information used to request state representation information corresponding to the current program loading state of the target device 102. The source device 101 can send the program load query instruction to each target device 102 via the interrupt endpoint of each target device 102. The source device 101 may perform the operation of sending the program load query instruction to each target device 102 via the interrupt endpoints of each target device 102 once at a preset time interval. The preset time interval may be a pre-set time interval. For example, the preset time interval is 5 seconds.

[0036] Optionally, for each target device 102, the program loading state of the target device 102 can be the state of the program loading process in which the target device 102 is currently performing. The program loading state of the target device 102 at the current moment is the program loading state of the target device 102 at the current moment, which is the state of the program loading process in which the target device 102 is currently performing. The program loading state of the target device 102 is: pending loading, stopped loading, or loading in progress. Pending loading may mean that the source device 101 needs to start loading the program for the target device 102. Stopped loading may mean that the source device 101 does not need to start loading the program for the target device 102. Loading in progress may mean that the source device 101 is currently loading the program for the target device 102. The state representation information corresponding to the program loading state can be information used to represent the program loading state of the target device 102. The state representation information corresponding to the program loading state is a stop loading command, a start loading command, or a loading in progress command. The stop loading command can be pre-set information used to represent that the program loading state of the target device 102 is stopped loading. The "Start Loading" command can be a pre-set message indicating that the program loading status of the target device 102 is "awaiting loading". The "Loading in Progress" command can be a pre-set message indicating that the program loading status of the target device 102 is "currently loading". The target device 102 stores the "Stop Loading", "Start Loading", and "Loading in Progress" commands.

[0037] Optionally, after receiving the program loading query instruction, each target device 102 determines the current program loading status and feeds back the status representation information corresponding to the current program loading status to the source device 101 through the interrupt endpoint of each target device 102. This includes: after receiving the program loading query instruction, each target device 102 performs the following operations: the target device 102 determines the current program loading status based on the status of the target button set on the target device 102 and the data already received by the target device 102; if the current program loading status is pending loading, the target device 102 determines the number of retransmission detection bytes based on the status of the target DIP switch set on the target device 102, adds the number of retransmission detection bytes to the start loading command, and feeds back the start loading command to the source device 101 through the interrupt endpoint; if the current program loading status is stopped loading, the target device 102 feeds back the stop loading command to the source device 101 through the interrupt endpoint; if the current program loading status is loading, the target device 102 feeds back the loading command to the source device 101 through the interrupt endpoint.

[0038] Optionally, the target button can be a button on the target device 102 used to instruct the target device 102 to begin program loading. The target button can be either pressed or unpressed. A technician can instruct each target device 102 to begin program loading simultaneously by pressing the target buttons on all target devices 102. Alternatively, a technician can instruct each target device 102 not to begin program loading simultaneously at this time by not pressing the target buttons on all target devices 102. The data already received by the target device 102 can refer to data that the target device 102 has already received.

[0039] Optionally, the target device 102 determines the current program loading status based on the state of the target button set on the target device 102 and the data receiving status of the target device 102. This includes: if the target button is pressed and the data received by the target device 102 does not contain a handshake request packet, the current program loading status is determined to be "pending loading"; if the target button is not pressed, the current program loading status is determined to be "stopped loading"; if the target button is pressed and the data received by the target device 102 contains a handshake request packet, the current program loading status is determined to be "loading in progress". The handshake request packet can be a data packet sent by the source device 101 to the target device 102 when it starts program loading, used to request confirmation of establishing a connection with the target device 102. Typically, if the target button is pressed and the data received by the target device 102 does not contain a handshake request packet, it indicates that program loading of the target device 102 needs to begin but the source device 101 has not yet started program loading, and the program loading status of the target device 102 can be determined to be "pending loading". If the target button is not pressed, it indicates that program loading for target device 102 does not need to begin, and the program loading status of target device 102 can be determined to be stopped loading. If the target button is pressed and the data received by target device 102 contains a handshake request packet, it indicates that program loading for target device 102 needs to begin and source device 101 has already started program loading for target device 102, and the program loading status of target device 102 can be determined to be loading. Target device 102 can detect the state of the target button and whether the data received by target device 102 contains a handshake request packet. If the target button is pressed and the data received by target device 102 does not contain a handshake request packet, the current program loading status can be determined to be pending loading. If the target button is not pressed, the current program loading status can be determined to be stopped loading. If the target button is pressed and the data received by target device 102 contains a handshake request packet, the current program loading status can be determined to be loading. The program loading status of target device 102 is pending loading, stopped loading, or loading. "Pending loading" means that the source device 101 needs to start loading the program onto the target device 102. "Loading stopped" means that the source device 101 does not need to start loading the program onto the target device 102. "Loading in progress" means that the source device 101 is currently loading the program onto the target device 102.

[0040] Optionally, the retransmission detection byte count for target device 102 can be the number of bytes used to detect whether retransmission is required during the transmission of the program code to be loaded to target device 102. After each write command packet containing part of the program code to be loaded is sent to target device 102, source device 101 checks whether the number of bytes of program code already sent to target device 102 via the write command packet is an integer multiple of the retransmission detection byte count. If the number of bytes of program code already sent to target device 102 via the write command packet is an integer multiple of the retransmission detection byte count, source device 101 checks whether to retransmit the write command packet via a verification request packet and a verification response packet. After determining that the write command packet should not be retransmitted or that the write command packet retransmission is completed, it continues to send the next write command packet. The target DIP switch set on target device 102 can be a DIP switch used to set the retransmission detection byte count for target device 102. The target DIP switch can be an 8-bit switch consisting of eight independent switches: Switch 1, Switch 2, Switch 3, Switch 4, Switch 5, Switch 6, Switch 7, and Switch 8. Each switch can be toggled to either ON or OFF. Each switch's state is either ON or OFF. Technicians can manually set the retransmission detection byte count for the target device 102 by toggling one of the eight switches or not toggling any of the eight switches. Initially, all eight switches are toggled OFF. The retransmission detection byte count for the target device 102 can be set to 1KB by toggling only Switch 1 to ON. The retransmission detection byte count for the target device 102 can be set to 2KB by toggling only Switch 2 to ON. The retransmission detection byte count for the target device 102 can be set to 3KB by toggling only Switch 3 to ON. The retransmission detection byte count for the target device 102 can be set to 4KB by toggling only Switch 4 to ON. The retransmission detection byte count for target device 102 can be set to 5KB by only turning the fifth switch to ON. The retransmission detection byte count for target device 102 can be set to 6KB by only turning the sixth switch to ON. The retransmission detection byte count for target device 102 can be set to 7KB by only turning the seventh switch to ON. The retransmission detection byte count for target device 102 can be set to 8KB by only turning the eighth switch to ON. The retransmission detection byte count for target device 102 can be set to 0 by keeping all switches in the OFF state.

[0041] Optionally, the number of retransmission detection bytes is determined based on the state of the target DIP switch set on the target device 102, including: if only the first switch among all the switches of the target DIP switch is in the ON state, then the number of retransmission detection bytes is determined to be 1KB; if only the second switch among all the switches of the target DIP switch is in the ON state, then the number of retransmission detection bytes is determined to be 2KB; if only the third switch among all the switches of the target DIP switch is in the ON state, then the number of retransmission detection bytes is determined to be 3KB; if only the fourth switch among all the switches of the target DIP switch is in the ON state, then the number of retransmission detection bytes is determined to be 4KB. B; If only the fifth switch among all the switches of the target DIP switch is in the ON state, then the retransmission detection byte count is determined to be 5KB; if only the sixth switch among all the switches of the target DIP switch is in the ON state, then the retransmission detection byte count is determined to be 6KB; if only the seventh switch among all the switches of the target DIP switch is in the ON state, then the retransmission detection byte count is determined to be 7KB; if only the eighth switch among all the switches of the target DIP switch is in the ON state, then the retransmission detection byte count is determined to be 8KB; if all the switches of the target DIP switch are in the OFF state, then the retransmission detection byte count is determined to be 0.

[0042] Optionally, if the current program loading status is "pending loading," the target device 102 can determine the number of retransmission detection bytes based on the state of the target DIP switch set on the target device 102, add the number of retransmission detection bytes to the start loading command, and then feed the start loading command back to the source device 101 via the interrupt endpoint. If the current program loading status is "stopped loading," the target device 102 can feed the stop loading command back to the source device 101 via the interrupt endpoint. If the current program loading status is "loading in progress," the target device 102 can feed the loading in progress command back to the source device 101 via the interrupt endpoint.

[0043] Optionally, when the source device 101 receives the start load command from each target device 102 via an interrupt endpoint, it can determine that the relevant application needs to be loaded into each target device 102 simultaneously. Then, it performs program loading on each target device 102 concurrently: extracting the retransmission detection byte count from the start load command from each target device 102; establishing a connection with each target device 102 via handshake request and handshake response packets transmitted via block endpoints of each target device 102; transmitting the program code to be loaded to each target device 102 via start address request and write command packets transmitted via block endpoints of each target device 102; and detecting whether retransmission occurs during transmission via retransmission detection byte count, verification request, and verification response packets transmitted via block endpoints of each target device 102. After the transmission of the program code to be loaded is complete, it controls each target device 102 to run the program code to be loaded. The program code to be loaded is the program code of the relevant application. The relevant application is the application that the target device 102 needs to use during operation. The program code to be loaded is stored in the local flash memory of the source device 101. The local flash memory of source device 101 can be the flash memory configured in source device 101.

[0044] Optionally, after detecting the start loading commands fed back by each target device 102, the source device 101 extracts the retransmission detection byte count from the start loading commands fed back by each target device 102 in parallel, determines the establishment of a connection with each target device 102 through the handshake request packet and handshake response packet transmitted based on the block endpoint of each target device 102, and transmits the program code to be loaded to each target device 102 through the start address request packet and write command packet transmitted based on the block endpoint of each target device 102. During the transmission process, it detects whether to retransmit by using the retransmission detection byte count, verification request packet, and verification response packet transmitted based on the block endpoint of each target device 102. After the transmission process of the program code to be loaded is completed, it controls each target device 102 to run the program code to be loaded, including: the source device 101 performs the following operations in parallel for each target device 102: the source device 101 extracts the retransmission detection byte count from the start loading command fed back by the target device 102; the source device 101 sends a handshake request packet to the target device 102 through the block endpoint of the target device 102; the source device 101... After receiving the handshake response packet from the target device 102 via its block endpoint, the source device 101 determines that a connection has been established with the target device 102 and sends a start address request packet to the target device 102 via its block endpoint. After receiving the start address response packet from the target device 102 via its block endpoint, the source device 101 extracts the start address from the response packet. The source device 101 divides the program code to be loaded into multiple code segments. For each code segment, it encapsulates the code segment and related data into a data packet, resulting in multiple sequentially arranged write command packets. The source device 101 sends each write command packet corresponding to the target device 102 to the target device 102 sequentially via its block endpoint, according to the order of the write command packets. During transmission, it checks whether to retransmit the write command packets using the retransmission byte count, verification request packet, and verification response packet. After determining that all write command packets corresponding to the target device 102 have been sent, the source device 101 controls the target device 102 to run the program code to be loaded.

[0045] Optionally, source device 101 can extract the number of retransmission detection bytes from the start loading command fed back by target device 102. Source device 101 can send a handshake request packet to target device 102 through the block endpoint of target device 102. The handshake request packet may be a data packet that source device 101 sends to target device 102 to request confirmation of establishing a connection with target device 102 when it starts loading the program on target device 102. The handshake request packet contains handshake request packet type data, one's complement data of handshake request packet type data, handshake request packet length data, and preset operation address. The handshake request packet type data may be pre-set data used to identify the data packet type as a handshake request packet. The handshake request packet type data occupies 1 byte. The one's complement data of handshake request packet type data may refer to the one's complement of handshake request packet type data. The handshake request packet length data may be data used to identify the length of the entire handshake request packet in bytes. The preset operation address may be a pre-set data used to identify an address. The handshake request packet type data, the one's complement data of handshake request packet type data, the handshake request packet length data, and the preset operation address may be hexadecimal data. For example, the handshake request packet type data is 0x5a, the one's complement data of the handshake request packet type data is 0xa5, the handshake request packet length data is 0x06, and the preset operation address is 0x0000.

[0046] Optionally, after receiving the handshake request packet sent by the source device 101, the target device 102 will send a handshake response packet to the source device 101 through the block endpoint of the target device 102, thereby feeding back the handshake response packet to the source device 101 through the block endpoint of the target device 102. The handshake response packet can be a data packet used to confirm the establishment of a connection between the source device 101 and the target device 102. The handshake response packet includes handshake response packet type data, one's complement data of the handshake response packet type data, handshake response packet length data, and a preset operation address. The handshake response packet type data can be pre-set data used to identify the data packet type as a handshake response packet. The handshake response packet type data occupies 1 byte. The one's complement data of the handshake response packet type data can refer to the one's complement of the handshake response packet type data. The handshake response packet length data can be data used to indicate the length of the entire handshake response packet in bytes. The handshake response packet type data, the one's complement data of the handshake response packet type data, the handshake response packet length data, and the preset operation address can be hexadecimal data. For example, the handshake response packet type data is 0x5b, the one's complement data of the handshake response packet type data is 0xa4, the handshake response packet length data is 0x06, and the preset operation address is 0x0000.

[0047] Optionally, after receiving the handshake response packet from the target device 102 via its block endpoint, the source device 101 determines that a connection has been established with the target device 102, and then sends a start address request packet to the target device 102 via its block endpoint. The start address request packet can be a data packet used to request the start address of the target device 102. The start address of the target device 102 can be the address of a storage area set in the target device 102 for storing the code to be loaded. The address of the storage area can be a string used to identify the storage area. The start address request packet includes start address request packet type data, the inverse of the start address request packet type data, start address request packet length data, and a preset operation address. The start address request packet type data can be pre-set data used to characterize the data packet type as a start address request packet. The start address request packet type data occupies 1 byte. The inverse of the start address request packet type data can refer to the inverse of the start address request packet type data. The start address request packet length data can be data used to characterize the length of the entire start address request packet in bytes. The starting address request packet type data, the one's complement data of the starting address request packet type data, the starting address request packet length data, and the preset operation address can be hexadecimal data.

[0048] Optionally, after receiving the start address request packet sent by the source device 101, the target device 102 will send a start address response packet to the source device 101 through the block endpoint of the target device 102, thereby feeding back the start address response packet to the source device 101 through the block endpoint of the target device 102. The start address response packet can be a data packet used to transmit the start address. The start address response packet includes start address response packet type data, one's complement data of the start address response packet type data, start address response packet length data, a preset operation address, and the start address of the target device 102. The start address response packet type data can be pre-set data used to identify the data packet type as a start address response packet. The start address response packet type data occupies 1 byte. The one's complement data of the start address response packet type data can refer to the one's complement of the start address response packet type data. The start address response packet length data can be data used to identify the length of the entire start address response packet in bytes. The start address response packet type data, the one's complement data of the start address response packet type data, the start address response packet length data, the preset operation address, and the start address of the target device 102 can be hexadecimal data.

[0049] Optionally, after receiving the start address response packet from the target device 102 via the block endpoint of the target device 102, the source device 101 can extract the start address from the start address response packet and then divide the program code to be loaded into multiple code segments. The source device 101 can sequentially read a preset number of bytes of program code from the start position of the program code to be loaded in its local flash memory until the end position of the program code to be loaded in the local flash memory. Each preset number of bytes of program code read constitutes a code segment. The code segments are arranged in the order they are read. The first code segment read is placed first, and the last code segment read is placed last. The preset number of bytes can be a pre-set number of bytes. For example, the preset number of bytes is 1KB. If the number of bytes of the remaining program code is less than the preset number of bytes, the remaining program code is read, and this remaining program code is determined as a code segment, resulting in the last code segment. The number of bytes in the last code segment is less than the preset number of bytes. If the number of bytes of the remaining program code equals the preset number of bytes, then the remaining program code is read, and this remaining program code is identified as a code segment, resulting in the last code segment. The number of bytes in the last code segment equals the preset number of bytes. Thus, the program code to be loaded is divided into multiple code segments.

[0050] Optionally, for each code segment, the source device 101 can encapsulate the code segment and related data into a data packet to obtain a write command packet. The related data includes write command packet type data, the inverse of the write command packet type data, the number of bytes to be written in the code segment, and the write address of the code segment. The write command packet type data can be pre-set data used to identify the data packet type as a write command packet. The write command packet type data occupies 1 byte. The inverse of the write command packet type data can refer to the inverse of the write command packet type data. The number of bytes to be written in the code segment can refer to the number of bytes in the code segment. The write address of the code segment can refer to the starting address of the target device 102. Each write command packet contains write command packet type data, the inverse of the write command packet type data, the number of bytes to be written in the code segment, the write address of the code segment, and the code segment. The write command packets are arranged according to the order of the code segments within them. The write command packet containing the code segment read for the first time is placed first. The write command packet containing the code segment read for the last time is placed last. For example, the write command packet type data is 0x5e, and the one's complement data of the write command packet type data is 0xa1.

[0051] Optionally, source device 101 sends each write command packet corresponding to target device 102 to target device 102 sequentially through the block endpoint of target device 102 according to the order of the write command packets. During transmission, it checks whether to retransmit the write command packets by using the retransmission detection byte count, verification request packet, and verification response packet. This includes: if the retransmission detection byte count is not 0, source device 101 sends each write command packet corresponding to target device 102 to target device 102 sequentially through the block endpoint of target device 102 according to the order of the write command packets; source device 101 sends the write command packets to target device 102 each time it sends them to target device 102. After step 102, it checks whether the number of bytes of program code sent to target device 102 via write command packet is an integer multiple of the retransmission detection byte number. If the number of bytes of program code sent to target device 102 via write command packet is an integer multiple of the retransmission detection byte number, source device 101 checks whether to retransmit the write command packet via verification request packet and verification response packet. After determining whether to retransmit the write command packet or to complete the retransmission, it continues to send the next write command packet. If the number of bytes of program code sent to target device 102 via write command packet is not an integer multiple of the retransmission detection byte number, it continues to send the next write command packet.

[0052] Optionally, if the number of retransmission detection bytes is not 0, indicating that it is necessary to detect whether to retransmit write command packets during transmission, the source device 101 will send each write command packet to the target device 102 sequentially through the block endpoint of the target device 102, starting from the first write command packet in the queue, until the last write command packet in the queue is sent to the target device 102. The number of bytes of program code already sent to the target device 102 via write command packets can refer to the sum of the number of bytes of the code segments contained in each write command packet already sent to the target device 102. The source device 101 can check whether the number of bytes of program code already sent to the target device 102 via write command packets is an integer multiple of the number of retransmission detection bytes after each write command packet is sent to the target device 102. If the number of bytes of program code already sent to target device 102 via write command packets is an integer multiple of the retransmission detection byte count, source device 101 checks whether to retransmit the write command packet using a verification request packet and a verification response packet. If it determines that write command packet retransmission is not necessary or that retransmission is complete, it continues to send the next write command packet. If the number of bytes of program code already sent to target device 102 via write command packets is not an integer multiple of the retransmission detection byte count, it continues to send the next write command packet.

[0053] Optionally, the source device 101 detects whether to retransmit the write command packet through a verification request packet and a verification response packet. After determining that the write command packet should not be retransmitted or that the write command packet retransmission is completed, the source device 101 continues to send the next write command packet. This includes: the source device 101 sending a verification request packet to the target device 102 through the block endpoint of the target device 102; wherein the verification request packet contains verification data; after receiving the verification response packet fed back by the target device 102 through the block endpoint of the target device 102, the source device 101 determines whether the checksum of the verification data in the local flash memory is consistent with the checksum of the verification data in the verification response packet; if the checksum of the verification data in the local flash memory is consistent with the checksum of the verification data in the verification response packet, the source device 101 determines that the write command packet should not be retransmitted; the source device 101 continues to send the next write command packet to the target device 102 through the block endpoint of the target device 102 until all write command packets are transmitted.

[0054] Optionally, the checksum can be a pre-set hexadecimal data. The checksum of the checksum is the value obtained by adding each bit of the checksum in hexadecimal. For example, the checksum is 0x1102130405160708, and the checksum is 0x27. The checksum and checksum of the checksum are stored in the local flash memory of the source device 101. The checksum of the checksum stored in the local flash memory of the source device 101 is the correct checksum. The source device 101 can send a check request packet to the target device 102 through the block endpoint of the target device 102. The check request packet can be a data packet used to transmit checksum. The check request packet includes check request packet type data, check request packet type data inverse, check request packet length data, and checksum. The check request packet type data can be pre-set data used to identify the type of the data packet as a check request packet. The check request packet type data occupies 1 byte. The checksum of the check request packet type data can refer to the inverse of the check request packet type data. The verification request packet length data can be data that represents the length of bytes occupied by the entire verification request packet. For example, the verification request packet type data is 0x6a, and the one's complement data of the verification request packet type data is 0x95.

[0055] Optionally, after receiving the verification request packet sent by the source device 101, the target device 102 extracts the verification data from the verification request packet, calculates the checksum of the verification data, and encapsulates the verification response packet type data, the one's complement data of the verification response packet type data, the length data of the verification response packet, the sequence number of the verification data, and the calculated checksum of the verification data into a data packet to obtain a verification response packet. The verification response packet can be a data packet used to transmit the checksum of the verification data. The verification response packet type data can be pre-set data used to identify the data packet type as a verification response packet. The verification response packet type data occupies 1 byte. The one's complement data of the verification response packet type data can refer to the one's complement of the verification response packet type data. The verification response packet length data can be data used to identify the length of the entire verification response packet in bytes. The sequence number of the verification data can be a numerical number corresponding to the verification data. The verification response packet contains the verification response packet type data, the one's complement data of the verification response packet type data, the length data of the verification response packet, the sequence number of the verification data, and the checksum of the verification data calculated by the target device 102. For example, the verification response packet type data is 0x6b, and the one's complement data of the verification response packet type data is 0x98. The target device 102 can send the verification response packet to the source device 101 through the block endpoint of the target device 102, thereby sending back the verification response packet to the source device 101 through the block endpoint of the target device 102.

[0056] Optionally, after receiving the verification response packet from the target device 102 via the block endpoint of the target device 102, the source device 101 determines whether the checksum of the verification data in its local flash memory matches the checksum of the verification data in the verification response packet. If the checksum of the verification data in its local flash memory matches the checksum of the verification data in the verification response packet, it indicates that there is no abnormality in the data transmission process between the source device 101 and the target device 102, and there is no need to retransmit the previous write command packet. Therefore, the source device 101 determines not to retransmit the write command packet. After determining not to retransmit the write command packet, the source device 101 continues to send the next write command packet to the target device 102 via the block endpoint of the target device 102 until all write command packets have been transmitted.

[0057] Optionally, the source device 101 checks whether to retransmit the write command packet using a verification request packet and a verification response packet. After determining that the write command packet should not be retransmitted or that the write command packet retransmission is completed, it continues to send the next write command packet. The method further includes: if the checksum of the verification data in the local flash memory is inconsistent with the checksum of the verification data in the verification response packet, the source device 101 determines to retransmit the write command packet and resends the previous write command packet to the target device 102 through the block endpoint of the target device 102. The source device 101 checks whether to retransmit the write command packet using a verification request packet and a verification response packet until it is determined that the write command packet should not be retransmitted. The source device 101 continues to send the next write command packet to the target device 102 through the block endpoint of the target device 102 until all write command packets have been transmitted.

[0058] Optionally, if the checksum of the verification data in the local flash memory is inconsistent with the checksum of the verification data in the verification response packet, indicating an anomaly in the data transmission process between the source device 101 and the target device 102, and requiring retransmission of the previous write command packet, then the source device 101 determines to retransmit the write command packet, resends the previous write command packet to the target device 102 through the block endpoint of the target device 102, and checks whether to retransmit the write command packet after retransmission using a verification request packet and a verification response packet. If it is still determined to retransmit the write command packet, then the previous write command packet is resent to the target device 102 through the block endpoint of the target device 102, and checks whether to retransmit the write command packet after retransmission using a verification request packet and a verification response packet, until it is determined not to retransmit the write command packet. After determining not to retransmit the write command packet, the source device 101 continues to send the next write command packet to the target device 102 through the block endpoint of the target device 102, until all write command packets are transmitted.

[0059] Optionally, the source device 101 sends each write command packet corresponding to the target device 102 to the target device 102 sequentially through the block endpoint of the target device 102 according to the order of the write command packets. During transmission, the source device 101 checks whether to retransmit the write command packets using the retransmission detection byte count, verification request packet, and verification response packet. The method further includes: if the retransmission detection byte count is 0, the source device 101 sends each write command packet corresponding to the target device 102 to the target device 102 sequentially through the block endpoint of the target device 102 according to the order of the write command packets. If the retransmission detection byte count is 0, it indicates that there is no need to check whether to retransmit the write command packets during transmission. In this case, the source device 101 will start with the first write command packet and send each write command packet to the target device 102 sequentially through the block endpoint of the target device 102 until the last write command packet is sent to the target device 102.

[0060] Optionally, after the source device 101 determines that each write command packet corresponding to the target device 102 has been sent, it controls the target device 102 to run the program code to be loaded. This includes: after the source device 101 determines that each write command packet has been transmitted, it sends a jump instruction packet to the target device 102 through the block endpoint of the target device 102, so that the target device 102 runs the program code to be loaded according to the jump instruction packet.

[0061] Optionally, if the number of retransmission detection bytes is not 0, then after sending the last write command packet to the target device 102, and if the number of bytes of program code sent to the target device 102 via the write command packet is not an integer multiple of the number of retransmission detection bytes or no retransmission of the write command packet is performed, the source device 101 determines that the transmission of each write command packet is complete. If the number of retransmission detection bytes is 0, then after sending the last write command packet to the target device 102, the source device 101 determines that the transmission of each write command packet is complete.

[0062] Optionally, after receiving each write command packet, the target device 102 can extract the code segment from each write command packet and sequentially write each code segment into the storage area set in the target device 102 for storing the program code to be loaded. After the transmission of each write command packet is completed, the storage area set in the target device 102 for storing the program code to be loaded will contain the complete program code to be loaded.

[0063] Optionally, source device 101 can encapsulate jump instruction packet type data, the inverse of jump instruction packet type data, jump instruction packet length data, and the starting address of target device 102 into a data packet to obtain a jump instruction packet. The jump instruction packet can be a data packet used to instruct target device 102 to run the program code to be loaded. The jump instruction packet type data can be pre-set data used to identify the data packet type as a jump instruction packet. The jump instruction packet type data occupies 1 byte. The inverse of jump instruction packet type data can refer to the inverse of the jump instruction packet type data. The jump instruction packet length data can be data used to identify the length of bytes occupied by the entire jump instruction packet. The jump instruction packet contains jump instruction packet type data, the inverse of jump instruction packet type data, jump instruction packet length data, and the starting address of target device 102. For example, the jump instruction packet type data is 0x5f, and the inverse of the verification response packet type data is 0xa0. Source device 101 can send the jump instruction packet to target device 102 through the block endpoint of target device 102. After receiving the jump instruction packet, the target device 102 can determine the storage area set in the target device 102 for storing the program code to be loaded according to the starting address in the jump instruction packet, and run the program code to be loaded in the storage area.

[0064] Optionally, after receiving the stop loading command fed back by each target device 102 through the interrupt endpoint, the source device 101 continues to periodically send the program loading query command to each target device 102 through the interrupt endpoint of each target device 102.

[0065] Optionally, after receiving the loading command from each target device 102 via the interrupt endpoint, the source device 101 stops periodically sending the program loading query command to each target device 102 via the interrupt endpoint of each target device 102.

[0066] In the technical solution of this invention embodiment, the source device periodically sends program loading query instructions to each target device through the interrupt endpoints of each target device. Upon receiving the program loading query instructions, each target device determines its current program loading status and feeds back status representation information corresponding to the current program loading status to the source device through its interrupt endpoints. This status representation information includes a stop loading command, a start loading command, or a loading command. After receiving the start loading commands from each target device through its interrupt endpoints, the source device extracts the number of retransmission detection bytes from the start loading commands fed back by each target device in parallel. It then determines the establishment of a connection with each target device through handshake request packets and handshake response packets transmitted based on the block endpoints of each target device, and sends the program to be loaded to the target device through start address request packets and write command packets transmitted based on the block endpoints of each target device. The program code is transmitted to various target devices. During transmission, retransmission is detected based on the number of bytes transmitted via the block endpoints of each target device, as well as verification request packets and verification response packets. After the transmission of the program code to be loaded is completed, each target device is controlled to run the program code. This solves the problem that related program loading schemes cannot simultaneously load related applications onto various electronic devices, resulting in low efficiency and intelligence in the program loading process. Based on the information transmitted via the interrupt endpoints and block endpoints of the electronic devices that need to load related applications, the program can intelligently load related applications onto multiple electronic devices simultaneously, improving the efficiency and intelligence of the program loading process. Retransmission can be detected based on verification request packets and verification response packets, thereby maximizing the verification of the correctness of program data while ensuring program loading efficiency.

[0067] Optional, Figure 2This is a schematic diagram of a target device provided in Embodiment 1 of the present invention. The target device includes external devices, memory, a processor, flash memory, a bootloader, and a data transmission module. The external devices, memory, processor, and flash memory are interconnected via a bus. External devices may refer to a display screen, keyboard, etc. Memory may refer to a read-only memory, random access memory, etc. The processor may refer to a central processing unit (CPU). The data transmission module may refer to a hardware module and a software module provided in the target device for sending or receiving data via the target device's USB interface. The data transmission module may include a controller and a port physical layer for sending or receiving data via the target device's USB interface. The target device can execute various operations during the program loading process through the bootloader.

[0068] Optional, Figure 3 This is a schematic diagram of a source device according to Embodiment 1 of the present invention. The source device includes memory, a processor, flash memory, and a data transmission module. The memory, processor, and flash memory are interconnected via a bus. Memory can refer to read-only memory, random access memory, etc. The processor can refer to a central processing unit (CPU). The data transmission module can refer to the hardware and software modules provided in the source device for sending or receiving data via the source device's USB interface. The data transmission module can include a controller and a port physical layer for sending or receiving data via the source device's USB interface.

[0069] Optional, Figure 4 This is a schematic diagram of a program loading system based on a USB interface according to Embodiment 1 of the present invention. The source device extends N USB interfaces via a USB hub: USB interface 1, USB interface 2, USB interface 3...USB interface N. The N target devices are: target device 1, target device 2, target device 3...target device N. The N USB interfaces extended by the source device are respectively connected to the USB interfaces of the N target devices, with each extended USB interface connected to the USB interface of one target device. USB interface 1 is connected to the USB interface of target device 1. USB interface 2 is connected to the USB interface of target device 2. USB interface 3 is connected to the USB interface of target device 3. And so on, with USB interface N connected to the USB interface of target device N.

[0070] Example 2

[0071] Figure 5 This is a flowchart illustrating a program loading method based on a USB interface, as provided in Embodiment 2 of the present invention. This method can be executed by the USB interface-based program loading system provided in the above embodiments of the present invention. Figure 5 As shown, the method includes:

[0072] Step 201: The source device periodically sends the program loading query command to each target device through the interrupt endpoint of each target device.

[0073] Step 202: After receiving the program loading query instruction, each target device determines the current program loading status and feeds back the status representation information corresponding to the current program loading status to the source device through the interrupt endpoint of each target device.

[0074] The status representation information includes a stop loading command, a start loading command, or a loading command.

[0075] Optionally, after receiving the program loading query instruction, each target device determines its current program loading status and feeds back the status representation information corresponding to the current program loading status to the source device through its interrupt endpoint. This includes: after receiving the program loading query instruction, each target device performs the following operations: the target device determines its current program loading status based on the status of the target button set on the target device and the data already received by the target device; if the current program loading status is "pending loading", the target device determines the number of retransmission detection bytes based on the status of the target DIP switch set on the target device, adds the number of retransmission detection bytes to the start loading command, and feeds back the start loading command to the source device through its interrupt endpoint; if the current program loading status is "stop loading", the target device feeds back the stop loading command to the source device through its interrupt endpoint; if the current program loading status is "loading", the target device feeds back the loading command to the source device through its interrupt endpoint.

[0076] Step 203: After receiving the start loading command from each target device via the interrupt endpoint, the source device extracts the retransmission detection byte count from the start loading command from each target device in parallel. It determines the establishment of a connection with each target device by transmitting the handshake request packet and handshake response packet based on the block endpoint of each target device. It transmits the program code to be loaded to each target device by transmitting the start address request packet and write command packet based on the block endpoint of each target device. During the transmission process, it detects whether to retransmit by transmitting the retransmission detection byte count, verification request packet, and verification response packet based on the block endpoint of each target device. After the transmission process of the program code to be loaded is completed, it controls each target device to run the program code to be loaded.

[0077] Optionally, after receiving the start loading command from each target device via its interrupt endpoint, the source device extracts the retransmission detection byte count from the start loading command from each target device in parallel. It then establishes a connection with each target device using handshake request packets and handshake response packets transmitted via the block endpoints of each target device. Finally, it transmits the program code to be loaded to each target device using start address request packets and write command packets transmitted via the block endpoints of each target device. During transmission, it checks for retransmissions using the retransmission detection byte count, verification request packets, and verification response packets transmitted via the block endpoints of each target device. After the transmission of the program code to be loaded is complete, it controls each target device to run the program code to be loaded. This includes: the source device performing the following operations in parallel for each target device: the source device extracts the retransmission detection byte count from the start loading command from the target device; the source device sends a handshake request packet to the target device via the block endpoint of the target device; and the source device, upon receiving the handshake request packet from the target device... After receiving the handshake response packet from the target device's block endpoint, the source device determines that a connection has been established with the target device and sends a start address request packet to the target device through the target device's block endpoint. Upon receiving the start address response packet from the target device through its block endpoint, the source device extracts the start address from the response packet. The source device divides the program code to be loaded into multiple code segments, and for each code segment, encapsulates the code segment and related data into a data packet, resulting in multiple sequentially arranged write command packets. The source device sends each write command packet corresponding to the target device to the target device sequentially through the target device's block endpoint according to the order of the write command packets, and during transmission, detects whether to retransmit the write command packets by checking the retransmission byte count, verification request packets, and verification response packets. After determining that all write command packets corresponding to the target device have been sent, the source device controls the target device to run the program code to be loaded.

[0078] Optionally, the source device sends each write command packet corresponding to the target device to the target device sequentially through the block endpoint of the target device according to the order of the write command packets. During transmission, the source device detects whether to retransmit the write command packets by using the retransmission detection byte count, the check request packet, and the check response packet. This includes: if the retransmission detection byte count is not 0, the source device sends each write command packet corresponding to the target device to the target device sequentially through the block endpoint of the target device according to the order of the write command packets. Each time the source device sends a write command packet to the target device... Next, it checks whether the number of bytes of program code already sent to the target device via the write command packet is an integer multiple of the retransmission detection byte count. If the number of bytes of program code already sent to the target device via the write command packet is an integer multiple of the retransmission detection byte count, the source device checks whether to retransmit the write command packet via a verification request packet and a verification response packet. After determining whether to retransmit the write command packet or to complete the retransmission, it continues to send the next write command packet. If the number of bytes of program code already sent to the target device via the write command packet is not an integer multiple of the retransmission detection byte count, it continues to send the next write command packet.

[0079] Optionally, the source device detects whether to retransmit the write command packet through a verification request packet and a verification response packet. After determining that the write command packet should not be retransmitted or that the write command packet retransmission is completed, it continues to send the next write command packet. This includes: the source device sending a verification request packet to the target device through the block endpoint of the target device; wherein, the verification request packet contains verification data; after receiving the verification response packet fed back by the target device through the block endpoint of the target device, the source device determines whether the checksum of the verification data in the local flash memory is consistent with the checksum of the verification data in the verification response packet; if the checksum of the verification data in the local flash memory is consistent with the checksum of the verification data in the verification response packet, the source device determines not to retransmit the write command packet; the source device continues to send the next write command packet to the target device through the block endpoint of the target device until all write command packets are transmitted.

[0080] Optionally, the source device detects whether to retransmit the write command packet through a verification request packet and a verification response packet. After determining that the write command packet should not be retransmitted or that the write command packet retransmission is completed, it continues to send the next write command packet. The method further includes: if the checksum of the verification data in the local flash memory is inconsistent with the checksum of the verification data in the verification response packet, the source device determines to retransmit the write command packet, resends the previous write command packet to the target device through the block endpoint of the target device, and detects whether to retransmit the write command packet through a verification request packet and a verification response packet until it is determined that the write command packet should not be retransmitted; the source device continues to send the next write command packet to the target device through the block endpoint of the target device until all write command packets have been transmitted.

[0081] Optionally, the source device sends each write command packet corresponding to the target device to the target device sequentially through the block endpoint of the target device according to the arrangement order of each write command packet, and detects whether to retransmit the write command packet during the transmission process by the retransmission detection byte count, the verification request packet and the verification response packet. The method further includes: if the retransmission detection byte count is 0, then the source device sends each write command packet corresponding to the target device to the target device sequentially through the block endpoint of the target device according to the arrangement order of each write command packet.

[0082] Optionally, after the source device determines that each write command packet corresponding to the target device has been sent, it controls the target device to run the program code to be loaded, including: after the source device determines that each write command packet has been transmitted, it sends a jump instruction packet to the target device through the block endpoint of the target device, so that the target device runs the program code to be loaded according to the jump instruction packet.

[0083] Optionally, after receiving the stop loading command from each target device via the interrupt endpoint, the source device continues to periodically send program loading query commands to each target device via the interrupt endpoint of each target device.

[0084] Optionally, after receiving the loading command from each target device via the interrupt endpoint, the source device stops periodically sending program loading query commands to each target device via the interrupt endpoint.

[0085] In the technical solution of this invention embodiment, the source device periodically sends program loading query instructions to each target device through the interrupt endpoints of each target device. Upon receiving the program loading query instructions, each target device determines its current program loading status and feeds back status representation information corresponding to the current program loading status to the source device through its interrupt endpoints. This status representation information includes a stop loading command, a start loading command, or a loading command. After receiving the start loading commands from each target device through its interrupt endpoints, the source device extracts the number of retransmission detection bytes from the start loading commands fed back by each target device in parallel. It then determines the establishment of a connection with each target device through handshake request packets and handshake response packets transmitted based on the block endpoints of each target device, and sends the program to be loaded to the target device through start address request packets and write command packets transmitted based on the block endpoints of each target device. The program code is transmitted to various target devices. During transmission, retransmission is detected based on the number of bytes transmitted via the block endpoints of each target device, as well as verification request packets and verification response packets. After the transmission of the program code to be loaded is completed, each target device is controlled to run the program code. This solves the problem that related program loading schemes cannot simultaneously load related applications onto various electronic devices, resulting in low efficiency and intelligence in the program loading process. Based on the information transmitted via the interrupt endpoints and block endpoints of the electronic devices that need to load related applications, the program can intelligently load related applications onto multiple electronic devices simultaneously, improving the efficiency and intelligence of the program loading process. Retransmission can be detected based on verification request packets and verification response packets, thereby maximizing the verification of the correctness of program data while ensuring program loading efficiency.

[0086] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0087] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A program loading system based on a USB interface, characterized by comprising: The method comprises the following steps: a source device and N target devices are connected through USB interfaces; each target device comprises a block endpoint and an interrupt endpoint; the source device sends a program loading query instruction to each target device through the interrupt endpoint of each target device; after receiving the program loading query instruction, each target device determines the program loading state at the current time, and feeds back state representation information corresponding to the program loading state at the current time to the source device through the interrupt endpoint of each target device; the state representation information is a stop loading command, a start loading command or a loading command; after receiving the start loading command fed back by each target device through the interrupt endpoint, the source device extracts the retransmission detection byte number in the start loading command fed back by each target device in parallel, establishes a connection with each target device through handshake request packets and handshake response packets transmitted based on the block endpoint of each target device, transmits the to-be-loaded program code to each target device through start address request packets and write command packets transmitted based on the block endpoint of each target device, detects whether retransmission is performed through the retransmission detection byte number, a check request packet and a check response packet in the transmission process, and controls each target device to run the to-be-loaded program code after the transmission process of the to-be-loaded program code is completed; the source device performs the following operations on each target device in parallel: the source device extracts the retransmission detection byte number in the start loading command fed back by the target device, the retransmission detection byte number is a byte number required when detecting whether retransmission is performed in the transmission process of the to-be-loaded program code to the target device; the source device sends a handshake request packet to the target device through the block endpoint of the target device; after receiving the handshake response packet fed back by the target device through the block endpoint of the target device, the source device establishes a connection with the target device, and sends a start address request packet to the target device through the block endpoint of the target device; after receiving the start address response packet fed back by the target device through the block endpoint of the target device, the source device extracts the start address in the start address response packet; the source device divides the to-be-loaded program code into a plurality of code segments, encapsulates each code segment and code segment related data into a data packet to obtain a plurality of sequentially arranged write command packets; the source device sends each write command packet corresponding to the target device to the target device through the block endpoint of the target device in sequence according to the arrangement order of each write command packet, and detects whether write command packet retransmission is performed through the retransmission detection byte number, the check request packet and the check response packet in the transmission process; after determining that each write command packet corresponding to the target device is sent, the source device controls the target device to run the to-be-loaded program code. The source device sends each write command package corresponding to the target device to the target device through the block endpoint of the target device in the arrangement order of each write command package, and detects whether to perform write command package retransmission through the retransmission detection byte number, the check request package and the check response package during transmission, comprising: if the retransmission detection byte number is not 0, the source device sends each write command package corresponding to the target device to the target device through the block endpoint of the target device in the arrangement order of each write command package; the source device detects whether the byte number of the program code that has been sent to the target device through the write command package is an integer multiple of the retransmission detection byte number after sending the write command package to the target device each time; if the byte number of the program code that has been sent to the target device through the write command package is an integer multiple of the retransmission detection byte number, the source device detects whether to perform write command package retransmission through the check request package and the check response package, and continues to send the next write command package after determining not to perform write command package retransmission or completing write command package retransmission; if the byte number of the program code that has been sent to the target device through the write command package is not an integer multiple of the retransmission detection byte number, the next write command package is continued to be sent.

2. The USB interface based program loading system according to claim 1, wherein, The source device is a portable device, and the target device is a development board.

3. A program loading method based on a USB interface, applied to the program loading system based on the USB interface as claimed in claim 1, characterized in that, Comprising: The source device sends a program loading query instruction to each target device through the interrupt endpoint of each target device; After receiving the program loading query instruction, each target device determines the program loading state at the current time, and feeds back state representation information corresponding to the program loading state at the current time to the source device through the interrupt endpoint of each target device; wherein the state representation information is a stop loading command, a start loading command or a loading command; The source device extracts the retransmission detection byte number in the start loading command fed back by each target device after receiving the start loading command, establishes a connection with each target device based on the handshake request packet and the handshake response packet transmitted by the block endpoint of each target device, transmits the to-be-loaded program code to each target device based on the start address request packet and the write command packet transmitted by the block endpoint of each target device, detects whether retransmission is performed in the transmission process by using the retransmission detection byte number, the check request packet and the check response packet, and controls each target device to run the to-be-loaded program code after the transmission process of the to-be-loaded program code is completed; wherein the source device performs the following operations on each target device in parallel: the source device extracts the retransmission detection byte number in the start loading command fed back by the target device, which is the number of bytes needed to be used when detecting whether retransmission is performed in the transmission process of the to-be-loaded program code to the target device; the source device sends a handshake request packet to the target device through the block endpoint of the target device; the source device establishes a connection with the target device after receiving the handshake response packet fed back by the target device through the block endpoint of the target device, sends a start address request packet to the target device through the block endpoint of the target device; the source device extracts the start address in the start address response packet after receiving the start address response packet fed back by the target device through the block endpoint of the target device; the source device divides the to-be-loaded program code into multiple code segments, encapsulates each code segment and code segment related data into a data packet to obtain multiple sequentially arranged write command packets; the source device sends each write command packet corresponding to the target device to the target device through the block endpoint of the target device in sequence according to the arrangement order of each write command packet, and detects whether write command packet retransmission is performed in the transmission process by using the retransmission detection byte number, the check request packet and the check response packet; the source device controls the target device to run the to-be-loaded program code after determining that each write command packet corresponding to the target device is sent. The source device sends each write command package corresponding to the target device to the target device through the block endpoint of the target device in the arrangement order of the write command packages, and detects whether to perform write command package retransmission through the retransmission detection byte number, the check request package and the check response package during transmission, comprising: if the retransmission detection byte number is not 0, the source device sends each write command package corresponding to the target device to the target device through the block endpoint of the target device in the arrangement order of the write command packages; the source device detects whether the byte number of the program code sent to the target device through the write command package is an integer multiple of the retransmission detection byte number after sending the write command package to the target device each time; if the byte number of the program code sent to the target device through the write command package is an integer multiple of the retransmission detection byte number, the source device detects whether to perform write command package retransmission through the check request package and the check response package, and continues to send the next write command package after determining not to perform write command package retransmission or completing write command package retransmission; if the byte number of the program code sent to the target device through the write command package is not an integer multiple of the retransmission detection byte number, the next write command package is continuously sent.

4. The program load method based on the USB interface according to claim 3, characterized in that, Each target device determines the program loading state at the current time after receiving the program loading query instruction, and feeds back state representation information corresponding to the program loading state at the current time to the source device through the interrupt endpoint of each target device, comprising: Each target device performs the following operations after receiving the program loading query instruction: The target device determines the program loading state at the current time according to the state of the target button arranged on the target device and the data received by the target device; If the program loading state at the current time is to be started to load, the target device determines the retransmission detection byte number according to the state of the target dial switch arranged on the target device, adds the retransmission detection byte number into the start loading command, and feeds back the start loading command to the source device through the interrupt endpoint; If the program loading state at the current time is to stop loading, the target device feeds back the stop loading command to the source device through the interrupt endpoint; If the program loading state at the current time is to be loaded, the target device feeds back the loading command to the source device through the interrupt endpoint.

5. The USB interface based program loading method according to claim 3, wherein, The source device detects whether to perform write command package retransmission through the check request package and the check response package, and continues to send the next write command package after determining not to perform write command package retransmission or completing write command package retransmission, comprising: The source device sends the check request package to the target device through the block endpoint of the target device; wherein the check request package contains check data; The source device judges whether the checksum of the check data in the local flash memory is consistent with the checksum of the check data in the check response package after receiving the check response package fed back by the target device through the block endpoint of the target device; If the checksum of the check data in the local flash memory is consistent with the checksum of the check data in the check response packet, the source device determines not to perform write command packet retransmission; The source device continues to send the next write command packet to the target device through the block endpoint of the target device until all write command packets are transmitted.

6. The program load method based on the USB interface according to claim 5, characterized in that, The source device detects whether to perform write command packet retransmission through the check request packet and the check response packet, and continues to send the next write command packet after determining not to perform write command packet retransmission or completing write command packet retransmission, and further comprises: If the checksum of the check data in the local flash memory is inconsistent with the checksum of the check data in the check response packet, the source device determines to perform write command packet retransmission, re-sends the last write command packet to the target device through the block endpoint of the target device, detects whether to perform write command packet retransmission through the check request packet and the check response packet, and determines not to perform write command packet retransmission until the end. The source device continues to send the next write command packet to the target device through the block endpoint of the target device until all write command packets are transmitted.

7. The USB interface based program loading method according to claim 3, wherein, The source device sends each write command packet corresponding to the target device to the target device through the block endpoint of the target device in the arrangement order of the write command packets, and detects whether to perform write command packet retransmission through the retransmission detection byte number, the check request packet and the check response packet during transmission, and further comprises: If the retransmission detection byte number is 0, the source device sends each write command packet corresponding to the target device to the target device through the block endpoint of the target device in the arrangement order of the write command packets.

8. The USB interface based program loading method according to claim 3, wherein, The source device controls the target device to run the to-be-loaded program code after determining that each write command packet corresponding to the target device is sent. The source device sends a jump instruction packet to the target device through the block endpoint of the target device after determining that each write command packet is transmitted, so that the target device runs the to-be-loaded program code according to the jump instruction packet.

Citation Information

Patent Citations

  • A method for detecting the loading integrity of a USB slave device driver

    CN109901960A

  • Communication method and device of USB protocol, storage medium and USB host

    CN120144518A