A lot of embedded devices have old-fashioned GUIs or don’t have a GUI at all. It doesn't mean that every product needs a Full HD display with fluid, modern and absurdly animated graphical user interface. Some devices do not need a GUI at all. However, the habits and expectations of the users have evolved over a time and your competitors are surely planning GUIs for embedded systems that they develop.
In this article I will explore the field of GUI development for embedded systems. We will get into practical problems and how to solve them. We will explain the common issues such as:
- the choice of a GUI software framework - Qt, LVGL or maybe something else?
- poor UX/UI design
- choice of the hardware target
- access to expertise and cost - our tips for fast and efficient GUI programming.
What makes me qualified to write about this topic? I am the founder of Somco Software - an embedded systems development company with a strong focus on GUI, Linux (buildroot, Yocto, Torizon) and connectivity. Each year we start up to 20 new projects for customers that seek experts in design, implementation and deployment of GUI for their embedded systems projects. I used to code myself and had a chance to work on a wide range of GUI projects ranging from car navigation for leading US manufacturer, to medical devices treating serious conditions.
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.
