USB Basics - Part II (How USB Devices are designed and developed?)

This article answers many questions related to how to develop USB devices and what are the factors involved in the development process.

When you goto any shop to buy an USB device, you might have found out many variants of USB devices like Pen Drives, MP3 Players, USB Printers and Scanners, Digital Cameras, Cell Phones and many more devices which use USB. All these devices can connect to a Personal Computer or Laptop through the ports available on that system. Later on you can use these devices to transfer data like photos contacts etc.. to the PC. After release of the USB Specification 2.0 many devices started supporting USB, which originally never thought of being connected to PC. In the previous article USB Basics - Part I the basic architectural features and facilities are listed.

This article discusses what are things need to be taken into consideration before the design of the USB device and what are all the options available to the designer of an USB device.

USB device development involves basically 4 steps.

Choosing the right FPGA, Microcontroller, Microprocessor, or Custom built devices which suits your application.

Designing and developing the hardware and firmware as required by the application.

Host system application development. To understand what is a host refer to USB Basics - Part I.

Obtaining a Vendor ID and Product ID.

Let us take a look at these aspects more closely.

Ok, it is time to learn some theory.

1. Choosing the right FPGA, Microcontroller, Microprocessor, or Custom built device.
USB came in two revisions, 1.1 and 2.0 . And all the new Computers in the market now support the revision 2.0 which is also known as USB specification 2.0. The USB specificaiton mentions verious features like speed of operation, trasfer types, physical connectors etc.. that can supported by the USB devices. See previous article USB Basics - Part I for more details.

But, one important thing to note down is, a particular device may not need all features that are mentioned in the specification. Some devices like Mouse can just have interrupt transfer(small quantity data transfer mechanism) and low speed operation supported in them. Some devices like memory stick or external CD drives may need high speed bulk operation(large quantity data transfer) implemented in them. So, it is the designer's responsibility to choose the right FPGA, Microcontroller or Microprocessor for his application. There are now many semi conductor companies coming out with USB solutions. For example Microchip has the PIC16C7X5 and 18F4550 family of devices which support low speed and full speed operations respectively. Cypress and Philips also have devices that support High Speed, Low Speed and Full Speed USB operations.

Other technologies like USB-OTG( USB On the go) and Wireless USB are emerging and these companies are coming up with solutions that support these emerging technologies.

There are also Custom built silicon available with RS-232 to USB conversion features, or Parallel Port to USB conversion features. So, if someone's application is just RS-232 to USB or USB to RS-232 conversion, he don't have spend lot of money on buying the micro controllers or FPGA and later on working on USB specific details. The developer can straight away pick one of the application specific chips and integrate them on his product. Devices of this type reduce the burden on the designer, so that he can concentrate on the end product instead of spending lot of time on developing USB related code. Again Cypress produces this kind of solutions

FPGA are specifically developed for a group of applicaitons and there are companies out there who are doing customized USB solutions on FPGAs.

So, depending on the speed, memory and transfer rate, and data integraty requirements one of the device can be selected. A list of devices supporting USB and their features are explained in the article Various USB Devices.

2. Designing and developing the hardware and firmware as required by the application.

Depending on the requirements you might have selected a device as per the explanation above. So, if the device selected is a custom built or application specific device in most probability the device might have implemented the USB operation completely and you just need to write to a bunch of registers for transmitting and receiving data over USB and make the required physical connections. But if you choose a microcontroller or microprocessor then, you may need to develop the USB Protocol Stack on the device(peripheral) side. This will involve considerable amount of work and you should be prepared for it. But most of the companies will do this work for you by providing the software and firmware frameworks when you buy their products. Again, as a developer you need to know what portions of the stack need to be implemented in the firmware. Sometimes the microprocessor/controller will come with the Chapter 8 protocol(This protocol is explained in Chapter 8 of the USB specification) and you may have to implement the Chapter 9(Again this protocol is defined in Chapter 9 of the USB specification) protocol. Sometime both. PIC18F4550 family devices come with Chpater 8 protocol implemented in them and the company supplies free Chapter 9 protocol stack. More explanation on the firmware USB Stack is available in the article Firmware USB Stack.

The other aspect is related to hardware design. The USB Bus has four wires in the cable. The cable can be 5 meters in length between the Hub and device. The signals carried in the cable are Vusb, GND, D+ and D- lines. D+ and D- lines are differential data lines and Vusb and GND can power lines which can power up the device. By placing pull-up resistors(1.5 K ohm connected to 3.3 V) on the D+ or/and D- lines we can enable a particular speed of operation. A pull-up on D+ line indicates the device uses Full-Speed Operation and pull-up on D- line indicates that the device uses Low-Speed operation. The High-Speed device connect to host as Full-Speed devices, meaning they will have a pull-up on D+ line. Many devices come with internal pull-up resistors which can be enabled or disabled as required. Otherwise external pull-up resistors need to be used.

USB works at 3.3 Volts, so the USB portion of the device need to have this power supply. Many devices come with 3.3 internal regulator or will have facilities to connect to an external regulator when other parts on the device operate at different voltages like 5 volts. Apart from this to achieve the bit rates as specified by the specification the USB devices need to have an appropriate input clock supplied. Now in industry the defacto standards related clock frequency are - 6 MHz in case of Low-Speed devices , 48 MHz in case of Full-Speed devices and 480 MHz in case of High-Speed operation.

After configuring the required speed with the pull-up and selecting appropriate input clock frequency for the device, one has to take a look at how the power supply need to provided to the device. The USB devices can draw power from the bus (known as Bus powered devices or they can have an external power supply connected to them (known as Self powered devices ). The factor that influences this decision is the power requirements of the USB device or USB board. By default the USB Bus can supply up to a maximum of 100 mAmps to each device connected on the bus and if more power is required upto 500 mAmps can be obtained through a process called negotiation. If the device does not get allocated the required amount of power because already other devices on the board are bus-powered, then the device need to have an external power supply. Also, if the device draws more than 500 mAmps, then it need to have an external power supply (self-powered).

The next thing that need to be taken into consideration related to hardware is the kind of USB connector to use. There are two types of connectors namely "A" Plug and "B" Plug. They are also called as Upstream Connectors and Downstream Connectors respectively. The "A" Plug is the one that get connected to the host or any hub. "B" Plugs are the combination of plugs. The following diagram shows 3 varities of "B" plugs for various speeds of operation.
The "mini - B" plugs are most widely used in Digital Cameras, Mobile Phones etc.. Sometimes the device will not use any "B type plugs". If you have observed on some of the Flash Drives or Pen Drives you can devices with out "B type" or "mini - B" type plugs. They will have the "A " type plug directly soldered to them. The specification allows some deviations in certain cases.

After selecting the chip and speed requirements, implementing the firmware USB stack, designing the board with specific power requirements deciding on the connectors you will be ready to have the USB device ready. So, the development activities will move further and you will get the first prototype of the board load the firmware and connect it to PC. At this point of time, if you think that the device works straight away you are mistaken. Still the hardware and firmware development activities are not completed.

At this point of time, you need to decide on how the device need to be seen by Windows operating system or any Host operating system for that matter.

The USB specification also introduced another concept called Classes also known as Device Classes.This mechansim helps in grouping similar types of devices into a single group. For example we can group devices like mouse, keyboard, joystick etc.. into a group. The basic nature of these 3 devices is that, they transmit data to the computer which the computer use to perform specific operations. Actually the USB Specification has given specific class name to this set of devices called as "Human Interface Device Class" or simply "HID Class". There are many types of device classes. To list a few,

• Audio Device Class - For audio devices like MP3 players
• Communication Device Class - RS-232(COM) port emulators, Parallel Port Emulators, Modems etc..
• Mass Storage Class - Flash Disks & Pen Drives
• Printer Class
• Test & Measurement Class

etc.. Devices that does not fall in any of the mentioned catogories are called as Custom Class or Vendor Class devices.

Each device class again has some sub classes. So, during the development of firmware, after having the Chapter 8 and Chapter 9(Data-Link Protocol) ready, the required device class code need to be implemented. The device class information is stored/represented in the form of collection of data structures also known as Descriptors. So, these descriptors need to be defined as per the device class specification. There are 5 types of descreptors. Device Descriptor, Configuration Descriptors, Interface Descriptors, End Point Descriptors and String Descriptors. More about these later in the article Device Descriptors. The Chapter 9 protocol stack needs this information for making the device functional and they are part of the Chapter 9 of the specification.

The next step would be development of user application itself. Once the user application is developed, the data transfer takes place on the USB Bus on a bunch of vrtual links called pipes. The Endpoint Descriptor mentioned above will define these pipes. The host will gatheger the information about the endpoints and the pipes are created between the host and the device. Later on the application on the device can use these pipes to transmit and receive data from the host.

So, the device is ready for operation.

3.Host system application development.
There are two aspects related to Host system application development. We have already seen in the previous section that there are two types of device classes namely Standard classes and Vendor Classes. If the device incorporates the descriptors and functionality for the standard classes, then the host system would have already supplied a device driver for this group of devices. This is the reason why when we plug in the flash or pen drive on the PC, automatically it shows a drive name like E:\ or F:\. But if the host system does not already support a device driver then, a new device driver for that class need to be developed and supplied along with USB device.

Also, if the device falls under Custom Class that time also a device driver need to be supplied.

One important note here is versions of Windows earlier to Windows 98 SP2 does not have support for USB. There are custom vendors who developed support packages for Windows NT.

The next aspect would be to decide on if a host application software need to be developed or not. In most cases the host application need to be developed. In cases where the host it self is the user of the device, no host application need to be developed. A good example for this is Mouse. Also when you are migrating the old RS-232 application to USB which comunicates with an already existing PC application using COM port, the PC application need not be modified. The new USB device can have the CDC(Communication Device Class) implemented in it and emulate the COM port behaviour. This reduces the burden of re-writing many applications.

Also, along with every device an .INF file (Information File) need to be supplied if the operating system does not have one. The INF file contains information about how to install the new USB device when it is connected. The installation process may include setting registry of the host, re-configuring the kernal and copying certain files from the installation disk.

4.Obtaining a Vendor ID and Product ID.
This is the last major and important step before releasing the product to the Market apart from device testing. The Vendor ID and Product ID are two unique 16-bit unsigned hexa decimal numbers assigned to a specific vendor or USB product developer. Out of these two, the Vendor ID need to be obtained from the USB Implementars Forun. For obtaining the Vendor ID also known as VID is a serial number, the company has to pay $1500 to the forum and register with them. The Product ID, also known as PID is an in-house serial number that is maintained by the developer or developer's company them selves and whenever a new product is released into the market a unique Product ID need to be incorporated into it.

The Vendor ID(VID) and Product ID(PID) are used in both the INF Files as well as in the Device Descriptors. During the Plug & Play(Auto Detection, Auto Configuration) activities, the Device Descriptors containing the VID & PID will be transferred to the Host System. The Host Operating System will search through all the registred INF files and if a match is found, will use that INF file for installing the device. If no match is found it will prompt the user to provide the media(CD-ROM, Floppy Disk etc..) with a new INF file.

So, to avoid the confilicts with other vendor's devices during the auto configuration stage, and to avoid leagel issues the Vendor ID need to be obtained from the implementors forum, before releasing the product into the market. The Product ID is required to avoid conflicts with other devices from the same vendor. Many semi conductor vendors has programs to help their customers related to Vendor IDs. Microchip Technologies has one program as of today where you can share their Vendor ID. This saves $1500 for you.

I conclude this article here.. And in next bunch of articles I will explain in detail how to go about device selection, firmware development, device class development, device driver selection & development etc..