h wired and wireless buses, LANs, and WANs. They are remotely monitored, configured, and controlled using standard network management protocols.
The proliferation of programmable processors in embedded systems has happened largely because of the availability of powerful, inexpensive processors and high-density, low-cost memory. However, three factors are accelerating this trend and may transform the embedded industry altogether. First is the emergence of standard run-time platforms such as Windows CE and Java that simplify systems programming and foster interoperability. Second is the emergence of integrated software development environments such as Green Hills Software's Multi and Wind River Systems' Tornado, which simplify applications development. Third is the marriage of embedded systems with the Internet, w
hich will simplify the development, networking, and management of distributed embedded systems.
Under the Covers of an Embedded System
The term
embedded system
is a nebulous one that encompasses just about everything except desktop PCs. An embedded system is one that is preprogrammed to perform a dedicated or narrow range of functions as part of a larger system, usually with minimal end-user or operator intervention.
For example, a V.34 modem typically uses two preprogrammed processors. One, an 8-bit microcontroller, implements the Hayes-AT command set and provides overall control for the modem. The other, a 16-bit fixed-point DSP, implements the core data-pump function. Similarly, an automobile might use a network of chips to handle such functions as active suspension, ABS braking, and engine control.
On a larger scale, a factory or power plant might use a network of VMEbus chassis to control manufacturing and such processes as heating, ventilation, and air-condi
tioning. You can even consider a PC to be an embedded system -- when it's packaged in a rack-mount configuration or ruggedized format and used to perform a dedicated function (e.g., telephone switching or machine control). In all these applications, embedded processors implement the bulk of the functionality by executing dedicated programs autonomously with minimal operator intervention.
Software
You write desktop applications -- and debug, compile, and execute them -- natively on PCs. You also develop the software for embedded systems on PCs and workstations. However, you must then cross-compile that software for the target processor, download it to the target platform, and debug it remotely from the PC or workstation.
Until a few years ago, the tools available for developing embedded software lagged far behind those available for producing native desktop PC applications. Native PC tools still hold an edge overall, but integrated embedded-software development environments have
closed the gap considerably.
Green Hills' Windows NT-based Multi, for example, automates all aspects of embedded-software development, including editing, source-level debugging, program building, execution profiling, run-time error checking, and project/version control. Moreover, tools such as Multi are available for most major embedded RISC and CISC CPUs and are compatible with major proprietary RTOSes, such as pSOS, VxWorks, Chorus, and Green Hills'
own VelOSity
and Integrity kernels.
In the DSP world, software methodologies still lag far behind. Assembly language coding is still common, and most designers opt for either a custom RTOS or no RTOS at all. An exception is Go DSP's Code Composer, which provides a window-oriented development environment for Texas Instruments' DSPs. Working in conjunction with TI's XDS-510-compatible emulators and Spectron Microsystems' Spox RTOS, Code Composer provides RTOS-aware source-level debugging, DSP project management, incremental compil
ation, and on-line help.
Embedded OSes
While Windows and Unix have established themselves as the dominant OSes on PCs and workstations, the embedded-systems market remains highly fragmented. Despite numerous attempts (e.g., Posix) by hardware and RTOS suppliers, the embedded market has failed to establish a standard run-time environment. DOS, real-time versions of Unix, and a handful of proprietary RTOSes own most of the off-the-shelf market. But more than two dozen smaller players have established a beachhead, with most designers still choosing to roll their own kernels.
The DSP market is even more wide open. Fresh from their transition from assembly language to C, DSP developers are surprisingly still reluctant to absorb the overhead of even the most efficient RTOSes. Still, growing DSP application complexity and substantial gains in performance are beginning to put programmer productivity on the radar screen. DSP designers are also beginning to warm to the idea of using RTOS
services in their applications. Probably the best known off-the-shelf RTOS for DSPs is Spox. However, vendors of mainstream RTOSes, such as Green Hills, are also beginning to port their products to DSPs. A handful of small European vendors have also done so. These products have their origins in the transputer market.
An encouraging development in the push to establish a standard DSP platform is TI's recent decision to create a standard BIOS for its fixed-point DSPs. The new DSP/BIOS, codeveloped with Spectron, provides standard multitasking, I/O, and real-time data-capture services (see the figure
"Programming DSPs"
). These not only simplify DSP programming, they also lay the groundwork for more advanced debugging, manufacturing test, and field diagnostics tools. The hope is that the industry will adopt this BIOS as a standard platform for DSPs from all vendors.
Proprietary RTOS vendors have been struggling for more than a decade to carve a niche in the embedded market. Durin
g that time, Microsoft has essentially sat on the sidelines. Even so, DOS and Windows have always had a strong following in the embedded market.
However, the nonexistence of a small-footprint DOS or Windows has limited their use in deeply embedded systems. At the same time, the lack of deterministic, preemptive multitasking has limited their use in mission-critical applications with hard real-time requirements.
The availability of Windows CE may well shift the balance of power in the embedded-RTOS market. Fully ROMable, Windows CE features preemptive multitasking and a Windows-like GUI. Windows CE also contains a standard communications protocol that facilitates Internet access and information sharing with other Windows-based applications. Windows CE's modular implementation makes it scalable, thereby enabling its use in a broad range of resource-constrained embedded environments.
Soon, Microsoft will upgrade Windows CE with a deterministic scheduler that makes it better suited for real-time
applications. Even with these improvements, Windows CE won't be able to match the miniature footprint, nimble context switching, and high-speed interrupt response of such RTOSes as VxWorks and pSOS. But for embedded systems that can tolerate 10-millisecond context switching and spare 256 KB of RAM and 512 KB of flash memory, the standard development and operating environment offered by Windows CE (not to mention third-party hardware and software support) may make Windows CE a serious contender.
So far, Microsoft is primarily targeting the high-volume hand-held PC market with Windows CE. However, the company is also making Windows CE available to the embedded community at large through distributors and systems integrators such as Annasoft Systems.
Another embedded platform that is gaining momentum in the embedded market is Java, an OS-independent platform originally developed for set-top boxes. The Java platform has two main components. One, the Java API, provides basic language, utility, I/O netw
ork, GUI, and applet services. The other, the Java virtual machine, separates Java applications from the details of the underlying browser, OS, or processor. You can compile Java applications directly for native execution on a particular processor. You can also compile them to produce an intermediate processor-independent byte code. You then convert this to processor-specific code by a Java interpreter and Java-compatible OS that reside on the target hardware.
Networking Embedded Systems
The processors in an embedded system can be connected via any number of proprietary or standard buses, LANs, and WANs. When the form factor is small, the processors are typically hard-wired together via a shared memory bus or other I/O port. Within a particular chassis, such as a hub, multiple processing boards might also be linked via a custom backplane or standard system bus such as VMEbus. Under the hood of an automobile, multiple processors may be linked via a custom bus built into the wiring harn
ess or a separate high-speed serial bus such as the Controller Area Network (CAN) bus that supports data rates of up to 1 Mbps.
A myriad of wired and wireless standard network solutions exist to link multiple embedded systems that are dispersed throughout an office, home, or factory. These include low-cost consumer networks such as Consumer Electronics Bus (CEBus) and LonWorks, which use existing telephone and power wiring; midrange LANs such as Ethernet and token ring, which use twisted-pair wiring, coaxial cable, and wireless media; high-end LANs such as Fiber Distributed Data Interface (FDDI) and Hiper Channel that use fiber optics; and market-specific LANs such as Mil-Std-1553, which are used in military applications.
While physical LAN-connection alternatives abound, the network protocol used most often in embedded systems for LAN communications is TCP/IP. In fact, most RTOSes are available with built-in TCP/IP support.
During the software-development phase, you use TCP/IP to support pr
ogram downloading and remote debugging. After you deploy the system in the field, you use TCP/IP to support communications with other embedded systems, supervisory computers, and management stations on the network.
The principal network management protocol used for remote monitoring, configuration, diagnostics, and management of embedded systems is SNMP, which runs on top of TCP/IP. Individual embedded systems incorporate SNMP agents, whose Management Information Bases (MIBs) store data, such as network statistics and configuration information. This data is accessed by remote SNMP stations such as Hewlett-Packard's OpenView and Sun's SunNet over the network. RMON, a MIB extension to SNMP, enhances remote management capabilities by enabling the SNMP agent to store more comprehensive information (e.g., statistics, history, alarms, events, and filtered packets).
Embedded on the Internet
High-level protocols such as TCP/IP and SNMP that span multiple physical networks are important
because they help lay the groundwork for industrywide connectivity. The ideal scenario, of course, would be a single worldwide network encompassing all LAN and WAN communications for factories, offices, military installations, and consumer-electronics devices.
Given the massive installed base of proprietary and standard LANs, and the breadth of specialized communications requirements associated with each application area, such a network is not likely anytime soon. However, the Internet is emerging as the glue for such a network. Independent of the underlying physical network, we can use the Internet for LAN and WAN communications. The Internet can accommodate voice, video, and data traffic, and is already in widespread use.
Currently, desktop computer users employ the Internet primarily to send e-mail, transfer data files, and access information repositories. However, you can also use the Internet to network embedded systems and even individual processors in an embedded system.
From a practi
cal standpoint, the Internet currently lacks the performance required to support real-time communications between embedded systems. Even in an intranet environment that circumvents Internet bottlenecks, IP lacks the capability needed to allocate dedicated bandwidth, which is essential for real-time communications.
Even so, the Internet and intranets are still ideal for performing such functions as remote configuration, diagnostics, and management that do not require real-time response. Improvements in the Internet's infrastructure, such as the deployment of high-performance asynchronous transfer mode (ATM) networks that can allocate dedicated bandwidth, will greatly extend the scope of the Internet in embedded-systems applications.
A number of companies are beginning to exploit the Internet to simplify remote management. Network hardware manufacturers such as Cisco Systems, HP, and Tivoli Systems, for example, are adding HTML interfaces to their hubs, routers, and switches that simplify the use of
SNMP. The HTML interface makes the device's MIB look like a Web page (see the figure
"Embedded on the Web"
), enabling it to be remotely queried, configured, and managed via standard Web browsers such as Microsoft Internet Explorer and Netscape Navigator, either via the Internet or the corporate intranet. RTOS vendors are taking a similar approach, adding browsers and HTML interfaces that enable embedded systems based on their RTOSes to manage or be managed by other Internet-ready systems.
Java in Embedded Systems
As interest in creating Internet-accessible embedded systems increases, developers of embedded-systems software will gravitate toward development tools that simplify the creation of Internet-enabled applications. The Java language is tailor-made for developing such applications. The reason is that you can compile Java applications to a processor-independent format that can be downloaded over the network to any processor running the Java virtual machine
and a Java interpreter.
Interpreted Java code is much slower than compiled C. However, this approach greatly enhances embedded systems' flexibility by enabling the system to be reprogrammed to perform new functions on the fly. The ability to download programs over the network is also ideal for resource-constrained embedded systems such as set-top boxes that don't have sufficient nonvolatile memory to store programs locally.
Many are predicting that Java will displace C and C++ as the language of choice for embedded-systems programming. Certainly, Java's processor independence will make it attractive for Web-based applications that require programs to be downloaded over the Internet. On the other hand, the overhead associated with interpreting downloaded Java programs on the fly makes it unattractive for applications in which programs are stored and executed locally on a particular processor.
As with C, you can also compile Java programs in advance to run native on a given processor. However,
you then lose portability, and Java must compete with C on the merits of the language itself. Java may also have some advantages in this regard, but probably not enough to overcome the tremendous installed base and momentum enjoyed by C.
With embedded systems gaining network, Web, and Java capabilities, they are getting smarter, more communicative, and more controllable. This can only result in more of them, in more applications, doing more clever chores.
illustration_link (23 Kbytes)
Texas Instrument's DSP/BIOS API, codeveloped with Spectron Microsystems, simplifies programming DSPs by real-time testing.
illustration_link (21 Kbytes)
Web-page-on-a-chip lets network managers use a standard Web browser to perform diagnostics on the embedded systems.
illustration_link (16 Kbytes)
The core of VelOSity is a small, fast multitasking kernel. It handles user processes
and system interrupt routines.
Bob Margolin writes on a variety of technical issues in Wheatland, Wyoming . You can reach him at
margolin@wyoming.com
.
Smarter Stuff
