For a few months now, we have been working on a new project under the codename Boot to Qt, and today we launch it as a technology preview.
Boot to Qt is a commercial offering that provides a fully integrated solution for the creation of slick user interfaces on embedded devices. The offering includes:
- A light-weight UI stack for embedded linux, based on the Qt Framework - Boot to Qt is built on an Android kernel/baselayer and offers an elegant means of developing beautiful and performant embedded devices.
- Ready-made images – We have images for several different devices which include the Boot to Qt software stack, making it possible to get up and running with minimal effort from day one.
- Full Qt Creator Integration – One-click deploy and run on hardware and a fully featured development environment.
- Simulator – A VirtualBox based simulator which allows device development without hardware and opens up for simulating hardware input, such as GPS and connectivity.
This technology preview focuses on the stack built on an Android baselayer. We also want to provide a similar software stack and the same convenience with ready-made images and IDE integration also for traditional embedded Linux, hopefully with a preview coming some time this summer.
We are expecting to have an official release towards the end of this year.
The following video shows Boot to Qt in action on our reference hardware:
And the following video show the Boot to Qt SDK works:
Scope of Boot to Qt
The software stack includes most of the Qt Framework:
- Qt Core, Qt Gui, Qt Network, Qt Widgets, Qt Xml
- Qt QML and Qt Quick
- Qt Quick Controls
- Qt Graphical Effects
- Boot to Qt specific additions, including virtual keyboard, brightness control and power off/reboot functionality
The hardware devices supported in the Technology Preview are:
- Google Nexus 7 - 1.2 GHz Quad-Core ARM Cortex A9, Tegra 3 GPU, 1GB RAM
- Beagle Board xM - 1GHz ARM Cortex A8, PowerVR SGX530 GPU, 512MB RAM
- Boundary Devices SabreLite (Freescale i.MX 6) – 1 GHz Quad-Core ARM Cortex A9, Vivante GC2000 GPU, 1GB RAM
This is not a fixed set, but a place for us to start. If you have suggestions for other devices, let us know. The stack can also run on x86 hardware.
Right now, the stack is single-process. The launcher is a QML application which launches other QML applications in-process. We have looked briefly into using Android Gralloc APIs to do multiprocess sharing of hardware buffers, and we know it can be done, but we consider this out of the 1.0 scope.
We have also had similar discussions around Multimedia and Webkit, we want to have them in place, but maybe not in the initial release. The current software stack is already quite powerful and serves a number of different use cases.
Qt 5 introduced a new OpenGL ES 2.0 based scene graph to power Qt Quick 2. This makes Qt Quick very suitable for running on embedded hardware, even those with moderate specs. The demo launcher we ship with the images for instance, runs velvet at 60 FPS on all our hardware devices.
We were looking at CPU usage while playing around in the application launcher on the Nexus 7. When idle, it uses a shader to add a glow on the currently selected item and has a small particle system on the Qt logo in the corner. We found that when the launcher was just animating the glow on the active item and running the small particle system on the Qt logo, the CPU load was running at about 50%. When we flicked it, it dropped to 30% and when the finger was down and we were moving the list via touch, it dropped to below 20%. So it seemed that the more we did, the less the CPU load became. What we were observing was CPU frequency scaling. The CPU is a Quad-core clocked at 1.2GHz (with a special 1.3Ghz single-core operating mode), but when idle, it had disabled 3 cores and had scaled the one remaining core to 102Mhz. So we were able to animate a large part of a 1280×800 screen at 60FPS on a CPU clocked at 102Mhz, and were still only using half of that.
For reference, the same animation runs at 2% CPU on the i.MX6 and 15% on the Beagle, none of which does do frequency scaling.
We also have pretty decent startup times. Below is a diagram comparing Boot to Qt to native Android. Now of course, full Android brings in a lot of additional stuff, but that is also the point. Most embedded devices do not need that.
Startup times, in seconds, from power-on until device reaches the B2Qt launcher or the Android Homescreen.
Lower is better
This is not too shabby, but we believe we can cut this down a bit more, at least when we start exploring various embedded Linux configurations. As an example, Qt 5 on Raspberry Pi can start rendering after as little as 3 seconds.
For more information, see the product page.
Boot to Qt is available for evaluation upon request. If you want to try it out or if you are just interested in the software, please use the contact form on the product page and we will be happy to get you started. Of course, feel free to leave comments and questions on this blog too.