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
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
Stephen Swoyer is a contributing editor for Enterprise Systems. He can be reached at [email protected].