Every other product on display at this year's Consumer Electronics Show seemed to integrate Internet connectivity. Whether their gadgets belong to new categories of devices whose very existence depends on the Internet, or to recognizable durable goods lines that are now "wired," consumer electronics makers have recast their wares as "Internet Appliances."
The challenge to "wiring" these devices comes from the need to embed the hardware/software "stack" that formerly resided only on resource-rich workstations, desktops and servers. That stack includes the CPUs, standard peripherals, sound and video interface chips and the associated device drivers, middleware and applications. Because of the dependence on desktop-style programming models and APIs, and because of the greater complexity of such networked and multimedia applications, embedded developers are increasingly abandoning the traditional kernels, such as VxWorks, pSOS and OS-9, and looking to embedded versions of the desktop software platforms they use for workstations. While Microsoft has targeted this need by building desktop Windows functionality into Windows CE, more and more projects are turning to embedded Linux.
Despite the addition of new age components in their software stacks, connected devices get developed with much the same tools as more-traditional embedded systems: cross-compiler tool chains and debuggers, for example. However, with the switch from using minimal embedded executives to embedding "real" operating systems like Linux, the developer must reorient from a tool-centric view of development to a kernel-centric one.
Traditional embedded systems weren't much to look at, literally. The prototypical embedded device most cited is the toaster: headless (no display), monofunctional (it toasts, right?), simple user interface (light/dark slide control) and no connectivity (except for ac). Writing code for an "intelligent" toaster-type device proceeded on a PC or engineering workstation-4- and 8-bit embedded processors don't usually host editors, compilers, linkers and debuggers. Developers tested and deployed their control software using in-circuit emulators and EPROM programmers to cross-load their programs from their development stations into the device's memory.
Even for more-complex embedded applications, developers have for the last 10 years depended on embedded software platforms that grew out of the "toaster" paradigm. The huge disparity in computing power and capability between the development host and the embedded target led to a dependence and focus on host-based tools, with little investment in making commodity embedded kernels more powerful or robust.
Developers building the current generation of smarter embedded and net-centric devices can and must design-in more-robust hardware and software platforms. Rather than embedding "just enough" CPU horsepower in target devices, they can draw on high-integration versions of processors developed for desktops and workstations-Intel IA-32, Motorola and IBM PowerPC processors, and MIPS derivatives-as well as 32- and 64-bit CPUs designed exclusively for embedded applications, like ARM processors and Hitachi's SH family.
These full-blown processors perform much more like workstations than their puny 8- and 16-bit predecessors. Rather than continuing with the unbalanced mating of workstation and toaster, developers now treat their embedded targets as peers on a network and leverage the powerful combination of embedded 32-bit CPUs running "real" OSes like Linux.
While using embedded software like Linux does not obviate the need for traditional cross-development tools, being able to access an embedded target with telnet, Web browsers and other types of clients changes the focus from the (tool-centric) power of the host to the (kernel-centric) power of the target.
Once reoriented, developers can leverage the Linux/Posix process model, memory protection and multiprogramming, and use hosted tools like scripting languages, shells, daemons, native file systems and core files for debugging.
Challenges for tools
These new-found tools and capabilities do not obviate the need for traditional tools, but rather augment the developers' original toolbox. The protection and quality provided by Linux/Posix memory management does present some challenges, however, to traditional tools like in-circuit emulators, logic analyzers and other run-control systems, whose companion interfaces and debuggers must be trained or redesigned to accommodate virtual address translation.
Building devices that include broad Web-browsing capability presents taxing technical and logistical challenges-combining a browser, browser plug-ins, a Java execution engine and a GUI that serves both the browser/Java combination and external applications. On the desktop, under Linux, Windows or MacOS, the platform provider and purveyors of the browser, plug-in and Java components all share the same GUI and other APIs with standard applications. But as you move away from the desktop, and leave the Intel IA-32-based world of the "gray box," this juxtaposition of key components becomes much more difficult.