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.
Related
I'm currently working on a Qt-GUI with which I plan to remote control a robot. The robot is ros-controlled and equipped with multiple cameras. The topic is completely new to me and I just started learning both Qt and ROS and have some basic questions. I didn't make any progress googling around so I finally decided to post it here:
How can I connect data from ROS with Qt? So let's say I kind of want to live-stream the recordings of the cameras into my GUI. How is the general procedure there?
I've seen this ROS Qt Creator Plug-in. Is that something I want to use for this project?
Thanks a lot to everyone answering.
This is my first post here so I hope I didn't mess anything up or flouted forum regulations.
Edit 1: I am working with C++.
Edit 2: In case it helps you giving me advice; the rostopic type of the camera topic is sensor_msgs/Image.
For question 1, since the images are coming over the sensor_msgs/Image topic, using ROS with OpenCV's cv_bridge in the Qt application to receive the the incoming image stream from ROS into the Qt-GUI is a good start. There are several tutorials that cover integrating OpenCV into a Qt project. An important advice is to keep track of the image properties (size, color format, etc.), which will help in displaying the image properly in the GUI. Disclaimer: I have worked with Qt libraries on the Python side, not with C++.
As for question 2, the information for setting up, building, and running the code within the Qt-Creator can be very convenient. There are times where it is prudent to use an IDE to build, run, and debug code (to deal with memory management, segmentation faults, etc.), while other for other times running "catkin_make" or "catkin build" in the root directory when the hardware is minimal.
I'm doing and embedded linux+qt project and I was wondering what was the base memory consuption of the linux kernel plus some basic services. Just enough to run some framebuffer based application.
I ended up in here: http://qt-project.org/doc/qt-4.8/requirements-embedded-linux.html but as I'm reading that seems like it's just the qt requirements without counting the linux overhead.
Can someone point me to a more detailed resource on the topic?
The numbers in the table you cited look reasonable.
The actual answer is "it depends". Yes, Virginia: it is possible to have a working OS and a Qt-based GUI in under 4MB.
The actual memory usage will vary wildly, depending on:
Which kernel you use
How you configure your kernel build
Which kernel drivers you load at runtime
What you start up during system init
Etc etc
Book recommendation:
Embedded Linux Primer, Christopher Hallinan
ALSO: here's a list of prebuilt-distros with GUIs that all run on Pentium IVs with 512MB RAM:
http://www.osnews.com/story/26087
I would suggest using Yocto for such builds, but you can also take a look at the upcoming "Boot to Qt" project which is basic a Qt 5 replacement for Qt embedded with Qt 4. I would not suggest looking into the link you pasted in your question.
You should definitely focus on Qt 5 for several reasons. The foremost is probably because you can get hardware acceleration and Qt got a lot of utilization for embedded, including decoupling the QtWidgets module, and so forth.
Here you can find the technology preview that the guy in Norway are working on. This is just for future reference:
http://blog.qt.digia.com/blog/2013/05/21/introducing-boot-to-qt-a-technology-preview/
I would start using the Yocto project for now. We have worked on a "meta-qt5" layer which is not perfect, but good enough. Yocto will also take care of the Linux with "minimal images", et cetera.
Not sure if you had seen the classic example a couple of years ago, but there was a "Qt boot" for an embedded Linux board which happened within a second. Here is the link to the reading material. Unfortunately, the original video does not seem to be available anymore.
http://www.embedded-bits.co.uk/2011/1-second-linux-boot-to-qt/
I'm trying to build an application in my ARM9 (Freindly ARM) board that will get data via serial port and update the database.
Now I need to port SQLite in my embedded linux and write an application to store my values.
How to port SQLite to Embedded linux
Pygtk or Qt? Which is easy for a newbie ?
P.S: I know I'm asking a lot of questions in a single post, but I just thought giving the complete picture will help to give a better suggestion. If not personalized opinions, I'll be grateful if you guys can give me pointers to good links/tutorials. :) Thanks.
1.
You don't need to port sqlite to the your Freindly ARM ARMv9 board.(as Mat has already mentioned)
I am going to assume that you have a mini2440 or
a micro2440.
Either way it is a Samsung S3C2440 chip.
sqlite works on this board as per the following thread.
Sumeet's post has cross compliation instructions.
Qt cross compliation works as per the following thread
So does Python and Gtk.
You have 2 options when it comes to cross-compliation,
Cross compile yourself
Use a tool like buildroot or openembedded's bitbake
For further resources on cross-compliation and building packages for this board
see the following resources.
mini2440 Google Code Project, specifically see the wiki and download sections
FriendlyArm Forum
FriendlyArm Downloads
linuxmce mini2440 wiki page
HOWTO-Getting-Started-With-OpenEmbedded for mini2440
Further HOWTOs
2.
PyGTK and PyQt are both relatively easy to learn in comparison to learning and debugging cross compilation on embedded architectures. If by Qt you didn't mean PyQt but instead meant C++ and Qt, then it not only becomes a choice of GUI toolkit, but also of language. I don't know your familiarity with Python or with C++, so I don't know which would be easier for you.
Which one you want to use is up to you.
Resources for both are linked to below
PyQt4 Tutorial
PyGTK Tutorial
We are trying to develop a real-time display system in safety critical domain. (All this is at very basic stage.) One option I have is to write my own Widgets using OpenGL. Other two options is to use something like GTK or QT.
QT seems easy to use and has good development tools. But I have worked on several applications in real-time domain using GTK but none in QT.
Can anyone point out to me the trade-offs involved here ?
I am settling with direct OpenGL programming for now.
The article Porting Qt for Embedded Linux to Another Operating System lists five things you have to do to port Qt for Embedded Linux to another OS. From the article:
There are several issues to be aware of if you plan to do your own port to another operating system. In particular you must resolve Qt for Embedded Linux's shared memory and semaphores (used to share window regions), and you must provide something similar to Unix-domain sockets for inter-application communication. You must also provide a screen driver, and if you want to implement sound you must provide your own sound server. Finally you must modify the event dispatcher used by Qt for Embedded Linux.
Is it really this easy to port Qt to another OS, or have i missed some information?
Another important component to port would be QAtomic, to ensure that you can have atomic operations and implicit sharing working well. See also
http://labs.trolltech.com/blogs/2007/08/28/say-hello-to-qatomicint-and-qatomicpointer/
Since Qt has been ported a large number of times it seems logical that it would be inherently simple. However the issue really is on the platform you are porting to and how many features it currently supports.
Assuming you find all those things easy, then the port is easy.
After investigating this in more detail I have come to the conclusion that the article "Porting Qt for Embedded Linux to Another Operating System" assumes that you are porting Qt to a very "linux-like" OS.
I have attempted this and currently making progress.
Some difficulties:
IDE - I have to manually add all Qt files and fight the compiler with #ifdefs until it builds with all dependencies in place.
Linux(ness) - I've had to disable all Linux/Windows things that are not supported in my target OS: threads, sockets, processes. Even the timers are slightly different.
Tips:
Start small : I compiled QtCore as a standard lib within my IDE, next up is QtGui which is a behemoth compared to QtCore.
I plan to run only a single QThread, so I have to artificially made a Thread object to avoid null pointers. You cannot compile out Thread information as it is key to all QObjects.
So far I have an qeventloop running within a qcoreapplication.
I wrote some inline assembly but had serious difficulties with my IDE and compilation. I left it in C++ and let the assembler handle it for me. Because I am single-threaded, I am not too concerned with shared data/ exclusive access as required by the atomic operations.