During this year’s Engineering Design Show, a panel of Witekio experts took to the stage to discuss practical chip shortage workarounds with embedded software.
You can see the highlights of the team at EDS, below:
As the topic is something we’re helping our clients with more and more, we decided to condense the hour-long workshop into an article, so everyone could reap the benefits of our experts’ advice on this subject.
Due to a host of reasons (Covid, factory fires, geo-political issues and more), there is a global chip shortage creating supply delays of up to a year – meaning huge setbacks for connected projects.
Although we’re starting to see pressure easing in the supply chain, it will be a steady and gradual climb back to meeting demand again, meaning many connected projects will need to think carefully about the hardware they pick now and in the near future.
Luckily there are ways to work around this, and even breathe new life into existing products, without needing to invest in new hardware (or wait for the chips to arrive).
So today we’re going to outline these workarounds and talk about the practical ways you can adapt your code to help you keep your products fresh. But first…
What does Witekio know about navigating the chip shortage?
As an embedded software expert – quite a lot! We see real use-case scenarios daily of clients wanting to update, expand or launch their device, who are unable to as originally planned due to chip delays.
It sounds simple, but sometimes the most straightforward answer really is the best one. Instead of updating your hardware – why not extend the functionality of your existing product?
Witekio has recently done just that by adding secure network communications to an existing device that needed E2EE (HTTPS), but their planned redesign wasn’t possible due to component wait times.
Our solution – add TLS support and certificate management to allow secure HTTPS connections between the client and webserver.
With this workaround, we obviously had to take in mind the RAM and flash footprint of the existing code and think of the best ways to make space for our updates.
One such space-saving technique is to ensure all binaries are stripped and use of -ffunction-sections, -fdata-sections and -gc-sections to prevent the inclusion of unused functions and variables in the executable.
Another hurdle with this workaround was ensuring the performance of the device was not affected, especially if there is no hardware accelerated cryptography support.
In this case we know the choice of cipher suite can make a large difference. For example, using ECDSA instead of RSA reduced total time of the TLS handshake from ~1 second to ~200 millisecond on this particular MCU.
Thinking of doing this? Make sure to benchmark where space is used before beginning your project, and focus efforts on the largest space contributors.
If your product has the ability to connect via Bluetooth or Wi-Fi and you’re looking to add new features, why not make the most of this external element?
We were faced with exactly this question when a client of ours needed help diversifying their product range by introducing a display-less version.
Instead of having a device that relied heavily on a screen, they wanted to run all commands via a new smartphone app.
After looking at the legacy product code, we knew to do this we needed to create new software architecture. Our approach was to:
– Demote the GUI from being “the system” to just another component
– Modularise core components of the system
– Abstract system control behind a well-defined RESTful API
– Use of well-defined standard Linux interfaces and libraries provides the ability to easily switch to different chipsets for future products in the roadmap
Thinking of doing this? Make sure to ensure feature parity through frequent A/B testing between new and old behaviours.
It’s in the title really. If the hardware you want has a long wait time, find another chip that’s available to you.
Of course, you might need to compromise on your end functionality due to the change in hardware, but it’s up to you if those compromises outweigh the possible two-year wait.
For a recent project where a client wanted to reduce Bill of Materials and replace components that were End of Life (EOL), we proposed exactly this.
We needed to replace two SoC systems with a single SoC solution that had guaranteed availability before their current component’s EOL.
We did this swiftly by re-designing the components and the system concurrency model to provide feature parity on a single more powerful multi-core SoC.
Thinking of doing this? We recommend modularizing software components for ease of porting.
If you have a product with performance issues that you’re not happy with, don’t skip straight to new hardware!
For instance, if you want to increase the battery life of your product, look to software power optimization instead.
By investing time into the power optimization of the MCU and MPU, we’ve seen a 50% increase in run-time and 1000% increase to standby time.
It might sound too good to be true, but it’s not. To do this you need to look at:
– Understand the current power profile of the device
– Start optimising the lowest hanging fruit first
– Repeat profiling and optimisation
These are just some of the many ways Witekio can work around the chip shortage to ensure you continue to get the most from your product.
From long-term updates to short-term fixes, we have both the embedded expertise and hardware understanding to suggest reliable fixes for your project.
We’re an Avnet company, meaning we have a direct link to one of the biggest hardware component distributors in the world.
