Chapter Name Description Pages Includes the motivation and scope for USB. The most important 1 Introduction

Transcription

1 USB in a NutShell Making sense f the USB standard Starting ut new with USB can be quite daunting. With the USB 2.0 specificatin at 650 pages ne culd easily be put ff just by the sheer size f the standard. This is nly the beginning f a lng list f assciated standards fr USB. There are USB Class Standards such as the HID Class Specificatin which details the cmmn peratin f devices (keybards, mice etc) falling under the HID (Human Interface Devices) Class - nly anther 97 pages. If yu are designing a USB Hst, then yu have three Hst Cntrller Interface Standards t chse frm. Nne f these are detailed in the USB 2.0 Spec. The gd news is yu dn t even need t bther reading the entire USB standard. Sme chapters were churned ut by marketing, thers aimed at the lwer link layer nrmally taken care ff by yur USB cntrller IC and a cuple aimed at hst and hub develpers. Lets take a little jurney thrugh the varius chapters f the USB 2.0 specificatin and briefly intrduce the key pints. Chapter Name Descriptin Pages Includes the mtivatin and scpe fr USB. The mst imprtant 1 Intrductin piece f infrmatin in this chapter is t make reference t the Universal Serial Bus Device Class Specificatins. N need 2 reading this chapter. 2 Terms and This chapter is self-explanatry and a necessary evil t any Abbreviatins standard. 8 Specifies the gals f USB which are Plug n Play and 3 Backgrund simplicity t the end user (nt develper). Intrduces Lw, Full 4 and High Speed ranges with a feature list straight frm marketing. N need reading this chapter either. 4 5 Architectural Overview USB Data Flw Mdel 6 Mechanical This is where yu can start reading. This chapter prvides a basic verview f a USB system including tplgy, data rates, 10 data flw types, basic electrical specs etc. This chapter starts t talk abut hw data flws n a Universal Serial Bus. It intrduces terms such as endpints and pipes then spends mst f the chapter n each f the data flw types 60 (Cntrl, Interrupt, Ischrnus and Bulk). While it s imprtant t knw each transfer type and its prperties it is a little heavy n fr a first reader. This chapter details the USB s tw standard cnnectrs. The imprtant infrmatin here is that a type A cnnectr is riented facing dwnstream and a type B cnnectr upstream. Therefre 33 it shuld be impssible t plug a cable int tw upstream prts. All detachable cables must be full/high speed, while any lw speed cable must be hardwired t the appliance. Other than a

2 7 Electrical 8 Prtcl Layer USB Device Frame Wrk USB Hst Hardware and Sftware Hub Specificatin quick lk at the cnnectrs, yu can skip this chapter unless yu intend t manufacture USB cnnectrs and/r cables. PCB designers can find standard ftprints in this chapter. This chapter lks at lw level electrical signalling including line impedance, rise/fall times, driver/receiver specificatins and bit level encding, bit stuffing etc. The mre imprtant parts f this chapter are the device speed identificatin by using a resistr t bias either data line and bus pwered devices vs 75 self pwered devices. Unless yu are designing USB transceivers at a silicn level yu can flip thrugh this chapter. Gd USB device datasheets will detail what value bus terminatin resistrs yu will need fr bus impedance matching. Nw we start t get int the prtcl layers. This chapter describes the USB packets at a byte level including the sync, pid, address, endpint, CRC fields. Once this has been grasped it mves n t the next prtcl layer, USB packets. Mst 45 develpers still dn t see these lwer prtcl layers as their USB device IC s take care f this. Hwever a understanding f the status reprting and handshaking is wrthwhile. This is the mst frequently used chapter in the entire specificatin and the nly ne I ever bthered printing and binding. This details the bus enumeratin and request cdes (set 36 address, get descriptr etc) which make up the mst cmmn prtcl layer USB prgrammers and designers will ever see. This chapter is a must read in detail. This chapter cvers issues relating t the hst. This includes frame and micrframe generatin, hst cntrller requirements, 23 sftware mechanisms and the universal serial bus driver mdel. Unless yu are designing Hsts, yu can skip this chapter. Details the wrkings f USB hubs including hub cnfiguratin, split transactins, standard descriptrs fr hub class etc. Unless 143 yu are designing Hubs, yu can skip this chapter. S nw we can begin t read the parts f the standard relevant t ur needs. If yu develp drivers (Sftware) fr USB peripherals then yu may nly need t read chapters, 4 - Architectural Overview 5 - USB Data Flw Mdel 9 - USB Device Frame Wrk, and 10 - USB Hst Hardware and Sftware. Peripheral hardware (Electrnics) designers n the ther hand may nly need t read chapters, 4 - Architectural Overview 5 - USB Data Flw Mdel

3 6 - Mechanical, and 7 - Electrical. USB in a NutShell fr Peripheral Designers Nw lets face it, (1) mst f us are here t develp USB peripherals and (2) it's cmmn t read a standard and still have n idea hw t implement a device. S in the next 7 chapters we fcus n the relevant parts needed t develp a USB device. This allws yu t grab a grasp f USB and its issues allwing yu t further research the issues specific t yur applicatin. The USB 1.1 standard was cmplex enugh befre High Speed was thrwn int USB 2.0. In rder t help understand the fundamental principals behind USB, we mit many areas specific t High Speed devices. Intrducing the Universal Serial Bus USB versin 1.1 supprted tw speeds, a full speed mde f 12Mbits/s and a lw speed mde f 1.5Mbits/s. The 1.5Mbits/s mde is slwer and less susceptible t EMI, thus reducing the cst f ferrite beads and quality cmpnents. Fr example, crystals can be replaced by cheaper resnatrs. USB 2.0 which is still yet t see day light n mainstream desktp cmputers has upped the stakes t 480Mbits/s. The 480Mbits/s is knwn as High Speed mde and was a tack n t cmpete with the Firewire Serial Bus. USB Speeds High Speed - 480Mbits/s Full Speed - 12Mbits/s Lw Speed - 1.5Mbits/s The Universal Serial Bus is hst cntrlled. There can nly be ne hst per bus. The specificatin in itself, des nt supprt any frm f multimaster arrangement. Hwever the On- The-G specificatin which is a tack n standard t USB 2.0 has intrduced a Hst Negtiatin Prtcl which allws tw devices negtiate fr the rle f hst. This is aimed at and limited t single pint t pint cnnectins such as a mbile phne and persnal rganiser and nt multiple hub, multiple device desktp cnfiguratins. The USB hst is respnsible fr undertaking all transactins and scheduling bandwidth. Data can be sent by varius transactin methds using a tken-based prtcl. In my view the bus tplgy f USB is smewhat limiting. One f the riginal intentins f USB was t reduce the amunt f cabling at the back f yur PC. Apple peple will say the idea came frm the Apple Desktp Bus, where bth the keybard, muse and sme ther peripherals culd be cnnected tgether (daisy chained) using the ne cable.

4 Hwever USB uses a tiered star tplgy, simular t that f 10BaseT Ethernet. This impses the use f a hub smewhere, which adds t greater expense, mre bxes n yur desktp and mre cables. Hwever it is nt as bad as it may seem. Many devices have USB hubs integrated int them. Fr example, yur keybard may cntain a hub which is cnnected t yur cmputer. Yur muse and ther devices such as yur digital camera can be plugged easily int the back f yur keybard. Mnitrs are just anther peripheral n a lng list which cmmnly have in-built hubs. This tiered star tplgy, rather than simply daisy chaining devices tgether has sme benefits. Firstly pwer t each device can be mnitred and even switched ff if an vercurrent cnditin ccurs withut disrupting ther USB devices. Bth high, full and lw speed devices can be supprted, with the hub filtering ut high speed and full speed transactins s lwer speed devices d nt receive them. Up t 127 devices can be cnnected t any ne USB bus at any ne given time. Need mre devices? - simply add anther prt/hst. While mst earlier USB hsts had tw prts, mst manufacturers have seen this as limiting and are starting t intrduce 4 and 5 prt hst cards with an internal prt fr hard disks etc. The early hsts had ne USB cntrller and thus bth prts shared the same available USB bandwidth. As bandwidth requirements grew, we are starting t see multi-prt cards with tw r mre cntrllers allwing individual channels. The USB hst cntrllers have their wn specificatins. With USB 1.1, there were tw Hst Cntrller Interface Specificatins, UHCI (Universal Hst Cntrller Interface) develped by Intel which puts mre f the burden n sftware (Micrsft) and allwing fr cheaper hardware and the OHCI (Open Hst Cntrller Interface) develped by Cmpaq, Micrsft and Natinal Semicnductr which places mre f the burden n hardware(intel) and makes fr simpler sftware. Typical hardware / sftware engineer relatinship... With the intrductin f USB 2.0 a new Hst Cntrller Interface Specificatin was needed t describe the register level details specific t USB 2.0. The EHCI (Enhanced Hst Cntrller Interface) was brn. Significant Cntributrs include Intel, Cmpaq, NEC, Lucent and Micrsft s it wuld hpefully seem they have pled tgether t prvide us ne interface standard and thus nly ne new driver t implement in ur perating systems. Its abut time. USB as its name wuld suggest is a serial bus. It uses 4 shielded wires f which tw are pwer (+5v & GND). The remaining tw are twisted pair differential data signals. It uses a NRZI (Nn Return t Zer Invert) encding scheme t send data with a sync field t synchrnise the hst and receiver clcks. USB supprts plug n plug with dynamically ladable and unladable drivers. The user simply plugs the device int the bus. The hst will detect this additin, interrgate the newly inserted device and lad the apprpriate driver all in the time it takes the hurglass t blink n yur screen prvided a driver is installed fr yur device. The end user needs nt wrry abut terminatins, terms such as IRQs and prt addresses, r rebting the cmputer. Once the user is finished, they can simply lug the cable ut, the hst will detect its absence and autmatically unlad the driver.

5 The lading f the apprpriate driver is dne using a PID/VID (Prduct ID/Vendr ID) cmbinatin. The VID is supplied by the USB Implementr's frum at a cst and this is seen as anther sticking pint fr USB. The latest inf n fees can be fund n the USB Implementr s Website Other standards rganisatins prvide a extra VID fr nn-cmmercial activities such as teaching, research r fiddling (The Hbbyist). The USB Implementrs frum has yet t prvide this service. In these cases yu may wish t use ne assigned t yur develpment system's manufacturer. Fr example mst chip manufacturers will have a VID/PID cmbinatin yu can use fr yur chips which is knwn nt t exist as a cmmercial device. Other chip manufacturers can even sell yu a PID t use with their VID fr yur cmmercial device. Anther mre ntable feature f USB, is its transfer mdes. USB supprts Cntrl, Interrupt, Bulk and Ischrnus transfers. While we will lk at the ther transfer mdes later, Ischrnus allws a device t reserve a defined amunt f bandwidth with guaranteed latency. This is ideal in Audi r Vide applicatins where cngestin may cause lss f data r frames t drp. Each transfer mde prvides the designer trade-ffs in areas such as errr detectin and recvery, guaranteed latency and bandwidth. Cnnectrs All devices have an upstream cnnectin t the hst and all hsts have a dwnstream cnnectin t the device. Upstream and dwnstream cnnectrs are nt mechanically interchangeable, thus eliminating illegal lpback cnnectins at hubs such as a dwnstream prt cnnected t a dwnstream prt. There are cmmnly tw types f cnnectrs, called type A and type B which are shwn belw. Type A USB Cnnectr Type B USB Cnnectr Type A plugs always face upstream. Type A sckets will typically find themselves n hsts and hubs. Fr example type A sckets are cmmn n cmputer main bards and hubs. Type B plugs are always cnnected dwnstream and cnsequently type B sckets are fund n devices. It is interesting t find type A t type A cables wired straight thrugh and an array f USB gender changers in sme cmputer stres. This is in cntradictin f the USB specificatin. The nly type A plug t type A plug devices are bridges which are used t cnnect tw cmputers tgether. Other prhibited cables are USB extensins which has a plug n ne end (either type A r type B) and a scket n the ther. These cables vilate the cable length requirements f USB. USB 2.0 included errata which intrduces mini-usb B cnnectrs. The details n these cnnectrs can be fund in Mini-B Cnnectr Engineering Change Ntice The reasning behind the mini cnnectrs came frm the range f miniature electrnic devices such as mbile phnes

6 and rganisers. The current type B cnnectr is t large t be easily integrated int these devices. Just recently released has been the On-The-G specificatin which adds peer-t-peer functinality t USB. This intrduces USB hsts int mbile phne and electrnic rganisers, and thus has included a specificatin fr mini-a plugs, mini-a receptacles, and mini-ab receptacles. I guess we shuld be inundated with mini USB cables sn and a range f mini t standard cnverter cables. Pin Number Cable Clur Functin 1 Red V BUS (5 vlts) 2 White D- 3 Green D+ 4 Black Grund Standard internal wire clurs are used in USB cables, making it easier t identify wires frm manufacturer t manufacturer. The standard specifies varius electrical parameters fr the cables. It is interesting t read the detail the riginal USB 1.0 spec included. Yu wuld understand it specifying electrical attributes, but paragraph suggested the recmmended clur fr vermlds n USB cables shuld be frst white - hw bring! USB 1.1 and USB 2.0 was relaxed t recmmend Black, Grey r Natural. PCB designers will want t reference chapter 6 fr standard ft prints and pinuts. Electrical Unless yu are designing the silicn fr a USB device/transceiver r USB hst/hub, there is nt all that much yu need t knw abut the electrical specificatins in chapter 7. We briefly address the essential pints here. As we have discussed, USB uses a differential transmissin pair fr data. This is encded using NRZI and is bit stuffed t ensure adequate transitins in the data stream. On lw and full speed devices, a differential 1 is transmitted by pulling D+ ver 2.8V with a 15K hm resistr pulled t grund and D- under 0.3V with a 1.5K hm resistr pulled t 3.6V. A differential 0 n the ther hand is a D- greater than 2.8V and a D+ less than 0.3V with the same apprpriate pull dwn/up resistrs. The receiver defines a differential 1 as D+ 200mV greater than D- and a differential 0 as D+ 200mV less than D-. The plarity f the signal is inverted depending n the speed f the bus. Therefre the terms J and K states are used in signifying the lgic levels. In lw speed a J state is a differential 0. In high speed a J state is a differential 1. USB transceivers will have bth differential and single ended utputs. Certain bus states are indicated by single ended signals n D+, D- r bth. Fr example a single ended zer r SE0 can

7 be used t signify a device reset if held fr mre than 10mS. A SE0 is generated by hlding bth D- and D+ lw (< 0.3V). Single ended and differential utputs are imprtant t nte if yu are using a transceiver and FPGA as yur USB device. Yu cannt get away with sampling just the differential utput. The lw speed/full speed bus has a characteristic impedance f 90 hms +/- 15%. It is therefre imprtant t bserve the datasheet when selecting impedance matching series resistrs fr D+ and D-. Any gd datasheet shuld specify these values and tlerances. High Speed (480Mbits/s) mde uses a 17.78mA cnstant current fr signalling t reduce nise. Speed Identificatin A USB device must indicate its speed by pulling either the D+ r D- line high t 3.3 vlts. A full speed device, pictured belw will use a pull up resistr attached t D+ t specify itself as a full speed device. These pull up resistrs at the device end will als be used by the hst r hub t detect the presence f a device cnnected t its prt. Withut a pull up resistr, USB assumes there is nthing cnnected t the bus. Sme devices have this resistr built int its silicn, which can be turned n and ff under firmware cntrl, thers require an external resistr. Fr example Philips Semicnductr has a SftCnnect TM technlgy. When first cnnected t the bus, this allws the micrcntrller t initialise the USB functin device befre it enables the pull up speed identificatin resistr, indicating a device is attached t the bus. If the pull up resistr was cnnected t V bus, then this wuld indicate a device has been cnnected t the bus as sn as the plug is inserted. The hst may then attempt t reset the device and ask fr a descriptr when the micrprcessr hasn t even started t initialise the usb functin device. Other vendrs such as Cypress Semicnductr als use a prgrammable resistr fr Re- Numeratin TM purpses in their EzUSB devices where the ne device can be enumerated fr ne functin such as In field prgramming then be discnnected frm the bus under firmware cntrl, and enumerate as anther different device, all withut the user lifting an eyelid. Many f the EzUSB devices d nt have any Flash r OTP ROM t stre cde. They are btstraped at cnnectin.

8 Figure 2 : Full Speed Device with pull up resistr cnnected t D+ Figure 3 : Lw Speed Device with pull up resistr cnnected t D- Yu will ntice we have nt included speed identificatin fr High Speed mde. High speed devices will start by cnnecting as a full speed device (1.5k t 3.3V). Once it has been attached, it will d a high speed chirp during reset and establish a high speed cnnectin if the hub supprts it. If the device perates in high speed mde, then the pull up resistr is remved t balance the line. A USB 2.0 cmpliant device is nt required t supprt high-speed mde. This allws cheaper devices t be prduced if the speed isn t critical. This is als the case fr a lw speed USB 1.1 devices which is nt required t supprt full speed.

9 Hwever a high speed device must nt supprt lw speed mde. It shuld nly supprt full speed mde needed t cnnect first, then high speed mde if successfully negtiated later. A USB 2.0 cmpliant dwnstream facing device (Hub r Hst) must supprt all three mdes, high speed, full speed and lw speed. Pwer (V BUS ) One f the benefits f USB is bus-pwered devices - devices which btain its pwer frm the bus and requires n external plug packs r additinal cables. Hwever many leap at this ptin withut first cnsidering all the necessary criteria. A USB device specifies its pwer cnsumptin expressed in 2mA units in the cnfiguratin descriptr which we will examine in detail later. A device cannt increase its pwer cnsumptin, greater than what it specifies during enumeratin, even if it lses external pwer. There are three classes f USB functins, Lw-pwer bus pwered functins High-pwer bus pwered functins Self-pwered functins Lw pwer bus pwered functins draw all its pwer frm the V BUS and cannt draw any mre than ne unit lad. The USB specificatin defines a unit lad as 100mA. Lw pwer bus pwered functins must als be designed t wrk dwn t a V BUS vltage f 4.40V and up t a maximum vltage f 5.25V measured at the upsteam plug f the device. Fr many 3.3V devices, LDO regulatrs are mandatry. High pwer bus pwered functins will draw all its pwer frm the bus and cannt draw mre than ne unit lad until it has been cnfigured, after which it can then drain 5 unit lads (500mA Max) prvided it asked fr this in its descriptr. High pwer bus functins must be able t be detected and enumerated at a minimum 4.40V. When perating at a full unit lad, a minimum V BUS f 4.75 V is specified with a maximum f 5.25V. Once again, these measurements are taken at the upstream plug. Self pwer functins may draw up t 1 unit lad frm the bus and derive the rest f it s pwer frm an external surce. Shuld this external surce fail, it must have prvisins in place t draw n mre than 1 unit lad frm the bus. Self pwered functins are easier t design t specificatin as there is nt s much f an issue with pwer cnsumptin. The 1 unit bus pwered lad allws the detectin and enumeratin f devices withut mains/secndary pwer applied. N USB device, whether bus pwered r self pwered can drive the V BUS n its upstream facing prt. If V BUS is lst, the device has a lengthy 10 secnds t remve pwer frm the D+/D- pullup resistrs used fr speed identificatin.

10 Other V BUS cnsideratins are the Inrush current which must be limited. This is utlined in the USB specificatin paragraph and is cmmnly verlked. Inrush current is cntributed t the amunt f capacitance n yur device between V BUS and grund. The spec therefre specifies that the maximum decupling capacitance yu can have n yur device is 10uF. When yu discnnect the device after current is flwing thrugh the inductive USB cable, a large flyback vltage can ccur n the pen end f the cable. T prevent this, a 1uF minimum V BUS decupling capacitance is specified. Fr the typical bus pwered device, it can nt drain any mre than 500mA which is nt unreasnable. S what is the cmplicatin yu ask? Perhaps Suspend Mde? Suspend Current Suspend mde is mandatry n all devices. During suspend, additinal cnstrains cme int frce. The maximum suspend current is prprtinal t the unit lad. Fr a 1 unit lad device (default) the maximum suspend current is 500uA. This includes current frm the pull up resistrs n the bus. At the hub, bth D- and D+ have pull dwn resistrs f 15K hms. Fr the purpses f pwer cnsumptin, the pull dwn resistr at the device is in series with the 1.5K hms pull up, making a ttal lad f 16.5K hms n a V TERM f typically 3.3v. Therefre this resistr sinks 200uA befre we even start. Anther cnsideratin fr many devices is the 3.3V regulatr. Many f the USB devices run n 3.3V. The PDIUSBD11 is ne such example. Linear regulatrs are typically quite inefficient with average quiescent currents in the rder f 600uA, therefre mre efficient and thus expensive regulatrs are called fr. In the majrity f cases, yu must als slw dwn r stp clcks n micrcntrllers t fall within the 500uA limit. Many develpers ask in the USB Implementr's Frum, what are the cmplicatins f exceeding this limit? It is understd, that mst hsts and hubs dn t have the ability t detect such an verlad f this magnitude and thus if yu drain maybe 5mA r even 10mA yu shuld still be fine, bearing in mind that at the end f the day, yur device vilates the USB specificatin. Hwever in nrmal peratin, if yu try t exceed the 100mA r yur designated permissible lad, then expect the hub r hst t detect this and discnnect yur device, in the interest f the integrity f the bus. Of curse these design issues can be avided if yu chse t design a self pwered device. Suspend currents may nt be a great cncern fr desktp cmputers but with the intrductin f the On-The-G Specificatin we will start seeing USB hsts built int mbile phnes and mbile rganisers. The pwer cnsumptin pulled frm these devices will adversely effect the perating life f the battery. Entering Suspend Mde

11 A USB device will enter suspend when there is n activity n the bus fr greater than 3.0ms. It then has a further 7ms t shutdwn the device and draw n mre than the designated suspend current and thus must be nly drawing the rated suspend current frm the bus 10mS after bus activity stpped. In rder t maintain cnnected t a suspended hub r hst, the device must still prvide pwer t its pull up speed selectin resistrs during suspend. USB has a start f frame packet r keep alive sent peridically n the bus. This prevents an idle bus frm entering suspend mde in the absence f data. A high speed bus will have micr-frames sent every µs ±62.5 ns. A full speed bus will have a frame sent dwn each ms ±500 ns. A lw speed bus will have a keep alive which is a EOP (End f Packet) every 1ms nly in the absence f any lw speed data. The term "Glbal Suspend" is used when the entire USB bus enters suspend mde cllectively. Hwever selected devices can be suspended by sending a cmmand t the hub that the device is cnnected t. This is referred t as a "Selective Suspend." The device will resume peratin when it receives any nn idle signalling. If a device has remte wakeup enabled then it may signal t the hst t resume frm suspend. Data Signalling Rate Anther area which is ften verlked is the tlerance f the USB clcks. This is specified in the USB specificatin, sectin High speed data is clcked at Mb/s with a data signalling tlerance f ± 500ppm. Full speed data is clcked at Mb/s with a data signalling tlerance f ±0.25% r 2,500ppm. Lw speed data is clcked at 1.50Mb/s with a data signalling tlerance f ±1.5% r 15,000ppm. This allws resnatrs t be used fr lw cst lw speed devices, but rules them ut fr full r high speed devices. USB Prtcls Unlike RS-232 and similar serial interfaces where the frmat f data being sent is nt defined, USB is made up f several layers f prtcls. While this sunds cmplicated, dn t give up nw. Once yu understand what is ging n, yu really nly have t wrry abut the higher level layers. In fact mst USB cntrller I.C.s will take care f the lwer layer, thus making it almst invisible t the end designer. Each USB transactin cnsists f a

12 Tken Packet (Header defining what it expects t fllw), an Optinal Data Packet, (Cntaining the paylad) and a Status Packet (Used t acknwledge transactins and t prvide a means f errr crrectin) As we have already discussed, USB is a hst centric bus. The hst initiates all transactins. The first packet, als called a tken is generated by the hst t describe what is t fllw and whether the data transactin will be a read r write and what the device s address and designated endpint is. The next packet is generally a data packet carrying the paylad and is fllwed by an handshaking packet, reprting if the data r tken was received successfully, r if the endpint is stalled r nt available t accept data. Cmmn USB Packet Fields Data n the USBus is transmitted LSBit first. USB packets cnsist f the fllwing fields, Sync All packets must start with a sync field. The sync field is 8 bits lng at lw and full speed r 32 bits lng fr high speed and is used t synchrnise the clck f the receiver with that f the transmitter. The last tw bits indicate where the PID fields starts. PID PID stands fr Packet ID. This field is used t identify the type f packet that is being sent. The fllwing table shws the pssible values. Grup PID Value Packet Identifier 0001 OUT Tken Tken 1001 IN Tken 0101 SOF Tken 1101 SETUP Tken 0011 DATA0 Data 1011 DATA DATA MDATA 0010 ACK Handshake 1010 NAK Handshake Handshake 1110 STALL Handshake 0110 NYET (N Respnse Yet) Special 1100 PREamble

13 1100 ERR 1000 Split 0100 Ping There are 4 bits t the PID, hwever t insure it is received crrectly, the 4 bits are cmplemented and repeated, making an 8 bit PID in ttal. The resulting frmat is shwn belw. PID 0 PID 1 PID 2 PID 3 npid 0 npid 1 npid 2 npid 3 ADDR The address field specifies which device the packet is designated fr. Being 7 bits in length allws fr 127 devices t be supprted. Address 0 is nt valid, as any device which is nt yet assigned an address must respnd t packets sent t address zer. ENDP The endpint field is made up f 4 bits, allwing 16 pssible endpints. Lw speed devices, hwever can nly have 2 additinal endpints n tp f the default pipe. (4 endpints max) CRC Cyclic Redundancy Checks are perfrmed n the data within the packet paylad. All tken packets have a 5 bit CRC while data packets have a 16 bit CRC. EOP End f packet. Signalled by a Single Ended Zer (SE0) fr apprximately 2 bit times fllwed by a J fr 1 bit time. USB Packet Types USB has fur different packet types. Tken packets indicate the type f transactin t fllw, data packets cntain the paylad, handshake packets are used fr acknwledging data r reprting errrs and start f frame packets indicate the start f a new frame. Tken Packets There are three types f tken packets, In - Infrms the USB device that the hst wishes t read infrmatin.

14 Out - Infrms the USB device that the hst wishes t send infrmatin. Setup - Used t begin cntrl transfers. Tken Packets must cnfrm t the fllwing frmat, Sync PID ADDR ENDP CRC5 EOP Data Packets There are tw types f data packets each capable f transmitting up t 1024 bytes f data. Data0 Data1 High Speed mde defines anther tw data PIDs, DATA2 and MDATA. Data packets have the fllwing frmat, Sync PID Data CRC16 EOP Maximum data paylad size fr lw-speed devices is 8 bytes. Maximum data paylad size fr full-speed devices is 1023 bytes. Maximum data paylad size fr high-speed devices is 1024 bytes. Data must be sent in multiples f bytes. Handshake Packets There are three type f handshake packets which cnsist simply f the PID ACK - Acknwledgment that the packet has been successfully received. NAK - Reprts that the device temprary cannt send r received data. Als used during interrupt transactins t infrm the hst there is n data t send. STALL - The device finds its in a state that it requires interventin frm the hst. Handshake Packets have the fllwing frmat, Sync PID EOP Start f Frame Packets

15 The SOF packet cnsisting f an 11-bit frame number is sent by the hst every 1ms ± 500ns n a full speed bus r every 125 µs ± µs n a high speed bus. Sync PID Frame Number CRC5 EOP USB Functins When we think f a USB device, we think f a USB peripheral, but a USB device culd mean a USB transceiver device used at the hst r peripheral, a USB Hub r Hst Cntrller IC device, r a USB peripheral device. The standard therefre makes references t USB functins which can be seen as USB devices which prvide a capability r functin such as a Printer, Zip Drive, Scanner, Mdem r ther peripheral. S by nw we shuld knw the srt f things which make up a USB packet. N? Yu're frgtten hw many bits make up a PID field already? Well dn't be t alarmed. Frtunately mst USB functins handle the lw level USB prtcls up t the transactin layer (which we will cver next chapter) in silicn. The reasn why we cver this infrmatin is mst USB functin cntrllers will reprt errrs such as PID Encding Errr. Withut briefly cvering this, ne culd ask what is a PID Encding Errr? If yu suggested that the last fur bits f the PID didn't match the inverse f the first fur bits then yu wuld be right.

16 Mst functins will have a series f buffers, typically 8 bytes lng. Each buffer will belng t an endpint - EP0 IN, EP0 OUT etc. Say fr example, the hst sends a device descriptr request. The functin hardware will read the setup packet and determine frm the address field whether the packet is fr itself, and if s will cpy the paylad f the fllwing data packet t the apprpriate endpint buffer dictated by the value in the endpint field f the setup tken. It will then send a handshake packet t acknwledge the receptin f the byte and generate an internal interrupt within the semicnductr/micr-cntrller fr the apprpriate endpint signifying it has received a packet. This is typically all dne in hardware. The sftware nw gets an interrupt, and shuld read the cntents f the endpint buffer and parse the device descriptr request. Endpints Endpints can be described as surces r sinks f data. As the bus is hst centric, endpints ccur at the end f the cmmunicatins channel at the USB functin. At the sftware layer, yur device driver may send a packet t yur devices EP1 fr example. As the data is flwing ut frm the hst, it will end up in the EP1 OUT buffer. Yur firmware will then at its leisure read this data. If it wants t return data, the functin cannt simply write t the bus as the bus is cntrlled by the hst. Therefre it writes data t EP1 IN which sits in the buffer until such time when the hst sends a IN packet t that endpint requesting the data. Endpints can als be seen as the interface between the hardware f the functin device and the firmware running n the functin device. All devices must supprt endpint zer. This is the endpint which receives all f the devices cntrl and status requests during enumeratin and thrughut the duratin while the device is peratinal n the bus. Pipes While the device sends and receives data n a series f endpints, the client sftware transfers data thrugh pipes. A pipe is a lgical cnnectin between the hst and endpint(s). Pipes will als have a set f parameters assciated with them such as hw much bandwidth is allcated t it, what transfer type (Cntrl, Bulk, Is r Interrupt) it uses, a directin f data flw and maximum packet/buffer sizes. Fr example the default pipe is a bi-directinal pipe made up f endpint zer in and endpint zer ut with a cntrl transfer type. USB defines tw types f pipes Stream Pipes have n defined USB frmat, that is yu can send any type f data dwn a stream pipe and can retrieve the data ut the ther end. Data flws sequentially and has a pre-defined directin, either in r ut. Stream pipes will supprt bulk, ischrnus and interrupt transfer types. Stream pipes can either be cntrlled by the hst r device.

17 Message Pipes have a defined USB frmat. They are hst cntrlled, which are initiated by a request sent frm the hst. Data is then transferred in the desired directin, dictated by the request. Therefre message pipes allw data t flw in bth directins but will nly supprt cntrl transfers. Endpint Types The Universal Serial Bus specificatin defines fur transfer/endpint types, Cntrl Transfers Interrupt Transfers Ischrnus Transfers Bulk Transfers Cntrl Transfers Cntrl transfers are typically used fr cmmand and status peratins. They are essential t set up a USB device with all enumeratin functins being perfrmed using cntrl transfers. They are typically bursty, randm packets which are initiated by the hst and use best effrt delivery. The packet length f cntrl transfers in lw speed devices must be 8 bytes, high speed devices allw a packet size f 8, 16, 32 r 64 bytes and full speed devices must have a packet size f 64 bytes. A cntrl transfer can have up t three stages. The Setup Stage is where the request is sent. This cnsists f three packets. The setup tken is sent first which cntains the address and endpint number. The data packet is sent next and always has a PID type f data0 and includes a setup packet which details the type f request. We detail the setup packet later. The last packet is a handshake used fr acknwledging successful receipt r t indicate an errr. If the functin successfully receives the setup data (CRC and PID etc OK) it respnds with ACK, therwise it ignres the data and desn t send a handshake packet. Functins cannt issue a STALL r NAK packet in respnse t a setup packet.

18 The ptinal Data Stage cnsists f ne r multiple IN r OUT transfers. The setup request indicates the amunt f data t be transmitted in this stage. If it exceeds the maximum packet size, data will be sent in multiple transfers each being the maximum packet length except fr the last packet. The data stage has tw different scenaris depending upn the directin f data transfer. IN: When the hst is ready t receive cntrl data it issues an IN Tken. If the functin receives the IN tken with an errr e.g. the PID desn't match the inverted PID bits, then it ignres the packet. If the tken was received crrectly, the device can either reply with a DATA packet cntaining the cntrl data t be sent, a stall packet indicating the endpint has had a errr r a NAK packet indicating t the hst that the endpint is wrking, but temprary has n data t send. OUT: When the hst needs t send the device a cntrl data packet, it issues an OUT tken fllwed by a data packet cntaining the cntrl data as the paylad. If any part f the OUT tken r data packet is crrupt then

19 the functin ignres the packet. If the functin's endpint buffer was empty and it has clcked the data int the endpint buffer it issues an ACK infrming the hst it has successfully received the data. If the endpint buffer is nt empty due t prcessing f the previus packet, then the functin returns a NAK. Hwever if the endpint has had a errr and its halt bit has been set, it returns a STALL. Status Stage reprts the status f the verall request and this nce again varies due t directin f transfer. Status reprting is always perfrmed by the functin. IN: If the hst sent IN tken(s) during the data stage t receive data, then the hst must acknwledge the successful recept f this data. This is dne by the hst sending an OUT tken fllwed by a zer length data packet. The functin can nw reprt its status in the handshaking stage. An ACK indicates the functin has cmpleted the cmmand is nw ready t accept anther cmmand. If an errr ccurred during the prcessing f this cmmand, then the functin will issue a STALL. Hwever if the functin is still prcessing, it returns a NAK indicating t the hst t repeat the status stage later. OUT: If the hst sent OUT tken(s) during the data stage t transmit data, the functin will acknwledge the successful recept f data by sending a zer length packet in respnse t an IN tken. Hwever if an errr ccurred, it shuld issue a STALL r if it is still busy prcessing data, it shuld issue a NAK asking the hst t retry the status phase later.

20 Cntrl Transfers : The bigger picture Nw hw des all this fit tgether? Let's say fr example, the Hst wants t request a device descriptr during enumeratin. The packets which are sent are as fllws. The hst will send the Setup tken telling the functin that the fllwing packet is a Setup packet. The Address field will hld the address f the device the hst is requesting the descriptr frm. The endpint number shuld be zer, specifying the default pipe. The hst will then send a DATA0 packet. This will have an 8 byte paylad which is the Device Descriptr Request as utlined in Chapter 9 f the USB Specificatin. The USB functin then acknwledges the setup packet has been read crrectly with n errrs. If the packet was received crrupt, the device just ignres this packet. The hst will then resend the packet after a shrt delay. 1. Setup Tken Sync PID ADDR ENDP CRC5 EOP Address & Endpint Number 2. Data0 Packet Sync PID Data0 CRC16 EOP Device Descriptr Request 3. Ack Handshake Sync PID EOP Device Ack. Setup Packet The abve three packets represent the first USB transactin. The USB device will nw decde the 8 bytes received, and determine it was a device descriptr request. The device will then attempt t send the Device Descriptr, which will be the next USB transactin. 1. In Tken Sync PID ADDR ENDP CRC5 EOP Address & Endpint Number 2. Data1 Packet Sync PID Data1 CRC16 EOP First 8 Bytes f Device Descriptr 3. Ack Handshake Sync PID EOP Hst Acknwledges Packet 1. In Tken Sync PID ADDR ENDP CRC5 EOP Address & Endpint Number

21 2. Data0 Packet Sync PID Data0 CRC16 EOP Last 4 bytes + Padding 3. Ack Handshake Sync PID EOP Hst Acknwledges Packet In this case, we assume that the maximum paylad size is 8 bytes. The hst sends the IN tken, telling the device it can nw send data fr this endpint. As the maximum packet size is 8 bytes, we must split up the 12 byte device descriptr int chunks t send. Each chunk must be 8 bytes except fr the last transactin. The hst acknwledges every data packet we send it. Once the device descriptr is sent, a status transactin fllws. If the transactins were successful, the hst will send a zer length packet indicating the verall transactin was successful. The functin then replies t this zer length packet indicating its status. 1. Out Tken Sync PID ADDR ENDP CRC5 EOP Address & Endpint Number 2. Data1 Packet Sync PID Data1 CRC16 EOP Zer Length Packet 3. Ack Handshake Sync PID EOP Device Ack. Entire Transactin Interrupt Transfers Any ne wh has had experience f interrupt requests n micrcntrllers will knw that interrupts are device generated. Hwever under USB if a device requires the attentin f the hst, it must wait until the hst plls it befre it can reprt that it needs urgent attentin! Interrupt Transfers Guaranteed Latency Stream Pipe - Unidirectinal Errr detectin and next perid retry.

22 Interrupt transfers are typically nn-peridic, small device "initiated" cmmunicatin requiring bunded latency. An Interrupt request is queued by the device until the hst plls the USB device asking fr data. The maximum data paylad size fr lw-speed devices is 8 bytes. Maximum data paylad size fr full-speed devices is 64 bytes. Maximum data paylad size fr high-speed devices is 1024 bytes. The abve diagram shws the frmat f an Interrupt IN and Interrupt OUT transactin. IN: The hst will peridically pll the interrupt endpint. This rate f plling is specified in the endpint descriptr which is cvered later. Each pll will invlve the hst sending an IN Tken. If the IN tken is crrupt, the functin ignres the packet and cntinues mnitring the bus fr new tkens. If an interrupt has been queued by the device, the functin will send a data packet cntaining data relevant t the interrupt when it receives the IN Tken. Upn successful recept at the hst, the hst will return an ACK. Hwever if the data is crrupted, the hst will return n status. If n the ther hand a interrupt cnditin was nt present when the hst plled the interrupt endpint with an IN tken, then the functin signals this state by sending a NAK. If an errr has ccurred n this endpint, a STALL is sent in reply t the IN tken instead. OUT: When the hst wants t send the device interrupt data, it issues an OUT tken fllwed by a data packet cntaining the interrupt data. If any part f the OUT tken r data packet is crrupt then the functin ignres the packet. If the functin's endpint buffer was empty and it has clcked the data int the endpint buffer it issues an ACK infrming the hst it has successfully received the data. If

23 the endpint buffer is nt empty due t prcessing f a previus packet, then the functin returns an NAK. Hwever if an errr ccurred with the endpint cnsequently and its halt bit has been set, it returns a STALL. Ischrnus Transfers Ischrnus transfers ccur cntinuusly and peridically. They typically cntain time sensitive infrmatin, such as an audi r vide stream. If there were a delay r retry f data in an audi stream, then yu wuld expect sme erratic audi cntaining glitches. The beat may n lnger be in sync. Hwever if a packet r frame was drpped every nw and again, it is less likely t be nticed by the listener. Ischrnus Transfers prvide Guaranteed access t USB bandwidth. Bunded latency. Stream Pipe - Unidirectinal Errr detectin via CRC, but n retry r guarantee f delivery. Full & high speed mdes nly. N data tggling. The maximum size data paylad is specified in the endpint descriptr f an Ischrnus Endpint. This can be up t a maximum f 1023 bytes fr a full speed device and 1024 bytes fr a high speed device. As the maximum data paylad size is ging t effect the bandwidth requirements f the bus, it is wise t specify a cnservative paylad size. If yu are using a large paylad, it may als be t yur advantage t specify a series f alternative interfaces with varying ischrnus paylad sizes. If during enumeratin, the hst cannt enable yur preferred ischrnus endpint due t bandwidth restrictins, it has smething t fall back n rather than just failing cmpletely. Data being sent n an ischrnus endpint can be less than the pre-negtiated size and may vary in length frm transactin t transactin. The abve diagram shws the frmat f an Ischrnus IN and OUT transactin. Ischrnus transactins d nt have a handshaking stage and cannt reprt errrs r STALL/HALT cnditins.

24 Bulk Transfers Bulk transfers can be used fr large bursty data. Such examples culd include a print-jb sent t a printer r an image generated frm a scanner. Bulk transfers prvide errr crrectin in the frm f a CRC16 field n the data paylad and errr detectin/retransmissin mechanisms ensuring data is transmitted and received withut errr. Bulk transfers will use spare un-allcated bandwidth n the bus after all ther transactins have been allcated. If the bus is busy with ischrnus and/r interrupt then bulk data may slwly trickle ver the bus. As a result Bulk transfers shuld nly be used fr time insensitive cmmunicatin as there is n guarantee f latency. Bulk Transfers Used t transfer large bursty data. Errr detectin via CRC, with guarantee f delivery. N guarantee f bandwidth r minimum latency. Stream Pipe - Unidirectinal Full & high speed mdes nly. Bulk transfers are nly supprted by full and high speed devices. Fr full speed endpints, the maximum bulk packet size is either 8, 16, 32 r 64 bytes lng. Fr high speed endpints, the maximum packet size can be up t 512 bytes lng. If the data paylad falls shrt f the maximum packet size, it desn't need t be padded with zers. A bulk transfer is cnsidered cmplete when it has transferred the exact amunt f data requested, transferred a packet less than the maximum endpint size f transferred a zerlength packet.

25 The abve diagram shws the frmat f a bulk IN and OUT transactin. IN: When the hst is ready t receive bulk data it issues an IN Tken. If the functin receives the IN tken with an errr, it ignres the packet. If the tken was received crrectly, the functin can either reply with a DATA packet cntaining the bulk data t be sent, r a stall packet indicating the endpint has had a errr r a NAK packet indicating t the hst that the endpint is wrking, but temprary has n data t send. OUT: When the hst wants t send the functin a bulk data packet, it issues an OUT tken fllwed by a data packet cntaining the bulk data. If any part f the OUT tken r data packet is crrupt then the functin ignres the packet. If the functin's endpint buffer was empty and it has clcked the data int the endpint buffer it issues an ACK infrming the hst it has successfully received the data. If the endpint buffer is nt empty due t prcessing a previus packet, then the functin returns an NAK. Hwever if the endpint has had an errr and it's halt bit has been set, it returns a STALL. Bandwidth Management The hst is respnsible in managing the bandwidth f the bus. This is dne at enumeratin when cnfiguring Ischrnus and Interrupt Endpints and thrughut the peratin f the bus. The specificatin places limits n the bus, allwing n mre than 90% f any frame t be allcated fr peridic transfers (Interrupt and Ischrnus) n a full speed bus. On high speed buses this limitatin gets reduced t n mre than 80% f a micrframe can be allcated fr peridic transfers.

26 S yu can quite quickly see that if yu have a highly saturated bus with peridic transfers, the remaining 10% is left fr cntrl transfers and nce thse have been allcated, bulk transfers will get its slice f what is left. USB Descriptrs All USB devices have a hierarchy f descriptrs which describe t the hst infrmatin such as what the device is, wh makes it, what versin f USB it supprts, hw many ways it can be cnfigured, the number f endpints and their types etc The mre cmmn USB descriptrs are Device Descriptrs Cnfiguratin Descriptrs Interface Descriptrs Endpint Descriptrs String Descriptrs USB devices can nly have ne device descriptr. The device descriptr includes infrmatin such as what USB revisin the device cmplies t, the Prduct and Vendr IDs used t lad the apprpriate drivers and the number f pssible cnfiguratins the device can have. The number f cnfiguratins indicate hw many cnfiguratin descriptrs branches are t fllw. The cnfiguratin descriptr specifies values such as the amunt f pwer this particular cnfiguratin uses, if the device is self r bus pwered and the number f interfaces it has. When a device is enumerated, the hst reads the device descriptrs and can make a decisin f which cnfiguratin t enable. It can nly enable ne cnfiguratin at a time. Fr example, It is pssible t have a high pwer bus pwered cnfiguratin and a self pwered cnfiguratin. If the device is plugged int a hst with a mains pwer supply, the device driver may chse t enable the high pwer bus pwered cnfiguratin enabling the device t be pwered withut a cnnectin t the mains, yet if it is cnnected t a laptp r persnal rganiser it culd enable the 2nd cnfiguratin (self pwered) requiring the user t plug yur device int the pwer pint. The cnfiguratin settings are nt limited t pwer differences. Each cnfiguratin culd be pwered in the same way and draw the same current, yet have different interface r endpint cmbinatins. Hwever it shuld be nted that changing the cnfiguratin requires all activity n each endpint t stp. While USB ffers this flexibility, very few devices have mre than 1 cnfiguratin.

27 The interface descriptr culd be seen as a header r gruping f the endpints int a functinal grup perfrming a single feature f the device. Fr example yu culd have a multi-functin fax/scanner/printer device. Interface descriptr ne culd describe the endpints f the fax functin, Interface descriptr tw the scanner functin and Interface descriptr three the printer functin. Unlike the cnfiguratin descriptr, there is n limitatin as t having nly ne interface enabled at a time. A device culd have 1 r many interface descriptrs enabled at nce. Interface descriptrs have a binterfacenumber field specifying the Interface number and a balternatesetting which allws an interface t change settings n the fly. Fr example we culd have a device with tw interfaces, interface ne and interface tw. Interface ne has binterfacenumber set t zer indicating it is the first interface descriptr and a balternativesetting f zer. Interface tw wuld have a binterfacenumber set t ne indicating it is the secnd interface and a balternativesetting f zer (default). We culd then thrw in anther descriptr, als with a binterfacenumber set t ne indicating it is the secnd interface, but this time setting the balternativesetting t ne, indicating this interface descriptr can be an alternative setting t that f the ther interface descriptr tw. When this cnfiguratin is enabled, the first tw interface descriptrs with balternativesettings equal t zer is used. Hwever during peratin the hst can send a SetInterface request directed t that f Interface ne with a alternative setting f ne t enable the ther interface descriptr.

28 This gives an advantage ver having tw cnfiguratins, in that we can be transmitting data ver interface zer while we change the endpint settings assciated with interface ne withut effecting interface zer. Each endpint descriptr is used t specify the type f transfer, directin, plling interval and maximum packet size fr each endpint. Endpint zer, the default cntrl endpint is always assumed t be a cntrl endpint and as such never has a descriptr. Cmpsitin f USB Descriptrs All descriptrs are made up f a cmmn frmat. The first byte specifies the length f the descriptr, while the secnd byte indicates the descriptr type. If the length f a descriptr is smaller than what the specificatin defines, then the hst shall ignre it. Hwever if the size is greater than expected the hst will ignre the extra bytes and start lking fr the next descriptr at the end f actual length returned. Offset Field Size Value Descriptin 0 blength 1 Number Size f Descriptr in Bytes 1 bdescriptintype 1 Cnstant DescriptrType 2... n Start f parameters fr descriptr Device Descriptrs The device descriptr f a USB device represents the entire device. As a result a USB device can nly have ne device descriptr. It specifies sme basic, yet imprtant