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
• Configuration Recovery
• Mask Testing
• This Week's Cool Product
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

Engineering: what a remarkable word! Engineering is about building a better world. In my lifetime we've gone from rotary dial phones where calls were expensive to international calls at the drop of a dime. From hulking mainframes accessible by very few, to multi-GHz processors in every pocket. From being Earth-bound to probes rocketing past Pluto. From Pluto being a planet, to a diminished planetoid!

My wife and I listen to XM's old-time radio programs (via a satellite link to our car, of all things). They often broadcast old commercials. In 1950 RCA offered a 15" black and white TV for $299. That's over $3000 in today's dollars. The thing probably got 5 channels, and if you lived in the sticks a wobbly high antenna might offer more static than picture. I think we paid $400 for our current 48" color unit that gets, via cable, a zillion (mostly awful) channels and is connected to the Internet, so tens of thousands of movies are but a click away.

When I was seven I spent a week in the hospital for a hernia operation. (Which was wonderful, as my parents wouldn't let us watch Popeye, figuring it was too violent. For seven days I got to see that pirate's bulging forearms as he gorged spinach.) Today a surgeon assisted by a robot powered by dozens of microprocessors might make that an outpatient surgery with better outcomes.

All of these advances, and many more, were empowered by science and engineering.

But engineering changes at an accelerating pace. The boss wants more bug-free code, today. Tomorrow he'll want even more in the same time-frame. Are you on top of the best ways to deliver it?

Every time I do a public version of my Better Firmware Faster class some percentage of registered attendees cancels at the last minute, citing a project in peril that needs their attention now. I'm reminded of this cartoon:

It is important to fight today's engineering battle. But the war will be lost if you don't find better ways to win.

This is what my one-day Better Firmware Faster seminar is all about: giving your team the tools they need to operate at a measurably world-class level, producing code with far fewer bugs in less time. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers.

Public Seminars: I'll be presenting a public version of my Better Firmware Faster seminar outside of Boston on October 22, and Seattle October 29. There's more info here. Or email me personally. There's a discount for those registering before September 22.

On-site Seminars: Have a dozen or more engineers? Bring this seminar to your facility. More info here.

Latest blog: Thoughts on Firmware Seminars.

I'm convinced that you could design a language about a tenth of the size of C++ (whichever way you measure size) providing roughly what C++ does. Bjarne Stroustrup

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

Mat Bennion had an interesting suggestion:

const int size = 5;
char buffer[size];

Roberto Bagnara, a member of the MISRA working group, has a worthwhile paper about the standard here.

Jeffrey O., who won the EE101 in last month's contest, had this to say about it:

This month we're giving away a 30 V 10 A power supply.

The contest closes at the end of September, 2018.

Enter via this link.

I blogged recently about how my toothbrush - a lousy toothbrush! - has modes. Bob Snyder makes an interesting point about this:

I don't think you'd want to have a simple RESTORE button, because accidently hitting it would erase modes that you want, and it may have taken some time to originally configure the device to your satisfaction. After all, that's the point of modes. Perhaps it activates only on a long press. Or, you could bury RESTORE in a menu... and carry the manual around to figure out how to get to it!

Turns out, products with huge feature sets turn people off. A study, Life Is Too Short to RTFM, suggests that many of us don't read the manual, and don't use most of a typical product's capabilities.

A number of digital oscilloscopes have a feature known as "mask testing." It's underused in engineering labs (I see more use in production facilities). But it's worthwhile for debugging both hardware and software. Basically, with a correct waveform of interest displayed, you create a "golden" waveform. This can be done by building an ASCII file (tedious!) or just by pressing the right buttons on the scope. The scope stores the current trace as a model of a perfect waveform. The following picture shows this:

The gray area is the mask. Note there's a little margin around the golden waveform; the size of the margin, in both the X and Y dimensions, is adjustable by the buttons at the bottom labeled ±X and ±Y.

If the signal being monitored ever wanders into that gray the scope will memorize that event and show it in red. Suppose the signal is perfect for hours, but for just a few microseconds goes slightly nuts. It's not possible to define a trigger along the lines of "trigger when something weird happens." So think of masking as a super-duper trigger: it can catch an incredibly complex and rare event. For instance:

Note the marauding partial sine waves on the right. The scope stores the errors and shows them in red.

The statistics are really useful. In the picture above, 67,047 tests were run over the course of seven minutes, and only 5 failed. It's hard to think of a conventional trigger that would capture this!

There's generally a trigger-out from the scope where a signal is asserted every time a mask error occurs. That's useful for triggering other instruments; maybe another scope monitoring something else, a logic analyzer, etc.

To my knowledge, no JTAG debugger has an external trigger input, which is a shame as the scope could trigger the capture of trace data when an error occurs. I have had the trigger-out generate an interrupt to the MCU and the debugger configured to do a trace-stop or breakpoint when that interrupt service routine was invoked. Then it's easy to see what code was running when the problem occurred.

(And that's the fun part of embedded systems, in that the hardware and software are as intertwined the lovers in Rodin's The Kiss).

Mask testing is a nice way to capture a metastable event. Metastability occurs when the data into to a flip-flop violates the setup or hold parameters of the part; that is, if the clock comes along at roughly the same time the data input changes. The flop's output might oscillate for a while, and then settle to a random value.

In the following picture I've configured a 74ALS74 flip-flop to occasionally go metastable. It's clocking pretty fast so a metastable event would be hard to capture any other way. The mask test clearly shows the event.

The red trace is the flip flop's D input, the blue the clock, and yellow is the output. There's about 2 ns between the D and clock. The part's spec requires 15 ns.

Note that in 11 million tests, only 4 metastable events were detected. That is typical of metastability: usually the circuit works great... most of the time. It's normally hard to capture, but the masking feature took only a few seconds to set up on the scope.

Fun aside: To inject the delay between the D input and the clock I drove the clock from the D signal over a short length of wire. Sliding the tap just 10 mm further out, increasing the setup time ever-so-slightly, ten billion captures later, there was one error. Though the circuit worked well almost all of the time, this shows the peril of violating the flop's setup time spec.

Sometimes one has a zany waveform that varies all over the place, so masking will always show errors. It is possible to set a mask for just a small portion of an input while displaying a big part of the entire wave. Crank up the horizontal sweep rate to show just the portion you'd like to mask-test, create the mask, and then reduce the sweep rate so you can see the entire portion of the signal you're interested in. The following video is an example. The mask test shows no errors even though unmasked parts of the waveform are all over the place.

I filmed this video with a camera, as most (all?) scopes will capture screen shot stills, but not videos. Why is that? The scope takes a second or two to write a still to a USB stick, but a video could be queued to RAM and then written after the capture is done.

On the Keysight MSO-X-3054A scope I used for these screenshots an error can be logged on the screen, as shown, and sweeps continuously reacquired. Or the scope can stop, or even save the trace. Better, it can display a measurement, like the exact width of the intruding bit of nastiness.

Circuit Cellar ran a PR piece about a new MCU from Maxim. The picture showed a part much smaller than a fingernail. Alas, you can't get a datasheet without an NDA so I was unable to get any serious information about it. And it's not at all clear to me the value of running teaser pieces about parts whose specs are secret. But the picture of the tiny micro got me to thinking: what is the smallest MCU out there, excepting parts sold as dice? It appears Microchip/Atmel's ATtiny4-MAHR has this honor. The 8-pin 8-bit device is just 1.95 x 1.95 mm! Microchip sent a sample.

6AU6A vs the ATtiny4 on paper with a 1/4" grid

The 6AU6A is a pentode - roughly equivalent to one transistor, though one with three control inputs. There are thousands (transistors, not 6AU6As) in the MCU. You can buy the tube for $8; the processor is half a buck in singles. And the MCU doesn't need 6.3 VAC for the filament!

Update: Hours before sending this Muse, I got an email from Maxim about their MAX32660, an even smaller device, which is a Cortex M4 with FPU in a 16 bump WLP package that measures 1.554 x 1.572 mm. $2.95 in singles. Running at 96 MHz, it has 256 KB of flash and 96 KB of RAM. That's a lot of horsepower in such a tiny part.

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.

Note: These jokes are archived here.

Laws of Computer Programming:

• Any given program, by the time all the bugs are out of it, is obsolete.
• Any given program costs more and takes longer than originally planned, even when this law is taken into account.
• If a program is useful, it will have to be changed.
• If a program is useless, it will have to be documented.
• Any given program will expand to fill all available memory.
• Program complexity grows until it exceeds the capability of the programmer who must maintain it.
• The sooner you start coding a program, the longer it will take.

Advertise in The Embedded Muse! Over 28,000 embedded developers get this twice-monthly publication. .

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.