10 software tips for hardware engineers

Embedded system design often requires not only an understanding of the hardware but also of how the software affects and interacts with it. Designing hardware requires a certain engineering paradigm that can be a complete polar opposite of designing software. When transitioning from hardware design to include software design, here are ten software tips that hardware engineers should keep in mind when they start developing software.

Tip #1 – Flowchart First, Implement Second
When an engineer first steps into the realm of developing software, there is an intense temptation to jump right in and start writing code. This mindset is the equivalent of trying to lay out a PCB before the schematics have been completed. It is critical when sitting down to develop software that the urge to start writing code be ignored and instead an architectural diagram of the software be developed using flowcharts. This will give the developer an idea of the different parts and components required for the application much like how a schematic tells an engineer what hardware components are required. By doing this the program overall will stand a better chance of being well organized and thought out which will save time and headaches in the long run by decreasing debugging time.

Tip #2 – Use State Machines to Control Program Flow
One of the great software inventions of the 20th century was the state machine. An application can often be broken up into multiple state machines each of which controls a specific component of the application. Each of these state machines has their own internal states and state transitions that dictate how the software reacts to various stimuli. Designing software using state machines will ease in the development of software that is modular, maintainable and easy to understanding. A wide variety of resources exist that demonstrate state machine theory and algorithms.

Tip #3 – Avoid the Use of Global Variables
In the old days of functional programming, function came before form with the programmers’ sole goal being to make the program operate as expected as quickly as possible without regard for program structure or reusability. This programming paradigm held no apprehension about using variables that were global in scope that any function within the program could modify. The result was an increased chance of variable corruption or misuse of variables. In the new recommended object-oriented paradigm, variables should be defined in the smallest possible scope and encapsulated to prevent other functions from misusing or corrupting the variables. It is therefore recommended that you limit the number of variables that use a global scope. These variables can be identified in the C language by the use of the extern keyword.