Skip to end of metadata
Go to start of metadata

Microsoft offers class drivers for some standard USB classes. These drivers can also be called native drivers. A complete list of the native drivers can be found in the MSDN online documentation on the page titled “USB class drivers included in Windows”. If a connected device belongs to a class for which a native driver exists, Windows automatically loads the driver without any additional actions from you. If a vendor-specific driver is required for the device, a manufacturer’s INF file giving instructions to Windows for loading the vendor-specific driver is required. In some cases, a manufacturer’s INF file may also be required to load a native driver.

When the device has been recognized by Windows and is ready for communication, your application may need to use a Globally Unique IDentifier (GUID) to retrieve a device handle that allows your application to communicate with the device.

The following sections explain the use of INF files and GUIDs.  Table - Micrium USB Classes Concerned by Windows USB Device Management shows the USB classes to which the information in the following sub-sections applies.

SectionMicrium USB classes
About INF FilesCDC, PHDC and Vendor
Using GUIDsHID, PHDC and Vendor
Table - Micrium USB Classes Concerned by Windows USB Device Management

About INF Files

An INF file is a setup information file that contains information used by Windows to install software and drivers for one or more devices. The INF file also contains information to store in the Windows registry. Each of the drivers provided natively with the operating system has an associated INF file stored in C:\WINDOWS\inf. For instance, when an HID or MSC device is connected to the PC, Windows enumerates the device and implicitly finds an INF file associated to an HID or MSC class that permits loading the proper driver. INF files for native drivers are called system INF files. Any new INF files provided by manufacturers for vendor-specific devices are copied into the folder C:\WINDOWS\inf. These INF files can be called vendor-specific INF files. An INF file allows Windows to load one or more drivers for a device. A driver can be native or provided by the device manufacturer.

Table - Windows Drivers Loaded for each Micrium USB Class shows the Windows driver(s) loaded for each Micrium USB class:

Micrium classWindows driverDriver typeINF file type
Audio Usbaudio.sys NativeSystem INF file
CDC ACMusbser.sysNativeVendor-specific INF file
HIDHidclass.sys
Hidusb.sys
NativeSystem INF file
MSCUsbstor.sysNativeSystem INF file
Vendorwinusb.sysNativeVendor-specific INF file
Table - Windows Drivers Loaded for each Micrium USB Class

When a device is first connected, Windows searches for a match between the information contained in system INF files and the information retrieved from device descriptors. If there is no match, Windows asks you to provide an INF file for the connected device.

An INF file is arranged in sections whose names are surrounded by square brackets []. Each section contains one or several entries. If the entry has a predefined keyword such as “Class”, “Signature”, etc, the entry is called a directive.  Listing - Example of INF File Structure presents an example of an INF file structure:

; =================== Version section =====================
[Version]                                                                     (1)
Signature = "$Windows NT$"
Class     = Ports
ClassGuid = {4D36E978-E325-11CE-BFC1-08002BE10318}
 
Provider=%ProviderName%
DriverVer=01/01/2012,1.0.0.0
 
; ========== Manufacturer/Models sections =================
 
[Manufacturer]                                                                (2)
%ProviderName% = DeviceList, NTx86, NTamd64
 
[DeviceList.NTx86]                                                            (3)
%PROVIDER_CDC% = DriverInstall, USB\VID_fffe&PID_1234&MI_00
[DeviceList.NTamd64]                                                          (3)
%PROVIDER_CDC% = DriverInstall, USB\VID_fffe&PID_1234&MI_00
 
; ================ Installation sections ==================                   (4)
 
[DriverInstall]                                                 
include   = mdmcpq.inf
CopyFiles = FakeModemCopyFileSection
AddReg    = LowerFilterAddReg,SerialPropPageAddReg
 
[DriverInstall.Services]                                        
include    = mdmcpq.inf
AddService = usbser, 0x00000002, LowerFilter_Service_Inst
 
[SerialPropPageAddReg]                                          
HKR,,EnumPropPages32,,"MsPorts.dll,SerialPortPropPageProvider"
 
; ================== Strings section ====================== 
[Strings]                                                                     (5)
ProviderName = "Micrium"
PROVIDER_CDC = "Micrium CDC Device"
Listing - Example of INF File Structure

(1) The section [Version] is mandatory and informs Windows about the provider, the version and other descriptive information about the driver package.

(2) The section [Manufacturer] is mandatory. It identifies the device’s manufacturer.

(3) The following two sections are called Models sections and are defined on a per-manufacturer basis. They give more detailed instructions on the driver(s) to install for the device(s). A section name can use extensions to specify OSes and/or CPUs the entries apply to. In this example, .NTx86 and .NTamd64 indicate that the driver can be installed on an NT-based Windows (that is Windows 2000 and later), on x86- and x64-based PC respectively.

(4) The installation sections actually install the driver(s) for each device described in the Model section(s). The driver installation may involve reading existing information from the Windows registry, modifying existing entries of the registry or creating new entries into the registry.

(5) The section [Strings] is mandatory and it is used to define each string key token indicated by %string name% in the INF file.

Refer to the MSDN online documentation on this web page for more details about INF sections and directives: http://msdn.microsoft.com/en-us/library/ff549520.aspx .

You will be able to modify some sections in order to match the INF file to your device characteristics, such as Vendor ID, Product ID and human-readable strings describing the device. The sections are:

  • Models section
  • [Strings] section

To identify possible drivers for a device, Windows looks in the Models section for a device identification string that matches a string created from information in the device’s descriptors. Every USB device has a device ID, that is a hardware ID created by the Windows USB host stack from information contained in the Device descriptor. A device ID has the following form:

USB\Vid_xxxx&Pid_yyyy

xxxx, yyyy, represent the value of the Device descriptor fields “idVendor” and “idProduct” respectively (refer to the Universal Serial Bus Specification, revision 2.0, section 9.6.1 for more details about the Device descriptor fields). This string allows Windows to load a driver for the device. You can modify xxxx and yyyy to match your device’s Vendor and Product IDs. In Listing - Device Configuration Template, the hardware ID defines the Vendor ID 0xFFFE and the Product ID 0x1234.

Composite devices, formed of several functions, can specify a driver for each function. In this case, the device has a device ID for each interface that represents a function. A device ID for an interface has the following form:

USB\Vid_xxxx&Pid_yyyy&MI_ww

ww is equal to the “bInterfaceNumber” field in the Interface descriptor (refer to the Universal Serial Bus Specification, revision 2.0, section 9.6.5 for more details on the Interface descriptor fields). You can modify ww to match the position of the interface in the Configuration descriptor. If the interface has the position #2 in the Configuration descriptor, ww is equals to 02.

The [Strings] section contains a description of your device. In Listing - Example of INF File Structure, the strings define the name of the device driver package provider and the device name. You can see these device description strings in the Device Manager. For instance,  Figure - Windows Device Manager Example for a CDC Device shows a virtual COM port created with the INF file from Listing - Example of INF File Structure. The string “Micrium” appears under the “Driver Provider” name in the device properties. The string “Micrium CDC Device” appears under the “Ports” group and in the device properties dialog box.

 Windows Device Manager Example for a CDC Device
Figure - Windows Device Manager Example for a CDC Device

Using GUIDs

A Globally Unique IDentifier (GUID) is a 128-bit value that uniquely identifies a class or other entity. Windows uses GUIDs for identifying two types of device classes:

  • Device setup class
  • Device interface class

Windows assigns a device setup GUID to devices that are installed in all the same way, and which all use the same class installer and co-installers. Class installers and co-installers are DLLs that provide functions related to device installation. There is a GUID associated with each device setup class. System-defined setup class GUIDs are defined in devguid.h. The device setup class GUID defines the ..\CurrentControlSet\Control\Class\ClassGuid registry key under which to create a new subkey for any particular device of a standard setup class. A complete list of system-defined device setup classes offered by Microsoft Windows® is available on MSDN online documentation.

device interface GUID provides the mechanism that applications use to communicate with the driver that has been assigned to devices in a class. A class or device driver can register one or more device interface classes to enable applications to learn about and communicate with devices that use the driver. Each device interface class has a device interface GUID. Upon a device’s first attachment to the PC, the Windows I/O manager associates the device and the device interface class GUID with a symbolic link name, also called a device path. The device path is stored in the Windows registry and persists across system reboot. An application can retrieve all the connected devices within a device interface class. If the application has gotten a device path for a connected device, this device path can be passed to a function that will return a handle. This handle is passed to other functions in order to communicate with the corresponding device.

Three of Micrium’s USB classes are provided with Visual Studio 2010 projects. These Visual Studio projects build applications that interact with a USB device. They use a device interface class GUID to detect any attached device belonging to the class.  Table - Micrium Class and Device Interface Class GUID shows the Micrium class and the corresponding device interface class GUID used in the class Visual Studio project.

Micrium USB classDevice interface class GUIDDefined in
HID{4d1e55b2-f16f-11cf-88cb-001111000030}app_hid_common.h
PHDC{143f20bd-7bd2-4ca6-9465-8882f2156bd6}usbdev_guid.h
Vendor{143f20bd-7bd2-4ca6-9465-8882f2156bd6}usbdev_guid.h
Table - Micrium Class and Device Interface Class GUID

The interface class GUID for the HID class is provided by Microsoft as part of system-defined device interface classes, whereas the interface class GUID for PHDC and Vendor classes have been generated with Visual Studio 2010 using the utility tool, guidgen.exe. This tool is accessible from the menu Tools and the option Create GUID or, through the command-line by selecting the menu Tools, option Visual Studio Command Prompt and by typing guidgen at the prompt.

  • No labels