USB on-the-go: opening up consumer/PC connectivity

USB OTG changes this paradigm with the ability for a peripheral to act, often only temporarily, as a host. This breaks the inhibiting requirement for a strictly PC-centric environment because OTG-enabled devices are free to communicate directly with function devices and even other OTG products.

Along with opportunity, of course, come risk and complexity. So, what are the inevitable limitations to host functionality in an embedded (non-PC) device? What are the trade-offs that will have to be made in those devices in order to maximize battery life and minimize form factor? Exactly how PC-like should be expect our OTG devices to be and what are the design decisions that device manufacturers need to consider in order to meet the world's expectations?

OTG is ideal for portable devices. That statement is not intended to limit its range of potential applications, but OTG was designed with such devices in mind and they are the easiest way of describing its benefits. Effectively, today's portable devices, most obviously PDAs, but also digital still cameras (DSC)and cellular phones, are just computers with previously unheard-of functionality and computing power packed into tiny form-factor products. As we become increasingly comfortable with owning multiple computers, each with a degree of commonality in their feature sets, we become increasingly uncomfortable with the reliance on any one of them above another. Specifically, we do not wish to remain PC-bound in our daily computing activities. OTG is one solution to the problem of sharing data between devices without the need to connect to a PC first.

Clearly, not all peripheral devices can, or should, support OTG. The DSC and PDA are obvious candidates for OTG support because there are sufficient resources within those devices - memory, processing power and user interfaces - to control a connected peripheral. A mouse, for example, is a really bad candidate for OTG because it has none of the above characteristics. What would a mouse do when given full control of a PDA?

The classic example of the limitations of USB, before OTG, is the DSC. If someone takes a picture and wishes to share it, there is currently no mechanism to do this without downloading it to a PC, then distributing it, often via more PCs and the Internet, to people who would like a copy of the image. You cannot share the pictures on a DSC with a cellular phone or a PDA. Even if there is only a need for a "paper copy", it is impossible to connect the camera directly to a printer and print off copies of the photo3.

OTG is one option to resolving this limitation because it allows the device to act as a host in certain well-defined situations. The OTG-enabled DSC would be able to connect directly to just about any peripheral device - a PDA, printer or even another camera - and drive them just like a PC would. This enables the direct transfer of images to friend's PDAs, phones or cameras, or the immediate printing of pictures on a normal (i.e. USB peripheral) printer. An important final point to this example is that DSC would still be able to connect to a PC and behave just like a "normal" peripheral device - the existing usage model is unchanged.

Unlike many networking systems, such as TCP/IP for example, USB is not a peer-to-peer solution. USB mandates a hierarchical network topology with the PC as the unquestioned king. There may be up to 127 peripheral devices in a given system but there can only be one host. OTG does not change this model.

Enforcing the rules

Even though you may connect two OTG-enabled devices, PDA to PDA for example, and both are capable of acting as the host, there is only ever one host at any given time. Just because OTG devices can swap modes does not mean you can change the basic rules of USB connectivity. This is a common misunderstanding of OTG and leads to much confusion over required functionality and the applications for which it is applicable. It is easiest to explain, and enforce, the connection rules for USB through the connectors and cables defined by the standard.

USB 2.0 introduces some new nomenclature to describe the role of a given device. Host devices, such as PCs, are defined as A devices while peripheral devices, such as mice and PDAs are defined as B devices. The specification also defines standard-A, standard-B and mini-B connector pairs as well as two cables to connect both the B types to A. These are the most commonly used connectors today, with the standard-A found on PCs and hubs, standard-B on many office products, such as printers, and mini-B common on portable devices like PDAs and DSCs.

The OTG supplement adds the mini-A connector pair and the mini-AB receptacle only (no plug). The mini-A and mini-B plugs are keyed so that they can only accept their corresponding receptacles, while the mini-AB receptacle can accept either a mini-A or mini-B plug. OTG also defines two new cables to connect the B-types to the new mini-A. The mini-A receptacle is defined for use in adaptor cables only but could find a niche in small form-factor computers, such as pocket PCs, that may be USB hosts but not adopt OTG.

OTG defines a new pin in the connection, named ID, which is used to signal required host behavior in an OTG system. In the standard A and B connector pairs the pin is absent, because they pre-date the supplement. In the mini-B it is left unconnected because the connector was designed with the upcoming OTG specification in mind. In the mini-A plug it is shorted to GND and in the mini-AB is used to determine the n ature of the connection.

If a device with a mini-AB receptacle detects a connection with the pin pulled low it knows that a mini-A plug has been inserted and hence it will assume the role of an A device (host). Conversely, if a connection is detected and the pin is floating it knows a mini-B plug has been inserted and will assume the role of a B device (peripheral). OTG-enabled devices will always use the mini-AB because it is the only receptacle that will allow connection to either an A or a B device.

What all this achieves for OTG, is a situation where the usage model of the devices is limited and forced to be logical, by the available cables, plugs and receptacles. When connecting a peripheral to an OTG it is impossible to connect the cable the wrong way around. This is because the B or mini-B receptacle on the peripheral will not accept the A end of the cable even though the OTG would accept both a mini-A and a mini-B. The OTG device is automatically defined as the host for the duration of the session because the cable signals it through the ID pin. When connecting to a PC a similarly logical cable orientation is mandated and the missing ID pin in the cable forces the OTG device to be a peripheral. Therefore, the careful definition of cables and connectors prevents the untenable situation of connected peripheral pairs or, equally useless, host pairs.

So, the behavior of OTG devices is typically defined by the devices to which they are attached. They always behave like peripherals when connected to a PC. Conversely, they always behave as hosts when connected to dedicated (i.e. non-OTG) peripherals. In these cases, the host-peripheral decision is pre-determined and there is no opportunity, or need, to swap modes in mid-session.

However, there is one more OTG connection scenario to consider; an OTG device with another OTG device. This could occur between similar products, PDA to PDA for example, or completely different OTG-enabled products such as a DSC to a PDA.

The O TG Supplement defines the Host Negotiation Protocol (HNP) as a method for two OTG devices to swap modality mid-connection, without the user needing to reverse the cable between them. The initial state is defined by the cable; whichever device gets the mini-A plug will assume the role of host and will, by definition, interact with the peripheral accordingly.

An OTG device that supports HNP will send, once the connection is established, a set Feature command to tell the peripheral that it may take control of an idle bus. At some point this session is likely to become idle, at which time the peripheral is allowed to request the host role and control of the bus. The original host will then assume the role of a peripheral device with the exception that it is still responsible for powering the physical bus.

Additional concerns

HNP creates a number of interesting issues for embedded and consumer electronics designs. HNP immediately removes support for a hub because they are uni-directional devices. There are also power usage concerns since the bus continues to be driven by the A device. These are real issues that are basically introduced into the equation merely to save the user the effort of swapping the cable. HNP is a sophisticated extension to USB, it is the key difference between true OTG and a simple multiplexed host and function controller solution. So, the question for product design teams is whether they should implement it in their designs. Will this hot-swap feature be adopted by the market as a useful time-saving feature or will it cause confusion among users who put OTG devices to hubs and expect it to still be capable of swapping roles?

For many embedded devices, form factor is a major issue. This is especially true in the handheld consumer electronics markets where USB is fast becoming a de-facto standard connection method. It is from the needs of this market that the "mini" style connectors have become so popular because, quite simply, there is not enough room for the original standard sockets and connectors on PDAs and digital cameras. Inside the products, the problems are more challenging.

One way to support USB is to put a discrete function controller onto the board. This is a safe, comfortable option because the chip will have been exhaustively tested and probably certified as compliant with the appropriate standards, but there are obvious prices to pay in terms of board real estate, chip count and cost of goods. The only way to reduce these costs is to build all or some of the USB functionality into the main SoC or ASIC.

Creating a new chip with on-board USB support is a major decision and not one that will be determined solely by functional requirements. Obviously there are many extra factors to consider, such as expected shipping volumes, cost of goods, power consumption, performance, other communication interfaces, CPU licensing, on-chip memory, software concerns and, ultimately, the ubiquitous time to market consideration. The reality is that this decision is typically already made before USB is considered. Applications self-sort into board and SoC designs where board-based products just add the discrete parts(s) and high volume SoC designs integrate the functionality on-chip.

Integrating discrete parts onto board designs is not significantly different for USB than any other communication chip. The real challenge for USB implementors today is in the design and creation of custom SoCs to be used in high volume applications where footprint (in terms of both pin and gate count), performance, power and cost all need to be highly optimized.

This article was excerpted from ESC paper 370, titled "Embedded Considerations for USB On-the-Go."

See related chart