In 1994 an alliance of four industrial partners (Compaq, Intel, Microsoft and NEC) started to specify the Universal Serial Bus (USB). The bus was originally designed with these intentions: Connection of the PC to the telephone Ease-of-use Port expansion The specification (version 1.0) was first released in January 1996 and the latest official version 1.1 was released in September 1998 The document is still under development and a version 2.0 was announced in 1999. The USB is strictly hierarchical and it is controlled by one host. The host uses a master / slave protocol to communicate with attached USB devices. This means that every kind of communication is initiated by the host and devices cannot establish any direct connection to other devices. This seems to be a drawback in comparison to other bus architectures but it is not because the USB was designed as a compromise of costs and performance. The master / slave protocol solves implicitly problems like collision avoidance or distributed bus arbitration. The current implementation of the USB allows 127 devices to be connected at the same time and the total communication bandwidth is limited to 12Mbit/s. Howewer use of low speed devices, management of USB "interrupts" and other overheads mean that actual throughput cannot exceed about 8.5Mbit/s under near ideal conditions, and typical performance may be around 2Mbit/s. Most modern motherboard chipsets provide a USB host controller. Older machines which are not equipped with a USB host controller can be upgraded using a PCI cards with a host controller built in. USB host controllers are compatible with either the Open Host Controller Interface (OHCI, by Compaq) or the Universal Host Controller Interface (UHCI, by Intel) standard. Both types have the same capabilities and USB devices work with both host controller types. Basically the hardware of UHCI is simpler and therefore it is cheaper, but needs a more complex device driver, which could cause slightly more CPU load. There are a wide range of USB devices intended for a wide range of purposes, and this means that implementation details can vary widely. A device can be self powered, bus powered or both. The USB can provide a power supply up to 500mA for its devices. If there are only bus powered devices on the bus the maximum power dissipation could be exceeded and therefore self powered devices exist. They need to have their own power supply. Devices that support both power types can switch to self powered mode when attaching an external power supply. Even the maximum communication speed can differ for particular USB devices. The USB specification differentiates between low speed and full speed devices. Low speed devices (such as mice, keyboards, joysticks etc.) communicate at 1.5MBit/s and have only limited capabilities. Full speed devices (such as audio and video systems) can use up to 90% of the 12Mbit/s which is about 10Mbit/s including the protocol overhead.

Version 2.0 of the USB specification is being developed, and is expected to deliver up to 480Mbit/s raw throughput. Physically there exist one, two or four USB ports at the rear panel of a computer. These ports can be used to attach normal devices or a hub. A hub is a USB device which extends the number of ports to connect other USB devices. The maximum number of user devices is reduced by the number of hubs on the bus (i.e. if you attach 50 hubs, then at most 77 (=127-50) additional devices can be attached. Hubs are always full speed devices. If the hub is self powered, then any device can be attached to it. However if the hub is bus powered, then only low power (100mA max) devices can be attached to it. A bus powered hub should not be connected to another bus powered hub - you should alternate between bus powered and self powered hubs. Normally the physical ports of the host controller are handled by a virtual root hub. This hub is simulated by the host controllers device driver and helps to unify the bus topology. So every port can be handled in the same way by the USB subsystem's hub driver (see ). The communication on the USB is done in two directions and uses four different transfer types. Data directed from the host to a device is called downstream or OUT transfer. The other direction is called upstream or IN transfer. Depending on the device type different transfer variants are used: Control transfers are used to request and send reliable short data packets. It is used to configure devices and every one is required to support a minimum set of control commands. The standard commands are: GET_STATUS CLEAR_FEATURE SET_FEATURE SET_ADDRESS GET_DESCRIPTOR SET_DESCRIPTOR GET_CONFIGURATION SET_CONFIGURATION GET_INTERFACE SET_INTERFACE SYNCH_FRAME Further control commands can be used to transfer vendor specific data. Bulk transfers are used to request or send reliable data packets up to the full bus bandwidth. Devices like scanners or scsi adapters use this transfer type. Interrupt transfers are similar to bulk transfers which are polled periodically. If an interrupt transfer was submitted the host controller driver will automatically repeat this request in a specified interval (1ms - 127ms). Isochronous transfers send or receive data streams in realtime with guaranteed bus bandwidth but without any reliability. In general these transfer types are used for audio and video devices. Whenever a USB device is attached to the bus it will be enumerated by the USB subsystem - i.e an unique device number (1-127) is assigned and then the device descriptor is read. The desciptor is a data structure which contains information about the device and its properties. The USB standard defines a hierarchy of descriptors (see ).

A Device Descriptor describes general information about a USB device. It includes information that applies globally to the device and all of the device s configurations. A USB device has only one device descriptor. The Configuration Descriptor gives information about a specific device configuration. A USB device has one or more configuration descriptors. Each configuration has one or more interfaces and each interface has zero or more endpoints. An endpoint is not shared among different interfaces within a single configuration, although a single interface can have several alternate settings which may use the same endpoint. Endpoints may be shared among interfaces that are part of different configurations without this restriction. Configurations can only be activated by the standard control transfer set_configuration. Different configurations can be used to change global device settings, such as power consumption. An Interface Descriptor describes a specific interface within a configuration. A configuration provides one or more interfaces, each with zero or more endpoint descriptors describing a unique set of endpoints within the configuration. An interface may include alternate settings that allow the endpoints and/or their characteristics to be varied after the device has been configured. The default setting for an interface is always alternate setting zero. Alternate settings can be selected exclusively by the standard control transfer set_interface. For example a multifunctional device like a video camera with internal microphone could have three alternate settings to change the bandwidth allocation on the bus. Camera activated Microphone activated Camera and microphone activated An Endpoint Descriptor contains information required by the host to determine the bandwidth requirements of each endpoint. An endpoint represents a logical data source or sink of a USB device. The endpoint zero is used for all control transfers and there is never a descriptor for this endpoint. The USB specification uses the terms pipe and endpoint interchangably. String Descriptors are optional and provide additional information in human readable unicode format. They can be used for vendor and device names or serial numbers. The standard device and interface descriptors contain fields that are related to classification: class, sub-class and protocol. These fields may be used by a host system to associate a device or interface to a driver, depending on how they are specified by the class specification. Valid values for the class fields of the device and interface descriptors are defined by the USB Device Working Group. Grouping devices or interfaces together in classes and then specifying the characteristics in a Class Specification allows the development of host software which can manage multiple implementations based on that class. Such host software adapts its operation to a specific device or interface using descriptive information presented by the device. A class specification serves as a framework defining the minimum operation of all devices or interfaces which identify themselves as members of the class. The HID class consists primarily of devices that are used by humans to control the operation of computer systems. Typical examples of HID class devices include: Keyboards and pointing devices for example, standard mouse devices, trackballs, and joysticks. Front-panel controls for example: knobs, switches, buttons, and sliders. Controls that might be found on devices such as telephones, VCR remote controls, games or simulation devices for example: data gloves, throttles, steering wheels, and rudder pedals. Finding device drivers for USB devices presents some interesting situations. In some cases the whole USB device is handled by a single device driver. In other cases, each interface of the device has a separate device driver.