Embedded

← Older posts

Introducing Boot to Qt – A Technology Preview

Published May 21, 2013 | By Gunnar Sletta

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:

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.

Performance

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.

Getting Access

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.

Enjoy!

Posted in Embedded, Qt | 72 Comments

Qt in World’s Fastest Electric Car

Published May 17, 2013 | By Tuukka Turunen

Digia has supported Metropolia University of Applied Sciences in their electric car project called Electric Raceabout (E-RA). This cool research project has produced a street legal electric sports car, which not only has the World record on ice, but also runs Qt.

Metropolia University, located in Helsinki, Finland, does extensive research on electric vehicles, one example being E-RA – an electric sports car built primarily by automotive engineering students.

With 4-wheel drive and well designed handling E-RA is a really capable sports car with impressive specs:

  • Top speed of over 260 km/h
  • Motor power of 282 kW
  • Peak torque of 800 Nm – in each wheel

And all this provided by an electric vehicle that is fully street legal (and rest assured, the Finnish road inspection is surely one of the toughest in the world to pass).

E-RA has achieved lap time of 8 minutes 42,72 seconds at Nürburgring Nordschleife, which was electric vehicle track record for quite a while, as well as World record as the fastest electric vehicle on ice with average speed of 252,09 km/h. Nicely driven E-RA has operating range of over 200 kilometers.

The students have built both the IVI system and the instrument cluster with Qt 4.8 running on top of Linux. I think the whole E-RA project is a really great proof of the skills the soon-to-graduate engineers have, and certainly the Qt parts are no less impressive.

Have a look on the enclosed video produced by the students at Metropolia University to hear the full story:

Posted in Embedded, Qt in Education, Qt in use | 8 Comments

Qt Showing off its Portability Power at Embedded World 2013

Published February 27, 2013 | By Katherine

It’s the second day of Embedded World 2013 and as the world of embedded system developers crowd the Nuremberg messe, the Qt team has dry mouth from talking to the hundred of visitors to our booth thus far and showing off the 10+ demos at the Qt stand, #4/520.

It can be said that the embedded industry is still slightly new to the idea of having GUIs on systems like a microcontroller, but this year more and more of the traditional hard-knobs-and-dials sort of developers are coming to Qt because they realize that the world is moving to graphical UIs and especially touch capabilities. They need not only a UI tool, but a full framework that can give them the ability to have a flexible and performing UX on high-end chipset where power and performance are not lost when ported to low-end chipsets and architectures. “I can do that with Qt?” Yes you can.

This year we are showing at our booth Qt running on various embedded operating systems like embedded Linux, QNX, VxWorks, previews of Android and iOS. We also have our “Live Coding Theater” where we are demoing how easy it is to develop with Qt Creator and deploy to an embedded Linux target. This has been very popular being held 3 times a day.

What is really blowing minds is the consistent performance of the same Qt 5.0 application running on QNX, Android and iOS.

 

 

What are your thoughts on UI development in the embedded space?

 

NOTE: Wifi is a bit dodgy at the event – too many people on. Apologies for the pics being slightly heavy and large. We will fix them and update the post throughout the day.

Posted in Embedded, Events

Getting more out of Qt on Windows Embedded Compact 7 & ARM processors

Published January 29, 2013 | By Janne Anttila

At the moment most of the buzz is probably around Qt5, but it is good to remember that Qt4 is still alive. While we are working to increase platform coverage on Qt5, there are still some platforms that are officially supported by Digia only with the Qt4 codebase. One of those platforms is Windows Embedded Compact 7. In this blog post I wanted to share with you a small tip that can bring you big performance benefits on Windows Embedded Compact 7.

Windows Embedded Compact 7 is tied to Visual Studio 2008, and if you are targeting an ARM based device you might have realized that the Visual Studio 2008 toolchain only supports ARMV4 and ARVM4i instruction sets for ARM architecture. Due to this limitation, Qt mkspecs for Windows Embedded Compact 7 defaults to ARMV4i instruction set. However, there also exists a version of the Visual Studio 2008 compiler which can generate code for more recent ARM instruction sets and CPU cores. This compiler is included in the Platform Builder (the tool used to generate Windows Embedded Compact 7 OS images and SDKs). If you have Platform Builder installed, you can build Qt for ARMv7 instruction set and also benefit from the more advanced floating point units of the latest CPU cores. To build Qt 4.8.x with ARMV7 instruction set and to use the latest floating point instructions supported by ARM you can do the following:

In the mkspec you are using for WEC7 ARM build, change the value of CE_ARCH variable from armv4i to armv7, and add the following code block there:

QMAKE_CFLAGS    += -QRarch7 -arch:VFPv3-D32 -QRfpe-
QMAKE_CXXFLAGS   = $$QMAKE_CFLAGS

Then make sure that you have the cl.exe from platform builder (c:\WINCE700\SDK\BIN\i386\ARM) in your path before visual studio 2008, and just reconfigure and build Qt and your Qt application. That’s it – now just enjoy the better performance!

For more detailed information about the different Visual Studio 2008 compiler versions, and the options used for QMAKE_CFLAGS, please check the paper written by Adeneo Embedded. With the upcoming Windows Embedded 2013, Microsoft has also updated the Windows Embedded Compact toolchain to Visual Studio 2012.

Posted in Build system, Compilers, Embedded, Performance, Qt

Necessitas Android Port Contributed to the Qt Project

Published November 8, 2012 | By Tuukka Turunen

Together with BogDan Vatra, the main author of the Qt for Android port called Necessitas, we have agreed that he will contribute his work into the Qt Project. This is great news and I am truly excited on the things we can do together in the Qt Project. The Qt 5 Android port will be based on the work done in the Necessitas project and BogDan will also continue his work in this area within the Qt Project. This co-operation will enable us to reach Tier 1 status of Qt for Android faster.

Qt for Android is developed actively under the KDE-hosted Necessitas project. There are already many developers who have deployed their apps with it, and an impressive number of users of the Qt-based apps on Android devices – currently over 800.000 active users and 2,7 million downloads. The work done with Qt 4.8 in the Necessitas project provides an excellent baseline to create Qt 5 support together within the Qt Project. Digia is planning to invest into the further development of Qt on Android and aims to introduce Android as fully supported platform of Qt, i.e. as a Tier 1 platform during 2013.

The efforts of getting Qt to run on Android began in late 2010 by BogDan as a hobby project using the newly available QPA of Qt 4.8.  The first Alpha release was made available in February 2011 and the port has been steadily growing with supported features, maturity and amount of users. With Qt 5 Android development moving to the Qt Project, the Necessitas project will still continue the work around Qt 4.8. It is expected that the port on Qt 4.8, currently in beta maturity, will be completed in the coming months with most of the work being able to be leveraged on top of Qt 5 in the Qt Project.

It is truly an impressive achievement to create the Android platform support of Qt as well as the Necessitas SDK extending Qt Creator for Android development, and the Ministro installer that allows applications to fetch the needed Qt libraries.  BogDan has created most of these, but there have been also many others, for example Ray Donnelly, helping him with the port as well as many others providing feedback.

KDE has been a significant help to the work by providing the needed infrastructure to distribute the SDK as well as the Qt libraries for Android devices. We are grateful for this contribution and hope to be able to continue our co-operation with KDE.

BogDan has expressed interest in being the Qt Project maintainer of the Android port, and I think that would be really great! In addition to BogDan, we want to continue the co-operation with the other members of the community, as we do believe that it is the best way to reach excellent results faster. We are also fully committed in keeping the Android port open and available to all Qt licensees, on both commercial and open-source licenses. The Android port is expected to be available as a development project on top of Qt 5 later this year, and reach full maturity with Qt 5.x releases during next year.

At Qt Developer Days next week in Berlin, we will have a couple of demos running Qt applications on the Android Necessitas port. Hope to see you there. Make sure to sign up! www.qtdeveloperdays.com.

 

Posted in Embedded, Qt | Tagged , ,

Cross compiling Qt for the masses

Published April 13, 2012 | By dcarr

Cross compiling Qt for particular devices/BSPs can be frustrating when operating from first principles and we are trying to improve the existing configure/qmake build infrastructure in Qt 5, as well as the associated documentation, in order to ease this burden. We are approaching the problem from 2 angles:

  • General cross compilation support
  • Direct target support

The general cross compilation support is being improved by:

  • Reworking the pkg-config logic
  • Introducing the -device flag to configure
  • Introducing the -sysroot flag to configure

The supported targets are documented here:

http://wiki.qt-project.org/Devices

and as you can see in the Raspberry Pi documentation, we have reduced compilation for this target down to:

./configure -prefix <your prefix> -release
  -device linux-rasp-pi-g++ -make libs
  -device-option CROSS_COMPILE=<your toolchain path>/bin/arm-none-linux-gnueabi-
  -sysroot <your sysroot path>

The resulting build has full (single process) OpenGL ES 2 support and keyboard support for the Raspberry Pi.

There is no need to patch any files as all the relevant changes have been upstreamed into Qt 5 where they can be adequately reviewed and QAed like any other Qt contribution. Needless to say this drastically increases the quality of the code finding its way on to these devices and should drastically improve the user experience when dealing with this kind of hardware for prototyping/productization/recreation. Sunlight is the best disinfectant, and we delight in consuming this dog food.

We heartily invite any (all!) chipset vendors/chipset customers/BSP vendors or interested parties to upstream relevant mkspecs and the associated code changes to Qt, in order to extend the breadth of Qt 5′s out-of-the-box device support. The move to Open Governance has made extending this support increasingly achievable, feasible and convenient and we are very excited about both Qt 5 as a whole and the current rate of development towards embedded (read constrained) Linux platforms.

Posted in Contributors, Embedded, Open Governance, Qt

Raspberry PI: A case study in deploying Qt apps to generic Linux devices

Published January 19, 2012 | By dcarr

Overview

This is an awfully dry post; dry due to the sheer logistic nature of it. This functionality exists and is quite straight forwards to stumble upon. This blog exists in order to draw your attention to it and hopefully minimize the stumble time.

You have a device:

1) Running an ssh server
2) With gdbserver

You also have:

1) A functional tool chain for the target (Code Sourcery is the traditional goto)
2) A Qt build for your target
3) A Linux box you are deploying from (My convenience, instructions should be readily repurposeable for Mac based developers)
4) Qt Creator (Qt Creator 2.4.0 (as shipped with the QtSDK) was used at the time of filming/documenting this process)

Qt Creator has various merits which basically speak for themselves.

Integrated documentation
Convenient remote visual debugging/profiling
Convenient (single click) deployment

You grow accustomed to this functionality if you target any of the officially/unofficially supported targets tightly integrated into Creator in its various distributions. (Official SDK, Necessitas, Meego SDK). It would be lovely if it were more commonly perceived as a generic end to end solution for deployment to generic Linux targets, and it is readily achievable if you avoid a couple of snags.

Initial configuration

Launch Creator
Menu -> Tools -> Options

Build & Run -> Qt Versions

Add your Raspberry PI Qt build: /opt/dev/qt-qpa-5-rasp-pi/bin/qmake

Creator indicates “Qt version 5.0.0 for Desktop”, this can be safely ignored.

Build & Run -> Tool Chains

Add your cross compiler: /opt/toolchains/arm-2010q1/bin/arm-none-linux-gnueabi-gcc

in my case. Adjust the ABI in the unlikely event it is incorrect.

Linux Devices -> Device Configurations

Add configuration with correct ssh details, deploy a public key and establish this works.

Per project configuration

1) Open an existing Qt application (example suffices)
2) Select a desktop build

Once this is done:

Projects -> Targets -> Build

Specify your target’s Qt version
Specify the toolchain from the drop down below

Projects -> Targets -> Run

Deployment

Method: Deploy to Remote Linux Host
Device Configuration: Select your “Linux Device” added in the Device Configurations step above

Run

Run Configuration: foo (on Remote Device)
Arguments: -platform eglfs

This should suffice, you should now be able to deploy, run and debug applications on the Raspberry PI (or any other similarly capable Linux based target)

A screen grab demonstrating the logistics is available here

A video where I talk through the steps is also available for those willing to weather my accent

Caveats

1) If you select a QtQuick UI project from the project wizard you will not be able to deploy to the target (will be grayed out). If you select a Qt Quick application you will get a QDeclarativeView based viewer/launch pad. If you want to dabble with Qt 5 (who doesn’t) at present, one has to ride to war with one’s own QQuickView based runtime/viewer (read: pony)

2) Qt must already be deployed on the target. We clearly handle this for our own devices, but when you are winging it as documented here, Qt has to have been (manually) installed to the configured prefix. (Needless to say, it is best to sanity check the Qt install prior to attempting IDE based deployment).

 

Posted in Embedded, Qt, Qt SDK, QtCreator

Testing QtQuick 2 (Qt 5) on your n9/n950

Published November 21, 2011 | By dcarr

QtQuick 2 promises superior performance, a new particle system and a host of new possibilities:

http://doc.qt.nokia.com/qt5/qtquick2-whatsnew.html

It is also quite ripe for testing if you are into that kind of thing. This is my personally recommended approach to testing QtQuick 2 on your n9(50) at this point in time and I have to stress that these steps are not officialy sanctioned. I don’t like chroot environments, and since my builds are restricted to Qt which uses the ever rational qmake build system (lone vocal fanboi here) which respects build (qmake profile) sovereignty, I don’t feel I need one. This is an alternate build approach to the webkit team’s approach linked to below and if you would rather follow in the footsteps of wisdom you might want to tail them.

The Webkit team were gracious enough to jot down these instructions:

http://trac.webkit.org/wiki/BuildingQt5OnHarmattan

which I used to setup the sysroot subsequently employed in my mkspec, available here:

https://gitorious.org/qt-platform-mkspecs/qt-platform-mkspecs/blobs/master/5.0/linux-harmattan-g++/qmake.conf

This mkspec clearly has to be adjusted to reflect your local dev paths.

0) Realize this is dangerous and might require the reflashing of your device/loss of user data
1) Install the dependencies (as documented in the webkit teams instructions above) in your HARMATTAN_ARMEL target under scratchbox
2) Replace any fully qualified symlinks under $HARMATTAN_ARMEL/usr/lib with relative ones
3) set PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH in relation to your SYSROOT
4) Run configure directly from qtbase
5) Use the resulting qmake to build the qtdeclarative module
6) Deploy Qt and the required xcb libs to the device (you will need to be root, supplement the existing files don’t override exist files)

You can use:

objdump -x ./plugins/platforms/libxcb.so

to establish what dependencies need to be fulfilled. Up until every required library is present, Qt is gonna tell you that the XCB backend does not exist.

I personally use shadow builds (build out of source) since I am targetting a wide range of devices and discard my builds with fair insane regularity. I have no hit any issues using them in Qt5 when targetting qtbase/qtdeclarative.

Similar steps would clearly probably work for the n900 but, alas, the version of xcb packaged as part of the Fremantle SDK is too old to be used with the XCB QPA backend as it stands. It will take a braver man than me with more time to kill to get that turkey airborne at this point in time. (I also managed to render my Meego 1.2.9 CE unbootable by trying to install the build dependencies, so I don’t see any really convenient avenue for QtQuick 2 experimentation on the n900. Prove me wrong)

Bon appetizer:

Graphic proof of flight, incase you are faring poorly and suspecting that I am a fibber.

Update

The Webkit guys (who tend to have their soup together) have created packages for Qt 5 (along with packing up all the xcb dependencies)

http://trac.webkit.org/wiki/BuildingQt5OnHarmattan

 

no money back guarantee offered, these packages could quite possibly consume your poodle.

Posted in Embedded, Lighthouse, Maemo, MeeGo, Multimedia, OpenGL, Qt, Qt Quick | Tagged , ,

Qt Commercial SDK for Desktop and Embedded Development to be Released in December 2011

Published November 17, 2011 | By Tuukka Turunen

With the Qt Commercial 4.8.0 release around the corner, we would like to mention that we are also preparing a new SDK in order to get the complete Qt Commercial development environment via a single installer. The new SDK contains Qt Commercial libraries, Qt Creator IDE and other useful tools, which can be conveniently installed with either a standalone offline SDK installer, or a smaller online installer that fetches the needed parts from our server.

 

The Qt Commercial SDK provides an update functionality that allows the user to easily check if there are new components available, and install them. The online-update functionality also allows an easy way to fetch additional components when they are needed.

 

The target is to deliver the first version of the Qt Commercial SDK in December 2011. This first SDK will be based on Qt Commercial 4.8.0 and Qt Creator 2.4.0. The SDK installers are initially available for Windows, Mac and Linux. Qt Commercial 4.8.0 supports many more operating systems, and we are looking into adding some of these into the SDK later on. In the future, we also aim to include the Visual Studio Add-In into the Qt Commercial SDK.

 

The new SDK will also contain improved support for embedded Linux development by introducing a new embedded Linux target in the Qt Creator IDE, cross-compiler toolchain, example configuration for embedded Linux and ready-made images for deploying Qt Commercial on commonly available BeagleBoard-xM and PandaBoard development boards.

 

For all upcoming Qt Commercial 4.8.x versions, the SDK will be available as an additional way of getting Qt Commercial. We will continue to publish the source packages and binary installers just as before for those who prefer them over SDK delivery. We hope the availability of the new SDK will make it easier to develop with Qt Commercial, and to stay up to date with new versions.

Posted in cross-platform, desktop, efficiency, Embedded, Qt

Full Steam Ahead with Qt Commercial

Published October 17, 2011 | By admin

The transfer of the Qt Commercial licensing business from Nokia to Digia was completed successfully a bit over one month ago. At Digia, we have been hard at work getting everything in place to ensure continuity for Qt commercial customers. We have invested in setting up our R&D team, in order to build new functionality and a verification system. Digia has hundreds of people who have Qt experience and this certainly will help us to ensure that we will provide high quality services for our Qt Commercial customers.

One area of great importance is to make sure that Digia´s development plans are well aligned with our customers’ needs. Based on earlier feedback from Qt Commercial customers we’ve heard, our customers have called for functionality that will support their applications on cross-platform desktop and embedded environments. Our customers have also said that added functionality can’t be included at the cost of stability and reliability. And, they’ve stated that the releases need to be supported longer to ensure business continuity.  Digia listens carefully its customer needs and will develop Qt Commercial according to their feedback.

We will approach our customers with a full customer survey during May. In the meanwhile, I will take this opportunity to present some updates to you right now.

To demonstrate the long term commitment for our customers’ Qt Commercial projects, we are extending the Standard Support from one year to two years after the next major Qt Commercial release is available. With this change a Qt Commercial software product version x.y.z will be supported at least two (2) years following the release date of the following version x.y+1.0 or x+1.y.0, whichever occurs first.

We have also identified that the life-cycle of Qt Commercial major releases should be extended to address the needs of those customers who do not want or cannot upgrade to a newer Qt Commercial version as it becomes available.

To ensure that Qt Commercial runs smoothly with those platforms our customers are actively using, we are complementing the Qt Commercial testing by packaging and testing Qt on several different platform configurations. Those platforms include Windows, Linux, Mac OS, Solaris, AIX, Windows CE and Embedded Linux. Going forward, we want to continue supporting these actively used platforms, as well as to add such new platforms and configurations our customers want to run Qt Commercial on.

Digia’s primary goal is to further develop Qt Commercial on the desktop and embedded platforms.

In order to complement the Standard Support, Priority Support and Premium Support we are working towards providing additional services to our customers, including training, consultancy, application development and UX design services. Together with our partners, we will increase our services offering for the whole Qt ecosystem.

The other major company in Qt is of course Nokia, and we are planning for a more detailed Qt Commercial roadmap aligned with Nokia’s Qt roadmap.  At the same time, we will also continue to support the functionality and platforms that are important for majority of Qt Commercial customers, but are not necessarily included in Nokia’s roadmap in the upcoming major Qt releases. As our customer, you can provide valuable input to all this via the customer survey conducted later this month. And, of course you can contact us at any time using the Customer Portal, the contact from at qt.digia.com, or via your sales representative.

We are working for the benefit of the Qt Commercial customers, as well as the whole Qt ecosystem.

Posted in cross-platform, desktop, Embedded, framework, Qt
← Older posts

The Qt Blog

Welcome to the new Qt blog! We have consolidated all the blog posts from the Qt Labs Blog with the posts from the Digia Qt Commercial blog. Our intention is to provide you with one area for all Qt development posts from our Qt experts.

As Qt enters a new era, we are working diligently to provide you with an ever-growing Qt Blog that includes projects, awesome ideas, tips and tricks and product info from our pool of very clever Qt developers.

This blog will be transforming as we move forward, so keep your eyes peeled for new developments.

Archives

Categories