 |
Computer Solutions Ltd | ||
After supplying all your Embedded Development
Tool needs for 42 years
|
|||
|
Having reached the grand old age of 75 it is time to relax and fulfil other ambitions. Its been an exciting ride with you, our customers, often on the
bleeding edge of technology Stay well I wish you all success in your future projects.
|
R4 | ||
|
But what to do with the web site ? It has taken >12 man years of work to create a repository of knowledge on many aspects of the art and science of embedded microprocessor development and even after closing the shop it still gets over 4,000 visitors per month. So as a service to my customers I have decide to keep it live providing my technical insights on the products and then redirecting viewers to sites where they can purchase the items they used to buy from us. Follow the link "Home" The "Information zone" consists of articles produced as background tutorials on subjects of interest to those designing new products. As different CPUs have became available this has lead to new development techniques and in particular to new ways of communicating between nodes.
|
|||
| Home | Information Zone |
Embedded USB - a brief tutorial
If you need your embedded application to talk to a PC then increasingly the way to go is USB. Partly this is because of the performance it can supply but also for the very practical reason that many PCs and most portables no longer have parallel or serial ports. But unlike the good old parallel or serial cables these interfaces are far from simple to implement, debug or program. Here is a quick summary of some terms you might encounter.
The Standards Signals and Protocols Devices, Hosts and On-The-Go Interface chips
The Standards
USB 1.1
The original USB standard provides a fast Master/Slave interface using a tiered star topology supporting up to 127 devices with up to 6 tiers (hubs). A PC is normally the master or Host and each of the peripherals linked to it act as slaves or Devices. One of the aims of the design was to minimise the complexity of the Devices by doing as much in the Host as possible. Data transfer rates are defined in the specification as - Low Speed 1.5 Mbits/sec and Full Speed 12 Mbits/sec and the maximum length of each cable section is 5 metres. The USB specification allows each device to take up to 500mA of power (limited to 100mA during startup).
USB 2.0
There are some minor variations from USB 1.1 within the USB 2.0 specification and since USB 2.0s inception most interfaces have been designed to conform to the USB 2.0 standard. The 2.0 specification is a superset of 1.1 and the major functional difference which is the addition of a High Speed 480 Mbits/sec data transfer mode. Be warned, however, that the Spec does allow a product (eg an interface chip) to say that it is "USB 2.0 compatible" without necessarily implying that it actually implements the High Speed mode.
USB 3.0
Released in 2008 with motherboards and products appearing in 2010. It has been designed to be backward compatible with 2.0 with a socket that will fit most combinations of legacy plugs and as well as supplying more power (900mA) it also adds a Super Speed >4.8 Gbits/sec data transfer mode so should be able to deliver 400MBytes/sec after protocol overheads. It is becoming popular for use with external hard disks and other high speed applications.
Wireless USB
A short range high speed radio communications protocol ( 480 Mbit/s up to 3 m and 110 Mbit/s up to 10 ) which seems to aim to compete with Bluetooth. Windows Drivers were not released with W7 and need to be obtained from the device suppliers
Signals, Throughput & Protocol
USB 1 & 2 cables use 4 lines - Power, Ground and a twisted pair differential +/- data lines using NRZI encoding. The USB connectors are designed so that power and ground are applied before the signal lines are connected. When the Host powers up it polls each of the Slave devices in turn (using the reserved address 0), it assigns each one a unique address and finds out from each device what its Speed is and the and type of data transfer it wishes to perform. This process is called enumeration and it also takes place whenever a device is plugged into an active network. The connectors design (contact to power then signal) along with the process of enumeration and a lot of host software allows devices to be described as "Plug-and-Play".
A typical transaction will consist of a number of packets - a token indicating the type of data that the Host is sending or requiring, the data and in some cases an acknowledgement. Each packet is preceded by a sync field and followed by an end of packet marker.
These transactions are used to provide four basic data transfer mechanisms
Control - used by the Host to send commands or query parameters. Packet lengths are 8 bytes for Low speed, 8-64 for Full and 64 for High Speed devices.
Interrupt - badly named it is in fact a polled message from the Host which has to request specific data of the Device. Used by Devices which will be sending small amounts of data (e.g. mice or keyboards).
Bulk - Used by Devices that send or receive data in quantity such as a printer. Variable length blocks of data are sent or requested by the Host (max length is 64-byte- full speed, 512 -high speed), are verified with a CRC and their receipt is acknowledged. This mechanism is not used by time critical peripherals as it takes whatever bandwidth is left by the other mechanisms.
Isochronous - Used for devices that stream data in real time without any error recovery such as audio channels. For them losing some data occasionally is better than the glitch resulting from a re-transmit. Packet sizes can be up to 1024 bytes.
As devices are enumerated, the host keeps track of the total bandwidth that the isochronous and interrupt devices request. They can consume up to 90 percent of the bandwidth that is available. After 90 percent is used up, the host denies access to any other isochronous or interrupt devices. Control packets and Bulk Transfers are guaranteed at least 10 percent with Control taking priority.
The USB Host does this by dividing the available bandwidth into frames containing 1,500 bytes, with a new frame starting every millisecond. During a frame, isochronous and interrupt transfers get a slot so they are guaranteed the bandwidth they need. Control and then Bulk transfers use whatever time is left.
Throughput for 2.0
| Maximum Theoretical transfer rates | |||
| Transfer Type | Low-speed | Full-Speed (all Kbytes/sec) | High-speed |
| Control | 24 | 832 | 15,872 |
| Interrupt | 0.8 | 64 | 24,576 |
| Bulk | - | 1,216 | 53,248 |
| Isochronous | - | 1,023 | 24,576 |
But note that in practice the actual throughput achieved also depends on the host's performance which
may only allow 70% of the highest values to be achieved.
Protocol
When the USB Device is enumerated as well as getting an address from the Host it presents the Host with a good deal of information about itself in the form of a series of descriptors.
The Device Descriptor tells the Host what the Vendor and Product ID
are
(which the Host may use to load a driver)
The Configuration Descriptors
(there may be a number of these - the Host chooses one) offers a power
consumption value
and a number of Interface Descriptors (a device may be a
printer/scanner/fax with separate descriptors)
each of these will define a number of Endpoints which are the sources
and destinations for data transfers
The Endpoint Descriptors provide the following detail ---
transfer type (Bulk, Interrupt, Isochronous), direction, packet sizes,
bandwidth requirement and repeat interval.
There can be 4 Endpoints for Low speed devices 16 in and 16 out for Full and High speed devices- these include the mandatory Endpoint 0. But what is an Endpoint ? Wikipedia defines it as "the the identifier for the entity on one end of a transport layer connection" in practice it may be a register in the device or a buffer into which data ("addressed" to the Endpoint) is going to be transferred. Those familiar with TCP/IP nomenclature will see that it resembles what is referred to in that software as a Socket.
Logically each USB peripheral sets up a one to one link between endpoints on the device and applications software. The driver software and the interfaces at each end translate between a software call on the host to a peripheral endpoint and the required message details. The host's application software simply moves data to or from the endpoint on the peripheral without needing to know the connection details.
The Host software does this via pathways known as Pipes between it and the Endpoints There are two types of pipe defined within the specification...
Message pipes which are bidirectional, for which the USB standard defines the format and which can only be used by Control Transfers
Stream pipes which can be In or Out and which can be used by Interrupt, Bulk and Isochronous Transfers. The USB standard does not determine the layout of the data in these streams (of course the messages passing the data across the bus are structured and contain endpoint addresses but these fields are stripped out before delivery to the pipe).
All the above are specified by the USB protocol so that devices will operate in a uniform manner both at the Bus level but also at the next level up the Transport Level.
Hopefully your USB interface chip will handle all the detailed operations that make up the actions we have discussed above however you will need to know these terms in order to select the appropriate Transfer mechanism, set your Device up correctly and to use the Pipe to transfer your data - not to mention having an idea of what is going on when you get an error message.
Devices, Hosts and On-The-Go
USB Device
Most early on-chip USB interfaces and USB interface chips provided support allowing your embedded system to connect to the USB as a Device.
USB Host
The Master for the transaction - may be a PC but your application will have to be Master if you want to plug a USB memory stick into it and read the files off the stick. Increasingly interfaces capable of being Host are being incorporated into Microcontroller chips.
On-The-Go OTG
The initial USB standard assumed the presence of a Host - the PC. However it has become important to connect units which may, under some circumstances be a Device but may be required under others to be a Host. For example a Printer is normally happy to be a Device when connected to a PC but may need to be connected to a Camera in the absence of a PC when the Printer will need to be the Host. The OTG protocol provides an arbitration mechanism that allows units to negotiate who is going to be Host. OTG introduces an additional data pin ID that determines the initial status for the Host/Device negotiation. OTG products may also be known as Dual Role Devices
Interface chips
USB Device
Unless explicitly stated on the spec sheet its best to assume that the interface is only suitable for a Device. When selecting an interface chip its important to consider what software is available from the chip manufacturers and from third parties. Many manufacturers are now providing software that allows the chip to interface as a standard serial or parallel device which, depending on your application, may be enough. If you are planning to transfer large amounts of data or time critical data you might be wise to look at USB interfaces that contain local Endpoint buffers or allow Endpoints to be attached to DMA channels.
External USB interface chips that are in popular use as embedded device controllers are NXP (Philips) ISP1161, 1181/3, 1362, 158x, 1761 and from Dallas the MAX3421.
Many of the latest generations of 32 bit Microcontrollers are now appearing with USB support, notably the Coldfire 525x, 527x, 532x/7x, 548x/7x, TI C5509A and using the ARM- the NXP (Philips) LPC2148, 2368, 2468 and 3180, Atmel AT91SAM7S, SAM9 and 920T, STMicro STR7 and STR9, Sharp LH7A4xx, NXP/Freescale MX and XScale.
USB Host
The requirements on a USB host interface are much more onerous than for a Device as the Host must manage Enumeration, Frame generation, Bandwidth allocation and error recovery. When the original USB specification was created it was almost assumed that a PC would be the host and so a number of USB Host interface standards and resulting chips were created which used PCI as their chip interface. These include UHCI (Universal Host Controller Interface), OHCI (Open Host Controller Interface) and EHCI (Enhanced Host Controller Interface) which does High Speed but needs to be teamed with another controller if Full and Low speed devices are to be supported. Very few, even among high end, embedded micros support the PCI standard and it is only recently that embedded Host interfaces have become available.
External chips that can be used for Host interfaces are NXP (Philips) ISP116x and with OTG capabilities ISP1362, 176x and from Dallas the MAX3421.
Embedded Micros with Host USB interfaces were initially rare but are becoming more common eg ColdFire 5222x, 525x, 532x/7x and in the ARMs AT91RM92xx, SAM9 NXP LPC3180, Sharp LH7A404 and Cirrus EP93xx.
Supporting software on Target and PC
I have separated this out under headings that outline a number of commonly encountered scenarios.
Simple but application specific Device
Here the Target Device is using the USB interface to get its control or
setup commands from a PC and the data going up and down needs to be highly
application specific.
It may be possible (depending on the application, the interface and the
level of manufacturer’s support) to set up Endpoints and program simple data
transfers via pipes at the Device (Target) end. If the manufacturers support
is poor then you can purchase the CMX USB Device software
Stack written in C for some 32 bit chips (ColdFire, ARM, PPC) that can be
used to quickly develop the Target
end of the dialogue. Software at the PC end needs to be written using the
Microsoft SDK or a USB SDK such as the one available from Jungo
Standard Devices via USB Classes
In order to simplify the connection of USB Devices, the USB community have defined a number of standard protocols (called Classes) that host software can support in a uniform manner. Microsoft have supported these classes since Windows XP. By using these Classes (available as options within the CMX USB Device Stack) your target device will be able to link to the PC end without needing to provide any special drivers in the PC but using the standard Windows 7, XP and Vista software:
Treat the device as Class name Mouse, keyboard Human Interface Device (HID) File based Mass Storage Serial links Communication Printer Audio Still Image Media Transfer Bluetooth HCI USB Wireless Adapter Video Hub Wireless Controller Smart Card Test & Measurement
So if you wish your Target to appear to the PC as a file system (just like Thumb drives do) then an CMX Device Stack with Mass Storage support will handle the USB communications and in addition will provide you with a FAT32 file Library package.
The Target is a USB Host
In this case there is no PC on the system and your Target may be a Host
data acquisition system that has outstations using USB to link to it and/or
may wish to make use of a Thumb Drive as a storage medium that can be easily
transported for later analysis by plugging it into a PC
Remember that one of the guiding principles of the initial USB spec was to
keep the Device as simple as possible and move the complexity and
responsibility of running the network with the Host. For this
reason we would strongly recommend that a 32 bit CPU be used along with a
CMX USB Host Stack that can then manage the enumeration process. The Host stack
will also optionally support the HID, Printer, Mass storage and Comms
Classes.
The Target system needs to be ON-The-GO enabled
As well as needing the interface to be OTG capable this implies that you will need both Device and Host software Stacks. An optional On-The-GO layer to the CMX USB stacks provides an API that the application can use to control switching between Host and Device Stacks. Other than those actions (usually used at enumeration) the OTG layer does nothing.
Debugging USB -- the USB analyser
If you are doing any significant USB development either at the driver
level or as part of your application then getting a USB Analyser such as one
of the Ellisys range will
soon recoup its cost in time saved. There are a Low Speed and Full Speed version
with the High Speed version is available with a range of
trigger options to help find the most elusive of bugs.
The analysers collect each transaction as they happen for archiving to disk
and include a software package that can be used to view not just the
transactions but also for standard messages the layout and meaning of each
field is displayed (right hand pane below). This review software does
not need an analyser in order to display collected data and so may be used
to share results with suppliers or colleagues. If you are a USB
beginner its worth downloading this
software in order to look at the examples included and to get a
better understanding of this level of the USB protocol.
 |
|
 |
These Analysers will still come in useful once the driver aspects are sorted as they will allow you to see what data is being passed by the application programs as you developed your higher levels of code. As well as showing individual messages an option is available on the Ellisys analysers to recognise the USB Classes and show how their data is structured and what values are being passed.
Further reading
USB in a nutshell provides a more detailed description of the USB hardware and protocols.
USB Standards site for those who want to read the standard or a wealth of supporting matter.
Jan Axelson's excellent books on USB are previewed on his site.
If you have found this
tutorial useful you might also be interested in our tutorials on
Embedded TCP/IP and CAN or in tutorials on a range of microprocessor and
microcontroller families.
If so you can find them at Embedded Tutorials
| Home | Information Zone |
| Computer Solutions Ltd 87 Briar Road, Shepperton, Middx, TW17 0JB |
|
| Telephone: +44 (0) 77 4342 2526 | |
| Email: sales@computer-solutions.co.uk | Web: www.computer-solutions.co.uk |
| Copyright © 2022 Computer Solutions Ltd | |