The average embedded system uses a 32-bit microprocessor with 2Mb of RAM — or an 8-bit controller sporting 2k of program space. Nearly every embedded system today requires TCP/IP stacks — except for that vast number that live inside unconnected smart toothbrushes and other consumer appliances.
Most smart products get replaced or are become obsolete in months. No need to worry about maintainable code — except for the huge range of devices like instruments and industrial controllers that function quietly for decades.
Reliability isn't an issue; if the electronic coffee spoon fails there's little impact. Bummer about those pacemakers, avionics, and even car computers that must be near-perfect.
C++ and Java are the usual choices for firmware today. Except for the other 90% of the market that uses C and even assembly. Linux is the only OS with a future, though it's less important in the embedded space than Windows.
I see most of the surveys about embedded systems and find them baffling. The correlation from one to the next is weak, at best. The data itself seems peculiar. Do 20% of all embedded systems really run Windows? A 2000 poll suggested as much. Maybe it's true, but it's awfully hard to believe.
Survey questions are lousy, at best. What does it mean when x% of the respondents claim to use (for instance) C++? Is this in an embedded system (lots of us write desktop code, too)? How does the number translate into the number of units sold? Is one developer using Windows CE in a product manufactured in zillion-lots a huge part of the market or an insignificant player?
Consider 32-bit processors: they're a huge part of the market now, and are increasingly more important. But how many of those are consumed by relatively few consumer products (cell phones and the like)? Do PDAs, relatively large computers packaged in tiny boxes, count as embedded systems? If so, they skew the data substantially.
ASIC volume has skyrocketed, accompanied by growth in the sales of processors as IP components. Instead of selling a real “thing”, the IP companies provide binary files that describe the product, which customers incorporate into their unique silicon. The magazines rave about the ASIC revolution, yet how many developers really work with the million-unit quantities that make ASICs so compelling? 50? 100? The volumes are huge, but is that representative of the industry?
There's no doubt that the embedded market has changed dramatically as high-powered ultra-cheap solutions appear for high volume products. That does not mean that there's been a reduction in products sold by the tens, hundreds or thousands.
Our field resists generalizations. At any talk at an Embedded Systems Conference, attendees may be using tiny CPUs with minimal code needs to huge multi-megabyte firmware bases. One very popular class covers building big internet-connected apps while another talks about optimizing your use of C in small systems. People using FPGAs — a cool but relatively expensive customized logic solution — sit with ASIC folks. Any single developer may work on both a PIC and a MIPS, using assembly, C, C++, and Java.
Magazines and web sites respond to users' real needs, as best perceived by surveys and the like. But there's no “average” in the embedded space. It's not like the PC market where all developers have the same platform. How should a magazine deal with the vast range of applications, architectures, code sizes, tools, and complexity? Any ideas?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. He founded two companies specializing in embedded systems. Contact him at . His website is .
One magazine to which I subscribe is Circuit Cellar Ink (yes, I started this after Byte stopped carrying Steve Ciarcia) and they have the same problem with diversity. They handle it nicely by making each issue a mix of general-interest and themed articles, where the themes are targeted at different spots on that wide open spectrum of readers each month. So “theme” one month on fitting tricky stuff into little MCUs, “theme” the next month on no-limits TCP/IP implementations using Linux as the conceptual base, “theme” the next month on niche processor cores like M*Core, etc. Embedded Systems Programming already does “themes” but they could more often home in on a platform segment rather than an advanced college class topic.My $.02, anyway…
Director of Product Development
IRIS Technologies, Inc.
We use C (with a very small quantity of asm for cpu initialization), and see no need or justification for C++, Java, C# or any other flavours. Occasionally one might make a tool in C to run from the prompt in a DOS box on a PC. Our hardware includes Xilinx LCAs. We are obviously different to some of the other people you describe, in terms of the practical techniques we use but the engineering principles can't be any different. Therefore if the Magazine continues to address the engineering principles while doing the rounds of the various technologies in use throughout the industry it will still be relevant and useful. I think the basic needs of the industry are still engineering principles, quality management, and common-sense-over-political-expediency. Those who are practised in their respective technologies may be able to share knowledge and wisdom with others using the same technology – which will help a small proportion of the embedded community at any one time, and most competent engineers can find ways to solve specific problems (which is why they are hired as engineers to begin with); the best impact the magazine (and indeed your own most thinkworthy column) can have is to improve basic attitudes of engineering managers and engineers in influential positions.