You may redistribute this newsletter for noncommercial purposes. For commercial use contact email@example.com.
IBM data shows that as projects grow in size, individual programmer productivity goes down. By a lot. This is the worst possible outcome; big projects have more code done less efficiently. Fortunately there are ways to cheat this discouraging fact, which is part of what my one-day Better Firmware Faster seminar is 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.
Better Firmware Faster in Australia and New Zealand: I've done public versions of this class in Europe and India a number of times. Now, for the first time, I'm bringing it to Sydney on November 9 and Auckland on November 16. There's more information here. Seating is limited so sign up early.
Better Firmware Faster in Maryland: The Barr Group is sponsoring a public version of this class at their facility on November 2, 2015. There's more information here.
|Quotes and Thoughts|
Embedded systems have 20% of the defects of information systems. - Capers Jones.
|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.
Andrew Retallack recommends Nuts and Volts magazine.
Caron Williams asks of Muse readers:
Amen to this question. I have some ADP172 voltage regulators from Analog Devices here. They're 1 mm square in a WLCSP with four balls. I can barely see the devices, let along solder them!
|Freebies and Discounts|
I bought a $50 zero to 10 MHz signal generator from eBay. It's a new unit which was shipped from China; these things are for sale all the time on that site. I did a review of the unit, and it is this month's giveaway. Go here to enter. The contest will close at the end of August, 2015. It's just a matter of filling out your email address. As always, that will be used only for the giveaway, and nothing else.
|More on In-the-Field Firmware Updates|
In the last issue I asked how people go about doing in-the-field firmware updates. Several readers had replies.
One who wishes to remain anonymous wrote:
Ray Keefe contributed this:
|More on Second Sources|
In the last issue I wrote about the troubles we often have with parts going end-of-life.
Stephen Irons wrote:
The problem is not 'a part goes obsolete', rather it is 'we have to support many different versions of hardware'. This is just a fact of life, and we must be ready to handle it.
Refactor your code to support both old and new hardware
When new hardware comes into the picture, it is a good opportunity to work out where to divide between 'device driver' and 'application'. It can be very tricky to work out a good API for the application code, and to separate out the stuff that is specific to the processor instruction set, its interrupt architecture, the compiler hooks to interrupts, the interrupt controllers, specific features of the peripherals, dependencies on external hardware on the PCB, how the system starts up, when the peripheral needs to be started, and the 1001 other details.
But it is likely that you will have to support both old and new hardware for some period of time. So make sure that you separate the device drivers from the application. There are lots of ways to do this from compile time #defines (yuck), link time (different builds for different hardware), startup time (OS device drivers, or dynamic linking) to run time.
Know which version of hardware you have
These different things are all present in the system. It is better to make them explicit, rather than hiding them away.
Hardware designers seem to think that they can encode everything that software needs to know about the hardware into a handful of values, encoded using either a voltage on an ADC input, or a few digital inputs.
Unfortunately, over the life of a product, hardware changes are not always sequential. You have to support two different memory sizes, and two different ADC devices, and that version of PCB where one line was accidentally inverted -- sure, we don't sell them any more, but they are used in the automated test system, so the software has to support them. You have to support all combination of these, for a total of 8 different versions in the trivial example. It would be nice to keep a linear hardware progression, but it is usually not that easy.
So I prefer a feature list written into the device during manufacture. You usually have to write serial numbers, product codes, etc into the device -- this is just another field in the manufacturing data. Reserve 8, 16 or 32 bytes of non-volatile memory for the feature list. When you change a particular piece of hardware, allocate a bit to indicate which option is installed. Someone in the project team must be responsible for maintaining this list.
It WILL get messy, when you allocate 1 bit to distinguish between 2 ADCs, then later you have a third option, but you cannot allocate two consecutive bits. Just accept that, and hide it behind an appropriate API.
If you have more non-volatile memory available for your manufacturing data, you might also store the hardware description as an Open Firmware Device Tree, which can be used to initialise device drivers and give them meaningful names.
It is also best if this hardware description, whether hardware ID, feature list or device tree, is stored on the device it applies to. If you have plug-in boards, they must each be able to describe themselves. This might mean that you have to put a serial EEPROM on each plug-in board.
Keep the component change separate from any new features
The only successful component change project I have worked on was successful because the engineering team pushed back against the marketing team's desire for new features. We first finished the component change (schematic, PCB, software, manufacturing, etc); then when those problems were out of the way, we went about adding new features.
The worst component change project I have worked on saw the component change as an excuse to revamp almost everything about the project: new compiler, new RTOS, new product features, big code refactoring, and, incidentally, a new processor SoC. The lead engineer was used to working alone, and just did stuff as it seemed good to him. The whole thing took forever, and caused much tension between the lead engineer and management.
So my principle is to either change the hardware (with only software changes to support old and new hardware) or to change the software (with minimal hardware changes).
Manage the transition
Trevor Woerner said:
Larry Rachman had a story about a part change:
Frequent correspondent Harley Burton also has a tale to tell:
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 Steve Bresson - an old joke with a new twist:
Two engineers were standing at the base of a flagpole, looking at its top. A woman walked by and asked what they were doing. "We're supposed to find the height of this flagpole," said Sven, "but we don't have a ladder."
The woman took a wrench from her purse, loosened a couple of bolts, and laid the pole down on the ground. Then she took a tape measure from her pocketbook, took a measurement, announced, "Twenty one feet, six inches," and walked away.
One engineer shook his head and laughed, "A lot of good that does us. We ask for the height and she gives us the length!"
Both engineers have since quit their engineering jobs and are currently serving as elected members of Congress.
|Advertise With Us|
Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. For more information email us at firstname.lastname@example.org.
|About The Embedded Muse|
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.