The market for connected products and IoT devices continues to grow. Products from coffee makers to sporting goods are now connected to the web. This means development teams have to run not only mechanical and electronics engineering in parallel, but firmware development as well.
However, firmware engineering is complex — and presents many potential risks related to programming for advanced feature sets. This can drive uncertainty in product development projects. In fact, budget and timeline misses are driven by firmware problems more frequently than by electrical engineering or mechanical engineering problems.
But there are three steps developers can take to prevent the most common firmware engineering problems:
- Beware of incomplete code libraries.
- Avoid continually learning new hardware or multiple platforms.
- Don’t waste effort on the wrong feature at the wrong time.
What can firmware developers do instead? Continue reading for our recommendations on how to refine your processes, eliminate inefficiencies, and speed up development.
Beware of incomplete code libraries.
Firmware development, whether for consumer or industrial electronics, is full of risks when it comes to development timelines and development costs. Firmware development typically begins with finding a package in the chip manufacturer’s code library that will serve as a springboard for development in a project. The code in that library becomes the foundation of a larger, interconnected code set.
Many developers have learned the hard way that manufacturer’s code libraries are often incomplete, or full of bugs. These bugs or deficiencies are not usually visible early in the development effort, but only become apparent later in bring-up or even in testing. That late in the game, unexpected delays or changes in direction can derail a project.
Avoid continually learning new hardware or multiple platforms.
Chipsets from Texas Instruments, ARM, and others each have advantages and disadvantages. But using multiple platforms within the development team can lead to inefficiencies. It can be difficult to keep up with the capabilities, constraints, and library quality for multiple platforms. When possible, choose one platform, and let your development team build a depth of knowledge around it.
It’s worth spending the effort to identify and commit to a platform that suits your products or projects, and weaning developers off of the others. For example, Nordic Semiconductor systems provide a solid set of features that are a good fit for consumer and industrial IoT products. The system provides solid foundations for BLE, Wi-Fi, and NFC communications, and the platform offers a large code library and a large user pool. This means that community-level support is easy to find when troubleshooting. Overall, the speed of development increases as a result.
Don’t waste effort on the wrong feature at the wrong time.
Firmware developers have a tendency to develop code with the functionality of the final production in mind. However, when firmware development is happening in parallel with electronics and mechanical development, this is problematic. Here’s why.
Consider the development of a web-connected IoT wearable, for instance. The product will have a number of high-risk physical characteristics or features that must be developed, tested, and iterated multiple times before production starts. In addition, there will likely be development milestones at which decisions will be made to fund or kill the rest of the project. It’s fairly common for funding decisions to be made based on market testing with a de-featured batch of prototype units. If the firmware team starts developing with the end-state (full-featured product) in mind, they may be successful coding to that spec. But the amount of effort, time, and expense will be more than was necessary since some of those features are not necessary for the prototype needed for user testing.
Rather than develop firmware to the final production state, firmware teams need to align with the overall project plan. This typically means planning for multiple iterations of the product (and therefore the firmware), with the level of feature inclusion increasing throughout the project.
If you’d like to learn more about our approach or talk about your electronic product development project, get in touch.
