CIRCUIT CELLARFEATUREARTICLEStuart Allman

Implementing a SimpleUSB InterfaceFor an Embedded Processor

When connecting modules inyour embedded system, deci-sions need to be made. Theuniversal serial bus (USB)may help you make up yourmind and ease the aches ofdevelopment. With the newsthat Intel is phasing out thegood old RS-232 and replac-ing it with the USB, Stuartshows us that all is not lost,because the USB shouldwork just as well. He suppliesus with all the info and leavesno room for excuses, so getready to make a game planfor your next design.

www.circuitcellar.com/online

eciding how toconnect all of the

modules of your em-bedded system together

can be similar to playing a game of"would you rather" with your cowork-ers. Do you design a new interface oruse an industry standard and accept alearning curve? How do you know thatan industry standard interface willmeet all of your needs before you de-sign it in? What becomes an evenworse predicament is, how do you testthe interface ifyou have onlyyour system toconnect it to?The universalserial bus (USB)just may be theelixir that takesaway some ofyour develop-mentpains.

Yes, it's sadbut true, Intelplans to phaseout your old

trusty RS-232 serial port on the backof your PC in favor of the USB. I, alongwith many of you, used the old trustyRS-232 serial interface for years. It isincredibly simple, and you have com-plete control over everything that goeson the bus. So, the question becomes,what do you use now that will besimple, allow complete control, and beimmediately understandable?

The answer I have come to in recentyears has been the USB. In this article,I'll show how getting up and runningon the USB can be painless and almosta direct drop in replacement for RS-232 solutions. I'll show you three ex-ample processors that I have developedfirmware for and how they can transferdata on the USB.

TYPICAL USB SOLUTIONSUnlike RS-232, the USB is a master-

slave configured bus that must have acentral host and can have up to 127peripherals attached. In other words,only the USB host initiates data trans-fers, and your device must be willingto share the bandwidth. Currentlythere are only two speeds available forV.l.l of the USB, 12 Mbps for fullspeed and 1.5 Mbps for low speed, witha third (480 Mbps) on the way for USB2.0. Even with the fastestmicrocontrollers on the market today,it's impractical to try to bit-bang USB

Figure 1-Here you can see the connection from the embedded processor tothe HAPI.

CIRCUIT CELLAR e ONLlNE December 2000

processor can set uppackets at the transac-tion level and have theSIE format the packetand send the data at the physical level.An SIE solution has the drawback ofmaking the embedded processor firm-ware have to understand and commu-nicate at the transaction level. Datacannot be simply transferred withoutunderstanding the USB protocol.

The second common solution is tointegrate the SIE into a micro-control-ler. Literally dozens of silicon vendorsprovide anywhere from bare-bones tohigh-power micro controller solutionsfor the USB. Typically these are usedin peripherals in which a micro-con-troller can act as the main systemcontroller. This high level of integra-tion allows for cost-competitive solu-tions in a tiny package, however, themicro controller firrnware still has tounderstand and interpret data at theUSB transaction level.

And, for this article, I will be exam-ining a third solution for systems thatalready have a central microprocessorand want to easily integrate USB con-nectivity, similar to RS-232 connectiv-ity. This solution involves letting aseparate USB microcontroller act as aperipheral handlingthe transaction level,freeing the centralmicroprocessor tosimply send andreceive bytes at theapplication level.The only drawbackof this scheme seemsto be a moderate hitto throughput be-cause themicro controller musthandle the transac-tion level. Still, much Figures 3

traffic and remainwithin the USB timingspecifications.

USB peripheralconnectivity solutionsgenerally exist in threeforms. First is thestandalone serial inter-face engine (SIE).Manyvendors sell these sothat an embedded

2 December 2000

'l'I'f''''''" :1..:., --{>_.. '.- -r -- ,... .,.... ".:----, .

,)I'".: •.'.'

: .: .

SIE, there is going tohave to be firmwaresomewhere in your pe-ripheral to communicateat the USB transactionlevel. That's where theperipheral firmwarecomes in.

The USB is generallysupported on three plat-forms, Windows98/2kand MacOS, with somelimited support onLinux. For the purposesof this article, I will be

using a Windows WDM driver. Thedriver recognizes and becomes at-tached to your device after you plugthe device into the host. The periph-eral provides the correct Product ID(PlO) and Vendor 10 (VID)during thestartup process.

The host application opens thedriver and sends and receives datafrom the peripheral. USB devices havea logical communications channelknown as endpoint 0, which allowsyou to send vendor-specific commandsto the peripheral. Later, I will present aWin32 dialog application that allowsyou to send data on endpoint 2 (BULKOUT), receive data on endpoint 1(BULKIN), and send vendor-specificrequests on endpoint O.

Figure 2

larger throughput than RS-232 caneasily be achieved.

REQUIRED COMPONENTSThere are five main elements that

are required to communicate on theUSE-USB SIE, peripheral processor,peripheral firrnware, host driver, andhost application.

The USB SIE can exist as astandalone memory-mapped periph-eral or be integrated in amicrocontroller. The SIE takes data atthe transaction level and transfers thebits out at the physical level, and viceversa.

The second element is the periph-eral processor. Most USB solutionstoday demand a processor solution ofsome kind to handle USB transactions,although some USB peripherals aredesigned to communicate without anyprocessor control. Generally the pro-cessor handles the system controlfeatures, such as optics and buttons ina USB mouse, as well as the USB trans-actions.

And, unless you have an intelligent

AN EASIER SOLUTIONThe USB micro-controller I'll dis-

cuss is the Cypress SemiconductorCY7C64013. This microcontroller hasa bidirectional parallel interface calledHAPI (hardware assisted parallel inter-face) that easily connects to most stan-dard embedded processor buses (see

Figure 1).With a bit of

firmware magicin theCY7C64013, allthe embeddedprocessor has todo to communi-cate on the USB isread a byte whenit gets inter-rupted by theHAPIDREADY#signal and write abyte at its leisure

1- I, I..... ,.

."

" .rl •••••••-:

J _,... - .•....•

r.· .... ..,•... .. ' -,

1"0 ••I~·I ••

..' ..... :.•...I. "':.1' ...• :''. :"

:., .. :'" I:- "......::.. .. ,....!... .. '.-.!.... or •. (~I'.«.r ::~~~..+'.--~----;~I.':,

..t!- .,.r·I~:I·.:~:I>; :

: • ." -. J.

_••.J ••.••••.•.• : ':. _, 'I (

r .:',' I •••. '.: .. '. .." .. ,...!.~P.> >-)- "<Ih

CIRCUIT CELLAR 8 ONLlNE

1- -01.

.............

iT" r:

www.circuitcellar.com/online

when the LEMPTY# isasserted. Using this inter-face you should be ableto achieve data rates ofaround 60 to 80 kbps-more than enough band-width to run circlesaround RS-232. This isobviously less than thetheoretical maximumthroughput of about 1MBps required by theUSB V.l.l specification,but there are a lot ofembedded systems outthere that don't require ultra-highspeed.

The CY7C64013 micro controllerhandles the USB start-up process. Thisis known as USB enumeration. Duringthis time, the USB host queries theperipheral for data about what thedevice is and which logical communi-cation channels the peripheral willcommunicate on. Then the main USBdriver on the host connects the periph-eral to the device-specific driver usingthe VID and Pill acquired from theperipheral.

An obstacle when using USB is mak-ing a device enumerate on the bus andbe "Chapter 9" (commonly used torefer to Chapter 9 of the USB specifica-tion) compliant. The enumerationprocess consists mainly of two types oftransactions-control read and no-datacontrol-and a list of associated devicedescriptions transferred during thistime, aptly called descriptors.

bus.When you change these

parameters, you need torecompile the embedinf.cmicro controller firmwareusing the ByteCraft M8Series C compiler andprogram a micro controller.Unfortunately, themicrocontrollers are OTP,so plan on having a few onhand if you intend to testdifferent products usingthis interface.

r:~.

"".'I:.~:I"IIA I .• i~.1 .:. ~ .•• " ~ • :,',••• I • 11 • -. ir {' _ ', ..~."..,............ <1---.. ,............;,: ,I (' Oh •• '

, . _. I

Figure 4

FOLLOWING THE RULESThere are a number of rules that the

device must follow that are not imme-diately obvious for a peripheral to beUSB compliant, and often these cause agreat deal of forehead bruising for thefirst-time developer. If these tasks aretaken care of by the CY7C64013micro controller, then the embeddedprocessor doesn't even need to knowthat it's connected to the USB.

Luckily for you (and your sanity),that piece of firmware has already beenwritten and comes with the designpackage for this article. Enumeratingthe bus is nearly a standard procedure,so the CY7C64013 firmware can be-come a black box in your design. All

www.circuitcellar.com/online

, •••• , I"" 11 • P_ •••. 0 •••

-1' .• - •.•. I•• _ ••....• 1.... • •••• ' ••• s , "' •• .J

you will need to specify are a few pa-rameters for the enumeration to betechnically correct for your particulardevice. I have specified default param-eters to get you up and running, butobviously these will change duringyour development process. The param-eters are defined as constants in theembedinf.h file and include VID, Pill,power source, and current draw.

Vendor ill is a two-byte value as-signed by the USBIFwww.usb.org)when you join. I have set this toOx04B4, the Cypress SemiconductorVID.

Product ill is a two-byte value as-signed by you to identify your USBproducts. This default value of thisparameter is arbitrarily set to Ox6401.Assign this parameter however youwish, as long as it doesn't conflict withanother product with the same VID.

The power source can be bus- orself-powered, and the host knows ifyou're going to draw current from it.By default this value is set to self-pow-ered. One of the advantages of USBover RS-232 is that the USB host canprovide up to 100 mA for a standardbus-powered device and up to 500 mAfor a high-power device. See the USBspecification Reference at the end ofthe article for more details on powerlimits.

If it is bus-powered, then the hostneeds to know how much current youplan to draw. By default, the currentdraw is zero because the device is self-powered.

Besides the physical connections tothe USB, this is all you need to know. Ifyou can write to memory withouthurting yourself, you can get on the

CIRCUIT CELLAR ~ ONLlNE

FIRMWARETypically, the CY7C64013 HAPI

will be connected to a microprocessordata bus. For demonstration purposes,I have written firmware for anMC68331, AT91M63200(ARM7DTMI) processor, and ADSP-21065L DSP to interface to the USB.Connection diagrams for each of theseprocessors are shown in Figures 2,3,and 4, respectively. The MC68331code was developed on a proprietarysystem, the ARM7TDMI code wasdeveloped on an AT91EB63 evaluationkit, and the SHARC code was devel-oped using a SHARC 21065L EZ-LAB.Because the processor interface is ge-neric, I won't spend time discussing thespecifics of these processors.

The USB driver that comes with thedesign package for this article is a ge-neric device driver that currentlycomes with the Cypress EZ-USB devel-opment kit. Before you plug in thedevice, you need to install theezusb.sys driver using the ezusbw2k.inffile. In the ezusbw2k.inffile, you willfind a list of device names and theirassociated VID and Pill. Any time youmodify the VID and Pill of your pe-ripheral, you need to reinstall thisdevice driver so the main USB drivercan associate your device driver withthe peripheral.

Automatic driver creation tools forthe Microsoft Windows platform arealso available from companies such as[ungo, BSQUARE, and NuMega. Someof these tools are wizard-driven, andothers allow you to just plug in yourdevice and the software configures adriver for you. This software can helpyou avoid the nightmare of developing

December 2000 3

a WDM driver and willprobably equal the cost ofhiring a consultant tocreate a custom driver foryou. The driver creationtools will also require thatyou have a Windows com-piler such as Visual c++along with the MicrosoftDDK.

There is also the possi-bility that, with a little modificationof the USB descriptors in embedinf.h,you can use the Microsoft Point of Sale(POSUSB)driver. This driver effec-tively allows you to interface yourUSB device like a RS-232 port on yourUSB host. For more details, check outthe Resources at the end of the article.

The drawback of using this driver isthat you lose the ability to form yourown vendor-specific requests. You alsomay need to investigate throughputwith this driver because it was de-signed to emulate serial port connec-tivity to point-of-sale devices.

In order to test your new, fabulousUSB interface, I have written a testapplication that connects to theezusb.sys device driver. The host appli-cation is shown in Photo I, and a num-ber of vendor-specific requests areshown in Tables 1 and 2 <LINK>.In-cluded are GETjO, SETjO,SET_TIMEOUT, andSENDjMMEDIATE.

Figure 5-Here you can see the big picture. Note that you can abstract the specificnature of USB and just leave the data-passing interface. This is what your embed-ded processor should see.

VENDOR·SPECIFIC REQUESTSGETjO gets the values on

portl[2:0]. These bits are hi-z inputsand should be pulled high or low if thedevice is bus-powered. If the inputs areleft floating while the device is sus-pended, then the inputs may consume

--.;::...w:-;i -~••....."'fT."""rl"lll.. r..._

System withdata to

communicateto host

too much current to meet the 500-pAUSB suspend current specification.

SETjO is written to port3[1:0].These pins have an internal pull-upresistor and CMOS pull down, so youcan use these pins as a host-controlledreset, button pull-up resistor, or anyother output function.

The IN endpoint communicationchannel has a buffer size of 32 bytes.SET_TIMEOUT is used to set a trans-mission timeout value on this buffer. Ifthe timeout value is set to 0 ms (bydefault, but you can change the defaultin embedinf.h), then themicro controller will wait for the de-vice to fill up the endpoint buffer be-fore sending data to the USB host. Ifthis value is between 1 and 255 ms andthe embedded processor has not writ-ten enough bytes to fill up the buffer inthat time interval, the micro controllerwill time out and send all the bytes inthe IN endpoint data buffer. This ismeant to handle the situation whenthe embedded processor may onlyhave 5 bytes to send. If the timeoutperiod is nonzero, then the data willmake it to the host after the timeoutperiod, otherwise the data will remainin the IN endpoint buffer until a full 32bytes are written into the HAPI by theembedded processor.

And finally, SENDjMMEDIATEcauses the microcontrollerto send whatever data it hasin the endpoint 1 buffer tothe USBhost immediately.

One thing you have tokeep in mind when thinkingabout USB transfers is thateverything is defined to behost-centric. Each device isassigned an address duringthe enumeration process.After enumeration, the hostcommunicates with theperipheral using logical

~~~r-----""'----------~i~1

Photo 1

4 December 2000 CIRCUIT CELLAR ~ ONLlNE

communication channelsthat exist at that address.These logical communica-tion channels are calledendpoints. Each endpointis assigned a size, direc-tion, and type of transfermechanism allowed. Aperipheral's OUT end-point accepts data fromthe USB host. A

peripheral's IN endpoint sends data tothe USBhost.

The host application allows you tosend up to 32 bytes at a time to theembedded processor (OUT endpoint)buffer in the micro controller. Thesebytes are then transferred from theOUT endpoint buffer to the centralmicroprocessor via the HAPI. Datatransfers from the host to central mi-croprocessor cannot occur again untilthe central microprocessor reads all ofthe bytes from the previous transfer.

The host application continuouslymonitors the IN endpoint while thedevice is attached to the host. When-ever a packet is sent from the periph-eral to the host, the data is displayed inthe window at the bottom of the appli-cation.

HOST TRANSFER MECHANISMSNow that I've caught your attention

and you are thoroughly salivating withcreative thoughts, it's time to thinkabout how you are going to communi-cate with the host computer. Unlessyour platform already has a deviceclass supported for your device, youwill need to write a custom host appli-cation for your new, fabulous gizmo.

The EZ-USB driver used in thisexample uses the older file namemechanism for opening the driver.Newer drivers that conform to theWDM standard will use a globallyunique ID (GUID) to access the driver .In order to open the USB device driverfor reading and writing, the host appli-cation makes a call to bOpenDriver()with the file name specifying the de-vice it wants to open. The system thenreturns a handle to the device(bOpenDriver( etJhDevice, "Ezusb-0");.).

The identifier "Eziisb-O" is the firstUSB peripheral plugged in that uses the

www.circuitcellar.com/online

Listing 2

bulkControl.pipeNum = 0;

bResul t = Devi celoControl ( hDevi ce,IOCTL_EZUSB_BULK_READ,&bul kControl ,

sizeof(BULK_TRANSFER_CONTROL) ,inbuffer,32,&numBytesReturned,NULL) ;

Listing 3

vendor_request. request = 3·vendor_request.value = 0;vendor_request.index = O·vendor_request.direction = 1;vendor_request. recepi ent = 0;vendor_request. requestType = 2;vendor_request. requestTypeReservedBi ts = 0;

bResul t = Devi celoControl (hDevi ce,IOCTL_EZUSB_VENDOR_OR_CLASS_REQUEST,

&vendor_request,sizeof(VENDOR_OR_CLASS_REQUEST_CONTROL) ,

buffer,1 ,&numBytesReturned,NULL);

Listing 4-need caption.

vendor_request. request = 2;vendor_request. val ue = portval;vendor_request. index = 0;vendor_request. di recti on = 0;

vendor_request. recepi ent = 0;vendor_request. requestType = 2;vendor_request. requestTypeReservedBi ts = O·

bResul t = Devi celoControl ( hDevi ce,IOCTL_EZUSB_VENDOR_OR_CLASS_REQUEST,

&vendor_request,sizeof(VENDOR_OR_CLASS_REQUEST_CONTROL) ,

buffer,0,&numBytesReturned,NULL) ;

www.circuitcellar.com/online CIRCUIT CELLAR €> ONLlNE

of vendor-specific requests formattedas control read and no-data controltransfers. They are defined as follows:

• Bulk out-the computer sends infor-mation to the peripheral using a bulkendpoint• Bulk in-the peripheral sends infor-mation to the computer using a bulkendpoint• Control read-the computer re-quests specific data on endpoint 0,and the peripheral returns the re-quested data on endpoint 0• No-data control-the computersends a control parameter to theperipheral on endpoint O.A zerolength acknowledgment packet issent by the peripheral to the com-puter on endpoint O.

The bulk out transfers occur byspecifying endpoint 2, the transfermechanism, and data buffer locationto a DeviceIOControl(J function call.Note that the bulkControl.pipeNurnparameter is zero-based, so you needto write a value of one to this param-eter. The rest of the parameters areconstants sent to the driver to specifya bulk out transfer, output buffer, andthe result of the transaction. When thetransfer has completed or if there wasan error in transmission, theDeviceloControl() function will re-turn with the result in iResult (seeListing 1).

Bulk in transfers are similar, exceptthey specify the constants for a bulk intransaction and a buffer to capturedata. Note that the function call speci-fies to get 32 bytes, which is the end-point size of the CY7C64013. If thedevice returns 32 bytes or less, this

December 2000 5

function will return with thenumber of bytes captured innumBytesReturned (see List-ing2).

Control read transfers are abit different in that you fill a"YfNrKGLClASS]llQ ..m:..rrNIKLstructure and specify a ven-dor-specific request to theDeviceloControl() functioncall. In Listing 3, thevendor_request structure isspecifying the parameters toperform a control read for theGETjO request. The requestshould return one byte in thebuffer parameter.

The last transfer type used in theexample application is a no-data con-trol transaction used during a SETjOcommand. The transfer parameters arebasically the same as a control-read,only the direction is changed to host-to-device. In this case, no data is re-turned from the peripheral. Theperipheral simply returns a zero lengthpacket to acknowledge that it receivedthe request (see Listing 4).

The other transfer types that areavailable with this driver are isochro-nous, interrupt, and control writes.The EZ-USB driver documentationdescribes how to use these, so I willleave these transfer types for you toexplore.

#1

~ '------7"--7---'

#5For instance, if you want towait for the embedded pro-cessor to boot before sendingany data down the USB pipe,you could monitor a pin onthe processor from the host.These pins are in a high-im-pedance state, so you wouldneed to provide a pull-upresistor for switches or useport3[l:0] as pull-up resistors.Feel free to be creative.

#6

cs#

THE GRAND CONCLUSIONThe embedded processor

doesn't have to know thatyou've taken it off the old bus

and put it onto a new one. This freesyour embedded processor to handleyour main system tasks and leave USBfor the background. Plus, you can keepyour same protocol if you are cur-rently using RS-232.

Even moderate data throughputs forUSB can make RS-232 solutions lookold and tired. It's time to accept thefact that USB is here to stay and youmay have to abandon your beloved RS-232 port.

The grand conclusion that I wastrying to persuade you to come to isthat the aspects of the USB can behidden by the simple use of a USBmicro controller. If you treat theCY7C64013 micro controller as a blackbox with data coming in and out ofeither end, then the design of an em-bedded system using USB becomesmuch simpler. I've given you themicrocontroller firmware, USB hostdriver, USB host example and testapplication, and example firmware for

Figure 6

~,--!-----,{, ,

, :----;...----...;.----i:,-« ;VaRd data ~•••••-+---Data(7:] i V

ing of the HAPI read and write se-quences.

The central microprocessor mayoptionally read the CONNECTED#signal (port3[2]) from themicrocontroller to determine if thedata written to the microcontroller'sHAPI will be transferred anywhere, butthis still does not require any knowl-edge of the USB. In effect, the centralmicroprocessor does not need to knowanything about USB to aptly handleUSBi and with an interface similar to a16550 UART, it's almost a drop inreplacement! The protocol that youhave already developed for your prod-uct can remain in place without modi-fication.

One requirement of my originaldesign enabled the USB host to resetthe peripheral. The CY7C64013 al-ready has a power-on reset circuit builtin, so the ability to control the pins atport[1:0] allowed me to pick a pin anduse it as a POR pin. Because of thebuilt-in 14-kilohm pull-up resistor,you can also usethese pins in parallelwith open-drainPOR circuits thatmay be in your sys-tem already. Needboth polarities ofPOR? No problem,use both pins.

The port1[2:0]pins allow you toattach buttons orstatus pins fromyour system andhave the USB hostread these values.

OE#

LEMPTY#

#1 #2 #3 #4 #5

,{,

"-, y--,

, ,, ,, ,,

,'{ I.

,,,,

:< Valid data : >

HOW DOES IT WORK?Now that I have gone into more

than enough detail, it's time to stepback and get the 10,0004:view. If youabstract the functionality of themicrocontroller, then the view willlook something like Figure 5. You havedata and control information comingin and out of the USB microcontroller,which appears as a simple data-ex-changing device. Data coming from theUSB host is passed through theCY7C64013 microcontroller and readby the embedded processor.

Likewise, when the embedded pro-cessor writes a byte to the CY7C64013microcontroller, it is transferred to theUSB host. Timing information for theCS#, STB#, OE#, LEMPTY#, andDREADY# signals can be found in theCY7C640l3 datasheet (see Resources).Figures 6 and 7 show the relative tim-

6 December 2000

CS#

STB#

Data (7:0]

Figure 7

CIRCUIT CELLAR fI ONLlNE www.circuitcellar.com/online

multiple embedded processors. Whatexcuse could you possibly have for notgiving it a try in your next design? Iil

Stuart Allman works for CypressSemiconductor in the USBmicrocontroller development toolsgroup. In his spare time, he is a DSPguru wannabe and is always up for agood audio discussion. He can bereached at sea@cypress.com.

SOURCESEmbedded USB interface designpackage and CY7C64013Cypress Semiconductor Corp.(408) 943-2600Fax: (408) 943-6848www.cypress.comfdesignfprogprodsfusbfusbrefdesign.html

MC68331Motorola Semiconductor Products(602) 952-4103Fax: (602) 952-4067www.mot-sps.com

AT91M63f4399 (ARMmTMI)Atmel Corp.(408) 441-0311Fax: (408) 436-4200www.atmel.com

ADSP-21065L DSP and SHARC21065L EZ-LABAnalog Devices, Inc.(617) 329-4700Fax: (617) 329-1241www.analogdevices.com

www.circuitcellar.com/online

REFERENCESCypress Semiconductor Corp.,"CY7C64013 CY7C64113 Full-Speed USB (12 Mbps) Function,"2000.

USB Revision 2.0 Specification,www.usb.orgfdevelopersfdocs.html.

USB development tools,www.usb.orgfdevelopersftools.html.

Microsoft Windows Point of Sale(POSUSB) driver information,www.eu.microsoft.comfhwdevfusbfposusb.htm.

RESOURCESIungo USB driver developmenttools information, www.jungo.comfwindriver.html.

BSQUARE USB driver developmenttools information,www.bsquare.com.

Cornpuware Corp., NuMega USBdriver development tools informa-tion, www.numega.comfdrivercentralfdefault.asp.

Linux USB project information,www.linux-usb.org.

Apple Computer, Inc., MacintoshUSB hardware and driver informa-tion, http://developer.apple.com/hardware/usb/,

CIRCUIT CELLAR ~ ONLlNE

Circuit Cellar, the Magazine for Computer Applica-tions. Reprinted by permission. For subscriptioninformation, call (860) 875·2199,subscribe@circuitcellar.com orwww.circuitcellar.com/subscribe.htm .

December 2000 7