Compared to serial or parallel ports, the USB is a complex bus. For example, each device that is connected to this bus receives an address, and packets of data are exchanged between the host computer and the addressed device. Additionally, devices can operate at multiple speeds, and devices can be temporarily disconnected from the bus if they do not understand high speed transfers. In general, data transfer on USBs is much more complex and relies on a well-defined protocol that is similar, in some respects, to a low-level network protocol.
For these reasons, USB devices incorporate some "intelligence" so they can correctly handle data packets that are exchanged over the USB. It is not generally possible to implement a USB interface by using discrete electronic components or small scale integrate or medium scale integrate circuits like you can on serial and parallel interfaces. Rather, a microprocessor is typically used on the device to handle communication over the USB.
Because a USB device is complex, you cannot just open and access a USB device from a User Mode application. At the hardware level, a USB device offers several endpoints
. The host can establish a pipe that is connected to each endpoint, and can talk to the device through this pipe. You have to do this work in kernel mode. Therefore, a USB device must have an associated driver. The Plug and Play architecture also requires a driver, because as soon as you plug in the device, the system tries to find a suitable driver for it.
A sample in the Windows DDK, which is named BulkUSB (DDKdir
\src\wdm\usb\bulkusb), allows a user mode application to read from and to write raw data directly to the endpoint of the USB device. The basic job of the sample driver is to copy data to and from the application and the endpoint. You can easily adapt this sample to almost any USB device. However, commercial devices must typically do the following:
- Have a more complete device driver, which abstracts its functionality.
- Offer a higher level programming interface to the user mode application.
- Comply with a specific device interface class (if the device is a common peripheral type).
In summary, there are limited scenarios where this sample can be used with no or little customization:
- For testing purposes
- To familiarize you with USB driver development
- For very simple devices that you know in advance will be accessed by one specific program
A USB device driver that is written for Windows XP and for Windows 2000 using only Windows Driver Model (WDM) functions is portable to Windows Millennium Edition and to Windows 98, generally with few or no changes. For additional information about how to port WDM drivers from Windows XP or from Windows 2000 to Windows Millennium Edition or to Windows 98, see the "References" section (Walter Oney's book, Appendix A).
Some third-party vendors offer pre-built chipsets, which you can incorporate to implement the USB interface. Many vendors also offer hardware development kits with which you can build prototypes around their chipset. For more information, see the "References" section of this article (Walter Oney's book, chapter 11).
Some third-party vendors offer generic USB drivers, which you can customize by using data files without having to use kernel mode programming. Some companies also offer ActiveX components (for example, OCXs) to access their driver from OLE automation clients, such as Microsoft Visual Basic.