Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
Issue Number 428, August 16, 2021
Copyright 2021 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 jack@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

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.

Quotes and Thoughts

John Carter's Law: "Arguably a check can be buggy and hence fire unnecessarily .  But it's far better to pinpoint the exact location of a bug, making reproduction and finding and fixing fast and deterministic, than let a sporadic unreproducible bug escape into the field."

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.

In response to an article in the last Muse, Johan Kraft writes:

Regarding the debugging tip by Todd Mizenko - ring-buffer event logging. This approach is actually provided by several trace tools, so you don't need to implement it yourself. In our tool Percepio Tracealyzer we call it "snapshot mode", and the same approach is also offered by e.g. TraceX and LTTng. This can be used during debug sessions in basically any IDE. When halted on a breakpoint, a snapshot is taken from the ring-buffer using the normal debugger connection (e.g. the "dump" command in gdb), allowing you to see the most recent history of the system execution, up to the current state (an error handler, or similar). An advantage of using tracing tools is that they allow for visualizing the data, which makes it easier to understand the data and spot anomalies in the event patterns. 

Freebies and Discounts

Kaiwan N Billimoria has a new book out named Linux Kernel Programming, and it's a heck of a volume. At 741 pages it is very comprehensive. The book is very well-written and Kaiwan makes working on the kernel crystal clear, starting with basic concepts and giving detailed examples. If you've never built the kernel he goes through the process step by step. His follow-on book Linux Kernel Programming Part 2 - Char Device Drivers and Kernel Synchronization is about creating user-kernel interfaces, work with peripheral I/O, and handle hardware interrupts. Kaiwan kindly sent both books for this month's giveaway.

Enter via this link.

On Systems Descriptions

Daniel McBrearty responds to the last issue's note on maintainability:

Hi Jack - you hit the nail on the head again with your note on language. I personally think human language is really important.

In my early days as an EE, before I turned to software, I was taught a really invaluable and simple skill, which I've found to be often overlooked. That of writing a System Description.

I was taught that you should be able to give a decent high level overview of a system, what it is trying to do and how it aims to do it, in 5 to 20 pages of well written text, with a few diagrams. This should be written early on and maintained. 

The idea is not to go into gory details, but just give a total newcomer a decent idea of what is going on. It also has the huge benefit of clarifying your own thoughts, and often the process of explaining things in simple terms throws up a surprising amount of questions and subtle issues. Breaking the system into the right building blocks and having the most sensible interfaces between them is a huge deal and making it simple and elegant takes work and iterations.

I believe that this applies to hardware and software, or a mix of the two, just as well. And it's just amazing how often I find myself at systems where no such document has been written, or where it is muddled and much too complex.

If you can't explain in reasonably simple terms how a thing is supposed to work, your chances of making it do it are compromised.

This should happen before a single line of code is compiled (except perhaps proof of concept stuff).

I agree. If you can't describe a system in clear vernacular then you shouldn't be implementing it. So often a developer will start building a project without a clear idea of where he's going. It's sort of like scratching one's head and thinking, "well let's try void main() and see what happens."

Long ago I traveled with a failed engineer-turned-marketer. We'd meet with a potential client who would start outlining a problem and before we had a good idea of what was wanted, he'd start telling all that we'd use such-and-such processor at so many MHz.

I never saw him close a sale.

His boss, who knew little about anything, consequently listened intently and let the techies back in the office come up with a proposal. He was pretty successful.

Dumbing Down Engineering Education

David Laurence writes:

There are moves in the UK to tear up the engineering education rule book to broaden appeal and embrace people lacking a maths/ physics background. Olin College have pursued a similar approach in the US – problem based learning essentially (or how most engineers solve every day challenges post graduation !).

I respect nations' sovereignty so won't comment on the UK. However, there are similar moves here in the USA which strike me as rather short-sighted. I see two basic versions of this.

The first is an attempt to teach "coding" via some abbreviated schedule. Some of that is just HTML or CSS which doesn't require much erudition.

The second is more concerning. Dumbing down the engineering curriculum by trimming math and science strikes me as a disservice to the student and to society in general. As a certified Old Fart I know that few engineering students really know what sort of work they will be doing. Some will design factory automation equipment. Others medical gear. Or smart toys. There are hundreds or thousands of embedded product domains and an engineering education simply cannot train anyone for all of these.

What schooling can do, however, is give the student a good grounding in the sciences and math that can translate into any of these areas. I hated chemistry in college but spent years designing gear that did chemical analysis of the output of a factory. Physics enabled me to build devices that interacted in predictable ways with the real world.

What about math? How often do you use calculus? For me, hardly ever, maybe once or twice a year. Or differential equations? Pretty much never. But those have been useful many times in reading - and understanding - scientific papers upon which some designs were based.

This weekend I driving, mind idle, and wondered what fraction of the sun's output hit the Earth. But, embarrassingly, I couldn't remember the formula for a sphere's area. It occurred to me it had to be the first derivative of the volume, (4/3)πr3, a trivial calculation.

An engineering education parsimonious in math and science won't prepare the student for a career of invention and understanding. Sure, you can write code like a casual chef, following detailed cookbook instructions. Only a well-educated engineer can write that cookbook.

Rage Against the EULA

A couple of readers have written complaining about EULAs. I wrote this a decade ago:

Maybe it was a slow news day. Tiger was in rehab. The Salahis were hiding behind the 5th. Whatever, I was installing a tool chain and actually read the license agreement, always a bad idea unless one has a strong appetite for the absurd. At 4646 words, some seven pages, riddled with lawyer-speak, it sure appears designed to induce narcolepsy.

The vendor is a great company with a marvelous product, and has provided fantastic support. And I'm a big believer in the legitimacy of copyrights. But these so-called EULAs have become outrageous.

First, the EULA is titled an "agreement." While it meets the definition of that word, it feels much more like coercion. There's no provision to modify the language in even the slightest form to fit the technical or legal needs of the customer. The "agreement" spells out all of the vendor's rights and none of the user's.

Secondly, the sheer length of said "agreement" insures few will read it before clicking the "accept" button. Of course we have a responsibility to read and understand contracts. But confronted with a blizzard of fine print every day, it's awfully hard to do so.

Then there's the provision that we, mere engineers, agree to bind the entire corporation to the terms of the EULA. Huh? That's probably not legal, certainly not likely, and is sure to get one fired if the boss finds out we're making such commitments.

The "agreement" stays in effect for an "indefinite" period in time. That word means either forever, or for a neither precise nor exact time period. That sounds like somewhere between a microsecond and eternity, so means nothing.

One is further required to keep records of the use of the software. Do you?

Finally and perhaps most importantly, the only warranty given is that the media will be defect-free. I downloaded the stuff, so even that weak guarantee is pretty lame. Would you buy an appliance whose only guarantee is that the box it is shipped in will be intact? To quote a pithy section from Software for Dependable Systems – Sufficient Evidence?,  "No software should be considered dependable if it is supplied with a disclaimer that withhold the manufacturer's commitment to provide a warranty or other remedies for software that fails to meet its dependability claims."

Many see EULAs as more motivation for the use of open source software. But proprietary tools do have an important place in this business.

Failure of the Week

A two-fer:

Scott Rosenthal sent this:

And Ed Criscuolo was in a horrific heat wave in Maine (this is the USA so all temperatures are in °F):

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.

John Carter sent this:

A software engineer, a hardware engineer and a department manager were on their way to a meeting in Switzerland. They were driving down a steep mountain road when suddenly the brakes on their car failed. The car careened almost out of control down the road, bouncing off the crash barriers, until it miraculously ground to a halt scraping along the mountainside.

The car's occupants, shaken but unhurt, now had a problem: they were stuck halfway down a mountain in a car with no brakes. What were they to do?

"I know," said the department manager, "Let's have a meeting, propose a Vision, formulate a Mission Statement, define some Goals and by a process of Continuous Improvement find a solution to the Critical Problems, and we can be on our way."

"No, no," said the hardware engineer, "That will take far too long, and besides, that method has never worked before. I've got my Swiss Army knife with me, and in no time at all I can strip down the car's braking system, isolate the fault, fix it and we can be on our way."

"Well," said the software engineer, "Before we do anything, I think we should push the car back up the road and see if it happens again."

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. can take now to improve firmware quality and decrease development time.