How to develop GUI for embedded systems and not go crazy?

Modern GUI for your embedded systems is no longer a luxury

Why is that? Let’s explain it using the example of automotive manufacturers. Despite some exceptions, most of the new cars go with a cockpit display. Not necessarily one, but even more. And they get even bigger. Although the majority of embedded systems do not need that level of craziness, a GUI that is good-looking, aesthetic and matching needs of customers, takes your product to the next level.

After working in this field for several years I have come to a few sad conclusions and one of them is that people judge books by the cover. It's not a surprise and there is no reason to take offense at reality. The product that is visually attractive makes a better impression and makes you feel that it will better meet your needs. That's why for many customers of Somco Software, their marketing departments are the ones driving the change to introduce or improve GUI for embedded systems they develop.

Of course, it's your job to make sure that look is not a facade and your device is an excellent product, but it is a subject for another article.

There is another, practical angle to this topic. Cost and maintenance. It is cheaper (I know, safety aside) in the long term to have one big screen in the middle instead of dozens of physical switches, knobs and buttons. Why have several physical controls for AC (on/off, temperature, airflow direction, fan speed, etc) if you can have all of that in your software. Physical controls have to be designed as well, produced and possibly replaced if they're damaged.

Moreover, with moving to software you let the gate for updates open. Let's say there is a feature in the car or your embedded system that can be realized with all hardware that is inside your device, but you have to release the product as it is and you didn't have time to implement that feature. With software, you can simply release an update some time after the release. But installing an additional physical control for that new feature in the devices that are already shipped to the customers would be at least cumbersome.

Choosing a GUI software framework

Qt, LVGL, TouchGFX, Flutter, Slint, Candera, Web frameworks, Kotlin, MAUI, Unity, Unreal... This list could probably be way longer, but we have seen all of these frameworks used for embedded systems GUI across various projects. Is there a solution that is significantly better for all cases? Of course not. Each technology has its own pros and cons as well as use cases that it serves best. Nevertheless, such a decision is important as it directly influences a lot of things like the choice of hardware, but it also indirectly influences your business (cost of development, licenses, delivery time).

There are plenty of factors to be considered. Some of them are:

Performance requirements (FPS, boot time, GPU usage)
Target hardware support
Memory footprint
Display features (touch, multi-touch, resolution, color depth)
Graphic capabilities (2D/3D, anti-aliasing, video)
Development speed and time to market
Integration ease
Licensing and cost
Compliance (we know this topic really well as Somco Software is ISO 13485 and ISO 9001 certified embedded software company and we work a lot with medical customers and other regulated industries)
Community and ecosystem maturity

Again this list could be way longer. The dilemma is even more complicated by the fact that "embedded systems" is a wide term. In-Vehicle display, huge medical device to operate spine and smartwatch are all embedded systems. The best definition I’ve heard is that it means "closed system".

So, the rule of thumb is: You will not make a good decision unless you understand your goals and what you need to build. First you have to gather the stakeholders (management, marketing, engineering) and figure out the requirements, then the budget and then you can make decisions. I can guarantee you that If you start the other way around and choose first a particular framework, because you like Python or for any other reason, then you can only bet and pray that you're lucky and there will be no problems afterwards.

One of the prominent projects we recently developed was embedded software we developed for Cutera Inc. - aesthetic laser device manufacturer from the United States. Somco Software develops various aspects of Cutera's software including Yocto Linux image, connectivity between microcontrollers, security updates and of course embedded GUI. So using this example: What were the goals of this customer?

They are in the beauty sector. I once visited an aesthetic medical clinic (for a product workshop, not to improve the way I look) that had Cutera's devices. And I can tell you that everything there looked like it was absurdly expensive, people were rich and happy and the world was a better place. So, Cutera made a strategic decision that the GUI of their embedded medical devices has to match these standards. It needs animations, 3D and fluid transitions.

And exactly this dictated the reasons why Cutera reached out to Qt development experts such as humble Somco. This framework is the most commonly used technology in our company and the core of our stack.

Advertising graphic for downloading the white paper Embedded GUI Frameworks Comparison, which is shown on a tablet (right), while on the left a woman is shown in a laboratory environment controlling a model of a robot arm on a PC.

Ultimate GUI frameworks comparison

Although the embedded world team is really nice, they put a limit of length of this guest article so we have no space here to describe pros and cons of each technology. We presented you the decision factors and a verbose example, so for now all that we can say is that you should get our free whitepaper - Embedded GUI frameworks comparison that gets deeper in this topic and also presents detailed performance (FPS, GPU, CPU, memory) benchmarks of Qt, LVGL, HTML, Slint and Flutter. We've also done the similar comparison Qt and Android (Kotlin, Jetpack Compose) stacks.

Poor UX and UI design

Somco has comprehensive services to deliver complete GUI for embedded systems, so we hire in-house designers and we cooperate together to deliver new GUIs of highest quality. What is the recipe to astonish your users? UX is not only about software, but also the device enclosure (we present some at our booth), so this tip is universal.

That might sound absurdly simple, but you have to ask your users. You have to understand how they really use the product (GUI or device as the whole) and who uses it. If you develop a GUI for an excavator or machine that operates in a factory, it usually means two things: big male hands and thick gloves. Therefore, your buttons have to be huge.

If you develop a medical device for surgeries, then you face two layers of nitrile gloves, protective foil on the touch display and specific lighting. And that's designers' task to ask right questions, organize workshops and figure this out.

Visualization of an embedded GUI UX/UI design process with interface elements and a robotic arm simulation.

Choice of the hardware target

Choice of the hardware target is again a very broad subject that is interconnected with the choice of the software framework and vice-versa. Again the tip is that you need to understand what you want to build and what your business goals are. Somco Software used to have customers who had to introduce tiny micro-controller from STMicroelectronics or ESP32 and still have a modern GUI, yet we also have customers that decide on powerful mini PC and they do not care about the costs.

So you have to evaluate different options, but the problem appears when you do not have enough expertise, because for example the new project differs from the ones you developed in the past. In such a situation I recommend you to get a piece of consultation from Somco on this topic as we are the partners and integrators of companies such as Toradex, SoMLabs, Riverdi, ST, NXP and we can evaluate these decisions for you and recommend the best options.

Lack of expertise and cost

My customers usually face a few specific challenges.

First, you need to develop embedded GUI in Qt or in similar framework, but you simply do not have all the skills required inside your team. Either the competencies are missing, or your best engineers are already fully loaded with other work. Or the skills you need are required only for a few weeks or a few months, which makes hiring even harder to justify.

Second, recruitment is slow and difficult. Even if you manage to find a candidate, it is very hard to verify their real experience when you do not have those skills. This creates a lot of risk for deadlines, quality and the success of the project.

Start small and de-risk early. Build a rough prototype on your real hardware to validate performance and memory limits before full development. Reuse reference designs, demo projects and UI components from your framework vendor. Document decisions and bottlenecks. Short external reviews or audits are often cheaper than fixing wrong architecture months later.

In short, successful embedded GUI development is about making informed technical decisions early and validating them fast. A bit of structure, prototyping and realism about your limits will save far more time and money than any late-stage optimization.

Visit Somco Software in hall 5, booth 5-386