A class driver re-enumeration method for USB orphan devices in embedded systems

Abstract

This invention discloses a class driver re-enumeration method for USB orphan devices in embedded systems. The method checks and traverses all USB orphan devices already recognized by the USB protocol stack in the system, combines a timeout retry mechanism, and calls the corresponding driver binding processing function, enabling the operating system to re-enumerate and bind the devices. This invention does not require modification of the operating system's USB protocol stack and USB class driver code; it only creates an external dynamically loadable program to implement re-enumeration. It also provides a configuration mechanism for the number of retries and the time interval, allowing the system to minimize the probability of orphan devices appearing in complex environments, thereby improving the management efficiency of various USB peripherals in embedded platforms and the overall system reliability.

Description

Technical Field

[0001] This invention belongs to the field of computer operating systems and embedded systems technology, and in particular relates to a class driver re-enumeration method for USB orphan devices in embedded systems. Background Technology

[0002] In modern computer systems, USB (Universal Serial Bus) devices are widely used for connecting various peripherals due to their plug-and-play nature. However, in complex electromagnetic environments using embedded devices and USB peripherals, USB devices may fail to be correctly recognized during the initialization enumeration process for various reasons. This can be roughly divided into two stages. The first stage involves a handshake between the USB system software (USB protocol stack) and the device. If a problem occurs in this stage, the device will be discarded by the USB system software. The second stage involves the USB protocol stack handing over the process to the USB class-specific driver for further handshake. This process can also fail, leading to device enumeration failure. If the second stage fails, the device becomes an "orphan device" (not bound to a class driver). In Linux-like systems, the protocol stack usually has a relatively complete retry mechanism, which can largely complete the device enumeration process (however, in extreme cases, the system software may still indicate device connection cable, electromagnetic compatibility, or other abnormalities).

[0003] Domestically developed embedded operating systems such as DeltaOS, ACoreOS, and JARI-Works are widely used in aerospace, industrial control, and other fields with high requirements for stability and real-time performance. In these fields, the stability of peripheral devices directly affects the reliability of the entire system. However, due to hardware compatibility, USB protocol stack implementation (the USB protocol stack in these operating systems is lightweight system software, and its functionality and robustness cannot reach the level of desktop-level system USB protocol stacks), and USB device firmware issues, USB devices may fail to be correctly enumerated and bound to the corresponding drivers after connection or restart, thus becoming orphan devices. Due to the lack of an effective retry mechanism, once a device becomes an orphan, even if the physical connection is normal, the operating system cannot recognize and use these devices, affecting the normal operation of the system. This remains an unresolved technical problem in systems with high requirements for real-time performance and reliable human-computer interaction. Summary of the Invention

[0004] The purpose of this invention is to provide a class driver re-enumeration method for USB orphan devices in embedded systems.

[0005] To achieve the objective of this invention, a class driver re-enumeration method for USB orphan devices in an embedded system is provided, comprising the following steps:

[0006] Step 1: Based on the configuration information of the USB devices on the embedded system hardware platform, determine the number of different types of hardware configurations for the USB devices and pass them to the USB orphan device re-enumeration detection program.

[0007] Step 2: For the type of USB device, based on the class driver name, traverse the linked list of enumerated connection processing function pointers of the registered USB protocol stack to determine the corresponding re-enumerated connection processing function pointer for the type.

[0008] Step 3: Within the orphan device re-enumeration detection program, check the number of USB character devices created by the USB device at the operating system I / O layer; if it does not match the number of devices in the hardware configuration, check whether the missing device is in an orphan device state and re-enumerate as appropriate; if it matches, exit the re-enumeration program.

[0009] Step 4: Obtain the number of USB host controllers in the system through the interface of the USB protocol stack, and traverse the root hub and ordinary hubs under the USB host controller. For the non-hub USB devices found, call the operating system USB protocol stack device information query interface through its node number to obtain and store the basic information of the USB device.

[0010] Step 5: If the basic information of the USB device shows that a non-hub type device is bound to a USB class driver, then skip the non-hub type device; for devices that are not bound to a USB class driver in the basic information of the USB device, the non-hub type device is an orphan device. Obtain the USB interface information temporarily stored for the orphan device in the USB protocol stack, find the class driver that matches the USB interface information, and call the connection callback function of the class driver to try to rebind the orphan device to its corresponding class driver.

[0011] Step 6: After traversing all USB devices in all topologies under all USB host controllers, perform a certain delay and then determine if there are still retries. If yes, then re-enter step 3; otherwise, exit the re-enumeration program.

[0012] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the program, implements the above-described class-driven re-enumeration method for an embedded system USB orphan device.

[0013] A non-transitory computer-readable storage medium, characterized in that the non-transitory computer-readable storage medium stores computer instructions, the computer instructions being used to cause the computer to execute the above-described class driver re-enumeration method for an embedded system USB orphan device.

[0014] A computer program product includes computer program instructions, characterized in that, when the computer program instructions are run on a computer, the computer executes the above-described class driver re-enumeration method for an embedded system USB orphan device.

[0015] Compared with the prior art, the significant advancements of this invention are: (1) This invention does not require modification of the USB protocol stack code of the embedded operating system, nor does it require modification of any code of the already developed USB class device driver. Instead, it only requires the construction of a separate external dynamically loadable program to implement re-enumeration, and also provides a configuration mechanism for the number of retries and time intervals, so that the system can minimize the probability of orphan devices in complex field environments, improve the stability and availability of the USB subsystem of the embedded system, and avoid potential problems caused by incorrect device binding; (2) This invention has strong versatility and meets the software development and operation requirements such as software reusability, versatility, and adaptability. This improves the management efficiency of various USB peripherals in the embedded platform and the overall reliability of the system.

[0016] To more clearly illustrate the functional characteristics and structural parameters of the present invention, further explanation is provided below in conjunction with the accompanying drawings and specific embodiments. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0018] Figure 1 This is a flowchart of the orphan device re-enumeration process based on class-driven rebinding of the present invention;

[0019] Figure 2 This invention is for finding the USB class driver pointer registered in the USB protocol stack for each type of device;

[0020] Figure 3 This is a flowchart of the recursive USB bus search for orphan devices and the re-enumeration process of the present invention;

[0021] Figure 4 This is a diagram showing the results of the orphan device detection and class-driven re-enumeration operation of the present invention. Detailed Implementation

[0022] 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 are within the scope of protection of the present invention.

[0023] The present invention provides a class driver re-enumeration method for USB orphan devices in an embedded system, characterized in that it combines... Figure 1 This includes the following steps:

[0024] Step 1: Based on the configuration information of the USB devices on the embedded system hardware platform and the class driver name information of each type of USB device, determine the number of hardware configurations for different categories of USB devices and pass them to the USB orphan device re-enumeration detection program.

[0025] Step 1-1: After the embedded system USB subsystem is initialized and before the application software of the USB device is initialized, insert the dynamically loaded and executed software module.

[0026] Step 1-2: Define integer parameters for the external interface of the dynamic software module. The integer variable represents and specifies the number of devices that the USB device should enumerate. Set the number of enumeration retries and the retry interval. Typically, the number of enumerations can be set to 60 and the retry interval to 1 second.

[0027] Steps 1-3: Determine the number of hardware modules, USB class driver name, character device node name, and class driver function pointer information of the USB device, and record them in a global structure array.

[0028] In steps 1-4, the user passes the desired number of USB devices to the software module, which can then determine the status of the devices based on this information.

[0029] Step 2: For the type of USB device, based on the class driver name, traverse the linked list of enumerated connection processing function pointers of the registered USB protocol stack, determine the corresponding re-enumerated connection processing function pointer for the type, and combine it with... Figure 2 ;

[0030] Step 2-1: Obtain the global driver chain mutex semaphore of the protocol stack for critical resource access;

[0031] Step 2-2: Traverse the driver nodes and match the USB device client name initialized in Step 1 with the driver name of the traversed driver. If the strings are the same, the USB device finds its associated class driver pointer and assigns the pointer to the class driver pointer in the USB device information table in Step 1.

[0032] Steps 2-3: Release the global driver chain mutex semaphore in the protocol stack to exit critical resource access.

[0033] Step 3: Within the orphan device re-enumeration detection program, check the number of USB character devices created by the USB device at the operating system I / O layer. If this number does not match the hardware configuration, check if the missing device is in an orphan device state and re-enumerate as needed. If the number matches, exit the re-enumeration program and combine it with... Figure 3 ;

[0034] Step 3-1: Based on the expected number of USB devices, check in the I / O layer whether the corresponding number of character devices have been created. If the number of any type of device does not match, proceed to step 3-2. If the number of character devices in the I / O layer for all types of USB devices meets the requirements, exit the re-enumeration program normally.

[0035] Step 3-2: Recursively search all USB host controllers under the embedded platform to find any orphan devices and perform re-enumeration.

[0036] Step 4: Obtain the number of USB host controllers in the system through the interface of the USB protocol stack, and traverse the root hub and ordinary hubs under the USB host controller. For the non-hub type USB devices found, call the operating system USB protocol stack device information query interface through its node number (a combination of USB bus number and device number) to obtain and store the basic information of the USB device.

[0037] Step 4-1: Obtain the number of USB host controllers of the embedded hardware platform through the protocol stack interface;

[0038] Step 4-2: Traverse the USB host controller, starting from the root hub, and search and analyze all connected devices (including the hub itself and the devices connected to its downstream ports).

[0039] Step 4-3: If the found device is a hub device, recursively continue searching for downstream ports; if the found device is a regular USB device, use the node number (a combination of USB bus number and device number) assigned to the regular USB device by the USB protocol stack to call the operating system's USB protocol stack device information query interface to obtain the basic information of the USB device (including the USB device's configuration descriptor information and interface descriptor information) stored by the USB protocol stack for the regular USB device.

[0040] Step 5: If the basic information of the USB device shows that the non-hub type USB device and the USB class driver are bound, then skip the non-hub type device; for devices that are not bound to the USB class driver in the basic information of the USB device, the non-hub type device is an orphan device. Obtain the USB interface information saved by the USB protocol stack for the orphan device, find the class driver that matches the USB interface information, and call the connection callback function of the class driver to try to rebind the orphan device to its corresponding class driver.

[0041] Step 5-1: If the USB device and class driver are already marked in the basic information of the USB device, then skip the current USB device;

[0042] Step 5-2: If the class driver has not been bound, the USB device is an orphan device. Obtain the interface descriptor information of the device from the configuration descriptor information of the USB device. The USB device usually contains multiple interfaces, which represent different functional modules of the USB device.

[0043] Step 5-3: Obtain the device's interface class, interface subclass, interface protocol code, and the driver name associated with the interface, and find the class driver pointer that matches the interface.

[0044] Step 5-4: From the USB device class driver pointer corresponding to the orphan device, call its driver connection processing function to perform re-enumeration connection processing, and attempt to rebind the orphan device to the driver; the class driver will be responsible for completing the actual USB bus communication operation and attempting to re-handshake with the device to establish a connection.

[0045] Step 6: After traversing all USB devices in all topologies under all USB host controllers, execute the 1-second delay described in Steps 1-2, and then determine if there are still retries. If yes, then re-enter Step 3; otherwise, exit the re-enumeration program.

[0046] Step 6-1: Delay and wait according to the configured global variable interval time;

[0047] Step 6-2: Decrease the number of retries in the retry mechanism. If the number of retries is exhausted, exit the re-enumeration software module. If there are still retries available, re-enter step 3 to recheck the matching of the number of character devices at the I / O layer for each type of USB device.

[0048] During each retry, the system repeats the device enumeration process described above, re-probing for devices and matching class drivers to further attempt to bind the devices to the drivers. After each retry, the system checks again whether the device node has been successfully created. Retrying continues until the maximum number of retries is reached or all devices are successfully bound. If all devices are successfully bound during the retry process, the system terminates the re-enumeration process and ensures that all devices are functioning correctly.

[0049] Combination Figure 4 In an embedded hardware platform containing a USB keyboard, a USB mouse, and two USB touchscreens, one touchscreen fails to enumerate due to interference, resulting in a missing USB touchscreen device in the system device list. When this embodiment detects the orphan device and re-invokes the touchscreen's class driver function pointer, it re-enumerates the device and successfully creates it. The expected USB device list in the system is now complete, and the re-enumeration process of this embodiment is finished.

[0050] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0051] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for re-enumeration of a class driver of an embedded system USB orphan device, characterized in that, The method comprises the following steps: Step 1, according to the configuration information of the USB device of the embedded system hardware platform, the number of hardware configurations of different categories of the USB device is determined and transmitted to the USB orphan device re-enumeration detection program; Step 2, according to the category driver name, the enumeration joint processing function pointer list of the registered USB protocol stack is traversed, and the corresponding re-enumeration joint processing function pointer of the type is determined; Step 3, the number of USB character devices created by the USB device in the operating system I / 0 layer is checked in the orphan device re-enumeration detection program; if it does not match the number of hardware configurations, it is necessary to check whether the missing device is in the orphan device state, and the re-enumeration process is carried out according to the situation; if it matches, the re-enumeration program is exited; Step 4, the number of USB host controllers in the system is obtained through the interface of the USB protocol stack, and the devices under the root hub and the ordinary hub under the USB host controller are traversed; for the found non-hub class USB device, the USB device basic information is obtained by calling the operating system USB protocol stack device information query interface through the node number, and is stored; Step 5, when the USB device basic information shows that the non-hub class device is bound with the USB category driver, the non-hub class device is skipped; for the device whose USB category driver is not bound in the USB device basic information, the non-hub class device is an orphan device, the USB interface information temporarily stored by the USB protocol stack for the orphan device is obtained, the category driver matching the USB interface information is found, and the joint callback function of the category driver is called to try to bind the orphan device with the corresponding category driver again; Step 6, after traversing all USB devices in the topology under all USB host controllers, a certain delay is executed to judge whether there is a retry number, if yes, the step 3 is re-entered; if no, the re-enumeration program is exited.

2. The method of claim 1, wherein the method further comprises: The step 1 comprises the following steps: Step 1-1, after the initialization of the USB subsystem of the embedded system is completed and before the initialization of the application software using the USB device, a software module dynamically loaded and executed is inserted; Step 1-2, the dynamic software module defines an integer parameter in the external interface, and the integer variable represents and specifies the number of devices that the USB device should enumerate, and the enumeration retry number and the retry interval time value are set; Step 1-3, the number of hardware modules of the USB device, the USB category driver name, the character device node name, and the category driver function pointer information are determined, and are recorded in the global structure array; Step 1-4, the user transmits the expected number of the USB device to the software module, and the software module can judge the state of the device according to the information.

3. The method of claim 1, wherein the method further comprises: The step 2 comprises the following steps: Step 2-1, the global drive chain mutex semaphore of the protocol stack is acquired for critical resource access; Step 2-2, name matching is performed on the USB device client name initialized in step 1 and the driver name of the traversed driver node; if the strings are the same, the USB device finds its associated class driver pointer, and the pointer is assigned to the class driver pointer in the USB device information table in step 1; Step 2-3, the protocol stack global driver chain mutual exclusion semaphore is released to exit the critical resource access.

4. The method of claim 1, wherein the method further comprises: The step 3 comprises the following steps: Step 3-1, according to the expected number of USB devices, it is checked whether the corresponding number of character devices has been created in the I / 0 layer; if the number of any type of device does not match, step 3-2 is entered; if the number of character devices of all types of USB devices in the I / 0 layer all meet the requirements, the re-enumeration program is normally exited; Step 3-2, all USB host controllers under the embedded platform are recursively embedded, and it is checked whether there is an orphan device, and the re-enumeration work is performed.

5. The method of claim 1, wherein the method further comprises: The step 4 comprises the following steps: Step 4-1, the number of USB host controllers of the embedded hardware platform is obtained through the protocol stack interface; Step 4-2, the USB host controllers are traversed, and all connected devices are searched and analyzed from the root hub as a starting point; Step 4-3, if the found device is a hub device, the recursive search of the downstream port is continued; if the found device is a normal USB device, the node number allocated to the normal USB device by the USB protocol stack is taken as a parameter, the operating system USB protocol stack device information query interface is called, and the USB device basic information stored by the USB protocol stack for the normal USB device is obtained.

6. The method of claim 1, wherein the method further comprises: The step 5 comprises the following steps: Step 5-1, if the USB device and the class driver binding in the USB device basic information have been marked, the current USB device is skipped; Step 5-2, if the class driver has not been bound, the USB device is an orphan device, and the interface descriptor information of the device is obtained from the configuration descriptor information of the USB device; Step 5-3, the interface class Interface Class, interface subclass Interface SubClass, interface protocol code Interface Protocol, and the driver name associated with the interface are obtained, and the class driver pointer matching the interface is found; Step 5-4, the re-enumeration splicing processing function is called from the USB device class driver pointer corresponding to the orphan device to attempt to re-bind the orphan device to the driver.

7. The method of claim 1, wherein the method further comprises: The step 6 comprises the following steps: Step 6-1, delay waiting is performed according to the interval time of the configured global variable; Step 6-2, the retry number in the retry mechanism is decremented; if the retry number is exhausted, the re-enumeration software module is exited; if the retry number is still available, step 3 is re-entered to recheck the number matching of each type of USB device in the I / 0 layer character device.

8. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor implements the method of any one of claims 1 to 7 when executing the program. The processor implements the method of any one of claims 1 to 7 when executing the program.

9. A non-transitory computer-readable storage medium, comprising: The non-transitory computer readable storage medium stores computer instructions for causing the computer to perform the method of any one of claims 1 to 7.

10. A computer program product comprising computer program instructions, characterised in that, The computer program instructions, when run on a computer, cause the computer to perform the method of any one of claims 1 to 7.

Images