`
`
`
`
`
`N A x E L S o N IPRZEI’l—gQQ4gs1l
`
`No custom drivers needed—use
`
`the Win32 API and Visual Basic
`
`FISI Ex 2003-p 1
`LG v FISI
`IPR2018-00461
`
`

`

` U S if???
`
`Complete
`
`Everything You Need
`to Develop Custom USB Peripherals
`
`Jan Axeison
`
`
`
`FISI Ex 2003-p 2
`LG v FISI
`IPR2018-00461
`
`

`

`copyright 1999 by Jan Axelson. All rights reserved.
`Published by Lakeview Research
`
`Cover by Rattray Design. Cover Photo by Bill Biisiey Photography.
`
`Lakeview Research
`
`2209 Winnebago St.
`
`Madison, W153704
`
`USA
`
`Phone: (SOS—2416824
`
`Fax: 608—2416848
`
`Email: info @lvr.com
`
`Web: http://www.ivrcorn
`
`141312111098765432
`
`Products and services named in this book are trademarks or registered trademarks of
`their respective companies. In all instances where Lakeview Research is aware of a
`trademark claim, the product name appears in initial capital letters, in ali capital letters,
`or in accordance with the vendor’s capitalization preference. Readers should contact the
`appropriate companies for complete information on trademarks and trademark registra-
`tions. All trademarks and registered trademarks in this book are the property of their
`respective holders.
`
`No part of this book, except the programs and program listings, may be reproduced in
`any form, or stored in a database or retrieval system, or transmitted‘or distributed in any
`form, by any means, electronic, mechanical photocopying, recording, or otherwise,
`without the prior written permission of Lakeview Research or the author, except as per-
`mitted by the Copyright Act of 1976. The programs and program listings, or any portion
`of these, may be stored and executed in a computer system and may be incorporated into
`computer programs developed by the reader.
`’
`
`The information, computer programs, schematic diagrams, documentation, and other
`material in this book and the accompanying diskette are provided “as is,” without war-
`ranty of any kind, expressed or implied, including without limitation any warranty con-
`cerning the accuracy, adequacy, or completeness of the material or the results obtained
`from using the material. Neither the publisher nor the author shall be responsible for
`any claims attributable to errors, omissions, or other inaccuracies in the material in this
`hook and the accompanying disc. In no event shall the publisher or author be liable for
`
`_
`
`FISI Ex 2003-p 3
`LG v FISI
`IPR2018-00461
`
`

`

`Inside USB Transfers
`
`Inside USB Transfers
`
`In order to design and program a USB device, you need to know a certain
`amount about the inner workings of the interface. This is true even though
`the hardware and system software handle many of the details automatically.
`
`This and the next three chapters are a tutorial on how USB transfers data.
`This chapter has the essentials that apply to all transfers. The, following
`chapters cover the four transfer types supported by USB, the enumeration
`process, and the standard requests used in control transfers.
`
`
`
`
`
`
`
`
`
`USB is complicated, and much of what you need to know is intertwined
`with everything else. This makes it hard to know where to start. In general, I
`try to begin with the big picture and work down to the details. Unavoidably,
`some of the things I refer to won’t be explained in detail until later. And
`some things are repeated because they’re important and relevant in more
`than one place.
`i
`
`The information in these chapters is dense. If you don’t have a background
`in USB, you won’t absorb it all in one reading. You should, however, get a
`
`USB Complete
`
`FISI EX 2003-p 4
`LG V FISI
`
`|PR201 8-00461
`
`FISI Ex 2003-p 4
`LG v FISI
`IPR2018-00461
`
`

`

`Chapter 3
`
`feel for how USB works, and will know where to look later when you need
`to check the details.
`
`You don’t need to know every bit of this information in order to get a
`project up and running, but I’ve found that understanding something about
`how the transfers work helps in deciding which transfer types to use, in writ—
`ing the firmware for the controller chip, and in tracking down the inevitable
`bugs that will occur when you try out your circuits and code.
`
`The ultimate authority on the USB interface is the specification published
`by its sponsoring members. The specification document, Universal Serial
`Bus Specification,
`is available on the USB Implementers Forum’s website.
`However, by design, the specification omits information and tips that are
`unique to any operating system or controller chip, and this type of informa—
`tion is essential when you’re designing a product for the real world.
`
`Transfer Basics
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`You can divide USB communications into two types, depending on whether
`they’re used in initial configuration or in applications. In configuration
`communications,
`the host
`learns about
`the device and prepares it for
`exchanging data. Most of these communications take place when the host
`enumerates the device on power up or attachment. Application communica—
`tions occur when applications on the host exchange data with an enumer—
`ated device. These are the communications that carry out
`the device’s
`purpose. For example, for a keyboard, the application communications are
`the sending of keypress data to the host, to tell an application to display a
`character or perform other actions.
`
`Configuration Communications
`
`During enumeration, the device’s firmware responds to a series of standard
`requests from the host. The device must identify each request, return the
`requested information, and takeOther actions specified by the requests.
`
`On PCs, Windows performs the enumeration, so there’s no user program—
`ming involved. However,
`to complete the enumeration, Windows must
`
`USB Complete
`
`FISI Ex 2003-p 5
`LG v FISI
`
`|PR2018—OO461
`
`FISI Ex 2003-p 5
`LG v FISI
`IPR2018-00461
`
`

`

`Inside USB Transfers
`
`have two files available: an INF file that identifies the filename and location
`
`of the device’s driver, and the device driver itself.
`
`Depending on the device and how it will be used, the device driver may be
`one that’s included with Windows or provided by the chip or peripheral
`vendor. The INF file is a text file that you can usually adapt from an exam—
`ple provided by the driver’s provider. Chapter 11 has more details about
`device drivers and INF files.
`
`
`
`
`
`
`Application Cemmunications
`After the host has exchanged enumeration information with the device and
`I a device driver has been assigned and loaded, the application phase can be
`fairly straightforward. At the host, applications can use standard Windows
`API functions to read and write to the device. At the device, transferring
`data typically requires placing data to send in the USB controller’s transmit
`buffer, reading received data from the receive buffer when a hardware inter—
`rupt signals that data has arrived,_and on completing a transfer, ensuring the
`device is ready for the next transfer. Most devices also require some addi-
`tional support for handling errors and other events.
`
`
`
`Each data transfer on the bus uses one of four transfer types: control, inter—
`rupt, bulk, or isochronous. Each has aformat and protocol suited for partic—
`ular uses.
`
`Managing Data on the Blis
`The USB’s two signal lines carry data to and from all of the devices on the
`bus. The wires form a single transmission path that all of the devices must
`share. Unlike RS-232, which has a TX line to carry data in one direction
`and an RX line for the other direction, USB’s pair of wires carries a single
`differential signal, with the directions. taking turns.
`
`The host is in charge of seeing that-all transfers occur as quickly as possible.
`It manages the traffic by dividing time into l—millisecond frames and giving
`each transfer a part of each frame (Figure 3-1).
`
`USB Complete
`
`FISI Ex 2003-p 6
`LG v FISI
`
`|PR2018—OO461
`
`FISI Ex 2003-p 6
`LG v FISI
`IPR2018-00461
`
`

`

`Chapter 3
`
`Each transfer consists of one or more transactions. Control transfers must
`use multiple transactions because they have separate Setup, (optional) Data,
`and Status stages. Other transfers use multiple transactions when they have
`more data than fits in one transaction. Depending on how the host sched—
`ules the transactions and the speed of a device’s response, a transfer’s transac-
`tions may all be in a single frame, or they may use multiple frames.
`Because all of the transfers share one data path, each transaction must
`include the address of the transactions source or destination. Every device
`has a unique address assigned by the host, and all data travels to or from the
`host. Each transaction begins with the host’s sending a block of information
`that includes the address of the receiving device as well as a specific location,
`called an endpoint, within the device. Everything a device sends is in
`response to receiving a request from the host to send either data or status
`information in response to received data.
`
`
` l
`
`
`l~MILLISECOND FRAME
`I-MILLISECOND FRAME
`l-MILLISECDND FRAME
`
`Figure 3-1: The‘ host schedules transactions within 1-millisecond frames. Each
`frame begins with a Start-of-Frame packet, followed by transactions that transfer
`data to or from device endpoints. The host may schedule transactions anywhere
`it Wants within a frame.
`'
`
`PC-to-PC Communications
`
`The USB doesn’t allow peripherals to exchange data directly. All communi—
`cations must go through a host. And there’s no way for two hosts to send
`data to each other without going through a peripheral. There is, however, a
`way to enable two PCs to communicate using their USB ports. Cypress
`SemiConductor’s EZ—Link contains two USB peripheral controllers that
`
`
`
`USB Complete
`
`il
`
`FISI EX 2003-p 7
`LG V FISI
`
`|PR201 8-00461
`
`
`
`ENDPOINT2
`DEVICEI,
`
`
` DEVICE1.ENDPOINT2DEVICE2,ENDPOINT2
`
`
`DEVICE5‘ENDPOINT3
`
`DEVICE5,ENDPOINT3
`DEVICE5,ENDPOINT3
`DEVICE2,ENDPOINT0
`
`DEVICES,ENDPOINT3
`DEVICE5ENDPOINT3
`DEVICEl.ENDPOINT2DEVICE2,ENDPOINT0
`DEVICE2,ENDPOINT0
`STARTOFFRAME
`STARTOFFRAME
`STARTOFFRAME
`
`FISI Ex 2003-p 7
`LG v FISI
`IPR2018-00461
`
`

`

`
`
`
`is, Each
`It transfer
`lnyWhere
`
`Efers must
`'31) Data,
`they have
`St SCheCL
`transac—
`rim must
`li‘ devrce
`‘3 om the
`“ll
`‘31an
`l’aca'tron,
`15513 in
`status
`‘
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Inside USB Transfers
`
`
`
` share a buffer. Each controller connects to a different PC and uses the shared
`
`buffer to exchange data. Similar products are available from other vendors.
`
`
`1
`
`‘
`ll
`ill
`l‘
`
`‘
`
`:l i:
`
`l
`‘1.
`l:
`H
`l
`
`‘l
`
`‘
`
`\
`
`ll»
`‘
`
`l
`
`Elements of a Transfer
`levels deep.
`Understanding USB transfers requires looking inside several
`Each transfer is made up of transactions. Each transaction is made up of
`packets. And each packet contains information. To understand transactions,
`packets, and their contents, you also need to know about endpoints and
`pipes.
`
`‘
`
`‘
`
`‘
`
`r
`
`l
`
`
`
`
`
`
`
`
`
`'
`
`,
`
`USB Complete
`
`FISI EX 2003-p 8
`LG V FISI
`
`|PR201 8-00461
`
`‘
`Device Endpoints
`All transmissions travel to or froma device endpoint. The endpoint is a
`buffer that stores multiple bytes. Typically it’s a block of data memory or a
`register in the controller chip. The data stored at an endpoint may be
`received data, or data waiting to transmit. The host has buffers for received
`data and data ready to transmit, but
`the host doesn’t have endpoints.
`Instead, it serves as the starting point for communicating with the device
`endpoints.
`The specification defines a device endpoint as “a uniquely addresSable por-
`tion ofa USB device that is the source or sink olfrinformation in a communi—
`cation flow between the host and device.” This suggests that an endpoint
`
`
`carries data in one direction only. However, as I’ll explain, a control end—
`
`
`point is a special case that is bidirectional.
`.
`.
`-‘
`»
`,
`
`31‘“ ..
`3
`The unique address required for each endpoint consists of an end 0th
`
`‘
`l“ j
`‘
`number and direction. The number may range from 00h to OFh. The direc-
`1‘ all J
`l:
`WWSpective: IN is toward the host and OUT is away
`
`l
`l
`from the host. An endpoint configured to do control transfers must transfer
`.
`‘
`data in both directions, so a control endpoint actually consists of a pair of
`“j” uni-
`
`‘ W
`IN and OUT endpoints that share an endpoint number.
`0 send
`
`2:25:
`Every device must have Endpoint 0 configured as a control endpoint.
`j.‘
`ill;
`
`
`
`l3 3"
`L that
`There’s rarely, if ever, a need for additional control endpoints.
`l
`
`
`
`
`
`
`
`
`
`
`
`
`
`FISI Ex 2003-p 8
`LG v FISI
`IPR2018-00461
`
`

`

`Chapter 5
`
`The Process
`
`
`
`
`One of the duties of a hub is to detect the attachment and removal of
`devices. Each hub has an interrupt IN pipe for reporting these events to the _
`
`host. On system boot~up, the host polls its root hub to learn if any devices '
`
`are attached, including additional hubs and devices attached to them. After
`
`the host continues to poll periodically to learn of any newly _
`boot-up,
`
`attached or removed devices.
`
`the host sends a series of requests to the
`On learning of a new device,
`device’s hub, causing the hub to establish a communications path between .-
`
`"
`the host and the device. The host then attempts to enumerate the device.
`
`Enumeration is the initial exchange of information that enables the host’s
`device driver to communicate with the device. The process consists of
`
`assigning an address to the device, reading descriptive data from the device,
`
`assigning and loading a device driver, and selecting a configuration from the
`
`options presented in the retrieved data. The device is then configured and
`
`ready to transfer data using any of the endpoints in its configuration.
`The host enumerates by sending control transfers containing standard USB
`requests to Endpoint 0. All USB devices must support control transfers,-
`
`standard USB requests, and Endpoint O. For a successful enumeration, the '
`
`device must respond to each requesr by returning the requested information
`
`and taking other requested actions.
`
`
`
`
`From the user’s perspective, enumeration should be invisible and automatic, ;
`except for in some cases a window that announces the detection of a new I'
`device and whether or not the attempt to configure it succeeded. Sometimes
`on first use, the user will need to provide a disk containing the INF file and '
`device driver.
`
`When enumeration is complete, Windows adds the new device to the
`Device Manager display in the Control Panel. Figure 5-1 shows an example.
`
`
`
`FISI Ex 2003-p 9
`LG v FISI
`IPR2018-00461
`
`

`

`'
`
`
`
`[7% Modern
`3;} Monitors
`
`e3; Network adapters
`3 Ports (com a LPTJ
`{$4 SCSI controilers
`‘7
`‘ % Sound, video and game controllers
`_ System devrces
`$5 Tape drive controllers
`_
`ape drives
`tr
`General purpose USB Hub
`%’ lntel BEEPIABJEE PCEto USB Universal HostControiier
`: 3% Roe—5090
`-- 42% use RootHub
`
`.
`
`:
`
`Figure 5—1: The Device Manager in Windows’ Control Panel lists all detected
`USB devices. (Some devices will be listed by type, such as keyboard or modern,
`rather than under UniversaE Serial Bus controllers.)
`
`In a typical peripheral, the peripherals program code contains the informa-
`tion the host will
`request, and the program code must recognize and
`respond to requests for the information. Some application-specific chips
`(ASICS) manage the enumeration entirely in hardware and require no firm-
`ware support. On the host side, under Windows there’s no need to write
`code for enumerating, because Windows handles it automatically. Windows
`will look for a special text file called an INF file that tells Windows what
`driver to. use for the device.
`
`
`
`Enumeration Steps
`
`During the enumeration process, a device moves through four of the six pos-
`sible device states: Powered, Default, Address, and Configured. (The other
`FISI EX 2003-p 10
`[513 V FISI
`
`..
`VUSB Complete
`
`|PR201 8-00461
`
`
`
`FISI Ex 2003-p 10
`LG v FISI
`IPR2018-00461
`
`

`

`Chapter 5
`
`the device has defined
`states are Attached and Suspended.) In each state,
`capabilities and behavior. These are the events that cause and occur during
`enumeration:
`
`
`
`1. The user plugs a device into a USB port. Or the system powers up with
`a device already plugged into a port. The port may be on the root hub at the
`host or on a hub that connects downstream of the host. The hub normally
`provides power to the port, and the device is in the Powered state.
`
`2. The hub detects the device. The hub monitors the voltages on the signal
`lines of each of its ports.
`
`The hub has a 15wkilohm pull—down resistor on each of the port’s two signal
`lines (D+ and D—), while a device has a 1. 5«kilohm pull—up resistor on either
`D+ (for a full-speed device) or D- (for a low»speed device). When a device
`plugs into a port, the device’s pull—up brings that line high, enabling the hub
`to detect that a device is attached. Chapter 16 has more on how hubs detect
`devices.
`
`the hub continues to provide power but doesn’t
`On detecting a device,
`transmit USB traiiic to the device, because the device isn’t yet ready to
`receive it.
`
`3.” The host learns of the new device. Each hub uses its interrupt pipe to
`report events at the hub. The report indicates only whether the hub or a
`port (and if so, which port) has experienced an event. When the host learns
`of an event, it sends the hub a Get_Port_Status request to find out more.
`Get__Porthtatus and the other
`requests described here are standard
`hub~class control
`requests that all hubs understand. The information
`returned tells the host when a device is newly attached.
`
`4. The hub resets the device. When a host learns of a new device, the host
`controlier sends the hub a Set_Port_Feature request that requests the hub to
`reset the port. The hub places the device’s USB data lines in the Reset condi»
`
`-
`
`
`
`FISI Ex 2003-p 11
`LG v FISI
`IPR2018-00461
`
`

`

`states and the device is ready to respond to control transfers over the default
`pipe at Endpoint O. The device can now communicate with the host, using
`the default address of Oh. At this point, the device can draw no more than
`100 milliamperes from the bus.
`
`6. The hub detects the device’s speed. Either just before or just after the
`Reset, the hub detects the device’s speed by examining the voltages on the
`two signal lines. The hub detects the speed of a device by determining which
`line has the higher voltage when idle. The hub sends the information to the
`host in response to the next GetWPorthtatus request.
`7. The host sends a GetWDescriptor request to learn the maximum
`packet size of the default pipe. The host sends the request
`to device
`address 0, Endpoint 0. Because the host enumerates only one device at a
`
`IW a
`I
`I
`time, only one dev1ce w1ll respond to communicatlons addressed to dev1ce
`address 0.
`
`The maximum packet size is in the eighth byte of the descriptor, so the host
`needs to read only the first 8 bytes. A Windows host requests 64 bytes, but
`after receiving just one packet (whether or not it has 64 bytes), it begins the
`_ status stage. On completion of the status stage, the host requests the hub to
`reset the device (repeating steps 4 and 5). The specification doesn’t require a
`reset here, because devices should be able to handle the host’s abandoning a
`control transfer at any time by responding to the next Setup stage. Resetting
`is a precaution that ensures that the device will be in a known state when the
`reset ends.
`
`3. The host assigns an address. The host controller assigns a unique
`address to the device by sending a Set_Address request. The device reads the
`request, returns an acknowledge, and stores the new address. The device is
`now in the Address state. All communications from this point on use the
`new address. The address is valid only until the device is detached or the sys#
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`'
`SB Complete
`
`|PR2018—OO461
`
`
`12
`FISI EX 2003-
`p
`it; v FISI
`
`FISI Ex 2003-p 12
`LG v FISI
`IPR2018-00461
`
`

`

`Chapter 5
`
`tern p0wers down. On the next enumeration, the device may be assigned a _
`different address.
`
`9. The host
`
`learns about
`
`the device’s abilities. The host sends a
`
`Get_Descriptor request to the new address to read the device descriptor, this I
`time reading the whole thing. The descriptor is a data structure containing :-
`the maximum packet size for Endpoint 0, the number of configurations the _'
`device supports, and other basic information about the device. The host uses
`this information in the communications that follow.
`
`The host then continues to learn about the device by requesting the one or
`more configuration descriptors specifiedin the device descriptor A Win— -
`dows hostMbeginTs—Wreq’JES'tihgJust the configurationdescriptors nine bytes. '
`Includedin these bytes18 the total length of the configuration descriptor -
`and all of its subordinate descriptors.
`
`Windows then requests the configuration descriptor again, this time using '
`the retrieved total length up to FFh bytes. This causes the device to send the '
`
`configuration descriptor foilowed by the interface descrip_tor(s) for each con» '
`
`m, followed by endpoint descri
` nldovvs obtains the full set of __
`descriptors total more thanFFhbytes,
`descriptors on a third request. Each descriptor begins with its length and
`
`”datathat foiiows. The Descriptors section in this chapter has more on what -
`each descriptor contains.
`
`10. The host assigns and loads a dievice driver (except for composite '-
`devices). After the host learns as much as it can about the device from its
`
`descriptors, it looks for the best match in a device driver to manage commu—
`nications with the device. In selecting a driver, Windows tries to match the
`Vendor and Product
`IDs, Release Number, and/or class
`information
`
`retrieved from the device with the information stored in the system’s INF
`files. After the driver is loaded, it often requests the device to resend descrip—
`
`FISI Ex 2003-p 13
`LG v FISI
`IPR2018-00461
`
`

`

`tiple configurations, the driver can decide which to use based on whatever
`information it has about how the device wiii be used, or it may ask the user
`what to do, or it may just select the first configuration. The device reads the
`request and sets its configuration to match. The device is now in the Config—
`ured state and the device’s interface(s) are enabled.
`
`Drivers for the interfaces in compound devices may be assigned now. As
`with other devices, if Vendor and Product IDs are available, the host uses
`
`these to select the driver for an interface. Otherwise, the host uses whatever
`
`class, subciass, and protocoi values are available.
`
`The device is now ready for use.
`
`The other two device states, Attached and Suspended, may exist at any time.
`
`Attached state. If the hub isn’t providing power (VBUS) to the port, the
`device is in the Attached state. This may occur if the hub detects an
`over-current condition, or if the host requests the hub to remove power
`from the port. With no power on VBUS, the host and device can’t communi—
`cate, so from their perspective, the situation is the same as when the device
`isrft attached at all.
`
`Suspended State. The Suspended, or Suspend, state means that the device
`has seen no activity on the bus for at least 3 milliseconds. In the suspended
`state, the device must consume minimal bus power. Both configured and
`unconfigured devices must support the Suspended state. Chapter 17 has
`
`more on this. -.-En_umerating a Hub
`
`USE Compiete
`
`
`
`Hubs are also USB devices, and the host enumerates a newly attached hub
`in exactiy the same way it enumerates a device. If the hub has devices
`
`FISI Ex 2903-p 14
`L3 v FISI
`
`|PR201 8-00461
`
`FISI Ex 2003-p 14
`LG v FISI
`IPR2018-00461
`
`

`

`attached, the host also enumerates
`host of their presence.
`
`Device Removal
`
`
`
`
`
`Device Manager’s display and th
`another newly attached device.
`
`About Descriptors
`
`g enumeration the host uses control transfers to
`request descriptors From the device.
`As enumeration progresses,
`the
`y small elements of the device: first
`' n, each configurations interface(s),
`
`FISI Ex 2003-p 15
`LG v FISI
`IPR2018-00461
`
`