Episode 39: Better Built By Burkhard

Embedded World 2023 Round-Up

Embedded World 2023 Round-Up

After a 3-year COVID break, I visited the Embedded World exhibition in Nuremberg again. I had a couple of instructive conversations - all unplanned, by the way. For the first time, I would have needed a second day for this exhibition.

Toradex: Towards Solutions on Modules (SoMs)

At the Toradex booth, I bumped into Sergio Prado, who is the key developer behind TorizonCore. He turned OTA updates into a solution, which uses the Toradex Easy Installer TEZI for bootloader updates and OSTree for root filesystem updates.

Using two different update mechanisms is not visible to customers. They get a ready-made high-quality OTA update solution. They don’t have to implement this solution themselves. Toradex saves its customers a lot of time and money.

Sergio currently helps Toradex develop a ready-made solution for secure boot. That’s why he has lately written quite a lot about encryption (e.g., Asymmetric-Key Encryption and Digital Signatures in Practice and A hands-on approach to symmetric-key encryption) and about embedded Linux security (part 1, part 2).

Building a mostly automated solution for secure boot is a lot harder than for OTA updates. Using software, a trusted person must install private keys in secure write-once memory of the SoC and blow some fuses to prevent fraudulent installations. I am curious to try out this solution, which again saves customers a lot of time and money.

Compare Toradex’s approach with Variscite’s. Here is part of a conversation with an engineering manager from Variscite from November 2022.

Me: “You could provide recipes or scripts to automate the implementation of standard features [(e.g., OTA updates, secure boot, inter-processor communication)]. This would save your support engineers and your customers a lot of time and money.”

Aaron: “Our business is hardware, not software. Automation is difficult because the requirements are varying too much. And, we don’t need it, because our Wiki’s are very good.”

See Episode 30 of my newsletter for the full conversation

Toradex understand that their business is much more than hardware and that their main differentiator is software. Whether you buy an iMX8-based SoM from Toradex, Variscite, Seco, Kontron, Avnet or anyone else doesn’t matter. You lose time on building customised Linux systems and adding standard features like OTA updates, remote support over VNC, secure boot and inter-processor communication.

Toradex save you this time by providing ready-made solutions so that you can focus on your core business. They give SoM a new meaning. SoM doesn’t stand for system on module but for solution on module.

Kontron: AMD Ryzen as Super ECU

I didn’t come to Embedded World 2023 to check out the dozens of i.MX8 variants. That’s getting a bit boring. I was looking for a SoC that can power a super ECU. A super ECU combines the 25 or more ECUs of agricultural and construction machines into a single ECU and can drive multiple high-resolution displays.

[The] manufacturers [of these machines] could integrate many of the ECUs into a single super ECU powered by an NVIDIA Jetson, an NXP i.MX8 or an AMD Ryzen. […]

[They] turn the integration of multiple ECUs over a network into the integration of multiple processes on a single super ECU. [They turn] a hardware problem into a software problem.

See Episode 3 of my newsletter

So, the wall with AMD Ryzen boards at the Kontron booth was just what I was looking for.

When you look at the specification of the D3723-R mITX, you wouldn’t regard it as a super-ECU candidate. Thanks to its powerful Radeon Vega GPU (as part of the SoC!), it can easily drive multiple high-resolution displays (4x display port, dual channel LVDS and eDP 4K on board). But where are the CAN ports? Where are the vibration-resistant, dust- and water-proof connectors? How can you integrate a 4G or 5G modem? Can I build a custom Linux with Yocto?

Alexander Jäger, a system solution architect doing sales, was just the right person to answer my questions. You can plug M.2 cards with CAN connectors and with 4G or 5G modems into the three M.2 slots. Kontron can replace the standard USB, Ethernet, serial and DP connectors with sturdy M12 connectors. They have done that for trains.

The board supports Windows 10/11 IoT and Ubuntu. Or, you can build your own Linux with Yocto. Kontron can also put the board into a case with a touch display. In other words, they can assemble a terminal for you.

Alexander told me that a railway company uses a super ECU powered by an AMD Ryzen in their trains. The super ECU replaces a cabinet full of ECUs and PLCs. The railway company replaced the cabinet by additional seats, for which it earns good money.

Slint: A Qt Competitor?

The Slint UI needs about 200 KB RAM of the 264 KB available on the Raspberry Pi Pico. Yes, you read that correctly: It’s kilo bytes, not mega bytes and not giga bytes. That’s amazing! Needless to say that Slint UI runs smoothly on SoCs with more oomph like the complete i.MX family of SoCs.

Compare that with Qt for MCU: The minimum requirement is 6-8 MB RAM and a high-end Cortex-M4 or even a Cortex-M7 microcontroller. As these SoCs are more expensive than many low-end SoCs with Cortex-A microprocessors, I don’t see Qt as an option for microcontrollers. In contrast, Slint UI definitely is an option.

Qt for MCU is on par with Slint with respect to memory consumption. The runtime of Qt for MCU consumes 200-250 KB of RAM. Consequently, Qt for MCU can run on the same lower-end and less expensive microcontrollers as Slint.

Slint UI has another important point going for them: licensing. Aurindam Jana, co-founder and responsible for sales and marketing, explained to me the three commercial licensing options for embedded:

• Ambassador: You get unlimited user seats and unlimited distribution for free in return for saying publicly that you are using Slint.

• For one product: For €5,900 per year, you get unlimited seats. No matter how many developers work on a single product, you pay €5,900 per year.

• For multiple products: If you work on multiple products, you pay per user. The first developer costs €5,900 per year and all the other ones €720 per year.

Additionally, you must pay royalties per device for the one-product and multiple-product solution. The maximum per-device fee is €3.50 and decreases with higher volumes. These prices are very moderate and fair. I am sure that many of my customers would happily pay these prices.

I asked Aurindam how they can pay the salaries for five employees by now. He answered that Slint is backed by an investor. Their main goal is to build an enthusiastic community of developers and companies that will eventually guarantee the commercial success of Slint. I really hope that Slint succeeds. The embedded space could use some competition for UI frameworks.

You should watch the demo Slint on Embedded Devices: An Introduction by Simon Hausmann. Simon shows the live preview: pretty cool. He is another founder of Slint. Simon was the mastermind behind the QML engine and QML on microcontrollers. With Slint, he and his colleagues can scale up a UI framework from small devices. This is a lot easier than scaling down a huge framework like Qt.

KDAB: Comparing Qt, Slint and Flutter

Over the last year, I had many companies complain to me bitterly about the aggressiveness of Qt Sales. The Qt sales people use fear, uncertainty and doubt (FUD) about Qt LGPL-3.0 to coerce companies into buying Qt for Device Creation licenses. These companies do not only ask me how to use Qt under LGPL-3.0 but also for alternatives to Qt.

So, KDAB’s comparison of Qt, Slint and Flutter caught my attention. KDAB implemented the same application - ship navigation and status summary - once with Slint, once with Qt and once with Flutter. The video is not one of KDAB’s best, but the discussion with Till Adam, CCO of KDAB, about the pros and cons of the three frameworks fully compensated for that. Here are the main points.

When it comes to memory consumption, Slint wins hands-down. The QML engine comes in second and Flutter last by far. The size of the Flutter engine is closer to that of the Qt web engine than to that of the QML engine.

When it comes to memory consumption, the Slint runtime and the newly developed runtime for Qt for MCU are on par. They come in at 200-250 KB. The size of the Flutter engine is closer to that of the Qt web engine than to that of the classic QML engine. You can expect that Google, the company behind Flutter, will reduce the size of the Flutter engine significantly over time. But this will require a lot of hard work. Slint and QML have a huge head start and are much better suited for embedded devices than Flutter.

Qt is much more than a feature-rich and easy-to-use UI framework. It offers networking, serial communication (CAN, ModBus, RS232/485), Bluetooth, NFC, IoT protocols (MQTT, CoAP), OPC UA, window managers, inter-process communication, and more. All these features work cross-platform. Qt is a platform, which you can grow into a product- or industry-specific platform.

Building platforms on top of Qt is Qt’s unique selling point. It will take Flutter and Slint a long time to catch up. Backed by Google, Flutter may well become a complete platform. This raises a couple of questions for me. Will it become a viable platform for embedded in addition to mobile and desktop? Why is Google investing into a second platform for embedded, mobile and desktop - in addition to Android? How does the positioning of Android and Flutter differ?

Slint should not try to cover all these non-UI features. Instead, it should leverage existing libraries like the C++ standard library, the Poco libraries, the Boost libraries and many other third-party libraries. As the overlap with Qt libraries is growing rapidly and Qt’s advantage is shrinking, this approach could also be good for Qt.

Providing clean and consistent interfaces (another hallmark of Qt!) to functionality common to embedded devices and industries may be the way to go. Qt OPC UA is a good example, where Qt provides just an interface for an existing OPC UA stack. Qt MQTT or Qt CoAP are bad examples, because Qt reimplemented the complete MQTT and CoAP protocols. Qt spreads its resources thin by doing this.

Till made the astute observation that Qt is overdoing cross-platform a bit. He gave QPA plugins as an example. QPA plugins abstract away the OS specifics of rendering. This plugins are shared libraries so that applications could replace one plugin by another at runtime. But wait! This will never happen, because it is clear at compile time which plugin the applications need. Flutter avoids this needless complexity and generality, and links to the correct rendering stack at compile time.

When you think about it, many of the Qt plugins are unnecessary. There is no need to change the CAN plugin or the Multimedia plugin at runtime. It’s clear at compile time which plugin to use.

When it comes to licensing, Flutter is the clear winner, with Slint a close second (see above) and with Qt a distant third. Flutter is licensed under the permissive BSD-3-clause license. You only have to include the license text in your documentation or in a license menu. So, Flutter is free as in free beer.

My Content

Accessing Private Git Repositories from Docker Containers

Running Yocto builds of embedded Linux images in Docker containers works smoothly, as long as the layers are in public repositories and the recipes only refer to public repositories. Things get tricky when the build must access private repositories from the container. It took me several attempts and a lot of searching on the Internet to find a working solution. My post will save you the time.