In Part I, we reviewed the history of USB, going over some of the communication advantages of USB over RS-232, and then touching on the various USB data transfer protocols. USB is a somewhat complex communications protocol but like many things, if you take it one step at a time, it can be digested. In this issue, we will recap some of the basics as well as get into more of the details involving the Windows drivers and their requirements. Also, we will go over some of the capabilities, shortcomings, and limitations of USB. Again, we are covering here the USB 1.x spec dealing with the low speed 1.5Mbps and high speed 12Mbps transfer rates. USB 2.0 devices (480Mbps rates) are not expected to have support from Windows until late 2001.
USB came into existence because of the need for interfacing a number of relatively fast peripherals to host systems such as a personal computers. Many peripherals must be installed inside the computer. In the past, just about the only way to add a new device to a computer was to turn off the power, remove the cover from the computer, find an empty PCI or ISA slot in which to install a 'printed circuit card', install the new card, replace the computer cover, turn the power back on, get the computer to install the driver(s) for the card, and hope that the computer system still works properly after your efforts. Many of today's computer systems only have 2 or 3 'spare' slots for new PC cards which can be a big limitation for some folks. Also, with PCI bus, there are limitations where some PC card slots share interrupts, and some card slots cannot be used with a PCI bus mastering card installed in them. As many PCI cards these days do have bus mastering built into them, these cards often will not work in those particular card slots. Theoretically, with USB you can install up to 127 different devices per USB port. Most PCs have 2 USB ports yielding up to 254 devices connected to a single PC! In reality, it can get a little sloppy on your desktop with this many USB devices, cables, and the hubs taking up room. Also, if you try this route you are probably going to run up against USB bandwidth limitations ...
A USB industrial touchpad module fromCirque Manufacturing
You cannot connect two computers directly together for communications purposes using a USB connection. However, you can hook two computers together using a peripheral called a USB bridge, also known as a USB to USB adapter. USB is not intended to be used like a LAN, so if you need to connect up two or more PCs together, you need to use Ethernet or something equivalent. If you need to connect USB devices to a host farther away than the maximum cable length of 3 meters for low speed (1.5Mbps) USB or 5 meters for high speed (12Mbps) USB, you will need to use hubs to extend the connection distance up to a maximum of 25 meters (5 hubs maximum, with 5meter cables between each hub).
When a device is added to a USB port, Windows on the PC side recognizes the connection and adds the proper previously installed driver to support the device. Many hardware devices that are plugged into the PC's USB port need to have a specialized driver written to support the device. Also, in some cases, specialized software applications will need to be supplied with the device to make it functional on the PC.
USB Driver Development
There are at least a couple of ways to get drivers that Windows can use for communications with a USB device: you can 'roll your own,'or you can make use of a set of USB drivers that the newer versions of Windows have included either on the Windows CD or that are available from resources such as those included in the Win DDK. Device descriptors inside each USB device contain information that Windows needs to know about the device before it can be used. Descriptors for a minimal device are mentioned below.
Windows Supplied Drivers
There is a set of drivers included in the newer versions of Windows that support certain devices called 'human interface devices' or HIDs. These devices include keyboards, mice, game controls, remote controls, and joysticks. In general, these devices don't require a great deal of data to be transferred to or from the host computer. The firmware inside these peripheral devices must support the Windows HID protocol if you want to use the existing HID drivers. The data that is transferred to and from these devices to the computer are called reports. Using HID, transactions can contain up to 64 bytes of data per transfer in high speed mode and 8 bytes of data in low speed mode using the HID drivers. Maximum speed of data transfer is also limited. A high speed device can only transfer 64K bytes per millisecond and a low speed device can only transfer 800 bytes per 10 milliseconds. Also, HID uses the control and interrupt pipes for data transfers (see our first article on USB for a discussion of this topic) which the USB protocol defines. As a result, HIDdoes not guarantee timely data transfer. If you need data to be delivered at a certain critical time, HID is probably not the way to go. As usual, the computer is the host and initiates all transfers. Even with these limitations, if you only require low volume data transfers, you can save a bit of time by using the Window HID-supplied drivers instead of writing your own software drivers.
A fairly rigid protocol must be adhered to when using the HID drivers with your device. Windows needs to determine which driver to load into memory to support a particular device that has been inserted into the USB port. It does this by issuing what is called a Get_Descriptor command to the device. What is returned to the PC host from the device is a block of information that tells the PC certain facts regarding its operation such as what class the device is, the number of logical interfaces it has, the size of its endpoints (data buffers), the vendor ID, product ID, and possibly serial number information. It is the class information that determines whether Windows can use its existing HID drivers.
After the Windows device drivers have been installed and the devices are connected to the host's USB port, Windows uses the Windows Device Manager to determine which USB driver to use with which device. It makes this decision based on a user-supplied .INF file that contains information such as manufacturer and product data, if the device is a non-HID device. If it is a HID device, it will use the .INF file named hiddev.inf for information on the device. This file also contains information that will be added to the registry once the device has initially been installed in Windows. Windows then uses data from all the .INF files (located in the \Windows\INF directory which is normally hidden) to catalog the data into two files named drvdata.bin and drvidx.bin for quick access to the proper .INF files to retrieve data for a particular device. If you do change the data inside an .INF file, you must go through a specific procedure to get Windows to change the entry for the device in the registry by using the Device Manager or else the changes will not be made when you expected them to. An .INF file has a format similar to the familiar .INI file.
User Supplied Drivers
If you cannot live with the limitations that the Windows HID driver imposes on you, you will need to write your own Windows drivers to communicate with your USB device. This can get quite involved and you may need to have access to several additional tools.
As discussed in the previous article, you will need to determine your devices' data transfer requirements -- such as which data transfer formats that you require for its use. You can have one or more of these data transfer formats identified in your device. Control mode is needed as a minimum for all USB devices for the query and setup of your device with Windows. If any of the following modes are required, Control mode also needs to be included. If data accuracy is important, you will need to use bulk mode, but you will need to give up guaranteed timing of data delivery as USB tends to give bulk mode its lowest priority. Bulk mode transfer is only available in high speed mode and includes error checking. If guaranteed timing of data delivery is more important than data accuracy, then you need to use isochronous mode of transfer. Isochronous mode transfer is also only available in high speed mode. You need to sacrifice one primary need for the other in these cases, i.e., transfer rate verses accuracy. If you need to be 'serviced' from the host at irregular intervals, you can use interrupt mode where the host will query you at regular intervals to see if you have an 'interrupt' pending to the host. You cannot interrupt a host in the usual sense, as it needs to ask you if you have anything pending. The host initiates almost all transfers except for remote wakeup.
Windows drivers typically 'isolate' applications from the details of the physical and logical aspects of the data transfer protocols. Much of the handshaking used is not seen by the application program, and neither is the structure of the packets and error checking. Drivers are seen as 'layered' between the hardware and the application program. You can use existing Windows drivers and write a mini-driver which adds to the capabilities of the existing driver. There is also a generic driver that is available called bulkusb.sys that can be used as a starting point for performing bulk mode transfers. Windows allows drivers greater privilege than applications programs by letting them have unrestricted access to system resources using IRPs (I/O request packets) to communicate with the lower level Windows USB drivers. Applications, which use the Win API to communicate with Windows, run in user mode while the drivers can run in kernel mode.
Communication Modes
There is a strict structure when using USB as a communications medium. After a device has been detected by the host, its device descriptors have been read, and it has been enumerated and assigned a handle by Windows, then an adherence to the set mode of communication mode must be kept. The control mode is the initial point of contact between the host and the connected device. Control mode in addition may be used for very limited user data volume between the host and the device. It is here where the host determines the device's setup such as communications modes, IDs, and general configuration. Control mode is the most complex mode of the four communication modes and has quite a bit of overhead on top the actual data transfers. There are many packets of data initiated by the host in this mode to the device and also packets of data are sent back by the device in response to the host. There are also several stages of communication such as Setup, Data, and Status stages, all which are structured. There are a total of eleven different USB standard requests in control mode where the host can set or get various parameters from the device. The USB standard also allows vendors to define their own additional requests in addition to the eleven provided.
The other three communication modes are generally used for user data transfer between the host and the host's connected devices. The basic 'gives' and 'takes' between these different modes has already been discussed above. Obviously, if you are using a custom Windows driver to communicate with a device, the device's firmware must be written to support the communication modes of the driver. It is imperative that good documentation be kept to document the different communication modes or the software and firmware development could get pretty 'outta whack' especially when working in a larger team project. The USB bus drivers that come with Windows are based on the WDM (Win32) drivers, and drivers written for your device should also be written based on the same WDM model. Remember, there are 'layers' of these drivers communicating with each other as well as the 'top' layer driver communicating with the application and the 'bottom' layer driver communicating with the USB hardware itself. Each driver has a limited set of tasks that it performs in conjunction with other drivers that also have assigned tasks.
Also remember that hubs need to be involved in the communication chain. They also have their internal firmware 'smarts' to make various decisions such as when to disconnect a downstream device that is not behaving properly. There is a hub driver within Windows that is used in the above-mentioned 'layers' that does the direct communication with the downstream hubs and also handles the enumeration. The USB bus-class driver assumes the responsibility of hub driver and the host-controller driver. It is this host-controller driver that does the direct communication with the hardware. You can see how the different tasks that are defined in the USB protocol are assigned the different tasks. When an application closes or no longer needs a USB device, it closes the device's Windows assigned handle to free up limited system resources -- which is imperative in Windows applications.
Tools
There are some software tools available from the USB.org Developer's section of the USB Implementer's Forum to help verify your software. USBComp.exe, available from http://www.usb.org/developers/developers/tools/, contains a series of several test programs that allow you to check out your device to see how it functions when connected to USB, whether you're using HID or your own Windows driver. This at present is only for computers running under Windows 2000. In particular, have a look at USBCheck which is included in USBComp.exe. There also are several USB protocol analyzers available which will allow you to see all traffic on the USB port. Using one of these is probably the best way to assist you in the development stages as well as thoroughly checking the operation of your device. As always, you can download the latest USB specs and current important documentation from http://www.usb.org/developers/docs/.
We have covered quite a bit regarding the basics of USB in these two articles. There are more details available at the USB Implementer's Forum web site that was mentioned above. Also, the web has many other resources to help educate you further on USB or provide USB development tools available for either lease or purchase. Be sure to check out SSS Online's USB Links information for more information and listings of some of these sites. At Pegasus / SSS-OnLine, we strive to help you with all your communication needs!
Sunday, February 14, 2010
Serial Bus (USB)
Part 1
With increasing use of the Internet, cellular telephones, and communications in general, communications interconnectivity has been growing at a rate that no one could have imagined five years ago. As a result, problems have arisen in the wireless industry related to limited bandwidth as well as connections to "wired" devices. The RS-232D standard has been a staple in "wired" communications for a number of years. Generally, this standard limits the rate of communication speed to 115,000 bps, which is not adequate for today's technology. Also, RS-232 does not allow daisychaining multiple devices that are attached to one main device, unless a special design is implemented for the purpose.
Of the many new serial protocols that have popped up in response to these problems, USB (Universal Serial Bus) currently seems to be reigning supreme. One of the reasons that USB was implemented was to replace existing serial and parallel ports on computers. USB has several advantages for this application, which is why it has been included in most of the new PCs that have been shipped since Windows 98 was released in late June of 1998:
* It uses a much higher data transfer rate than many common serial data formats.
* It allows a large number of devices to be attached to a single host USB connector. Up to 127 devices can theoretically be used on a single USB port, but realistically this could cause bandwidth problems and other potential complications.
* It simplifies the connection to external devices. USB supports "plug and play" -- the operator does not need to be heavily involved in the set-up process. When a device is connected to a host's USB bus, it is immediately recognized by the host, dynamically enumerated, and assigned an address by the host. Once the host knows what kind of device has been plugged into it, it interrogates the device to understand how to communicate with it. While a device driver needs to be loaded on the host PC, some operating systems have "generic" drivers embedded in them that will work for some common USB devices such as keyboards.
USB Specifications and Operating Program Support
USB Implementers Forum, Inc. is a non-profit corporation formed by a group of companies that developed the initial USB specification. Among their activities is the development of a testing and certification program for compliance with the USB specification. Before a device can use the USB logo or icon, it must undergo rigorous testing and be certified as USB compliant.
While this compliance testing goes a long way toward ensuring device compatibility, there are no guarantees, however, that all USB certified devices will be able to work together compatibly over a particular USB bus. This is not only because of differences in interpreting and implementing the USB standard and failure by some manufacturers to adhere to the standards, but also because of the rapid development of technology itself. For example, because of the limited bandwidth of the USB 1.x standard, care must be exercised when combining devices compliant with that specification where data receipt is time-sensitive -- such as several devices on one bus that all transfer video simultaneously.
There are several different editions of the USB standard that have been released:
* USB 1.0, the first edition, was released in January 1996. It supported 1.5 Mb/s (low speed) and 12 Mb/s (high speed) transfer rates. Note that this is Megabits per second and not MegaBytes per second -- a common misunderstanding. A percentage of this data rate is reserved for USB protocol overhead, so the actual data transfer is less than the indicated speed. How much less depends on the transfer type and the packet sizes.
* USB 1.1 was released in September 1998. This edition fixed many of the problems in release 1.0.
* USB 2.0 was released in early 2000 and has increased the maximum transfer speed by a factor of 14 up to 480 Mb/s! USB 2.0 is backwards compatible with USB 1.x. Although the USB 2.0 specification has been released, operating programs for personal computers are not expected to have USB 2.0 support until about the fourth quarter of 2001. A few peripherals supporting USB 2.0 have already begun to show up on the market in late 2000.
Windows 95 (and earlier versions of Windows) has no USB support. A sub-release of Windows 95 (OEM Service Release 2) was issued to computer manufacturers only and it added somewhat limited support for the USB protocol. Windows 98 added additional support and fixed some problems that were in the 95 OEM Service Release 2. Windows 98se (98 second edition) released in early June of 1999 had more robust support for USB. Both Windows 2000 and Windows Me released in early 2000 added additional features. Apple Computer's OS 9.0.4 was released late summer of 2000 and added much better support for USB for the Mac. Many problems associated with USB can be solved by using the latest version of the appropriate operating system.
In this article, the term USB includes all the above revisions as a general protocol. However, the operating details described below refer to USB 1.x (both USB 1.0 and 1.1) unless otherwise specified. Also, when a "device" is mentioned here, it is referring to a USB-compliant peripheral.
How USB Works: an Overview
USB uses a four-wire cable interface. Two of the wires are used in a differential mode for both transmitting and receiving data, and the remaining two wires are power and ground. The source of the power to a USB device can come from the host, a hub, or the device can be "self powered." There are two different connector types on each end of a USB cable. One of these connectors is for upstream communications, and the other for downstream. Each cable length is limited to about 5 meters.
USB has four types of communication transfer modes:
* control,
* interrupt,
* bulk, and
* isochronous.
Control mode is initiated by the host. In this mode, every data transfer must send data in both directions, but only in one direction at a time. The control mode is used mainly for initialization of devices, but it can also be used to transfer small amounts of data.
In interrupt mode, interrupts do not occur in the usual sense. As in control mode, the host has to initiate the transfer of data. Interrupt mode works by the host querying devices to see if they need to be serviced.
Bulk mode and isochronous mode complement each other in a sense. Bulk mode is used when data accuracy is of prime importance, but the rate of data transfer is not guaranteed. An example of this would be disk drive storage. Isochronous mode sacrifices data accuracy in favor of guaranteed timing of data delivery. An example of this would be USB audio speakers.
These four modes will be discussed in more detail below.
USB sockets
Above is an example of USB ports found on PCs and on some USB peripherals including keyboards and monitors. (Thanks, USB Forum, for this picture!)
The PC host typically has connections for two external USB ports. Each of these two connectors on the PC is actually a connection to a separate root hub inside the PC. If either of the two root hubs needs to have more than one device connected to it, a downstream USB hub is required to expand connections. Hubs are used to add to the number of devices that can be connected to one USB port. They can be considered to be a repeater of sorts and also a controller. When a device is connected downstream of a hub, the hub does the connect detection of the new device and notifies the host.
Hubs can be inside the device itself -- for example, in a keyboard that may have an additional two downstream USB connectors for additional devices. A hub can have a combination of high and low speed devices connected to it, up to a maximum of four additional hubs downstream from itself. A hub's upstream port to the PC must be high speed. The hub acts as a traffic cop, handling communication to downstream devices as either high or low speed. A hub can ignore a downstream device that is not behaving properly. Hubs can be either self-powered or receive power from the USB bus. USB 1.x hubs support both low and high-speed data transfers.
There are several hardware requirements for devices that are placed on the USB bus. Five volts is the nominal supply voltage on the bus. A device that requires 100mA or less can be powered from the host or any hub, provided that the total available power hasn't already been exhausted by other devices. A device on the bus can draw up to 500mA from it. However, not all USB hosts (especially a battery powered PC) or bus-powered hubs will allow a device to draw more than 100mA from the bus. For this reason, a USB device that draws more than 100mA should, in most cases, be self-powered .
A device tells the host how much current is required for its operation. Self-powered devices usually get their power from a separate power supply or batteries. A battery-powered device plugged into the bus can get its power from the bus if it meets the tests above, and it can then switch back over to battery power when it is disconnected from the bus or when the host is shut down. When a device is in suspend mode, it cannot draw any more than 500uA from the bus if it is bus-powered. Also, if a device has not seen any activity on its bus in 3 mS, it needs to go into suspend mode. A host can initiate a resume command to a device that is in suspend mode. A device can also issue a remote wakeup to an inactive host to make it active.
All devices have endpoints, which are memory buffers. An endpoint can be as simple as an addressable single register, or it can be a block of memory that is used to store incoming and/or outgoing data. There may be multiple endpoints inside a device. Each device has at least one endpoint -- "endpoint 0"-- which is used as a control endpoint. It must be able to both send and receive data, but can only communicate in one direction at a time. Typically, when a device receives data such as an Out or Setup command from the host, this data is stored in the endpoint and the device's microprocessor is interrupted and works on this data. When a device receives an In command that is addressed to it from the host, data for the host that is stored in the endpoint is sent to the host.
The host is considered to be the master in most all cases. One exception is when a device issues a remote wakeup to the host as discussed above. There are time limits for both the host and device to respond to each other. For example, if the host requests data from a device using an In command, the device must send the data back to the host within 500mS, in some cases. Depending on the transaction type, the host and/or the device may respond to data received with an acknowledgement. Data transfer involves quite a bit of error-checking and handshaking. The different types of data packets sent and received use different ways to verify correct data transfer.
A logical connection link needs to be set up between the host and a device before a transaction can occur. This connection is referred to as a Pipe. It is set up as soon as possible after a host has recognized a device as being connected. When the host responds to a connect signal from the device, one of the parameters that is sent to the host is the device's required data transfer type and speed. The host can refuse to establish a Pipe if the host does not have enough bandwidth to support the device's request or if its power requirements cannot be met. The device at its discretion can lower its requested data rate and try again until the host accepts it and initiates a Pipe.
When a device is connected, it also sends to the host descriptor information on the types of endpoints in the device, the type of data transfer it uses, size of data packets, endpoint addresses within the device, and if used, the time required between data transfers.
The following describes a typical data flow for a device when it is initially plugged into a host's bus while the host is active. Remember here that the host has an internal USB hub, and additional hubs may be connected downstream from the host's hub.
1. The host recognizes that a device has been attached to one of its USB hubs. It realizes this by a simple resistive divider that is connected to the differential data pair of wires in the USB bus. These resistors are inside the USB hubs and devices.
2. The host sends a Get_Port_Status request to the hub to find out more about what has been plugged in. It could be another hub, a device connected directly to the host hub, or a device that has been plugged into one of the downstream hubs.
3. After receiving a response from the hub, the host issues a Set_Port_Feature command in which the hub issues a reset over the data pair but only to the newly connected device on the USB bus.
4. The host then checks to see if the device has come out of the reset state by issuing a Get_Port_Status command to the hub. After reset, the device is in the Default state and can only draw a maximum of 100mA. In Default state, the device can communicate with the host through Endpoint 0.
5. The hub now detects the device's speed by using the resistive dividers that are attached to the USB bus. The hub sends the speed of this device back to the host.
6. The host then sends a Get_Descriptor command to the hub in which the hub gets the packet size needed from this particular device and sends the result back to the host.
7. The host now issues a Set_Address command to the hub which sends this information to the device. The device in turn acknowledges the command back through the hub to the host and sets up this address internally.
8. To learn more about this device, the host sends a Get_Descriptor command to the address that the device has been given. The information that is returned to the host consists of various details of the device that the host needs to know for its operation. These queries by the host continue two more times to retrieve all the information needed.
9. Based on the information received from the device, the host determines the best device driver to use for communications with it.
10. The device driver in the host now takes over by requesting a Set_Configuration command. There can be several configurations for one device, and the device driver determines which to use based on information received from the device in response to the Get_Descriptor command.
11. The device is now ready for use.
As you can see, the USB protocol is a fairly complex arrangement. This strict pattern of query and response, however, is important in alleviating potential conflicts on the bus.
With increasing use of the Internet, cellular telephones, and communications in general, communications interconnectivity has been growing at a rate that no one could have imagined five years ago. As a result, problems have arisen in the wireless industry related to limited bandwidth as well as connections to "wired" devices. The RS-232D standard has been a staple in "wired" communications for a number of years. Generally, this standard limits the rate of communication speed to 115,000 bps, which is not adequate for today's technology. Also, RS-232 does not allow daisychaining multiple devices that are attached to one main device, unless a special design is implemented for the purpose.
Of the many new serial protocols that have popped up in response to these problems, USB (Universal Serial Bus) currently seems to be reigning supreme. One of the reasons that USB was implemented was to replace existing serial and parallel ports on computers. USB has several advantages for this application, which is why it has been included in most of the new PCs that have been shipped since Windows 98 was released in late June of 1998:
* It uses a much higher data transfer rate than many common serial data formats.
* It allows a large number of devices to be attached to a single host USB connector. Up to 127 devices can theoretically be used on a single USB port, but realistically this could cause bandwidth problems and other potential complications.
* It simplifies the connection to external devices. USB supports "plug and play" -- the operator does not need to be heavily involved in the set-up process. When a device is connected to a host's USB bus, it is immediately recognized by the host, dynamically enumerated, and assigned an address by the host. Once the host knows what kind of device has been plugged into it, it interrogates the device to understand how to communicate with it. While a device driver needs to be loaded on the host PC, some operating systems have "generic" drivers embedded in them that will work for some common USB devices such as keyboards.
USB Specifications and Operating Program Support
USB Implementers Forum, Inc. is a non-profit corporation formed by a group of companies that developed the initial USB specification. Among their activities is the development of a testing and certification program for compliance with the USB specification. Before a device can use the USB logo or icon, it must undergo rigorous testing and be certified as USB compliant.
While this compliance testing goes a long way toward ensuring device compatibility, there are no guarantees, however, that all USB certified devices will be able to work together compatibly over a particular USB bus. This is not only because of differences in interpreting and implementing the USB standard and failure by some manufacturers to adhere to the standards, but also because of the rapid development of technology itself. For example, because of the limited bandwidth of the USB 1.x standard, care must be exercised when combining devices compliant with that specification where data receipt is time-sensitive -- such as several devices on one bus that all transfer video simultaneously.
There are several different editions of the USB standard that have been released:
* USB 1.0, the first edition, was released in January 1996. It supported 1.5 Mb/s (low speed) and 12 Mb/s (high speed) transfer rates. Note that this is Megabits per second and not MegaBytes per second -- a common misunderstanding. A percentage of this data rate is reserved for USB protocol overhead, so the actual data transfer is less than the indicated speed. How much less depends on the transfer type and the packet sizes.
* USB 1.1 was released in September 1998. This edition fixed many of the problems in release 1.0.
* USB 2.0 was released in early 2000 and has increased the maximum transfer speed by a factor of 14 up to 480 Mb/s! USB 2.0 is backwards compatible with USB 1.x. Although the USB 2.0 specification has been released, operating programs for personal computers are not expected to have USB 2.0 support until about the fourth quarter of 2001. A few peripherals supporting USB 2.0 have already begun to show up on the market in late 2000.
Windows 95 (and earlier versions of Windows) has no USB support. A sub-release of Windows 95 (OEM Service Release 2) was issued to computer manufacturers only and it added somewhat limited support for the USB protocol. Windows 98 added additional support and fixed some problems that were in the 95 OEM Service Release 2. Windows 98se (98 second edition) released in early June of 1999 had more robust support for USB. Both Windows 2000 and Windows Me released in early 2000 added additional features. Apple Computer's OS 9.0.4 was released late summer of 2000 and added much better support for USB for the Mac. Many problems associated with USB can be solved by using the latest version of the appropriate operating system.
In this article, the term USB includes all the above revisions as a general protocol. However, the operating details described below refer to USB 1.x (both USB 1.0 and 1.1) unless otherwise specified. Also, when a "device" is mentioned here, it is referring to a USB-compliant peripheral.
How USB Works: an Overview
USB uses a four-wire cable interface. Two of the wires are used in a differential mode for both transmitting and receiving data, and the remaining two wires are power and ground. The source of the power to a USB device can come from the host, a hub, or the device can be "self powered." There are two different connector types on each end of a USB cable. One of these connectors is for upstream communications, and the other for downstream. Each cable length is limited to about 5 meters.
USB has four types of communication transfer modes:
* control,
* interrupt,
* bulk, and
* isochronous.
Control mode is initiated by the host. In this mode, every data transfer must send data in both directions, but only in one direction at a time. The control mode is used mainly for initialization of devices, but it can also be used to transfer small amounts of data.
In interrupt mode, interrupts do not occur in the usual sense. As in control mode, the host has to initiate the transfer of data. Interrupt mode works by the host querying devices to see if they need to be serviced.
Bulk mode and isochronous mode complement each other in a sense. Bulk mode is used when data accuracy is of prime importance, but the rate of data transfer is not guaranteed. An example of this would be disk drive storage. Isochronous mode sacrifices data accuracy in favor of guaranteed timing of data delivery. An example of this would be USB audio speakers.
These four modes will be discussed in more detail below.
USB sockets
Above is an example of USB ports found on PCs and on some USB peripherals including keyboards and monitors. (Thanks, USB Forum, for this picture!)
The PC host typically has connections for two external USB ports. Each of these two connectors on the PC is actually a connection to a separate root hub inside the PC. If either of the two root hubs needs to have more than one device connected to it, a downstream USB hub is required to expand connections. Hubs are used to add to the number of devices that can be connected to one USB port. They can be considered to be a repeater of sorts and also a controller. When a device is connected downstream of a hub, the hub does the connect detection of the new device and notifies the host.
Hubs can be inside the device itself -- for example, in a keyboard that may have an additional two downstream USB connectors for additional devices. A hub can have a combination of high and low speed devices connected to it, up to a maximum of four additional hubs downstream from itself. A hub's upstream port to the PC must be high speed. The hub acts as a traffic cop, handling communication to downstream devices as either high or low speed. A hub can ignore a downstream device that is not behaving properly. Hubs can be either self-powered or receive power from the USB bus. USB 1.x hubs support both low and high-speed data transfers.
There are several hardware requirements for devices that are placed on the USB bus. Five volts is the nominal supply voltage on the bus. A device that requires 100mA or less can be powered from the host or any hub, provided that the total available power hasn't already been exhausted by other devices. A device on the bus can draw up to 500mA from it. However, not all USB hosts (especially a battery powered PC) or bus-powered hubs will allow a device to draw more than 100mA from the bus. For this reason, a USB device that draws more than 100mA should, in most cases, be self-powered .
A device tells the host how much current is required for its operation. Self-powered devices usually get their power from a separate power supply or batteries. A battery-powered device plugged into the bus can get its power from the bus if it meets the tests above, and it can then switch back over to battery power when it is disconnected from the bus or when the host is shut down. When a device is in suspend mode, it cannot draw any more than 500uA from the bus if it is bus-powered. Also, if a device has not seen any activity on its bus in 3 mS, it needs to go into suspend mode. A host can initiate a resume command to a device that is in suspend mode. A device can also issue a remote wakeup to an inactive host to make it active.
All devices have endpoints, which are memory buffers. An endpoint can be as simple as an addressable single register, or it can be a block of memory that is used to store incoming and/or outgoing data. There may be multiple endpoints inside a device. Each device has at least one endpoint -- "endpoint 0"-- which is used as a control endpoint. It must be able to both send and receive data, but can only communicate in one direction at a time. Typically, when a device receives data such as an Out or Setup command from the host, this data is stored in the endpoint and the device's microprocessor is interrupted and works on this data. When a device receives an In command that is addressed to it from the host, data for the host that is stored in the endpoint is sent to the host.
The host is considered to be the master in most all cases. One exception is when a device issues a remote wakeup to the host as discussed above. There are time limits for both the host and device to respond to each other. For example, if the host requests data from a device using an In command, the device must send the data back to the host within 500mS, in some cases. Depending on the transaction type, the host and/or the device may respond to data received with an acknowledgement. Data transfer involves quite a bit of error-checking and handshaking. The different types of data packets sent and received use different ways to verify correct data transfer.
A logical connection link needs to be set up between the host and a device before a transaction can occur. This connection is referred to as a Pipe. It is set up as soon as possible after a host has recognized a device as being connected. When the host responds to a connect signal from the device, one of the parameters that is sent to the host is the device's required data transfer type and speed. The host can refuse to establish a Pipe if the host does not have enough bandwidth to support the device's request or if its power requirements cannot be met. The device at its discretion can lower its requested data rate and try again until the host accepts it and initiates a Pipe.
When a device is connected, it also sends to the host descriptor information on the types of endpoints in the device, the type of data transfer it uses, size of data packets, endpoint addresses within the device, and if used, the time required between data transfers.
The following describes a typical data flow for a device when it is initially plugged into a host's bus while the host is active. Remember here that the host has an internal USB hub, and additional hubs may be connected downstream from the host's hub.
1. The host recognizes that a device has been attached to one of its USB hubs. It realizes this by a simple resistive divider that is connected to the differential data pair of wires in the USB bus. These resistors are inside the USB hubs and devices.
2. The host sends a Get_Port_Status request to the hub to find out more about what has been plugged in. It could be another hub, a device connected directly to the host hub, or a device that has been plugged into one of the downstream hubs.
3. After receiving a response from the hub, the host issues a Set_Port_Feature command in which the hub issues a reset over the data pair but only to the newly connected device on the USB bus.
4. The host then checks to see if the device has come out of the reset state by issuing a Get_Port_Status command to the hub. After reset, the device is in the Default state and can only draw a maximum of 100mA. In Default state, the device can communicate with the host through Endpoint 0.
5. The hub now detects the device's speed by using the resistive dividers that are attached to the USB bus. The hub sends the speed of this device back to the host.
6. The host then sends a Get_Descriptor command to the hub in which the hub gets the packet size needed from this particular device and sends the result back to the host.
7. The host now issues a Set_Address command to the hub which sends this information to the device. The device in turn acknowledges the command back through the hub to the host and sets up this address internally.
8. To learn more about this device, the host sends a Get_Descriptor command to the address that the device has been given. The information that is returned to the host consists of various details of the device that the host needs to know for its operation. These queries by the host continue two more times to retrieve all the information needed.
9. Based on the information received from the device, the host determines the best device driver to use for communications with it.
10. The device driver in the host now takes over by requesting a Set_Configuration command. There can be several configurations for one device, and the device driver determines which to use based on information received from the device in response to the Get_Descriptor command.
11. The device is now ready for use.
As you can see, the USB protocol is a fairly complex arrangement. This strict pattern of query and response, however, is important in alleviating potential conflicts on the bus.
Oracle :::Complete info
- Enabling the information age
Oracle Corporation Overview:
Oracle Corporation is in the business of managing information. Oracle offers information solutions for businesses: how to manage information, ways to use it, solutions for sharing it, how to protect it.
Oracle is the world's largest enterprise software company, offering solutions for middleware, business intelligence, business applications, and collaboration.
Oracle company headquarters are located in Redwood Shores, CA (between San Jose and San Francisco). Oracle was founded in 1977 and now employs over 55,000 people worldwide.
Company Culture
Oracle is known in the technology industry as being very innovative and highly competitive. Much of the Oracle "campus" is designed around the fact that the employees there are expected to work long hours. There is a cafeteria, a fitness center, various cafes around the corporate headquarters and lots of on-site resources to make life easier.
Oracle Corporation (Nasdaq: ORCL) is the world's leading supplier of software for information management, and the world's second largest independent software company. With annual revenues of more than $10.1 billion, the company offers its database, tools and application products, along with related consulting, education, and support services, in more than 145 countries around the world. Headquartered in Redwood Shores, California, Oracle is the first software company to develop and deploy 100 percent internet-enabled enterprise software across its entire product line: database, server, enterprise business applications, and application development and decision support tools.
Oracle is the only company capable of implementing complete global e-business solutions that extend from front office customer relationship management to back office operational applications to platform infrastructure. Oracle software runs on PCs, workstations, minicomputers, mainframes and massively parallel computers, as well as on personal digital assistants and set-top devices. As more and more companies transform themselves into e-businesses, Oracle's Internet-enabled solutions provide a cost-effective way to expand market opportunities, improve business process efficiencies, and attract and retain customers. By replacing expensive, unwieldy client/server computing models with the efficiency and reach of the internet, companies can deploy a wealth of innovative applications that can be accessed with a Web browser.
The only software company to offer a full suite of e-business products, Oracle provides:
• An Internet-ready platform for building and deploying Web-based applications
• A comprehensive suite of Internet-enabled business applications
• Professional services for help in formulating e-business strategy, as well as in designing, customizing,
and implementing e-business solutions
Oracle: Past, Present and Future
The beginnings.
When CEO Lawrence J. Ellison and a few associates formed
Oracle in 1977, they were out to prove wrong the prevailing
theory that relationship databases could not be commercially
viable.
Larry Ellison, Bob Miner and Ed Oates found Software Development Laboratories. Inspired by a research paper written in 1970 by an IBM researcher titled " A Relational Model of Data for Large Shared Data Banks", the three decide to build a new type of database called a relational database system. Their orginal project is for the government and is titled Oracle. The founders believe that Oracle, meaning source of wisdom,
would be an appropriate name for their project and receive permission from the CIA to use it.
What's in a name?
In 1978, Software Development Laboratories moved from their office in Santa Clara to a new one on Sand Hill Road in Menlo Park, the heart of Silicon Valley. In an attempt to explain what their company does, they changed their name to Relational Software Inc., or RSI. The newly-christened company shipped its first commercial SQL-based database, V2, in 1979 (V1 was never officially released). In 1982 RSI changed its name to Oracle Systems Corporation, which later become Oracle Corporation.
Tapping the Internet.
In 1983, Oracle decided to make RDBMS portable, and introduced V3 - the first portable database to run on PCs, mini computers and mainframes. Today, Oracle targets high-end workstations and mini computers as the server platforms on which to run its database systems. Along with few others, Oracle has long been a champion of network computers. It now boasts that is was the world's first software company to develop and deploy 100 percent Internet-enabled enterprise software across its entire product line: database, server, enterprise business applications, applications development and decision support tools. In fact, CEO Ellison has said, "If the Internet turns out not to be the future of computing, we're toast. But if it is, we're golden."
A phenomenal success story.
Today, as proof of their success, they've parlayed an initial $2,000 investment in the company into an annual revenue exceeding $10.1 billion. Based in Redwood shores, California, it has more that 43,000 employees worldwide and does business in over 150 countries. Oracle (ORCL) is publicly traded on the NASDAQ.
Little known facts about Oracle
Oracle is ranked among the 10 best companies for a six-month return on equity.
Oracle's relational database was the world's first to support the Structured Query Language, now an industry standard.
Today, the Oracle DBMS is supported on over 80 different operating environments, ranging from IBM mainframes and DEC VAX minicomputers, to UNIX-based minicomputers and Windows NT platforms.
Oracle spends nearly 13% of their revenues for research and development.
Oracle V1 ran on PDP-11 under RSX, 128 KB max memory and was written in assembly language.
Oracle created the first database to run on a massively parallel computer.
65% of the Fortune 100 use Oracle for e-business.
Subscribe to:
Posts (Atom)
