Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
Issue Number 444, April 18, 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 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.

Bob Paddock notes that Capers Jones will be giving a free webinar called "Accurate Measurement, Accurate Estimating, Excellent Quality" on Wednesday April 20. Jones is the guru of software engineering metrics, and I suspect this will be of great interest to all software engineers.

And don't forget The Embedded Online Conference which takes place next week. I'm giving a talk titled "Learning From Disaster". The cost for the entire conference is $190, but if you register here with the promo code GANSSLE it goes down to $149.

Quotes and Thoughts

There are thousands of ways to mess up or damage a software projects, and only a few ways to do them well. Capers Jones

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.

Andrzej Telszewski wants to clarify a comment made in the last issue:

Based on the story in TEM 443, a TEM reader might incorrectly think that C++ is slower than C. It is not.

If the code in C++ was written without using heap, it would _most_ probably meet the requirements of the 1-Wire protocol.

It would _certainly_ meet them if it was further optimized by removing abstractions, which I guess used virtual functions. But I would first benchmark it to see whether the abstractions can stay and make the code benefit from a better structure.

Please don't understand me incorrectly -- I don't imply that the many levels of abstraction that were present in the 1-Wire driver were OK -- but some were actually OK.

On the other hand, if the code in C was written making use of _malloc()_ all over the place, it would perform as poorly as the C++ code using heap allocations.

Today, C and C++ run equally efficient provided that we use features that can be actually compared apples to pales. It's about incorrect use of C++ and not it being slow.

C vs C++ -- let's not go there again! :-)

Freebies and Discounts

April's giveaway is a DMM.

Enter via this link.

The Worst Invention Ever

Last month I mused about the how interruptions destroy productivity. That generated a fair amount of email dialog, mostly too personal for publication.

Alas, interruptions are aided by the productivity killers we embrace. Sometimes I think the telephone is the worst invention we've created. Now aided by email, Twitter, texting and a myriad of other technologies, the telephone and its ilk ensures that we never get a few minutes of peace in which to carefully think through a problem.

It's astonishing how rapidly the telephone has changed life. My grandmother grew up in Manhattan. When she was young she knew someone, across town, who had a phone.

When I was a kid it was illegal to own a phone in this country. Ma Bell leased them to consumers, and most homes had just one, a black, rotary dial device enshrined on its own stand. An out-of-state call (always for dad) brought the family to a standstill. "It's long distance" were the words that hushed all, and made us wonder what was of so much import it deserved such an expensive and rare call.

At the 1965 World's Fair in New York an exhibit touted the new push-button phone, and offered a chance to compare dialing speeds. My brother was so puzzled by this novelty that he was unable to "dial" a number in the maximum time allotted.

But now every desk has one. We all have at least one mobile phone at hand at all times, to the extent that cars are now telephone booths on wheels. (Remember telephone booths?). Though in many States the driver's use of hand-held phones is outlawed it's hard to miss the hoards of vehicles swerving between lanes as the driver takes that oh-so-important call.

The mobile is no longer a phone; it's an appliance that feeds a great number of streams of chatter to us. Each beep, tweet, text and call is an interruption, one that breaks a train of thought (assuming one has the time to form such a train). Each is demanding of our attention. I constantly see people walking with their gaze entirely on the little screen, inevitably bumping into still objects or other pedestrians.

The modern telephone, especially mobile phone, is a marvelous device of great complexity that offers an amazing array of capabilities. But it's a tool. We have a responsibility to manage it, like any tool, for both safety and to maximize our productivity.

I'm reminded of a story: An old farmer and a young farmer are talking about farm-lore, and the old farmer's phone starts to ring. The old guy just keeps talking about herbicides and hybrids, until the youngster interrupts "Aren't you going to answer that?"

"What fer?" Says the old-timer.

"Why, 'cause it's ringing. Ain't you gonna get it?" asks the younger.

The older farmer sighs and knowingly shakes his head. "Nope". he says. Then he looks the younger in the eye to make sure he understands, "Ya see, I bought that phone for MY convenience."

Most of us regard the ringing phone as an emergency. Drop whatever you're doing and grab it! Stop all conversation, abandon the meeting, and respond to what is all too often some salesman pushing cheap phone services or car warranties.

As I mentioned in Muse 442 DeMarco and Lister's research outlined in their book Peopleware makes it clear that responding to this electronic chatter and all of the other interruptions that represent a sensed exigency of the moment cuts software engineering productivity to a third of what it should be.

I'm not sure of the veracity of this story, but long ago I read somewhere that the Amish are not so much tech-adverse as they want to control its impact on their family and religious lives. Some have a phone, but it's in a little outhouse-like shed a hundred meters from the house, so its ringing won't interrupt family dinner time. It's pretty hard not to respect that.

Our electronic assistants are great tools, but only when we manage them responsibly.

More on Technical Writing

Last issue's musings on "convincing them" (i.e., technical writing) generated some interesting conversation. Mike Coffman wrote:

Your admonition to "Edit your work mercilessly" reminds me of a favorite quote, whose oldest attribution seems to be to Blaise Pascal (in French, of course):

"I have made this [my letter] longer than usual because I have not had time to make it shorter."

I would add another rule to yours: Put your big point and call to action in the first paragraph, even into the first two sentences.

During my life and career I seemed to have spent a lot of time editing my written communications to be concise and clear.  Yet, even after that, I would have readers that would not read past the first few sentences to reach the gems in the second or third paragraph.

I adopted a practice of writing to build my case in an orderly fashion, climaxing with my conclusion and my "ask" at the close, then moving the essence of that paragraph to the top in order to be seen before my reader's attention drifted away.

Jon contributed:

I see your article re. Convincing "Them".

Technical writing ISN'T difficult, but I've frequently seen poor grammar, expression and (especially) spelling from colleagues who are smarter and better educated than myself.  I see things like your example written as "Metre a displays the currant voltage" - which sails through the spell checker unhindered.
Unless documentation is proof-read by someone independent and literate, it can often sabotage the technical matter it aims to support.  Technical writing and user interface design share important communication principles, with "user- domain vocabulary" possibly the most commonly neglected.

Pictures are good - each worth a thousand words - which is why a modern GUI is preferred to a character based interface displaying "?" and a blinking cursor.

A skilfully designed GUI may free users from character-based interaction altogether.

John Kougoulos makes a good point: we're all salespeople. It grates to admit this, but you're selling when applying for a job, when asking for a budget, and when negotiating features. He writes:

About the persuasive documents, I have found out that many of the concepts written in the book of Daniel Kahneman "Thinking, fast and slow" provide very good hints on where and how to emphasize on the documents/presentations in order to get the result you want. 

Psychology is probably not the first thing that comes to an engineer's mind, but in that case he/she is a salesman :)

Vendor Libraries and More

Since nearly the earliest days of microcontrollers, engineers have complained about vendor libraries. Some of those complaints have been echoed in the Muse over the years. Bob Paddock sent along some comments about this and some related issues:

I've looked at the Process Expert generated code that Bernd is discussing below. It was incomprehensible.  I see far too many people, particularly younger developers, relying on IDE generated code.  What happens when the Lawyers show up?  'I did not know that was in my code, it came from the tool'...

"The main obstacles I encountered were the miserable and incomplete documentation of the Kinetis USB peripheral and a complete lack of any official example code (code that demonstrates the usage of the peripheral itself and not code that merely demonstrates the incredible ability of Freescale engineers to build monstrous Layers upon Layers upon Layers of convoluted abstraction and indirection that becomes evermore obfuscated and bloated with every new version), so quite some reverse engineering and trial and error had to be done to understand the USB peripheral and still not all questions are answered." - Bernd Kreuss-- https://community.nxp.com/thread/437591

Jack, how much high quality bug free code have you seen come from vendor libraries and IDEs?

Me, very little.  While IDEs are great if your motivation is fast out the door, they fall short if you want to do anything safety related. Other than looking at what they do for initiation code, I don't use them, and I don't even use the initialization code directly.  It is my ass on the line when something fails, not some unknown IDE/library author.

Indirectly related is this unfolding mess: Read this and the mounting comments under it, for the next few days:


Read the code and importantly the comments under the code:


This type of stuff is WRONG, hurts innocent people not government politicians, it is also illegal.

We and others can get drawn into lawsuits with such code if there are automatic dependencies updates.

Revlon Cosmetics vs Logisticon,  already set a precedent that sabotaged/booby trapped code is illegal, and has been for about the last 30+ years; see the Risk Digest archives. More info: "Self-Help Remedies for Software Vendors" by Henry Gitter in the January 1993 issue of The Santa Clara High Technology Law Journal.Vol 9, Issue #2. https://digitalcommons.law.scu.edu/chtlj/vol9/iss2/2/

Te Aka Matua o te Ture
Report 54
May 1999"


Of course there are modern updates, those show the thinking of that era and that this kind of protest hacking has been illegal for a very LONG time.

Failure of the Week

From Alan Kilian:

I know inflation is bad, but infinity? Marcos Gonzalez sent this:

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.

An engineer, a psychologist, and a theologian were hunting in the wilderness of northern Canada.

Suddenly, the temperature dropped and a furious snowstorm was upon them. They came across an isolated cabin, far removed from any town. The hunters had heard that the locals in the area were quite hospitable, so they knocked on the door to ask permission to rest.

No one answered their knocks, but they discovered the cabin was unlocked and they entered. It was a simple place. Two rooms with a minimum of furniture and household equipment. Nothing was unusual about the cabin except the stove. It was large, potbellied, and made of cast-iron. What was strange about it was its location. It was suspended in midair by wires attached to the ceiling beams.

"Fascinating," said the psychologist. "It is obvious that this lonely trapper, isolated from humanity, has elevated this stove so that he can curl up under it and vicariously experience a return to the womb."

"Nonsense!" replied the engineer. "The man is practicing the laws of thermodynamics. By elevating his stove, he has discovered a way to distribute heat more evenly throughout the cabin."

"With all due respect," interrupted the theologian, "I'm sure that hanging his stove from the ceiling has religious meaning. Fire LIFTED UP has been a religious symbol for centuries." The three debated the point for several hours without resolving the issue.

When the trapper finally returned, they immediately asked him why he had hung his heavy potbellied stove from the ceiling. His answer was succinct. "Had plenty of wire, not much stove pipe."
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.