Dumbing down embedded design - Embedded.com

Dumbing down embedded design

Like it or not, the abstraction in embedded systems design is changing, again.

Click image to go to digital edition.

When John Bruggeman left Wind River to become chief marketing officer at Cadence Design Systems, he didn't leave the embedded community so much as he shifted to a new phase of the industry's evolution. Neither did he leave behind his ear for a great sound bite or his ability to spot the trend behind the noise.

At the Design Automation Conference this June, Bruggeman showcased both these traits in one statement. We were discussing the struggle to increase the level of abstraction in embedded systems design, and he remarked, “This whole fragmented, RTOS-tied world is shrinking. We are coming to the point where only a handful of mission-critical applications will use an RTOS and code developed in C/C++. Everything else is going to the Linux/Android world.”

Bruggeman's concept is that the Linux port, libraries, drivers, and tasks with hard deadlines are becoming the responsibilities of the IC vendors, not the embedded systems developers. All this work gets done once per chip family, before a new MCU line or SoC is introduced–not once per application. When an embedded design team selects a chip, the IC comes with a platform such as Android or AUTOSAR (the AUTomotive Open System ARchitecture, if you haven't been following that industry) already running. The embedded systems design team writes their application in Java, just as if they were writing an iPad app. All of the complexity of machine-dependent and time-critical code is encapsulated by the chip maker.

This may sound infeasible and undesirable. But please remember that we've seen this shift before. Skilled assembly-level programmers objected–rightly, but irrelevantly–that compilers could never generate the code quality they could for embedded systems. Crafters of bare-metal code and application-specific kernels railed–with equal justification and effect–that no off-the-shelf RTOS could be as efficient and reliable as their creations. All were swept away into niches where their expertise was defensible. Today there are few surviving practitioners of either assembly-language programming or proprietary kernel development who are not working for an RTOS vendor or–increasingly–a semiconductor company. “Between Portland and Alameda, Intel alone has about three thousand software developers,” Bruggeman observed.

So what is the future for skilled craftspeople who know an RTOS or three inside-out, are black-belts in C or C++, and can deploy linked-list structures, hash tables, complex interrupt schemes, and similar joys to actually save memory and slash energy consumption? You need a strategy.

One approach would be to embrace the future: use your skills to become a black belt in Android development, or an AUTOSAR guru. Another would be to find markets likely to be late adopters because of hardware or legacy-code limitations, power constraints, or cultural isolation. This can delay the inevitable, but it has about it a bit of striping the road in front of the steamroller. Or you can join a semiconductor company. But I don't suggest denial. Whatever you decide, don't just sit there.

Ron Wilson is now editor-at-large on EDN magazine. This is his last #include as the editorial director of Embedded Systems Design. You may reach him at .

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.