Everyone is in a hurry these days and embedded system developers are no exception. Development teams are racing as quickly as possible towards a goal or a delivery that isn’t just a moving target but may not exist at all! Fire! Ready, aim goes the mantra but what about teams that have a known goal, a target that they are trying to reach quickly? Below are several tips that embedded systems developers can follow to get their system to market faster.
Tip #1 – Use the right tools for the job
Have you ever tried to tighten a screw using the wrong size screw driver? If you have, you know very well that that several different things occurred:
- The screw head was probably stripped, making it difficult in the future to remove
- Extra pressure had to be added to get the desired result
- It took much longer than it should have taken if you had just used the right screw driver tip
Developing an embedded system is no different! I encounter countless engineers and teams every year who are in a hurry to get their products to market but who are unwilling to spend a little bit of money on the right tool. That tool could be a:
- RTOS
- Computer
- Software stack
- Debugger
- Compiler
- Integrated Development Environment (IDE)
- Etc
In order to save a few thousand dollars, these teams suffer huge losses in productivity and money due to extra time compiling, debugging and testing their systems. A simple bug that should have taken a few minutes to discover with a trace tool suddenly takes days or weeks to discover. Does any of this sound familiar?
Tip #2 – Add test points for every MCU signal
Test points are quite possibly the most important hardware feature that an embedded systems developer can add to their hardware to ensure that their system can be easily debugged. Test points allow software developers to get access to critical signals that provide them to peer into the software and see what is happening at the hardware level. If a component such as a SD card or EEPROM device is not working as expected, a developer needs to see the communication signals in order to figure out what is going on. Without them, it’s all just guesswork and will take ten times longer to debug.
Test points don’t have to be fancy, they can be small vias and won’t these days won’t affect the board cost much if at all. Don’t forget to also put test points on unused GPIO pins. Developers may find that they need a few extra output signals to understand their software timing.
Tip #3 – Develop and use automated tests
Thoroughly and successfully testing an embedded system can be time consuming. A minor software change can result in having to go back and rerun hundreds of test cases. If a team is doing this manually, they are either going to spend most of their time testing or shrug off minor changes, cross their fingers and hope for the best.
Creating automated tests that can be executed on a continuous integration server where builds are checked nightly can ensure that developers focus their efforts on developing software and not testing it. Developing automated tests does require upfront time and effort, but the long term benefits and savings are too big to ignore.
Tip #4 – Create and use Hardware Abstraction Layers (HAL)
Hardware abstraction layers are a great way to separate the underlying hardware from application the code. A HAL provides developers the ability to write their application code without having to worry about the hardware that they are developing for ( or at least think less about the hardware). The low level implementation is hidden behind a set of standard interfaces ( function calls) that remain constant.
Developers can either create their own HALs that they are responsible for managing or use one that already exists. Many microcontroller manufacturers provide a HAL that simplifies interacting with their products. Leveraging an existing HAL can dramatically save time especially if it is qualified or industry standard.
Tip #5 – Leverage existing components and frameworks
The trick to moving faster is to stop redoing the same work over and over again. Embedded software developers love to work in the bits and the bytes, playing with hardware registers and at the lowest software levels. Times are changing. Development teams that don’t leverage existing components, libraries and frameworks and instead decide to go it on their own will be left behind. There are more than 100 different RTOSes on the market which easily fit every possible conceivable application and licensing scheme. Writing your own doesn’t make sense.
The same goes for other components that are typical in many embedded systems today. Creating SD Card, EEPROM, USB, TCP/IP or other common software stacks makes no sense. Starting from scratch is time consuming, expensive and odds are that the robustness will not be anywhere near what can already be found out in the wild.
Tip #6 – Use trace tools to debug your system
For many development teams, debugging consumes nearly 40% of the development cycle. With so much time being spent debugging, developers need to make sure that they don’t just have good debugging tools but the right debugging tools. Traditionally developers have had to sprinkle their software with blinking LEDs, printf statements and the like in order to guess at how their software is executing. Modern microcontrollers now have powerful debugging modules built in that can record events such as:
- Entering and exiting a function
- Interrupt entering and exiting
- Task context switches
- RTOS object events
- etc
Developers can literally record these events with timing and visualize how their software is executing. It takes all the guesswork out of debugging which then decreases debugging time and time to market.
Tip #7 – Design for Reuse
Embedded software developers need to start thinking in an object-oriented manner, and for this post, that means that they should be thinking about reuse from the start. Embedded software has traditionally been developed in a one-off manner. Write directly to the registers, mix the application code in with the hardware code and voila! Code complete. Embedded systems have become far more complicated than they were just five years ago let alone a decade ago. Writing applications in this one-off manner no longer works.
Instead, developers should be layering their software and asking from the design stage which components have the potential to be reused and which will be used once and discarded.
Conclusions
Even though todays development teams are under pressure to work faster and faster, there are plenty of tools available to help them in this quest. We’ve examined just a few different tips on how embedded system developers can work faster. It’s up to them to realize that in many instances, slowing down and being disciplined will be far more beneficial.
What tips and experiences do you have for building embedded systems faster?
