Click here to go to the on-line version The Embedded Muse 488

The Embedded Muse Logo The Embedded Muse
Issue Number 488, April 15, 2024
Copyright 2024 The Ganssle Group

Editor: Jack Ganssle,

   Jack Ganssle, Editor of The Embedded Muse

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

Editor's Notes

SEGGER embOS Ultra Cycle-resolution accurate RTOS

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" in the subject line your email will wend its weighty way to me.

The next advance in chip making? A "gate all around transistor." Article about this here.

Jacob Beningo's recent article about the popularity of Rust in the embedded world is interesting. He says today 70% of teams use C and 23% use C++. I looked at my historical data from a survey in 2010 in Back then 60% used C, 20% C++. So the numbers haven't changed much in a decade and a half. One could argue that we are resistant to change... or that C/C++ are still the best solutions for most embedded projects. I've given up C for non-embedded work in favor of Python, and Rust is certainly interesting. But they are basically non-starters, at least for now, in the embedded world.

Here's a very interesting article about what we must do to use C++ more securely.

Quotes and Thoughts

Programming will remain very difficult, because once we have freed ourselves from the circumstantial cumbersomeness, we will find ourselves free to tackle the problems that are now well beyond our programming capacity. - Dijkstra

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.

  I'll be speaking at the upcoming Embedded Online Conference.This will be great fun, and it will be my last embedded speaking event.

Downloading AI-generated code? Better be careful. This article is thought-provoking.

Kobus Steyn, responding to a query in Muse 484 about dysfunctional teams, wrote:

I have been working for the same company for 20+ years, fortunately I have not been on a team with such lack of care and focus. I have however worked on teams where we had to work significant overtime. You are very mature to realise that this will have a negative impact on your wellbeing. Studies anyway show (as Jack have published previously) that working 60-70 hour weeks is only effective for a short period of time, thereafter you are so tired you could have just worked 40 hours a week from the start. One should only work overtime for genuine unforeseen problems and NEVER for lack of good planning or because other people are doing the minimum they can.

I agree with some of the previous responses. You will not get good mentoring in this type of team, look to transfer to another team or another company if you have tried to improve the situation without success. You will only know what other opportunities are available if you start looking around.

This experience is however invaluable  and when you do find a new team or company which is mature and works together well, you will be able to appreciate it. Often people do not appreciate a good team and leave for better money and end up in a bad team.

What We Have Not Learned

Greg Bollendonk sent a link to a report from 1977 about the software development used by the Viking Mars landers. Its 300 pages make a number of useful recommendations for future software programs using the lessons learned in Viking. A few stand out; alas, today, half a century on, these are still too often neglected:



Frequent correspondent Charles Manning always has something inciteful to say. He wrote:

I would like to take you to task somewhat on the late and buggy firmware. You provide some articles to back up these claims, but there's nothing newer than 20 years ago.

I would have agreed with you back then, but now I think complexity is by far the bigger enemy these days.

In that time there are so many things that  have completely changed the nature of defects. Straight critical programmer errors (what I tend to think of as real bugs) are less frequent. Some of this is due to improved test regimes, using operating systems with bounds checking, better compiler warnings and many other factors.

One large change is that much of what is now considered "firmware" is actually application software. Many, if not most, complex embedded devices are now running Linux of such and are really high end computers (compared to 20 years ago). Most of the programmers are now software-oriented people with software training rather than EEs who did a 6 month course in programming.

So the "dumb stuff with pointers" and other coding problems have diminished (relatively speaking).

Instead I think the massive increases in complexity give us far more system integration problems:
* Subsystem A is bug-free and works fine. So does subsystem B. But when they are plugged together unexpected interactions cause the system as a whole to fail.
* If you have a remote Bluetooth device interacting with Android and iOS, you might test it and it all works great, but then a subtle timing difference in a new Android/iOS version causes it to fail.
* Increased complexity means it is easier to forget to specify or cater for some required features.
* Increased complexity makes it harder to test different use cases especially when different regulations kick in across the world.

A modern cell phone maybe has 5 different cell bands as well as FM radio, two Wifi bands, Bluetooth (Classic and LE), GPS. That's a lot of radios (before we even consider the unintentional radios such as DDR buses, power supplies, ...).

So much of this is changing very rapidly. Very few products will ship with the same set of specifications/requirements that they started with.

Often the complexity is such that the marketing team determining requirements do not sufficiently understand the technology and their customers' problems to make solid specs. And the engineers likely don't either. Instead they end up learning during the development.

Thus it is not surprising that often specifications and requirements change, leading to massive project blowouts.

I of course recognise that different people have different experiences, but that's been my experience on the last few projects I have worked on over the last 10 or so years.

Failure of the Week

From Doug Abbott:

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.


Joke For The Week

These jokes are archived here.

Vlad Z sent this. I remember when it ran in the print edition of Embedded Systems Programming.

About The Embedded Muse

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

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

Click here to unsubscribe from the Embedded Muse, or drop Jack an email.