USB device driver guide (3)

"There are infinite advertisements and limited time." Don't look at the advertisements. Come back soon. (I find myself an advertising genius, but I am familiar with it, as if there is something similar in the game) Previously, we learned about the location structure of the USB driver in CE and the folder structure of the sample driver. Next, we need to know which interfaces usbd provides for us to implement Device Access and driver management functions. Find usbdi. h. Don't tell me you can't find it. No matter what Editor, notepad, Pb, Vc, EVC, or vs you use, open it, let's take a look at what usbd provides for us. The first large struct we see is _ usb_driver_settings. Note that this struct is not a description of the USB device in the USB specification, but is created for the convenience of the CE Device Manager to load the USB device driver. The supplier description, device description, and interface description in this struct are used to match the registry key of the USB device driver in the registry, when the device manager finds that the values of your device match those in the registry, it loads your driver. That is to say, it is a unique identifier that corresponds to your device. The supplier description of this struct must be based on the supplier information of your device. The device categories, subclasses, protocols, and other descriptions can be found in the USB specification, in the USB 100.h header file, a part is also defined in the following sample program. The following three functions must be implemented by the USB driver, which we can see in msdn or other CE documents. These functions are: USB deviceattach: called by the system when the device is loaded Usbinstalldriver: This is called by the system when the device is loaded for the first time. It is used to install registry configuration to search for devices. Usbuninstalldriver: After the device is removed, the Registry configuration written by the previous function is cleared. In this way, we must follow the prototype of the three functions in our driver, otherwise it cannot be recognized by the Device Manager. In fact, in addition to the three, I think the fourth is also necessary. This is the function pointed to by a function pointer: * Lpdevice_policy_routine The Pointer Points to a function that is used to receive notification messages. Since Microsoft says that any USB device must respond to the message of usb_close_device, then the function pointed to by this pointer is naturally necessary to be implemented. Looking down, this is the prototype of a group of functions. These functions are the service interfaces that usbd provides to the device driver. Some functions can be called at will, these functions are used to read version information, perform registry operations, and register device drivers: Getusbdversion registerclientdriverid unregisterclientdriverid registerclientsettings Unregisterclientsettings openclientregistrykey A large number of functions must be called through pointers. Generally, they can only be called in the driver. For example, a _ usb_funcs struct is provided here, each struct member corresponds to a function pointer, so that you can only use one struct variable to use the usbd function in the driver. here we need to remember the struct name, microsoft also defines the struct variable as follows: Typedef struct _ usb_funcs, * pusb_funcs, * lpusb_funcs; Typedef struct _ usb_funcs const * pcusb_funcs; Typedef struct _ usb_funcs const * lpcusb_funcs; Now, we find that most of the USB work has been completed by usbd. to implement our own device driver, we only need to use these pointers or functions, to implement four of our own functions, and then match our own device in it. Is it simple? Yes, you can't scare yourself at the beginning, so you can't do it later.