[Article] Author: Li Hong time: 2004-10-06 Source: Computer and Information Technology Editor: Ark
Abstract This article describes the basic concepts, structures, and features of the WDM USB device driver, and illustrates methods for developing using DriverWorks.
Key words WDM; USB device driver; driverworks
preface
General Serial Bus USB is a new type of communication standard promoted by companies such as Kangbo, Microsoft, IBM, DEC, etc., which has the advantages of convenient installation, high bandwidth, easy extension, and has gradually become the development of modern data transmission. trend. When developing USB devices, the design of the device driver is an important technical link, which directly affects the performance of the entire equipment system. Windows98 and its higher version of the operating system provide comprehensive support for the USB bus and uses the WDM driver model instead of the VXD device driver. WDM supports USB protocol and provides an efficient development platform. Therefore, WDM has become a technique that is necessary to develop USB peripheral drivers.
Windows Driver Model (WDM)
There are three types of drivers in the Windows environment. One is VXD (Virtual Device Driver, virtual device driver), originated in the Windows 3.1 era, used in the Windows 95/98 / ME operating system; one is KMD (kernel mode driver , Kernel mode driver), used under Windows NT; there is a class is WDM (Win32 Driver Mode, Win32 driver model), is Microsoft started from Windows 98, a new drive type launched, is a cross-platform The driver model, not only such a WDM driver can also run on a non-Intel platform without modifying the source code, is not exaggerated, WDM calculates the driver framework for the 21st century.
WDM is developed on the NT4.0 driver structure, so it is very similar to NT4.0 drivers, but it has an essential improvement, adding to plug and play (PNP), advanced power management (PowerManagement), support for Windows Management Interface (WML). More importantly, WDM is a universal drive mode that provides a series of driver classes including USB, IEEEEEL394, and HID.
1, hierarchical structure of the WDM driver
The WDM architecture is hierarchically processed, that is, the device driver is divided into several layers, typically divided into: high-level drivers, intermediate layer drivers, underlying drivers. Each layer is driven to divide the I / O request into a simpler request to transmit it to the lower-level driver. The bottom-up driver After receiving the I / O request, the hardware abstraction layer is functioning with the hardware, thereby completing the I / O request work. Under such an architecture, the above drive layer does not need to be developed over again. As shown in Figure 1
WDM also introduces a functional device object FDO (Functional Device Object) to describe hardware, a PDO corresponding to a real hardware. One hardware only allows a PDO, but can have multiple FDOs, and we are not directly operating hardware in the driver, but the corresponding PDO and FDO are operated. The hierarchical case of the driver and device object is shown in Figure 2.
The bus driver is located at the bottom of the bottom, controls access to all devices on the bus, and creates the device that PDO represents discovery. The main function of the function driver control device is hierarchically in the bus driver, which is responsible for creating the FDO. In the case of USB, the function driver must use a USB-class driver access device. 2, WDM structure of USB driver
The constituent hierarchy of the USB driver is shown in Figure 3. Where the USB client driver communicates with the lower driver through the USB-class driver interface (USBDI) provided by the Windows system.
Before the USB device is available, it must be configured and interface selection, and then the various pipes of the selected interface are available. Based on USBDI, the program will be greatly simplified, and the user does not need to care about the type of IRP, but only needs to construct a USB block in the corresponding distribution routine and send it to the USB device to send it to the USB device.
Access to equipment
WDM is not through the driver name, but through a 128-bit global unique identifier (GUID) to realize the identification of the driver. In terms of application and WDM driver communication, the system is packaged for each user request to form an I / O request package (IRP) structure, send it to the driver, and distinguishes the PDO in IRP, which is sent which device is sent. . The kernel typically runs the code in the driver by sending IRP.
The WDM driver has a primary initialization entry point, that is, a routine that must be called DriveREntry. It has a standard function prototype. When the WDM driver is loaded, the kernel calls the DriveRETRY routine. The DriveREntry routine of the driver must set a series of callback routines to process IRP. Each callback routine has a standard function prototype. The core will call this routine in a suitable environment.
Most WDM device objects are created when the AddDevice routine entry point is called at the Add-Play Manager. After inserting a new device, this routine is called when the system finds the driver configured by the installation information file. After that, a series of plug-and-play IRPs are sent to the driver, and the device driver can perform corresponding functional processing.
USB Device Driver Development Tool Develop USB Device Drivers require specialized development tools, currently have two major categories.
One is a Windows DDK (Device Driver Kit) provided by Microsoft. It has two versions of Windows 98 DDK and Windows 2000 DDK. Windows 98 DDK can develop VXD, KMD, and WDM drivers under Windows 95/98 / ME / NT. Windows 2000 DDK can develop KMD and WDM drivers under Windows 98 / ME / NT / 2000. Since DDK is based on programming methods of assembly language and kernel mode, the task is quite arduous for those who have no deep OS principle and programming levels.
Another category is DriverStudio provided by Numega, which is a large development kit, including development tools such as VToolsd, Softice, and DriverWorks. The VToolsD development package provides the C / C library support for VXD programming, using the QuickVxD tool in vtoolsd to quickly generate the VXD C / C code framework, developers can add their own code based on their respective needs according to their respective needs. DriverWorks is used to develop KMD and WDM drivers, and the DDK function has been encapsulated to develop Windows NT, Windows 2000, and WidnWos98 WDM device drivers provide an automation method.
DriverWorks provides VC Development Wizard Driver Wizard, which can quickly generate the driver's framework according to its prompt. This framework structure provides requests for IRPs in the WDM dynamic environment, and also include classes for simplifying standard-type drivers (such as HID, streams) and bus drivers (such as PCI, and USB) interfaces. In summary, using DriverWorks to develop WDM drivers, it can greatly simplify the workload of developers, shorten the development cycle, and reduce the difficulty of developing drivers. [1]
Develop WDM model USB device drivers with driverWorks
To use DriverWorks, you must first install the following software: DriverStudio2.5, Visualstudio6.0, and Windows2000DDK. Since the class library used by DriverWorks is the package of DDK library functions, you must also compile the required library files [3] in Visual C , which describes how to create their own library files in the VC environment.
(1) Start Visual C .
(2) Select Menu File / Open Workspace. Open the workspace file located in DriverStudio / DriverWorks / Source / VDwlibs.dsw.
(3) Select the menu build / batch building, select the library you want to compile in the pop-up dialog box.
(4) Click Build in the dialog to compile you to the library.
Below, the method of developing a USB device driver using DRiverWorks is explained below.
This USB device has 3 two-way endpoints, and the configuration of each endpoint is as follows:
Endpoint type address buffer (bytes) 0 in / out control (Control) 0x80 / 0x00 16/161 in / out block (BULK) 0x81 / 0x01 16/162 in / out block (BULK) 0x82 / 0x02 64/64
The function that the driver needs to be implemented is to control the brightness and destruction of the LED light on the device, and read and write the device via endpoint 2.
(1) First, start the VC IDE by the shortcut "Setup DDK and Start MSVC". The program pointed to by this shortcut will make some necessary settings, then launch VC IDE so that our program can use DDK and DW header files and libraries.
(2) Select "DriverWizard" from the VC IDE menu "driverStudio", then fill in the project name and the directory by pressing the prompt of the dialog. And press the Wizard Select the driver type to WDM, the bus type is USB.
(3) Press the configuration table of the end to perform the settings of the endpoint. Since the endpoint 0 specified in USB must exist, we only need to define endpoints 1 and endpoint 2.
(4) Select Endpoint 2 Generate Bulk Read and Bulk Write's code, DriverWorks automatically generates read and write code for endpoint 2, without modifying, you can use it directly.
(5) Add an IOCTL to control the LED lights for the USB device. The IOCTL code name is taken as Test_iOctL_LED, and other values are default.
(6) Finally press the "Finish" button, ending Wizard.
In this process, only the steps that need to be modified are described, and the unintended portions can be directly pressing the "Next" button.
At this point, we have created a basic driver, where the block read and write code is automatically generated by DriverWorks, without additional code, only the vendor requests are made through IOCTL, and the LED light is controlled. Code is as follows: NTSTATUS TESTDevice :: TEST_IOCTL_LED_Handler (KIrp I) {NTSTATUS status = STATUS_SUCCESS; t << "Entering TESTDevice :: TEST_IOCTL_LED_Handler," << I << EOL; // TODO: Verify that the input parameters are correct // If not, return STATUS_INVALID_PARAMETER if (! I.IoctlOutputBufferSize () || I.IoctlBuffer () || (I.IoctlInputBufferSizer () = sizeof (UCHAR))!) // TODO: Handle the the TEST_IOCTL_LED request, or // defer the processing of the IRP (ie by queuing) and set // status to STATUS_PENDING. PURB pUrb = m_Lower.BuildVendorRequest (NULL, // transfer buffer 0, // transfer buffer size 0, // request reserved bits (UCHAR) (* PUCHAR ), // request. 1 = led_on, 0 = led_off 0 // value); // transmit status = m_lower.submiturb (purb, null, null, 5000L);} // Todo: Assuming That The Request Was Handled Here. Set Iinformation // TO INDICATE How much data to copy back to the user. I.information () = 0; .status () = status; return status;}
This function controls the LED light, which is transmitted to the device via USB Vendor Request. When REQUEST = 1 means that the L Ed is bright, the request = 0 will let the LED come. It passed by DeviceioControl by the upper application.
Now, the driver is complete, to ensure that the last generated USB driver can be compiled, be sure to set [BASEDIR] and [CPU] and other items in Driver Building in DriverWorks. . After setting, select "Build / Batch Build", perform the correct selection in the pop-up dialog box, then press the "Rebuild" button to generate the final .sys driver.
Conclude
The WDM is a device driver model that has become a unified mode since Windows 2000. At the same time, USB technology has been widely used, and the development of USB device drivers is an essential technology link, while using DriverWorks to develop USB device drivers, simple and convenient.
