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
• On Risk
• Binary Editing
• RAM Testing
• Failure of the Week
• This Week's Cool Product
• 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.

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

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

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.

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

Enter via this link.

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.

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

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

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.

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.

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.”

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.