Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
 Issue Number 402, July 20, 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

SEGGER Embedded Studio cross platform IDE

Jack's latest blog: Does Anyone Remember In-Circuit Emulators?
Quotes and Thoughts

When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along. David L. Akin.

Tools and Tips

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

Though I'm hesitant to enter the editor wars, I've been using Ultraedit for many, many years and it is my preferred editor on Windows. They're up to version 27; I'm using 24 as I just can't think of any additional features I'd need or want. The Ultraedit folks do sell a file compare, but I'm addicted to Beyond Compare from the oddly-named Scooter Software. It's fast and it shows deltas brilliantly.

Bob Paddock wrote:

In some recent Muses there has been discussion of State Machines and visualizing them.

Graphviz - Graph Visualization Software at https://graphviz.org/ is useful when writing your own State Machine  code to get some good visibility.

The 'dot' format is easy to automatically generate, even manually can come up with useful state graphs.

Sometimes it is far easier to detect issues visually.

If the State Machine graph looks like a Möbius strip you know you have a problem.

Another very useful tool for State Machines is the Ragel State Machine Compiler at https://www.colm.net/open-source/ragel/

"Ragel targets C, C++ and ASM. Ragel state machines can not only recognize byte sequences as regular expression machines do, but can also execute code at arbitrary points in the recognition of a regular language."  Which means it is easy to add code when a (sub)state is entered or exited, without adding yet more states.

I've used it for several years and was involved with its early development to a small degree, in getting the Grpahviz support added.

Such a graph is shown on the home page.

Ragel also supports a minimal State Chart model of input.

One obscure feature is that Ragel can be configured to use GCC's even more obscure feature of 'Computed Gotos'.  This makes embedding the code easier in small processors like the AVR, where early versions of AVR-GCC required 'decorations' on tables to get them into Flash space.

Generally 'Goto' is to be avoided. In autogenerated code they can make things a lot smaller depending on the processor.
Freebies and Discounts

July's giveaway, courtesy of Firia Labs, is one of their Explorer Kits, which includes 2 micro:bit circuit board computers and associated components for experimenting.

Explorer Kit giveaway

Enter via this link.
Microcontroller Basics with PIC

What, another book about the Microchip PIC? Aren't there shelves groaning under the weight of these tomes? Well, yes, but Tam Hanna's new book Microcontroller Basics with PIC is a bit different. It's aimed at students and embedded wanna-bees rather than practitioners.

This is a hands-on book that teaches both hardware and software design in a manner analogous to how practicing engineers work. Many simple projects are introduced and explained. The wise reader will build and test the projects. However, unlike every other hands-on book, there is no specified evaluation or demo board used. He recommends using a PIC16F18877 with a solderless breadboard like this:

Then, each of the projects is built simply by plugging in a few parts on the board. This is an excellent approach as demo boards come and go; if gone, so would the value of the book be. (Alas, Tam doesn't use the word "solderless breadboard" and I'm afraid a novice wouldn't know how to go about obtaining this item).

The book starts with the basics and begins with assembly language (another nit: it doesn't explain what assembly is or why it's important). MPLAB is the IDE used, and Tam gives a great overview of installing and using that product.

Hardware and software are presented as a unified gestalt, as is proper in the embedded world. Code to toggle a pin is accompanied with oscilloscope screen shots showing the result. Even better, drawings annotated with events show what's happening when, such as:

Assembly instructions are presented with example usage and resulting scope outputs. I'd recommend that a reader have a scope handy to follow along; even a low-bandwidth USB scope would suffice.

Sometimes blinking an LED is that "ah-ha" moment that turns people on to embedded systems. I think the real exciting bit from the book is a table-driven sine wave generator and the accompanying scope shot.

The second half of the book is about using C. As the author notes, it's not a C text and assumes the reader has some familiarity with the language. But it does dig into using interrupts and various serial protocols.

The book is chatty, perhaps too much so with many references to the author. But it is a great introduction to embedded systems and I recommend it.

I'd pair this book with Alex Dean's Embedded Systems Fundamentals with ARM Cortex-M based Microcontrollers as two works, taken together, which would give a decent foundation to this field. Tam's will get you going in the 8-bit world; Alex pushes that to 32 bits and more complex subjects. Both are eminently practical and readable.
Requirements Traceability

Responding to last issue's article about Software Elements Out Of Context, Harold Kraus wrote:

  • "It is traceability that gives you the ability to modify with confidence when there are slightly different assumptions made by the target system."

I was going to leave it at just that thumbs up ….

In my mind, SEooCs are rather a microcosm of Safety Relevant software. That is, every component of a Safety Relevant software product can be conceived as a case of SEooC …

As we develop, requirements are decomposed until we reach the simplest components and requirements practical -- each such atomic component (or Unit) is allocated specific requirements in terms of its inputs, outputs and internal states.  These component requirements are either decomposed or elaborated from system requirements ( I prefer "elaborated" to DO-178C's "derived" ). It is through these component-specific requirements that each component can verified 'out of context' of the rest of the software product. This is the old-school unit testing, but requirements-based because these unit tests are written from the requirements rather than the code.

30 years ago, we tested our flight software a unit at a time, that is, in a build limited to the unit with no more additional code stubbed in for the unit other than the minimum needed to assemble and run by itself in a simulator.  This approach was a compromise with the limitation of computers and microcontrollers at the time (slow computers and no background debug silicon). Today, the FAA is aware that with increased computer capacity and comprehensive background debug silicon, low-level component verification can be accomplished in context within the full software product (with minimal instrumentation, if any), and has started insisting testing in that manner.

But, it is still the traceability of requirements to every component of the source code out of context that permits this approach to verifying every component in context. A goal of this traceability of every line of code to requirements is for all stakeholders to agree that every line of code has a reason to be in the product and safely fulfills that reason.
Failure of the Week

From Scott Sweeting:
This Week's Cool Product

Not quite a product, but researchers have a way of creating short pulses. How short? On the order of 5 ps. There's more here.

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.

From Clive Souter:

I'll never forget the first time I saw a universal remote.  I thought, "This changes everything!"
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.