You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• The Art of Readable Code
• On Middleware
• USB Power Monitors
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it’s not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm.

The Muse comes out the first and third Monday of each month. However, everyone deserves some vacation time, including the Muse, so this is the last issue of the year. See you in 2015!

Some people have called the book the "bible of software engineering." I would agree with that in one respect: that is, everybody quotes it, some people read it, and a few people go by it. - Frederick Brooks, on his classic book The Mythical Man-Month.

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

Bruce Wedding sent this:

Javier Tia wrote:

In Muse 272 Paul Bennett mentioned the book The Art of Readable Code by Dustin Boswell and Trevor Foucher. I ordered a copy and found the book very readable. Fifteen short chapters fill this slender 180 page volume, which is divided into four parts:

• Surface level improvements
• Simplifying loops and logic
• Reorganizing your code
• Selected topics

Important points are broken out as "Key Ideas," and while some are obvious or trite, many are pithy. The very first is code should be easy to understand, which pretty much sums up the book's entire philosophy. I do wish there had been an appendix listing all of the key ideas.

Plenty of examples are given, in a variety of languages including C, C++, Python, Java and HTTP. Most of the ideas do apply to C.

The authors' treatment of names is spot on, and I'll bet many developers have never thought about some of the ideas. For instance, does CART_TOO_BIG_LIMIT = 10 mean the cart can have 10 items or 9? The name is ambiguous, and they suggest using max and min for limiting values.

They refer to the overall look of a function as its "silhouette." They take this code:

... and improve the silhouette as follows:

... then take it a bit further:

The last one sure looks nicer than the first.

Their central Key Idea about comments is "The purpose of commenting is to help the reader know as much as the writer did." I'd add "at the time he wrote the code" as memories are feeble.

Interestingly, they do advocate using multiple returns and gotos where they might clean up what would otherwise be convoluted code. MISRA C advises against these constructs, rather than prohibiting them. However, some safety-critical standards require that functions have a single point of return.

A very brief bit of prose and an example touch on using De Morgan's laws to simplify logical structures. In school EEs De Morganize Boolean expressions ad nauseam; I wonder if the CS folks learn these useful techniques? If you're not familiar with De Morgan, this is a good site.

The example given is:

if (!(file_exists && !is_protected)) do something;

which can be De Morganed to the easier to understand:

if (!file_exists || is_protected) do something;

Chapter 12, "Turning Thoughts Into Code" recommends writing out in English exactly what a function is supposed to do before coding it. The idea of understanding a function's behavior before typing in C is very old, though in some corners today is getting deprecated. Unfortunately.

Many amusing cartoons, some pertinent, are scattered throughout.

True stories:

A company, let's call it Acme Products, had a very popular product which many of us use on a daily basis. Powered by a single 16 bit processor, all the code fit into 256k of ROM. The code had evolved over decades; patch after patch added to the convoluted mess. Maintenance costs escalated yearly.

Engineering convinced management that a complete rewrite was needed. Not unreasonably they elected to go to a 200 MHz high-end 32 bitter. Perhaps unreasonably, succumbing to the siren call of cool, the engineers elected to replace a traditional RTOS with Windows CE, an extensive graphics library, and many layers of middleware to insulate CE's API from the application, and to provide all of the resources needed to do, well, anything imaginable in the future.

Five years of development and $40 million in engineering crept slowly by. System ROM went from 256k to a meg, to two and more. When they called me the application now consumed 32 MB, yet included only half the functionality in the original, 256KB, 16 bit version. Button presses, which previously offered instantaneous response, now took seconds. The safety aspects of the system were in question.

Grand dreams of vendor-neutral code mandated so many layers of middleware that the system burned too much CPU time, consumed huge amounts of code space, and ate enormous amounts of engineering time. I recommended they cancel the program and start over. They did.

Then there was, let's call them ABC Security, who built a secure communications device upon a Pentium Pro. A quarter gig of RAM holding a version of Linux, middleware that again aimed to provide a vendor-neutral API, more API-neutral access to a flash file system, a chain of device drivers so deep, so convoluted, that was sure to baffle Linus himself, led to a product that took full ten minutes to produce a dial tone when the unit went off-hook.

Also cancelled, after burning $2 million in engineering dollars.

Then there was the data acquisition product that migrated from an 8051 to a Power PC. Engineers replaced the old brain-dead idle-loop design with an RTOS from a well-known vendor, and the simple data storage structure with a real filesystem. TCP/IP replaced the previous incarnation's proprietary synchronous communications mechanism. And this system, too, never saw the light of day as a real product, as it could no longer keep up with the input datastream.

I get many emails from people wanting to know how to use X on some small microcontroller, where X is from the set: C#, Linux, .net,

Magazine ads scream the benefits of higher levels of abstraction, of complex middleware, of languages guaranteed to provide immediate and painless reuse. If you're not working with Linux or some flavor of Windows your products are dinosaurs sure to fail in the marketplace.

In the olden days assembly programmers could count T-states to predict execution time. RAM and ROM needs were absolutely clear. The move to C did obscure this somewhat, but with a little experience developers could reasonably estimate real-time performance and memory requirements. That's not possible anymore when we bundle huge chunks of middleware into our products.

Management finds it hard to resist the promises of vendors, who earnestly show how just one more layer will ensure the product will outlive capricious decisions made by other vendors, of how converting to a popular API will let us replace expensive embedded experts with dollar-an-hour Visual C++ programmers. Yet the costs, in terms of memory and CPU cycles, never seem to enter these discussions. It's not till the system has grown into a bloated morass of code running at a crawl, that the realities become apparent. At that point there's usually no recovery other than a complete recode. Expensive? You bet.

Middleware, high-end languages, and complex OSes are awesome tools and capabilities that many embedded systems absolutely need. They're rarely the panaceas promised by anxious vendors. We must demand quantitative overhead specifications in place of the all-too-often vague promises used to sell this stuff today.

Real time resource-constrained embedded systems are still the norm, and still fundamentally differ philosophically from PCs. Yet too many vendors seem to view the embedded space as an extension of the desktop market.

Tom Evans was not thrilled with the PortPilot, which I reviewed in the last Muse:

Tom also sent some links to other units:

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 intents of this newsletter. Please keep it to 100 words.

Note: These jokes are archived at www.ganssle.com/jokes.htm.

Caron Williams sent this story, which, though not really a joke, does make one laugh... or cry:

I have just finished upgrading my HP Envy dv6 laptop to Windows 8.1, which was a very, very, frustrating experience. However I thought the following observation might interest your readers.

By way of setting it up, here's a cut-and-paste from http://windows.microsoft.com/en-us/windows-8/rip-burn which is a help file. A little over half way through it you'll find:

========
Here's how to burn an audio CD:
1. Swipe in from the right edge of the screen, and then tap Search.
(If you're using a mouse, point to the lower-right corner of the screen, move the mouse pointer up, and then clickSearch.)
2. Enter Windows Media Player in the search box, and then tap or click Windows Media Player.
=========

This is not an isolated example. Typing text into the Search box is the advice offered with very many (all?) Windows 8 Help files.

Now stay with me - I'm just about to get to the point!

You'll notice that we have come full circle. In the bad old days, using ASR32 Teletypes, we used to type program names at prompts. Later, on the text-only screens of "Glass Teletypes", we continued to type text: commands which were often tortuously - but ingeniously - abbreviated to five characters.

Then Xerox invented the GUI, where we pointed at what we wanted and clicked on it, instead of typing in a name. Apple copied Xerox, and Microsoft copied Apple. Interestingly, in accordance with the laws of physics concerning increasing entropy, each copy was worse than its predecessor.

But I digress.

So having run a point-and-click interface for more than 30 years since the original Apple Mac, and then through Windows 1, 3, 95, ...and so on to Windows 7, I continued to point-and-click.

Now we have Windows 8, with gesture recognition (does anyone doing serious work need gesture recognition?) and how are we supposed to use it?

Why, by typing a name into a text box!

Who said that the more things change, the more they stay the same?

Advertise in The Embedded Muse! Over 23,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.