Firmware: Software for Electronics

The major steps in Firmware design:

• Program Specification
• Program Design
• Writing code
• Program Test

Program Specification

The specification for the Electronic Product being designed will usually also be the specification for the programming required. There is a lot of overlap between the hardware and software components, and it is often easier to specify the two together. In some instances a designer will trade off hardware against software, and so reduce the cost of the final product by implementing a function as code instead of in components.

The program specification will require the writer to go into substantial detail about how the product actually operates, and how it is used. To design a good user interface (if interaction with an operator is required by the product) requires a thorough knowledge of the products operation, and substantial experience with existing products, controls and menus.

A thorough program specification leads straight in to Flow charts and timing diagrams, which are components of Program Design.

Program Design

The program design stage lays out the structure and algorithms of the firmware. There may be several ways to do the same job, but some will work far better than others. The structure and algorithms may be laid out as a flowchart, a timing diagram, a description of a protocol, a memory map, or as equations.

The work done in the program design may be transient, depending on the job. It may well be that the material generated in the program design stage becomes largely irrelevant to understanding and maintaining the final code, if the final code is documented well enough.

Writing code

If the program is well specified and the algorithm design stage has been thorough, the actual code writing stage can become almost mechanical. By defining the software at the outset, before code is written, a much more defined, integrated, set of code can be produced. Code that has been modified extensively, or added to repeatedly, often exhibits "ragged edges" in its structure which make it difficult to understand. If this causes problems, the solution is a thorough rewrite. New code can also suffer from the "ragged edge" symptoms if it is written without a proper Program Design stage.

Commenting and Documentation

At AirBorn Electronics we value well commented software. The extra space occupied by comments costs nothing, and if the comments are well laid out and kept up to date there is no possibility that they can detract from understanding the code. The software itself is also a fine place to maintain the inevitable notes on revision levels, and interfacing to the hardware - it is the one item of documentation guaranteed to be passed to a new engineer on a job. Software commenting is just as important to the original engineer - it is difficult to remember the details of code 12-18 months after writing it.

It is difficult to understand how some individuals can churn out code without commenting or documenting it - but a lot do. You should hear warning bells if told that "the code is inherently self commenting" or "we will document the code as a separate task" or "pressure of time stops us commenting as well as we would like". The other side of the coin, is that I have personally had the experience of working on code from which some of the commenting had been removed - it existed, but the previous subcontractor had intended to use it as a lever to ensure the customer continued to avail himself of said subcontractors services. Needless to say, the customer found a new subcontractor - AirBorn Electronics.

Documentation is the castor oil of programming. Managers know it must be good because the programmers hate it so much. -- from "Fortunes"

Program Test

Program test can be similar to Electronics testing. To use a maxim:

"Divide and conquer"

By testing the code in a modular fashion, it is easier to detect faults before they are compounded by other factors. Program testing requires some way to get diagnostic data out of the target, for analysis. Often this is by way of emulation tools, or through the hardware itself, for instance a serial port. You can read more about our prototyping/debugging techniques in the "detail section" before this one: More info - Prototypes and more about the plan & method in Test procedures.

Realtime programming

The programming for control systems, Realtime programming, is quite different from the programming of a PC applications package. The programming of electronics systems is different again. The best results are achieved by staff with substantial experience in electronics design, or direct guidance by an electronics engineer. This cross-disciplinary skill is most important in the Program design stage, where the algorithms are actually set and divisions are made, for instance, between functions that will run under interrupt and functions that will run as a main-line task.

We have some example code available for you to examine, and details of an energy management project we were involved in: Firmware Custom design - an example. Our specialty is the code that actually runs on the target, where each increment of memory capacity and processor power adds cost to the product unit price. The code that runs on the target benefits from being efficient and carefully structured. We don't do a lot of work with the "front end" code that runs on PCs.

We hope you will contact us for your Realtime programming requirements - click on CONTACT or ENQUIRY to speak further with AirBorn Electronics

Prototyping Design overview Firmware design