USB Device Classes and Choosing the right Device Class for your application

1. USB Device Classes

A USB Device Class is a groups of devices or interfaces with similar attributes or services. USB Class is mainly used to describe the manner in which an interface communicates with the host including both data and control mechanisms. The class information is used by the host to identify and load the required drivers for specific interfaces/devices, to manage interface connectivity, and to manage the capabilities provided by the interface.

A USB Class Specification defines the requiremenets of a USB Class. The Class Specification is used by both firmware developers and host software developers (device driver developers) to agree upon certain rules while developing a USB device. The device drivers that cover all features of a device class is known as Class Drivers. These drivers can be used by any kind of device that falls in a particular device class.

The Class Drivers are developed by Operating System or third party software vendors, as well as by manufacturers supporting multiple devices which fall in the same device class.

USB-IF is responsible for defining and maintaining Device Class Specifications.

2. OS Supplied Device Drivers

The Class Definition and Class Specification allows independent groups to work seperately on host software development and device development, but still allows the device and host software work without any interoperability issues. Most of the times the Operating Systems will implement default device drivers for most of the device classes introduced by USB-IF. The default device drivers reduce the burden on device manufacturers as they avoid spending time on development of device drivers. These device drives will be installed when the Operating System is installed on a host, and available for all devices that follow the class specifcation.

The other benifit of designing a device to follow a specific Device Class is, even if a Operating System does not support a device class in current version, there is a good chance that the class will be supported in next version.

To avoid Windows to show the Unknown Provider message, the vendor developed device drivers need to signed for Windows. If you are already using a Operating System supplied Class Driver then this activity can also be avoided.

So, overall apart form grouping devices which has common features, the device class also reduces the development time cycle by helping the Operating Systems also to do some work on device manufacturer's behalf.

3. List of USB Device Classes supported by Windows Operating System as of today.

The Base Class Code is a hexadecimal number which is used by the USB identify a device class. In the following lists it is provided in the parenthesis. Device Classes listed in Microsoft web-site:

1. Bluetooth class - (0xE0)
2. Chip/smart card interface devices (CCID) - (0x0B)
3. Hub class - (0x09)
4. Human interface device (HID) - (0x03)
5. Mass storage class (MSC) - (0x08)
6. Printing class - (0x07)
7. Scanning/imaging (PTP) - (0x06)
8. USB Audio class - (0x01)
9. Modem class (CDC) - (0x02)
10. Video class (UVC) - (0x0E)



Not all classes proposed by the USB-IF are implemented in the Operating Systems. Compare the following list with previous list. The numbers in the parenthesis will give th Base Class code. This should match in both the lists.

Device Classes listed in USB-IF web-site(www.usb.org):

1. Use class information in the Interface Descriptors - (0x00) - Special Case
2. Audio Class - (0x01)
3. Communications and CDC Control - (0x02)
4. HID (Human Interface Device) - (0x03)
5. Physical - (0x05)
6. Image (PTP) - (0x06)
7. Printer - (0x07)
8. Mass Storage (MSD) - (0x08)
9. Hub - (0x09)
10. CDC-Data - (0x0A)
11. Smart Card - (0x0B)
12. Content Security - (0x0D)
13. Video - (0x0E)
14. Diagnostic Device - (0xDC)
15. Wireless Controller - (0xE0)
16. Miscellaneous - (0xEF)
17. Application Specific - (0xFE)
18.
19. Vendor Specific - (0xFF)
20.



Each Device Class will have pre-defined format for the descriptors in use. So, when a particual device is implemented to use a particular device class, all the data structures need to be formatted as per the device class requirements.

Next Section on Standard USB Device Classes and Choosing the right Device Class for your application - (Part II) explains how Descriptors in USB is used to distinguish between Device Classes and how they need to be used for defining Device Classes.

Windows 98 USB Driver Information - How to find one for your USB device?

1. Windows 98 USB Drivers - Introduction

In this article I try to provide some insights on why we struggle to find Windows 98 USB Drivers for many USB devices. At the same time I also tried to provide various links to available free and non-free drivers for Windows 98 based devices.

See if the links in the Article related resources section can solve your problems, or you can read through the main article below.

First and most important one has to know about Windows 98 USB Driver support is, the evolution of the windows product line.
i.e Windows 95 > Windows 98 > Second Edition > Windows ME > XP.

If you see the time lines of USB Specification versions and Windows Operating Systems version, by the time Windows 98(NOT Windows 98 SE) came into existence only USB 1.1 Specification is available. And not many USB devices are available in the market. The USB Host Protocol Stack implementation is still going on in both hardware (host controllers development) as well as in software (USB Stacks).

So, when Windows 98 is released it came with limited support for USB devices. The only devices that started working on USB are Mouse and Keyboard. No Pen Drives, No Cameras, No iPods, No Mobile phones could connect to the PC over USB.
Also, Windows 98 being a new face-lift OS from the time Windows 95 is released, it could support USB devices from few vendors (device manufacturers) only.

The Windows 98 SE (Second Edition) is released, the number of USB devices that are supported increased dramatically. We can say proper USB support is available starting from Windows 98 SE only. What it means is, Windows 98 SE essentially came with more USB Device Drivers.

Also note that Windows NT, which also came into existence along with Windows 98, does not have USB support at all. And there many software suites like Jungo's WinDriver/KernelDriver are designed to specifically solve this problem.

2. Windows 98 USB Driver for you MSD (Mass Storage Drives)
The scarcity of support in Windows 98 for many vendors lead to unavailability of Windows 98 specific usb device drivers for devices like iPODs, USB Pen Drives, Game Consoles etc...

How most vendors tackled this situation is they started providing download packages of Windows 98 driver for their devices on their web sites and re-distribution packages. Most of the times you need provide your product details in a search box in the vendor's website.

For example if you have ScanDisk USB Thumb Drive, goto ScanDisk's website, in the support section enter the Device details, they show you available list of driver downloads. If the drivers are not available here or they don't give Windows 98 USB Driver support, then you can goto the generic driver download web sites and search for closest match.

There are many general websites which claim to scan your computer provide you with appropriate drivers. Some websites provide free downloads of Windows 98 USB Driver software.

And you can do search for Windows 98 USB Drivers at Microsoft Download Center too.

3.Generic Windows 98 USB Driver packages

Apart from the USB Device specific drivers, there are generic usb drivers also available. I have provided few links in the resource section which give more details on from where these Generic Windows 98 USB Driver packages can be downloaded.

4.Notes for developers/programmers

Every Windows OS will come with it's Driver Development Kit(DDK). If you want to develop a Windows 98 USB Driver you should learn the Windows 98 DDK first and start doing the development. Windows XP, 2000, 2003, Vista are having Layered USB Driver Architecture, where as a developer you don't need to learn DDK and do low level programming on the OS. These OSes are providing a generic user level USB driver that any one can use easily.

jsr080 - javax.usb - A Java based USB Library

1. JSR-080 Introduction

JSR-080 (JSR080 or JSR-80) is a Java Specification Request in the Java Community Process(SM) Program. The JSR080 specification provides a standard Java(TM) API for communicating with any device attached to the computer via Universal Serial Bus (USB). It allows Java applications to discover, read, write, and manage USB devices.
The JSR080 specification is released during year 2005. More details about the JSR080(JSR-80) can be found here.

2. javax.usb Introduction

javax.usb is an Opensource implementaion for the API provided in JSR080. There are 7 modules in javax.usb project. They are listed below.

• javax-usb: The actual API implementation as per JSR080.
• javax-usb-ri: This is the common RI (Partial OS-Independent Reference Implementation ).
• javax-usb-ri-linux: This is the Linux implementation that connects the Linux USB Stack to OS-Independent RI.
• javax-usb-ri-windows: This is an ABANDONED Windows implementation. it does not work, it needs a kernel driver.
• javax-usb-libusb: This is an alpha libusb implementation (written for Windows).
• javax-usb-tck: This is the Test Compliance Kit (TCK) required by the JCP.
• javax-usb-example: This package contains example code that shows how the API can be used.

There is also a BSD implementation created by Ricoh. For more information, visit either their global site and register for the Ricoh Developer Program (RiDP).
3. How javax.usb API looks?

The starting point to use the API is a Java class USBHostManager. This class lets you obtain an OS-specific instance of the USBServices interface (based on information in javax.usb.properties), from which you can obtain the virtual root hub:
UsbServices services =
UsbHostManager.getUsbServices ();
UsbHub vroothub = services.getRootUsbHub ();


The virtual root hub, obtained by calling UsbServices's public UsbHub getRootUsbHub() method, provides access to all of the available host controllers (and their root hubs). UsbHub's public boolean isRootUsbHub(), public byte getNumberOfPorts(), and public List getUsbPorts() methods are useful in verifying, enumerating, and obtaining root hubs.

More details on how to access USB devices is explained here: "Access USB Devices from Java Applications"

USB Mass Storage Device Class (MSD) [Or] The "Flash Drive, MP3 Player, External USB Hard Drive, Digital Camera" Class

1. USB Mass Storage Device (MSD) Class - Introduction

After HID Class MSD (Mass Storage Device) Class is the most celebrated device class out of all the USB Device Classes. Unlike HID class it is really not used for many different kinds of applications. It's sole purpose of existance is to connect a device to the PC as if the device is a Disk Drive. Thus the name Mass Storage Device Class.

Most popular examples of devices based on Mass Storage Device Class are:

* external magnetic hard drives
* external optical drives, including CD and DVD reader and writer drives
* portable flash memory devices
* adapters bridging between standard flash memory cards and a USB connection
* digital cameras
* various digital audio players & portable media players
* Card readers
* Portable Gaming systems (Nokia N-GAGE/Sony PSP)
* personal data assistants and handheld computers
* some newer mobile phones, like Sony Ericsson K800 and K510, Nokia N73, Nokia E61

Two books that covers MSD to the core are USB Complete and USB Mass Storage .

2. Benefits of using MSD device in your application

Mass Storage Devices are almost supported by all existing operating systems. For Windows 95, the MSD device used to come with it's own Windows 95 driver, as Microsoft did not produce any Generice USB MSD driver by then. Similar case with Windows 98 too. Almost all versions of Microsoft Windows starting from Windows 98 SE, and all most all Linux variants, latest MaxOS versions give good support to Mass Storage Device Class. What it means to you as an USB device developer is, you don't have put effort on developing OS specific device drivers. These device drivers are already available for your use. The only catch is when you design and develop a Mass Storage Device hardware/firmware you are essentially developing a device that will be viewed by the host computer as a Disk Drive. And that is what you need to remember.

Windows Mobile supports accessing of the most USB mass storage devices formatted with FAT on devices with USB Host. Also note that there is no native support for Mass Storage Devices in Windows NT.

3. How to interact with any MSD device on Windows

The USB mass storage specification does not require any particular file system to be used on MSD devices. Instead, it provides a simple interface to read and write sectors of data—much like the low-level interface used to access any hard drive—using the "SCSI transparent command set." Operating systems may treat the USB drive like a hard drive, and can format it with any file system they like.

But if you want to provide additional File System support then, MSD device need to implement a File Syetem on top of the firmware. Some standard file systems are NTFS, FAT, FAT32 etc..

Once you are have your MSD firmware stack ready, and your device is viewed as MSD device by the OS, and you can access the MSD device from your application like access any other file system. You can create files, directories, format the drive and do all sorts of things that you can do with a file system.

4. How to Initialize any MSD device on Linux

The following articles will provide better understanding on MSD on Linux.
These articles explain how Mass Storage Devices can be initialized in Linux, what are Linux commands need to use called etc...

The HID (Human Interface Device) Class [Or] The "Keyboard, Mouse, Joystick" Class

1. HID Class - Introduction

HID Class is most celebrated device class out of all the USB Device Classes. It is used by many different kinds of applications. Sometimes you will be surprised to know that a device that does not fit into the HID paradigm, connects to the PC using HID class. I saw some initial mobile phones connecting the PC on USB using HID class. You will also find many industrial control applications, that connect to PC uses HID class. You will not know that those devices are HID devices, because the INF(Microsoft Windows Information) file tells otherwise.
Initially the HID specification is designed with the intention to support, PC devices like keyboard, mouse, joystick etc... Because these devices fall in the category of Human Interface for the PC.
But, later HID has expanded it's reach. The HID section(See Article Related Resources) on www.usb.org has grown to huge segment. One book that covers HID to the core is USB Complete

2. Benefits of using HID device in your application

HID is almost support by all operating systems, including versions of Microsoft Windows starting from Windows 98 SE, and all most all Linux versions. What it means to you as a USB device developer is, you don't have put effort on developing OS specific device drivers. These device drivers are already available for your use. Well, If you are not developing Mouse, Joystick or Keyboard, then there is some work you have to do on PC side too, but not at the kernel level of the OS.

3. How to interact with any HID device on Windows

Once you are have your HID firmware stack ready, and your device is viewed as HID device by the OS, you can use the two standard API provided by Windows to interact directly with the HID device.

1. Windows API functions - supplied by the HID.DLL file.
2. Microsoft DirectX® - which provides faster, more direct access to the hardware (USB device).

4. How to interact with any HID device on Linux

Still reading! Hoping to finish it soon! :-)

5. Major concepts of HID

1. While using HID, the class specification defines an entity called Reports. A HID Report is nothing but the data exchange format defined by the HID speciation. NOTE: User can also add his own report formats. Each report is identified by a Report Descriptor.
   The host sends and receives data by sending and requesting reports in control or interrupt transfers. The report format is flexible and can handle any type of data.
   So, when designing the device, the firmware need to be designed by keeping the standard Report formats in mind, as well as per the requirement new report formats may have to be defined.
   
   
2. Each transaction can carry only small or moderate amounts of data, as only Interrupt transfer is supported on HID class devices. That mans Bulk, and Isochronous transfers are not supported on HID Class.
   A low speed device can transfer maximum of 8 bytes per transaction.
   A full speed device can transfer maximum of 64 bytes per transaction.
   A high speed device can transfer maximum of 1024 bytes per transaction.
   A long report can use multiple transactions.
   A device may send information at unpredictable times, well again because it uses interrupt transfer the latency is maintained as in interrupt transfers the host polls the device periodically.
   
   
3. Many HID devices mostly send data to host, but HID specification allows devices to receive data from host. This helps in control applications, or those applications where the device need information from host for it's operations.
   
   
4. Any device that can technically follow the HID class specification (sending & receiving data at the data rates specified for HID) can be implemented as a HID device. Some examples are Bar-code readers, Thermometers, Voltmeters and are even included in the HID specification as examples of HID devices :-). These devices mostly send data to the host computer.
   Similarly devices like Remote displays, robots or devices of any kind that receive occasional or periodic commands can also be HID devices.
   
   
5. The HID can be implemented as one the multiple USB interfaces supported by a device. For example a video display may have a HID interface for software control of brightness, contrast etc.., while a conventional Video Class interface to manage the display.
   Another example is a USB speaker system, where volume can be controlled using HID, and the Audio class interface allows actual Audio data transfer.
   
   
6. Two important documents for working with HIDs are "Device Class Specification for Human Interface Devices" and "HID Usage Tables".
   
   

This concludes the article on HID class.

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..

USB Basics - Part I (What actullay is USB?)

This article is part of a series of articles that explain USB from the standpoint of a software/firmware developer. USB has become a defacto standard in the PC world. And it is replacing the older buses like RS-232, ISA and Parallel ports at faster pace. Apart from this USB is becoming more available, like USB On The Go(USB-OTG) and Wireless USB. Which means that both embedded system developers as well as PC application developers need to understand on how to use this new bus architecture in their development activities. As per the USB Specification 2.0 the motivation for developing USB came from three interrelated considerations. They are connecting PC to telephone, Ease-of-use and Port expansion. USB met all these 3 considerations and it not only able to connect the PC to telephone, but it also allowed lot of new devices to be created and lot of existing applications to be migrated to it architecture. The primary advantage of USB is the ease-of-use. This is accomplised by incorporating plug & play and hot plugging mechanisms into the architecture. These features have lead to the conversion of many existing applications which use the legacy parallel ports and serial ports to USB. The USB Specification came in two revisons. The first release is called USB 1.1 and the second release is called USB 2.0. These specifications can be downloaded from www.usb.org. www.usb.org is the implementars forum of USB and it responsible for maintaining the USB specification. This web site also maintains links to various developer resources, a frequently ask questions section etc. The USB 2.0 specification is released in year 2000 and subsequently some errata documents are added. USB 1.1 has support for two different speeds of operation namely Low-Speed USB and Full-Speed USB. The USB 2.0 specification added another speed to the specification which is called as High-Speed USB. What this means to a developer is that, when a USB device is developed, it can operate at 3 different data transfer rates depending the device requirement. For exmample, if the USB device developed is lets say a Mouse device. The Mouse normally does not transfer large quantities of data, also in a second it may just transmit few bytes of data. Then it can work in Low-Speed USB. If there another device like let's say a data acquisition system which need to transmit data at higher rate as compared to Mouse, then it can use the Full-Speed USB operation which can do approximately 1 MB/s. If the device is something like disk drive,then the device may use High-Speed USB which can do approximate 480 Mb/s. So, if we take an anology with RS-232, like how RS-232 supports various baud rates, USB also supports 3 speeds of operation. Apart from USB has another feature also, which different from how RS-232 works. It supports 4 types of transfers, namely Control Transfer, Interrupt Transfer, Bulk Transfer and Isochronous Transfers. Depending on the application's requirement the USB device developer need to choose the required transfer types. In USB each transfer type is mechanism which dectates how and what kind of the data is packed and transmitted over the USB bus. Control Transfer: It is primarily used during intiling the device or configuring the device. USB devices support plug & play mechanism, which is nothing but auto detection and auto configuration. The USB device transmits certain information about itself as per the specificaiton to the PC to which this device is connected through the mechanism called control transfer. Interrupt Transfer: This mechanism is used for tranmitting the actual data over the bus. The speciality of this transfer type is, the integraty of data is varified and maintained. Also, the data is transmitted in real time with accuracy. In this transfer type the amount of data that can be transmitted per second is limited. Again tipical applications are those which require integraty and timeliness. Mouse device is a good example which use this transfer. Bulk Transfer: This mechanism is again used for transmitting the actual data. In this case the timeliness of data is not maintained, but integraty is maintained. So, applications like printers which requires correct data but which can neglect small delays in data arraival can use this transfer. As the name indicates this transfer type can transfer large quantities of data depending the speed of operation. Isochronous Transfer: This mechanism is again used for transmitting the actual data. In this case timeliness is maintained during data transfer. But, integraty will not checked. So, applications like streaming audio devices, video cameras etc.. can use this tranfer type for real time transfer of the data. The following table shows how each transfer type is supported in each speed of operation. Speed of Operation Transfer Type Low Speed Full Speed High Speed Control Transfer Supported @ 24 KB/sec Supported @ 832 KB/sec Supported @ 15,872 KB/sec Interrupr Transfer Supported @ 800 bytes/sec Supported @ 64 KB/sec Supported @ 24,576 KB/sec Bulk Transfer Not Supported Supported @ 1,216 KB/sec Supported @ 53,248 KB/sec Isochronous Transfer Not Supported Supported @ 1,023 KB/sec Supported @ 24,576 KB/sec The above table shows what are the real speeds a device can achieve with a specific speed configuration and with a specific transfer type. But the one thing to be noticed is the specification mentions a much higher speed value for for each speed of operation. And it may look like a discripency. But one important aspect of USB bus is Port expansion. This means that the same bus is used by multiple devices. In USB terminology these devices are called as Peripherals. So, when the specification mentions a speed for a particular speed of operation, it is mentioning the maxmum amount of data that can be transmitted in a specified time by all the device on the bus which are using a specific speed of operation. Again, as we saw the atual speed depends on transfer type also. The USB bus architecture diagram will look something like this. In the diagram you might have observed 4 important components. 1. Host: The host is the PC or the device which has the maximum processing power with features to control peripheral buses like USB. 2. Host Controller & Root Hub: The Host controller is the device responsible for controlling the USB bus. And the Root Hub is a HUB device which will/can extend the bus. If you see 2 USB ports on a computer the there is a possibility that only one Root Hub is there. If you see more than 4 USB ports on a computer then there is a possibility that it has 2 Root Hubs and Two Host controllers connected to the Host System. 3. Hub: A device that will extend the bus and provide channels(USB Ports) to which more number of devices can be connected. 4. Peripherals: The actual USB device which will use various transfer types and speed of operation. The USB protocol is a host controlled protocol. We will see what this means in the up coming articles. So, this article introduced you to USB, what types of speeds available and how the architecture looks like.

Test Post

My comvcon domain ceased to exist and somebody else have already registered before I took notice. So I am posting those articles here.