Maximize the investment in your legacy hardware platform

April 05, 2016

Maximize the investment in your legacy hardware platform

Even if you aren't planning to develop a new product, a number of options can help you make the most of your investment in your current embedded produ...

Even if you aren’t planning to develop a new product, a number of options can help you make the most of your investment in your current embedded product line. Legacy products based on older hardware platforms can become obsolete or use end-of-life components. Customers are also continually looking for new features and better performance, but often don’t want to invest in new hardware. 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.

Optimizing 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.

It can sometimes be as simple as using more modern development tools with improved binary code generation. However, optimizing embedded firmware is often a task where using a fresh pair of eyes can yield benefits, particularly if the engineers concerned have experience in this type of work and know the pitfalls to look out for. A company’s own engineers are sometimes too close to the current design to have an objective view of what’s needed 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 way to improve 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 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 a legacy codebase and the longer they run and the more successful they are, the less the engineers want to carry out 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, which means that adding these new features can be a complex and painful business.

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.

Finally, it’s important to ensure that the refactored code still does exactly what it’s supposed to do. Hence, a suite of regression tests which can be run before and after is essential. The end result is a code base that’s once again fit for purpose and can be used as the basis for future development for years to come.

Sometimes the previous options simply aren’t sufficient, and you have to look at moving to a new hardware platform to get higher performance and lower cost and power. Although this inevitably requires investment in a new hardware design, the results can be significant and 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 environments. 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 dramatically reduce the risks and amount of work required.

The migration may also be combined with a refactoring exercise as described here so that some of the previous investment in developing the legacy system can be retained. But it can be rewritten so the end result is more efficient and offers higher performance, while still being maintainable.

Ian Smith is Managing Director of Abelon Systems, an embedded systems design consultancy based in Edinburgh, Scotland. He has been developing embedded systems for over 30 years, and has experience leading and implementing complex technical projects on a national and international scale.

Ian Smith, Managing Director, Abelon Systems