Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Software unsnarls embedded connections

Posted: 01 Jul 2005 ?? ?Print Version ?Bookmark and Share

Keywords:embedded? network? i/o? soc? hardware?

A lot of attention is paid to processing elements within embedded systems. But in the end, the data that feeds into and results from calculations carried out within these elements will eventually pass through some type of I/O port in the system. Given the importance of I/O, therefore, it is worth examining how the approach to designing system interfaces is changing. Some of these changes are subtle, such as the effects of SoC hardware on overall system architecture. Others, like network interfaces, are forcing drastic changes in the applications being created.

This is a key change in terms of the design of embedded systems. Integration of sophisticated I/O ports gives designers the option of handling complex peripheral environments and the responsibility of not being overwhelmed by them.

Embedded systems used to be a comfortable backwater in terms of software and network access. The rate of change was quite manageable and the consequences of design decisions were strictly local. Now, however, the increases in transistor density on ICs have given chip designers the raw material to add features to embedded cpus. These features have taken the form of faster and more complex CPUs, on-chip memory in many forms and peripheral I/O devices. For a long time, those peripherals consisted of more serial and parallel ports, but a revolution has occurred in smarter and higher-level peripheral interfaces as well. Smarter interfaces are becoming standard features on integrated MCUs and SoC processors. The advent of standardized interfaces and more complex systems is forcing this backwater discipline into mainstream computing.

Several options are available to designers in terms of I/O ports. Some broad categories include serial/parallel, standard ports and network interfaces. For many years, the vast majority of embedded systems have been built around simple parallel- and serial-port I/O. In fact, at one point, it was common to use discrete bits on parallel ports to emulate serial ports. This avoided the cost of an additional UART chip, which could be significant.

This combination of ports could handle a variety of interfaces. Parallel ports gave the ultimate bit-level control and parallel speed, while serial ports interfaced to smarter devices at slower rates. These smarter devices could implement high-level data protocols to handle file transfers or other, more-complex data exchanges. There were also straightforward trade-offs in terms of distance. Parallel ports were limited by crosstalk and skew, not to mention the cost of long ribbon cables, while serial ports could be much longer and more robust.

Integrating standard ports

The best examples of these smart interfaces are IEEE-1394 and USB. Each offers multidrop serial interfaces that define a number of high-level protocols supporting numerous sophisticated application profiles. In reality, the hardware implementation of either of these interfaces is relatively straightforward, but there is significant software involved in the protocol stacks supporting that simple hardware. That increased software complexity is of primary concern in modern embedded systems.

Another key advantage is flexibility. The application profiles defined on each of these interfaces allows them to be used for everything from low-end human interface devices like keyboards and mice to external disk-storage devices and real-time media interfaces. These devices can even coexist in relative harmony on the same interface because quality-of-service protocols allow dedicated data time slots that support scheduled real-time data transfers.

This is a huge advantage for chip designers. The interfaces can be integrated into high-volume chips that can be repurposed into a number of application markets. This is a major change from previous generations, which failed or succeeded based on getting just the right mixture in terms of on-chip peripheral devices. The vast universe of peripheral interfaces has migrated from being a hardware problem and is now squarely in the software camp.

While USB and 1394 interfaces provide access to a number of local peripherals, a network interface can literally add worldwide connectivity to a system. From a hardware point of view, there is not much difference between a USB port and an Ethernet port. But there is a huge difference in terms of the software opportunitiesand dangersinvolved.

As networked devices proliferate, the infrastructure will either expand to support them or, in the case of newer mesh networks, literally be expanded by them.

These interfaces have tremendously simplified the hardware base for embedded systems. In a very real way, the detailed low-level system design has been moved to a higher level. It is no longer necessary to design unique protocols to handle data transfers or peripherals. The need to program specifically to particular peripherals has been turned into a plug-and-play exercise. This detailed system design has been replaced by the integration of standardized high-level interfaces and protocols.

That is not to say that the complexity has been removed from these systems. Instead, it has been transferred to the software in terms of complex protocol stacks, increased customer expectations and greater system-level risks.

Each peripheral interface allows for a mind-boggling number and variety of devices to be connected to an arbitrary system, but it is up to software to coordinate the tree of devices that can be linked. The base protocol stack for each interface handles much of the interfacing, but for a device to be used, there must be an application profile that can handle the abstracted device type. If a USB keyboard is plugged into your system, will your application know what to do with it?

The interfaces do not remove the need for device drivers; they simply move it to a higher level. A single application profile will be able to handle any device that implements that side of the profile. If a USB storage device class is implemented in your application, it will be able to handle a large variety of storage devices from a number of sources, but that class must still be implemented. This requires the system designer to determine if it ever would make sense for a user to plug a disk into the system and, if so, what they should do with it.

- Larry Mittag

Independent Consultant

Article Comments - Software unsnarls embedded connectio...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top