Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
Issue Number 464, February 20, 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


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.

IEEE Spectrum has a series of articles celebrating the 75th anniversary of the invention of the transistor.

Quotes and Thoughts

"People seem to misinterpret complexity as sophistication." - Niklaus Wirth

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.

A recent article tests build times for Rust versus C++ projects. They are about the same for small projects, but C++ builds much faster as the system grows. Interestingly, at least for the project tested, Rust requires about the same number of source lines of code as C++.

Sergio Caprile wrote a nice article about using the Mongoose networking library.

Freebies and Discounts

A ShortSniffer! This unit will find short circuits. I wrote about it here.

Enter via this link.

On Risk

This ad ran in Embedded Systems Design magazine some years ago:

It was a joke. Note the April 1 tag line. But the people there told me they got orders for that 8051 COBOL compiler.

It seems we're always on a quest for some new tool, some new idea, something that is novel, to magically solve our problems. Alas, there are no silver bullets. New tools and ideas are awesome and deserve our investigation. But hold the claims to the cold, harsh light of engineering analysis.

Consider Rust, mentioned above. I'm hearing a lot about the language, and do think it offers some compelling advantages over C. The benchmarks generally indicate that, unlike a lot of would-be contenders to be C's replacement, it's about as speedy as its older cousin. Ironically, though, C's fame as a fast super-assembly language is less important in these days of cheap CPU cycles and plentiful memory.

But, to a first approximation, no one is using Rust in real projects. And the language is evolving, lacking any sort of standard.

Being a pioneer invites risk, and risk can threaten a business.

C was once new, or at least new to the embedded world. It was a disaster. Lacking an ANSI standard there were many variants with incompatible syntax. Compilers were notoriously buggy. It was very common to debug with an open disassembly window to see what sort of nonsense source lines compiled to. I'm not entirely sure what has happened in the intervening years, but tools - compilers and the like - are just better today. Even newish programs (like Rust compilers) just seem to work. The program crashes we expected in years past, those that kept us compulsively hitting control-S with OCD-like frequency so we wouldn't lose anything in a crash, are much rarer today. That's pretty astonishing when one considers the computer is running billions of operations per second, at maybe one volt with little one vs zero margin, and any error would cause a meltdown.

Today, by and large, we expect things to work. But if you're going to employ a new tool, there are some other considerations. I see two general categories of these resources:

  • Adjuncts. Things that might give visibility into the code, or that are not essential to the success of the business. Tolerance for problems with these is reasonably high. Even compilers are somewhat fungible as choosing a turkey is not and end-of-world event as plenty of alternatives exist. With the language mediated by an ANSI (or other) standard, it's not too hard to migrate.
  • Mission-critical. The language choice. Some add-on packages (networking, filesystems, etc.). Getting these wrong could kill the business.

In engineering we need to, as appropriate, push the technological bounds and to incorporate the best in novel ideas. But that must be tempered with a conservative approach to insuring that the system will work, and that risk is mitigated.

I have seen too many projects doomed by engineers, untamed by management, going off on wild tangents with the latest, coolest technology. An example: a company, whose name you know, had a product deployed all over the world that worked great. A 16 bit CPU with little memory drove the thing. But wouldn't it be cool to soup it up a bit? Toss in a 32 bitter. A huge OS. Tons of middleware. Five years went by and the team had half the functionality of the original product, but now consuming 32 MB. No end seemed in sight. I was called in to make recommendations, and after an analysis suggested tossing the code and starting over with more modest goals. They did - throwing out $40 million of engineering.

In the USA, at least, the word "conservative" is one I'm hesitant to use given the political divisions we endure. But engineering has always embraced the word, "conservative" to us meaning making decisions that minimize risk. A conservative design will have adequate margins: a little extra room for things to go wrong. Sneak in a bit of additional RAM, if we can. When a system must run from 0 to 70° buffer in maybe 10° each side if circumstances permit.

Conservative design favors the tried and true, while admitting the new when needed. But was always subject these decisions to careful engineering analysis.

Binary Editing

Attie Grande sent useful thoughts about working with binary in GNU:

I thought I'd follow up on the "Binary Editing" topic...
This is perhaps a little different, but still very useful when matching up running firmware (e.g: behind readout protection) with the relevant build artifacts.

Did you know that the GNU linker (and likely others) will automatically include a "Build ID" in ELF files by default, or if you give a --build-id=sha1 parameter to ld to be explicit (or -Wl,--build-id=sha1 if passing to gcc).

This can be very useful, but care needs to be taken to include it in the binary / hex derivatives, and not just throw it away.

There's a good write up on the subject here: https://interrupt.memfault.com/blog/gnu-build-id-for-firmware

More info about the --build-id argument in the ld man page: https://linux.die.net/man/1/ld

Request creation of ".note.gnu.build-id" ELF note section. The contents of the note are unique bits identifying this linked file. style can be "uuid" to use 128 random bits, "sha1" to use a 160-bit SHA1 hash on the normative parts of the output contents, "md5" to use a 128-bit MD5 hash on the normative parts of the output contents, or "0x hexstring " to use a chosen bit string specified as an even number of hexadecimal digits ("-" and ":" characters between digit pairs are ignored). If style is omitted, "sha1" is used.
The "md5" and "sha1" styles produces an identifier that is always the same in an identical output file, but will be unique among all nonidentical output files. It is not intended to be compared as a checksum for the file's contents. A linked file may be changed later by other tools, but the build ID bit string identifying the original linked file does not change.
Passing "none" for style disables the setting from any "--build-id" options earlier on the command line.

RAM Testing

Eric Ryherd had some thoughts about RAM testing, which was addressed in the last Muse:

The standard RAM test is the March test which requires several passes of 1/0 patterns thru the memory. Often these are implemented in hardware as a Built-In-Self-Test block to accelerate the test and not slow down the processor on bootup. The BIST is often used to speed up the silicon test time as time is money on a tester! The trick to these algorithms is that you must know the physical organization of the RAM which assumes adjacent bits are physically next to each other.

The problem I came across is that a chip designer, in his infinite wisdom, decided to wire all the odd bits to one physical RAM and all the even bits to another one. Thus breaking the fundamental assumption of the March test - that adjacent bits are physical neighbors. After getting unusually high fallout of a very expensive ASIC due to functional RAM failures which all passed the BIST testing, we followed each bit of the bus to the RAMs and realized what the engineer had done and thus had to alter the BIST algorithm to be a C3 pattern instead of an A5 pattern to ensure adjacent bits have different ones and zeros.

The learning from this failure: Always check all the assumptions of an algorithm!

Failure of the Week

Washington can figure out where much of our money goes, but Randy Robinson found that they are precise in tracking snow:

Andrew Newman writes: The attached image came from a Sudoku app that I downloaded and started using on the iPad over the Christmas holidays. It seems that, when the board completion Time is longer than the Best Time, the “seconds” field of the Best Time is replaced by the time delta between the ‘Time’ (last completed board) and the ‘Best Time’. It is displayed correctly only when the Time is also the new Best Time.

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

Remember ExpressLogic? Their ThreadX was a nifty RTOS that was/is widely used. A few years ago Microsoft acquired the company and they now sell the RTOS under the Azure name. They still have a killer URL: www.rtos.com, though it vectors to a Microsoft address.

Bill Lamie was the guru behind ThreadX, and now he has a new endeavor. PX5 is offering a, well, you guessed it, RTOS. This appears to be a very-low footprint product tailored to the usual crop of 32 bit MCUs. A lot of these products offer their own proprietary filesystems, networking, and other resources. PX5 cleverly uses common open-source versions of these packages.

Percepio has integrated their Tracealyzer product with PX5. This is a product that gives great visualizations of RTOS and the associated application's operation in the time domain.

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.


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 biologist, an engineer, and a mathematician were observing an empty building. They noted two people entering the building, and sometime later observed three coming out.

The biologist remarked, “Oh, they must have reproduced.”

The engineer said, “Our initial count must have been incorrect.”

The mathematician stated, “Now if one more person goes into the building, it will be completely empty.”

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.