Go here to sign up for The Embedded Muse.
TEM Logo The Embedded Muse
Issue Number 273, November 17, 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 jack@ganssle.com.

Editor's Notes


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.

Quotes and Thoughts

John Johnson sent in this quote from Douglas Adams: "Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws."

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.

A Power Monitor for USB

The PortPilot is a small bit of test equipment that is placed in series with a USB host and a USB device. It measures the voltage and current supplied to a USB device, and integrates that to show total mWh consumed. It measures the host's impedance to figure its ability to supply power, and shows that in amps. Resolution is 1 mA and 1 mV.


The PortPilot in action. The USB connection on the right goes to the host; on the left to the device (in this case a flash drive). The micro-USB connection on top goes to a PC for data logging. On the display: mW being used, total mWh consumed during the session, which in this case was 23 hours and 29 minutes. The voltage and current are displayed prominently. The device is using 14% of the device's 0.5A capability.

It allows you to elect to block data transfers between the host and the device, perhaps useful when working with a public, untrusted, USB port.

Sure, you could put a DMM in series with the USB power line. But if you're working with a USB device and need to keep an eye on current consumption this is a handy way to do so without tying up a probably-expensive meter. And, if you want to know average power consumption over some time period (which could range from seconds to years) just divide the displayed mWh by the displayed time.

The program also can enable a virtual fuse, which turns power off to the USB device if it consumes more than a settable number of mA.

The PortPilot's real strength is its logging. A micro-USB connector on the device lets you connect it to a PC. A DOS command-line program will read from the device and either show the results on the screen or log them to a file. In the following picture I instructed it to read the parameters 11 times:

PortPilot Command Line

The columns are: Time (s), Vbus in (mV), VBus out (mV), Current (mA), Max current (mA), Power (mW), Energy (mWs), Status

Charting capability is included, though to use charts must install the LabVIEW runtime, which takes several minutes to install, though the process is mostly automatic. You do have to bow to Redmond's screwy architecture and restart the computer. An example display follows:

PortPilot Chart

The PC software is still evolving. I asked for a capability to set how often the data gets sampled, which the company said is coming. In the graph above each new data point gets added to the right, so the horizontal axis keeps compressing. I've asked for a scope-like mode where only the most recent N samples are displayed.

For $60 this is a handy device if you must monitor USB power. You can find out more at www.portpilot.net.

Engineering Vs. Recurring Costs

I came across two engineers arguing about buying a commercial RTOS. "It's too big," one complained, "we're already short on flash."

Engineering isn't about achieving some sort of technology perfection. Engineering is a business proposition. We're paid to help the company generate profits and increase shareholder value. So a wise developer uses that context to evaluate every decision he makes.

Can't squeeze some commercial product, say an RTOS or protocol stack, into memory? Don't start salivating at the chance of writing that code yourself ("I've always wanted to write an OS!"). Take your hands off the keyboard and consider the business impact of buying a smaller product from a different vendor... or adding more flash.

We deal with two kinds of costs. Bits and pieces, ICs, PCBs and labor form the cost of goods sold (COGS). Additional memory will indeed inflate the COGS and thus increase the product's price.

But NRE (non-recurring engineering) is every bit as significant as COGS. NRE is us: our salary, desks, scopes and tools. It's incurred once, hopefully, during product development.

There's a tradeoff between NRE and COGS. If you're building an electronic greeting card even $0.0001 in recurring cost is hugely important. It's wise to invest lots of engineering to shave every microcent. But other products require different tradeoffs.

Firmware is the most expensive thing in the universe, with most companies spending some $20 to $40 per line of code. The space shuttle's software ran about $1000/line. A decent RTOS will run 5000 lines or more of C, representing an effort worth well over $100k... assuming average practices.

But even at $100k, if you're building a thousand widgets you'll save the company serious dough by adding ten bucks worth of memory, rather than rolling your own OS.

A few years ago an engineer emailed me that they were coding their own Internet stack. Management had choked on the $15,000 cost of the commercial package they'd considered. I called the vendor, who confirmed the package had over 100,000 lines of code.

That's 15 cents per line. A Blue Light Special.

The right business decision would have been to present the vendor with a $15,000 check and a huge grin. That purchase is so lopsided in the customer's favor it's akin to robbery. (Of course, there are other, open source, options as well.)

What do you think? Does your company make reasonable business tradeoffs between NRE and COGS?

On an On-Line Thesaurus

Gary Lynch commented about the use of an on-line Thesaurus:

Edwin Decoene wrote about linguistic resources, and recommended an online thesaurus. I have kept a copy of _Roget's_International_Thesaurus_ on my desk (right next to K&RII) for decades and use it in choosing variable and
function names.

A true thesaurus is more than a synonym dictionary, more of a reverse dictionary. It allows you start with a concept and find a word that renders it concisely. This is especially important in choosing variable names because so many English words are ambiguous:
currentReading: Does 'current' mean 'now' or 'flow of electrons'?
noErrors: Does a '1' mean there are no errors, or is that the number of errors?

I have never found an on-line thesaurus that provides this meaning-to-word transformation, so I am sticking with the book for now.


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.

An exasperated caller to Dell Computer Tech Support couldn't get her new Dell Computer to turn on. After ensuring the computer was plugged in, the technician asked her what happened when she pushed the power button. Her response, "I pushed and pushed on this foot pedal and nothing happens." The "foot pedal" turned out to be the computer's mouse.

Advertise With Us

Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. .

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.