Embedded App Dev at the Crossroads

Talking Points

  • 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

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