Version 3 (modified by 7 years ago) ( diff ) | ,
---|
Universal Serial Bus (USB)
Universal Serial Bus (USB) is an industry standard developed in the mid-90's that defines cables, connectors and communication protocols used in a bus between computers and peripherals.
References:
- AN57294 - USB 101: An Introduction to Universal Serial Bus 2.0 - Cypress App Note does a good job of summarizing
- http://en.wikipedia.org/wiki/USB
Versions
Summary of USB versions:
- USB 1.0 - USB LowSpeed (1.5mbps) and USB FullSpeed (12mbps)
- USB 2.0 - adds USB HighSpeed (480mbps)
- USB 3.0 - adds USB SuperSpeed (10gbps)
Host Controllers
The following types of USB host controllers exist:
- Universal Host Controller Interface (UHCI): Produced by Intel for USB 1.0 and USB 1.1. Using UHCI requires a license from Intel. This controller supports both LowSpeed and Full-Speed.
- Open Host Controller Interface (OHCI): Produced for USB 1.0 and 1.1 by Compaq, Microsoft, and National Semiconductor. Supports Low-Speed and Full-Speed and tends to be more efficient then UHCI by performing more functionality in hardware.
- Extended Host Controller Interface (EHCI): Created for USB 2.0 after USB-IF requested that a single host controller specification be created. EHCI is used for HighSpeed transactions and delegates LowSpeed and FullSpeed transactions to an OHCI or UHCI sister controller.
USB Speeds
The following is a set of supported speeds per USB specification:
- USB LowSpeed (1.5mbps) (USB 1.0 UHCI/OHCI) - Only supports Control and Interrupt transfer types
- USB FullSpeed (12mbps) (USB 1.0 UHCI/OHCI)
- USB HighSpeed (480mbps) (USB 2.0 EHCI)
- USB SuperSpeed (10gbps) (USB 3.0 XHCI)
USB Transfer types
There are four types of transfers in USB:
- Control Transfers Used for sending commands to the device, make inquiries, and configure the device. This transfer uses the control pipe.
- Interrupt Transfers Used for sending small amounts of bursty data that requires a guaranteed minimum latency. This transfer uses a data pipe.
- Bulk Transfers Used for large data transfers that use all available USB bandwidth with no guarantee on transfer speed or latency. This transfer uses a data pipe.
- Isochronous Transfers Used for data that requires a guaranteed data delivery rate. Isochronous transfers are capable of this guaranteed delivery time due to their guaranteed latency, guaranteed bus bandwidth, and lack of error correction. Without the error correction, there is no halt in transmission while packets containing errors are resent. This transfer uses a data pipe.
USB Device Classes
USB has a list of recognized and approved USB device classes in order to simplify driver development. The most common device classes are:
- Human Interface Device (HID):
- Supports Control and Interrupt transfer types
- has a max FullSpeed rate of ~64KB/s
- standard driver in all modern OS
- Mass Storage Device (MSD)
- standard driver in all modern OS
- Communication Device Class (CDC)
- Supports Bulk and Isochronous transfer types
- has a max FullSpeed rate of ~80KB/s
- standard driver in all modern OS
- Vendor (Vendor Specific)
- Supports all four transfer types
- has a max FullSpeed rate of ~1MB/s
- requires custom driver (but can be userspace through libusb)
Human Interface Device
Often vendors choose HID device class to allow control via userspace applications without needing a OS specific driver (as all modern OS's have an HID driver).
The HIDAPI (open-source and cross-platform Linux/Windows/MacOS) provides simple USB HID enumeration, read and write functions.
The HID device class uses HID reports to describe details about the data input and output a device supports. The sub class can be 'Generic HID' and the report type can be 'Vendor Defined' which makes it generic. The maximum report size is 64B.
Vendor Specific
Vendors sometimes choose to implement a Vendor specific device which has an undefined class.
The libusb (open-source and cross-platform Linux/Windows/MacOS) can be used for generic USB communication. Vendor specific commands can be implemented.
Gateworks USB devices
In an effort to define these options available to developers, Gateworks has created the following table with the fields as follows:
- Family: Board Product family.
- SBC: The base SBC (Single Board Computer) model that the proceeding rows apply to.
- USB Port: The particular USB port and controller in question.
- Ref: The reference part designator that can be found on the PCB silkscreen (white lettering).
- Reset Type: How the usb device is re-enumerated and/or reset, which will be either:
- Soft - Both data lines of the usb bus are driven low, signalling a reset condition that is handled differently from device to device.
- VBUS - The 5V power rail of the port is brought down (when indicated with the manual control of a gpio).
- Bus-Device[.Port]: The bus, device, and port (if behind a hub) of the port in question.
- Bus Steering: The conditions for the bus to be electrically steered to this port if applicable.
In all cases the miniPCIe slots get their VBUS directly from the board power rail, which has no power control.
Gateworks USB device Table:
Family | SBC | USB Port | Ref | Reset | Bus-Device[.Port] | Bus Steering |
---|---|---|---|---|---|---|
Newport | GW630x | Front Panel Top XHCI | J21 | Soft | 1-1.2 | |
Front Panel Bot XHCI | J21 | Soft | 1-1.1 | |||
Bot Right miniPCIe EHCI | J9 | Soft | 1-1.3 | |||
Bot Mid miniPCIe EHCI | J10 | Soft | 1-1.4 | |||
Bot Left miniPCIe XHCI | J11 | Soft | 3-1 | |||
Ventana | GW51xx | Front Panel OTG | J20 | Soft/VBUS | 1-1 | |
miniPCIe USB EHCI | J6 | Soft | 2-1 | |||
GW52xx | Front Panel OTG | J15 | Soft/VBUS | 1-1 | gpio2 low (default) | |
Bot Right miniPCIe EHCI | J7 | Soft | 2-1 | |||
Bot Left miniPCIe OTG | J8 | Soft | 2-1 | gpio2 high | ||
GW53xx | Front Panel OTG | J20 | Soft/VBUS | 1-1 | ||
Front Panel EHCI | J18 | Soft/VBUS | 2-1.1 | |||
Bot Left miniPCIe EHCI | J9 | Soft | 2-1.2 | |||
Bot Center miniPCIe EHCI | J8 | Soft | 2-1.3 | |||
Bot Right miniPCIe EHCI | J6 | Soft | 2-1.4 | |||
GW54xx Front Panel OTG | J23 | Soft/VBUS | 1-1 | |||
Bot Right miniPCIe EHCI | J6 | Soft | 2-1.1 | |||
Top Right miniPCIe EHCI | J9 | Soft | 2-1.2 | |||
Top Left miniPCIe EHCI | J7 | Soft | 2-1.3 | |||
Front Panel EHCI | J21 | Soft/VBUS | 2-1.4 | |||
GW551x | Adapter Board OTG | J3 (J9 on Adapter) | Soft | 1-1 | ||
Bot miniPCIe EHCI | J2 | Soft | 2-1 | |||
GW552x Bot Left miniPCIe EHCI | J6 | Soft | 1-1.1 | |||
Bot Right miniPCIe EHCI | J5 | Soft | 1-1.2 | |||
Front Panel EHCI | J10 (Top) | Soft/VBUS | 1-1.3 | |||
Front Panel EHCI | J10 (Bot) | Soft/VBUS | 1-1.4 | |||
GW553x | Front Panel OTG | J8 | Soft/VBUS | 1-1 | ||
miniPCIe EHCI | J5 | Soft | 2-1 | |||
Laguna | GW2380 | MiniPCIe EHCI | J5 | Soft | 1-1 | |
GW2382 | Front Panel EHCI | J4 | Soft/VBUS (gpio9) | 1-1 | gpio10 high (default) | |
MiniPCIe EHCI | J5 | Soft | 1-1 | gpio10 low | ||
GW2383 | Front Panel OTG | J4 | Soft/VBUS | 1-1 | ||
MiniPCIe EHCI | J6 | Soft | 1-2 | |||
GW2387 | Front Panel OTG | J12 (Top) | Soft/VBUS (gpio6) | 1-1 | ||
Front Panel EHCI | J12 (Bot) | Soft/VBUS (gpio6) | 2-1 | gpio5 low (default) | ||
MiniPCI EHCI | J5 (Bot) | Soft | 2-1 | gpio5 high | ||
GW2388 | Front Panel OTG | J19 (Top) | Soft/VBUS (gpio6) | 1-1 | (loading option)(1) | |
Front Panel EHCI | J19 (Bot) | Soft/VBUS (gpio6) | 2-1 | (loading option)(1) | ||
MiniPCI EHCI (1) | J4 (Bot) | Soft | 2-1 | (resistor loading option)(1) | ||
GW2391 | Front Panel OTG | J14 (Top) | Soft/VBUS (gpio6) | 1-1 | gpio5 low (default) | |
Front Panel EHCI | J14 (Bot) | Soft/VBUS (gpio6) | 2-1 | gpio7 low (default) | ||
MiniPCIe OTG | J4 (Bot) | Soft | 1-1 | gpio5 high | ||
MiniPCIe EHCI | J3 (Top) | Soft | 2-1 | gpio7 high | ||
Cambria | GW2350 | Front Panel EHCI | J9 (Top) | Soft/VBUS | 1-1 | |
Front Panel EHCI | J9 (Bot) | Soft/VBUS | 2-1 | |||
MiniPCI EHCI (1) | J4 | Soft | 2-1 | (resistor loading option)(1) | ||
GW2358 | Front Panel EHCI | J16 (Top) | Soft/VBUS | 1-1 | ||
Front Panel EHCI | J16 (Bot) | Soft/VBUS | 2-1 | |||
MiniPCI EHCI (1) | J8 | Soft | 2-1 | (resistor loading option)(1) | ||
Avila | GW2348-SP107 | Front Panel EHCI | J18 (Top) | Soft/VBUS | 1-1 | |
Front Panel EHCI | J18 (Bot) | Soft/VBUS | 2-1 | |||
MiniPCI EHCI (1) | J4 | Soft | 2-1 | (resistor loading option)(1) |
- This is a loading option available on specials - contact sales@…
- Cambria GW2350 (Bottom MiniPCI socket J4)
- R164, R163 = Load to route USB to MiniPCI connector J8 (bottom slot)
- Cambria GW2358 (Bottom MiniPCI socket J8)
- R146, R153 = Load to route USB to MiniPCI connector J8 (bottom slot)
- R138, R140 = Load to route USB to frontpanel connector J16 (top USB port)
- Laguna GW2388-D+ (Bottom MiniPCI socket J4)
- R240, R244 = Load to route USB to MiniPCI connector J4 (bottom slot) (default on GW2388-4)
- R241, R242 = Load to route USB to frontpanel connector J19 (top USB port) (default on GW2388-SP208, SP212 and SP213 w/front panel USB loaded)
- Cambria GW2350 (Bottom MiniPCI socket J4)
USB Steering
Some boards allow USB to be steered via a software controlled gpio. Refer to the 'bus steering' column for details which show which gpio to use, what the default is set to (via bootloader), and where it can be steered to. Typically a bus may be steerable between a front-panel connector and a miniPCIe socket in which case the front-panel is always the default configured by the bootloader. You can change the steering at run-time if you whish which would be like physically removing a USB device from the bus and adding another (re-enumerates).
Examples:
- Ventana GW52xx: steer the USB OTG bus to the miniPCIe socket (device-mode only) which uses gpio2:
# export and configure the GPIO as an output high echo 2 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio2/direction echo 1 > /sys/class/gpio/gpio2/value # 0=front-panel 1=miniPCIe-j8
- Laguna GW2387/GW2388/GW2391: steer USB OTG bus to miniPCIe socket (device mode only) which uses gpio 5:
echo 1 > /sys/class/gpio/gpio5/value # 0=front-panel 1=miniPCIe
USB Reset
The best way to reset a USB device is to 'hot plug' the device by physically removing and reinserting it. However this is not typically possible and there are other options.
Note that BUS Steering can sometimes be a useful alternative to resetting a device as it forces a re-enumeration of the device.
VBUS reset
The next best thing to physically removing and re-inserting a USB device is to toggle power to that device. While this is not possible on the USB bus routed to miniPCIe sockets (which run off an always 3.3V power rail) this is possible on:
- OTG ports with Host capability (because they must have the ability to turn on and off their VBUS)
- Front panel ports that have over-current/fault-detect capability
- Ports that have a gpio controlled VBUS
Ports provided by a USB OTG controller ('OTG' in USB Port name) which support host mode can have their VBUS reset by unbinding and rebinding the host controller via sysfs:
- Ventana (where the OTG controller is '2184000.usb'):
echo 2184000.usb > /sys/bus/platform/drivers/imx_usb/unbind sleep 1 echo 2184000.usb > /sys/bus/platform/drivers/imx_usb/bind
- Laguna (where the OTG controlleris 'dwc2.0'):
echo dwc2.0 > /sys/bus/platform/drivers/dwc2/unbind sleep 1 echo dwc2.0 > /sys/bus/platform/drivers/dwc2/bind
Ports provided by a USB Hub's (will have a '.<port>' in their bus-device.port entry in the table above) with over-current/fault detection such as those found on a GW530x/GW540x can have their VBUS reset by unbinding their upstream bus-dev from the USB bus:
echo 2-1 > /sys/bus/usb/drivers/usb/unbind sleep 1 echo 2-1 > /sys/bus/usb/drivers/usb/bind
- this is not possible for MiniPCIe sockets as their VBUS comes from the 3.0V rail
Ports with GPIO controlled VBUS such as the Laguna boards can be reset by turning them on/off via gpio control:
- GW2382 (gpio9):
echo 0 > /sys/class/gpio/gpio9/value # de-assert GW2382 VUSB_EN sleep 1 echo 1 > /sys/class/gpio/gpio9/value # assert GW2382 VUSB_EN
- GW2387/GW2388/GW2391 (gpio6):
echo 0 > /sys/class/gpio/gpio9/value # de-assert GW2387/GW2388/GW2391 VUSB_EN sleep 1 echo 1 > /sys/class/gpio/gpio9/value # assert GW2387/GW2388/GW2391 VUSB_EN
Refer to the USB device table above for the bus-dev and/or VBUS capabilities per board.
Soft reset via sysfs bind/unbind (re-enumerate)
In some scenarios (ie Mini-PCIe modem) having command line options to reset these devices via sysfs is preferable and can be found via modern kernel drivers. Refer to the USB Device Table above for the bus-device.port reference for your board/port.
Note that commands targeting a hub cause a soft reset for all child devices which include the front panel and any pcie ports with "usb" on the silk screen. VBUS is only brought down on the front panel port(s) connected to the internal hub.
Examples:
- Reset GW54xx Front panel OTG device (bus-device 1-1). Note this will cause VBUS to be toggled for a full power reset - see above:
echo 1-1 > /sys/bus/usb/drivers/usb/unbind sleep 1 echo 1-1 > /sys/bus/usb/drivers/usb/bind
- Reset GW54xx EHCI devices by unbinding/binding the USB hub (bus-device 2-1). The bot right, top right, top left miniPCIe sockets will get a 'soft reset' (because they power off 3P3V which can't be toggled) and front panel EHCI will get a full VBUS power cycle:
echo 2-1 > /sys/bus/usb/drivers/usb/unbind sleep 1 echo 2-1 > /sys/bus/usb/drivers/usb/bind
- Reset GW54xx EHCI device in the top right miniPCIe socket J6 (bus-device 2-1.1):
echo 2-1.1 > /sys/bus/usb/drivers/usb/unbind sleep 1 echo 2-1.1 > /sys/bus/usb/drivers/usb/bind
Soft reset via ioctl
There are also ioctls that can accomplish the same results programmaticlly and in some cases give even finer control than the above table. An example of a simple program that uses some of these ioctls is the usbreset
command (present in OpenWrt):
Further information regarding these ioctls can be found throughout the Linux source documentation.