Versatility
USB’s four transfer types and three speeds make the interface feasible for
many types of peripherals. There are  transfer types suited for exchanging
large and small blocks of data, with and without time constraints. For data
that can’t tolerate delays, USB can guarantee bandwidth or a maximum time
between transfers. These abilities are especially welcome under Windows,
where accessing peripherals  in real time is often a challenge. Although the
operating system, device drivers, and application software can introduce
unavoidable delays, USB makes it as easy as possible to achieve transfers that
are close to real time.
Unlike other interfaces, USB doesn’t assign specific functions to signal lines
or make other assumptions about how the interface will be used. For exam-
ple, the status and control lines on the PC’s parallel port were defined with
the intention of communicating with line printers. There are five input lines
with assigned functions such as indicating a busy or paper-out condition.
When developers began using the port  for scanners and other peripherals
that send large amounts of data to the PC, having just five inputs was a lim-
itation. (Eventually the interface was enhanced to allow eight bits of input.)
USB makes no such assumptions and is suitable for just about any periph-
eral type.
For communicating with common peripheral types such  as printers, key-
boards, and drives, USB has defined classes that specify device requirements
and protocols. Developers can use the classes as a guide instead of having to
reinvent everything from the ground up.

Operating System Support
Windows 98 was the first Windows operating system with reliable support
for USB, and the editions that have followed, including Windows 2000,
Windows Me, Windows XP, and Windows Server 2003, support USB as
well. This book focuses on Windows programming for PCs, but other com-
puters and operating systems also have USB support, including Apple Com-
puter’s Macintosh and the Linux operating system for PCs. Some real-time
kernels also support USB.
A claim of operating-system support for USB can mean many things. At the
most basic level, an operating system that supports USB must do three
things:

• Detect when devices are attached to and removed from the system.
• Communicate with newly attached devices to find out how to exchange
data with them.
• Provide a mechanism that enables software drivers to communicate with
the computer’s USB hardware and the  applications that want to access
USB peripherals.

At a higher level, operating system support may also mean the inclusion of
class drivers that enable application  programmers to access devices. If the
operating system doesn’t include a driver appropriate for a specific periph-
eral, the peripheral vendor must provide the driver.
With each new edition of Windows, Microsoft has added class drivers. Sup-
ported device types in recent Windows editions include human interface
devices (keyboards, mice, game controllers), audio devices, modems,
still-image and video cameras, scanners, printers, drives, and smart-card
readers. Filter drivers can support device-specific features and abilities
within a class. Applications use Application Programming Interface (API)
functions or other operating-system components to  communicate with
device drivers.
For devices that aren’t in supported classes, some vendors of USB peripheral
controllers provide drivers that developers can use with the vendor’s control-
lers.
USB device drivers use the Windows Driver Model (WDM), which defines
an architecture for drivers that run under Windows 98 and later Windows
editions. The aim is to enable developers to support multiple Windows edi-
tions with a single driver, though some devices may require different drivers
for Windows 98/Windows Me and for Windows 2000/Windows XP.
Because Windows includes low-level  drivers that handle communications
with the USB hardware, writing a USB device driver is typically easier than
writing drivers for devices that use other interfaces.

Peripheral Support
On the peripheral side, each USB device’s hardware must include a control-
ler chip that manages the details of USB communications. Some controllers
are complete microcontrollers that include a CPU, program and data mem-
ory, and a USB interface. Other controllers must interface to an external
CPU that communicates with the USB controller as needed.
The peripheral is responsible for responding to requests to send and receive
data used in identifying and configuring the device and for reading and
writing other data on the bus. In some controllers, some functions are
microcoded in hardware and don’t need to be programmed.
Many USB controllers are based on popular architectures such as Intel Cor-
poration’s 8051 or Microchip Technology’s PICMicro®, with added circuits
and machine codes to support USB communications. If you’re already
familiar with a chip architecture that has a USB-capable variant, you don’t
need to learn an entirely new architecture. Most peripheral manufacturers
provide sample code for their chips. Using this code as a starting point can
save much time.

USB Implementers Forum
With some interfaces, you’re pretty much on your own when it comes to
getting a design up and running. With USB, you have plenty of help via the
USB Implementers Forum, Inc. (USB-IF) and its Web site (www.usb.org).
The USB-IF is the non-profit corporation founded by the companies that
developed the USB specification.
The USB-IF’s mission is to support the advancement and adoption of USB
technology. To that end, the USB-IF offers information, tools, and tests.
The information includes the specification documents, white papers, FAQs,
and a Web forum where developers can discuss USB-related topics. The
tools provided by the USB-IF include software and hardware to help in
developing and testing products. The support for testing includes develop-
ing compliance tests to verify proper operation and holding compliance
workshops where developers can have their products tested and earn the
rights for their devices to display the USB logo.