Often, when I'm asked how I approach particular engineering problems, the questioner most specifically wants to know how to get started with any particular project that requires some firmware. I can say this much for certain: There really is no easy answer.
In my experience, the process of developing the firmware generally starts with the introduction of an idea or, in other circumstances, a hardware design review where the schematic for the device is first introduced. Roughly, the entire process goes as follows:
- Marketing and engineering comes up with either an idea or a solution to a problem.
- This idea gets formulated into either a set of specifications or more usually notes written on a whiteboard that are photographed, digitized, and distilled into bullet points, which are then further discussed.
- From this, a schematic is captured, reviewed, and further discussed.
- At this point, the firmware architecture is thought out and some consensus is built as to where to “steal” the existing firmware from — another project, an evaluation kit, a development board. Usually, the firmware comes from another project.
- The firmware gets modified from some existing project. I call this step moving the furniture around, because this restructuring process is tedious and time consuming.
- Usually by now a firmware baseline is created that can be ported to the hardware, which is being fabricated.
- The hardware comes in and hopefully a set of diagnostic routines can be “burned.” These diagnostics usually come in the form of a command line interface (CLI), pushbuttons, blinking LEDS, or some combination of all of these methods.
- The firmware and hardware engineers unit test the board. This step is called the initial bring up of the board.
- Finally, the firmware engineer is left to his own devices to port in the application, test, integrate, and get the application to run.
- The firmware is released. Many times problems are discovered during the application development process and the hardware must be re-spun. Re-spinning the hardware at least a couple of times is the general rule. In more complex systems, it is not uncommon to do up to a dozen re-spins.
- Another team may be developing some client-level interface that may interact with the device. This could be some client setup and monitoring application that will connect via USB, RS232, TCPIP, or some other interface.
- The final system test and integration is done at this point. Bugs are posted, fixed, and more testing and verification is done.
- Finally, at some point all of the hardware, support software, and firmware are released into some document / property control system. Then on to the next project.
Of course, the 13 steps I outline here are a broad overview of how these systems get put together. I'm certain, however, that many of you do your projects similarly. In some places, the process can be very rigorous and formal, in others, the process can be very ad-hoc and informal.
KISS, (Keep It Simple Stupid)
Many times, I hear: “You must keep it simple. Simple is very good. We want some high degree of elegance for our solutions.” In other words, the term Keep It Simple Stupid tends to get really worked up.
To this, I ask: “Well, I am not stupid, and for whom are we making this simple? Are we supposed to make it simple in implementation? Are we to keep the interface simple? Just what simple are we to do?” To me, simple is a relative word that can be fraught with all types of subtleties. Things in the real world of problems may look simple at 1st … only to get very thorny as the layers start getting uncovered.
A good example of KISS is the MSDOS operating system. Actually, to tell you the truth; I really enjoyed writing applications under MSDOS. Indeed, it has a very simple TTY-type of programming model. Plus, it was single-threaded, had well-defined interfaces to the various peripherals and an easy-to-use file system.
Outside of the engineering world; users largely put up with MSDOS. In fact, from my recollections whole industries were spawned to make DOS even easier to use. Also, I do remember that even Microsoft got into the act and for a brief period and created the DOS SHELL. This was an ill-fated attempt to make the OS even easier to use … However; it added a lot more complexity to the operating system.
In a nutshell, what originally started out as something very simple, in the end, sometimes becomes very complicated? I can honestly say that I do not think it was the fault of the creators of the MSDOS for the ensuing complexity. I think that this is the natural tendency of all systems to generally accrete more features and attributes until the KISS system becomes not so simple.
So, given this tendency of entropic system accretion; how do we deal with this with a typical firmware project? To this date, I have very seldom worked on a project where we started with a set of features and came out at the end with exactly the same set of features we started during the discussion and idea phase. In most cases, we wind up with even more features. Most folks call this feature creep.
One must note however; MSDOS was the OS which helped to spawn one of the world’s largest and most successful corporations. If economic success is any measure, then this is definitely a big thumbs-up for the KISS principle.
LAWS, (Least Amount of Work Smarter)
I forgot exactly where I 1st saw this term. The term LAWS reallylooks like it could have come from some sales person or a marketingprofessional. I believe it came from a book on interfacing the Zilog Z80processor, written sometime in the mid to late 1980s.
The premise of LAWS is that in general we should always try figure outhow to get various parts of what we need to do with the least amount ofeffort expended as possible. From my experience, it really does not meanthat one works less, (I wish). It means that we attempt to get moredone with less effort. In the end we all tend to put in very long hoursdeveloping hardware and code to make our systems do what they aresupposed to do. Then, inevitably, when we demonstrate what we have done,more features tend to get added and other changes come into play.Hopefully, these changes are implemented as extensions to the existingarchitecture, and not as outright modifications.
The following is a very small list of examples of the LAWS principle:
- A well-defined set of methods which are used repeatedly across projects and within a project. A good example of this would be the standard ‘C’ library
- Some baseline code which has all the drivers and a set of libraries, and is used as the starting point for any new project within an organization.
- An application framework which aids in some way to alleviate the coding required to implement some protocol or some other standard
- Of course, some shrink wrapped software which implements a protocol stack, file or operating system.
One of the caveats of creating these libraries and frameworks is thetendency to overdo it. Sometimes, one needs to know when enough isenough and start using those methods and attributes to go and finishcreating the application. I can honestly say that I am very guilty ofthis over-do mentality many times.
Lately, I had a spirited discussion of the KISS vs. LAWS principle inthe context of embedded systems design. My friend told me: “Ken! KISSand LAWS are simply two different sides of the same coin! I think youare over-analyzing this.” To tell you the truth, I have now come tobelieve that both principles come into play in any good design … to somedegree.
So, what do you think? Are these principles just two sides of the samedesign philosophy? Or are these principles simply different approachesto solving problems?
I thought it would be good to throw this out there for some discussion.This is the Embedded Round Table after all. Plus, I thought it would begood to get some feedback from you, and decided to not write a how-toarticle this time around.I promise to write more how-to articles in the near future however. Ireally do hope the how-to helps you in some way.