In-Depth

Fighting change is hard work

• By Stephen Swoyer
• August 1, 2005

For decades, embedded application development has typically presupposed the use of highly limited computational resources.

Because of this, most electrical or computer engineering students, along with many computer science students, for that matter, cut their teeth programming in machine language, or in low-level languages such as Assembly, on Intel or Motorola microcontrollers. Assembly has been supplanted by a highly efficient and streamlined C programming language, but there’s still a perception that 4GL languages such as C++, Java and C#, among others, simply require too much (in terms of memory, processing power and storage capacity) than C or Assembly, at least for embedded application development.

That is changing rapidly. Veterans of embedded software development continue to hew to the old ways, but it’s hard to fight the tide of change—especially when your ranks are being infiltrated by coding greenhorns accustomed to programming to several megabytes of memory space. “A number of our staff members have been in embedded systems since the 1980s, so we are used to writing lean code for small memory spaces and slower processors,” says Curtis Whitley, a programmer with a provider of embedded solutions for the retail petroleum industry.

“One fear we always have is that newer development systems…will bring tons of baggage that isn’t really required, simply because the memory spaces are larger today; the processors are faster,” Whitley says. “The younger programmers know it; the deadlines are short; and there is no real motivation to keep things lean.”

One upshot of this, Whitley says, is a much bigger resource footprint in next-gen embedded applications that have, in previous iterations, been almost maniacally lean. Part of this is because of the mainstream use of C++ and (although less common) newer object-oriented programming languages including Java and C#.

Part of it, too, has to do with the emergence of embedded Java, Linux and Windows operating environments, which are slowly emerging as viable alternatives to proprietary device-specific operating systems. Part of it has to do with uptake of shrink-wrapped or open-source IDEs, such as Eclipse or Visual Studio .NET, which are being used in place of vi and other cherished editors.

Nevertheless, Whitley doesn’t think the inexperience of programmers, the use of resource-intensive object-oriented code, or the uptake of bloated development tools can account for the much larger footprints of today’s embedded apps. Instead, he says, it’s an issue of systemic complexity. “It is becoming more and more difficult to trim systems to work optimally or to find out which component really has a problem, because there are so many interrelated parts, and no one can understand them all,” he remarks. “Gone are the days when the whole OS plus applications ran in 32KB or 64KB!”

If anything, says Raj Seghal, senior director of product marketing with Borland, the efficiency of C++ and other object-oriented languages has improved drastically over time, such that—in the case of C++, at least—object-oriented development is now a viable option for most embedded applications.

Back to Feature: Embedded App Dev at the Crossroads