Develop a GUI in Qt

When you start using our boards, you already have a precompiled root filesystem on the board that starts a small X-Server. There you will see that the touch screen will work immediately. However the touch needs calibration so that the input matches the display resolution. So in fact you don't need to do anything to get the touch screen running. You get coordinates and button events when using the touch in the same way as when using a regular mouse. So from the point of view of the application you handle the input exactly the same way. If an application works with a mouse, it will also work with the touchpanel.

Regarding Qt, I would recommend the following precedure. The BuildRoot based root filesystem that we have included can also be extended to use Qt. So first try to build the included root filesystem yourself, i.e. install the toolchain (if not already done), unpack buildroot, call "make fsvybrid_std_defconfig" (or whichever architecture you have) to configure for the standard root filesystem as provided and call "make" to build. This will take quite a while, maybe an hour or so, depending on the speed of your PC. Then copy the file output/images/rootfs.ubifs to your board and check if everything looks the same as with our release.

Then call "make menuconfig", go to the "Package Selection for the target", "Graphic libraries and applications" and check the "Qt" entry. Then enter the Qt entry and check "Compile and install demos and examples". You can add more Qt features here if you like.

Now exit everything, save your configuration and call "make" again. This will add Qt to your image, that will be now more than twice the size as before. If you install this image on your board, you have Qt available and you can experiment with the demos and examples. You can have a look at the examples source code and you can start developing your own application. You should also have a look at the documentation on the Qt website (<!-- m --><a class="postlink" href="http://qt-project.org/">http://qt-project.org/</a><!-- m -->), as it is rather generic and will give you a basic introduction on how to use and work with Qt.

Your F&S Support Team

Are you using the newest release V1.4? If I remember correctly, I tried Qt myself not so long ago and it did work. I can't remember having problems with /dev/fb0.

2.6.38 is the newest kernel version that we have for PicoCOM4 at the moment. If porting to newer kernels is easy or not I don't know, because we haven't tried yet.

First of all there is a 3 seconds pause in U-Boot, that you can easily get rid of by setting an environment variable. And you can reduce the kernel loading time to the minimum by setting a variable (e.g. KernelSize) with the size of the actually running kernel and then adding this variable to the bootcmd:

nand read.jffs2 31000000 Kernel $(KernelSize)

But then don't forget to update this variable if you install a different kernel or you'll load too much, or what's worse, insufficient data on the next boot.

Then you can scan through the options of the Kernel with "make menuconfig" and remove unnecessary stuff, e.g. audio, SD-card, USB, I2C, SPI, CAN, etc if you don't need them. A good idea is also to remove any debug options. If you also don't need networking, then you can remove this, too. But be aware that this makes development rather uncomfortable up to impossible, as you can't download any files by tftp or use an NFS mounted root filesystem anymore. So I would remove this as the last final step before going to a stand-alone, self-contained system. Also think about how you will do any updates later if your device is in the field. If you remove all these drivers, you may get to a system that can't be updated anymore.

One final thing you can do about the kernel is to remove the serial console from the command line. This also reduces the kernel boot time considerably. Please note that this only removes the boot log from the serial line, in /etc/inittab you can still configure a getty on the serial port that allows to login and execute shell commands. And the boot log can still be accessed via command dmesg afterwards.

And then you have to have a look at your root filesystem. For example you can remove unnecessary start scripts in /etc/init.d, remove unnecessary options in /etc/inittab, etc.

The next step is to reduce the file sizes, for example by stripping any debug data from the executables. The smaller the data the faster the files load. You can also try to split the root filesystem in a small one that is quickly mounted to show the bootscreen and a second one with your application and the Qt library that is mounted later on and may take a little longer to mount.

These are all things that can be done without actually having to modify the existing code base. Of course you can also try to add some new code. For example JFFS2 is not the fastest filesystem when mounting the first time. By switching to UBI, this might reduce the mount time considerably, about several seconds on a large filesystem. However the U-Boot of the PicoCOM4 does not support UBI in its current version. So you could search if there is some UBI implementation for this version or if you could switch to a newer U-Boot. One hint: use one before 2011.12 because in this version the boot system was reorganized and starting from then the U-Boot binary is quite a lot larger, so the 256KB of our current size will not be sufficient anymore. But PicoCOM4 NBoot (pc4boot) can not handle larger U-Boot images.

And you can switch to a different C library that is smaller and maybe faster than the glibc that we use, e.g. eglibc or µcLibc. A toolchain for this can be built by BuildRoot. Just switch from the external toolchain to a self-built toolchain. In this case you can also switch from default code generation for armv4t to armv5te. This might also reduce the execution time for some parts of a second.

As you can see, getting a quicker boot sequence is a process of optimizing in several different places and each place has its own pitfalls and needs time to find out how everything works.

Your F&S Support Team