Class driver re-enumeration method of embedded system USB orphan equipment

Abstract

The invention discloses a class driver re-enumeration method for USB (Universal Serial Bus) orphan equipment of an embedded system, which comprises the following steps of: checking and traversing all USB orphan equipment identified by a USB protocol stack in the system, combining with a timeout re-try mechanism, and calling a corresponding driver overlap processing function, so that an operating system can re-enumerate and bind the equipment. According to the method, a USB protocol stack and a USB type drive code of an operating system do not need to be modified, only an external dynamic loadable program is formed to realize reenumeration, and meanwhile, a configuration mechanism of retry times and time intervals is also provided, so that the system can reduce the occurrence probability of orphan equipment to the greatest extent in a complex environment, and the reliability of the system is improved. Therefore, the management efficiency of various USB peripherals in the embedded platform and the overall reliability of the system are improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of computer operating systems and embedded systems, and particularly relates to a method for re-enumerating class drivers of USB orphan devices in an embedded system. Background Art

[0002] In modern computer systems, USB (Universal Serial Bus) devices are widely used in various peripheral connections due to their plug-and-play characteristics. However, in some complex electromagnetic environment scenarios using embedded devices and USB peripherals, USB devices may fail to be correctly recognized for various reasons during the initialization and enumeration process, which can be roughly divided into two stages. In the first stage, the USB system software (USB protocol stack) shakes hands with the device. If a problem occurs in this stage, the device will be abandoned by the USB system software. In the second stage, the USB protocol stack hands over the device to the USB class-specific driver to further shake hands with the device, and problems may also occur in this process, resulting in device enumeration failure. If the failure occurs in the second stage, the device will become an "orphan device" (not bound to the class driver). In the Linux-like system, usually the protocol stack has a relatively complete retry mechanism, which can largely complete the device enumeration work (but in extreme cases, the system software will still prompt abnormalities such as device connection cables and electromagnetic compatibility).

[0003] For domestic embedded operating systems such as DeltaOS, ACoreOS Tianmai, and JARI-Works, they are widely used in fields with high requirements for stability and real-time performance, such as aerospace and industrial control. In these fields, the stability of peripheral devices directly affects the reliability of the entire system. However, due to problems such as hardware compatibility, USB protocol stack implementation (the USB protocol stack of such operating systems is lightweight system software, and its functional completeness and robustness cannot reach the level of the desktop-level system USB protocol stack), and USB device firmware, USB devices may not 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, when the device becomes an orphan device, even if the physical connection is normal, the operating system layer cannot recognize and use these devices, affecting the normal operation of the system. This is still an unsolved technical problem in systems with high requirements for real-time performance and human-computer interaction reliability. Summary of the Invention

[0004] The purpose of the present invention is to provide a method for re-enumerating class drivers of USB orphan devices in an embedded system

[0005] To achieve the purpose of the present invention, the present invention provides a method for re-enumerating class drivers of USB orphan devices in an embedded system, including the following steps:

[0006] Step 1: Determine the hardware configuration quantities of different categories of the USB device according to the configuration information of the USB device on the embedded system hardware platform, and pass them to the USB orphan device re-enumeration detection program;

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

[0008] Step 3: Inside 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 hardware configuration quantity, it is necessary to check whether the missing device is in the orphan device state, and perform re-enumeration according to the situation; 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 devices under 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 their node numbers to obtain and store the basic information of the USB device;

[0010] Step 5: When the basic information of the USB device shows that the non-hub device is bound to the USB class driver, skip the non-hub device; for the device that is not bound to the USB class driver in the basic information of the USB device, the non-hub device is an orphan device. Obtain the USB interface information temporarily stored 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 attempt to re-bind 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 whether there are still retry times. If so, re-enter Step 3; if not, exit the re-enumeration program.

[0012] An electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that when the processor executes the program, it implements the above-mentioned class driver re-enumeration method for USB orphan devices in an embedded system.

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

[0014] A computer program product includes computer program instructions, characterized in that when the computer program instructions run on a computer, the computer is caused to execute the above-mentioned method for class driver re-enumeration of orphan devices in an embedded system.

[0015] Compared with the prior art, the remarkable progress of the present invention lies in: (1) The present invention does not require modifying the USB protocol stack code of the embedded operating system, nor any code of the developed USB class device driver. Instead, only an external dynamically loadable program needs to be separately constructed to achieve re-enumeration, and at the same time, a configuration mechanism for the number of retries and time intervals is provided, enabling the system to minimize the probability of orphan devices in a complex on-site environment and enhancing the stability and availability of the USB subsystem of the embedded system. It avoids potential problems caused by incorrect device binding; (2) The present invention has strong versatility and meets the software development and operation requirements such as software reusability, versatility, and adaptability. Thus, it 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, the following further explains in conjunction with the drawings and specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings described herein are used to provide a further understanding of the present invention, form a part of this application, and the schematic embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation to the present invention. In the drawings:

[0018] Figure 1 is the flowchart of orphan device re-enumeration based on class driver re-binding of the present invention;

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

[0020] Figure 3 is the flowchart of recursively searching for orphan devices on the USB bus and performing re-enumeration of the present invention;

[0021] Figure 4 is the operation result diagram of orphan device detection and class driver re-enumeration of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0022] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments; based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0023] A method for re - enumerating the class driver of an embedded system USB orphan device according to the present invention is characterized in that, in combination with Figure 1 , including the following steps:

[0024] Step 1: Determine the number of hardware configurations of different categories of USB devices according to the configuration information of the USB devices on the embedded system hardware platform and the class driver name information of each category of USB devices, and pass it to the USB orphan device re - enumeration detection program;

[0025] Step 1 - 1: After the initialization of the embedded system USB subsystem is completed and before the application software using the USB device is initialized, insert a software module that is dynamically loaded and executed;

[0026] Step 1 - 2: Define an integer parameter 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, and set the number of re - enumeration attempts and the retry interval time value. Usually, the number of re - enumeration attempts can be set to 60 times, and the retry interval time is 1 second;

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

[0028] Step 1 - 4: The user passes the expected number of the USB device to the software module, and the software module can judge the status of the device according to this information internally.

[0029] Step 2: For the type of the USB device, according to the class driver name, traverse the enumeration connection processing function pointer linked list of the registered USB protocol stack to determine the corresponding re - enumeration connection processing function pointer for the type, in combination with Figure 2 ;

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

[0031] Step 2 - 2: Traverse the driver nodes, and match the name of the USB device client 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] Step 2 - 3: Release the protocol stack global driver chain mutex semaphore to exit the critical resource access.

[0033] Step 3. Inside 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 hardware configuration number, it is necessary to check whether the missing devices are in the orphan device state and perform re-enumeration according to the situation; if it matches, exit the re-enumeration program, combined with Figure 3 ;

[0034] Step 3-1. According to the expected number of the USB devices, check in the I / O layer whether the corresponding number of character devices has been created. If the number of any type of device does not match, go to Step 3-2; if the number of character devices of all types of USB devices in the I / O layer all meet the requirements, normally exit the re-enumeration program;

[0035] Step 3-2. Recursively check all USB host controllers under the embedded platform to find out whether there are orphan devices and perform re-enumeration work.

[0036] Step 4. Obtain the number of USB host controllers (USB Host Controllers) in the system through the interface of the USB protocol stack, and traverse the devices under 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 their node numbers (the combined number of the USB bus number + device number) to obtain and store the basic USB device information;

[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 controllers, starting from the root hub as the search starting point, 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 to search for downstream ports; if the found device is an ordinary USB device, call the operating system USB protocol stack device information query interface through the node number (the combined number of the USB bus number + device number) assigned by the USB protocol stack for the ordinary USB device to obtain the basic USB device information (including the configuration descriptor information and interface descriptor information of the USB device) stored by the USB protocol stack for the ordinary USB device.

[0040] Step 5. When the basic information of the USB device shows that the non-hub USB device is bound to the USB class driver, skip the non-hub device; for the device without a bound USB class driver in the basic information of the USB device, the non-hub 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 attachment callback function of the class driver to attempt to rebind the orphan device to its corresponding class driver.

[0041] Step 5-1. If the USB device and the class driver are marked as bound in the basic information of the USB device, skip the current USB device.

[0042] Step 5-2. If the class driver has not been bound yet, 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, and the interfaces represent different functional modules of the USB device.

[0043] Step 5-3. Obtain the Interface Class, Interface SubClass, Interface Protocol of the device, as well as 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 attachment processing function for re-enumeration attachment processing to 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 and establish a connection with the device.

[0045] Step 6. After traversing all USB devices in all topologies under all USB host controllers, after performing the 1-second delay described in Step 1-2, determine whether there are still retry counts. If so, re-enter Step 3; if not, exit the re-enumeration program.

[0046] Step 6-1. Wait for a delay according to the configured global variable interval time.

[0047] Step 6-2. Decrease the retry count in the retry mechanism. If the retry count is exhausted, exit the re-enumeration software module. If there are still retry counts, re-enter Step 3 to re-check the completeness of the number of each type of USB device in the I / O layer character device.

[0048] During each retry process, the system will repeatedly execute the above device enumeration process, further attempt to bind the device to the driver by redetecting the device and matching the class driver. After each retry is completed, the system will check again whether the device node has been successfully created. Retry operations are performed until the maximum number of retries is reached or all devices are successfully bound. During the retry process, if all devices are successfully bound, the system will end the re-enumeration process and ensure that all devices can work properly.

[0049] Combined with Figure 4 , on an embedded hardware platform that includes a USB keyboard, a USB mouse, and two USB touchscreens, one of the touchscreens fails to enumerate due to interference, and the system device list is missing a USB touchscreen device. When this embodiment detects the orphan device and re-invokes the class driver function pointer of the touchscreen to re-enumerate the device and successfully creates the device, the expected USB device list in the system is complete, and the re-enumeration work of the embodiment is completed.

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

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

Claims

1. A class driver re-enumeration method for USB orphan devices in an embedded system, characterized in that: The following steps are involved: Step 1, according to the configuration information of the USB device of the embedded system hardware platform, determine the hardware configuration quantity of different categories of the USB device and pass it to the USB orphan device re-enumeration detection program; Step 2: for the type of the USB device, according to the class driver name, traverse the enumeration overlap processing function pointer linked list of the registered USB protocol stack, and determine the corresponding re-enumeration overlap processing function pointer for the type; Step 3, through the orphan device re-enumeration detection program, check the number of USB character devices created by the USB device in the operating system I / O layer; if it does not match the hardware configuration number, check whether the missing device is in an orphan device state, and re-enumerate according to the situation; if it matches, exit the re-enumeration program; 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 the devices under the common hub under the USB host controller. For the non-hub USB device 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; Step 5: When the basic information of the USB device shows that the non-hub device is bound to the USB driver, skip the non-hub device; For a device that is not bound to a USB class driver in the USB device basic information, the non-hub device is an orphan device, USB interface information temporarily stored by the USB protocol stack for the orphan device is obtained, a class driver matching the USB interface information is found, and a binding callback function of the class driver is called to try to rebind the orphan device to its corresponding class driver; Step 6: After traversing all USB devices in the topology under all USB host controllers, determine whether there are still retry times after a certain delay. If yes, re-enter the step 3; if not, exit the re-enumeration program.

2. The class driver re-enumeration method for USB orphan devices in an embedded system according to claim 1, characterized in that: The step 1 comprises the following steps: Step 1-1, after the embedded system USB subsystem is initialized and before the application software using the USB device is initialized, a software module for dynamic loading and execution is inserted; Step 1-2, the external interface of the dynamic software module defines an integer parameter, wherein the integer variable represents and specifies the number of devices that the USB device should enumerate, and sets the number of enumeration retries and the retry interval time value; Step 1-3, determine the number of hardware modules, USB class driver name, character device node name, class driver function pointer information of the USB device, and record them in a global structure array; Step 1-4: The user transmits the expected number of USB devices to the software module, and the software module can judge the status of the device based on this information.

3. The class driver re-enumeration method for USB orphan devices in an embedded system according to claim 1, characterized in that: The step 2 comprises the following steps: Step 2-1, obtain the protocol stack global driver chain mutex semaphore to access critical resources; Step 2-2, traversing the driver nodes, matching the USB device client name initialized in step 1 with the driver name of the traversed driver; if the character 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; Step 2-3: Release the protocol stack global driver chain mutex semaphore to exit critical resource access.

4. The class driver re-enumeration method for USB orphan devices in an embedded system according to claim 1, characterized in that: The step 3 comprises the following steps: Step 3-1, according to the expected number of USB devices, search in the I / O layer whether the corresponding number of character devices has been created, if the number of devices of any type does not match, proceed to step 3-2; if the number of character devices of all types of USB devices in the I / O layer meets the requirements, exit the re-enumeration program normally; Step 3-2: Recursively search all USB host controllers under the embedded platform to find out whether there are orphan devices and perform re-enumeration.

5. The class driver re-enumeration method for USB orphan devices in an embedded system according to claim 1, characterized in that: The step 4 comprises the following steps: Step 4-1, obtaining the number of USB host controllers of the embedded hardware platform through the protocol stack interface; Step 4-2, traverse the USB host controller, starting from the root hub as the search starting point, and search and analyze all connected devices; Step 4-3, if the found device is a hub device, recursively continue to search for downstream ports; if the found device is an ordinary USB device, use the node number assigned by the USB protocol stack to the ordinary USB device as a parameter, call the operating system USB protocol stack device information query interface, and obtain the USB device basic information stored by the USB protocol stack for the ordinary USB device.

6. The class driver re-enumeration method for USB orphan devices in an embedded system according to claim 1, characterized in that: The step 5 comprises the following steps: Step 5-1: If the USB device and class driver binding are marked in the USB device basic information, skip the current USB device; 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, obtaining the device's interface class Interface Class, interface subclass Interface SubClass, interface protocol code Interface Protocol, and the driver name associated with the interface, and finding a class driver pointer that matches the interface; Step 5-4: from the USB device class driver pointer corresponding to the orphan device, call its driver binding processing function to perform re-enumeration binding processing, and try to re-bind the orphan device to the driver.

7. The class driver re-enumeration method for USB orphan devices in an embedded system according to claim 1, characterized in that: The step 6 comprises the following steps: Step 6-1: Delay waiting according to the configured global variable interval time; Step 6-2, decrement the number of retries in the retry mechanism, if the number of retries is exhausted, exit the re-enumeration software module. If the number of retries is still available, re-enter step 3 to recheck the completeness of the number of character devices at the I / 0 layer of each type of USB device.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the method according to any one of claims 1 to 7 is implemented.

9. A non-transitory computer-readable storage medium, characterized in that: The non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to cause the computer to execute any one of claims 1 to 7.

10. A computer program product comprising computer program instructions, characterized in that When the computer program instructions are executed on a computer, the computer is caused to perform the method according to any one of claims 1 to 7.

Images