You may redistribute this newsletter for noncommercial purposes. For commercial use contact email@example.com.
The average firmware teams ships about 10 bugs per thousand lines of code (KLOC). That's unacceptable, especially as program sizes skyrocket. We can - and must - do better. This graph shows data from one of my clients who were able to improve their defect rate by an order of magnitude (the vertical axis is bugs/KLOC) over seven quarters using techniques from my Better Firmware Faster seminar.The seminar is all about giving your team the tools they need to operate at a measurably world-class level, producing code with far fewer bugs in less time. 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.
I'm now on Twitter.
|Quotes and Thoughts|
"For a long time it puzzled me how something so expensive, so leading edge, could be so useless. And then it occurred to me that a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match." - Bill Bryson
|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.
I'll present my Better Firmware Faster seminar in Melbourne, Australia February 20. All are invited. More info here.
Robert Smallwood is the lucky winner of last month's contest; he got a Freescale FRDM-KL25Z development board.
This month I'm giving away a Raspberry Pi 2 Model B. The contest will close at the end of March, 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.
Matt Chernosky wrote:
I just wanted to weigh in on the VM discussion.
Another tool which is really useful is Vagrant (https://www.vagrantup.com/). It's kind of like a wrapper for VirtualBox or VMWare, which lets you script the creation and set up of virtual machines. It's used a lot for web development environments (where there are often a lot crazy dependencies to setup), but there's no reason you can't use it for embedded development environments as well.
It uses a plain text Vagrantfile which describes the configuration of the machine, and then a provisioning script that gets run inside the VM once it's created.
With Vagrant -- instead of giving you a bunch of instructions to install and configure the project dependencies -- I can just give you this Vagrantfile and provisioning script. These files can be checked into source control right along side of your source code. This is what the what the web DevOps people call "configuration (or infrastructure) as code."
You can set it up to automatically forward your target USB connections to the VM as well. And, it automatically creates a shared folder between the VM and your host machine.
I wrote an article about it here: http://www.electronvector.com/blog/portable-reproducible-embedded-build-environments-with-vagrant
The Boston Embedded Systems Conference is just over a month away. The convention center will be packed with exhibitors and attendees. A thousand or so will attend the program sessions, talks by fellow engineers about new technologies and different ways to develop embedded hardware and software. Most are deeply technical and serious.
But not all. I'm doing one on embedded disasters. For tens of thousands of years people have passed knowledge from generation to generation via stories, rather than web sites and the written word. The human brain seems predisposed to remember stories far more efficiently than we retain formulas. The lore of disaster is so compelling that I use anecdotes to help drive the lessons-learned home.
One of those lessons is about the danger of abusing our tools. Space missions have been lost due to poor version control, an astonishing fact considering how well-known that problem is, and how easy it is to solve.
Then there are languages. C code is usually buggy compared to some alternatives like Ada. Compilers happily accept constructs like:
... even though no human on the planet has a clue what that means. Compilers happily swallow:
... whether that's correct or not, probably without even generating a warning.
"Good" C code usually runs a 5 to 10% error rate post-compile, once the syntax errors have been removed. Ada programs are about an order of magnitude better. These are typical numbers experienced in practice, not quantities that are indicative of the languages themselves. With the right tools and discipline C bug rates can approach those of Ada. Fact is, few developers employ those tools or rigor.
Sometimes people mistake my comments about C as a condemnation of the language, rather than a complaint about how we use C. So I expect, once again, a flurry of emails with comments like "It's a poor craftsman who blames his tools."
It's a poor craftsman who blames his tools. That phrase sounds wise and profound. It's wrong.
Perhaps Noah could build an ark with nothing more than an adze. Few boatbuilders since have managed such a feat. Today's boat shop is packed with tools, each one exquisitely-designed to fulfill a particular task. Take those away and the skilled builder will find his productivity crumble.
That same craftsman has a variety of choices in tools. He could select a $100 Sears quarter-horsepower table saw or a $2000 5 hp Delta Unisaw. The former can barely cut a straight line; the latter sports so much accuracy it's easy to slice a shaving 1/32" thick from a long board. The Sears model might get through a two inch hunk of teak -- in a week -- while the Delta will rip the same board in seconds.
There are some, a very few, extremely-talented boatbuilders who can accomplish miracles with a nearly-empty toolbox. Not many, and all of those are starving, rendered irrelevant by better-equipped workers who produce wonderful products faster and therefore cheaper.
Tools matter. Bad ones slow us down. A compiler that frequently miscompiles will bring a project to its knees, no matter how skilled the developers may be. Though tools won't turn an amateur into a skilled professional, good ones make everyone more efficient.
It's a demanding craftsman who blames his tools. And then he discards the bad ones, sharpens those that are dull, and adds additional ones where a need exists.
C is the community's lingua franca, and will be for a long time to come. Like every language, it's imperfect. The true artisan uses additional tools to help him create great code efficiently.
Don't, and your product might end up in one of my Powerpoint slides!
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.
Note: These jokes are archived at www.ganssle.com/jokes.htm.
Apple's new phone lacks backdoors and has a hack-proof OS:
Advertise in The Embedded Muse! Over 25,000 embedded developers get this twice-monthly publication. For more information email us at firstname.lastname@example.org.
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at email@example.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 firstname.lastname@example.org for more information.