When Embedded Systems Programming debuted, embedded systems constituted a niche carved in the electronics industry.
Just to make sure we're all on the same page, by embedded systems we mean products with microprocessor-based control systems. We're not referring to memories embedded into ASICs any more than we mean reporters embedded into units stationed in Iraq. And we're not referring to hard-wired controllers either.
Embedded developers were those few electrical engineers who possessed a unique expertise in the arcane business of real-time development and had some facility with assembly language programming. They were the ones who made it possible to add microprocessor-based control to a few specialized products.
The exclusivity of embedded systems is now a thing of the past. Nowadays virtually all systems containing electronics sport a processor, so the term embedded system can now apply to practically any product with an electronic control element.
The scope of embedded systems development has undergone significant changes over the years. Software now makes up a much larger part of system functionality. Assembly language usage has declined, having been supplanted for the most part by C or C++ except for very low-level work. Developers bring software design tools into play to help them wrestle with huge designs. They have APIs to write to.
The expertise of developers is changing as well. CS folks are joining the EEs at the table. Moreover, the diversity of processor architectures and software tools seems to be dwindling in the transition from 8- to 32-bit systems. A few architectures and a few tool families and operating systems are gobbling up more of the available opportunities.
A few weeks ago, Jack Ganssle wrote a column called “The demise of the embedded generalist” in which he says that the embedded universe is so broad, that developers need to specialize on one facet within the field.
As compilers and real-time operating systems travel their inexorable path toward commoditization, vendors are differentiating by adding middleware appropriate to particular products or industry sectors. See the story about mobile middleware.
In fact, that seems to be how embedded is playing out. The focus seems more and more to be on industry sectors than on “embedded.” You can see that happening at the embedded systems conference as design seminars focusing on particular technologies and applications begin to emerge.
Three or four years ago when embedded tool veteran Jerry Fiddler said that there is no embedded market, it seemed like heresy. But he was right. “Embedded” in the sense that we use it is a group of technologies that serves a number of markets, including automotive, communications, mil/aero, consumer, medical, and the like.
Granted many of the fundamental challenges are common across all embedded systems, but complexity fosters greater specialization. Vendors of real-time operating systems and tools now package their products to serve particular industry sectors. A story on Embedded.com this week is just one of many examples of how companies pitch their products at particular industries.
As a side note, increasing software content raises safety concerns. Jack Ganssle has recently addressed software safety in his column “Who's at fault when code kills.” You might want to read not just his column, but the responses it has elicited as well.