Unit USB

From Ultibo.org
Revision as of 05:41, 15 September 2016 by Ultibo (Talk | contribs)

Jump to: navigation, search

Return to Unit Reference


Description


USB

This unit implements the USB core software that does not depend on the specific host controller hardware and is not specific to any single USB device or platform.

Features and limitations:

  • This driver is written to be compatible with USB 2.0. USB 3.0 devices work correctly when operating in USB 2.0 compatible mode, actual support for USB 3.0 host controllers and native super speed modes will require some modification to this driver.
  • Not all USB transfer types and speeds are supported yet. This depends on the Host Controller Driver, see USBRequestSubmit.
  • This driver does not attempt to do any intelligent power management, bandwidth allocation, or transfer scheduling. Devices are always set to their first listed configuration regardless of power requirements. Requests are simply passed to the Host Controller Driver in the order submitted, the Host Controller Driver is responsible for doing any more intelligent scheduling if desired.
  • This driver does not support multiple configurations per USB device. If a device happens to have multiple configurations, the first one will be assigned (see devices below for more information).
  • By design, it is possible to implement a host controller driver for different host controller hardware without changing any of this code, as long as the host controller driver provides the functions declared in TUSBHost (Start, Stop, Reset, Submit and Cancel).
  • By design, this driver has a hard-coded dependency on the USB hub driver because USB is useless without hubs.


To initialize this core USB driver, USBInit must be called by the system startup code. See that function for details.

If the flag USB_AUTOSTART is not set then USBStart must be called to start the USB core. See that function for details.

The other functions exported by this core USB driver are mostly intended to be used by USB device drivers.

Debugging messages in this driver can be enabled by changing the value of USB_DEFAULT_LOG_LEVEL and by enabling the USB_DEBUG define in GlobalDefines.

Be careful when enabling USB debugging as the USB core can generate a lot of messages due to constant polling of interrupt endpoints on devices such as hubs, keyboards and mice.

USB Device

USB devices are the generic implementation of anything that can be connected to the USB bus. All USB devices require a driver to implement the specific behaviour of the device but at the generic level each device will have:

  • One or more configurations available. The USB core will first offer the device to drivers without a configuration being selected, the driver may choose a specific configuration if required otherwise the core will simply select the first available configuration.
  • One or more interfaces available. On devices with multiple interfaces, the USB core supports different drivers binding to different interfaces. This way combination devices are supported.
  • One or more endpoints available. All devices must have a control endpoint and most devices will have one or more bulk, interrupt or isochronous endpoints as well. The USB core will only communicate with the control endpoint to perform generic operations like reading the desriptors and assigning a device addresss.


Drivers are expected to understand which endpoints they need to communicate with to provide the device specific functionality.

Devices are considered dynamic by the USB core and can be connected or disconnected at any time. The hub driver is responsible for attaching and detaching devices in response to hub status change events and for binding or unbinding drivers as devices are added or removed.

Constants


To be documented

Type definitions


To be documented

Public variables


To be documented

Function declarations


To be documented


Return to Unit Reference