Fighting change is hard work
- By Stephen Swoyer
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
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
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
Stephen Swoyer is a contributing editor for Enterprise Systems. He can be reached at email@example.com.