For novel ideas about building embedded systems (both hardware and firmware), join the 30,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
Dumbing Down Embedded Design
Summary: If you believe the pundits, prepare to stuff Android into your next electronic toothbrush.
In his #include column in the July/August issue of this magazine (http://www.eetimes.com/discussion/-include/4218261/Dumbing-down-embedded-design) Ron Wilson reports that there's a feeling that virtually all embedded applications will go to Android or Linux.
He quotes one well-known wag "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 market." Later Ron says that chip companies are providing complete Linux/Android ports, so "embedded design" is more about writing a bunch of Java code to run on top of these operating systems.
I'm increasingly talking to semiconductor people who have teams writing vast amounts of code for their customers. The semi folks tell me their customers are demanding more than just silicon; they want complete solutions. The customers, though, tell me the problem is the chips are so complex, and so poorly documented, that it's impossible to generate a lot of the low-level application. When an 8 bit six pin PIC10 part requires a 200+ page datasheet, when an OMAP's datasheet is incomplete even at 4000 pages, it's clear that these parts have reach a staggering level of complexity. So many vendors have teams that supply complete Android/Linux ports. The idea is to get the customers up to speed quickly.
But the semiconductor people who are furiously writing so much customer code are mostly in the very high-end space. We're talking cell phones and products where chip sales are so huge the vendors' natural response to any request is "you betcha." While many vendors of smaller CPUs do provide software IP, the range of applications is so vast that they can do little more than create some drivers and the like.
Consider an oscilloscope: yep, there's a fabulous GUI, probably networking, maybe even a file system. A natural Linux/Android/Windows app, right? Well, yes, and indeed a lot do use these. But under the hood that instrument has an enormous amount of code devoted to sampling analog inputs, triggering, measurements and more, much of which has to run at insane speeds. Sure, some big-honking OS is there, but the soul of the application is in the data acquisition and the "scopy" features. The embedded part, the non-Linux code, is what makes the application an oscilloscope, and what differentiates it from a mobile phone or other product that uses Linux.
Billions of microcontrollers are shipped every year. Dozens of companies sell nothing but microcontrollers, be they little 8 bitters or Cortex-M series. There are literally thousands of different part numbers available. None of these will ever run Android or Linux due to memory limitations and the like. Are those markets going to disappear? Of course not.
In 2004 Jerry Fiddler of Wind River read the embedded market's obituary at the ESC. We're hearing it again now. Yet Microchip, whose parts don't run Android or Linux, has more than doubled processor shipments since then despite the worst recession in nearly a century. ARM licensees have created an entirely new market in small microcontrollers since then.
The range of applications enabled by embedded systems is so huge and the technologies employed are so diverse that blanket statements like "all apps will migrate to Linux/Android" are wrong. The only generalization about embedded systems that's accurate is that one cannot generalize about embedded systems.
Published October 20, 2011