Qt Arrives For Small Computers

There was a time when writing embedded systems meant never having to deal with graphical user interfaces, and spending long hours trying to free up a dozen bytes of ROM to add a feature. Nowadays, an embedded system is likely to have a screen and what would have been a huge amount of memory even for a PC a scant decade ago. Qt has long been a popular choice for building software on desktop platforms, and — while not as popular — has even run on phones for a while. Now there’s Qt for MCUs which is clearly targeting the IoT market that everyone is trying to capture. You can see the glitzy video for the new product, below.

We generally like Qt, and the move recently has been towards an HTML-like markup language called QML instead of directly manipulating widgets. We guess that’s a good thing. However, Qt isn’t just for user interfaces. It provides a wide range of services in a straightforward way

The biggest draw though is that the system is portable. You mostly see Qt programs on Linux, but they work in a lot of other places including Windows and many cell phones. This will continue the drive to push Qt to as many places as possible. You can argue that Java does this, but a truly resource-friendly and hassle-free Java has been elusive. Even on big computers, the joke is often that Java is “write once, debug everywhere” — a play on the “write once, run everywhere” slogan.

We looked at QtCreator — a nice tool for working with Qt, back in 2016. You’ll see in that article, they offered an embedded Qt that was made to draw right to the framebuffer on a Linux platform. It will be interesting to see how the new product improves on that. Of course, the Raspberry Pi and its ilk can just run regular Qt, too. QtCreator can do more than Qt, with some help from some friends.


26 thoughts on “Qt Arrives For Small Computers

    1. I have to agree. For all the press coverage this is getting no one has mentioned if this will be open or commercial.

      I love the qt framework on PC’s and would like to be able to use parts of it embedded, but if it’s closed then it’s completely useless to me. I have no company behind me, only curiosity and personal projects – ie. Hobbyist

      1. Not perfect by any measure, but I find the code life-cycle will last a lot longer

        Qt4 was initially a good concept at first, that grew into something rather maintenance heavy in Qt5.
        Given the history, I would also vote “No” on Qt for commercial code, and a “meh” for FOSS projects.

        It is unfortunate whenever the “Second-system effect” hits a project like Qt4 to 5, OpenCV3 to 4, Python2.7 to 3.x, and systemd…

        Sometimes we need to remind ourselves that Sisyphus and his rock are not the intended use case…

        1. Plus, the license for Qt5 changed from QT4 and you can easily find yoursef in situations where you can’t port your app to a new mcu because the framebuffer drivers don’t have support for QT4 but 5, so, your free of charge code magically become expensive, unless you want to let the final users to load their own compiled version of the QT library on your device, which I’m always happy about it but sometimes we are not working for ourselves.

  1. I just can’t see how this is going to be portable across a broad range of MCUs. Even assuming, say, a common denominator of a C compiler and some kind of byte code VM, it’s still a huge challenge.

    1. To get the Qt eye-candy you will probably need a frame buffer device. At that point all Qt is doing is writing to the memory (unless there’s support for hardware acceleration). Event routing and rendering can be easily detached from the hardware as shown by other commercial solutions such as GUIX or emWin.

  2. Their definition of embedded is very different from mine. They mention cortex-m but the demo i saw requires >1MB RAM. Only a few Cortex-m provessors if any can accommodate that without external RAM.

    1. I looked at the MCUs mentioned in detail. It only technically runs on MCUs because there are chips with far more ram than 99.9% of anything else on the market. Even most Cortex M7 devices can’t handle the memory requirements.

      1. It’s a start. Better to have it run on a small handful of MCUs (and maybe they’ll biuld on that later?) than on none at all, and having to include a full blown SBC because all you have available is desktop devs.

  3. “the move recently has been towards an HTML-like markup language called QML instead of directly manipulating widgets. We guess that’s a good thing”

    It sounds like a good thing. I develop for other platforms (web and Android) but new UI paradigms like two-way data binding have made things a lot nicer.

  4. QT5 sucks. Try to run cutecom, kst , ZeGrafer, Grace or labplot using FreeBSD, rpi3 and xfree86_video_scfb driver. You have to recompile them using qt4 support and they will work, allthough some of the menus texts will not be visible. Installing them as pre-compiled binaries will not work, they will give you errors such as communication failure within xcb module.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.