In-Depth

Fat is in, with good reason

• By Stephen Swoyer
• August 1, 2005

If convergence and standardization are the twin engines of IDE uptake in the embedded app dev space, then both trends account for the emergence of embedded variants of Linux and Windows. Call them the fat-client counterparts to the thin-client embedded devices of yore.

Why program to the wild profusion of embedded microcontrollers, much less to a dizzying array of proprietary operating environments, when you can generate managed .NET code from any of the flavors of Microsoft’s embedded Windows operating systems? The software giant has, after all, shipped its Windows Consumer Electronics embedded operating environment for almost a decade now, and—with the availability of an embedded version of Windows XP—programmers have still another reduced-footprint Windows option.

Both are based on the same Win32 application programming interface that vanilla Windows XP or Windows Server 2003 uses, and both boast support for Microsoft’s .NET framework (via the .NET Compact Framework in the case of Windows CE), ActiveX, DirectX, Microsoft Foundation Classes (MFC) and other Windows-centric programming technologies. Codejockeys can choose among a number of familiar tools—such as Visual Studio .NET—to develop software for both of Microsoft’s embedded OSes.

And then there’s Linux, which has been made to run on children’s toys, video game consoles, and—in one of many textbook cases—a popular wireless router marketed by Cisco Systems subsidiary Linksys. There’s a complete set of GNU-embedded development tools for Linux, and there are also full-fledged IDEs such as Eclipse. In addition, dozens—if not hundreds—of vendors provide embedded Linux solutions, with brand names including MontaVista Software, eCosCentric (RedBoot) and LynuxWorks, along with embedded or realtime OS distros such as White Dwarf Linux and the hugely popular Debian.

One upshot of this is that many embedded programming vets are embracing the bloat—with a kind of skeptical enthusiasm, of course. “When I program, I definitely prefer to program for embedded systems,” confirms Matthew Hamrick, manager of software architecture with Gibson Audio. “In the last 10 years, the difference increasingly has become academic as faster [or] better hardware allows
traditionally non-embedded OSes like WindowsCE and Linux to be used for solutions that typically had a more embedded flavor to them.”

From Hamrick’s perspective, this is both a good thing and a bad thing. As a case in point, he cites the limited use of commercial debugging tools in embedded app dev, largely on account of their high cost. But debugging is made more difficult in a canned environment such as Windows CE, which doesn’t provide as much flexibility, he says. “[T]he WinCE model is that you always have at least one serial port for debugging. Well, guess what? Our device had one serial port that was used for something else—not debugging. We had to make significant changes to our application to put it in a state that would allow us to use the few debugging tools we did have available. This should never happen.”

Windows CE, Windows XP Embedded and even embedded Linux are being sold in part on the promise of near-turnkey software development using familiar tools and familiar APIs for embedded systems, but some developers say testing and debugging for the embedded variants of these OSes is generally more difficult
than doing so for their conventional counterparts.

“We definitely have more debugging control over the Windows portions of our system. Although the ARM compiler does support embedded debugging, we do not have the physical interface necessary to make good use of it,” says Curtis Whitley, a programmer with a provider of embedded solutions for the retail petroleum industry.

Back to Feature: Embedded App Dev at the Crossroads