Charting the system design and describing the performance parameters and interface are best accomplished prior to building the prototype model. Not all changes can be implemented in firmware.

I have been a computer consultant specializing in products based on microcontrollers for over 20 years. Over this period of time I have designed the hardware and written the software for consumer, medical and industrial devices ranging from children's toys and games to blood pressure machines and blood analyzers. In virtually all of these items I have noticed what I somewhat facetiously refer to as the "Oh By The Way" syndrome.

In days before the $.49 embedded microcontroller integrated circuit, the engineer had to very carefully and thoroughly define the operational characteristics of the product he was working on. The operational specification was followed by a detailed block diagram of the hardware. the schematic and ultimately the printed circuit boards.

Changes to products after the printed circuit boards were completed were among the most torturous events that could happen to an engineer. Altering printed circuit cards with an Exacto knife, a Dremel tool, jumper wire and a soldering iron in the early morning hours just prior to the demonstration for your biggest customer is something that you sort of wish upon your worst enemy.

So the good engineer always tried to get the product defined as completely as possible. One 3 AM session with the modification tools of the trade is enough to remind you never to willingly let it happen a second time. But then came the 4004 and 8008 microprocessors from Intel (only grey haired engineers remember those parts.)

The engineer was now responsible for designing the hardware that had the right number of inputs and outputs. Enter the "software" aspect of the project. Someone who practiced the "black art" of programming was responsible for controlling how the hardware worked. Somehow all of the programmers invariably had long hair, wore a dirty sweater and never took notes on what you told them. They rushed off into back rooms to generate lines of code that were supposed to provide the solution to the operational requirements of the project.

In the last 20 odd years this black art has progressed into a discipline which can legitimately be called software engineering. But even with documentation techniques such as flow charts and commented code, too many projects suffer from the lack of definition that was a virtual necessity in the "good old" hardware days.

Because a major change in a product can be implemented with a coding change instead of a hardware change, the engineer has unfortunately not been as forceful in insisting on complete operational specifications before the hardware and software aspects of the project begin. The non-technical company personnel, (marketing, sales, etc.) who are frequently responsible for defining what the next line of products should be, are not in a position to produce this operational documentation.

But they know that the "program can be changed" to incorporate new features. So they spring these beauties on us poor engineers at the last moment. These are the "Oh By The Way" additions that start to wreak havoc on a project. Microcontrollers have a fixed amount of programming space (ROM) available, and these "Oh By The Ways" have a nasty habit of eating up left over ROM very quickly. Add more memory you say, get a bigger chip you suggest.

Unfortunately some microcontrollers are available in several memory sizes, the larger capacities cost more money. Bill of material costs, especially for consumer items, do have limits. So in many cases the size of the microcontroller is fixed; it's just the appetite for more features that is unsatiable.

So how does the programmer incorporate the "must have" feature into a microcontroller whose code space is essentially full? You become cleaver! You rewrite parts of code so you can save an instruction here and there. Ultimately you clear enough space in the ROM so that the "must have" can be included. This type of programming throws out every statistic on how many lines of debugged code a programmer can write per day.

We all know that a product cannot always be defined to the last button push and blinking light, but that is still no excuse for not adequately specifying what is supposed to be done at the beginning. In "old days" we had the preliminary design review meetings and final design review meetings in a determined attempt to avoid 3 AM Exacto sessions. We didn't always succeed, but I don't ever remember throwing out an entire set of printed circuit cards and starting over. I can not count the number of times I have heard "it's easier to discard the program and start over."

How much of this "start over" conclusion is based upon poor documentation and how much is based upon a series of "Oh By The Ways" is academic. But it seems to be a generic illness based on the assumption that anything can be fixed by changing the software. While this may be somewhat true, it is still not proper design procedure to start implementation without really knowing what you are doing. Fixing it later is not the answer.