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.
Re: Qt on Raspberry Pi as an Embedded System
Here we meet again 
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

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
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org
Re: Qt on Raspberry Pi as an Embedded System
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.
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.
Re: Qt on Raspberry Pi as an Embedded System
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...
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!!!
Re: Qt on Raspberry Pi as an Embedded System
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.
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.
Re: Qt on Raspberry Pi as an Embedded System
What error do you get, is it about not enough memory ?, if so click opionsmatinzk 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.
then compiler setup and up the memory available.
In the fasmarm editor.
Batteries not included, Some assembly required.
Re: Qt on Raspberry Pi as an Embedded System
I've tried that but doesn't help.
Anyway, PNG is what Im after. BMPs are very difficult to work with
Anyway, PNG is what Im after. BMPs are very difficult to work with

Re: Qt on Raspberry Pi as an Embedded System
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
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
Re: Qt on Raspberry Pi as an Embedded System
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
Is it possible you tell me how I can made one, because I follow many tutorials but I didn't succeed.
thanks in advance
Re: Qt on Raspberry Pi as an Embedded System
Nope, haven't got it working. for what we wanna do we've abandoned RPi at the moment 
Thanks.

Thanks.