Walking through the Los Angeles airport late last Wednesday night, I wasnt able to read the flight status display for my departure to New York. The critical part of the screen was occupied by a familiar System Process alert that said, “Your system is running low on virtual memory. Please close some applications …”
When I returned on Saturday night, that same error box was still there—including the discreet little Windows logo at the top left corner, in case anyone didnt recognize the timeless prose of the message.
I dont know if this error display went ignored for more than 72 hours, or if its a chronic but intermittent problem that I happened to see strike twice. Either way, it was a striking reminder that developers tend to use the platforms that they know best for many kinds of applications, and that the requirements of embedded applications include degrees of predictability and hands-off operation that challenge both development teams and IT infrastructures.
Few things expose those challenges better than an error box with an “OK” button, just waiting for someone to click it, but with not a pointing device—or any other input device—in sight. At least this embedded system had a display: many devices lack even this means of warning the user that something has gone wrong … gone wrong … gone wrong.
Makers of both processor chips and operating systems are well aware of the huge growth opportunities in embedded systems development—for example, in automobiles, where the number of cars in the United States with some kind of “telematics” capability is projected to grow at a compound annual rate of 63 percent over the next five years. Intel opened this month with availability announcements for Pentium-, Celeron-, and XScale-family chips aimed at somewhat more familiar embedded applications such as telecommunications, point-of-sale, media players, and other roles in which one cant expect to ask for system management assistance from the user.
Also at the beginning of this month, AMD introduced a new reference design for thin-client devices with compact size and low power consumption.
To sell chips into these environments, Intel and AMD need reliable suppliers of companion operating systems that range from Windows CE or XP variants, with their extensive tool sets and other support, to Linux with its vigorous community of open-source developers and value-adding infrastructure architects—and also to well-established real-time operating systems vendors such as Wind River Systems Inc., whose views will be part of a panel discussion on device software trends this Tuesday evening in Mountain View, Calif.
Relative costs of embedded system development on various platforms are as controversial a topic as the relative costs on servers, with equally spirited discussion of the assumptions and distortions that interested parties see in each others analyses. Relevant measures of performance for these systems are also important as developers search for tradeoffs among performance and power consumption.
With the Cassini-Huygens spacecraft scheduled to enter Saturnian orbit at the end of this month, Im reminded of a famous comment on the standards that have been set by embedded software developers on previous deep-space missions. “Allegedly, one Real Programmer managed to tuck a pattern-matching program into a few hundred bytes of unused memory in a Voyager spacecraft that searched for, located, and photographed a new moon of Jupiter,” wrote Ed Post in the classic “Real Programmers Dont Use Pascal” in 1982.
Whether or not real programmers use Pascal, its increasingly clear that Real Programmers dont depend on the user to correct software development oversights. The standard of software quality is therefore, necessarily, rising; that trend will continue.
Tell me about your needs for embedded device development at firstname.lastname@example.org.