Go here to sign up for The Embedded Muse.
TEM Logo The Embedded Muse
 Issue Number 296, January 4, 2016
Copyright 2016 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.

Contents
Editor's Notes

Happy New Year to the Muse community. I wish you and yours a great 2016. May all your code be bugless!

Give your team the tools they need to operate at a measurably world-class level, producing code with far fewer bugs in less time. This is what my one-day Better Firmware Faster seminar is all about. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers. Information here shows how your team can benefit by having this seminar presented at your facility.

An excellent short pair of articles (article 1 and article 2) from QSM discusses an analysis of 1060 software projects. The author shows that small teams consistently deliver better code for much less money than large teams. And while the bigger groups get to market faster, the difference is only a handful of percent.

I'm now on Twitter.
Quotes and Thoughts

"A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible. There are no prima donnas in engineering." - Freeman Dyson (Alas, I have met more than a few prima donnas in this field - Jack).
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.

Margaret Johnson wrote:

re: Kicad

I have found this site helpful: https://forum.kicad.info/

I wanted to note regarding learning kicad, I find Chris Gammell's videos on youtube (as well as his Contextual Electronics courses) to be excellent.  I've gone from not having a clue about electronics - let alone kicad - to designing, building, writing software for PCBs.  Words cannot express how grateful I am to Chris for putting this power in my hands.

Luca Matteini had some thoughts about PCB layout software:

In the last few years, some higher end tools have been sponsored by large distributors in a stripped down version, see RS (DesignSpark), Farnell (Cadsoft Eagle), Mouser (MultiSIM Blue), and Digikey (Designer Schematic and Layout).

Reviewing the list of PCB EDA tools available around, I discovered a new tool sponsored by DigiKey (at least new for me) called PCBWeb, that I have to admit it pleased me very much.

First, it lets you produce your Gerber files, and save files locally. Schematics and PCB files are in XML format, without complex data bases storing everything you did after your birth. Then it produces a nice BOM with parts directly from DigiKey, with an updated board cost and the options to export it for an order.

They also sponsor a few PCB makers, from which you can have an automatic quotation on your PCB cost, and optionally order fabrication (unless you don't want to do something else, since you have Gerbers).

It's even quite good at moving some already routed components on PCB, without disrupting the tracks.

Libraries are on-line, and the mix of schematic parts, footprints and DigiKey codes works quite well, while new parts may need a few work, if you plan to keep in sync with DigiKey catalog.

I think it's worth considering for many ones, at least for an evaluation. Then there are its cons, like when you delete a component from schematic for substitution and all of its connections get zapped (so you have to reconnect everything).

The second good new of this autumn/winter season is the release of latest KiCAD, as mentioned also on EM 295. I already used the previous versions for my usual proof-of-concept scope, along with other PCB tools. However the unpolished interface never got me fond of it. I have to say that since version 4.0.0 (and 4.0.1 at the moment I write) there have been some nice updates, for a better look and usability.

I strongly recommend everyone interested in PCB tools to try it, even though it's a complex tool, and takes some effort to use it.
The cons about it? Well, library management has been redesigned from previous releases, but it looks organized by a team of goblins, trying to hide from you the right menus and buttons everywhere. Why not creating a clear path to a "create a new library" task?

Again, maybe it's just my point of view, I'm sure someone else could find everything linear... Anyway: it's free, it works. Get it, try it!
Freebies and Discounts

Steve Morse is the lucky winner of last month's contest; he got a LogicPort logic analyzer..

Real-Time Current Monitor

This month I'm giving away a copy of Gary Stringham's excellent Hardware/Firmware Interface Design.

The contest will close at the end of January, 2016. It's just a matter of filling out your email address. As always, that will be used only for the giveaway, and nothing else. Enter via this link.

Careful Hardware Design

Tim Wescott has some thoughts about careful hardware design:

Just a really quick note on quadrature encoders and debouncing. I should have written this in response to the original article, but it was the responses that really got me going.

While the writers are correct that you can detect and fix stupid hardware errors in code, the first line of defense should always be to not make stupid hardware errors in the first place.

Note that I say this not just as a grumpy old writer of embedded code, but also as a hardware designer and a sometime systems architect. The best time to solve this particular sort of problem (open-collector outputs over long distances) is when the decisions about mechanical and electronic hardware layouts are being made, not after problems are discovered in assembled equipment.

I fully understand that for most of your readers I'm preaching to the choir: by the time such problems are discovered the situation may be such that the design is carved in stone, or it may be presented as such by management. Moreover, an individual embedded software engineer may have no control over, or even visibility into, the mechanical and electrical design of a system. For those guys, I commiserate. The audience I'm really trying to reach is the fraction of your readers who are placed highly enough in the food chain to affect the process by which such errors are spawned or avoided.

The problem described should not be considered to primarily be an interesting problem in embedded software design. It should be considered as a failure in system design that is creating a potentially serious failure which is then being papered over by software. Moreover, it's a problem in system design that is very likely caused by project management paying insufficient attention to the importance of overall system design.

As such, however much heroism is being displayed by coping with the problem in software, the real solution should lie with project management, product line management, and systems architects. These people should both connive on ways to fix the problem in the existing product, and to ensure that the problem doesn't happen again on future projects (probably by simultaneously insuring the competence of the system design team, and giving the system designers time to do their job).

(Feel free to insert a plug for Kim Fowler's "Developing and Managing Embedded Systems and Products", 2014, Elsevier. I wrote Chapter 8, of which about a quarter of which is an extended rant in much the same vein as the above, and the rest of which is advice on how to prevent such things from happening in the first place, in a cost-saving and timely manner.)
Ethics Maintenance

Accepted wisdom is that most of the cost of software lies in its maintenance. As far back as the 70s various researches pegged it at 40-80% of the total lifecycle cost, with most of the papers leaning towards the higher numbers.

Nothing seems to have changed; Bertrand Meyer (in Objected Oriented Software Construction) claimed that in 1997 70% of software costs belong in the maintenance phase.

But is this true for firmware?

To my knowledge there are no studies on the subject; indeed, embedded systems are the stealth segment of software which simply doesn't garner the research applied to IT projects. So all we can do is speculate. But if that astonishing 70% number did apply to our projects, the cost implications are staggering.

Embedded code is inherently different than that living in the world of a PC. Despite 'net-based reflashing that some products support, for most firmware a software upgrade is very costly. The car must come back to the dealer, or an instrument has to be returned to a repair depot. One could argue that these costs change the nature of the code; that the expense of doing an upgrade is such that firmware engineers inherently build better code. And, of course, some products are never upgraded, like a smart toothbrush.

Meyer quotes a study by Lientz and Swanson finds that 42% of maintenance costs stem from changes in user requirements. My sense is that there's little of that in the embedded space. MP3 players neither get recalled for bug fixes, nor are a stream of continuing software releases that improve functionality available. Instead, vendors launch a new version of the product, one that has a raft of newer, cooler features. The previous version's hardware and software is obsoleted.

That's very different than the PC, where on might use versions Word for years, contributing to Microsoft's bottom line via a never-ending series of upgrades rather than replacements.

Perhaps in the embedded world maintenance due to changing requirements is really expensed as new product development.

Lientz and Swanson claim 18% of maintenance costs come from changes in data formats. That smells like a problem in the info-processing world than in firmware. 21% are due to bug fixes, a plague shared by all programmers, and 6% from hardware changes. One would think that is entirely in the embedded domain.

But maybe things are changing. Philips recently sent a patch to their smart light bulbs that disabled access to competitors' products. (Yes, for a mere $60 each you, too, can outfit your house with bulbs that some teenager can hack). The company backed down after being deluged with complaints. We've all heard about the cheating software VW will have to patch.

Is the future of firmware maintenance cleaning up ethical lapses?
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. There is no charge for a job ad.
Joke For The Week

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

From RISKs Digest 28.91: "A great example appeared in a 1999 issue of Computing.  A representative of a company with a voice recognition product prepared to demonstrate their product and asked the crowd gathered to see the demonstration to be quiet.  Someone in the back of the room shouted, ``Format C Colon Return!''  Someone else shouted, ``Yes, Return!''  The software worked perfectly, reformatting the primary disk on the demonstration unit, requiring that the machine finish its format and have all of its software and data reinstalled."

Advertise With Us

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