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
• Quotes and Thoughts
• Tools and Tips
• Freebies and Discounts
• Interesting Contact Debouncer
• More on Turnover and Retention
• To Source, or Not to Source
• Failure of the Week
• Jobs!
• Joke for the Week
• About The Embedded Muse

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.

Tolstoy: I know that most men, including those at ease with problems of the greatest complexity, can seldom accept even the simplest and most obvious truth if it be such as would oblige them to admit the falsity of conclusions which they have delighted in explaining to colleagues, which they have proudly taught to others, and which they have woven, thread by thread, into the fabric of their lives.

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

High-end processors need a lot of power, on the order of hundreds of amps. This article is an interesting survey of the requirements advanced cars and AVs will place on power supplies.

Jonathan Morton, replying to the last issue's take on bfloat16, wrote:

The folks at ORBcode are generously giving away one of the debuggers for Cortex M devices. I have not tried this, but it looks quite interesting.

Enter via this link.

M. Simon sent this interesting idea for a contact debouncing circuit. There's more info here.

RS Latch Eliminates SPST Debounce Time as the RS Latch does for the SPDT.  Further explanation below the schematic.

An SPST switch is made to act like a SPDT by selecting the SR Latch terminal that will drive it to the opposite state when the switch changes position. The XNOR insures the logic is correct in each state. The logic terminal selected doesn't change until after debounce time. I'm multiplexing the switch between /PRESET and /CLR. So it acts like a SPDT. When the SR Q = 1 the switch is connected to /CLR and when the SR Q = 0 the switch is connected to /PRE. After a debounce delay.

T Sheffield had some thoughts on employee retention after reading Muse 470:

Colin Walls recently wrote an article about whether or not one needs the source code of a commercial product. This is a contentious issue that people have strong opinions about. Once upon a time, hardware people designed all of their circuits.  But in the vacuum tube days some wise engineer created modules. An example was a dual triode flip flop that would generally plug into a standard octal socket. Now others could reuse that design by buying the module and including it in their product.

Later the integrated circuit formalized this notion, and today there's a veritable ocean of standard parts available. Datasheets carefully characterize their behavior; we buy them and wire them onto a board.

That's the holy grail of reuse, and in some cases the software community does the same thing. We recycle an object module and link it into a new application. Alas, for reasons both good and bad we often monkey with the source instead, even though NASA has shown that once one changes more than about 25% of the source lines there's little benefit to reuse.

Traditionally, vendors who supply proprietary code that will be included in a production system (like protocol stacks, operating systems and the like) provided libraries compiled on a particular CPU architecture. You link these into your code. But for as long as I can remember engineers grumbled that the provided API was both interface and insulation. Insulation, because who knows what boundary conditions lurk behind the often-inadequately documented API? Insulation, because it can be impossible to track down bugs that live in the nebulous region between your own code and that of the vendor.

Who hasn't gotten frustrated by the poor docs that sometimes cause us to prototype an API call, tossing almost random data at a package in an attempt to understand just how one goes about properly interfacing to a package?

We see it in the hardware, too, when a peripheral’s control registers either don’t work as advertised, or there’s some bizarre combination of bits that drive the thing into a crazy mode.

And yet there’s a part of me that doesn't want exposure to the internals of some other company's code. I really don't want the source; I want a clean, clearly-defined interface that works as advertised. Returning to the hardware analogy, it's fun but unnecessary to look at the schematic of a flip flop. The interface at the pins is really all that is important.

But in the software world we've all been burned enough that trust is scarce.

Then there's the stability issue, especially in these strange economic times. If I have a package's source there’s much less risk if the company goes out of business. I may not want to support the code, but that's better than getting set adrift by the seller's bankruptcy. Yes, it’s possible to set up a source code escrow, but what are the legal implications of dealing with that escrow? Why add layers of hassle?

What do you think? Is not having the source a deal-breaker? Or, conversely, does the source make a vendor's product more compelling to you?

From Tyler Herring:

From Mark Peterson:

I ran into this speed demon on Prime Day:

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.

These jokes are archived here.

If it ain't broke, fix it till it is broken.

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.