USB

Finalized in 2001, USB 2.0 is an external bus that supports data rates up to 480Mbps. USB 2.0 is an extension of USB 1.1...

USB 2.0 is compatible with USB 1.1. USB 2.0 cables and connectors will work with USB 1.1 devices. Not all USB 1.1 cables may work with USB 2.0 devices.

There is a difference between the terms Hi-Speed USB and USB 2.0. The difference is that USB 2.0 is the specification...

"Hi-Speed USB" refers to just the 480 Mbps portion of the USB 2.0 specification. A device can still be USB 2.0 compliant and be full speed or low speed.

USB 2.0 supports 1.5Mb/S,12Mb/S, and 480Mb/S speeds which are known as Low Speed, Full Speed, and High Speed respectively.

The Host is the root of the USB tiered star network. It controls the bus and communication is initiated by USB Host. The USB protocol mandates a single Host in any USB system.

The definition found in the USB specification for device notes the ambiguity in the word. The specification details that a “USB device” is either a hub or a function...

When using the term “USB Device” should be used in place of “device” to help reduce the ambiguity. Even with the clarification of “USB Device”, some publications use the term “USB Device” when they are referring to any USB enabled device. Because of this inconsistency of term usage, peripheral may be a less ambiguous wording option.

The USB specification does not define the term peripheral in its definitions list but uses it throughout the specification interchangeably for USB device. The USB certification checklists for USB devices are also called the peripheral checklists. The definition for Function in the USB specification says that a function is a USB device that provides some type of capability to the host.

Each host controller can support up to 127 devices. A host may contain multiple host controllers...

The presence of root hubs and/or compound devices may change, based on their implementation, the total available physical devices. Hubs also count as a device on the bus so each hub will also reduce the number of available USB device/peripheral slots.

The USB implementers forum also known as USB-IF...

Their official website is http://www.usb.org from where you can download latest specification for USB for free.

USB Specification defines four different types of data transfers mechanisms:

Control Transfer
The USB Host sends commands & query to USB device using Control transfer. The Control transfer uses End point 0(EP0) while USB device is being enumerated and thus it is mandatory to support EP0 by all USB device irrespective of supported speed. The maximum size for a Control packet is 8, 16, 32 or 64 bytes. The packet length of Control transfer in Low-speed USB device must be 8Bytes, for Full-speed USB device must be 64Bytes and for High-speed USB device allows 8, 16, 32 or 64Bytes

Interrupt Transfer
Interrupt transfers are a method for a USB device to request a certain polling rate from the USB host. The polling time is requested to USB Host by USB device during enumeration process. The maximum polling rate for a full-speed device is once per millisecond and once per every 10 milliseconds on low speed devices. The maximum data payload size for Low-speed USB device is 8Bytes, for Full-speed USB device is 64Bytes. This results in a maximum throughput of 64KB/Sec and 800B/Sec is for Low-speed USB device. Interrupt transfers are acknowledged so they guarantee the delivery. If a packet fails to arrive it is retried.

Bulk Transfer
Bulk transfers are a way for devices to transfers large amounts of data but as a consequence do not guarantee timely delivery. Bulk transfers have the lowest priority when it comes to scheduling on the bus. After all other transfers are complete the reset of the remaining bandwidth is given to bulk transfers. Just like interrupt transfers, bulk transfers are acknowledged to guarantee their delivery. Bulk transfers are only supported by Full-speed and High-speed devices. For Full-speed USB device endpoints, the maximum packet size can either be 8, 16, 32 or 64 bytes long. For High-speed USB device endpoints, the maximum packet size can be up to 512 bytes long.

Isochronous Transfer
It provides guarantee of transfer rate. A Full-speed isochronous transaction can send 1023 bytes per frame. Isochronous transfers are not acknowledged. It is possible that isochronous packets will not arrive. A typical application for isochronous transfers is audio/video streaming where it is more important to keep the video and audio up to date at the expense of dropping packets. The maximum transfer rate can be 1023KB/Sec for Full-speed USB device

USB protocol defines four types of packets:

Start of Frame
Token
Data
Handshake

There are three different types of Token packets.
IN ---- Informs the USB device that the host wants to read information.
OUT---Informs the USB device that the host wants to send the information.
Setup---Used to indicate to the device that a control transfer is about to occur.

USB protocol detects error using CRC (Cyclic Redundancy Check)...

This is done by the SIE (Serial Interface Engine), thus eliminating the need of CRC check in software and reduces the software overhead. For token packet CRC is 5 bit & data packet CRC is 16 bits.

The SIE discards the corrupt packet if the packet fails the CRC checks. No software intervention is required...

. An error flag is set indicating that a corrupted packet was received. The SIE will not ACK packets that have incorrect CRC values. For interrupt, bulk, and control transfers the host will try to retransmit the packet if it fails to receive the ACK. In this way these transmissions will not have data loss due to a corrupted packet but may suffer from lower application bandwidth.

Transfers are groups of transactions and transactions are groups of packets.

It depends on type of transferred used. Interrupt & Bulk transfers have a maximum payload size of 64 bytes for full-speed USB devices...

Isochronous transfers can send up to 1023 bytes for full-speed USB devices.

It is the process by which USB host learns about a USB device that has just been connected to the bus...

Before the application is able to start running, the host queries the device for various information to determine what type of device it is, what device driver it needs to load for the device, what power requirements the device has, etc. During the enumeration process the USB host also assigns an address to the connected device. After the address is set the USB host will communicate to the device at that address from that point forward. On of the final tasks of the enumeration process is to set the device into a specific operational configuration. A detailed enumeration process is given in section 9.1.2 of USB specification.

The USB host has weak pull down resistors on both of the communication lines (D+ and D-)...

A device will pull up D+ with a stronger pull-up resistor if it wishes to run in full-speed. If a device wishes to run in low-speed then D- is pulled up instead. The value of pull up resistor in each case is nominally 1K5.

The USB host sends a reset to the device by setting D+ and D– low for at least 10 milliseconds...

A USB device is allowed to determine that reset has occurred if it sees that D+ and D- are low for more than 2.5 microseconds. Once the USB device detects the reset, it goes into default state as soon as the USB host removes the reset. This reset is a USB reset only and does not reset the controller.

No. The USB host will request that a hub reset the particular connected USB device and only that device will be reset. If the USB host resets the hub itself then all of the devices attached to the hub will be reset.

There are several strings located in the device descriptor of the USB device, one of which being the manufacturer string. These strings, if implemented, can be read by the USB host during the enumeration process.

No. The host resets one device at a time and then completes the enumeration of one device before it starts investigating the next device.

More information about the various USB development and evaluation platforms is available on the “Tools” page.

You can buy all them from Microchip Direct or one of Microchip's authorized distribution partners.

A full list of C compilers is available at Microchip C Compilers.

All software is available with the USB Framework Tool, which is part of the Microchip Applications Library.

For the USB firmware release v2.1 or later precompiled demos can be found in the “\USB – Precompiled Demos” directory...

Documentation is also available in that directory to describe what hardware is required to run the demos, how to load the firmware into the device, and how to run the demo.

Resource requirements vary depending on the compiler, the processor family, the USB operational mode (Host, USB Device, OTG, etc), the USB class/function driver in use, etc...

The resource requirements may also vary between release versions of the USB firmware. Please refer to the release notes of a specific release for the estimated sizes of several combinations of the possible variables.

USB hub has to recalculate the time left before the end of the frame. The small extra delay added by the hub will decrease the available bandwidth...

If several devices are connected on the hub and working in parallel (for example, a webcam + a USB flash drive + a mouse), then the USB bandwidth is shared among the devices usage.

Currently Microchip supports evaluation USB device versions of HID (Human Interface Device - keyboard, joy stick, mouse etc are examples), CDC ...

(Communication Device – modem, Ethernet adapter etc. are examples), MSD (Mass Storage Device – thumb drive, external hard disk etc. are examples), and Custom device classes – customers can develop their drivers uniquely for their devices.

Please refer to the release notes of the specific software release for more information about the device class support.

The maximum length of USB cable is 5 meters.

A “compound” USB device is one with that has a built in hub, in addition to one or more USB peripherals devices, all built into a single product with only one USB cable connecting it to the host.

A “composite” USB device does not use hub silicon. It uses more than one interface in a single peripheral device. Currently, Microchip’s Full Speed USB silicon can be used to develop composite USB devices but not compound devices.

Release versions 1.3 and later contain an updated driver that works on Windows Vista (both 32 and 64 bit versions).

The maximum capacitance as seen by the Vbus pin of the USB connector must be less than 10uF...

This is to limit the inrush current that goes into the device when it is plugged into the device. The purpose of limiting the inrush current is to limit the drop in the Vbus voltage due to the charging of the capacitors on the newly attached device. Without limiting the inrush current of hot-plugged devices, a newly attached device may cause other devices to stop working.

If an application requires more capacitance than the spec allows, a soft-start circuit is required to limit the inrush current to the specified limits.

If the device is self powered, an I/O pin must be used to detect a cable attachment. The D+ or D- line must not be pulled up until USB host drives the Vbus high...

A self powered device must also consistently specify that it is self powered. If the configuration descriptor says that it is self powered then any GET_STATUS requests to the device must also return self-powered.

If the device wishes to be bus powered at all, even if it self powered part of the time, then it must declare itself as a bus powered device...

The GET_STATUS request should accurately reflect to the host if the USB device is currently running on self power or bus power.

The CDC class has many other sub class specifications. The host needs to know which of these device drivers to load for the attached device...

This information is contained in the .INF file. This means that the host will require some installation/setup process when a new CDC device is attached for the first time.

Hosts are almost always referred in context to PCs and laptops where any USB peripheral can be plugged. Full host must source 500mA of current on the Vbus to power the peripheral devices connected to it...

Embedded hosts are always found in small form factor and portable devices like a set top box, PDA, etc. It has to source current of minimum 8mA on the Vbus. It has limited memory space to store limited drivers, thus the connectivity to peripheral is also limited. Unlike a full host the embedded host is not required to load device drivers for a device it does not support. It is required, however, to notify the user that an unsupported device was attached. Embedded hosts are often called “mini-Hosts” or “limited hosts” but they refer to the same type of device. The terms embedded host, mini-host, or limited host are not referred to in the USB specification or the OTG supplement. The certification procedural walkthrough refers to these devices as Embedded hosts.

Yes. Microchip provides the USB mass storage class drivers, the SCSI interface, the FAT16/32 format software, and an example file management application. This firmware is available in Software/Tools

Currently the embedded host stack supports the MSD (Mass Storage Device – thumb drive, external hard disk etc. are examples), and Custom device classes – customers can develop their drivers uniquely for their devices...

Please refer to the release notes of the specific version for more information about software support.

Yes. The USB protocol requires all full speed and high speed communication to initiate as full speed, and then scale up to high speed if both devices support it. In the case that one of the devices only supports full speed, the communication would be limited to full speed, 12 Mbps.

No. Hard drives are mass storage devices, and as such have some form of data format provisions. For the devices to work, as opposed to just recognize each other, the file and interface protocols must also match. For example, a Thumb drive is a basic mass storage application. But for it to function, the USB class drivers, the SCSI interface, and the FAT16 format must all be present.

Currently only the FAT16 file format is supported in the USB embedded host firmware release versions. FAT32 support is being developed. NTFS and other file systems are not supported.

For an embedded host SRP is an optional feature but is not required. In most cases it is probably not desired either. For more information about what SRP is please see the OTG section of this FAQ.

Since an embedded host is only capable of being a host and never a USB device, HNP should not be supported. For more information about what HNP is please see the OTG section of this FAQ.

The OTG specification is an addendum to the original USB specification. USB OTG defines a way for portable devices, through only one connector per device, to connect to supported USB products in addition to the PC.

This allows to mobile device to connect to each other. One will assume the role of embedded host and the other will assume the role of USB device. This eliminates the need to have a PC for specific USB applications.

If a device only needs to talk to USB devices and never attach to another USB host, then the device can be an embedded host instead of an OTG product (please refer to the embedded host section above). If a device needs to connect to both USB devices and USB hosts then it needs to be an OTG product.

No, USB OTG products will connect to all PCs, and will also have host functionality to connect to the specific USB peripherals it supports.

No. In fact, USB OTG complements the concept of the “Extended PC”, where the PC is at the center of the consumer’s extended world of digital devices...

By enabling basic functions between digital devices, USB OTG augments the capability of these PC peripherals, making them more valuable to consumers and corporate users.

USB OTG devices determine which device is the host and which device is the peripheral based on which end of the cable is attached to the device...

If operation requires that the roles be switch HNP provides a mechanism for switching that role without having to remove and switch ends of the cable.

Unlike other USB hosts, USB OTG devices are allowed to remove power from the Vbus line when they are not using it...

The time when Vbus is powered is referred to as a session. SRP is a method for which a device attached to an OTG product can request a new session be started. After a device signals SRP, the OTG product acting as host will then power up Vbus and start communicating with the device.

When two dual role devices get connected together via a cable, the cable sets a default host and default peripheral...

If the application is such that the roles need to be reversed, then the Host Negotiation Protocol (HNP) can provide a handshake that performs that function. If HNP is not supported in either device then the cable may need to be reversed if a specific role is required.

OTG devices that are not already in production should use a micro-A/B connector. This allows either an A end or B end of a micro cable to be attached. This connector should not be confused with the micro-B connector that is available for USB devices.

Yes, this is possible. There are two possible ways to tackle this problem...

The first solution is to use the micro-A/B connector and program the device as an OTG device. Because SRP and HNP are optional these features can be disabled. The limitation here is that USB devices with full size A connectors will need an adaptor to connect to the micro-A/B port on the device.

Alternatively the device can have two USB connectors. Each would have to have it’s own separate circuitry for Vbus but share D+ and D-. The limitation here is that the USB test specifications state that any connectors that are accessible to the user must all be functional at the same time. Since the current USB devices only support one USB port, it is not possible to have both connectors functional at the same time. This means that some sort of mechanical feature must be implemented such that only one of the two ports is accessible for use at any given point of time.

The device descriptor is data table that describes various information about the attached device, such as the vender ID (VID) and product ID (PID) of the manufacturer...

The complete contents of the device descriptor can be found in Table 9-8 of the USB specification

VID stands for Vendor ID & PID stands for Product ID. The VID is issued by USB-IF by paying a required fee...

USB-IF mandates each vender have their own VID in order to market their product. There are possibly both legal and technical complications involved when using a VID/PID that is not unique. VID can be obtained from http://www.usb.org/developers/vendor/ Once a VID has been purchased, how the PIDs are used within that VID are determined by the manufacturer.

Microchip does have a sublicensing program for its VID. Please download this form to apply for a PID with Microchip’s VID for your prototypes.

A new PID is required for each product line produced. Each identical product in that product line should have the same PID...

If each device in a product line requires a unique identifier then the iSerialNumber field of the device descriptor can be used to uniquely identify each device.