Tweet Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
TEM Logo The Embedded Muse
Issue Number 274, December 1, 2014
Copyright 2014 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com
   Jack Ganssle, Editor of The Embedded Muse

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

Contents
Editor's Notes

Ad

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 http://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!

Quotes and Thoughts

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.

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.

Bruce Wedding sent this:

Regarding thesauri, I'm not sure these will replace your copy of Roget's but they're pretty cool regardless. Try the first with your example word 'current':
http://www.visualthesaurus.com  (free to try)
http://www.visuwords.com/  free

Javier Tia wrote:

From 'On an On-Line Thesaurus' section, what about this Roget On-Line Thesaurus?

www.thesaurus.com/Roget-Alpha-Index.html

The Art of Readable Code

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:

First code silhouette

... and improve the silhouette as follows:

Second code silhouette

... then take it a bit further:

Third code silhouette

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.

The price of $29 from Amazon is too high for this very-quickly read book. But it is a gem and offers a lot of very solid advice. I recommend it.

On Middleware

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 insure 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.

USB Power Monitors

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

There are lots of cheap USB Power Monitors available on eBay, for around $6 or so.

What you get for the money? A pretty toy with flashing lights mainly. A toy with a label claiming 1% accuracy.

This is the email I sent to the seller, more for my amusement (in taking the measurements) than for their elucidation.

At least I have a "calibrated" meter now.

Would you believe these cheap units have the 0.1 ohm current shunt in the GROUND rail? The input and output USB Shields aren't directly connected, but go (together with the 0V rail) through the 0.1 ohm resistor.

======================

The units are incapable of showing a steady reading, but jump around by 2 to 9 digits when measuring a guaranteed constant current. So rather than trying to get an "average" I've graphed the lowest and highest readings for each current measured.

I've also had Excel perform a "Best Fit" to the curves and show the resulting equations. They show (on both graphs) that the unit measures a consistent 70mA to 80mA low..It has a pretty constant "offset error".

The first graph shows the current measurements over the range 0 to 0.5A, which is the maximum a PC USB port can deliver. The "offset error" is very easy to see here.

The second graph shows the current measured up to 2.6A, which is less than the maximum rating, but the maximum I could generate. The equations show the minimum readings are 3.9% high and the maximum ones are 8.7% high. They are also offset by 70mA to 80mA.

I suspect they read high at high currents to try and minimise the mid-range error caused by the offset. This is a design problem with the hardware they chose. I don't think they can fix it.

Like a broken clock which shows the right time twice a day, this unit is "accurate" at 1.4A, but is worse above and below that. At 2.6A it reads between 3% and 5% high. At 100mA it reads between 60% and 80% low!

Power meter graph

USB power meter 2

Tom also sent some links to other units:

In looking at the various units on eBay and elsewhere, there are two classes of units:

Firstly the very cheap ones for less than $4 delivered:

http://www.ebay.com.au/itm/USB-Power-Amp-Meter-Tester-Charging-Monitor-Voltage-Current-Multimeter-DH-/271542195208?pt=AU_B_I_Electrical_Test_Equipment&hash=item3f392d1408

They only have voltage and current, with two digits after the decimal point and (at least the two units I bought) poor accuracy and noise.

There's also the following "battery discharge capacity" unit. Its purpose is to measure the actual delivered capacity of the lithium battery packs that are used to recharge phones, or how much charge a device takes getting charged. I don't know what its accuracy is like:

http://www.ebay.com.au/itm/NEW-Mini-USB-LCD-Voltage-Current-Detector-Battery-Discharge-Capacity-Tester-/390972071259?pt=AU_Components&hash=item5b07c05d5b

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

 

Joke For The Week

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 With Us

Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. For more information email us at info@ganssle.com.

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. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information.