Software Design
This continues on from my posts on Software Architecture and Operating Systems. The basis of Software Design for Embedded Systems is ensuring that you implement the required features within the available hardware. A lot of people forget that second point. I have found there are many more opinions on what you “Should Do” than there are helpful ways of assessing what you “Can Do” and how likely it is to be successful. Way too much of the conversation is like the picture below.
Software – You’re Doing It Completely Wrong!
Unlike a typical Computer Science project, there are hard and fast restrictions on the system resources in a Small Embedded System. Some of the constraints to consider are:
- RAM
- FLASH or program storage space
- Clock Speed for both the peripherals and the main processor
- Power Consumption
- IO and peripherals
- Latency requirements
If we have selected an Operating System then we also have constraints from that choice:
- How to tasks or modules communicate?
- How is data protected from simultaneous access by foreground and background tasks?
- What is the worst case latency for a task or interrupt response?
- Can I meet the peak execution demand with the processor, Software Architecture and Operating System?
- What design methodology will I use?
- How will I test?
Software Design Methodology
This is also a pretty big area. For now we will focus on the primary methods that are used to manage more complex projects.
State Machine
The first and most important is the State Machine, originally known as the Finite State Machine. It was an invention of Hewlett Packard and many were surprised that Intel beat them to the first microprocessor given that the State Machine was one of the breakthrough concepts that made that possible. At it’s core, a State Machine defines the states a system or sub-system can be in and the conditions under which it moves from one state to another. Below is a State Machine for estimating the charge left in a rechargeable battery. We design a lot of battery powered equipment so this is a common design element for us.
State Machine
One big advantage of a State Machine is that it can be easily designed to operate in a polled environment where very little processor time is required until a transition condition is achieved. This allows very complex systems to operate without needing a larger processor.
Test Driven Development
Test Driven Development is the next important Software Design Methodology to consider. In this case the system is analysed and the test requirements identified. The tests are written and then the code is written and debugged until it passes the tests. If requirements change, then update the tests to match and debug until the code passes. Code is refactored once is passes all tests.
The big advantage of Test Driven Development is that you think about test up front and that generally leads to simpler designs that are easier to maintain. You also always have a full test suite to ensure changes made don’t have side effects that cause other features to misbehave. The tests pick this up automatically.
The big disadvantage is that you might write tests then decide to change direction and have to recreate those. These is also interaction between the system call structure and the test suite so you need to do more detailed design up front. But particularly in mission critical applications, always having an up to date test suite is a big advantage.
Rapid Application Development
The final consideration is whether you will use a visual coding or modelling system. For Windows Software we are big fans of the Embarcadero toolset, formerly under the Borland brand. These support Rapid Application Development or RAD as it is known. The tools create forms and provide the software skeleton to go with them automatically managing class members and access functions for you. This way you can focus on the application specific code. We find their C++ toolset one of the most productive to create application with.
These systems are generally used on general purpose computing platforms and larger embedded systems rather than a Small Embedded System.
However the concept behind them support rapid prototyping and minimal code writing to get to a working demonstration. Rapid Application Development is primarily about doing this. Get to a prototype fast then find out what the problems are. You can think of this as Risk Identification. Identifying and eliminating risks early is one of our core strategies for delivering projects on time and budget and is covered in more detail in our Project Management Methodology.
Modelling
Another common approach is the Unified Modelling Language or UML. This uses an open standard for a visual model to drive the code generation. You get the model right and the tool produces the Embedded C code for you. This is also important for reusability. The models are processor independent so in theory you can use them on any processor the toolset supports. They support state based design most easily but can be hard work for highly algorithmic processes or communications processing engines.
Regardless of the Software Design Methodology selected, the coding must still be done with care. But selecting the right Software Design approach makes that a much more likely process.
Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2012 Successful Endeavours Pty Ltd
