You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• Freebies and Discounts
• Not Writing Linux Code?
• On Subscription-Based Tools
• Is C Obsolete?
• Failure of the Week
• Jobs!
• Joke for the Week
• About The Embedded Muse

Tip for sending me email: My email filters are super aggressive and I no longer look at the spam mailbox. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me.

Dissing embedded: EETimes - EETimes! - has several recent articles claiming that DRAMs are "the chips used in virtually every electronic product". Really? I guess products using MCUs (Digikey currently lists 92,497 unique MCU part numbers) don't count. EETimes should know better.

When Herbert Hoover (to non-USA readers, Hoover was a US president) told a lady he was an engineer, she replied, “Why, I thought you were a gentleman!”

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

Antonio Martinez is a fan of Circuit Cellar magazine. I used to subscribe. It's unbeatable for hobbyist projects, and does often cover issues of interest to embedded pros. For me there's a bit too much fluff to dig through, though, as the saying goes, YMMV.

Tam Hanna and the kind folks at GigaDevices have given us two of their very popular GD32F470 evaluation boards for the giveaway. These boards use Cortex M4s with FPU and come with a camera interface.

Enter via this link.

Prepare to stuff Android into your next electronic toothbrush. Or not.

In a 2011 column in EETimes (no longer available, it seems) the author reports 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 he wrote 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.

A decade later that didn't come to pass.

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 reached a staggering level of complexity. As a result, 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, even a file system. A natural Linux/Android/Windows app, right? Well, yes, and indeed most 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. The article I cited amplified that in 2011. Yet Microchip, whose parts don’t run Android or Linux, thrives. 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. A weaker statement like "most will migrate..." is also wrong. The only generalization about embedded systems that’s accurate is that one cannot generalize about embedded systems.

And MCUs are a huge, growing, business.

In the last issue I commented about subscription-based tools. Paul Carpenter wrote:

Paul makes a couple of good points, not the least of which is that backwards compatibility is not something OS vendors seem all that concerned with. Over the years I've had many programs go obsolete simply because they won't run on more recent versions of Windows. In some cases even programs run from the DOS command line no longer function. My own MTBASIC (a multitasking BASIC compiler for embedded applications), which I wrote in the early 1980s and which sold some 10,000 copies, won't run on a DOS window anymore, though that's hardly a tragedy as it's hopelessly obsolete.

In the embedded space we often have to provide support for years and even decades; the rail industry routinely requires a guarantee of 30 years of support. How one accomplishes that baffles me. Even if you store a PC loaded with the tools in a closet, odds are the capacitors will go bad long before those three decades elapse. What about the developers? A middle-aged engineer will be long retired when a fix is needed decades hence. We hear about a shortage of COBOL programmers. What about a MANX C developer? Or a PL/M expert?

A number of people had thoughts about whether it's time to replace C from the last issue. Felipe Lavratti wrote:

From Pete Friedrichs:

 Finally, Jim Donelson sent this:

Olivier Betschi sent this scary item  :

 From Emberson Beserra:

Have you submitted a Failure of the Week? I'm getting a ton of these and yours was added to the queue.

Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.

These jokes are archived here.

The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com.

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.