Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
 Issue Number 398, May 18, 2020
Copyright 2020 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.

Contents
Editor's Notes

Express Logic

Jack's latest blog: Is the Future All Linux and Raspberry Pi?
Quotes and Thoughts

We should continue to collect and analyze data on how, when, where and why people make software errors in order to find means to avoid people making these errors. Barry Boehm
Tools and Tips

SEGGER Embedded Studio leading cross platform IDE

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

Sometimes we have very limited I/O for debugging. One approach I have used is to generate Morse code messages to a speaker. Here's a program that will do this. This site gives implementations in 62 languages; the C version is very clunky, but the Forth version is intriguing. A couple of years ago a reader wrote that he did this, but the beeping drove other engineers crazy!

Max Maxfield has a 9 (!) part series on switch debouncing. Part 9 is here, and that page has links to the earlier parts as well.
Freebies and Discounts

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.
Design by Contract

Design by Contract (DbC) is an idea that I believe was first implemented in the Eiffel1 programming language. Ada-2012 included the notion. Essentially, the idea is the components of a program have contractually-governed relationships to each other. A function, for instance, can only accept parameters that meet certain constraints (e.g., code that computes a rocket's velocity might only accept positive values).

DbC usually includes three types of contracts:

  • Preconditions are those that must be satisfied when a function is called. An example: a parameter that will be used in a square root (in the Real number domain) must be positive.
  • Postconditions are those that must be satisfied as a function exits. A postcondition is a check on the validity of the function's code.
  • Invariants are those conditions which remain unchanged throughout the execution of the function.

I've tried to torture C via macros and other convoluted processes into supporting DbC, without much success. Assertions are a poor-person's crude-DbC alternative, and I've written extensively about better ways of using those here.

I recently stumbled across a nice writeup on using DbC in Ada. Recommended, even for C developers, as that page has wisdom worth pondering.

1. Eiffel is an object-oriented programming language that no one in the embedded industry uses. It is described in Betrand Meyer's Object Oriented Software Construction, which is probably the best book written about OO design. Though it teaches Eiffel most of the book's ideas scale directly to C++. Meyer is a brilliant writer.
RTOS... or a State Machine?

Tony Garland responded to my comments in the last issue about using an RTOS:

There is a very useful half-way-house between interrupts+timers+polling main loop and full-blown RTOS.  That is: event-driven state machines.  I've found myself with that solution over and over again when the complexity of an RTOS isn't warranted but the interrupts+polling main loop gets overwhelmed or impossible to understand as it grows beyond all recognition.

State machines, especially of the hierarchical variety, can nicely decompose some very complex situations with style. If the machines are cleanly decoupled and adopt strictly-sequenced atomic-action (run-to completion) event handling, the larger problem can often be transformed into a reliable set of mostly orthogonal components--with some cross-machine event posting as needed.

If the state machine implementation uses a framework (rather than an ad-hoc bunch of switch statements), then one can maintain good traceability between the state machine diagrams and the code which implements them. They also impose a level of rigor in the design which is often otherwise missing (let's just "just one more timer" to get this icon to blink...).  For example: serializing event-handling in a way which minimizes resource contention problems and can helpfully transfer actions with potential race conditions among interrupts and the main loop into main-loop-only strictly-sequential operations.  And the pictorial nature of state machine designs often point up design flaws before one even gets to implementation.

After decades of embedded development, I'm much more likely to turn to a state-machine framework than ramp all the way up to use an RTOS.  The convenience and resources afforded by an RTOS can really be nice--but there is a substantial cost of taking that step and corresponding loss of control and visibility of how the overall system is operating.

One can hardly do better for an in-depth treatment on this subject than the landmark book (IMHO) by Miro Samek, Practical UML Statecharts in C/C++. His book deserves a place on every real-time/embedded engineer's bookshelf (or tablet)!

Miro's book is indeed excellent. I did find it a bit heavy going at times, but worth the effort.
The (Scope) New Math

Last year I was using an opto-interrupter to measure the speed of a rotating wheel. The pulses went to an oscilloscope, and by measuring their period I could derive RPM. It occurred to me that most scopes today can do some math, though that is limited to a handful of pre-defined operations. Wouldn't it be nice if the instrument could do any sort of math? That is, the user could type in custom formulas. Then one could observe things like RPM directly. I mentioned this to Siglent; they said they'd look into it. Of course I forgot all about it.

Recently I upgraded the firmware in my Siglent SDS5034X and found that the MATH button operates normally, but a little clicking around brings up this screen:

random math in an oscilloscope

That's right - the scope can accept many kinds of user-defined math functions. The middle array of soft-buttons select the source: channels 1 through 4 (C1-C4), zoomed subsets of those channels (Z1-Z4) and two user-defined functions. The buttons on the left enable common functions and the grouping on the right includes numbers and the basic arithmetic functions.

In the formula bar (the arrow points to this) I've entered (∫(channel 3 times channel 2)) *√ (channel 1).

The computation's result appears as another trace on the screen. As one moves the cursor a box displays the instantaneous value at the cursor position.

Remember when we used to count divisions on the screen and convert those to volts or time? That's long gone. So too, it now seems, with figuring some function manually.
Failure of the Week

ATM giving multiples of zero
This Week's Cool Product

Here's a gyro that's 10,000 times more accurate than the one in your mobile phone, but is only 10x more expensive. Though not available yet as a product, it's pretty amazing. This is a golden age of sensors.

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.
Jobs!

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.

As a computer, I find your faith in technology amusing.
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.