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

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• A Power Monitor for USB
• Engineering Vs. Recurring Costs
• On an On-Line Thesaurus
• 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.

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

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

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:

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:

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.

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?

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

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.

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