Qt on Raspberry Pi as an Embedded System


11 posts
by matinzk » Mon Nov 05, 2012 12:35 pm
Hi everyone.

I have written my application with QT Creator as a "QT Quick Application" and would like to run it on my RPi to be used as an embedded system.

I want to run my application as soon as I power up the Pi, is this possible? I want the boot time till my application runs to be less than 2 seconds. Any guides? We're doing a project and need a solution asap and happy to contribute to whomever that can help us out.

Thanks.
Posts: 17
Joined: Fri Sep 28, 2012 4:26 pm
Location: UK
by ghans » Mon Nov 05, 2012 2:05 pm
Here we meet again :lol:
http://linux.about.com/od/itl_guide/a/gdeitl36t04.htm
Add your program to a runlevel (i believe 5) .
You might want to disable LXDE and just use X only.
Google for "rc.d" for more information.
You should just disable any services you don't need.
"update-rc.d" and "apt-get remove" are the commands you should look into.


ghans
• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org
Posts: 4638
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany
by matinzk » Mon Nov 05, 2012 3:11 pm
By doing so will the boot time reach 2 seconds or less till it runs my application?

How do I specify where my application is and also will the built project with QT just run as soon as it's called?

Thanks.
Posts: 17
Joined: Fri Sep 28, 2012 4:26 pm
Location: UK
by matinzk » Tue Nov 06, 2012 2:10 pm
bump
Posts: 17
Joined: Fri Sep 28, 2012 4:26 pm
Location: UK
by Wizard » Tue Nov 06, 2012 3:58 pm
No, it wont boot in under, or even near, two seconds.

If speed is required then you have to look at bare metal coding or perhaps some low level QNX stuff.
One possible solution could be to boot a small RAM image and execute from there but I suspect the load time on Raspberry Pi will take >2 sec regardless...
Raspberry Pi - finally a worthy replacement for A500!!!
User avatar
Posts: 120
Joined: Sun Aug 19, 2012 4:52 am
Location: Sweden
by matinzk » Tue Nov 06, 2012 4:18 pm
Thanks for the reply.

The DexOS within the Bare Metal category is a good choice and I have tested it. But since we're using alot of images for our application it doesn't support more than 10 images and gives errors when compiling. It also doesn't support PNG images with transparent background which is what we have.

Thanks.
Posts: 17
Joined: Fri Sep 28, 2012 4:26 pm
Location: UK
by DexOS » Sat Nov 10, 2012 9:46 pm
matinzk wrote:Thanks for the reply.

The DexOS within the Bare Metal category is a good choice and I have tested it. But since we're using alot of images for our application it doesn't support more than 10 images and gives errors when compiling. It also doesn't support PNG images with transparent background which is what we have.

Thanks.

What error do you get, is it about not enough memory ?, if so click opions
then compiler setup and up the memory available.
In the fasmarm editor.
Batteries not included, Some assembly required.
User avatar
Posts: 864
Joined: Wed May 16, 2012 6:32 pm
by matinzk » Sat Nov 10, 2012 9:50 pm
I've tried that but doesn't help.

Anyway, PNG is what Im after. BMPs are very difficult to work with :D
Posts: 17
Joined: Fri Sep 28, 2012 4:26 pm
Location: UK
by dms75 » Tue Nov 13, 2012 8:01 am
Hi,

as a lower bound for linux-ish boot times that can be achieved I tested the following setup:

- booting overclocked to 1 GHz
- a fast class 6 SDCARD Sandisk 30MB/s for fast 4k block access times
- initial turbo
- loading the emergency_kernel with a small custom initramfs specified in the config.txt file
wich drops you into a busybox based command promt (the emergency kernel supports an external initramfs as a seperate file on the sdcard, and I didn't want to compile my own kernel for the tests)

I could boot in about 7 to 8 seconds (4 to 5 seconds after plugging in power to get to the colored spash screen, and annother 3 seconds to boot to the command promt).
Note that in this setup i didn't load any initscripts and didn't connect any USB Hardware, since enumerating these on the bus also takes some additional time.
So regardless of the OS you'd use, you won't be able to achieve times under 5 seconds, and with linux it really depends on what you need. To have very fast boot times under embedded linux the usual approach generally is:

- don't do unecesary stuff (as in: initialasing stuff you'll never use, cutting down init scripts helps a lot, and replacing tons of different sripts with a single one to avoid context swithching helps too)
- if you really have to do stuff check whether you can do it at a later time (as in: initialize devices after you have started the UI, so you'll have a responsive system and likely nobody will notice you're still initializing components while the user is still navigating menus etc.)
- lots of kenel drivers and kernel modules have optional command line arguments that can give hints how to initialize the hardware, avoid autodetection since it eats a lot of time due to timeouts
- trade flexibility for speed - if you really need fast boot times replace init scripts with a compiled programm which does the same job, only faster (This is rather annoing if you still tweak the setup and always need to recompile it though, save it untill last if you really need to scrape off those last few seconds boottime)

In the case of the raspberry a custom compiled kernel with only the drivers built in you'll actually use and a small initramfs will also speed up the bootprocess, for not having to initialize the drivers and for smaller files to load by the bootloader.

So you won't achieve sub second boot times with the pi as the firmware is too slow for that compared to a system where you might have some flash memory directly attached to the arm adress bus, but getting in the range of 8 seconds or so should be feasible. In my tests I have not recompiled the kernel there are some possible optimisations there, and since the initramfs is loaded by the firmware you can get away with a kernel without built in support for the sdcard too. If you need to access the sdcard itself later on (for stuff that is not in the initramfs) - build sdcard support as a module and initialize it after the UI has started. If you're running headless maybe you can get away with a kernel without USB support that might give you annother second boottime less. Or load and initialize USB after the UI runs while doing automated stuff like showing a slideshow, since without USB you'll have very little means for user interaction - no network no mouse no keyboard, gpio maybe?

I hope I could give some pointers in how things could be done, good luck!

Dirk
Posts: 25
Joined: Mon Aug 06, 2012 1:41 pm
by lsandrini » Sat Nov 17, 2012 6:16 pm
Hi matinzk, do you have an working sd image with QT 5?
Is it possible you tell me how I can made one, because I follow many tutorials but I didn't succeed.
thanks in advance
Posts: 1
Joined: Sat Nov 17, 2012 6:10 pm
by matinzk » Sat Nov 17, 2012 7:38 pm
Nope, haven't got it working. for what we wanna do we've abandoned RPi at the moment :D

Thanks.
Posts: 17
Joined: Fri Sep 28, 2012 4:26 pm
Location: UK