USB Hardware and Software Knowledge 5: wince USB device driver guide

With the increasing number of USB devices, we have become more involved in driver development for USB devices. Through this article, I hope that more friends can understand the implementation process of the driver model and sample program for USB devices in Windows CE, based on the sample code, straighten out the development idea of the driver for the USB device. Before looking at the sample program, let's look at it first:

In this figure, we can clearly see the structure between the host and physical peripherals. On the host end, the usbd module and the HCD module use the default pipe to access a common logical device, in fact, usbd and HCD are a set of abstract logical interfaces for accessing all USB devices. They are responsible for managing the connection, loading, removal, data transmission, and general configurations of all USB devices. HCd is a host control driver and provides underlying function access services for usbd,Usbd is a USB bus driver located on the upper layer of HCD. It uses HCD services to provide high-level Abstract Functions..

During the data transmission process, the operation process is generally performed in the following order: ① the USB device driver initializes the data transmission, that is, a data transmission request is sent to the usbd module through the usbd interface function. ② The usbd module divides the request into several separate transactions. ③ The HCD module emits the transaction order. ④ The hardware of the master controller executes transactions.

With our understanding of this structure, we can clearly understand that what we want to write is the top-end USB device driver, which works on usbd, in fact, our work is to use the interface provided by usbd to complete the USB device driver for a specific physical device, and it is not related to other parts temporarily.

(1) USB folder in BSP

Take 6.5 as an example. The path is public/common/oak/Drivers/USB.

The USB folder is divided into several folders, including class, clients, common, HCD, Inc, and usbd. the INC and common folders have a lock. C program, the code is very simple, just an encapsulation body similar to the critical section, can protect the multi-thread read/write access to the same memory area, you can leave it alone. The clients folder may have been originally used by Microsoft developers to place device drivers, but it was not released and was not deleted at the time of release. Usbd and HCD are the aforementioned underlying drivers, which contain many subfolders and programs. Because we only use USB drivers, we will not analyze these two parts.
The focus is on the class folder. It can be expanded to include the common, hid, printer, and storage folders. Similarly, the source programs stored in common are shared by hid, printer, and storage. Hid is a sample driver for a USB input device such as a keyboard or mouse, printer is a sample driver for a USB printer, and storage is a sample program for a USB storage device such as a USB flash drive.

(2) driver header file

Take the USB storage device as an example. Expand the storage folder. The INC folder contains the header file, the class is the driver of the USB storage device, and the disk is the disk driver. Here is why there are two drivers. Let me briefly explain them.
The driver works between the hardware and the operating system. It has two functions. One is to forward the operation of the operating system to control the hardware in the form of a specified hardware device; the other is to provide this access interface to the operating system. For example, the USB flash drive, on the one hand, the driver needs to convert the operating system's identification, reading, and writing operations on the USB flash drive into the USB flash drive; on the other hand, it also tells the operating system that this is a USB flash drive, it can be used as a folder or file system and can accept standard file operation commands. Therefore, there are two drivers.

There is also a folder/public/common/DDK/INC, which is a header file related to the device driver. For USB devices, the related files include usb100.h and usbtypes. h, usbdi. h. The definitions of USB in the front two items fully comply with USB specifications, while USB di. the content in the hfile is the interface description provided by the usbd bus driver to the USB driver. This header file must be included in the development of the USB driver, in this way, the prototype of the usbd interface can be obtained.
Attachment) load the USB device driver for easy setup. 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 is based on the supplier information of your device. The device categories, subclasses, protocols, and other descriptions can be found in the USB specification.

(3) Main Functions of Device Drivers

The following three functions must be implemented by the USB driver:
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.

USB deviceattach is used when a USB device is connected to the master computer. The usbd module calls this function to initialize the USB device, obtain information about the USB device, configure the USB device, and apply for required resources. USB installdrive is called first when the driver of the USB device is loaded for the first time. It enables the driver to create the required registration key, write the registry information required by a driver to the HKEY_LOCAL_MACHINE/Drivers/USB/clientdrivers directory, such as the device name. Note that the USB device driver uses the registerclientdriverid () and registerclientsettings () functions instead of the standard registry function to register the corresponding device information. Usbuninstalldriver is called when a user deletes a USB device driver. It deletes the registration key and releases other related resources. It deletes all registration keys created by the driver's usbinstalldriver () function by calling the unregisterclientsettings () and unregisterclientdriverid () functions. Therefore, we need to strictly follow the prototype of the three functions in the driver, otherwise it cannot be recognized by the Device Manager.
In addition to the three functions, there is also a function pointer pointing to: * 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, this function is used to read version information, perform registry operations, and register device drivers. These functions include 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 convenience, 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 this struct variable as follows: typedef struct _ usb_funcs, * pusb_funcs, * lpusb_funcs;
At this point, we found that most of the USB work has been completed by usbd. to implement our own device drivers, we only need to use these pointers or functions to implement four of our own functions, then we can match our own device.

(4) Understanding USB storage instances
We will go to the drivers/USB/class/storage/class folder to learn about the two header files: storage/INC/usbmsc. H and storage/class/usbmscp. h. The former is the header file shared by the USB storage device, and the latter is the header file that needs to be changed according to your own device.

Let's first look at the former. In the header file usbmsc. H, many constants are defined on the front side, including subclasses and Protocol constants. Where does this come from? These values are derived from the USB device specification and are defined in the specification. Therefore, the values here must be consistent with those in the USB specification. The downstream command block struct and data block struct are used to communicate with USB devices. data can be transmitted through these two struct instances and USB devices.

Let's take a look at the USB mscp. h header file, which needs to be modified according to your own needs and the USB device. For example, driver_name_sz is the name of the driver, and reset_timeout is the default value for timeout. The setting of usbmsc_driver_settings is also very important,This setting corresponds to the usb_driver_settings struct in usbdi. h.To meet the requirements of my own devices, we usually need to set dwvendorid and dwproductid to the corresponding device values. For example, the vendorid Of My USB flash drive is 0x058f, And the productid is 0x9321, then I will write the corresponding values in the corresponding positions. At the same time, the system registry also uses these two values to modify the registry key so that the Device Manager can smoothly find my device driver. There is also a _ usbmsc_device struct, which is used to describe your own USB storage device, it is the most important data structure that encapsulates usbd function table pointers, disk device pointers, pipelines, and configuration items. In driver implementation, this data structure is the key parameter,

Well, after learning about these two header files, we will go to the most critical part, the source program. Let's take a look at the usbmsc. c file. Why should I read this file first instead of several other files in the same folder? In this folder, there is a usbmsc. def file, we all know that it defines the export function, usually a program file with the same name as it will contain the dllentry entry, since the entry is here, then we should first look at this file. Below the dllentry entry function is the usbinstalldriver () function, which is used to perform registry operations related to the USB device. The main statement is:
BRC = registerclientdriverid (wsusbdeviceid );
BRC = registerclientsettings (szdriverlibfile, wsusbdeviceid, null, & usbdriversettings );
That is, first register the device category, and then the device details. The registration-related functions are mentioned above. Here we can see the importance of usbd to the device driver.
(5) Storage instance function explanation

Looking down, we found the USB deviceattach () function, which is the most important thing. After a USB device is inserted into the plug-in, how does the operating system identify it, how can I access it as a folder?

Let's take a look at row 4th of the program. Here we have a judgment Statement, which is used to determine whether the inserted device is of the usbmsc_interface_class type. This constant is in usbmsc. the H file defines that if the device is not a USB storage device, the function is terminated, that is, the driver can only process USB storage devices. When the device meets the requirements of this driver, it will be resolved through the parseusbdescriptors () function, which will be implemented in the following program, let's take a look at the function body of this function. Obviously, it is configuring various configurations for the device.

Next, allocate the memory, set the flag, and read the information from the registry. Note: The registry information read here is
[HKEY_LOCAL_MACHINE/Drivers/USB/clientdrivers/mass_storage_class/6]
"DLL" = "usbdisk6.dll"
"Prefix" = "DSK"
"Folder" = "USB disk"
"IOCTL" = DWORD: 4
"Iclass" = "{A4E7EDDA-E575-4252-9D6B-4195D48BB865 }"
From this we can see that, through the registry here, the driver can know which form and DLL the device will provide interfaces to the operating system.

The most important part is in the next loaddriver () clause. Load the DLL file of another driver, which is the usbdisk6.dll file in the above registry. Add one to the counter, obtain the address of the usbdiskattach function and usbdiskdetach function in the file. After usbdisk6.dll is called, the operating system processes the program in the file as a disk or as a folder, you can control the read and write operations. We can also take a look at this function of the HID device. It also allows the operating system to recognize the USB device as a mouse device. Next we need to understand how the Operating System reads and writes specific devices through an abstract disk?

Let's first look at the USB/class/storage/Disk/sci2/usbdisk6.def file. In this file, we can see that the DLL has exported a total of 14 functions, two of which are the USB diskattach and USB diskdetach called by the device driver in the previous content, the rest is a set of stream-driven interfaces starting with DSK. It is easy to see that USB disk provides services to the operating system in the form of stream-driven.

(6) flow drive for USB devices

Follow these steps to attach a USB stream DRIVER:

(1) Select the prefix of the file name that represents the device. The prefix is very important. The Device Manager uses the prefix in the Registry to identify the device. In addition, This prefix is also used as the prefix of the entry point function during stream interface naming. If the device prefix is XXX, the stream interface corresponds to xxx_close and xxx_init.

(2) set each entry point function of the driver. The so-called entry point refers to the standard file I/O interface provided to the Device Manager. After a DLL is generated, replace xxx with the prefix of the device file name. Therefore, each loaded stream interface driver must implement a set of standard functions, such as xxx_init (), xxx_iocontrol (), and xxx_powerup, used to complete standard file I/O functions and power management.

(3) create a. Def file. After the Device Manager initializes the flow interface function compiled by the USB device, A. Def file must be created. The def file defines the interface set to be exported by the DLL, and most of the loaded stream drivers exist in the form of DLL, so the DLL and Def file names should be unified. The def file tells the linking program what kind of function to output, and finally compiles the driver into the kernel, so that the flow interface driver of the USB device can be called by the application.

(4) create a table entry for the driver in the registry. Create a driver entry point in the registry so that the Device Manager can identify and manage the driver. In addition, the Registry can store additional information that can be used after the driver is running.

Let's look at the program file disk. C. Find the dsk_read and dsk_write functions. Both functions are shown
Unreferenced_parameter (pdevice); this implementation means that the user cannot use this device through the regular readfile and writefile functions. What should I do? We should immediately think of the dsk_iocontrol () function,When some devices cannot use regular file operation functions, the deviceiocontrol () User function can be used, and this function will call the dsk_iocontrol function in the driver..
In this function, we find the handler for commands such as ioctl_disk_read. The most critical sentence is scsirwsg (pdevice, psgreq, pdevice-> Lun, bread ), that is, a scsirwsg function is called. In this function, we find that it calls the scsireadwrite () function again to perform read and write operations. In this function, we call the most important one, that is, the usbsdatatransfer () function, it is in the driver of the USB device.
Through this process, we found that all the SCSI functions are only preparing some buffers and data structures, and they are not operating on the hardware, the USB driver is used to operate the hardware device. in the C program, find the usbsdatatransfer function, which is very simple. Call cbit_datatransfer () or bot_datatransfer () based on the transmission protocol.

Http://hi.baidu.com/xjh_sz520/blog/item/a05ddddec444eeb1cd1166d2.html ()

Http://hi.baidu.com/btkxql/blog/item/4ca38023b4cec75f9822ed2b.html ()