One of my passions is sailing across long stretches of ocean on a smallboat. In this hyperspeed age it's a silly obsession. I'm thrilled toaverage 5 knots (just under 6 MPH) over the course of a trip. A jetflies from here in Baltimore to Bermuda in two hours; by sailboat it'sat least a week, sailing 24 hours per day.
Being so far from land and help we carry an extensive set of spareparts so a simple failure doesn't turn deadly. Extra sails, dieselparts, plumbing, rigging, electrical, and more, hundreds of items arestashed all over the boat. Before leaving on a long voyage I create alist of spares so I know exactly what's onboard and where it's allstowed.
I do the same thing after building an embedded product.
How much memory is unused? That's a critical thing to know. If it's10 bytes count on extreme maintenance costs. The smallest patch mayconsume weeks as one recodes, retests, and requalifies other areas ofthe program just to free up some flash.
It's a simple matter to look at the link map, in most cases, to findthe program's size. RAM might be harder in an environment where it'sbeing dynamically allocated and freed, but some tools, like the freemem utility, will help. And stacks and heaps don't grow forever;they're generally bounded by the developer.
What about real-time issues? Is your system 9% loaded or 99%? Doyou even profile your code to see how much time is consumed? Time is aresource just as important as RAM, ROM or money. Run out, or run short,and maintenance costs will soar just as surely as they do when short onmemory.
It's not hard to figure idle time. See ExtremeInstrumenting for a couple of approaches.
I know one company that monitors CPU utilization with greatprecision, because their volumes are so high that the engineers arerequired to keep the processor loaded at 99% or better. Anything lessand they figure a couple of transistors can come out, saving amicrocent or two.
When one considers products that optimize hardware to improveexecution speed (like the tools for Altera's NIOS-II), you can't helpwonder if there's a market for a reverse optimizer. Something thatexamines to the code to minimize hardware needs. On an FPGA the onlydirect benefit (since the transistors are still there) would be to freeup resources to add features.
At the end of a project do you know how much memory, and how manyCPU cycles, are still free?
Jack G. Ganssle is a lecturer and consultant on embeddeddevelopment issues. He conducts seminars on embedded systems and helpscompanies with their embedded challenges. Contact him at . His website is
You just hit on one of my pet peeves:
You said: “I know one company that monitors CPU utilization with great precision, because their volumes are so high that the engineers are required to keep the processor loaded at 99% or better. Anything less and they figure a couple of transistors can come out, saving a microcent or two.”
It will cost you more later on if you need to do a SW upgrade and you don't have the space available! I say… keep system utilization below 85%, so you have room for expansion if you need it! Example: Suppose you have a space probe or weapon system that needs a heafty SW upgrade. If you have designed in 15% more space than initially required, you're safe. If not, your costs will sky rocket because you have to redesign the HW.
– Steve King
There have been many times where I have written some PERL scripts to parse the linker MAP file. I have done this to get an idea of what modules take up the most code. Also, it is a good idea to keep track of the .bss global variable space.
Most developers do not do this though. In general, the model that is normally used is Shoot and Wince.
– Ken Wada.
Instrumenting processor bandwidth is always a good idea. A lot of the simpler projects I do end with with a round robin scheduler instead of an RTOS. I toggle a spare I/O bit on at the beginning of each pass through the round robin scheduler and off at the end. Monitor the I/O pin with a scope to let you when the system is bogging down. You can move the I/O toggling logic around to instrument specific execution time spent in each module within the code. Toggle the I/O pin in the same way while handling interrupts to see how much of your processors bandwidth is consumed there.
The idea of 99% processor utilization scares me. Seems like they are setting themselves up for failure. I sure hope these systems aren't being used to control anything that could be lethal.
– Phil Ouellette
I just read, I kid you not, this interesting bit:
“For every 5 feet of length and complexity you add to a boat, you will sail it half as often”.
You do realize, the more 'boat' you sail, the more prep time you need to plan a trip. To the point, where you might spend all of your time preparing, leaving nothing for the voyage itself. Are you likely to even go on a day trip that takes unforseen prep time?
It's the same with embedded system. The more features you add into a product, the harder it is to maintain and use. To the point where it becomes too cumbersome to use and maintain that for all practical purposes it just gathers dust.
A product is only a winner to the extent that it gets used.
So, when designing a product, think of the 90/10 or 80/20 rules. Typically 10 or 20 percent of the features will get used 80 or 90 percent of the time.
– Joe Sallmen
Also, when wrapping up a project, the tools, including the emulator hardware, used with the project should be catalogued, archived and/or stored, including an image of the hard drive in use to build the project, so that ten (or more!) years later something requires resurrection it isn't a mad scramble trying to find (remember?) everything that was needed. For instance, a project may compile on a later revision compiler, but does it work the same??
– Matthew Staben
I used to work at a conservative defense contractor, and we required our vendors to have 50% spare memory (both in RAM and ROM) and 50% spare processing time prior to initial production. (Changes and fixes after that could cut into the spare resources.) If the board could take more, or larger, chips, that counted as spare. Any self-testing that ran during otherwise idle time did not count against processing time.
– Bob Dowling