You’ve been spending months if not years on an embedded project for a new product launch. And then the worst news of all comes in from the procurement department – we cannot source the necessary component(s) from our supplier(s)!

The reality is that this is a common issue these days due to supply chain disruption stemming from a variety of global crises. Swapping hardware at any point in an embedded development project is not an ideal solution – you and your team have spent countless hours researching, engineering, testing, and coding. It essentially could be the life-or-death of the product and a major impact on the business’ financials.

In this article, we’ve outlined four different scenarios to help you rationalize your options and hopefully come up with a solution to keep your project moving forward. And a few solutions to choose from to minimize the impact of shortages in the future. 

If you’re just starting your project, we encourage you to read this article and then strongly consider the scenarios provided to modernize your embedded project – and keep you isolated from major crises and cost overruns due to component sourcing issues.

Scenario one - Find a drop-in replacement.

The first thing to do is to use an online database – such as Octopart – to search for availability and compatibility quickly. The best-case scenario is a pin-for-pin, footprint compatible, replacement. This is a direct drop-in replacement that doesn’t involve much engineering time or changes to other hardware to accommodate. The replacement should be of similar spec and/or over-spec’d for the project to ensure there are no operational hazards for the end-user. 

Scenario two - Find a functionally equivalent but different footprint component.

The next worst scenario is that you have exhausted your searches to find a direct drop-in, but you do find a component with the same (or improved) functionality that has a different footprint or pinout. This scenario will require some rework, but with hopefully minimal impact on the project timeline and budget.

The electrical engineers will need to modify the printed circuit board (PCB) design to accommodate the new component. Hopefully, this is only a minor change to the PCB, but it can vary from board to board. You will also likely need to make minor adjustments to the code. If the new component is from a different family of chipset or manufacturer, you may have a lot of changes to make. Then, your team will want to take sufficient time to test your product again.

Scenario three - You have all other components (or a majority of the components) and you’re missing the microcontroller.

A shortage of a microcontroller fits somewhere in the middle as far as the complexity to replace – depending on the replacement you find. If it's from the same chipset family, often the footprints are the same (ST does a particularly good job of keeping micros within a family pin-compatible with each other - and their STM32CubeMX tool is a great tool to just search through their product SKUs), but you will almost certainly need to modify the firmware to ensure the product is functional again.

If the differences are small, or if you've invested in a hardware abstraction layer (HAL) in your code, the change can be relatively easy and require little to no involvement of the engineering team to complete the project. Alternatively, if you're using a real-time operating system (RTOS) – such as Zephyr – which has hardware-agnostic drivers and a built-in HAL, you will also find your work relatively easy to complete and enter production. 

However, if you have to use a completely different microcontroller, you may find that a substantial rewrite of your firmware is required – and possibly a lot of electrical rework on the PCB as well. This emphasizes the value of HAL and RTOS design decisions early on in the process. The industry seems to glorify writing "bare metal" code as a test of strength or some sort of badge of honor, but often the bragging rights are worth very little when you are staring a shortage of your main micro in the face. 

Further exacerbating the problem, most software development kits (SDKs) from silicon vendors do not make using a HAL or RTOS easy – they tend to drive you right into the bare metal option that comes with all of these pitfalls. Why? It's in their interest to lock you into their product to increase market share and dependence on their products.

Scenario four - You’ve exhausted all other options to source the component you need, but can’t find it or enough of them. You need to bite the bullet and rework a major portion of your design.

This would be considered the “worst-case” scenario in an embedded build. Your team has tried everything to find a replacement, and literally scoured the globe to source it – but – it cannot be found, there are only a small number of them, or the cost is exorbitantly high and the finished product will not be financially viable in the market. You might have to get creative to fix the problem and/or there simply may not be a fix. You’re going to be facing major rework and delays in the project.

This scenario can be firmware-related, electrical engineering (or both) depending on the nature of the change and fixes. If you've prepared well in your firmware, you can minimize the impact of this type of change.
This scenario could be seen as an opportunity to take advantage of a less-than-ideal situation in the current state and focus on creating a more advanced, future-proof product with an advanced design or with components that are readily available. 

This is why we advocate for a modern embedded design approach early on in the planning process – it will make major reworks a little less painful. 

A long-term solution

Taking a “modern embedded” approach early on in a project is the best solution to overcome all of the problems outlined above. The reality is a lack of components in a high-demand economic environment, with supply chain uncertainty and shortages in components, are a day-to-day occurrence. The shortage of components will likely persist in the near term. 

As an industry, we can take this “crisis” in the supply chain as an opportunity to be mindful of our decisions and improve our processes. Some of the decisions you may want to consider include:

• Choosing silicon with footprint-compatible families of devices (like ST)
• Using an RTOS like Zephyr or FreeRTOS/CMSIS combo which abstracts the hardware away
• Designing out unique components or sourcing them early in the design process to ensure they are available when the design is complete (which actually exacerbates the supply problem, but is about all you can do to protect yourself)
• Supporting localized vendors and on-shore vendors whenever possible, so that components aren’t stuck in transit or in a port of entry for weeks, if not months at a time
• Choose a partner that takes a “modern embedded” approach to do business with

If you’re stuck trying to work through these issues, the Dojo Five team is available. Feel free to connect with us to explore your options.