In-Depth
Embedded App Dev at the Crossroads
- By Stephen Swoyer
- August 1, 2005
Talking Points
EMBEDDED OR ASSIMILATED?
- If embedded software development occurs industry watchers say, it’s
invariably segregated from conventional app dev.
- Commercial and open-source IDEs are environments of choice for two often-irreconcilable
software development camps.
- Organizations want their developers to source code and ensure consistency
between embedded and conventional domains.
Thanks to the emergence of mobile and wireless devices, the existence of lite
versions of cutting-edge application frameworks such as Java 2 Enterprise Edition
and .NET (the embedded versions are J2ME and the .NET Compact Framework), and
the availability of versions of Linux and Windows that are designed specifically
for embedded
applications, it’s a Brave New World for embedded application development.
|
This new worldscape has some technology visionaries talking up a scenario in
which the once-discrete practices of embedded and enterprise application development
meld—or at the least, commingle. Although convergence does seem inevitable,
it’s also mostly horizonal, at least at this point. Most embedded programmers
continue to code in their traditional technology domains, and vice versa.
This is part of a trend—how widespread, no one knows for sure—in
which commercial and open-source IDEs are becoming the programming environments
of choice for two often-irreconcilable software development camps: hardware-savvy
embedded programmers and hardware-averse enterprise codejockeys. To be sure,
embedded codejockeys continue to plug away in vi, Emacs and other venerated
editors, but many—including some of those who are accustomed to embedded
application development in vi or Emacs—are increasingly adjusting to the
use of a commercial or open-source IDE.
Proponents call it standardization, and they say it’s a good thing. “I think
we’re seeing some of that [standardization] already, although we’re going to
see more over time” says Eric Naiburg, marketing manager for desktop products
with IBM’s Rational Software Group. “What the teams are building and embedding
on the embedded side, they want to be able to use on the IT side, as well. They
don’t want to have separate development tools. We’ve seen a lot of the organizations
that we work with standardize on one [IDE] so they have more synergy across
the two [programming] teams.” (See related story, “Fat
is in, with good reason.”)
There are a raft of IDEs, of course, but two merit special mention: Microsoft’s
Visual Studio .NET and the open-source Eclipse project. The latter is the most
popular Java IDE in use. It’s also an open and extensible IDE framework—it
can support any kind of programming language or application architecture. This
means that Eclipse is increasing the underpinning for a proprietary IDE, like
IBM’s Rational Application Developer. Recently, however, Borland Software
announced an Eclipse-related initiative of its own, along with embedded software
development specialist Wind River, which bases its Wind River Workbench development
environment on Eclipse.
And with momentum of this kind, industry watchers say,
the IDE’s the thing.
Not your grandfather’s 8051 microcontroller
A quarter of a century ago, Intel delivered its venerable 8051 microcontroller.
Originally designed as an 8-bit chip with 128 or 256 bytes of internal RAM,
several different flavors of the 8051 are manufactured to this day—and
will likely be manufactured for many years to come, too.
Chips such as the 8051 aren’t so much a dying breed as a setting trend.
They’re ideally suited for applications including keyboard microcontrollers
or industrial control systems, and that’s probably not going to change
anytime soon.
However, embedded programming vets are increasingly working with chips (or
multi-chip hardware networks) that—in terms of processing power, memory complement
and storage capacity—could have functioned as desktop computers a decade ago.
These include not just x86 chips, but also 32-bit RISC based chips such as ARM,
PowerPC, and others. (See related story, “Fighting
change is hard work.”)
“The embedded system, with respect to what I target, is becoming more
and more like a traditional system,” says
Chuck Gales, a principal at embedded software development house Pinnacore Consultants.
“It is very common that an embedded system has 8MB or more of Flash, 256MB
of RAM and a 32-bit processor running at over 100 MHz. These embedded systems
are very powerful in their own respects, so using the term embedded application
code is kind of misleading.”
That’s a perspective endorsed, although with some reservation, by Raj
Seghal, senior director of product marketing
with Borland Software. “The traditional concept of embedded application
development is changing, although I wouldn’t say these old [embedded]
applications are going away. But now [programmers] typically have more resources,
in some cases substantially more [resources], and so we’re seeing much
more sophisticated [embedded solutions],” says Seghal.
One upshot of this, says Gales—a computer scientist with a background
in electrical engineering and digital design—is that he now does little
in the way of traditional embedded programming. “I have not worked on
a traditional control system in a long time. I did work on a system with an
8-bit CPU last year, but that is extremely rare. With prices coming down for
a 32-bit processor, every design I am working on has one of these new chips.”
Gales, for his part, still programs the old-fashioned way—using his trusty
SlickEdit text editor and makefiles.
But Borland’s Seghal and other vendor reps suggest codejockeys such as
Gales might soon be the odd geeks out. With more computing power than ever to
play with, they argue, why shouldn’t embedded programmers step up to more
computationally intensive development tools and languages?
One IDE to unite them all
If embedded software development occurs in enterprise environments today, industry
watchers say, it’s invariably segregated from conventional app dev. That’s
changing, however, because the increasing ubiquity of mobile and wireless devices
has helped carry embedded application development far afield from its roots
in the industrial and manufacturing sectors.
It’s even more complicated than that, says Borland’s Seghal. Some
enterprises are developing hybrid, or interdependent, applications that have
both conventional (client desktop) and embedded (mobile or wireless, and, in
some cases, control systems) components. Not surprising, these organizations
want all of their developers to be
on the same page, with access to the same versions of source code, and with
consistency assured between developers
working in the embedded and conventional domains.
Ideally, Seghal and others argue, they’ll also want their programmers—embedded
and conventional alike—working with the same development tools. This,
of course, is what IBM/Rational’s Naiburg means by standardization. What’s
surprising—at least, in the context of a hypercompetitive industry in
which oneupsmanship is the rule—is that IBM, Borland and nominal competitors
are apparently reading from the same script.
They also aren’t opposed
to be upping the ante. After all, notes Naiburg, a pro programmer who’s
able to use IBM/Rational tools to write Java code for conventional applications
can use the same IDE to write Java code for the embedded space.
For some organizations, particularly those in which embedded application development
isn’t an established practice,
this is a potentially compelling vision. “In some cases, yes, there’s
going to be a strong tendency to want to unify those [development processes],”
Naiburg argues. “They’ve got to come together, because you’ve
got to enable these things to run on the desktop, on the server, on these mobile
devices. So I don’t know if I’d call it a trend, but we are seeing
more and more [organizations] wanting to share these assets across different
teams.”
This isn’t exactly a welcome development, however, at least from the
perspective of some embedded programming
pros.
Not so fast
Many embedded codejockeys think of themselves as—in a single word—elite.
This doesn’t mean they believe they’ve
been selected for or elected to greatness, however. Instead, it’s a way
of saying they’re extremely aware of the fact that
the code they write has very real consequences—perhaps life-or-death consequences—in
the real world. Embedded
systems power pacemakers, fetal heart monitors, flight control systems, dialysis
machines and so on. A glitch or bug in a production system, in these cases,
can result in a lot more than a missed SLA, lost revenue or potential litigation.
What’s at stake? Phil Frisbie, a principal with Hawk Software, a provider
of embedded speech compression products, ticks off a litany of potential pratfalls.
“Resource leaks, even tiny ones that would never be noticed in a desktop
application running on a desktop OS, can cause severe problems with embedded
applications. Memory resources are more restricted, and embedded OSes such as
[Windows] CE rarely get rebooted,” he notes, citing
memory fragmentation issues, in particular on Windows CE, as well.
Most embedded specialists would agree the best practices that apply to conventional
software development can
also apply in the embedded space. The difference, argues Matthew Hamrick, manager
of software architecture with
Gibson Audio, is that codejockeys who work in conventional application environments
tend to disregard many of
these best practices.
And why shouldn’t they? They’ve got computing resources a-go-go,
and they’re working in a model in which bugs, glitches and coding errors
aren’t just tolerated but expected. Hamrick, who’s also worked with
next-gen embedded OSes such as Linux and Windows CE, says these platforms—like
the universal IDE—are being
hyped as productivity facilitators for otherwise overwhelmed IT departments.
“What I’ve noticed is organizations building embedded mobile devices
these days seem especially susceptible to hype,” Hamrick says. “MontaVista
[an embedded Linux vendor] will come in and talk about how their embedded Linux
is the best thing since sliced bread and how it turns your senior developers
into embedded gods,” he comments. “Then Microsoft comes in and says,
‘No, no, you want to be using [Windows CE]. It turns your junior
developers into embedded gods.”
The danger, Hamrick says, is tri-fold: management isn’t evaluating a
tool on the basis of its appropriateness for a
particular task; the efficiency of developers is not measured across changes
in methodology or the tool chain; and the
need for realistic, testable interim milestones is ignored.
Getting better all the time
Jesse Davis, a software developer with a provider of wireless learning services,
is a new type of embedded programmer. He’s never worked on traditional
control systems, for example, and is charged with porting his employer’s
implementation of a SyncML client from Python on the desktop to C# on the PocketPC.
Davis’ project is a hybrid: “Our SyncML server is written in Python
for Linux and will remain that way,” he says. “For speed, we’ve
had to switch from Python to C#, and for memory, we’ve gone from a DOMbased
XML parser to the .NET Framework’s stream-oriented XML parser.”
What does he like most about the move, at least so far? The surprising performance
of Microsoft’s SQL Server provider for Windows CE, which he says “gives
us a richer data model on the handheld than we have on the desktop.”
What Davis dislikes most, on the other hand, is the performance of Visual Studio
.NET, which he says isn’t as snappy as his Python-based tool. “I
find Visual Studio .NETunbelievably slow and buggy. My high-end workstation
constantly pauses to think, especially when deploying my projects to the handheld.”
Further, the .NET Compact Framework seems inferior to the regular .NETFramework,
he comments, citing the omission of more resource-intensive .NET mainstays,
along with what he says is “a horrendous bug” in the .NET Compact
Framework’s HTTP implementation.
Nevertheless, Davis concedes, writing .NETcode for the desktop or programming
for the embedded PocketPC using Visual Studio .NET, “mostly the same experience.
Some of Visual Studio’s handheld-specific tools are slow and buggy, but
many features, notably the debugger, behave the same.”
Things could get better for Davis when Microsoft ships Visual Studio .NET2005,
which is expected to deliver
a slew of embedded app dev enhancements, such as tighter integration with the
software giant’s new Windows
Mobile 5.0 technologies designed for PDAs, PocketPCs and cell phones.
Davis, of course, didn’t exactly pick up Visual Studio .NET and C# of his own
volition. Chances are, a lot of programmers will find themselves presented with
a similar Hobson’s choice. As Davis’ experience demonstrates, however, this
isn’t necessarily an unbearable situation. In some cases it’s one that even
seasoned embedded codejockeys take in stride.
Sidebar: Fighting
change is hard work
Sidebar: Fat is in,
with good reason
On ADTmag.com
Tools for Embedded Systems
Development
By John K. Waters
Embedded systems
evolving
By John K. Waters
Utility computing
throttles app dev's value
By Jeff Kaplan
ILLUSTRATION BY ANDREW JUDD