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
• C - Whither Thou Goest
• Embedded Engineering Body of Knowledge
• The First Rule of UI Design
• Failure of the Week
• 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.

 The tool that is so dull that you cannot cut yourself on it is not likely to be sharp enough to be either useful or helpful. - John Tukey

The always-interesting bloggers at Memfault have a great post about doing over-the-air updates incrementally.

I'm sad to say that my favorite text editor, Ultraedit, is now subscription-only. $79.95 per year is, in my opinion, an absurd price for what is just an editor.  I'm switching to the free Notepad++. The trend to subscription-only services isn't new, and insidious price gouging via small incremental yearly price issues is not uncommon. One example: Adobe's Dreamweaver,  a buggy, bloated app that, with the advent of cascadeable style sheets, doesn't do a whole lot anymore. But it does have a few killer features my web site is structured around. Some years ago it was a few hundred dollar one-time purchase. Fair enough. That morphed into a subscription-only plan for about $5/month, which also seemed reasonable. Today it's $21/month and, like addicts who haven't the time to go into rehab, we're slaved to the program due to 2000 pages built with the app. Then there's Office 365, which offers a whole slew of complex programs that work well, for $70/year - and that covers 5 users. Not a bad deal, in my opinion. The trends, though, are ominous and I hope purveyors of embedded tools don't go into this black hole. Beyond the annoying clawing at our wallets, commercial tools using this model means users need to get purchasing approvals every year.

Jeroen Proveniers sent this:

As mentioned below, I'm pretty aghast at the state of tech publications. However, EDN's Design Ideas column has been a great resource for many decades. The latest: a very clever air-flow sensor using a Darlington pair. 

Tam Hanna and the kind folks at GigaDevices have given us two of their very popular GD32F470 evaluation boards for the giveaway. These boards use Cortex M4s with FPU and come with a camera interface.

Enter the contest via this link.

Jason Wheatley sent a link to an article by Jacob Beningo that wonders if it's time to retire C.

There's no question C is an old language that's basically a step up from assembly. Decades ago we (mostly) dumped the latter despite its efficiency in favor of the more user-friendly, relatively portable and much more productive C. Though the language made an entrance into the embedded landscape in the 80s, it wasn't till a decade later that it was widely adopted. Partly that delay was a normal reticence to try something "new"; partly the tools needed time to catch up.

Three decades later we can say this: Though C is imperfect it has served our community well. There are better alternatives but none have made any significant headway in this space. Donald Rumsfeld's famous quote could be adopted to our industry: "You go to work with the language you have, not the language you might want or wish to have." Engineers are a practical lot and we leverage what works. We have an army of people who know C, are familiar with the tools, might have tens of thousands invested in C tools and infrastructure, and alternatives carry risk.

I'd like to see C replaced. And I'd like an end to death and taxes.

One of the virtues of C is its elegant simplicity, especially when compared to more modern dialects. C++ seems to be loaded with every artifact the committee could invent; only the bravest venture into its deepest depths. Since simplicity is a virtue, why not pursue that with vim and vigor?

Consider Brainfuzz (the language's real name is a bit of a barnyard epithet so I choose to use a bit of discretion here). Simple? You betcha. It has but 8 primitives: >, <, +, -, *, a comma, [, and ]. A Hello World program is merely:

++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.
>>.<-.<.+++.------.--------.>>+.>++. 
    

(The self-documenting nature of this code is clear).

A number of Brainfuzz variants exist. My favorite is Ook! which is based on the well-known Orangutan language used by primates in Borneo. Or maybe on back lots in Hollywood productions. Hello World becomes (and yes, this is real, or as real as taking a silly notion to absurd levels can be):

Interestingly, this is exactly the same speech I heard from an earnest politician recently. Compared to what his opponent said, he has my vote!

Bill Gatliff posed an interesting question: Is there a Body of Knowledge for embedded developers?

The IEEE published their Software Engineering Body of Knowledge (SWEBoK) some years ago. It's sort of a grab bag of everything known about the subject with little to indicate what a practicing engineer should be doing.

To my knowledge there are no real equivalents for embedded work. Plenty of pundits are happy to push their One True Way, but how does an engineer with a product to deliver know which of these are effective?

Fads have always been rampant in software engineering, and I think there's no single approach for everyone. Chaos is possibly ideal for a small project that needs to get to market fast while a much more disciplined ethic is appropriate for safety-critical systems. We're faced with a universe of ideas which practicing engineers need to digest into an appropriate discipline for their unique needs.

(I've seen chaos work, agile methods generating great products, and highly-disciplined approaches resulting in the best of the best code. And I've seen chaos utterly fail, agile approaches collapse in tatters, and highly-disciplined teams crash and burn.)

An Embedded Engineering Body of Knowledge needs more than a software-engineering lifecycle; it has to address gritty details like standards compliance, configuration management, change control, and even bug finding and prevention. Alas, instead of a silver bullet I think the EEBoK is an amorphous thing comprising years of experience and a never-ending devotion to studying new approaches. The nicely-minted EE degree is merely a key that opens the door to a lifetime of learning.

You start with the books - lots of them. Here's a pretty comprehensive review of embedded books.

Then there's the trade press, which today is a poor shadow of its former glory. There's little in print anymore; the web has dried up all of the ink. And, alas, most of the web publications are pretty abysmal today. The headlines appear to be computer-generated extracts of the first line of each article instead of a careful-curated summary of what the articles are about. Other pubs have gone away; one of my favorites was Crosstalk, a USAF production that lost its funding. For good, deep, tech content on software engineering, well, there's simply not much out there.

Though I try to follow venerable electronics magazines like EETimes, there's just not much worthwhile content anymore. EDN remains pretty good. Electronic Design is OK, though you have to sort through inscrutable headlines to find useful information. Steve Leibson's articles on EE Journal are good. Memfault's blog is nearly always a winner, as is Embedded Artistry's newsletter.

Are there blogs, books, sites or other resources you find useful for this industry? Let me know and I'll pass them along.

Miles, kilometers, degrees of longitude - there are a lot of ways to measure distance. A friend told me Bermuda is 1431 songs from Norfolk: running his iPod 24/7, that’s how much music he consumed on the 5-day sail.

For business travel I often measure distance in hours. A trip a few years ago from Baltimore to Bangalore was 39 hours door-to-door, somewhat longer than usual due to an overnight stay in the Mumbai airport. The longest leg is the 14 hour hop between JFK and the first stop in Delhi. Fortunately, or so I thought, both going and coming I was aboard a brand-new plane, a state-of-the art aircraft, the pride of Boeing.

A voracious reader, on trips I’ll typically dig through a stack of business literature and a book or four. But 14 hours in the air is so painful I ultimately seek the mind-deadening distraction of the in-seat entertainment system. Years ago one was lucky just to see one movie projected en masse; today, the embedded revolution has placed an entire catalog of flicks at each seat.

According to the in-flight magazine, Air India’s aircraft had a Thales 5000 or 6000 entertainment system. The screen is huge - a good 10” or so. One navigates using an iPad-like touch screen interface.

I picked a really brain-dead movie. Gone With the Wind runs 222 minutes. After 218 the system crashed with a “this selection is not available” message. The one satisfying moment of the film, when Rhett Butler issues his withering “Frankly, my dear, I don’t give a damn” line, was lost.

Every movie I tried to watch on the two flights crashed, usually just before the conclusion.

You’d think the “back” button would naturally pop one up the stack to the previous screen. In some cases it did. But on other screens “back” went all the way up to an introductory display.

The touch screen was very slow and, worse, took some time to acknowledge a selection. I’m a firm believer in making embedded systems immediately responsive to a user input. Even if it’ll take some time to perform a selected function, at least light up the key instantly so the user knows that his action was accepted by the system. For instance, when debouncing an input, debounce the trailing edge; don’t wait for the contacts to settle before accepting the input. More on this here: https://www.ganssle.com/debouncing.htm.

Fast forward, a vital feature when movies crash, was too slow to be useful.

And what’s with volume levels on airplanes? Don’t the designers realize that engine noise and aging ears require more than a few dB of output? Sometimes I envy my deaf cousin’s lip reading skills.

The first rule of UI design is Don’t Piss Off The User. Thales failed miserably with this system. Consistency (make controls respond in the same fashion regardless of mode or screen), reliability, and smooth delivery of content are the very minimum requirements. Yet many companies don’t get this. Is it any wonder Apple excels? New iStuff users are amazed at the devices’ simple and clean interfaces. Isn't it a shame that we’re surprised when a system works well?

On the upside, the maps showed the position of wrecks like the Titanic, Thresher and the Monitor. That was pretty cool.

We’re expected to deliver a lot. Enormous feature sets, huge code bases, awful real-time responses. But remember that the customer only sees the system’s behavior. Never, ever, build a system that pisses off the user.

Vendors quoting you long lead times? It could be worse. From Chris Yewell: Note that is is just a single 67 cent part:

And from Brian Miller:

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

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.

Raz Dan sent this. We know how a fried IC releases its stored smoke. Now there's a smoke restoration kit:

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.