Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
Issue Number 454, September 19, 2022
Copyright 2022 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com

   Jack Ganssle, Editor of The Embedded Muse

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

Contents
Editor's Notes

SEGGER Embedded Studio cross platform IDE

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.

Quotes and Thoughts

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!”

Tools and Tips

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.

Freebies and Discounts

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.

Not Writing Linux Code?

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.

On Subscription-Based Tools

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

Now that Microsoft eventually got away with it after at least a decade, with enterprises pushing back we now have subscription based OS. Even Chromebooks are effectively time limited landfill products with AUE dates.

Many tools are ALREADY subscription based especially in the CAD arena, most notable anything from Autodesk including the bought out Eagle, and Altium Designer.

Many are going to web based tools to hook you in then you can see subscription coming down the line.

In many serious markets (those with product life cycle of any model greater than one year!!), have other issues on rebuilding projects CAD or software as in markets like Medical, Avionics, and Military you need to be able to rebuilding bit identical version on any tool change before any modifications. How many of us rebuild all our old projects for support purposes on a version change ?

If you have to archive systems sorting out subscription service on an old system could take weeks as the new subscription will not work on an archived platform and insists everything must be on a new platform. Of course all the tools used on that project obviously still exist and are supported on new platforms NOT. Let alone will new monitors work with old system output of 640 x 480.

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?

Is C Obsolete?

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

One comment on “replacing C”, there are many new languages coming with the goal of becoming alternative systems languages. Most of them are still in beta, and their point is into getting the language right, learning from C and all predecessors. In my opinion it is not a matter of if, but when C will be somewhat phased, and become a stage or fallback language, as assembly has. I say that from looking into those new languages and reading their reasoning. As language enthusiast I fully recommend people to have a look at all these new system languages and the point their authors make against C and C++. Here follow a list: Jai, Odin, V, Zig and Beef. (Maybe Nim, arguably. It has GC, but that is optional) (Carbon is not in the list, for it not breaking with C++ type system). 

My point is, it is great time to be a developer  seeing all these smart folks reworking such fundamental infrastructure that we take as the normal and end up not experiencing the further joy into programming that more modernized approaches could provide. 

But then in a professional setting I don’t think we are anywhere ready to phase C or C++ out other than using Rust in some niche applications. 

From Pete Friedrichs:

My reaction to the “elimination” of  C…

A hammer is about as primitive a tool as you can imagine. Despite that, a hand sledge purchased from Home Depot today will not be substantially different from one uncovered at an ancient Roman archeological site. Why? Two reasons: (a) This tool converged upon an optimal design centuries ago, and (b) there are many tasks, even today, for which no better tool exists.  

Suppose now that somebody comes along and proposes “eliminating” hammers… the argument, you see, is that hammers are old, and heavy, and cumbersome. You can’t loosen a nut with one, you can’t paint with it, drill a hole, or display RMS voltage. Oh… and a hammer has no intrinsic safety mechanism to prevent a careless operator from smashing his own thumb. Surely, technological progress has provided “better” alternatives.

The argument appears to have merit, until you need to drive a brad into the wall in order to hang a picture: I suppose you could whack the nail into place with a more sophisticated tool--the head of a rachet wrench, for example, or your DMM, or the butt of a pistol--but why? Why do so, when you already have a tool optimized for that class of task?

At the end of the day, computer languages are simply tools… like hammers, screwdrivers, and wrenches.  There is no “best” tool, but there is a best tool for a given job.

I view C language as a trusty old hammer.

 Finally, Jim Donelson sent this:

Time to retire C?
No.

1. Works just fine for its intended purpose. While it does not have classes or inheritance we have developed idioms that serve the same function and there is not a good way to do that without adding overhead.

2. All embedded devices have one or more compilers, IDEs and debuggers that are well seasoned and understood.

3. C generates code with a deterministic execution profile that is easily knowable and understandable.

4. For me C++ was never a viable option for embedded applications (see 3 above). The problems with C++ are well known so I won't review them at this time.

5. And replace it with what? Rust? Rust is a systems programming language and seems to have it's own set of issues. At this time Rust compilers are not ubiquitous in the embedded world and I am not seeing a large uptake for embedded. Could be wrong about that, but it sounds like Rust has too much overhead and it's seems it is not easily understood.

For me the issues Jacob raises are non starters - me-thinks it's a bit of click bait.

The theory of gravitation is a bit dated too but for a large set of real world problems; it still works well. I hope being dated does not mean it's time to be discarded, as you and I are a bit dated.

"entry-level engineers who are often highly sought after by tech companies have little to no experience with C. University programs today focus on teaching modern languages like Python or C++."

Embedded projects don't really seek entry level engineers. University programs never really prepared students well enough for this context anyway.

"C  doesn’t support modern programming concepts like classes and inheritance" while this would be useful in some contexts, so far no language has managed to do this in a way that works for us.

Not to mention classes and inheritance and not really a modern concepts anymore.

"The last time the C standard had new features added was 2011" A good thing in my book.

The last thing we need is Garbage Collection. In my current job we are having fits with Java GC. It totally disrupts determinism and injects huge delays, which causes our queues to back up.

I also take exception to the TIOBE index. Why is javascript #7? I can assure you that more KLOC per day is written in JavaScript than any other language. I suppose it depends on how you choose to measure it.  PYLP has Python, Java and JavaScript as it's top 3 and C/C++ at #5, but they measure how often tutorials are searched for.

Failure of the Week

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.

Jobs!

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.

Joke For The Week

These jokes are archived here.

About The Embedded Muse

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.