emusb

emUSB

emUSB is a high speed USB device stack specifically designed for embedded Systems. The software is written in ANSI "C" and can run on any platform. emUSB can be used with embOS or any other supported RTOS. A variety of target drivers are already available. Support for new platforms can usually be added for no extra charge.

Main features

High speed
Optimized to be used with embOS but works with any other supported RTOS.
Easy to use
Easy to port
No custom USB host driver necessary
Start / test application supplied
Highly efficient, portable, and commented ANSI C source code
Hardware abstraction layer allows rapid addition of support for new devices.

emUSB components

emUSB consists of three layers: A driver for hardware access, the emUSB core and at least an USB class driver or the bulk communication component.

The different available hardware drivers, the USB class drivers and the bulk communication component are additional packages, which can be combined and ordered as it fits to the requirements of the project. Normally, emUSB consists of a driver that fits to the used hardware, the emUSB core and at least one of the USB class drivers MSD, CDC, HID or the unclassified bulk component

Component	Description
USB protocol layer
Bulk	emUSB bulk component. (emUSB-Bulk)
MSD	emUSB Mass Storage Device class component. (emUSB-MSD).
CDC	emUSB Communication Device Class component. (emUSB-CDC)
HID	emUSB Human Interface Device Class component. (emUSB-HID)
Core layer
emUSB Core	The emUSB core is the intrinsic USB stack.
Hardware layer
Driver	USB controller driver.

emUSB-Bulk

The emUSB-Bulk stack consists of an embedded side, which is shipped in source code form, and a driver for the PC, which is typically shipped as executable (.sys). (The source of the PC driver can also be ordered.)

Purpose of emUSB-Bulk

emUSB-Bulk allows developers to quickly and painlessly develop software for an embedded device that communicates with a PC via USB. The communication is like a single, high speed, reliable channel (very similar to a TCP connection). It basically allows the PC to send data to the embedded target, the embedded target to receive these bytes and reply with any number of bytes. The PC is the USB host, the target is the USB client. The USB standard defines 4 types of communication: Control, isochronous, interrupt and bulk. Experience shows, that for most embedded devices bulk mode is the communication mode of choice. It allows usage of the full bandwidth of the USB bus.

The Kernel mode driver (PC)

In order to communicate with a target (client) running emUSB, an emUSB bulk kernel mode driver has to be installed on Windows PC' s. Typically, this is done as soon as emUSB runs on target hardware.

Why is a driver necessary ?

In Microsoft 's Windows operating systems, all communication with real hardware is implemented with kernel-mode drivers. Normal applications run in user-mode. In user-mode, hardware access is not permitted. All access to hardware is done through the operating system. The operating system uses a kernel mode driver to access the actual hardware. In other words: every piece of hardware requires one or more kernel mode drivers to function. Windows supplies drivers for most common types of hardware, but it does not come with a generic bulk communication driver. It comes with drivers for certain classes of devices, such as keyboard, mouse and mass storage device (for example, a USB stick). This makes it possible to connect a USB mouse and not having to install a driver for it: Windows already has a driver for it.

Unfortunately, there is no generic kernel mode driver which allows communication to any type of device in bulk mode. This is why a kernel mode driver needs to be supplied in order to work with emUSB-Bulk.

Supported platforms

The kernel mode driver works on all NT-type platforms. This includes Windows 2000 and Windows XP (home and professional), Windows 2003 Server and Windows Vista. Windows NT itself does not support USB; Win98 is not supported by the driver.

Example application

Example applications for both the target (client) and the PC (host) are supplied. These can be used for testing the correct installation and proper function of the device running emUSB. The application is a modified echo server (BULK_Echo1.c); the application receives data byte by byte, increments every single byte and sends it back to the host.

bulk example

MSD class

Access the target device like an ordinary disk drive

emUSB-MSD enables the use of an embedded target device as a USB mass storage device. The target device can be simply pluged-in and used like an ordinary disk drive, without the need to develop a driver for the host operating system. This is possible because the mass storage class is one of the standard device classes, defined by the USB Implementers Forum. Virtually every major operating system on the market supports these device classes out of the box.

No custom host drivers necessary

Every major OS already provides host drivers for USB mass storage devices, there is no need to implement an own. The target device will be recognized as a mass storage device and can be accessed directly.

Plug and Play

Let's say the target system is a digital camera using emUSB-MSD. Videos or photos taken by this camera can be conveniently accessed with the file system explorer of the used operating system, if the camera is connect to the host.

Typical applications

Digital camera
USB stick
MP3 player
DVD player
Any target with USB interface: Easy access to configuration and data files

emUSB-MSD features

Key features of the emUSB-MSD are:

Can be used with RAM, parallel flash, serial flash or mechanical drives
Support for Full speed (12 MBit/s) and High speed (480 MBit/s) transfer rates
Easy to use
Easy to port
No custom USB host driver necessary
Highly portable, efficient, commented ANSI C source code
OS-Abstraction: Use with any RTOS, no OS required for MSD only devices
Hardware abstraction layer allows rapid addition of support for new devices

How does it work?

Use file system support from host OS
A device which uses emUSB-MSD will be recognized as a mass storage device and can be used like an ordinary disk drive. If the device is unformatted when plugged-in, the host operating system will offer to format the device. Any file system the host provides can be used. Typically FAT is used, but other file systems such as NTFS are possible too. If one of those file systems is used, the host is able to read from and write to the device using the storage functions of the emUSB MSD component, which define unstructured read and write operations. Thus there is no need to develop extra file system code if the application only accesses data on the target from the host side. This is typically the case for simple storage applications, such as USB memory sticks or ATA to USB bridges.

Only provide file system code on the target if necessary

Mass storage devices like USB sticks does not require an own file system implementation. File system program code is only required if the application running on target device has to access the stored data. The development of a file system is a complex and time-consuming task and enhances the time-to market. Thus we recommend the use of commercial file system like emFile, Segger's file system for embedded applications. emFile is a high performance library that has been optimized for minimum memory consumption in RAM and ROM, high speed and versatility. It is written in ANSI C and can be used on any CPU and on any media. Refer to www.segger.com/ emfile.html for more information about emFile.

CDC Class

emUSB-CDC converts the target device into a serial communication device. A target device running emUSB-CDC is recognized by the host as a serial interface (USB2COM, virtual COM port), without the need to install a special host driver, because the communication device class is one of the standard device classes and every mayor operating system already provides host drivers for those device classes. All PC software using a COM port will work without modifications with this virtual COM port.

Typical applications

Modem
Telephone system
Fax machine

HID class

The Human Interface Device class (HID) is an abstract USB class protocol defined by the USB Implementers Forum. This protocol was defined for the handling of devices which are used by humans to control the operation of computer systems. An installation of a custom-host USB driver is not necessary, because the USB human interface device class is standardized and every major OS already provides host drivers for it.

Method of communication
HID always uses interrupt end points. Since interrupt endpoints are limited to at most one packet of at most 64 bytes per frame (on full speed devices), the transfer rate is limited to 64000 bytes/sec, in reality much less than that.

Categories

Devices which are in the HID class basically fall into one of 2 categories:
"True HIDs" and "vendor specific HIDs", explained in the following. One ore more examples for both categories are provided.

"True HIDs"
HID devices communicating with the host operating system. Devices which are used by a human being to input / output data, but do not directly exchange data with an application program running on the host.

Typical examples:

Keyboard
Mouse and similar pointing devices
Joystick
Game pad
Front-panel controls - for example, switches and buttons.

"Vendor specific HIDs"
These are HID devices communicating with an application program. The host OS loads the same driver it loads for any "true HID" and will automatically enumerate the device, but it can not communicate with the device. When analyzing the report descriptor, the host finds out that it can not exchange information with the device; the device uses a protocol which is meaningless to the HID driver of the host. The Host will therefore not exchange information with the device. A host recognizes a vendor specific HID by its vendor defined usage page in the report descriptor: The numerical value of the usage page is between 0xFF00 and 0xFFFF.

An application has the chance to communicate with the particular device using API functions offered by the host. This allows an application program to communicate with the device without having to load a driver. HID does not take advantage of the full USB bus bandwidth; bulk communication can be much faster, but requires a driver. Therefore it can be a good choice to select HID as device class, especially if easy-of use is important and high communication speed is not a requirement.

Typical examples:

Bar-code reader
Thermometer
Voltmeter
Low-speed JTAG emulator
UPS (Uninterruptible power supply)

Drivers

emUSB does not contain any hardware dependencies. These are encapsulated through a hardware abstraction layer, which consists of the interface functions described in this chapter. All of these functions for a particular USB controller are typically located in a single file, the USB driver. Drivers for hardware which has already been tested with emUSB are available.

Range of supported USB hardware

The interface has been designed in such a way that it should be possible to use the most common USB device controllers. This includes USB 1.1 (full speed) controllers, USB 2.0 (high speed) controllers, both as external chips and as part of microcontrollers.

Available USB drivers

The following device drivers are available for emUSB:

Driver (Device)	Identifier
ATMEL AT91RM9200	USB_Driver_AtmelRM9200
ATMEL AT91SAM7A3	USB_Driver_AtmelSAM7A3
ATMEL AT91SAM7S64	USB_Driver_AtmelSAM7S
ATMEL AT91SAM7S128	USB_Driver_AtmelSAM7S
ATMEL AT91SAM7S256	USB_Driver_AtmelSAM7S
ATMEL AT91SAM7SE	USB_Driver_AtmelSAM7SE
ATMEL AT91SAM7X128	USB_Driver_AtmelSAM7X
ATMEL AT91SAM7X256	USB_Driver_AtmelSAM7X
ATMEL AT91SAM9261	USB_Driver_AtmelSAM9261
NXP LPC214x	USB_Driver_NXPLPC214x
NXP LPC23xx	USB_Driver_NXPLPC23xx
NXP LPC318x	USB_Driver_NXPLPC318x
OKI 69Q62	USB_Driver_OKI69Q62
Sharp LH79524/5	USB_Driver_SharpLH79524
ST STR71x	USB_Driver_STSTR71x
ST STR750	USB_Driver_STSTR750