USB Complete fourth- P7 doc

Chapter 2 36 the received data and take any other required action. On receiving an IN packet, if the endpoint has data ready to send to the host, the hardware sends the data on the bus and typically triggers an interrupt. Firmware can then do whatever is needed to get ready to send data in the next IN transaction. An end- point that isn’t ready to send or receive data in response to an IN or OUT packet sends a status code. For SuperSpeed transactions, the protocol differs as described later in this chap- ter. 2KRGU%QPPGEVKPI'PFRQKPVUVQVJG*QUV Before data can transfer, the host and device must establish a pipe. A pipe is an association between a device’s endpoint and the host controller’s software. Host software establishes a pipe with each endpoint address the host wants to com- municate with. The host establishes pipes during enumeration. If a user detaches a device from the bus, the host removes the no longer needed pipes. The host can also request new pipes or remove unneeded pipes by using control transfers to request an alternate configuration or interface for a device. Every device has a default con- trol pipe that uses endpoint zero. The configuration information received by the host includes an endpoint descriptor for each endpoint that the device wants to use. Each endpoint descriptor contains an endpoint address, the type of transfer the endpoint sup- ports, the maximum size of data packets, and, when appropriate, the desired interval for transfers. 6[RGUQH6TCPUHGTU Devices with varied and differing requirements for transfer rate, response time, and error correcting can all use USB. Each of the four types of data transfers meets different needs. Each device can support the transfer types that are best suited for its purpose. Table 2-1 summarizes the features and uses of each type. Control transfers are the only type with functions defined by the USB specifica- tion. Control transfers enable the host to read information about a device, set a device’s address, and select configurations and other settings. With driver sup- port, control transfers can also contain class- and vendor-specific requests that send and receive data for any purpose. All USB devices must support control transfers. Inside USB Transfers 37 Bulk transfers are intended for applications where the rate of transfer isn’t criti- cal, such as sending a file to a printer, receiving data from a scanner, or accessing files on a drive. For these applications, quick transfers are nice, but the data can wait if necessary. On a busy bus, bulk transfers have to wait, but on a bus that is otherwise idle, bulk transfers are the fastest type. Low speed devices don’t sup- Table 2-1: Each of the USB’s four transfer types is suited for different uses. 6TCPUHGT6[RG %QPVTQN $WNM +PVGTTWRV +UQEJTQPQWU 6[RKECN7UG Identification and configuration Printer, scanner, drive Mouse, keyboard Streaming audio, video 5WRRQTVTGSWKTGF! yesnonono .QYURGGFCNNQYGF! yes no yes no /CZKOWORCEMGVUK\G OCZKOWOIWCTCPVGGF RCEMGVUKPVGTXCN5WRGT5RGGF 512; none 1024; none 1024; 3 / 125 µs 1024; 48 / 125 µs /CZKOWORCEMGVUK\G OCZKOWOIWCTCPVGGF RCEMGVUKPVGTXCNJKIJURGGF 64; none 512; none 1024; 3 / 125 µs 1024; 3 / 125 µs /CZKOWORCEMGVUK\G OCZKOWOIWCTCPVGGF RCEMGVUKPVGTXCNHWNNURGGF 64; none 64; none 64: 1 / ms 1023; 1 / ms /CZKOWORCEMGVUK\G OCZKOWOIWCTCPVGGF RCEMGVUKPVGTXCNNQYURGGF 8; none not allowed 8; 1 / 10 ms not allowed &KTGEVKQPQHFCVCHNQY IN and OUT IN or OUT IN or OUT (IN only for USB 1.0) IN or OUT 4GUGTXGFDCPFYKFVJHQTCNN VTCPUHGTUQHVJGV[RG 10% at low/full speed, 20% at high speed & SuperSpeed none 90% at low/full speed, 80% at high speed and SuperSpeed (isochronous and interrupt combined, maximum) /GUUCIGQT5VTGCOFCVC! message stream stream stream 'TTQTEQTTGEVKQP! yes yes yes no )WCTCPVGGFFGNKXGT[TCVG! no no no yes )WCTCPVGGFNCVGPE[OCZKOWO VKOGDGVYGGPVTCPUHGTU CVVGORVU! no no yes yes Chapter 2 38 port bulk endpoints. Devices aren’t required to support bulk transfers, but a specific device class can require them. Interrupt transfers are for devices that must receive the host’s or device’s atten- tion periodically, or with low latency, or delay. Other than control transfers, interrupt transfers are the only way low-speed devices can transfer data. Key- boards and mice use interrupt transfers to send keypress and mouse-movement data. Interrupt transfers can use any speed. Devices aren’t required to support interrupt transfers, but a specific device class can require them. Isochronous transfers have guaranteed delivery time but no error correcting. Data that uses isochronous transfers incudes streaming audio and video. Isoch- ronous is the only transfer type that doesn’t support automatic re-transmitting of data received with errors, so occasional errors must be acceptable. Low-speed devices don’t support isochronous endpoints. Devices aren’t required to support isochronous transfers, but a specific device class can require them. 5VTGCOCPF/GUUCIG2KRGU In addition to classifying a pipe by the type of transfer it carries, the USB speci- fication defines pipes as either stream or message. Control transfers use bidirec- tional message pipes; all other transfer types use unidirectional stream pipes. %QPVTQN6TCPUHGTU In a control transfer’s message pipe, a transfer begins with a transaction contain- ing a request. Depending on the request, to complete the transfer, the host and device may exchange data and status information, or the device may just send status information. Each control transfer has at least one transaction that sends information in each direction. If a device supports a received request, the device takes the requested action. If a device doesn’t support the request, the device responds with a code to indicate that the request isn’t supported. 1VJGT6TCPUHGTU The data in a stream pipe has no structure defined by the USB specification. The receiver just accepts or rejects the data that arrives. The device firmware or host software can process the data in whatever way is appropriate for the appli- cation. Of course, even with stream data, the sending and receiving devices must agree on a format of some type. For example, a host application may define a format Inside USB Transfers 39 for a received series of bytes that contain a temperature reading and the time of the reading. +PKVKCVKPIC6TCPUHGT The USB 2.0 specification defines a transfer as one or more bus transactions that move information between a software client and its function. A transfer may be very short, sending as little as a byte of application data, or very long, sending the contents of a large file. Windows applications can access some USB devices by calling API functions to open a handle to the device and request data transfers. The operating system passes a request to transfer data to a device or class driver, which in turn passes the request to other system-level drivers and on to the host controller. The host controller initiates the transfer on the bus. For devices in standard classes, a programming language can provide alternate ways to access a device. In many cases, the application doesn’t have to know or care whether the device uses USB or another interface. For example, the .NET Framework includes Directory and File classes for accessing files on drives, which may use USB. A vendor-supplied driver can also define API functions. For example, chip company FTDI provides a driver that exposes functions for setting communications parameters and exchanging data with FTDI’s control- ler chips. For receiving data from a device, some drivers request the host controller to poll an endpoint at intervals, while other drivers don’t initiate communications unless an application has requested data from the device. 75$6TCPUCEVKQPU Figure 2-1 shows the elements of a typical USB 2.0 transfer. A lot of the termi- nology here begins to sound the same. There are transfers and transactions, stages and phases, data transactions and data packets. There are Status stages and handshake phases. Data stages have handshake packets and Status stages have data packets. It can take a while to absorb it all. Table 2-2 lists the ele- ments that make up each of the four transfer types. Each transfer consists of one or more transactions, and each transaction in turn consists of two or three packets. (Start-of-Frame markers transmit in single packets.) The USB 2.0 specification defines a transaction as the delivery of ser- vice to an endpoint. Service in this case can mean either the host’s sending infor- Chapter 2 40 mation to the device or the host’s requesting and receiving information from the device. Setup transactions send control-transfer requests to a device. OUT transactions send other data or status information to the device. IN transactions send data or status information to the host. Each USB 2.0 transaction includes identifying, error-checking, status, and con- trol information as well as any data to be exchanged. A transfer may take place over multiple frames or microframes, but each USB 2.0 transaction completes within a frame or microframe without interruption. No other packets on the bus can break into the middle of a transaction. Devices must respond quickly with requested data or status information. Device firmware typically arms (sets up, or configures) an endpoint’s response to a received packet, and on receiving a packet, the hardware places the response on the bus. Figure 2-1. A USB 2.0 transfer consists of transactions. The transactions in turn contain packets, and the packets contain a packet identifier (PID) and sometimes additional information. Inside USB Transfers 41 A non-control transfer with a small amount of data may complete in a single transaction. Other transfers use multiple transactions with each carrying a por- tion of the data. 6TCPUCEVKQP2JCUGU Each transaction has up to three phases, or parts that occur in sequence: token, data, and handshake. Each phase consists of one or two transmitted packets. Each packet is a block of information with a defined format. All packets begin with a Packet ID (PID) that contains identifying information (Table 2-3). Depending on the transaction, the PID may be followed by an endpoint address, data, status information, or a frame number, along with error-checking bits. Table 2-2: Each USB 2.0 transaction has two or three phases. (Not shown are additional transactions required for split transactions, the PING protocol used in some transfers, and the PRE packet that precedes downstream, low-speed packets.) 6TCPUHGT6[RG 0WODGTCPF&KTGEVKQPQH6TCPUCEVKQPU 2JCUGURCEMGVU Control Setup Stage One (SETUP) Token Data Handshake Data Stage Zero or more (IN or OUT) Token Data Handshake Status Stage One (opposite direction of the transaction(s) in the Data stage or IN if there is no Data stage) Token Data Handshake Bulk One or more (IN or OUT) Token Data Handshake Interrupt One or more (IN or OUT) Token Data Handshake Isochronous One or more (IN or OUT) Token Data Chapter 2 42 Table 2-3: The PID provides information about a transaction. (Part 1 of 2) 2CEMGV 6[RG 2+& 0COG 8CNWG DKPCT[ 6TCPUHGT V[RGUWUGF KP 5QWTEG $WU 5RGGF &GUETKRVKQP Toke n (identifies transaction type) OUT 0001 all host all Device and endpoint address for OUT transaction. IN 1001 all host all Device and endpoint address for IN transaction. SOF 0101 Start of Frame host all Start-of-Frame marker and frame number. SETUP 1101 control host all Device and endpoint address for Setup transaction. Data (carries data or status code) DATA0 0011 all host, device all Data toggle or data PID sequencing DATA1 1011 all host, device all Data toggle or data PID sequencing DATA2 0111 isochronous host, device high Data PID sequencing MDATA 1111 isochronous, split transactions host, device high Data PID sequencing Handshake (carries status code) ACK 0010 control, bulk, interrupt host, device all Receiver accepts error-free data packet. NAK 1010 control, bulk, interrupt device all Receiver can’t accept data or sender can’t send data or has no data to transmit. STALL 1110 control, bulk, interrupt device all A control request isn’t supported or the endpoint is halted. NYET 0110 control write, bulk OUT, split transactions device high Device accepts an error-free data packet but isn’t ready for another, or a hub doesn’t yet have complete-split data. Inside USB Transfers 43 In the token phase of a transaction, the host initiates a communication by send- ing a token packet. The PID indicates the transaction type, such as Setup, IN, OUT, or SOF. In the data phase, the host or device may transfer any kind of information in a data packet. The PID includes a data-toggle or data PID sequencing value that guards against lost or duplicated data when a transfer has multiple data packets. In the handshake phase, the host or device sends status information in a hand- shake packet. The PID contains a status code (ACK, NAK, STALL, or NYET). The USB 2.0 specification sometimes uses the terms status phase and status packet to refer to the handshake phase and packet. The token phase has one additional use. A token packet can carry a Start-of-Frame (SOF) marker, which is a timing reference that the host sends at 1-ms intervals at full speed and at 125- µs intervals at high speed. This packet also contains a frame number that increments, rolling over on exceeding the maximum value. The number indicates the frame count, so the eight microf- Special PRE 1100 control, interrupt host full Preamble issued by a host to indicate that the next packet is low speed (low/full-speed segment only). ERR 1100 all hub high Returned by a hub to report a low- or full-speed error in a split transaction (high- speed segment only). SPLIT 1000 all host high Precedes a token packet to indicate a split transaction. PING 0100 control write, bulk OUT host high Busy check for bulk OUT and control write data transactions after NYET. EXT 0000 – host all Protocol extension token Table 2-3: The PID provides information about a transaction. (Part 2 of 2) 2CEMGV 6[RG 2+& 0COG 8CNWG DKPCT[ 6TCPUHGT V[RGUWUGF KP 5QWTEG $WU 5RGGF &GUETKRVKQP Chapter 2 44 rames within a frame all have the same number. An endpoint can synchronize to the SOF packet or use the frame count as a timing reference. The SOF marker also keeps devices from entering the low-power Suspend state when the bus has no other USB traffic. Low-speed devices don’t see the SOF packet. Instead, the hub the device attaches to provides an End-of-Packet (EOP) signal, called the low-speed keep-alive signal, once per frame. As the SOF does for full- and high-speed devices, the low-speed keep-alive keeps low-speed devices from entering the Suspend state. The PRE PID contains a preamble code that tells hubs that the next packet is low speed. On receiving a PRE PID, the hub enables communications with any attached low-speed devices. On a low- and full-speed bus, the PRE PID pre- cedes all token, data, and handshake packets directed to low-speed devices. High-speed buses encode the PRE in the SPLIT packet, rather than sending the PRE separately. Low-speed packets sent by a device don’t require a PRE PID. In a high-speed bulk or control transfer with multiple data packets, before send- ing the second and any subsequent data packets, the host may send a PING PID to find out if the endpoint is ready to receive more data. The device responds with a status code. The SPLIT PID identifies a token packet as part of a split transaction, as explained later in this chapter. The ERR PID is only for split transactions. A USB 2.0 hub uses this PID to report an error in a downstream low- or full-speed transaction. The ERR and PRE PIDs have the same value but don’t cause confusion because a hub never sends a PRE to the host or an ERR to a device. Also, ERR is only for high-speed segments and PRE never transmits on high-speed segments. The Link Power Management addendum to the USB 2.0 specification defines the EXT PID. The host follows an EXT token packet with an extended token packet for a specific function. Chapter 16 has more about an extended token packet for use in power management. 2CEMGV5GSWGPEGU Every USB 2.0 transaction has a token packet. The host is always the source of this packet, which sets up the transaction by identifying the packet type, the receiving device and endpoint, and the direction of any data the transaction will transfer. For low-speed transactions on a full-speed bus, a PRE packet precedes Inside USB Transfers 45 the token packet. For split transactions, a SPLIT packet precedes the token packet. Depending on the transfer type and whether the host or device has information to send, a data packet may follow the token packet. The direction specified in the token packet determines whether the host or device sends the data packet. In all transfer types except isochronous, the receiver of the data packet (or the device if there is no data packet) returns a handshake packet containing a code that indicates the success or failure of the transaction. The absence of an expected handshake packet can indicate a more serious error or an unsupported Packet ID. 6KOKPI%QPUVTCKPVUCPF)WCTCPVGGU The allowed delays between the token, data, and handshake packets of a USB 2.0 transaction are very short, intended to allow only for cable delays and switching times plus a brief time to allow hardware (not firmware) to determine a response, such as data or a status code, in response to a received packet. A common mistake in writing firmware is to assume that the firmware should wait for an interrupt before providing data to send to the host. Instead, before the host requests the data, the firmware must copy the data to send into the endpoint’s buffer and arm the endpoint to send the data on receiving an IN token packet. The interrupt occurs when the transaction completes. After a suc- cessful transaction, the interrupt informs the firmware that the endpoint’s buffer is ready to store data for the next transaction. If the firmware waits for an interrupt before providing the initial data, the interrupt never happens and data doesn’t transfer. A single transaction can carry data bytes up to the maximum packet size the device specifies for the endpoint. A data packet with fewer than the maximum packet size’s number of bytes is a short packet. A transfer with multiple transac- tions can take place over multiple frames or microframes, which don’t have to be contiguous. For example, in a full-speed bulk transfer of 512 bytes, the max- imum number of bytes in a single transaction is 64, so transferring all of the data requires at least eight transactions, which may occur in one or more frames. A data packet that contains a Data PID and error-checking bits but no data bytes is a zero-length packet (ZLP). A ZLP can indicate the end of a transfer or successful completion of a control transfer. . vendor-specific requests that send and receive data for any purpose. All USB devices must support control transfers. Inside USB Transfers 37 Bulk transfers are intended for applications where the. may define a format Inside USB Transfers 39 for a received series of bytes that contain a temperature reading and the time of the reading. +PKVKCVKPIC6TCPUHGT The USB 2.0 specification defines. or care whether the device uses USB or another interface. For example, the .NET Framework includes Directory and File classes for accessing files on drives, which may use USB. A vendor-supplied driver