ID 221C: USB for Embedded Systems Viewed from the Embedded Target Side

Transcription

1 ID 221C: USB for Embedded Systems Viewed from the Embedded Target Side Christian Légaré Vice-President 12 October 2010 Version: 1.0 In the market place today the myth about embedded Ethernet is that it very hard to achieve. In this presentation and lab, I will show you that Open-Source TCP/IP stacks with freely available tools are now true enablers for less costly embedded Ethernet products. 1

2 Mr. Christian Légaré Vice-President PREVIOUS EXPERIENCE: Twenty five years in the Telecom industry as an executive, Engineering Manager, Product Manager, and Engineer at various levels Internation Insstitute of Telecommunication, Schlumberger, Telweb, Mincacom, Alphanet, Teleglobe Canada, Télésystème National, SMIS I hold an MSEE from the University of Sherbrooke, Québec, Canada 2 2

3 3 USB Products 3

4 Our Position is consistently recognized as a leader in embedded software components. products are created for engineers by engineers and are designed to work with the resources available on embedded systems. provides you RTOS and Tools. The industry surveys for the last 5 years position as the #2 RTOS vendor. 4 The perception in the market place is that embedded Ethernet is hard to achieve. The cost of TCP/IP stacks, development tools, and the time to learn the technology all make it very difficult to design products that talk to each other over Ethernet. However, with a low cost Ethernet enabled MCU and the software freely available in the Open Source community embedded Ethernet is very easy to achieve. Renesas has a complete set of solution for H8S/2472 Ethernet connectivity. 4

5 Agenda Hardware architecture Mechanical specifications Electrical specifications Software specifications Compliance Final comments 5 5

6 6 USB for Embedded Systems Universal Serial Bus : Serial bus standard to interface devices. Peripheral communication protocol of choice for keyboards, printers, and memories Automatic error detection and recovery. Large number of devices. (127) Replaced RS-232 This document covers USB and differentiate USB Host protocol stack from USB Device protocol stack and On-The-Go. It goes over the design implications and some solutions. 6

7 7 Brief history 1969 Serial port (RS-232C) 1995 The USB consortium is formed by Compaq, DEC, IBM, Intel, Microsoft, NEC and Northern Telecom USB 1.0 standard was released. Plug Fest 1999 USB 1.1 was released. Corrected bugs 2000 USB 2.0 was released specifying the implementation of a 480 Mbps bus 2001 USB On-The-Go (OTG) supplement was added which allowed devices to talk to each other 2005 Wireless USB standard was released which is a point to point wireless communications link 2007 USB 3.0 goal is to deliver over 10 times the speed of today s connection 7

8 When the host is transmitting a packet of data, it is sent to every device connected to an enabled port. It 8 Architecture topology Star network configuration Only one host Maximum of seven levels of tiers, hub at center Host schedules and initiates data transfers. Host and hubs provide power to slaves Maximum number of devices allowed to connect to the bus is 127 Devices are referred to as functions Three rates: 1.5Mbps (Low), 12Mpbs (Full) & 480Mbps (High) 8 USB version 1.1 supported two speeds, a full speed mode of 12Mbits/s and a low speed mode of 1.5Mbits/s. The 1.5Mbits/s mode is slower and less susceptible to EMI, thus reducing the cost of ferrite beads and quality components. For example, crystals can be replaced by cheaper resonators. USB 2.0 has upped the stakes to 480Mbits/s. The 480Mbits/s is known as High Speed mode and was a tack on to compete with the Firewire Serial Bus. The Universal Serial Bus is host controlled. There can only be one host per bus. The specification in itself, does not support any form of multimaster arrangement. However the On-The-Go specification which is a tack on standard to USB 2.0 has introduced a Host Negotiation Protocol which allows two devices negotiate for the role of host. This is aimed at and limited to single point to point connections such as a mobile phone and personal organizer and not multiple hub, multiple device desktop configurations. The USB host is responsible for undertaking all transactions and scheduling bandwidth. Data can be sent by various transaction methods using a token-based protocol. USB uses a tiered star topology, similar to that of 10BaseT Ethernet. This imposes the use of a hub somewhere, which adds to greater expense, more boxes on your desktop and more cables. However it is not as bad as it may seem. Many devices have USB hubs integrated into them. For example, your keyboard may contain a hub which is connected to your computer. Your mouse and other devices such as your digital camera can be plugged easily into the back of your keyboard. Monitors are just another peripheral on a long list which commonly have in-built hubs. Up to 127 devices can be connected to any one USB bus at any one given time. Need more devices? - simply add another port/host. Functions and hubs have associated pipes (logical channels). Pipes are connections from the host controller to a logical entity on the device named an endpoint. The term endpoint is also occasionally used to refer to the entire pipe. A function can have up to 32 active pipes, 16 into the host controller and 16 out of the controller. Each endpoint can transfer data in one direction only, either into or out of the device/function, so each pipe is uni-directional. As stated above a maximum of 127 devices (including hubs) may be connected. This is because the address field in a packet is 7 bits long, and the address 0 cannot be used as it has special significance. (In most systems the bus would be running out of bandwidth, or other resources, long before the 127 devices was reached.)

9 9 Mechanical specifications Cable: Cable is made of 4 28-AWG conductors: Vbus Power Red Gnd Power Black D+ Data Green D- Data White Data pair is twisted Maximum cable length is 5 meters Low speed cables are attached to device Type A USB Connector Connector: Type B USB Connector Connector Type A connects to host Connector Type B connects to device Connector power pins are longer for hot-swap Mini connectors were added in USB 2.0 and OTG supplement 9 The ID pin on a Micro-A plug shall be connected to the GND pin. The ID pin on a Micro-B plug is not connected or is connected to ground by a resistance of greater than Rb_PLUG_ID (100kΩ MIN). An On- The-Go device is required to be able to detect whether a Micro-A or Micro-B plug is inserted by determining if the ID pin resistance to ground is less than Ra_PLUG_ID (10Ω MAX) or if the resistance to ground is greater than Rb_PLUG_ID. Any ID resistance less than Ra_PLUG_ID shall be treated as ID = FALSE and any resistance greater than Rb_PLUG_ID shall be treated as ID = TRUE.

10 Mechanical specifications A mini-b plug and receptacle has also been defined as an alternative to the standard B connector on handheld and portable devices. The mini-b connecter has a fifth pin, named ID, but it is not connected. Mini-B Plug and Receptacle Pin Assignments Mini-B USB Connector 10

11 11 OTG connectors Contact Number Signal Name 1 VBUS Red 2 D- White 3 D+ Green Typical Wiring Assignment 4 ID <10Ω = Micro-A >100kΩ = Micro-B 5 GND Black Shell Shield Drain Wire Micro Plug Pin Assignments White insulator 5 1 Micro-A USB Connector Black insulator 5 1 Micro-B USB Connector 11 The reasoning behind the mini connectors came from the range of miniature electronic devices such as mobile phones and organizers. The current type B connector is too large to be easily integrated into these devices. USB 2.0 included errata which introduces mini-usb B connectors. The details on these connectors can be found in Mini-B Connector Engineering Change Notice.

12 Serial Interface Engine (SIE) The complexities and speed of the USB protocol are such that it is not practical to expect a general purpose microcontroller to be able to implement the protocol using an instruction-driven basis. Dedicated hardware is required to deal with the time-critical portions of the specification, and the circuitry grouping which performs this function is referred to as the Serial Interface Engine (SIE). 12

13 13 Electrical specifications Device detection Current is limited to 100mA Either the D+ or the D- line will be pulled high D+ is high, the device is a full or high speed D- is high, the device is a low speed High Speed negotiation protocol occurs during the Bus Reset phase After detecting the reset signal, the high speed device will signal the host with a 480 Mbps chirp 13 USB uses 4 shielded wires of which two are power (+5v & GND). The remaining two are twisted pair differential data signals. High speed devices will start by connecting as a full speed device (1.5k to 3.3V). Once it has been attached, it will do a high speed chirp during reset and establish a high speed connection if the hub supports it. If the device operates in high speed mode, then the pull up resistor is removed to balance the line. However a high speed device must not support low speed mode. It should only support full speed mode needed to connect first, then high speed mode if successfully negotiated later. A USB 2.0 compliant downstream facing device (Hub or Host) must support all three modes, high speed, full speed and low speed. USB supports plug n play with dynamically loadable and unloadable drivers. The user simply plugs the device into the bus. The host will detect this addition, interrogate the newly inserted device and load the appropriate driver provided driver is installed for your device. The end user needs not worry about terminations, terms such as IRQs and port addresses, or rebooting the computer. Once the user is finished, they can simply lug the cable out, the host will detect its absence and automatically unload the driver (With the exception of Mass Storage Device where an abrupt disconnect can cause File System corruption on the device).

14 Device Powering The USB bus 5V supply is a very attractive feature. A USB device with a single connection is also attractive to the user Supply voltage can fall to 4.35V at the device When other devices are being plugged, there can be transients lowering the supply voltage by 0.4V Devices can be classified as: Bus powered Self powered Hybrid powered 14 A USB device specifies its power consumption expressed in 2mA units in the configuration descriptor which we will examine in detail later. A device cannot increase its power consumption, greater than what it specifies during enumeration, even if it looses external power. There are three classes of USB functions, Low-power bus powered functions High-power bus powered functions Self-powered functions Low power bus powered functions draw all its power from the VBUS and cannot draw any more than one unit load. The USB specification defines a unit load as 100mA. Low power bus powered functions must also be designed to work down to a VBUS voltage of 4.40V and up to a maximum voltage of 5.25V measured at the upsteam plug of the device. For many 3.3V devices, LDO regulators are mandatory. High power bus powered functions will draw all its power from the bus and cannot draw more than one unit load until it has been configured, after which it can then drain 5 unit loads (500mA Max) provided it asked for this in its descriptor. High power bus functions must be able to be detected and enumerated at a minimum 4.40V. When operating at a full unit load, a minimum VBUS of 4.75 V is specified with a maximum of 5.25V. Once again, these measurements are taken at the upstream plug. Self power functions may draw up to 1 unit load from the bus and derive the rest of it s power from an external source. Should this external source fail, it must have provisions in place to draw no more than 1 unit load from the bus. Self powered functions are easier to design to specification as there is not so much of an issue with power consumption. The 1 unit bus powered load allows the detection and enumeration of devices without mains/secondary power applied. No USB device, whether bus powered or self powered can drive the VBUS on its upstream facing port. If VBUS is lost, the device has a lengthy 10 seconds to remove power from the D+/D- pull-up resistors used for speed identification. Other VBUS considerations are the Inrush current which must be limited. This is outlined in the USB specification paragraph and is commonly overlooked. Inrush current is contributed to the amount of capacitance on your device between VBUS and ground. The spec therefore specifies that the maximum decoupling capacitance on a device is 10uF. Disconnecting the device after current is flowing through the inductive USB cable, a large flyback voltage can occur on the open end of the cable. To prevent this, a 1uF minimum VBUS decoupling capacitance is specified. Suspend mode is mandatory on all devices. During suspend, additional constrains come into force. The maximum suspend current is proportional to the unit load. For a 1 unit load device (default) the maximum suspend current is 500uA. This includes current from the pull up resistors on the bus. At the hub, both D- and D+ have pull down resistors of 15K ohms. For the purposes of power consumption, the pull down resistor at the device is in series with the 1.5K ohms pull up, making a total load of 16.5K ohms on a VTERM of typically 3.3v. Therefore this resistor sinks 200uA before we even start. 14

15 Device Powering Self-powered devices provide power requirements on descriptor (see descriptor in the software section). Initially provides 100mA, this can be increased up to 500mA (high power) Self-powered hubs have a limitation on self-powered devices of 100mA A device may draw up to 500mA after it has been configured as a high-power device. Being configured is dependent on the Hub being able to supply 500mA, which implies a self-powered hub. So there is always a degree of uncertainty whether more than 100mA will be available. It is a good design practice to offer the option of external power via a socket on such a device. Devices requiring more than 500mA are obliged to be self-powered. (It is dangerous to attempt to draw power from two adjacent USB ports using a modified cable. It is not permitted by the specification and can easily damage the ports) 15 Power Distribution A device (or hub) can only sink (consume) current from its upstream port. A 'self-powered' device is one which does not draw power from the bus. A device which draws its power from the bus is called a 'bus-powered' device. In normal operation, it may draw up to 100mA, or 500mA if permitted to do so by the host. A device which has been 'Suspended', as a result of no bus activity, must reduce its current consumption to 0.5 ma or less. If a device is configured for high power (up to 500 ma), and has its remote wakeup feature enabled, it is allowed to draw up to 2.5mA during suspend. Device Powering The availability of a 5V supply is a very attractive feature of USB, and can simplify the design of a device considerably. And a device with a single connection is also attractive to the user. However before designing a bus-powered device it is well to consider the limitations of this approach. The voltage supplied can fall to 4.35V at the device. There can also be transients on this taking it 0.4V lower, due to other devices being plugged in. Your device needs to cope with these voltage levels. The standard unit load available is 100mA. No device is permitted to take more than this before it has been configured by the host. It must also reduce its current consumption to 0.5mA whenever it is 'suspended' by a lack of activity on the bus. Note that this suspend condition will occur at least once before the device is configured. It should be remember that of this 0.5mA, the required 1.5k pullup resistor is already drawing 0.3mA. This leaves you a budget of 0.2mA to power the rest of your device circuitry. If the device contains a micro-controller it will need a sleep mode which meets this requirement, but do not forget that a badly placed resistor can very easily draw current which you hadn't expected. Measure your suspend current with a meter. A device may draw up to 500mA after it has been configured as a high-power device. Being configured is dependent on the Hub being able to supply 500mA, which implies a self-powered hub. So there is always a degree of uncertainty whether more than 100mA will be available. It would be well to offer the option of external power via a socket on such a device. Devices requiring more than 500mA are obliged to be self-powered. The practice of attempting to draw power from two adjacent USB ports, using a modified cable, is not permitted and can easily damage the ports. 15

16 Device Powering There is a suspend mode (no bus activity). In suspend mode, devices consume up to 500µA (where 200 µa already used by the pull up and pull-down resistors) Devices containing a micro-controller need a sleep mode which meets this requirement. but do not forget that a badly placed resistor can very easily draw current which you hadn't expected. Measure your suspend current with a meter High power devices (up to 500 ma) with remote wakeup feature enabled are allowed to draw up to 2.5mA during suspend This suspend condition will occur at least once before the device is configured 16 A USB device specifies its power consumption expressed in 2mA units in the configuration descriptor which we will examine in detail later. A device cannot increase its power consumption, greater than what it specifies during enumeration, even if it looses external power. There are three classes of USB functions, Low-power bus powered functions High-power bus powered functions Self-powered functions Low power bus powered functions draw all its power from the VBUS and cannot draw any more than one unit load. The USB specification defines a unit load as 100mA. Low power bus powered functions must also be designed to work down to a VBUS voltage of 4.40V and up to a maximum voltage of 5.25V measured at the upsteam plug of the device. For many 3.3V devices, LDO regulators are mandatory. High power bus powered functions will draw all its power from the bus and cannot draw more than one unit load until it has been configured, after which it can then drain 5 unit loads (500mA Max) provided it asked for this in its descriptor. High power bus functions must be able to be detected and enumerated at a minimum 4.40V. When operating at a full unit load, a minimum VBUS of 4.75 V is specified with a maximum of 5.25V. Once again, these measurements are taken at the upstream plug. Self power functions may draw up to 1 unit load from the bus and derive the rest of it s power from an external source. Should this external source fail, it must have provisions in place to draw no more than 1 unit load from the bus. Self powered functions are easier to design to specification as there is not so much of an issue with power consumption. The 1 unit bus powered load allows the detection and enumeration of devices without mains/secondary power applied. No USB device, whether bus powered or self powered can drive the VBUS on its upstream facing port. If VBUS is lost, the device has a lengthy 10 seconds to remove power from the D+/D- pull-up resistors used for speed identification. Other VBUS considerations are the Inrush current which must be limited. This is outlined in the USB specification paragraph and is commonly overlooked. Inrush current is contributed to the amount of capacitance on your device between VBUS and ground. The spec therefore specifies that the maximum decoupling capacitance on a device is 10uF. Disconnecting the device after current is flowing through the inductive USB cable, a large flyback voltage can occur on the open end of the cable. To prevent this, a 1uF minimum VBUS decoupling capacitance is specified. Suspend mode is mandatory on all devices. During suspend, additional constrains come into force. The maximum suspend current is proportional to the unit load. For a 1 unit load device (default) the maximum suspend current is 500uA. This includes current from the pull up resistors on the bus. At the hub, both D- and D+ have pull down resistors of 15K ohms. For the purposes of power consumption, the pull down resistor at the device is in series with the 1.5K ohms pull up, making a total load of 16.5K ohms on a VTERM of typically 3.3v. Therefore this resistor sinks 200uA before we even start. 16

17 Hot-Pluggable Place a capacitance of at least 1uF across Vbus and GND to prevent from flyback voltage when unplugging a cable at the far end from the device The maximum value of the shunt capacitor across Vbus and GND is limited by the specification to 10uF. This is to avoid other devices to crash because plugging device in, a capacitance between Vbus and GND will cause a dip in voltage across the other ports of the hub For the same reason, the hub port supply must be bypassed with at least 120uF 17

18 Self-Powered Devices If you pull, say D+, high in the absence of Vbus then you will risk faulty operation with On-The-Go hosts When designing a self-powered device, you must not pull a D+ or D- line above the Vbus voltage supplied. This means that you must sense when Vbus is connected The D+ or D- resistor should be pulled up to a 3.3V supply derived from Vbus, or controlled by Vbus in such a way that the resistor never sources current to the data line when Vbus is switched off 18

19 19 More Power On-The-Go and Battery Charging Specification both add new powering modes to the USB specification. Powered USB (aka Retail USB, USB Plus Power, and USB + Power) +5 volts DC at up to 6 amps per connector (up to 30 watts) +12 volts DC at up to 6 amps per connector (up to 72 watts) +24 volts DC at up to 6 amps per connector (up to 144 watts) Powered USB uses standard USB signaling with the addition of extra power lines for point-of-sale terminals IBM owns the intellectual rights to Powered USB and charges a licensing fee for its use 19 (Battery Charging)

20 20 Physical layer signaling Asynchronous communications Differential signal with a 4VDC sweep (300mV HS) Data on the bus is encoded using Non-Return-to-Zero-Inverted (NRZI) Use of bit stuffing to avoid loosing synchronization The bits are transmitted least-significant-bit (LSB) first. 20 It uses a NRZI (Non Return to Zero Invert) encoding scheme to send data with a sync field to synchronize the host and receiver clocks. USB uses a differential transmission pair for data. This is encoded using NRZI and is bit stuffed to ensure adequate transitions in the data stream. On low and full speed devices, a differential 1 is transmitted by pulling D+ over 2.8V with a 15K ohm resistor pulled to ground and D- under 0.3V with a 1.5K ohm resistor pulled to 3.6V. A differential 0 on the other hand is a D- greater than 2.8V and a D+ less than 0.3V with the same appropriate pull down/up resistors. The receiver defines a differential 1 as D+ 200mV greater than D- and a differential 0 as D+ 200mV less than D-. The polarity of the signal is inverted depending on the speed of the bus. Therefore the terms J and K states are used in signifying the logic levels. In low speed a J state is a differential 0. In high speed a J state is a differential 1. USB transceivers will have both differential and single ended outputs. Certain bus states are indicated by single ended signals on D+, D- or both. For example a single ended zero or SE0 can be used to signify a device reset if held for more than 10mS. A SE0 is generated by holding both D- and D+ low (< 0.3V). Single ended and differential outputs are important to note if using a transceiver and FPGA as the USB device. We cannot get away with sampling just the differential output.

21 Line States Given that there are just 2 data lines to use, it is surprising just how many different conditions are signaled using them: Differential '1' Differential '0' Single Ended Zero (SE0) Single Ended One (SE1) Data J State: Low-speed Full-speed Data K State: Low-speed Full-speed Idle State: Low-speed Full-speed Resume State Start of Packet (SOP) End of Packet (EOP) Disconnect Connect Reset Bus State D+ high, D- low D- high, D+ low D+ and D- low D+ and D- high Differential '0' Differential '1' Differential '1' Differential '0' Levels D- high, D+- low D+ high, D- low Data K state Data lines switch from idle to K state SE0 for 2 bit times followed by J state for 1 bit time SE0 for >= 2us Idle for 2.5us SE0 for >= 2.5 us 21

22 Detached When no device is plugged in, the host will see both data lines low, as its 15 kohm resistors are pulling each data line low. 22

23 Attached When the device is plugged in to the host, the host will see either D+ or D- go to a '1' level, and will know that a device has been plugged in. The '1' level will be on D- for a low speed device, and D+ for a full (or high) speed device. 23

24 Idle The state of the data lines when the pulled up line is high, and the other line is low, is called the idle state. This is the state of the lines before and after a packet is sent. D+ and D- Idle state 24

25 J and K States To make it easier to talk about the states of the data lines, some special terminology is used. The 'J State' is the same polarity as the idle state (the line with the pull-up resistor is high, and the other line is low), but is being driven to that state by either host or device. The K state is just the opposite polarity to the J state. The J and K terms are used because for Full Speed and Low Speed links they are actually of opposite polarity. 25

26 SE0 The Single Ended Zero (SE0) is when both lines are being pulled low. D+ and D- SE0 26

27 EOP signal The End of Packet (EOP) is an SE0 state for 2 bit times, followed by a J state for 1 bit time. D+ and D- Last data bits of packet 2 bits 1 bit Idle state EOP 27

28 Single Ended One (SE1) This is the illegal condition where both lines are high. It should never occur on a properly functioning link. D+ and D- SE1 28

29 Reset When the host wants to start communicating with a device it will start by applying a 'Reset' condition which sets the device to its default unconfigured state. The Reset condition involves the host pulling down both data lines to low levels (SE0) for at least 10 ms. The device may recognize the reset condition after 2.5 us. This 'Reset' should not be confused with a micro-controller power-on type reset. It is a USB protocol reset to ensure that the device USB signaling starts from a known state. Idle state >= 10ms Idle state D+ and D- Reset 29

30 Suspend With today s emphasis on energy saving, the USB suspend mode is very useful. It allows to power down an unused device. Suspending a device is achieved by not sending anything to the device for 3 ms. A Start-Of-Frame packet (at full speed, see Packets section) or a Keep Alive signal (at low speed) is sent by the host every 1 ms to keep the device awake. A suspended device must recognize the resume signal and the reset signal. D+ and D- Idle state Suspended >= 3ms 30

31 Keep Alive Signal This is represented by a Low speed EOP. It is sent at least once every millisecond on a low speed link, in order to keep the device from suspending. D+ and D- Idle state 2 bits 1 bit Idle state Keep Alive 31

32 Resume When the host wants to wake the device up after a suspend, it does so by reversing the polarity of the signal on the data lines for at least 20ms. The signal is completed with a low speed end of packet signal. It is also possible for a device with its remote wakeup feature set, to initiate a resume itself. It must have been in the idle state for at least 5ms, and must apply the wakeup K condition for between 1 and 15 ms. The host takes over the driving of the resume signal within 1 ms. Suspended Resume D+ and D- Idle J state K state Idle J state >= 20 ms 2 low speed bit time 1 low speed bit time 32

33 33 Data Signaling Rate Another area which is often overlooked is the tolerance of the USB clocks. High speed data is clocked at Mb/s with a data signaling tolerance of ± 500ppm. Full speed data is clocked at Mb/s with a data signaling tolerance of ±0.25% or 2,500ppm. Low speed data is clocked at 1.50Mb/s with a data signaling tolerance of ±1.5% or 15,000ppm. This allows resonators to be used for low cost low speed devices, but rules them out for full or high speed devices. 33

34 34 Software specifications USB Protocols Packets Transfer types Transactions Frames Endpoints Pipes 34 USB is made up of several layers of protocols. We really only have to worry about the higher level layers. Most USB controller ICs will take care of the lower layer, thus making it almost invisible to the end designer. As we have already discussed, USB is a host centric bus. The host initiates all transactions. The first packet, also called a token is generated by the host to describe what is to follow and whether the data transaction will be a read or write and what the device s address and designated endpoint is. The next packet is generally a data packet carrying the payload and is followed by an handshaking packet, reporting if the data or token was received successfully, or if the endpoint is stalled or not available to accept data.

35 35 Packets The fundamental element of communications is the packet A packet is made of three parts: START, INFORMATION, and END-OF-PACKET (EOP) At the START of a packet will be a sequence of transitions which is called SYNC The SYNC pattern is a chirp of either 8 bits (full-/low-speed) or 32 bits (high-speed) where each bit is a J or K state: KJKJKJKJKJKJKJKJKJKJKJKJKJKJKJKJKK The INFORMATION varies from 1 byte up to 1024 bytes Packet Identifier (PID) 4bits + complement Payload and CRC Not present in handshake packets The EOP is indicated by having both D+ and D- low for 3 bits (full-/low-speed) or 8 bits (highspeed). 35

36 36 USB Packet Fields SYNC SYNC All packets must start with a SYNC field. The SYNC field is 8 bits long at low and full speed or 32 bits long for high speed and is used to synchronize the clock of the receiver with that of the transmitter. The last two bits indicate where the PID fields starts. 36

37 37 USB Packet Fields PID PID PID stands for Packet ID. This field is used to identify the type of packet that is being sent. 37

38 38 USB Packet Fields PID Group PID Value Packet Identifier Token 0001 OUT 1001 IN 0101 SOF (Start of frame) 1101 SETUP Data 0011 DATA DATA DATA MDATA Handshake 0010 ACK 1010 NAK 1110 STALL 0110 NYET (No Response Yet) Special 1100 PRE (Host-issued preamble. Enables downstream bus traffic to low-speed devices) 1100 ERR (Split Transaction Error Handshake (reuses PRE value)) 1000 SPLIT (High-speed Split Transaction Token) 0100 PING (High-speed flow control probe for a bulk/control Endpoint) 0000 Reserved The first 2 bits of a Token which are transmitted determine which of the 4 groups it falls into. SOF is officially considered to be a Token PID. Bits are transmitted LSB first. The packet types which have been added for high speed are: DATA2 MDATA NYET ERR SPLIT PING DATA2 This data packet token has been added as part of a system for controlling multiple isochronous IN packets during one microframe at high speed. For each isochronous IN packet requested, the suffix of the DATAx PID represents the remaining number of packets to be transferred during the current micro-frame. MDATA This data packet token has been added as part of a system for controlling multiple isochronous OUT packets during one microframe at high speed. All but the last packet sent during a microframe use the MDATA PID. The last packet sent uses DATA0, DATA1 or DATA2 depending on whether one, two or three packets were sent. NYET NYET handshake packets are used in 2 different high speed situations. One use is when a hub wishes to respond to a 'complete split' transaction to say that it is has not yet been completed. The other use is during the high speed control or bulk OUT PING protocol. It means that the endpoint has accepted the data but is not yet ready for further data. A PING will need to be used to verify when it is ready for more data. ERR Used during the high speed split protocol by a hub, to indicate that there was an error on the full or low speed bus. 38

39 39 USB Packet Fields PID The first byte in every packet is the Packet Identifier (PID) byte. This byte needs to be recognized quickly by the USB controller. This is why it is not included in any CRC checks. It has its own validity check. There are 4 bits to the PID. The check method uses the PID 4 bits by repeating and complementing them, making an 8 bit PID field in total. PID 0 PID 1 PID 2 PID 3 npid 0 npid 1 npid 2 npid 3 PID shown in transmission order, LSB first. 39

40 40 USB Packet Fields ADDR ADDR The address field specifies which device the packet is designated for. Being 7 bits in length allows for 127 devices to be supported. Address 0 is not valid, as any device which is not yet assigned an address must respond to packets sent to address zero. 40

41 41 USB Packet Fields ENDP ENDP The endpoint field is made up of 4 bits, allowing 16 possible endpoints. Low speed devices, however can only have 2 additional endpoints on top of the default pipe. (4 endpoints max) 41

42 Cyclic Redundancy Code (CRC) A CRC is a value calculated from a number of data bytes to form a unique value which is transmitted along with the data bytes, and then used to validate the correct reception of the data USB uses two different CRCs a 5 bits long (CRC5) and a 16 bits long (CRC16) The USB specification contains all the details for the algorithms used to compute the CRCs 42 42

43 43 USB Packet Fields EOP EOP End of packet. Signalled by a Single Ended Zero (SE0) for approximately 2 bit times followed by a J for 1 bit time. 43

44 44 USB Packet Types USB has four different packet types. Start of Frame Packets Token Packets Data Packets Handshake Packets & Split Transaction Special Token Packets 44

45 45 Start of Frame Packets Start of frame packets indicate the start of a new frame. The SOF packet consisting of an 11-bit frame number is sent by the host every 1ms ± 500ns on a full speed bus or every 125 µs ± µs on a high speed bus. The first transaction in each (micro)frame. An SOF allows endpoints to identify the start of the (micro)frame and synchronize internal endpoint clocks to the host. 45

46 46 Token Packets Token packets indicate the type of transaction to follow. They are always the first packet in a transaction, identifying the targeted endpoint, and the purpose of the transaction. There are three types of token packets: In Informs the USB device that the host wishes to read information. Out Informs the USB device that the host wishes to send information. Setup Used to begin control transfers. 46

47 47 Data Packets Data packets contain the payload. There are two types of data packets each capable of transmitting up to 1024 bytes of data. Data0 Data1 DATA0 and DATA1 PIDs are used in Low and Full speed links as part of an error-checking system. When used, all data packets on a particular endpoint use an alternating DATA0 / DATA1 so that the endpoint knows if a received packet is the one it is expecting. If it is not the expected packet, it will still acknowledge (ACK) the packet as it is correctly received, but will then discard the data, assuming that it has been re-sent because the host missed seeing the ACK the first time it sent the data packet. 47

48 48 Data Packets High Speed mode defines another two data PIDs, DATA2 and MDATA. DATA2 This data packet token has been added as part of a system for controlling multiple isochronous IN packets during one microframe at high speed. For each isochronous IN packet requested, the suffix of the DATAx PID represents the remaining number of packets to be transferred during the current microframe. MDATA This data packet token has been added as part of a system for controlling multiple isochronous OUT packets during one microframe at high speed. All but the last packet sent during a microframe use the MDATA PID. The last packet sent uses DATA0, DATA1 or DATA2 depending on whether one, two or three packets were sent. 48

49 DATA packets Isochronous IN When requesting IN transactions, the device packages them in DATA2, DATA1 or DATA0 packets, depending on how many packets per microframe are specified, and which one it is. One transaction per microframe DATA0 Two transactions per microframe DATA1 DATA0 Three transactions per microframe DATA2 DATA1 DATA

50 DATA packets Isochronous OUT When sending OUT transactions, the host packages them either in MDATA or DATA0 or DATA1 or DATA2 packets. One transaction per microframe DATA0 Two transactions per microframe MDATA DATA1 Three transactions per microframe MDATA MDATA DATA

51 51 Handshake Packets Handshake packets are used for acknowledging data or reporting errors. There are three type of handshake packets which consist simply of the PID. ACK Acknowledgment that the packet has been successfully received. NAK Reports that the device temporary cannot send or received data. Also used during interrupt transactions to inform the host there is no data to send. STALL The device finds itself in a state that requires intervention from the host. NYET The device is not ready to answer. 51

52 52 Split Transaction Special Token Packets The split transaction token is used to support split transactions between the host controller communicating with a hub operating at high speed with full-/low-speed devices to some of its downstream facing ports. 52

53 Maximum data packet size Transfer Type Attributes High Speed Full Speed Low Speed Examples Control Quality + time 64 8,16,32 or 64 8 System control Bulk Quality <512 8,16,32 or 64 NA Printer, scanner Interrupt Quality + time <1024 <64 8 Mouse, keyboard Isochronous Time <3072 <1023 NA Audio, video Enpoints have several attributes in addition to their type. One of them being the maximum quantity of data that the endpoint can provide or consume in a single transaction. A single transfer can involve less than the maximum quantity of data an endpoint can handle

54 54 Hierarchy of data Transfer (Control, Interrupt, Isochronous, Bulk) Transaction 1 Transaction 2 Transaction 3.. Transaction n Packet 1 Packet 2 Packet 3 Packet 1 Packet 2 Packet 1 Packet 2 Packet Token: OUT, IN, SOF, SETUP Data: DATA0, DATA1 Handshake: ACK, NAK, STALL, NYET Special: PRE, ERR, SPLIT, PING 54

55 55 Transactions Each USB transaction consists of a Token Packet (Header defining what it expects to follow), an Optional Data Packet, (Containing the payload) and a Status Packet (Used to acknowledge transactions and to provide a means of error correction) A successful transaction is a sequence of three packets which performs a simple but secure transfer of data. For IN and OUT transactions used for isochronous transfers, there are only 2 packets; the handshake packet on the end is omitted. This is because error-checking is not required. There are three types of transaction: SETUP, IN and OUT. 55 USB is made up of several layers of protocols. We really only have to worry about the higher level layers. Most USB controller ICs will take care of the lower layer, thus making it almost invisible to the end designer. As we have already discussed, USB is a host centric bus. The host initiates all transactions. The first packet, also called a token is generated by the host to describe what is to follow and whether the data transaction will be a read or write and what the device s address and designated endpoint is. The next packet is generally a data packet carrying the payload and is followed by an handshaking packet, reporting if the data or token was received successfully, or if the endpoint is stalled or not available to accept data. A transaction is the delivery of service to an endpoint. it consists of a token packet, optional data packet, and optional handshake packet. Specific packets are allowed/required based on the transaction type. Some bus transactions between host controllers and hubs involve the transmission of four packets. These types of transactions are used to manage the data transfers between the host and full-/low- speed devices. A transaction of a particular transfer type typically requires multiple packets.

56 56 Frames All USB communication links are broken into frames The first packet of each frame is the Start-Of-Frame packet (SOF) A frame is transmitted every 1 ms in low and full speed At high speed the 1 ms frame is divided into 8 microframes of 125 us. A SOF is sent at the start of each of these 8 microframes, each having the same frame number, which then increments every 1 ms. A high-speed microframe is 125µs to minimize the buffer requirement On a low speed link, to preserve bandwidth, a Keep Alive signal is sent every millisecond, instead of a Start of Frame packet. In fact Keep Alives may be sent by a hub on a low speed link whenever the hub sees a full speed token packet. 56 USB establishes a 1 millisecond time base called a frame on a full-/low-speed bus and a 125 µs time base called a microframe on a high-speed bus. A (micro)frame can contain several transactions. Each transfer type defines what transactions are allowed within a (micro)frame for an endpoint. Isochronous and interrupt endpoints are given opportunities to the bus every N (micro)frames USB has a start of frame packet or keep alive sent periodically on the bus. This prevents an idle bus from entering suspend mode in the absence of data. A high speed bus will have micro-frames sent every µs ±62.5 ns. A full speed bus will have a frame sent down each ms ±500 ns. A low speed bus will have a keep alive which is a EOP (End of Packet) every 1ms only in the absence of any low speed data.

57 57 Bandwidth Management The host is responsible in managing the bandwidth of the bus. No more than 90% of any frame to be allocated for periodic transfers (Interrupt and Isochronous) on a full speed bus. (80% in high speed) In a highly saturated bus with periodic transfers, the remaining 10% is left for control transfers and once those have been allocated, bulk transfers will get its slice of what is left. 57

58 58 Bandwidth Management All USB transactions are performed in 1mSec frames initiated by the Host. Time Division Multiplexing is used to separate packets or transactions from different sources within each frame. 58

59 Protocol Analyzer Strongly recommended 59 Talk about packets (SOF, Setup). Talk about endpoints, control endpoint in this case, data packets, Ack packets etc.

60 60 Endpoints All packets are sent to and received by the device via endpoints. Endpoints are buffers where a device either puts or gets data Each endpoint has a direction, IN or OUT and an address Up to 16 endpoints can reside within a device A device can have up to 16 OUT and 16 IN endpoints with each its buffer The endpoint direction is implicit in the PID. OUT and SETUP PIDs refer to the OUT endpoint IN PID refers to the IN endpoint. Endpoint 0 is always the control endpoint 60 Endpoints can be described as sources or sinks of data. As the bus is host centric, endpoints occur at the end of the communications channel at the USB function. At the software layer, the device driver may send a packet to the devices EP1 for example. As the data is flowing out from the host, it will end up in the EP1 OUT buffer. The firmware will then at its leisure read this data. If it wants to return data, the function cannot simply write to the bus as the bus is controlled by the host. Therefore it writes data to EP1 IN which sits in the buffer until such time when the host sends a IN packet to that endpoint requesting the data. Endpoints can also be seen as the interface between the hardware of the function device and the firmware running on the function device. All devices must support endpoint zero. This is the endpoint which receives all of the devices control and status requests during enumeration and throughout the duration while the device is operational on the bus.

61 61 Pipes A Pipe is a logical connection between a source or destination on the host and endpoint(s) on a device. USB defines two types of pipes Stream Pipes No defined USB format: an application can send any type of data down a stream pipe and can retrieve the data out the other end. Data flows sequentially. Pre-defined direction for data: IN or OUT. Support bulk, isochronous and interrupt transfer types. Controlled by the host or the device. Message Pipes Well-defined USB format. Controlled by the host : host initiates a request for the device. Data is then transferred in the desired direction, dictated by the request. Data can flow in both directions. Only support control transfers. 61 While the device sends and receives data on a series of endpoints, the client software transfers data through pipes. A pipe is a logical connection between the host and endpoint(s). Pipes will also have a set of parameters associated with them such as how much bandwidth is allocated to it, what transfer type (Control, Bulk, Iso or Interrupt) it uses, a direction of data flow and maximum packet/buffer sizes. For example the default pipe is a bi-directional pipe made up of endpoint zero in and endpoint zero out with a control transfer type. The USB data transfer model between a source or destination on the host and an endpoint on a device is referred to as a pipe. There are two types of pipes: stream and message. Stream data has no USB-defined structure, while message data does. Additionally, pipes have associations of data bandwidth, transfer service type, and endpoint characteristics like directionality and buffer sizes. Most pipes come into existence when a USB device is configured. One message pipe, the Default Control Pipe, always exists once a device is powered, in order to provide access to the device s configuration, status, and control information.

62 Endpoints and Pipes Data Pipe Control Pipe Data Pipe 62 Spec defines endpoint : uniquely addressable portion of an USB device that is either a source or sink of info in a comm flow.. True except in case of control endpoint.. Bidirectional. In USB, There are a numbers of logical communication PIPE between HOST and DEVICE. Pipes are associated to a specific endpoint. EP (End Point) is an DEVICE side end of each PIPE. A Performance of a device controller is represented by EP specification of the device. -Number of EP -Support transfer type -FIFO size of EP The EP configuration essentially determines if a device is suited for an application or not

63 63 Transfers types A transfer is made of one of more transactions Transfers type Control Isochronous Interrupt Bulk Description Is non-periodic. It is used mostly for commands and status operations. Mandatory using Endpoint 0 OUT and Endpoint 0 IN. Has a fixed number of bytes per frame. The bandwidth is guaranteed. No error-checking Is periodic and the latency between transactions is guaranteed. Error-free and low throughput Is not periodic and it is used mostly to transfer large amounts of data. Error-free high volume throughput when bandwidth available 63 Another more notable feature of USB, is its transfer modes. USB supports Control, Interrupt, Bulk and Isochronous transfers. Isochronous allows a device to reserve a defined about of bandwidth with guaranteed latency. This is ideal in Audio or Video applications where congestion may cause loss of data or frames to drop. Each transfer mode provides the designer trade-offs in areas such as error detection and recovery, guaranteed latency and bandwidth.

64 64 USB's actual throughput Function of: target device's ability to source or sink data, the bandwidth consumption of other devices on the bus, and the efficiency of the host's USB software stack. Assuming Host and Device CPU can follow line speed, it is a function of: Transfer type and Signaling rate (In practice, most hosts can reach the maximum isochronous and interrupt bandwidths with a single target endpoint. With bulk transfers, typical transfer rates are around 900kb/s to a single endpoint, increasing to near ideal transfer rates with multiple endpoints.) 64 Assuming only the target endpoint consumes a significant amount of bus bandwidth-and both the target and the host are able to source or sink data as fast as USB can move it-the maximum attainable bandwidth is a function of the transfer type and signaling rate. These bandwidths are given in chapter 5 of the USB Specification. In practice, most hosts can reach the maximum isochronous and interrupt bandwidths with a single target endpoint. With bulk transfers, typical transfer rates are around 900kb/s to a single endpoint, increasing to near ideal transfer rates with multiple endpoints.

65 65 Transfer impacts on communication flow Each transfer type determines various characteristics of the communication flow including the following: Data format imposed by the USB Direction of communication flow Packet size constraints Bus access constraints Latency constraints Required data sequences Error handling The designers of a USB device choose the capabilities for the device s endpoints. 65

66 66 Table Calculation for the transfer impacts Each table shows: The protocol overhead required for the specific transfer type (and speed) For some sample data payload sizes: The maximum sustained bandwidth possible for this case The percentage of a (micro)frame that each transaction requires The maximum number of transactions in a (micro)frame for the specific case The remaining bytes in a (micro)frame that would not be required for the specific case The total number of data bytes transported in a single (micro)frame for the specific case A transaction of a particular transfer type typically requires multiple packets. The protocol overhead for each packet includes: a 8-bits (FS/LS) or 32-bits (HS) SYNC field a PID byte A 3-bits (FS/LS) or 8-bits (HS) EOP In a token packet: endpoint number + device address + CRC5 = 16 bits In a data packet: 16-bits CRC16 + any data field (8 bits per byte) For transaction with multiple packets, the inter packet gap or bus turnaround time required. For these calculations, there is assumed to be no bit-stuffing required. 66 A transaction of a particular transfer type typically requires multiple packets. The protocol overhead for each transaction includes: A SYNC field for each packet: either 8 bits (full-/low-speed) or 32 bits (high-speed) A PID byte for each packet: includes PID and PID invert (check) bits An EOP for each packet: 3 bits (full-/low-speed) or 8 bits (high-speed) In a token packet, the endpoint number, device address, and CRC5 fields (16 bits total) In a data packet, CRC16 fields (16 bits total) In a data packet, any data field (8 bits per byte) For transaction with multiple packets, the inter packet gap or bus turnaround time required. For these calculations, there is assumed to be no bit-stuffing required.

67 Low-speed Control Transfer Limits 67 67

68 Full-speed Control Transfer Limits 68 68

69 High-speed Control Transfer Limits 69 69

70 Full-speed Isochronous Transaction Limits 70 70

71 High-speed Isochronous Transaction Limits 71 71

72 Low-speed Interrupt Transaction Limits 72 72

73 Full-speed Interrupt Transaction Limits 73 73

74 High-speed Interrupt Transaction Limits 74 74

75 Full-speed Bulk Transaction Limits 75 75

76 High-speed Bulk Transaction Limits 76 76

77 77 Enumeration Once the device is attached, enumeration starts Host requests a number of data structures called descriptors Enumeration occurs on the default endpoint Host assigns a unique 7-bit address to the device Device attachment Reset device Get device descriptor Assign address Get configuration descriptor Get other descriptors Select device driver 77 A common Windows enumeration involves the following steps,: 1. The host or hub detects the connection of a new device via the device's pull up resistors on the data pair. The host waits for at least 100ms allowing for the plug to be inserted fully and for power to stabilize on the device. 2. Host issues a reset placing the device in the default state. The device may now respond to the default address zero. 3. The MS Windows host asks for the first 64 bytes of the Device Descriptor. 4. After receiving the first 8 bytes of the Device Descriptor, it immediately issues another bus reset. 5. The host now issues a Set Address command, placing the device in the addressed state. 6. The host asks for the entire 18 bytes of the Device Descriptor. 7. It then asks for 9 bytes of the Configuration Descriptor to determine the overall size. 8. The host asks for 255 bytes of the Configuration Descriptor. 9. Host asks for any String Descriptors if they were specified. At the end of Step 9, Windows will ask for a driver for your device. It is then common to see it request all the descriptors again before it issues a Set Configuration request. Step 4 often confuses people writing firmware for the first time. The Host asks for the first 64 bytes of the device descriptor, so when the host resets your device after it receives the first 8 bytes, it is only natural to think there is something wrong with your device descriptor or how your firmware handles the request. However as many will tell you, if you keep persisting by implementing the Set Address Command it will pay off by asking for a full 18 bytes of device descriptor next. Normally when something is wrong with a descriptor or how it is being sent, the host will attempt to read it three times with long pauses in between requests. After the third attempt, the host gives up reporting an error with your device.

78 78 Descriptors Describes attributes about the peripheral Peripherals typically have more than one descriptor It is typically stored in an EEPROM in the device s circuit There are few types of descriptors: Standard Class Vendor Among the standard descriptors: Device descriptor - general information about device Configuration descriptor - device configuration Interface descriptor number of endpoints Endpoint descriptor - properties of an endpoint Device Descriptor: bcdusb: 0x0110 bdeviceclass: 0x00 bdevicesubclass: 0x00 bdeviceprotocol: 0x00 bmaxpacketsize0: 0x08 (8) idvendor: 0x058F idproduct: 0x9380 bcddevice: 0x0100 imanufacturer: 0x01 iproduct: 0x02 iserialnumber: 0x00 bnumconfigurations: 0x01 ConnectionStatus: DeviceConnected Current Config Value: 0x01 Device Bus Speed: Full Device Address: 0x04 Open Pipes: 2 Endpoint Descriptor: bendpointaddress: 0x01 Transfer Type: Bulk wmaxpacketsize: 0x0040 (64) binterval: 0x00 Endpoint Descriptor: bendpointaddress: 0x00 Transfer Type: Control wmaxpacketsize: 0x0507 (1287) winterval: 0x0282 bsyncaddress: 0x40 78

79 Enumeration Device Descriptor Configuration Descriptor 1 General Interface 0 Descriptor Endpoint Descriptor 1 Endpoint Descriptor 2 Configuration Descriptor 1 wtotallength Interface 1 Descriptor Endpoint Descriptor 1 Configuration Descriptor 2 Endpoint Descriptor 2 HID Interface 0 Descriptor HID Descriptor Configuration Descriptor 2 wtotallength Endpoint Descriptor 1 Configuration Descriptor n 79 When the configuration descriptor is read, it returns the entire configuration hierarchy which includes all related interface and endpoint descriptors. The wtotallength field in the Configuration Descriptor reflects the number of bytes in the hierarchy. A USB device can have several different configurations although the majority of devices are simple and only have one. The configuration descriptor specifies how the device is powered, what the maximum power consumption is, the number of interfaces it has. Therefore it is possible to have two configurations, one for when the device is bus powered and another when it is mains powered. As this is a "header" to the Interface descriptors, its also feasible to have one configuration using a different transfer mode to that of another configuration. Once all the configurations have been examined by the host, the host will send a SetConfiguration command with a non zero value which matches the bconfigurationvalue of one of the configurations. This is used to select the desired configuration.

80 HID Enumeration Request Set Configuration for Device Report Descriptor Descriptor CONTROL pipe Reply Reply with with Reply with Configuration Device Interface with Endpoint Report HID Descriptor(s) Endpoint 0 (EP0) CONTROL endpoint USB Host (PC) HID Driver MCU IN Packet INTERRUPT-IN pipe IN Report Endpoint 3 (EP3) INTERRUPT-IN endpoint Connect USB cable 80 80

81 81 Device Driver The loading of the appropriate driver is done using a PID/VID (Product ID/Vendor ID) combination. Abstract from a.inf file: [DeviceList] %USB\VID_8765&PID_1234.DeviceDesc%=USBBulkInstall, USB\VID_8765&PID_ The VID is supplied by the USB Implementor's forum at a cost and this is seen as another sticking point for USB. The latest info on fees can be found on the USB Implementor s Website Other standards organizations provide a extra VID for non-commercial activities such as teaching, research or fiddling (The Hobbyist). The USB Implementors forum has yet to provide this service. In these cases, the developper may wish to use one assigned to the development system's manufacturer. For example most chip manufacturers will have a VID/PID combination the developper can use for the chips which is known not to exist as a commercial device. Other chip manufacturers can even sell a PID to use with their VID for the commercial device.

82 82 USB Functions i.e. Classes The USB standard makes references to USB functions which can be seen as USB devices which provide a capability or function such as a Printer, Mass Storage Drive, Scanner, Modem or other peripheral. In Software, Classes implements the Functions. 82 Most functions will have a series of buffers, typically 8 bytes long. Each buffer will belong to an endpoint - EP0 IN, EP0 OUT etc. Say for example, the host sends a device descriptor request. The function hardware will read the setup packet and determine from the address field whether the packet is for itself, and if so will copy the payload of the following data packet to the appropriate endpoint buffer dictated by the value in the endpoint field of the setup token. It will then send a handshake packet to acknowledge the reception of the byte and generate an internal interrupt within the semiconductor/micro-controller for the appropriate endpoint signifying it has received a packet. This is typically all done in hardware. The software now gets an interrupt, and should read the contents of the endpoint buffer and parse the device descriptor request.

83 Classes Currently 18 device classes specified by the USB specification Software interfaces for common devices A single device can belong to multiple classes Class Name Audio Mass Storage Human Interface Devices (HID) Communication Video Printer Examples Speakers, microphones Hard drives, flash drives, CD-ROMs Keyboard, mouse, digital I/O Modems Video cameras 83 83

84 USB Mass Strorage Class Host Host application Device Device application File System File System USB Mass Storage Class USB Host Stack USB Mass Storage Class USB Device Stack USB Host Controller Driver USB Device Controller Driver Storage Access functions USB Host Controller USB Device Controller Storage Device Software Hardware USB Cable 84

85 USB Control Device Class (CDC) Host Host application Serial Interface USB CDC ACM Class USB Host Stack USB Host Controller Driver Device Device application Serial Interface USB CDC ACM Class USB Device Stack USB Device Controller Driver Many variants of the CDC Class exist: ACM (Abstract Control Model ) ECM (Ethernet Networking Control Model ) EEM (Ethernet Emulation Model) and others USB Host Controller USB Device Controller Software Hardware USB Cable 85 CDC-ACM (Abstract Control Model) allows any communication device to provide a serial communication interface (e.g modem devices that send and receive AT commands). CDC-ECM (Ethernet Networking Control Model) offers device manufacturers to interface as a standard NIC (Network Interface Card) device. This interface is usually adopted by high speed LAN networking devices allowing high speed Ethernet data transfer over USB. CDC-EEM is a specification for inexpensive and efficient transport of Ethernet frames across the USB bus. It is part of the USB CDC specification, but unlike ECM, the EEM specification lacks the control requests to extend the Ethernet interface over USB. Instead, EEM utilizes the USB bandwidth to move Ethernet packets between a device and a host (While ECM will simply act as a channel for transmitting Ethernet Packets over a USB Bus to the device which will then export them to the network, the EEM can encapsulate several Ethernet frames into a single USB packet and by thus utilize the USB bandwidth to achieve maximal transfer performance). A general use case of a CDC EEM device would be creating "Network over USB" connectivity with a host, without extending the EEM device to serve as a "NIC" to an actual LAN/WLAN.

86 USB Control Device Class (CDC) Host Device Web Browser Web Server TCP/IP TCP/IP RNDIS over USB USB CDC ACM RNDIS Class USB Host Stack USB Device Stack USB Host Controller Driver USB Device Controller Driver USB Host Controller USB Device Controller Software Hardware USB Cable 86 RNDIS - provides CDC like communication capabilities on Windows PCs supporting the Microsoft RNDIS protocol. Please refer to the RNDIS webpage for more info. Remote NDIS (RNDIS) is a specification for network devices on dynamic Plug and Play I/O buses such as USB and InfiniBand. Remote NDIS eliminates the need for device manufacturers to write an NDIS miniport device driver by defining a bus-independent message set and a description of how this message set operates over various I/O buses. Since this Remote NDIS interface is standardized, one set of host drivers can support any number of bus-attached networking devices. This significantly reduces the development burden on device manufacturers, improves the overall stability of the system since no new drivers are required, and improves the end-user experience since there are no drivers to install to support a new bus-connected network device. Remote NDIS has become a standard component of modern Windows operating systems, including Windows 2000 and Windows XP. However, to implement the peripheral side of Remote NDIS, a special component needs to be embedded into the device firmware. RNDIS (Remote Network Driver Interface Specification) permits emulating Ethernet over USB. It is not part of the USB specification, but some popular PC operating systems, such as Windows and Linux, support it. Adding an RNDIS function driver to an embedded device allows interfacing its USB device stack to its TCP/IP stack that, in turn, connects to its web server. When the embedded device is plugged into a PC, its browser can connect to the web server in the embedded device. Hence, it is possible to use a browser to access an embedded device s web server, even when there is no Ethernet connection or it is difficult to access. This can be convenient for field troubleshooting or configuration using a laptop. The same information accessed via the network to which the embedded device is connected, can be accessed via USB.

87 USB Audio Class Host Host application Device Sound Manager Sound Layer Audio Interface MIDI USB Audio Class USB Audio Class USB Host Stack USB Device Stack USB Host Controller Driver USB Device Controller Driver Codec Driver USB Host Controller USB Device Controller Microphone Speaker Software Hardware USB Cable 87 The USB Audio Class is defined such that if a USB device follows the specification, a PC host will treat it as a sound card. The embedded device audio class provides both an audio interface and a MIDI (Musical Instrument Digital Interface) interface to a sound manager, which in turn can connect to a microphone, speaker, or other audio hardware, such as a musical instrument. This class uses isochronous transfer mode.

88 Host Stack Application USB Class API Class Drivers Mass HID CDC Hub storage USB Host core stack Host Controller Driver Custom drivers Kernel Abstraction Kernel Host Controller Hardware 88 Protocol Driver Layer The USB Specification defines different classes, subclasses and protocols. The class and the subclass identify the device category and define necessary endpoints required by the USB device for data transfer. The protocol defines the command formats, for example SCSI for the Mass Storage Class and PTP for the Still Image Capture class. USB devices may support different protocols though they are defined with the same class and subclass. For this reason, the protocol handling is moved to the Protocol Driver layer and class and subclass handling is moved to the Class Driver layer. There can be multiple Protocol Drivers for a single Class Driver. The applications may interface with the Protocol Driver layer or they may directly access the Class Drivers. Class Driver layer Class Driver layer provides device drivers for different USB device Classes and Subclasses such as: Mass storage (Flash drives, Hard drives, DVD etc..,) HID (Keyboard and Mouse etc.,) CDC (USB-Ethernet Dongles, Wi-Fi etc..,) Other (Vendor specific device classes)usb Core layer The USB Core layer is the center of the USB Host stack. It is hardware independent implementation containing most of the stack functionality. The USB Core layer contains the USB Driver, the Hub Driver and the Class Device Manager. The USB Driver allows its clients (Class Drivers) to communicate with it through the USB Driver Interface (USBDI). The Hub Driver is responsible for monitoring the hub ports for device attach or detach events. When the hub driver detects that a device is attached or detached, it calls the USB Driver to configure the device and load the appropriate device driver. The Class Device Manager provides a framework for the Class Drivers. When a new USB device is attached, the Class Device Manager loads the appropriate Class Drivers registered for that device. When the device is detached from the port, the Class Device Manager calls the disconnect routine to uninitialize the Class Driver. Host Controller Driver (HCD) Layer The HCD Layer communicates with the Host Controller hardware to transfer data across the USB Bus. This layer implements the Host Controller Driver Interface (HCDI). OS Abstraction Layer This layer abstracts RTOS services (such as timers, semaphores, and hardware I/O) that are 88

89 89 Host controller interfaces USB 1.1 OHCI Compaq, Microsoft, and National; hardware burden UHCI Intel, software burden USB 2.0 EHCI USB with Intel, simplified software and reduced cost USB 3.0 SuperSpeed - Hewlett-Packard, Intel, Microsoft, NEC, NXP Semiconductors and Texas Instruments November 17, 2008 The first certified USB 3.0 consumer products were announced January 5, 2010 Custom Memory map, SPI, etc 89 The USB host controllers have their own specifications. With USB 1.1, there were two Host Controller Interface Specifications, UHCI (Universal Host Controller Interface) developed by Intel which puts more of the burden on software (Microsoft) and allowing for cheaper hardware and the OHCI (Open Host Controller Interface) developed by Compaq, Microsoft and National Semiconductor which places more of the burden on hardware(intel) and makes for simpler software. Typical hardware / software engineer relationship... With the introduction of USB 2.0 a new Host Controller Interface Specification was needed to describe the register level details specific to USB 2.0. The EHCI (Enhanced Host Controller Interface) was born. Significant Contributors include Intel, Compaq, NEC, Lucent and Microsoft so it would hopefully seem they have pooled together to provide us one interface standard and thus only one new driver to implement in our operating systems. Its about time.

90 Host and Root Hub Root Hub (RH) = embedded hub part of the Host Provides 1 or more attachment points (i.e. ports) Equivalent to external Hub Presents standard hub functions Presents standard states as other USB devices Responsible for: Device connection/disconnection Device reset Port power Device Host Root Hub Device Device Hub Hub Device Device Compound Device Device Device 90 From USB 2.0 spec: There is only one host in any USB system. The Host Controller may be implemented in a combination of hardware, firmware, or software. A root hub is integrated within the host system to provide one or more attachment points. The Host Controller converts transactions into appropriate implementation-dependent activities that result in USB packets moving over the bus topology rooted in the root hub. The root hub provides standard hub function to link the Host Controller to one or more USB ports. The root hub presents to the hub driver the same standard states as other USB devices: Attached, Powered, Default, Address, Configured, Suspended. The Host Controller supports these states and their transitions for the hub. The root hub provides the same functionality for dealing with USB topology as other hubs (see Chapter 11), except that the hardware and software interface between the root hub and the Host Controller is defined by the specific hardware implementation. Host Controller Driver (HCD) = abstraction of Host Controller hardware and the Host Controller s view of data transmission over the USB. Presents the root hub and its behavior according to the hub class definition. This includes supporting the root hub such that the hub driver interacts with the root hub exactly as it would for any hub. In particular, even though a root hub can be implemented in a combination of hardware and software, the root hub : responds initially to the default device address (from a client perspective), returns descriptor information, supports having its device address set, and supports the other hub class requests. However, bus transactions may or may not need to be generated to accomplish this behavior given the close integration possible between the Host Controller and the root hub => virtualization of the Root Hub in the 90

91 Host and Root Hub Host Controller Driver (HCD) manages the Root Hub according to the hub-class protocol Some hub features handled in HW Other features in SW (e.g. standard USB descriptors for the Hub class) OHCI Host Controller Host stack EHCI Host Controller Root Hub PHY Port 1 Port 2 Port 3 Port 4 91 From USB 2.0 spec: There is only one host in any USB system. The Host Controller may be implemented in a combination of hardware, firmware, or software. A root hub is integrated within the host system to provide one or more attachment points. The Host Controller converts transactions into appropriate implementation-dependent activities that result in USB packets moving over the bus topology rooted in the root hub. The root hub provides standard hub function to link the Host Controller to one or more USB ports. The root hub presents to the hub driver the same standard states as other USB devices: Attached, Powered, Default, Address, Configured, Suspended. The Host Controller supports these states and their transitions for the hub. The root hub provides the same functionality for dealing with USB topology as other hubs (see Chapter 11), except that the hardware and software interface between the root hub and the Host Controller is defined by the specific hardware implementation. Host Controller Driver (HCD) = abstraction of Host Controller hardware and the Host Controller s view of data transmission over the USB. Presents the root hub and its behavior according to the hub class definition. This includes supporting the root hub such that the hub driver interacts with the root hub exactly as it would for any hub. In particular, even though a root hub can be implemented in a combination of hardware and software, the root hub : responds initially to the default device address (from a client perspective), returns descriptor information, supports having its device address set, and supports the other hub class requests. However, bus transactions may or may not need to be generated to accomplish this behavior given the close integration possible between the Host Controller and the root hub => virtualization of the Root Hub in the 91

92 92 Host and Root Hub When the Host stack starts, the 1 st device to be enumerated is always the Root Hub (RH). During enumeration, the RH returns the Hub descriptor which contains features supported by the RH. bnbrports: Number of downstream facing ports that this hub supports Hub driver (part of Host core layer) will handle hub events: Device attachment/detachment event Port power/enable/reset/suspend events Host stack bnbrports = 2 Enumerating RH Hub descriptor Root Hub Enumerating Function 1 Function 1 bnbrports = 2 Enumerating Hub Hub descriptor Enumerating Function 2 & 3 Host controller Hub Function 2 Function 3 92 Host stack will enumerate the Root hub: 1) Get Device descriptor 2) Set Address of the Root Hub 3) Get Configuration descriptor (with Interface and Endpoint descriptors) 4) Get Hub descriptor 5) Enable the power on each port of the Root Hub using a hub class request The Root Hub possesses an extra endpoint of type interrupt. This endpoint is used for Status Change about one of the port or the hub. If a change is detected in the status of the port or the hub, the Host stack will identify the cause of the change and do the appropriate action with the hub class request. The Host stack maintains information about the Root Hub in data structures. From USB 2.0 spec: The Hub Class defines one additional endpoint beyond Default Control Pipe, which is required for all hubs: the Status Change endpoint. The host system receives port and hub status change notifications through the Status Change endpoint. The Status Change endpoint is an interrupt endpoint. If no hub or port status change bits are set, then the hub returns an NAK when the Status Change endpoint is polled. When a status change bit is set, the hub responds with data, as shown in Section , indicating the entity (hub or port) with a change bit set. The USB System Software can use this data to determine which status registers to access in order to determine the exact cause of the status change interrupt.

93 93 Device Stack HID Application USB Class API Class Drivers Mass storage CDC USB Device core stack Device Controller Driver Device Controller Hardware Custom drivers Kernel Abstraction Kernel 93 A Device normally consists of three layers: A driver for hardware access, the core and at least a USB class driver or the bulk communication component.

94 94 USB On-The-Go Supplement to USB 2.0 Allows for devices to be host and peripheral New features: Smaller connectors with an added pin (ID) Tighter power constraints for devices Protocol enhancement for dynamic switching Definition session request protocols (SRP) 94 Portable computing devices such as hand-helds, cell phones and digital cameras that today connect to the PC as a USB peripheral will benefit from having additional capability to connect to other USB devices. USB OTG defines a dual-role device, which can act as either a host or peripheral, and can connect to either a PC or other portable devices through the same connector. Dual-role devices will connect to all PCs, and will also have host functionality to connect to supported USB peripherals. 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 will connect to PCs, as they are 100% compliant to the USB 2.0 specification. They will also have limited host capability that allows them to connect to a targeted set of other USB peripherals. USB OTG does not compete directly with Bluetooth. USB OTG allows devices to connect to many of the 2 billion supported USB devices, which have been shipping for over 10 years, while Bluetooth is just now shipping. USB OTG is much faster and cheaper than Bluetooth. However, USB OTG is expected to co-exist with Bluetooth on some portable devices such as hand-helds and cell phones, just as USB does today. Since USB On-The-Go is targeted toward existing USB peripherals, it continues to differ in application focus with 1394, just as USB does today. 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) will provide a handshake that performs that function. This reversal will be completely invisible to the user. The specification and more information on USB OTG can be found on the USB-IF website's OTG Developer's page at

95 USB On-The-Go Allows two USB devices to talk without a PC as host. DRD (Dual Role Devices). Unique mini-ab receptacle. OTG High Speed and Full Speed. Low power requirements on battery powered devices. 95 Not only will a standard USB host significantly cripple the battery life of a low-powered device, the connectors are also too large for the form factor of those miniature devices. 8mA min current supply with negotiation for more from host. Although OTG appears to add "peer to peer" connections to USB, it does not. Instead, USB OTG retains the standard USB host/peripheral model, where a single host talks to USB peripherals. OTG introduces the dual-role device (DRD), capable of functioning as either host or peripheral. Part of the magic of OTG is that a host and peripheral can exchange roles if necessary. Before OTG, the concept of an embedded host was already established in the USB world. Instead of duplicating the full UHCI/OHCI USB controllers and drivers built into personal computers, most embedded host chips provide limited hosting capabilities. This makes them better suited to the embedded environment than to the PC with its huge resources and infinite capacity for drivers and application software Can act as either host or peripheral depending on how users connect the cable to its unique mini-ab receptacle. When the dual-role device is connected to the mini-a plug, it turns into a host. When the mini-b plug is connected instead, the device becomes a peripheral. digital cameras, smart phones and handheld computers whose natures of their applications generally require some forms of expansions

96 USB On-The-Go Application OTG stack Device stack Device stack OTG Controller Driver Host Controller Hardware Device Controller Hardware 96 96

97 97 Wireless USB Certified Wireless USB is the new wireless extension to USB that combines the speed and security of wired technology with the easeof-use of wireless technology Certified Wireless USB is the first high-speed wireless personal interconnect technology to meet the needs of multimedia consumer electronics, PC peripherals, and mobile devices. Certified Wireless USB will preserve the functionality of wired USB while also unwiring the cable connection and providing enhanced support for streaming media CE devices and peripherals. Certified Wireless USB performance is targeted at 480Mbps at 3 meters and 110Mbps at 10 meters. 97

98 98 Compliance The USB organization has created a compliance program Two main criteria are: checklists and compliance testing Checklists contain questions relating to a product and its behavior USB-IF provide a Compliance Program for a small membership fee Usage of the USB logo requires a product to be compliant There are a set of registered USB logos which are not interchangeable 98

99 Renesas offering SH720 3 SH720 5 USB-Device USB-Host USB- Devi ce USB-Host R8C SH772 2 SH776 3 SH726 3 USB-Device SH726 5 USB-Device USB-Host SH776 4 SH7760 USB-Host USB-Device SH728 5 SH770 5 SH728 6 USB-Host SH772 0 USB- Devi ce USB-Host SH772 1 SH7727 USB-Device USB-Host SH767 0 H8SX/165 3 H8SX/1658 R H8SX/1668 R H8SX/166 3 H8S/217 2 H8S/221 5 H8S/221 8 USB-Device USB-Device USB-Device USB-Host USB-Host USB-Host USB-Device H8S/2472 USB-Device M16C/24 SH2A SH4A USB-Device Controller types Type a H8S2215 USB-Host USB-Host USB-Host Type b H8S2218 H8S2212 USB-Device USB-Host 78K0/R V850M x V850Jx USB-Device USB-Host RX200 USB-Device USB-Host RX60 0 Type c Type d H8S2472 H8SX1653 H8SX1663 H8SX1658R H8SX1668R 99 99

100 Have Reasonable Expectations Typical MCU can not keep up with High speed USB controllers. USB device controllers are sometimes troublesome to port. This is partly because a USB device controller port deals more closely with more complicated hardware than, say,a TCP/IP NIC port. Partly, this is because USB device controllers are much more various than NICs. The Device can never initiate a communication. If using MSD & a file system, either the device or the host (but not both) can access the disk at any time. 100

101 101 Summary Appealing features: Ease of use Bus power Auto-detection and self configuration Expandability Speed Availability of peripherals Flexibility and reliability The tradeoff is complex implementation and cost 101

102 102 References Documentation Universal Serial Bus Specification, Revision USB Design by Example: A Practical Guide to Building I/O Devices by John Hyde USB Complete by Jan Axelson Web Sites

103 Questions?

104 104