I'm trying to understand how to cross-compile for a Raspberry PI3.
First, let me check if I understood correctly the meaning of the cross-compiling: is it to compile for a hardware that is different from the machine I'm building my application? This means, building for example a linux application from a windows system?
Second, all the tutorials I found required the building of QT for the target platform. Is this because to build a QT application I need the target-hardware-specific-built-version of QT libraries? Why there are no pre-built versions?
Third, I don't understand why a raspberry image is required in all the tutorials I could find.
Those are some of the tutorials I found, I found really strange that such a long setup is needed to cross-compile an application and I'm just wondering if what I'm trying to do (compile from a Linux machine a raspberry-pi3 QT application) is what those articles are really describing.
Tutorial 1, Tutorial 2, QT official embedded device page
You are correct, cross-compiling is building on one type of hardware (Host) to run on a different type of hardware (Target).
If you are willing to go for a commercial version of Qt, Qt will provided a turnkey solution (Boot to Qt) for developing on a specific Raspberry Pi. By turn-key, I mean they have all the target tools for cross compiling and the correctly built libraries for the target, etc. It's not cheap, and probably not the way to go for the hobbyist.
If you go with the open source (free) version of Qt, you will need to do most of the setup work yourself. The reason you are having a hard time finding everything built for you are mostly related to two things: The size of the distribution, and what you are building for what (i.e. which Qt version for which Raspberry Pi and which Raspberry Pi Linux version and which drivers, etc.).
The Raspberry Pi image is needed as you need the correct libraries to build Qt against. The cross-compilation tools need to link against the target (Raspberry Pi) images.
Yes, it is a long process to setup a Qt cross compilation environment, but it only needs to be done when once for each Qt version. Once you have setup the environment, building and deploying a Qt application on the target Raspberry Pi is really quite fast and easy.
Related
I have been working with QML for a couple of weeks now. But now a new requirement has risen where I have to check whether I can run QT5 in an embedded device for my project. I need this for my GUI related operations. The device has an ARM processor (Intel ARM920T-PXA27x processor to be exact) with 64 MB RAM. 32 MB will be taken up for the OS and the rest will be available for application and QT.
I have to check whether this is possible. I have googled for some references and unable to find a suitable answer to my requirement with QT5. I need the GUI libraries but my project does not have advanced graphical requirements like swiping or animations. It contains basic controls like texts, buttons and lists/grids. Since I am new to QT especially to this part, I would like to hear whether
1) Is this a viable option and should I keep digging more into this? Any feedback would be welcome to know if it's worthy to spend time to attempt this or if it's a lost cause.
2) If there are options, could you point me in the right direction to look more into this?
It depends on the OS you are running on your SOC.
It's definitely possible when running Linux. You can e.g. use Qt Lite for configuring a minimal static build of Qt. Then you deploy your statically linked application to the device. You can check this blog post for experiences with Qt Lite.
One possibility is to go with Qt for Device Creation for the whole embedded Linux based software stack which boots to a UI implemented with Qt technologies.
I'm wanting to develop a GUI application for the Raspberry Pi. I want this application to run without the overhead of a Desktop GUI environment, directly on X11. My google searching has led me nowhere trying to find examples of people doing this. My preferred platform is Qt, although if an option were available in another language/environment I would be open to it. My question is: does anyone know of examples of applications that do this? I'm just looking for anything to get me started.
Is it possible to use the MCU on the Intel Edison without having the standard Yocto Linux installed?
At the moment I have downloaded the specific Eclipse MCU SDK and have been using that to program the MCU on the Edison. I have the newest version (from Intel's website) of Yocto on the Edison as well.
If I switch to e.g. Emutex's Ubilinux will I still be able to use the MCU in any way? With or without the standard Eclipse MCU SDK?
The main reason I want to switch to Ubilinux is to have an easier time using ROS (Robot Operating System), but this is not strictly relevant to the question.
The Quark core runs its own Zephyr based OS, but I do expect some sort of support to be required on the Linux side too for intercommunication between CPUs. As dwelch said, the required drivers might be there for Ubilinux too.
If you are specific about ROS someone is working on adding it to Yocto. A quick google search also returned an unfinished project of ROS on Edison.
I know it is weird but I need to execute a Qt GUI application that supports X11 protocol on MS Windows platform.
It is obvious that if I build my Qt source code in Unix environment it automatically becomes an X11 application and this application can be run only on Unix Operating Systems, not MS Windows.
I tried to use MXE (MinGW cross environment) to compile my application in Unix for Windows, but it does not help for X11 issue. It creates an application for Windows but the application is not an XWindow application.
There is also a XPortMinGW project for minGW. But I do not know if it works for Qt applications.
Is there any way to build my Qt application with X11 support that can run in Windows OS?
I don't think that there's any need for cross-compilation. There are two problems:
Getting Xlib compiled for Windows. I don't know offhand of any maintained Xlib implementations that are ported to Windows. You will definitely need to find one, or make one. Hopefully Xlib depends only on a handful of posix APIs and they may be easy to translate to win32. Forget about Cygwin.
You may have luck porting Xlib yourself to Qt's network backend and making it cross-platform in the process, too. Xlib would simply use the core and network modules of Qt. No problem with that.
The good news here are that Qt 5 comes with a bundled Xlib implementation. It would be presumably much easier to get that to compile on Windows than some other implementation.
Configuring Qt to build using said Xlib on Windows. To do it right, you'll probably want to mess a bit with and rebuild the configure tool that comes with Qt, and add a makespec that will link with the Xlib.
This should be much easier to do with Qt 5.
It's not an entirely trivial thing to do, but should be possible. Give yourself a month and expect to get very intimate with some details of Qt's configuration and Xlib.
Notes About Cygwin
If your application is closed-source and distributed outside of your organization, you need to buy a commercial license in order to redistribute cygwin.dll. Otherwise, Cygwin is GPL and merely linking to cygwin.dll makes your application a derived work.
Cygwin becomes problematic when you mix posix- and non-posix code in the same application, especially if the non-posix code is a large framework like Qt. You can of course use the Posix platform code in Qt and make it all run on Cygwin, but that way you lose performance and expose yourself to shortcoming of Cygwin's emulation of POSIX APIs.
Using Cygwin for Xlib / windowing system but having Qt otherwise use Windows APIs may require a lot of tweaking for Qt code. So may using Qt with Xlib on Windows of course, but at least you don't have to debug/work around Cygwin's quirks.
If so, are there any platform specific code to be modified, or any other apparent issues observed?
QTouchEvent was added in Qt 4.6: http://doc.qt.nokia.com/latest/qtouchevent.html
There are some examples of what Qt have done:
http://www.youtube.com/watch?v=b749KvoX3w4
There are limitations in that the underlying windowing system needs to support this, such as Windows 7.