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
• Knowledge Capture
• Efficacy of Bug-Finding Tools
• Hardware, Software or Hardware/Software?
• Failure of the Week
• This Week's Cool Product
• Jobs!
• Joke for the Week
• About The Embedded Muse

A recent EEWorldonline article states "TIRIAS Research forecasts that 98% of all edge devices will use some form of machine learning/artificial intelligence by 2025." In my opinion, this AIn't gonna happen anytime soon.

A long but fascinating history of the transistor is here.

Jack's latest blog: Networking Did Not Start With the IoT

58% of innovations fail, except for those originated by top management, which fails at a rate of 74%. - The Economist

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

Recent Muses have had comments about using state machines. But what about tools? I have heard good things about IAR's Visual State. Michele Corradin wrote that they are using Yakindu. I had not heard of it but he says they've had great success with it and the web site looks interesting. Does anyone have any experience with either of these tools?

Firia Labs is donating one of their CodeBots (a Python-enabled robot with a host of sensors) for this month's giveaway.

Enter via this link.

In Knowledge Capture and Management for Space Flight Systems author John Goodman argues that, particularly in aerospace projects, much vital project knowledge exists only in engineers' heads. Imperfect memories, career changes and retirement means this information goes missing, often to the detriment of a current program, or a future one that could have drawn on what might have been painfully-acquired experience.

Goodman relates that early space efforts took just a few years to complete; Project Mercury ran just over four years from contract award till final flight, Gemini took 5 years. The Shuttle program spanned 38 years, an engineer's entire career. How many original engineers were associated with that system over the entire program?

Just two years after contract award the P-38 fighter had made its first flight, and was introduced to the service two years later. The F-4 flew three years after the contract. But the F-22, despite the contractor having built a flying prototype before winning the competition, required an additional six years for the first flight of the contracted aircraft, and a further eight before the first production model made it to the Air Force. The F-35's schedule appears unbounded. These are more ambitions projects than the primitive, by today's standards, P-38 and F-4, so comparisons are not completely fair. But it's clear that both the complexity of the programs and the engineering duration means preserving design decisions is increasingly important.

In the commercial world the problems are little different. I've often wondered how the automotive companies preserve corporate knowledge. Ford learned at great expense how to position gas tanks due to the Pinto fiasco, but do young engineers who weren't even alive at the time know those lessons learned so painfully, so long ago?

Middle-aged readers who can't find their keys understand that even a single person's memory is pretty unreliable. I figure the brain is a FIFO queue. When it fills, around age 50, something has to go when one learns something new.

So how do we preserve knowledge? Traditional tools aren't up to snuff. Goodman suggests the use of "Brain Books," more or less engineering notebooks used by developers to record design decisions, test results, and the like. He cites a case where a Brain Book saved a project. But hardcopy is tough to search and poor penmanship hinders understanding.

I keep a notebook in my woodworking shop to record things I learn that I'll surely forget. There's no computer in that room and the volume of data is very low, so that works well. A variety of pretty organized files on my PCs keep resource notes, interesting quotes, facts and the like. But perhaps a wiki is the ultimate Brain Book repository, and reading Goodman's article has given me motivation to set up a personal Brain Book on a wiki. We're drowning in information and, unless preserved and categorized, an excess of data is the same as no data.

Microsoft Notes is an interesting system for recording ideas. I've had pretty good success with it. But not trusting any cloud provider to be around forever I do download the data from time to time as a backup.

How do you preserve your design notes and other important bits of information that exist outside of normal tool flow?

I stumbled across a 2005 paper by Stefan WagnerJan JürjensClaudia KollerPeter Trischberger called Comparing Bug Finding Tools with Reviews and
Tests. The key takeaway: bug-finding tools are useful, but they don't replace tests or code inspections/reviews.

Now, the study was about Java code and the bug-finding tools were open source, not the commercial versions now available. Here are their conclusions:

Interestingly, code reviews were much more effective at finding the worst bugs than bug-finding tools. Tests were not as good as reviews, but were far better than the tools for these impactful bugs. The tools shine at detecting the least consequential errors. Tests found none of these.

My takeaway: use the tools to cheaply find some errors. Apply reviews, and then tests. Think in terms of a series of filters, as no one approach will give quality code.

When the embedded field was young most developers wore at least two hats, that of firmware and hardware designer. Some also came up with analog, power and maybe even RF circuits. A single engineer might be responsible for most of the electronics in a product. Sometimes the same person would even lay out the PCB and assemble prototypes.

That was a lot of fun!

But systems were simpler back then. 8 KB of code was a lot, and SMT hadn't turned board assembly into an art practiced only by the caffeine-deprived. 12 bit A/D converters were expensive, which meant those of us working in the analog domain had, in general, smaller noise issues than today's systems that measure femtoamps. Low clock rates dodged Maxwell's Laws and programmable logic was merely a dream.

Though a huge number of embedded systems are still small, often containing a bare sliver of silicon embodied in a small PIC or other minimal MCU, big applications are common. Firmware can consume hundreds of thousands or even millions of lines of code. Hardware people design with multi-hundred pin chips running with tiny noise margins, while wrestling with EMI and ESD requirements that were unheard-of decades ago. It's natural that engineers started to specialize, at first to divide the work into manageable chunks, and later because of the specialized knowledge required to deal with advancing technology and requirements.

Today an increasing number of embedded systems developers live in their own domain, with little knowledge of other aspects of the system they're building. That's a natural part of the progression of knowledge: as a technology or science advances people's expertise at their own arcane area grows while their breadth narrows. But it's interesting how that, in a single generation, we've progressed to the point where many firmware developers can't answer simple questions about their hardware platform. In casual discussions with engineers I'll often ask about their system's clock rate, or supply voltage, or any of a number of hardware issues. Quite a few can't answer; in some cases the software people don't know what the target processor is.

The reverse is often true as well: ask a hardware developer about the firmware's data structures or which RTOS is used and you might get a blank look. The FPGA whizzes are sometimes clueless about classes and analog gurus can be completely ignorant about PWM control.

I've worked with groups that use embedded Windows or Linux simply to minimize their need for firmware people, who can be hard to find and a lot more expensive than Visual Studio programmers. These folks may have little idea about the physical instantiation of their product.

This natural and necessary specialization has created a new job category, which I call the systems person. The person who does have a deep understanding of all of these interrelated issues, who can sling some VHDL and C while probing a low-noise preamp. Sometimes they're the computer experts who can tie together the digital hardware and code to interface with the RF crowd to help the entire team solve a challenging multipath problem.

These systems people are invaluable and increasingly hard to find. At times I wonder if they are a vanishing breed. But other fields have managed to keep systems folks with armies of specialists. Medical GPs, for instance, look at the whole body.

What is your experience? Are systems folks a dying breed?

I took this picture at an airport in Norway. The word "Bug" plastered on the plane didn't leave a feeling of confidence:

Need a custom PCB? Here's a site that will quote boards instantly. Change a parameter (say from 2 layer to 4 layer) and the price comes up in under a second. And, small boards are dirt cheap.

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.

From Dan Daly, who writes: Seen in Silicon Valley, at a park along a bicycling/hiking trail. There were many casts in the pond, but the most visible, for obvious reasons, were (float).

(The jokes section of my website now has 200 computer-related bits of humor.)

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.