Click here to go to the on-line version The Embedded Muse 483

The Embedded Muse Logo The Embedded Muse
Issue Number 483, February 5, 2024
Copyright 2024 The Ganssle Group

Editor: Jack Ganssle,

   Jack Ganssle, Editor of The Embedded Muse

You may redistribute this newsletter for non-commercial purposes. For commercial use contact 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" in the subject line your email will wend its weighty way to me.
Quotes and Thoughts

Again and again and again - what are the facts? Shun wishful thinking, ignore divine revelation, forget what "the stars foretell," avoid opinion, care not what the neighbors think, never mind the unguessable "verdict of history" - what are the facts, and to how many decimal places? You pilot always into an unknown future; facts are your single clue. Get the facts! - Robert Heinlein

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 an interesting article on memory safety in Rust.

  I'll be speaking at the upcoming Embedded Online Conference. Muse readers can use promo code GANSSLE24 to get a $200 discount if used by February 15, and a $100 discount if used after Feb. 15 and before March 31st.

A payrolled NYTimes article describes how a furniture company banned smartphones... and saw a 20% productivity increase. Though sparse on details it does make you think.

Apollo Computers

I can still remember watching our grainy black and white TV when Alan Shepard launched in 1961. I was probably in first grade, but we were allowed to skip school that day to see the flight, since Dad was working at Grumman on LEM (now called LM) proposal work. The launch was postponed a couple of times and days, and I have no memory if we stayed home on those occasions as well.

That was just over 50 years ago. Younger folks would be stunned how space fever grabbed this nation. From about 1961 to 1970 it practically defined popular culture: space burgers, space motels, space everything was the order of the time.

The interest quickly waned. I remember watching Apollo 17 go; the launch was shown as a small inset on a broadcast of a (apparently more important) football game.

Computers were still in their infancy in 1961. The Mercury spacecraft didn't have one, which to a 2013 EE is pretty astonishing considering we need computers even to drive toothbrushes today ( IBM's 360 series was still years away; even their 7090 family was only a year old. A decade later when I started college the university was dismantling their 7094 as it was completely obsolete.

By the time of Apollo computers were more sophisticated, but by today's standards were primitive. The history of these times has been told in many books. One of my favorites is Digital Apollo ( But recently I ran across an old book called "Computers in Spaceflight." It's a 300+ page tome (not including references) which is available here ( as a huge (500 MB) .PDF. James Tomayko wrote it under a NASA contract.

The book does have a number of obvious errors, and my first reaction was that Mr. Tomayko must have been more English Major than computer scientist, but Google indicates he was a professor of Computer Science at Carnegie Mellon till his untimely death in 2006. For instance, the cycle time of the Gemini computer is listed as 140 msec which seems incredibly slow; on-line references suggest that should be 140 usec. But the mistakes do not diminish this important book.

It's divided into three sections, covering manned and unmanned missions and ground support equipment. The former takes us to about 1986 and the Shuttle, though Challenger's loss that year isn't mentioned. Obviously, this long predates the International Space Station.

The story of the Apollo Guidance Computer has been told many times and continues to fascinate, but till reading Computers in Spaceflight I had little information about Mercury's lack of a processor, or about the very limited CPU aboard the Gemini missions. It used no ICs and was composed entirely of discrete devices, presumably transistors, though the book is silent about this. At almost 60 pounds it was composed of 510 PCBs just for the logic section. A bit-serial machine, it had 4k 39 bit words of core memory. An auxiliary tape unit weighed in at another 26 pounds and stored just over a million bits. Compare that to a modern sub-$100 disk drive that stores ten million times more data in a package measured in grams of weight.

Unmanned programs started using microprocessors with the 1802, one of the first CMOS CPUs which used practically no power and had no hardware stack. The book makes tantalizing references to AMD's 2901 (a bit-slice CPU the author gets wrong) and the 68K, but hardware gets much less focus than software. To me, that's Computers in Spaceflight's biggest disappointment as the digital hardware of the time had to be ingeniously designed to overcome the limitations of low-transistor counts.

The software gets lots of attention, sometimes in mind-numbing detail. But the meta-story is fascinating. As far back as Gemini program managers found that the software was the pacing component. It was never done fast enough and many meetings and committees tried, without much luck, to constrain the code.

The section on ground computers is less compelling than the others, as these were off-the-shelf mainframes. One interesting tidbit: the Saturn V firing rooms at the Cape required 250 men stationed behind consoles to get the thing off the pad. A floor layout shows that, indeed, these individuals were men: there's a sizable men's room, but no ladies!

For a computer history buff this is a must-read, though be prepared for some slow sections. A Kindle edition is available for a buck, which is a much better deal than printing so many pages. No doubt I made a generous donation to HP's ink division.

Do you remember the Apollo program? How about Mercury or Gemini?

Even More on Are Engineers Born or Made

Are we born or made? Readers have lots of interesting opinions, responding to articles in Muse 481 and 482.

Vlad Z, who started this discussion, added:

>I have had several people that I have just met, ask me if I am an engineer.  There is something in our personality,
>presumably the way we talk, that is different than most people and some people can sense those differences.

The short answer to that is that an engineer's brain has a considerable preference for a logical approach.  As was demonstrated by behavioral psychologists, we have an intuitive system and a logical system, and the former works faster, its use is easier, and it's more error-prone.  We make many decisions using it, some call it System 1, and people use it most of the time.  The use of a logical system takes more effort, and it is used much less frequently; that's System 2.  Engineers tend to employ it much more frequently than the non-engineering folk, and it shows in conversation.

Wouter van Ooijen warns against killing an interest:

I am not entirely sure about the contribution of made versus born, but I am sure that too many children are frightened away from exploring and tinkering, which is the child version of engineering (maybe the adult version too). The first time Anne comes home with her shirt dirty because she played with mud, or torn because she climbed a fence, and her mother criticizes her for unfitting behavior, a potential engineer is lost. Whenever you throw a household gadget away instead of giving it to your children, with a screwdriver seemingly randomly placed beside it, you nudged them away from ever becoming an engineer. I think Neil de Grasse Tyson said something like "All children are curious by nature. When an adult isn't curious, that's nurture."

Anne Adamczyk has a slightly different take:

In the answers to the question “are engineers born or made,” I think a lot of your respondents use somewhat flawed logic in their answers.  They state, “I built a working nuclear reactor in my basement when I was 8 months old.  Therefore, I conclude that engineers are born, not made.”  But I don’t think we should draw the conclusion that people who did not do such things as a child were therefore never meant to be engineers because they were not born so.  There are a lot of factors that can prevent someone from tinkering on their own.  I was attracted to engineering because I liked helping my dad fix things around the house, but natural timidity prevented me from trying to do a lot of things on my own.  If the FIRST Robotics program had existed when I was in high school, I have no doubt that I would be a better engineer today, because it would have taught me and given me a platform for trying and experimenting – skills that it took me much longer to develop as an adult.  I agree that we should not attempt to force an interest in STEM when there is none to begin with, but providing opportunities, or even just an introduction to the subjects, can spark the creativity that in some of us takes time to develop.

Roy Tellason sent a pic of one of his early favorite books:

Eric Brewer figured if a little voltage would work, well...

I loved the comment, "My first crystal set did not work because I failed to read the text properly and did not understand the need to scratch the enamel coating off the wire to solder it."   

Back in the sixties, my cousin and I set out to build an intercom of some sort, but we were tired of using ignition cell batteries so we decided it should somehow run on 110v AC.  Found a filament transformer and proceeded to "breadboard" a power supply, using my bed as the workspace.  Unfortunately, you know what happens when you reverse the leads on said transformer...  a melted blob in the middle of the bed and a very smoke-filled room!  

I guess we had very tolerant parents.  Which, I think, proves that engineers are born but then allowed to develop without parental or educational discouragement.

Branchless Programming and Testing

Louis Bertrand's take on Branchless programming:

Ouch! I had a bad reaction to the branchless programming version of the a-greater-than-b operation suggested by Charles Manning (TEM 482). Avoiding branches to reduce cyclomatic complexity is good, but the example chosen makes me skeptical of the value of the effort of converting if statements to arithmetic and Boolean expressions in actual practice. The example was:

greater = (a < b)  * b + (a >= b) * a;

First, it replaces the hazard of an extra local branch with the hazard of making a mistake in complementing the Boolean expression. At least write it with the complementing operator:

greater = (a < b)  * b + !(a < b) * a;

However, the claim that it has the beneficial side effect of avoiding the performance hit of discarding the contents of a long CPU pipeline is not based in fact. The actual code produced by the comparisons generates branches in the assembler output. Using the compiler explorer, GCC on Extensa ESP32 generates a BLT and a BGE, MSVC on ARM64 does the same and adds two unconditional branches.
I'm not sure that a more realistic example would have helped. The simple example obfuscated a straightforward operation familiar to even beginning programmers. If the linearized branching operation was more complicated, would even an experienced programmer recognize the intent of that statement?

Geoffrey commented on AI and test:

I can't speak for any tools dedicated for writing tests via formal analysis, but modern AI tools (eg ChatGPT, copilot) are fairly good at finding edge cases and writing tests. You can feed it any written code and the relevant section of requirements. 
As a bonus you're not actually 'shipping' any AI generated code - although if you get it write tests from the requirements first, the AI will probably do a better job of writing the function correctly. (TDD works on AI too!)

For example, ChatGPT given:
Write a complete set of python unit tests for function that does a vector cross product. The function definition is: `def cross_product(a: Tuple[float, float, float], b: Tuple[float, float, float])`
Use pytest for unit testing

Gave me 6 tests including a vector with itself, orthogonal vectors, a zero vector, positive and negative valued vectors, and both int's and floats (in python the float type is effectively Union[float, int]). No analytic test generator would 'think' of those cases by analysing the code as the code for a cross product should have no branches.

Obviously this is a toy example, but in my day job it does a pretty good job, often finding edge cases that I hadn't thought of even for domain specific pieces of code, and even if there is significant boilerplate. With github copilot, while you still have to write most of the function code yourself, testing is often as simple as pressing 'tab' repeatedly.

Geoffrey's comments are augmented by a recent article about this.

Failure of the Week

Deepak Agarwal sent this little jewel:

Yes we have negative bananas. David Ryan 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.

Walter Turchyn sent this:

Each year just before Christmas, I've had this habit of writing up a component-related song, based on the tune of some well-known Christmas carol or other seasonal song. Here is this year's edition, which I have shared with my internal " customers" at Parker Hannifin: 

"My Favourite Parts" 
(sung to the tune of "My Favourite Things" from the movie "The Sound of Music") 

Bright shiny LEDs, thin-film resistors, 
Common-mode filters, diodes, and thermistors, 
Multi-core processors with ten UARTs, 
These are a few of my favourite parts! 
Zeners and MOSFETs and logic inverters 
Hall Effect sensors and voltage converters, 
Even though prices have gone off the charts, 
These are still some of my favourite parts! 
When stock runs out, 
builds are in doubt, 
and the planner's mad. 
But then I remember my favourite parts, 
And then I don’t feel... so sad! 

About The Embedded Muse

The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.

Click here to unsubscribe from the Embedded Muse, or drop Jack an email.