This week we’re getting to know The Hackaday Prize Judge [Jack Ganssle] a little better. His depth of experience with embedded systems is formidable, and recently I was very interested to learn about his mission to improve the quality of the product in the embedded code universe. We’ll get to that in a little bit, but I wanted to start off with [Jack's] answer to my final question.
Is there anything else you’d like our audience to know about you?
My entry into this field was when the first 8 bit processor (the 8008) came out, and still find it endlessly fascinating. I write a lot about embedded topics, and give talks and seminars, on all of the continents except Antarctica (so far!). We live in heavily-wooded Finksburg, MD, which is just stunning this time of year, and, since my office is in the house, the commute is pretty tolerable. Other passions include sailing; I wrote an on-line book (www.ganssle.com/jack) about racing alone across the Atlantic. Great trip, other than losing the boat.
You’ve been on the forefront of firmware for many years. How have you seen connected devices change?
No wires! It used to be that most connections were RS-232 or RS-485. Then we got GP-IB, latter codified into IEEE-488. Now there are so many near- and not-so-near-field wireless interfaces. The complexity of the protocols has skyrocketed, too.
A new(ish) shift is the availability of really inexpensive ARM Cortex-M series MCUs. Some are tens of cents in volume. Many will run on milliamps. These will make the connected device industry really take off.
I’ve long been a fan of your research on button debounce where you mention software solutions are more common than hardware ones. Do you have a preference between the two?
I much prefer a hardware solution because you can get a perfect debounce. However, that’s generally the wrong business decision as it is much more expensive than using software. So, the reason I did all of that research was to see how switches really behave. Turns out that engineers have their own favorite amount of time to debounce for (10 ms, 20 ms, whatever), but with no real basis for the number. That’s engineering by divine intervention. As Deming said “In God we trust; all others bring data.”
You’ll likely be interested in the code of entries in The Hackaday Prize. How do you usually advise people to produce easy-to-read code?
A friend once told me he thought C was for people who hate to type. There’s some truth to that. Clean code means plenty of white space, use of descriptive and well-thought-out names, and plenty of appropriate comments. Whenever I see a function without a well-commented header block I gag. In fact, the right way to write code is to write all of the comments first. That’s the hard part, that’s the design. Then anyone can fill in the code. Editorial Note: Check out [Jack's] Guide to Commenting Code
I recently heard your interview on the Making Embedded Systems podcast. It seems you are an advocate of overhauling what has become an accepted practice of developing firmware quickly and spending a long time debugging it. For people just starting out in firmware, is there a resource you would recommend for learning better practices from the start. (great place to mention your seminar)
The average embedded project spends 50% of the schedule in debugging, so I guess the other 50% is bugging.
I work with engineers all over the world, and have observed that too many are too anxious to start coding ASAP. The pattern is to write a lot of code and spend gobs of time debugging it. The average embedded project spends 50% of the schedule in debugging, so I guess the other 50% is bugging. We need to cut down on the bugging to get a well-designed product to market faster. I push this concept in my Better Firmware Faster seminar and have written a lot about this (see http://www.ganssle.com). Check out the Personal Software Process for some good resources. Google on Ada, as well – even if you don’t use the language, its philosophy is spot on. And everything written by Capers Jones is great.
In that interview you also mentioned code review being paramount. How can this virtue be applied well in a project that has just one code developer? Any advice for small teams of 2-3 developers?
Code review is meant to do two things: bring many eyeballs to the code, and to break the dysfunctional “write a lot of code fast without thinking too hard and start debugging” cycle. Small teams still benefit from an extra pair or two of eyes reading the code. A one-person shop makes this harder, so I recommend writing the stuff and then putting it on a metaphorical shelf for a week. Then review it yourself. Do this before doing any testing. Keep metrics – how many problems you find – and set a goal to reduce this over time. We want to do the work up front: get it right, and then use tests not so much to find bugs, but to show that it is, indeed, correct.
You often write about the hassles of project management and dealing with time crunch. We have a deadline for The Hackaday Prize. How do you normally ensure a project gets done on time?
As Douglass Adams said “I love deadlines; I like the sound of them swooshing by!” First, they have to be realistic. That means real care taken in preparing them, and no capricious changes made by the boss. It also means managing changes: change always happens, but it also has a cost (in money and/or time) and we have to account for that. And, the schedule must be managed; we need quantitative and proactive management guiding the project from day one, instead of a week before the deadline when management by shouting begins.
Though you now write and speak about the science of software engineering, you have been part of the tech communities for many years. What was the coolest hack you saw to get something done on time?
Apollo 14. Remember that 13 was the one where the command module exploded. 14 really had to work. In lunar orbit the LM’s abort switch shorted out (probably due to a floating solder ball). Mission rules said they had 4 hours in which they could start to land, or would have to abort the mission. The folks at MIT came up with a smart but really fast software workaround, which saved the mission. Talk about cool!
There are a lot of people out there with a software background interested in embedded development. Can you speak a little about where they should target their hardware studies and how deeply they should go in order to round out their skill sets on the path to becoming firmware engineers?
I’m hearing from a lot of managers in recent years that they can’t find firmware people with a good grounding in electronics, yet it is that hardware that really defines embedded systems, and which differentiates firmware from normal, boring (in my opinion!) IT software. Every firmware person should have some knowledge of electronics. You don’t need to be an ASIC designer, but you do need to be decent with a scope and logic analyzer. The more you know about electronics, the easier it’ll be to get a job.
My Embedded Muse newsletter covers this. I published a number of resources about getting started (as I get asked about this a lot). Get a board, like Freescale’s FRDM-KL25Z ($13) and make stuff. Digilent’s Analog Parts Kit is a great resource to learn about analog electronics. I’m a big fan of The Radio Amateur’s Handbook as a resource to learn about electronics in general.
- 8008 by Konstantin Lanzet – CPU Collection Konstantin Lanzet CC BY-SA 3.0
- ARM chip by Viswesr CC BY-SA 3.0
- RC Debounce via The Ganssle Group
- Egg Timer by Hustvedt CC BY-SA 3.0
- Apollo 14 Insignia
The Hackaday Prize challenges you to build the future of connected devices. Build the best and claim a trip into space or one of hundreds of other prizes.