Embedded Firmware Refactoring, Optimisation and Migration
Legacy products are often based on older hardware platforms which often become under-powered or run out of memory which constrains further product development. Customers are always looking for new features and improved performance but often either don’t want to invest in new hardware or need to retain the current field population of devices.
These are ongoing challenges for any product manufacturer, but are particularly highlighted in embedded systems where product lifetimes are typically much longer than in consumer markets.
This article looks at some ways to address these issues, and why you may want to consider them.
Optimising your existing firmware can provide better performance and new features while still retaining the investment in your current hardware platform. This will not only remove (or at least delay) the need for a new hardware design but also provides an opportunity to add new features, fix existing issues and enhance reliability
Sometimes it can be as simple as using more modern development tools with improved binary code generation, but optimising embedded firmware is often a task where using a fresh pair of eyes can yield benefits, particularly if the engineers concerned have experience of this type of work and know the sort of pitfalls to watch out for.
A company’s own engineers are sometimes too close to the current design to be able to take an objective view of what is required to make the system run better and using a third party can frequently be the best way improve performance and reliability.
Firmware refactoring is often overlooked as a means of improving the maintainability of legacy code, but an effective refactoring exercise can greatly improve the quality of older code, and reduce the time to add new features. It can also help reduce the maintenance burden on the original code authors who are often now more senior and would be better employed on new design work.
Many successful products are based on legacy code and the longer they run and the more successful they are, the less engineers want to perform a major redesign on them. This leads to the firmware being a mixture of old and new code, often with different coding styles and varying levels of comments and documentation.
Adding new features, particularly non-trivial ones, can result in a lot of time being spent trying to review the current code and understand what it does, and means that adding these new feature is a complex and painful business. Consequently they will often be added in new files, using different design templates and coding standards which in turn help to propagate the issues.
Carrying out a detailed refactoring exercise can help to unify the legacy code base and make it more maintainable. A fresh pair of eyes can often identify bugs or weaknesses in the code and address them before they reach the customer.
It is of course important to ensure that the refactored code still does exactly what it is supposed to do, and so a suite of regression tests which can be run before and after are also essential.
The end result is then a code base which is once again fit for purpose and can be used as the basis for future development for years to come.
Firmware Migration (or “Porting”)
Sometimes the previous options are simply not sufficient, and you have to look at moving to a new hardware platform to get higher performance, lower cost and lower power. Although this inevitably requires investment in a new hardware design, the results can be significant and very cost effective.
A typical firmware migration project not only requires an understanding of the product requirements, but also experience of the new hardware and firmware environment. The old and new firmware may run on different operating systems and/or types of processor, and using experienced engineers to carry out this porting work can help dramatically reduce the risks and amount of work required.
The migration may also be combined with a refactoring exercise as described above so that a lot of the previous investment in developing the legacy system can be retained, but re-written so that the end result is much more efficient and offers higher performance, while still being maintainable.
To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.
Please login (on the right) if you already have an account on this platform.
Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers: