Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
Issue Number 476, October 16, 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.

Editor's Notes

SEGGER Gang Programming Solution

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

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.

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.

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:

AMD also supports bfloat16 in its latest GPUs, as these are used in their AI acceleration products.  The latter are distinguished by an emphasis on memory bandwidth with the installation of HBM stacks, which are too expensive for consumer GPUs.  Those continue to use conventional GDDR chips, controlled by a different type of cache/interface chiplet but paired with the same compute die.  This allows AMD to get better economies of scale on their compute dies - their "chiplet strategy".  It's very interesting but not very widely known.

AFAIK, the bfloat16 support is also available on the consumer GPUs, if anyone wants to experiment with them.

Freebies and Discounts

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.

Interesting Contact Debouncer

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.

More on Turnover and Retention

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

Hi Jack, I saw your reader question about turnover and retention.  It's something I've been researching for years.  Here are my thoughts.

I think there is some truth to the idea that because of communications technology we are more connected than in the past and it's easier to learn about competing opportunities, so the younger generations are growing up with that FOMO mindset.  But it's also true that as a general rule people don't enjoy having to change jobs or move homes and the interview process is miserable.  

There's an old adage that people only leave jobs because they are looking for something they aren't finding at their current job, and the onus is on the employer to provide that.  The vast majority of companies seem to just completely ignore their employees that are telling them what they are interested in doing, how they want to grow, etc.  And companies are no longer interested in keeping people around long term.  Just look at the change in pensions, the prevalence of open office floor plans (notorious for high turnover, nobody wants to stay in a place like that), the lack of stock options/equity and/or profit sharing.  I've worked for a big public firm that did regular massive hire/layoff cycles.  Those companies are not designed for keeping people around long term anymore.  They view engineers as so many interchangeable cogs that all function more or less equivalently.

Companies are led by just a few people at the top and they make all the decisions and stick strictly to what they know.  Young employees are interested in pivoting to new challenges and new industries but when they suggest a new product idea to the business development leaders, they are typically just shot down with rote explanations about new ideas falling outside the brand purpose and domain expertise.  That's fine, but it will cost a company young talent to hold that line as new hires seek people that will let them explore and grow.

It's very, very difficult to find a company in our industry that checks all these boxes:
- quiet, private work space
- positive culture with good people and not empire-builders
- growth and challenge and intellectual opportunity
- good pay that keeps up with market changes, benefits, and equity in the enterprise
- customizable time off to match life style, sabbaticals, family leave, etc
- finds the talents in their employees and encourages them
- in a good, affordable location

In fact, after years of intensive research, I can't think of a single company I've discovered that does all this.  Most do only some.  Even the best have a major flaw that eventually sends employees packing, and sometimes that flaw is simply that only certain personalities/talents/locations are encouraged and promoted and others not. 

My wife's company (not in our field) is a good example of a small business run by a single owner that chases employees away by treating them poorly.  Others built up the business, they left, and now it's being run into the ground.  The owner complains all the time about not finding loyalty, but he's a miser that stabs his employees in the back to take advantage of them regularly and rages about every single benefit the law requires them to receive.  The company is dying as a result.

In every instance of which I'm aware, companies that are struggling more than is typical to retain talent have only to look at themselves in the mirror to see where the problem lies.

Two more suggestions for the poster having trouble with hiring younger engineers: 
1) target more seasoned folks with families that are looking for a place to settle down.  They are less likely to jump so fast.
2) consider that interviewees that have slick answers to every question, think fast on their feet, have no test performance anxiety, and look really good in interviewers certainly seem appealing but they will seem just as appealing to competing companies; maybe look for some diamonds in the rough instead.

To Source, or Not to Source. That is the Question

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?

Failure of the Week

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.

Joke For The Week

These jokes are archived here.

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

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.