• Contact us
• Our Service
• Re-engineering
• Design Flowchart
• Home

Firmware: Software for Electronics

The programming used in electronics products is quite different from standard applications. The main difference is in resources - a typical PC has perhaps a few terabytes of more-or-less fixed storage, and a few gigabytes of RAM. The typical microprocessor in an industrial controller might have a a few tens of kilobytes of more-or-less fixed storage (FLASH) and one or more kilobytes of RAM. The programming in Electronics products is in intimate contact with the hardware - it twiddles bits, pokes flags, and cycles pins - and a lot of electronics programming happens "under interrupt" or in real time, and is timing critical.

• 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. In others, he will bring part of the function into software so it can be made more versatile, or put it into hardware so it can be made more reliable (a failsafe).

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 (the part that specifies how interaction with an operator is accomplished 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, and some will work 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 was written without a proper Program Design stage.

Commenting and Documentation

Most people who have to maintain or add to code really value well commented software. The extra space occupied by comments costs just the time to type and proof read, 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. Some people don't comment their code. You should hear warning bells if told that "the code is inherently self commenting" or "we will document the code as a separate task"

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. This can by using emulation tools, or through the hardware itself using 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 and method in Test procedures.

Realtime programming

The better Realtime programmers have some amount of hardware (electronics) skills in addition to their programming abilities. Many engineers dabble with both careers. 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 older example code available to look at. We also have details of an older energy management project we were involved in: Firmware Custom design - an example. AirBorn Electronics' specialty is the code that actually runs on the target. The code that runs on the target benefits from being efficient and carefully structured.