USB drive-free communication method and device, electronic equipment and storage medium

Abstract

The application discloses a USB driver-free communication method and device, electronic equipment and a storage medium, wherein the method comprises the following steps: enumerating a USB device inserted to obtain enumeration information of the USB device; determining a host device number and a secondary device number created by the USB device in a host device according to the enumeration information; creating a character device according to the host device number and the secondary device number; binding the USB device and a usbfs driver through the character device; and communicating with the USB device through the usbfs driver. Thus, the host device number and the secondary device number created by the USB device in the system are determined according to the enumeration information, the corresponding character device is created, the IOCTL command is executed through the character device, the USB device is bound with the usbfs driver provided by the kernel, and then the USB device can directly use the common usbfs driver in the kernel for data communication without relying on the specific driver of the manufacturer.

Description

Technical Field

[0001] This invention relates to the field of USB device data transmission technology, and specifically to a USB driverless communication method, apparatus, electronic device, and storage medium. Background Technology

[0002] Wireless communication modules, leveraging cellular networks provided by telecom operators, are widely used in PCs, tablets, industrial gateways, and other products, offering a wireless bridge for the Internet of Things (IoT) in consumer and industrial electronic devices. Currently, for wireless communication modules to perform functions such as log capture or upgrades via USB ports in embedded Linux host environments, existing chip solution providers typically require the installation of vendor-specific drivers. However, due to customer customization, high degree of customization, and cost considerations, embedded Linux systems cannot fully integrate drivers from various vendors, thus limiting the application of these modules. Summary of the Invention

[0003] To address the aforementioned problems in the prior art, this application provides a USB driverless communication method, apparatus, electronic device, and storage medium, enabling USB devices to directly use the universal usbfs driver in the kernel for data communication without relying on manufacturer-specific drivers.

[0004] Firstly, embodiments of this application provide a USB driverless communication method, which specifically includes:

[0005] Enumerate the inserted USB devices to obtain the USB device enumeration information;

[0006] Based on the enumeration information, determine the major and minor device numbers created by the USB device in the host device;

[0007] Create a character device based on the major and minor device numbers;

[0008] The USB device is bound to the USBFS driver via a character device, where the USBFS driver is pre-configured in the host device's kernel;

[0009] Communicate with USB devices via the usbfs driver.

[0010] In one embodiment of the present invention, the inserted USB devices are enumerated to obtain enumeration information of the USB devices, including:

[0011] The supplier identification and product identification code of the USB device are read through the inserted interface;

[0012] Based on the supplier's identity and product identification code, the system matches the data in a preset path directory to obtain enumeration information for USB devices.

[0013] In one embodiment of the present invention, creating a character device based on a major device number and a minor device number includes:

[0014] Character devices are dynamically created using the mknod interface based on the major and minor device numbers.

[0015] In one embodiment of the present invention, before binding the USB device to the USBFS driver via a character device, the method further includes:

[0016] Use the IOCTL command on the character device to determine if the USB device has the driver loaded;

[0017] When the USB device has already loaded the driver, unbind the USB device from the driver.

[0018] In one embodiment of the present invention, communication with a USB device via a USBFS driver includes:

[0019] Create a read thread using the usbfs driver;

[0020] Bind the read thread to the endpoint in the input direction to obtain data from the USB device by reading the endpoint in the input direction in a blocking manner using the read thread.

[0021] In one embodiment of the present invention, communicating with a USB device via a USBFS driver further includes:

[0022] Create a write thread using the USBFS driver;

[0023] Bind the write thread to the endpoint in the output direction to write data to the USB device.

[0024] In one embodiment of the present invention, writing data to the endpoint in the output direction via a write thread includes:

[0025] The data is assembled into a URB BULK package using a write thread;

[0026] Write the URB BULK packet to the endpoint in the output direction.

[0027] Secondly, embodiments of this application provide a USB driverless communication device, which specifically includes:

[0028] The enumeration module is used to enumerate the inserted USB devices and obtain the enumeration information of the USB devices;

[0029] The analysis module is used to determine the major and minor device numbers created by the USB device in the host device based on the enumeration information.

[0030] The communication module is used to create character devices based on the major and minor device numbers, and bind USB devices to the usbfs driver through the character devices. The usbfs driver is pre-configured in the kernel of the host device and communicates with the USB devices through the usbfs driver.

[0031] Thirdly, embodiments of this application provide an electronic device, including: a processor connected to a memory for storing a computer program, and the processor for executing the computer program stored in the memory to cause the electronic device to perform the method as described in the first aspect.

[0032] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that causes a computer to perform the method as described in the first aspect.

[0033] Fifthly, embodiments of this application provide a computer program product, the computer program product including a non-transitory computer-readable storage medium storing a computer program, and a computer operable to perform the method as described in the first aspect.

[0034] Implementing the embodiments of this application has the following beneficial effects:

[0035] In this embodiment, the major and minor device numbers of the USB device created in the system are determined through the enumeration information of the USB device, and then a corresponding character device is created based on the major and minor device numbers. The IOCTL command is then executed through this character device to bind the USB device to the kernel's built-in usbfs driver. This allows the USB device to directly use the kernel's general-purpose usbfs driver for data communication, without relying on vendor-specific drivers. Attached Figure Description

[0036] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0037] Figure 1 A schematic diagram of the hardware structure of a USB driverless communication device provided for an embodiment of this application;

[0038] Figure 2 A flowchart illustrating a USB driverless communication method provided for an embodiment of this application;

[0039] Figure 3A functional module block diagram of a USB driverless communication device provided for embodiments of this application;

[0040] Figure 4 This is a schematic diagram of the structure of an electronic device provided for an embodiment of this application. Detailed Implementation

[0041] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0042] The terms "first," "second," "third," and "fourth," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0043] In this document, the term "implementation" means that a specific feature, result, or characteristic described in connection with an implementation may be included in at least one implementation of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same implementation, nor is it a separate or alternative implementation mutually exclusive with other implementations. It will be explicitly and implicitly understood by those skilled in the art that the implementations described herein can be combined with other implementations.

[0044] First, refer to Figure 1 , Figure 1 This is a schematic diagram of the hardware structure of a USB driverless communication device provided in an embodiment of this application. The USB driverless communication device 100 includes at least one processor 101, a communication line 102, a memory 103, and at least one communication interface 104.

[0045] In this embodiment, the processor 101 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present application.

[0046] Communication line 102 may include a path for transmitting information between the aforementioned components.

[0047] The communication interface 104 can be any transceiver-like device (such as an antenna) used to communicate with other devices or communication networks, such as Ethernet, RAN, wireless local area networks (WLAN), etc.

[0048] The memory 103 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0049] In this embodiment, the memory 103 can exist independently and be connected to the processor 101 via the communication line 102. Alternatively, the memory 103 can be integrated with the processor 101. The memory 103 provided in this embodiment is typically non-volatile. The memory 103 stores computer execution instructions for implementing the scheme of this application, and its execution is controlled by the processor 101. The processor 101 executes the computer execution instructions stored in the memory 103 to implement the method provided in the following embodiments of this application.

[0050] In an optional implementation, the computer execution instructions may also be referred to as application code, and this application does not specifically limit this terminology.

[0051] In an optional implementation, processor 101 may include one or more CPUs, for example... Figure 1 CPU0 and CPU1 in the CPU.

[0052] In an optional implementation, the USB driverless communication device 100 may include multiple processors, such as... Figure 1Processors 101 and 107 are shown in the diagram. Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. A processor here may refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0053] In optional implementations, if the USB driverless communication device 100 is a server, for example, it can be a standalone server or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Then the USB driverless communication device 100 may further include an output device 105 and an input device 106. The output device 105 communicates with the processor 101 and can display information in various ways. For example, the output device 105 can be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector, etc. The input device 106 communicates with the processor 101 and can receive user input in various ways. For example, the input device 106 can be a mouse, keyboard, touchscreen device, or sensor device, etc.

[0054] The USB driverless communication device 100 described above can be a general-purpose device or a special-purpose device. The embodiments of this application do not limit the type of the USB driverless communication device 100.

[0055] The USB driverless communication method disclosed in this application will be described below:

[0056] See Figure 2 , Figure 2 A flowchart illustrating a USB driverless communication method provided for embodiments of this application may specifically include the following steps:

[0057] 201: Enumerate the inserted USB devices to obtain the USB device enumeration information.

[0058] Enumeration, in essence, is the process by which the host controller recognizes the USB device, prepares resources for it, and establishes a data transfer mechanism between the host and the device. This stage is defined by the USB communication protocol and is therefore part of the ISO standard process. The device enumeration stage corresponds to five states of the USB device: After the USB device is plugged into the interface, it is in the Attached state; the USB host controller supplies power to the USB device, placing it in the Powered state; after step 2 of the device enumeration stage, the reset operation, the device is in the Default state; after step 3 of the device enumeration stage, the address setting operation, the device is in the Addressed state; and after device enumeration is complete, the device is in the Configured state.

[0059] Specifically, the device enumeration phase can be divided into the following eight steps: 1. Obtain device descriptor; 2. Reset; 3. Set address; 4. Obtain device descriptor again; 5. Obtain configuration descriptor; 6. Obtain interface and endpoint descriptors; 7. Obtain string descriptor; 8. Select and set configuration. Steps 1 and 4 both involve obtaining the device descriptor. However, step 1 only obtains a fixed-length field of the device descriptor, while step 4 obtains all fields of the device descriptor. Through these eight steps, during the device enumeration phase, the host controller obtains all the detailed information (five main descriptors) of the USB device and then allocates resources to it (sets the address).

[0060] Based on this, in this embodiment, the inserted USB device can be enumerated through the inserted interface, the device descriptor of the USB device can be read, and then the vendor identification number (VID) and product identification number (PID) of the USB device can be determined according to the fields in the device descriptor. Then, based on the VID and PID of the USB device, a match is made in a preset path directory, such as the sys / bus / usb directory, to obtain the enumeration information of the USB device.

[0061] 202: Based on the enumeration information, determine the major and minor device numbers created by the USB device in the host device.

[0062] Linux device management is tightly integrated with the file system. Various devices are stored as files in the ` / dev` directory, called device files. Applications can open, close, and read / write these device files to perform operations on the devices, just like operating on ordinary data files. To manage these devices, the system assigns them numbers, each device number being divided into a major device number and a minor device number. The major device number is used to distinguish different types of devices, while the minor device number is used to distinguish multiple devices of the same type. In this implementation, the device file can be found by enumerating information, obtaining `bNumInterfaces` information, obtaining the number of ports enumerated by the current module, and then determining the major and minor device numbers created for the USB device on the host based on `uevent`.

[0063] 203: Create a character device based on the major and minor device numbers.

[0064] Character devices are a type of custom device structure in Linux that provides a continuous stream of data, allowing applications to read input / output (I / O) devices sequentially. They typically support reading and writing data byte-by-byte or character-by-character, but do not support random access. Specifically, in this implementation, character devices can be dynamically created using the mknod interface based on the major and minor device numbers.

[0065] 204: Bind a USB device to a USBFS driver via a character device.

[0066] In this implementation, the USBFS driver is pre-configured in the host device's kernel; it is a generic driver that comes with the kernel. Specifically, before binding, it's necessary to determine the driver loading status of the USB device, i.e., whether any drivers have been automatically loaded. In this implementation, the USB device can be opened using the `open` system call from the created character device, and then the `IOCTL USBDEVFS_GETDRIVER` command can be run to query whether the USB device has already loaded other drivers.

[0067] If the query results indicate that the USB device has automatically loaded the usbfs driver, you can proceed to the next step. If another driver has been loaded, unbind the USB device from the other driver, and then bind the USB device to the usbfs driver using the IOCTLUSBDEVFS_CLAIMINTERFACE command.

[0068] 205: Communicating with USB devices via the usbfs driver.

[0069] In this embodiment, firstly, the data port used for communication by the USB device is determined by the PID, and the input endpoint (EP) and output endpoint of the USB device are set based on the data port.

[0070] In this implementation, the USBFS driver can then create a read thread through the data port and construct a `usbdevfs_bulktransfer BULK` read request to bind the input EP. After binding, the driver uses `USBDEVFS_BULK IOCTL` to read the input EP in a blocking manner, obtaining data from the USB device into the user buffer, thus completing the reading of the USB device.

[0071] Finally, in this embodiment, the USBFS driver can create a write thread through the data port and construct a `usbdevfs_urb URB` write request through this thread to request binding to the output direction EP. After binding is complete, the data in the user buffer is assembled into a URB BULK packet, which is then written to the output direction EP via `USBDEVFS_SUBMITURB IOCTL`. The data in the user buffer is then sent to the USB device controller, completing the write operation to the USB device.

[0072] In summary, the USB driverless communication method provided by this invention determines the major and minor device numbers created in the system for the USB device through the enumeration information of the USB device, and then creates a corresponding character device based on the major and minor device numbers. The character device then executes the IOCTL command to bind the USB device to the kernel's built-in usbfs driver. This allows the USB device to directly use the general-purpose usbfs driver in the kernel for data communication, without relying on vendor-specific drivers.

[0073] See Figure 3 , Figure 3 A functional module block diagram of a USB driverless communication device provided for embodiments of this application, specifically, as follows: Figure 3 As shown, the USB driverless communication device 300 includes:

[0074] The enumeration module 301 is used to enumerate the inserted USB devices and obtain the enumeration information of the USB devices.

[0075] Analysis module 302 is used to determine the major device number and minor device number created by the USB device in the host device based on the enumeration information;

[0076] The communication module 303 is used to create a character device based on the major device number and minor device number, and bind the USB device to the usbfs driver through the character device. The usbfs driver is pre-configured in the kernel of the host device and communicates with the USB device through the usbfs driver.

[0077] In an embodiment of the present invention, the enumeration module 301 is specifically used for enumerating the inserted USB devices to obtain enumeration information of the USB devices, wherein the enumeration module 301 is configured to:

[0078] The supplier identification and product identification code of the USB device are read through the inserted interface;

[0079] Based on the supplier's identity and product identification code, the system matches the data in a preset path directory to obtain enumeration information for USB devices.

[0080] In an embodiment of the present invention, in creating a character device based on a major device number and a minor device number, the communication module 303 is specifically used for:

[0081] Character devices are dynamically created using the mknod interface based on the major and minor device numbers.

[0082] In an embodiment of the present invention, before binding the USB device to the USBFS driver via a character device, the communication module 303 is further configured to:

[0083] Use the IOCTL command on the character device to determine if the USB device has the driver loaded;

[0084] When the USB device has already loaded the driver, unbind the USB device from the driver.

[0085] In an embodiment of the present invention, in terms of communicating with a USB device via a USBFS driver, the communication module 303 is specifically used for:

[0086] Create a read thread using the usbfs driver;

[0087] Bind the read thread to the endpoint in the input direction to obtain data from the USB device by reading the endpoint in the input direction in a blocking manner using the read thread.

[0088] In an embodiment of the present invention, in terms of communicating with a USB device via a USBFS driver, the communication module 303 is further configured to:

[0089] Create a write thread using the USBFS driver;

[0090] Bind the write thread to the endpoint in the output direction to write data to the USB device.

[0091] In an embodiment of the present invention, regarding writing data to the endpoint in the output direction via a write thread, the communication module 303 is specifically used for:

[0092] The data is assembled into a URB BULK package using a write thread;

[0093] Write the URB BULK packet to the endpoint in the output direction.

[0094] See Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided for an embodiment of this application. For example... Figure 4 As shown, the electronic device 400 includes a transceiver 401, a processor 402, and a memory 403. These are connected via a bus 404. The memory 403 stores computer programs and data, and can transfer data stored in the memory 403 to the processor 402.

[0095] The processor 402 is used to read the computer program in the memory 403 and perform the following operations:

[0096] Enumerate the inserted USB devices to obtain the USB device enumeration information;

[0097] Based on the enumeration information, determine the major and minor device numbers created by the USB device in the host device;

[0098] Create a character device based on the major and minor device numbers;

[0099] The USB device is bound to the USBFS driver via a character device, where the USBFS driver is pre-configured in the host device's kernel;

[0100] Communicate with USB devices via the usbfs driver.

[0101] In an embodiment of the present invention, in enumerating the inserted USB devices to obtain enumeration information of the USB devices, the processor 402 is specifically configured to perform the following operations:

[0102] The supplier identification and product identification code of the USB device are read through the inserted interface;

[0103] Based on the supplier's identity and product identification code, the system matches the data in a preset path directory to obtain enumeration information for USB devices.

[0104] In an embodiment of the present invention, in creating a character device based on a major device number and a minor device number, the processor 402 is specifically configured to perform the following operations:

[0105] Character devices are dynamically created using the mknod interface based on the major and minor device numbers.

[0106] In an embodiment of the present invention, before binding the USB device to the USBFS driver via a character device, the processor 402 is further configured to perform the following operations:

[0107] Use the IOCTL command on the character device to determine if the USB device has the driver loaded;

[0108] When the USB device has already loaded the driver, unbind the USB device from the driver.

[0109] In an embodiment of the present invention, in communicating with a USB device via a USBFS driver, the processor 402 is specifically configured to perform the following operations:

[0110] Create a read thread using the usbfs driver;

[0111] Bind the read thread to the endpoint in the input direction to obtain data from the USB device by reading the endpoint in the input direction in a blocking manner using the read thread.

[0112] In an embodiment of the present invention, in communicating with a USB device via a USBFS driver, the processor 402 is further configured to perform the following operations:

[0113] Create a write thread using the USBFS driver;

[0114] Bind the write thread to the endpoint in the output direction to write data to the USB device.

[0115] In an embodiment of the present invention, in writing data to the endpoint in the output direction via a write thread, processor 402 is specifically configured to perform the following operations:

[0116] The data is assembled into a URB BULK package using a write thread;

[0117] Write the URB BULK packet to the endpoint in the output direction.

[0118] It should be understood that the USB driverless communication device in this application may include smartphones (such as Android phones, iOS phones, Windows Phones, etc.), tablet computers, PDAs, laptops, mobile internet devices (MIDs), robots, or wearable devices, etc. The above-mentioned USB driverless communication devices are merely examples, not an exhaustive list, and include, but are not limited to, the aforementioned USB driverless communication devices. In practical applications, the aforementioned USB driverless communication devices may also include: intelligent vehicle terminals, computer equipment, etc.

[0119] Through the above description of the embodiments, those skilled in the art can clearly understand that the present invention can be implemented by means of software combined with a hardware platform. Based on this understanding, all or part of the technical solution of the present invention that contributes to the background art can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of the present invention.

[0120] Therefore, embodiments of this application also provide a computer-readable storage medium storing a computer program that is executed by a processor to implement some or all of the steps of any of the USB driverless communication methods described in the above method embodiments. For example, the storage medium may include a hard disk, floppy disk, optical disk, magnetic tape, magnetic disk, USB flash drive, flash memory, etc.

[0121] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the USB driverless communication methods described in the above method embodiments.

[0122] It should be noted that, for the sake of simplicity, the aforementioned methods are described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are optional, and the actions and modules involved are not necessarily essential to this application.

[0123] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0124] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0125] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0126] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software program module.

[0127] If the integrated unit is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0128] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage device, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0129] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The above description of the embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A USB driverless communication method, characterized in that, The method includes: Enumerate the inserted USB devices to obtain the enumeration information of the USB devices; Based on the enumeration information, the major device number and minor device number created by the USB device in the host device are determined. The major device number is used to distinguish different types of devices, and the minor device number is used to distinguish multiple devices of the same type. Create a character device based on the major device number and the minor device number; The USB device is bound to the USBFS driver via the character device, wherein the USBFS driver is pre-configured in the kernel of the host device; Communicating with the USB device through the USBFS driver; The step of creating a character device based on the major device number and the minor device number includes: The character device is dynamically created using the mknod interface based on the major device number and the minor device number.

2. The method according to claim 1, characterized in that, The process of enumerating the inserted USB devices to obtain enumeration information for the USB devices includes: The supplier identification and product identification code of the USB device are read through the inserted interface; The USB device enumeration information is obtained by matching the supplier identity and the product identification code in a preset path directory.

3. The method according to claim 1, characterized in that, Before binding the USB device to the USBFS driver via the character device, the method further includes: The IOCTL command is executed on the character device to determine whether the USB device has been loaded with a driver; When the USB device has a driver loaded, the binding relationship between the USB device and the driver is released.

4. The method according to any one of claims 1-3, characterized in that, The communication with the USB device via the USBFS driver includes: A read thread is created using the aforementioned USBFS driver; The read thread is bound to the endpoint in the input direction so that the read thread reads the endpoint in the input direction in a blocking manner to obtain data from the USB device.

5. The method according to any one of claims 1-3, characterized in that, The method of communicating with the USB device through the USBFS driver also includes: A write thread is created using the aforementioned USBFS driver; The write thread is bound to an endpoint in the output direction to write data to the endpoint in the output direction, thereby writing data to the USB device.

6. The method according to claim 5, characterized in that, The step of writing data to the endpoint in the output direction via the write thread includes: The write thread assembles the data into a URB BULK package; Write the URB BULK packet to the endpoint in the output direction.

7. A USB driverless communication device, characterized in that, The device includes: The enumeration module is used to enumerate the inserted USB devices and obtain the enumeration information of the USB devices; The analysis module is used to determine the major device number and minor device number created by the USB device in the host device based on the enumeration information. The major device number is used to distinguish different types of devices, and the minor device number is used to distinguish multiple devices of the same type. A communication module is used to create a character device based on the major device number and the minor device number, and bind the USB device to the usbfs driver through the character device. The usbfs driver is pre-configured in the kernel of the host device and communicates with the USB device through the usbfs driver. Specifically, in the aspect of creating a character device based on the major device number and the minor device number, the communication module is used for: The character device is dynamically created using the mknod interface based on the major device number and the minor device number.

8. An electronic device, characterized in that, The method includes a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the one or more programs include instructions for performing the steps of the method of any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is executed by a processor to implement the method as described in any one of claims 1-6.

Images