µC/USB-Bulk Overview

You are here : Micrium : Products : µC/USB-Bulk : Overview

Mass Storage Class (MSC) Communication Device Class (CDC) Drivers Licensing Pricing Information

µC/USB-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.

µC/USB-Bulk stack has been designed to work on any embedded system with a USB client controller. A hardware abstraction layer makes it possible to easily write or modify existing hardware access routines. It can be used with USB 1.1. or USB 2.0 devices. The 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), but is also available as source code.


The USB standard defines 4 types of communication:

• Control,
• isochronous,
• interrupt
• and bulk.

What is included

The following table shows the contents of all USB bulk stack subdirectories:

Features

• High speed
• The stack can be used with or without a RTOS.
• Start / test application supplied

USB Basics

USB is the abbreviation for "Universal Serial Bus".

A USB system has an asymmetric design. Every single host can be connected with multiple devices in a tree-like fashion using special hub devices. You can connect up to 127 devices to a single host, but the count must include the hub devices as well.

The design of USB improves the plug-and-play capabilities by allowing devices to be added to the system without rebooting the PC.

USB communication includes provision for power to the connected devices, so several devices with minimal power requirements can be used without extra power supplies. USB can connect peripherals such as keyboards, mice, digital cameras, scanners, printers, networking components and harddrives.

When a new device is connected the first time, the host enumerates it and tries to load the device driver necessary to run it.

Endpoint types

The USB standard defines 4 types of communication: Control, isochronous, interrupt and bulk. Control transfers are used in the setup phase. The application can basically select one of the other 3 transfer types. For most embedded applications, bulk is the best choice since it allows the highest possible data rates.

Control transfers
Typically used to configure a device. It can also be used device specific purposes. Used to configure a device at attach time and can be used for other device-specific purposes, including control of other pipes on the device.

Isochronous transfers
Typically used for applications which need guaranteed speed. Isochronous transfer is fast, but with possible data loss. A typical use is audio, which requires a constant data rate.

Interrupt transfers
Typically used by devices that need guaranteed quick responses (bounded latency).

Bulk transfers
Typically used by devices that generate or consume data in relatively large and bursty quantities. Bulk transfer have wide dynamic latitude in transmission con- straints. It can use all remaining available bandwidth, but with no guarantees on bandwidth or latency. Since the USB bus is normally not very busy, there is typically 90% or more of the bandwith available for USB transfers.

Setup phase / enumeration

Before the target can communicate with the host, the host needs to get information from the target. This information is gathered in the initial setup phase. The information is contained in the descriptors, which are in the configurable section of the stack. The most important part for identification of the target device are the product Id and vendor Id. During the setup phase, the host also assign an address to the client. This part of the setup is called enumeration.

Product / vendor Ids

A vendor Id can be obtained from the USB Implementers Forum, Inc. (www.usb.org). This is necessary only when you finish development of the product; during the development phase, you can use the vendor and product Ids supplied as sample.

Start application

The start application (in the application subfolder) is a modified echo server, which can be used to test the stack. The application receives data byte by byte, increments every single byte and sends it back to the host.

Source code of Start.c:

The start application will of course later on be replaced by your real application program. For the purpose of getting the stack up and running as well as doing an initial test, the start application should not be modified, but instead compiled and linked with your project.

The Kernel mode driver (PC)

In order to communicate with a target (client) running the stack, you have to install the USB-Bulk kernel mode driver on your Windows PC. Typically, this is done as soon as the stack runs on your 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 (USB stick). This makes it possible to connect a USB mouse and not having to install a driver for it: Windows alreadys 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 the USB stack.

Supported platforms

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

Using the sample application

Sample applications for both the target (client) and the PC (host) are supplied. The sample application for the PC is supplied as source code incl. MSVC 6.0 workspace and as executable; the sample application for the target is supplied as source code only.

The sample application can be used to test the correct installation and proper function of the USB BULK device.

The PC sample application first tries to establish a connection to the target by opening the device. If this fails, an error message is shown. If a connection can be established, it exchanges data with the target, testing the USB connection.

Running the sample application

The sample application is supplied in both source code and executable form in the SampleApp directory as SampleApp\SampleApp.exe. To run the sample application, simply start the executable, for example by double clicking it. If the USB BULK device isn't connected to your PC or the driver is not installed, you get the following message box.

If the connection to the USB BULK Device works correctly, the sample Application will write one byte and afterwards read one byte. If an error in the reading or writing process occurs a message box pops up.

In the USB BULK device runs an application that increments the received byte and sends it back. The sample application reads this byte and checks its value. This is repeated 2 times unless an error occurs. In either case, a message box pops up, informing you whether everything worked fine or if an error occurred.