How to continue embedded GUI development despite the silicon shortage

Up and down the tech stack, embedded systems manufacturers have one problem in common: there aren’t enough semiconductors to satisfy demand. Whether building wearables or in-home smart appliances, these components that make devices smarter and more connected are simply unavailable.

What does the chip shortage mean for continuing the development of your embedded GUI product?

“The half-trillion-dollar semiconductor supply chain is one of the world’s most complex. The production of a single chip often requires more than 1,000 steps and passing through international borders 70 or more times before reaching an end customer.” - A big little problem: How to solve the semiconductor shortage, IBM

The semiconductor shortages aren’t going away any time soon and product teams are finding their own way through. Some make do with the existing inventory they have, hoping the silicon supply chain catches up eventually. Others have announced delays publicly, and are waiting to restart development again. A few have already had job cuts.

While every situation is unique, it’s important to consider alternatives to utilizing the resources you already have, from budgets and tools to highly-skilled people.

Here are four ideas to keep the embedded GUI development pipeline going.

#1 Update your GUI architecture

Unlike web and mobile applications, software for embedded systems tends to be tightly-coupled and connected — making the code highly dependent on the hardware. Modern techniques, like model-view controller (MVC), have gained traction but if your GUI-to-backend system was designed as a tight ball of code to achieve high performance, you can make use of the silicon downtime to consider a new architecture.

Decoupling the user-facing behavior and logic from the backend allows you to develop the GUI without having the hardware in place. There are many ways to do this, like MVC, model-view-presenter (MVP), model-view-viewmodel (MVVM), and others, but they’re all designed to keep the system model intact while the GUI does its thing in terms of presentation and updating data used by the backend. Meeting performance goals with these architectures is less of a constraint these days as many hardware vendors push the boundaries of what microcontrollers (MCU) can do.

As a result, the development of the GUI itself can move forward without having the hardware in place, as long as there’s a well-defined interface between the two.

Beyond continuity of development, a decoupled architecture helps:

• Progress UX design and validation without requiring hardware
• Focus UX designers on their needs rather than worry about software logic
• Optimize different areas of the application without impacting the whole team
• Test the decoupled elements independently from each other, using testbeds to simulate inputs and outputs

#2 Enable progress by evolving designer-developer processes

As much as decoupling GUI architecture supports development without hardware, eliminating the barriers between designers and developers helps too. Specifically, a true parallel process between these roles gets designs and code to maturity faster so that the eventual hardware integration and testing is performed with a far more stable version of the application.

We have a whole blog dedicated to explaining and implementing parallel workflows here but the main goal is to support designers and developers working on the UX, code, and user validation together without overwriting each other’s work or losing critical information (like UX design choices or target memory limits) between them.

#3 Adopt tools to facilitate development during the chip shortage

Getting down to embedded GUI development tools, the silicon shortage offers the breathing room to investigate and try out different options. We offer some evaluation criteria here but for the current semiconductor crisis, the biggest factor lies in how far you can take GUI development without hardware.

GUI frameworks that offer simulation and testing on the host computer obviously take you further down the development lifecycle than simple code libraries and tools. The biggest limitation with host-based test tools is that they often don’t align with the performance characteristics of the target platform. Either by mismatched CPU emulation, instrumentation overhead, missing peripherals, or other gaps.

However, test tools that allow you to validate the operational behavior of the GUI saves valuable UX and application development time, and doesn’t require the hardware to be there. This video demonstrates how AMETEK Crank's Storyboard lets you do it:

Testing using the Storyboard simulator

#4 Consider alternative hardware vendors (that your GUI supports!)

The final strategy we recommend is to shift your GUI hardware. Given that it may take years for the silicon supply to return, switching vendors may be the only option.

This becomes easier with a decoupled GUI architecture (to minimize front-end changes), parallel designer-developer processes (to streamline any impacts), and a GUI development framework that adapts easily to new hardware targets. Storyboard in particular is purpose-built to work with any hardware platform, and has built-in tools to support scaling up or down, with optimized runtimes for many different vendors.

There’s little to no friction when changing hardware due to the silicon shortage, even to smaller or lower-end MCUs.

Once you’ve considered these alternatives to your current GUI development processes, feel free to start looking into your hardware options. This best practices whitepaper offers an agnostic view into choosing the best platform for your GUI project: