Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
 Issue Number 477, November 6, 2023
Copyright 2023 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.

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

"You will say that I am always conjuring up awful difficulties & consequences - my answer to this is it is an important part of the duty of an engineer." Robert Stephenson, engineer of the Britannia Bridge.
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.

Here's a pretty cool article about calculating a square root in VHDL. The algorithms are particularly interesting.

Regarding the necessity of having a package's source code, T Sheffield wrote:

I find that in almost every instance, I'm more likely to value a product I'm considering buying if it comes with source code.  I'll pay more for it.  Despite the hassle of having to learn other people's code, I find that our very specialized needs are often not entirely met by off-the-shelf modules.  We regularly need to go in and make modifications.  Can't do that without the source.  Or sometimes we are trying to debug something mysterious, and even though the root of the problem is within our own modules, we don't discover that's the case until we've hacked up the code we bought and are able to gain a thorough understanding of how it works.  I've seen that process point us squarely back at where the problem really lies in our own stuff.  Again, that is all made more difficult with a black box.  

Now, when it comes to certified safety-critical stuff that is very well documented and proven and we don't dare touch ... well, that's an entirely different story I suppose.

Freebies and Discounts

This month's Cool Product is the H32 development board. Christos Apostolidis has kindly made one available to Muse readers.

Enter via this link.
More on Debouncing

Brian Cuthie responded to the article on debouncing in the last Muse:

Just for the record, people make switch debouncing seem a LOT harder than it is in practice. For Man-Machine Interfaces, the dominant factor is the required response time to a human, which is always >> the bounce time of the switch. The other thing is to treat switch actions are events. But many embedded SW people seem to get that wrong, too, which leads to all kinds of complex logic and spaghetti.

For almost all real applications, the following works just fine:

uint8_t  oldSwitchState = 0;
while(true)  {
               uint8_t  newSwitchState = readSwitch();
if  (newSwitchState != oldSwitchState) {
               if  (newSwitchState) {
               //  do whatever happens when the user presses the switch
               switchDownEvent();
               }
               else  {
               //  do whatever happens when the user releases the switch
               switchUpEvent();
               }
               }
               oldSwitchState  = newSwitchState;
//  this delay has to be longer than the settling time of the switch
               delay(100ms);
               }

Of course, this is a great example of how an RTOS can be helpful in an embedded system. You can put this in a thread of its own (possibly with some LED cadence management) and then the rest of the SW system just gets notified of switch events without needing to know how that happens. 
On Thinking Ahead

John Strohm on the importance of thinking ahead:

Back around 1994-1995, I had to do a driver, in Ada, for (I think) a Signetics 2650 DUART (Dual UART).  After some thought, I organized it as a set of three or four generic packages, one for the core functionality, one for each "side" of the DUART.  I had two basic ideas in mind.  First, I wanted the end user to be able to add functionality, if he decided he wanted to use a feature I didn't need in our system, and second, I wanted to be prepared for the inevitable memo from the hardware guys that they'd swapped sides: what used to be on port A was now on port B, and vice versa.

I still can't believe the amount of static I caught, from all directions, over that design.  First, they didn't like my decision to use generics, because the second-stringers in control had trouble using a debugger to work on a generic anything.  Funny: I'd never done a generic before, and I had no trouble with the debugger, but it MIGHT have had something to do with the fact that I went to some trouble to design the code in the first place, and I knew what I needed to do to check it all out.

They didn't like that I'd provided stubs for functionality I didn't need, but someone else might.  Well, if you're gonna instantiate a generic that includes provisions for that kind of expansion, ya gotta provide a do-nothing stub for the default case.

They didn't like that they had to instantiate three packages (Side A, Side B, and then the Core, using the Sides A and B instantiations).  Well...

The inevitable hardware memo came down.  Lots of groaning all around.  I changed two (2) lines of code, recompiled, and I was done.  It worked, perfectly, first time.

The real payoff came a year later.  A coworker, on a related project, had to pick up my driver and adapt it for their system.  Unlike our clown parade, he was good, knew what he was doing.  He told me one day, in passing: "Hey, I had to pick up your DUART driver for our system.  I had to add one line of code, to turn our drivers on and off, but, other than that, it dropped right in, no trouble at all."  (I had RS-422 lines.  They had RS-485 multidrop lines.)  I replied "Please, do me a favor.  Have your software manager write a memo describing that to your program manager, and copy my software manager on it.  I don't get nearly enough credit when things go right."

Crappy Code?

I stumbled across an article (alas, behind a paywall) by James Kwak, a law professor and not a software engineer, with the alarmist title "Software Runs the World: How Scared Should We Be That So Much of It Is So Bad?"

He seizes on the Knight Capital debacle to petrify readers, and makes the absolutist statement "The underlying problem here is that most software is not very good."

Really?

He’s right that software does run the world. However, the world in many ways has never run better. Remember travel agents? Now an airplane seat is just a few clicks away. How about that encyclopedia your young parents bought before you could even read, whose spines encased information that started becoming obsolete immediately? Today much of the world’s knowledge is available in your pocket on that smart phone. Then there is that phone - when I was young a long distance call was so prohibitively expensive that they were reserved for a rare business emergency or a death in the family. Today Skype gives us video chats into every corner of the world… for free. My 1966 VW needed a valve adjustment every 3000 miles, but my 2013 Prius, with 180,000 miles on it, still has the original spark plugs. TV was a handful of channels not long ago; today there are hundreds (though still populated with the same old crap) and other services deliver movies on demand. SCADA systems, though admittedly imperfect, literally control the world of industrial production.

Then there's the Curiosity rover. My dad, a mechanical engineer who did many Mars landing studies, once told me that if he had proposed such a gutsy mission he would have been fired. But the embedded software guided the spacecraft to a very complex autonomous landing. What a triumph of software and software engineering!

Ironically, Mr. Kwak lists his blogs and Twitter connections, concepts that would be impossible without software that works pretty darn well.

The author writes: "The question is how much you're willing to sacrifice in the name of quality." That is getting it exactly wrong. The entire thrust of the Deming revolution is that quality saves money.

Sure, software isn't perfect. What is? Regular readers know I’m passionate about improving the quality of our software-based products, but it’s important to step back occasionally and acknowledge our successes. In a single lifetime computers have gone from science fiction to the very fabric of our lives. The notion of not having hundreds of processors is today as absurd as the idea of owning any computer was forty years ago. Those machines are all quietly running software that works.

And embedded code works the best of all. The data shows that firmware bug rates are about an order of magnitude lower than for PC and IT applications. So developers stand up and take a bow! The average person - and law professor - would be utterly lost if your software were to suddenly disappear.
Failure of the Week

Ed Criscuolo sent this with a YouTube link. At that link the announcer smoothly states "Everyone in McKinney is dead".

Leon Bazdor sent this:

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

The H32 is an ultra-low power ESP32 platform which makes connecting additional electronics easy. According to the web site, most development kits have poor power management circuits and are not great for developing battery-powered applications. Instead, the H32 achieves low power in part by shutting down power completely when needed, giving a 9 uA idle. It has an onboard fuel gauge which turns power on in a low-battery situation, presumably to let the system do a controlled shutdown. $36 each, and more info is here. Code can be found here. This board is this month's giveaway.

Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors.
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.

A photon checks into a hotel and the bellhop asks him if he has any luggage. The photon replies, "No, I'm traveling light."
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.