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
• Audio Telemetry
• A New Book: Embedded Software Design
• On Resumes
• 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.

We live in a society exquisitely dependent on science and technology, in which hardly anyone knows anything about science and technology. Carl Sagan.

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

Jacob Beningo is graciously giving three copies of his new book away to Muse readers. I review it later in this issue.

Enter via this link.

Over the holidays I watched a couple of documentaries about deep-space probes. Good Night, Oppy, about the Mars rovers, is a special treat. In one of these shows (I can't remember which) engineers diagnose a troubled spacecraft by listening to a series of beeps, chirps, clicks and other sounds. I found it fascinating that the human ear can hear this cacophony of sounds and isolate individual themes. Those 1 Hz clicks that represent, perhaps, a watchdog tickle, stand out clearly from the warbling tones signaling an ADC overflow (or something).

Taken together, the sounds form a musical score that indicates spacecraft health and problems.

Fans of classical music listen to Bach's fugues and hear a complete piece, but one can zero in on individual themes and see how they are developed and drawn into counterpoint. His Passions are complex creations but a single wrong note from an oboe stands out as something ineffably wrong.

I've often wondered why we rely on a debugger and not much else. These tools are wondrously-powerful today, but embedded systems are, by their nature, imponderable boxes whose mysteries are hidden. And debuggers are pretty much only useful when hunting for a bug. Why not add "health" signals to your code in the form of a musical score? An important but infrequent task could send a click. Pure tones indicate sampling. Warbles calculations. Mix these into a single data stream that goes to a speaker or other human interface that might be used only as telemetry, or as a debugging aid should something unexpected happen when the system is no longer in your lab.

Our brains are remarkably good at extracting patterns from sound.

In the early 70s we were embedding minicomputers into systems. Debugging tools were practically non-existant. We found that a short-wave radio, tuned to an empirically-determined frequency, was a great way to hear what the code was doing. Different loops each had unique sounds.

I can see developing an open-source library of code to make these sounds. Integrating that code would take little in terms of hardware resources while generating a highly-useful stream of telemetry.

Jacob Beningo is a well-known embedded guru whose frequent articles on embedded.com and other sites are worth reading. He has written several books; the latest is Embedded Software Design. I did help with some technical editing of the book, so will just make a few comments here.

In many ways the book implores developers to be data-centric. His first two principles (of 7 total) are Data Dictates Design and There is No Hardware (Only Data). Though I'm not entirely sure I agree, Jacob offers compelling arguments that will help you think about design in a different way. And different thinking is always a good thing. In fact, the first chapter is about the philosophy of embedded design, which he carries throughout the book. We do need an embedded "overstory" that guides our engineering. Sans that we'll get lost in the intricacies of pushing ones and zeros, losing focus on more important goals.

The book covers material that will be familiar to old hands... and some that might not be. I rarely see embedded code structured as event-driven even though that can be a tremendously-effective design paradigm (Jacob prefers "design pattern" - one of those newish phrases I feel is more smoke than essence). Microservice design, too, is covered, as are publish-subscribe models. The latter can be complex but offers a fascinating way to decouple code. The book treads lightly on these subjects but provides enough context to whet appetites and encourage further exploration.

As is usual in embedded books, there's a chapter on designing with an RTOS, but in this case it has some great information on measuring execution time with affordable commercial tools.

If you keep up with the literature you've run into DevOps, a term whose meaning seems a bit slippery depending on the promoting pundit's passions. Jacob defines it as "a software engineering methodology that aims to integrate the work of software development and software operations teams by facilitating a culture of collaboration and shared responsibility." To me this means working together, but perhaps that's a notion as quaint as bipartisanship. Regardless, this chapter is worthwhile if you work in a large group. Particularly useful is his take on continuous integration/continuous delivery, which, when coupled with the appendix on CI/CD using GitLab, offers a detailed cookbook approach.

Chapters on test (including test-driven development - not one of my favorite approaches, but one with many proponents), modeling/simulation and build systems offer practical and useful advice.

A couple of excellent chapters cover things we need to do... but don't. Design-by-Contract is, in my opinion, a very powerful idea which the book couples to the use of assertions.

One tip he offers that I could not agree with more is "If you spend 20% or more debugging your software, you will mostly likely have a process problem. Don't muscle through it; fix your processes!"

Embedded Software Design is a book I heartily recommend especially for people with limited experience as it covers ideas beyond the mechanics of coding; ideas needed to build systems reliably. More experienced people will find nuggets of great information packed into an easy-to-read, almost conversational style.

With the start of the new year it makes sense to update your resume. I wish I had saved all of the quirky resumes that have come across my desk over the decades. One was printed on bright pink paper, an obvious gambit to make it stand out from the rest of the pile. Others were long… really long, sometimes over 100 pages.

I did save on from 30 years ago (the rest is equally priceless) which contains this nugget:

Do you think this person got an interview?

A job opening often results in a deluge of resumes. If you've never hired anyone you might think that the evaluator would carefully dig through the stack, weighing and evaluating each candidate’s skills. You’d be wrong. There are usually too many submissions for that. No, the goal is to find a reason to toss as many as possible, fast. Find one full of typos? Probably means the person isn't careful, so it goes into the bin. A lack of skills critical to the opening means the resume instantly goes in the reject pile. And a hint of crazy (or more than a hint as in the one above) nets a sure pass.

A resume has two purposes: first, to get an interview. And second, to serve as a reference used by the interviewers during the selection process. The resume of candidates who aren't immediately rejected get annotated throughout the courtship to aid feeble memory.

Above all it’s a sales document, meant to sell you. Relentlessly scrutinize your resume from the perspective of a potential employer. Have your friends and family attack it. Every line should scream “I am experienced and competent at all of these things!”

The resume is a living document, updated regularly even if you’re not looking for work. It may be in a less-than-perfect format if you’re happily employed, but keep notes in it about your accomplishments as they develop. Then tidy it up when it’s needed.

A resume can also be a career blueprint. If there's a gapping hole in your experience perhaps it's time to take some action. Resume management is part of career management.

And what about the cover letter? Its only raison d'etre is to get the resume read. The cover letter is vital, and must be tailored to the prospective job. Give the reader a reason to think you're a match. If the company is hiring someone to build colorimeters, stress (briefly) the skills you have that align with that. If you have much experience, surely your resume will list a variety of CPUs you've used, but if the job ad talks about ARM experience, the cover letter should highlight that.

Too many engineers neglect their resumes instead of continuously managing them. I have some more thoughts about this here: https://www.ganssle.com/sellurself.htm .

Have you submitted a Failure of the Week? I'm getting a ton of these and yours was added to the queue.

Bob Snyder sent what he called "The Shelbyville Anomaly":

Peter Greuter sent this - a 1.5 year wait for the next train:

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.

Dick Selwood sent this, and you can get your own here:

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.