GUI for my embedded board

How much RAM and flash do you have? Maybe you can strip it down, but I think you'll need at least 10 MB of both. But at least it should work with uClinux, a Google search shows this page:

The general idea for embedded systems (if you don't have an X server running in your system) is to compile your kernel with a graphics driver (or a kernel module), which provides a framebuffer (e.g. /dev/fb0 device). Besides lots of the other Linux infrastructure (clock, network, libc etc.) and maybe tslib, this is all Qt needs to run, if compiled for embedded platforms.

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

etc.)

Hi I have an SD card of 2 GB and I have 192 kb of SRAM on chip .

and I have " qt-embedded-free-3.3.4.tar " of 23 mb and I want to port the application to the board.

Actually what I am not getting is that if I port the compiled application to the board than will it run or I have to create the environment on my board to make the application run.

Please tell me in detail , and if you have some good links related to this than please tell me.

Thank you

--------------------------------------- Posted through

What display hardware do you use? Not even one framebuffer with small resolution fits in such small RAM. And Qt needs at least some MB RAM, so you are out of luck for Qt.

Take a look at the Qt homepage:

Qt is a graphics library. It needs Linux, Mac or Windows as an operating system. For Linux you create some shared object files (.so) and copy this (and other files) to /usr/local/Trolltech/qt-version on your embedded device. Then you compile your application, linked to the libraries, and copy it to your device.

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

Hi if you don't mind can you explain this in DEtail if possible in steps.

Actually I am a beginner in this field.

I have browsed the QT site very well and also found lots of documentation on cross compiling and building and transferring.

But don't know the basics.

Thank you

--------------------------------------- Posted through

Hi

If I am correct than I should proceed in this way:

1 - Porting the Linux kernel to the embedded board as it would provide the basic kernel to interact with the hardware.

2 - Now I should install the QT library in the kernel directory of my board.

3 - than I should cross compile the aplication on my PC and than transfer it to the board .

Now I want to know that if I am correct or not or I am missing something.

Thank you

--------------------------------------- Posted through

Looks like you have absolute no clue. Maybe start to write a program with a Linux desktop system to learn the basics. Then add step 0: Add more RAM to your board. You can't even run Linux with 192 kB, and Qt needs some additional MB.

Maybe a better idea would be to use some lightweight C graphics toolkit, without dependencies to any operating system, but this depends on your requirements.

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

a

to

HI

this was not what I mean.

Actually my PC has both LINUX and Win7 installed on it, and I am working on the Linux for 4 months.

I have done programming on the Linux and have made various programs too.

But I am going to deal with the Linux at the embedded level for the first time .

I have installled the QT on my Linux system on PC , and have written many small programs, this is from where I got inspired to use QT on my embedded board too.

What I just want to know that what would be the hierarchy of the various Layers on the board,ofcourse it would be the LInux kernel first than other things, I just want to know these other things to run QT application on my board.

Now I think you would have got my point, I think that I am just missing a small point and I want help on that .

Thank you

--------------------------------------- Posted through

It is nearly the same as on your desktop PC, just change "harddisk" by "flash". A simplified overview: First the bootloader is started, which loads the Linux kernel from flash into the RAM, maybe decompresses it, and then starts the kernel. Then the kernel mounts the flash filesystem (or a ramdisk) and starts the init process. The init process is a user mode application, which starts other programs (with the SysV Init Runlevels concept, or the init process could be just a simple bash script), e.g. for network setup and maybe finally your program, if you want to autostart it, and/or a login program, if you want to login to a shell to the system.

For running Qt applications on your system, you have to cross compile Qt and copy it to the flash filesystem. Then cross compile your application, linked to the cross compiled Qt, and copy it to the flash filesystem.

Qt for embedded systems (e.g. configure called with "-embedded arm" when cross compiling Qt) needs at least the /dev/fb0 device. This is the framebuffer for painting to the display, and it is provided by the Linux kernel or a Linux kernel module. Note: if you don't have a standard framebuffer, you could provide your own QScreen implementation with the Qt Plugin concept, see

, but this is not easy to implement and if you don't have special requirements, the best way would be to use or write a standard Linux framebuffer driver, because then you can use the built-in classes from Qt and don't have to write anything for it. Qt embedded applications detects valid framebuffer devices automaticly at startup, so you don't even have to do some special configuration.

But I really don't think that you can do this with 192 kB of RAM. Google shows, that some people managed to run uClinux with 400 kB RAM, but usually you need at least 1 MB RAM to do something useful. And Qt needs many MB of RAM to do something useful with it.

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

Hi Frank

This is very good description and I got many things clear , but I have some new questions to ask. I am also pointing to my original doubts in between your description.

##############################################################################

and

for

it,

############################################################################

I am aware of this part, I know that to load a kernel in the system in PC a bootloader is used , sometimes it is primary bootloader and secondary bootloader and also in some system there is single one.

Mostly there are two types of Bootloader used :

1 - GRUB (which is on my system) 2 - LILO.

But in embedded systems due to absence of the BIOS the various booting softwares like uboot and others are used to load the kernel in flash.

###########################################################################

###########################################################################

Now my problem is here.

Cross- compiling the library is ok on my PC, but what part of the library should be transferred , and how it should be written to the flash, I mean how the library should be ported to the kernel on the board. Should I use the bootloader to load the QT library in the flash.or there is another way to do this.

how should I make a directory in the kernel on my embedded board for the QT library.

actually the kernel is on the board and how should I talk to it, by my PC .

#############################################################################

Qt

best

devices

############################################################################

what is this framebuffer and why should I use this. ############################################################################

usually

of

###########################################################################

can I exceed the RAM on my board by putting more memory chips in the circuit to increase the required memory of my board.

I think upto 4 MB of RAM would be sufficient.

Thank you

--------------------------------------- Posted through

You are right, but it is still a bootloader, e.g. take a look at the u-boot wiki:

Ok, maybe it is a "Boot Loader", not a "bootloader" :-) Some chips have integrated bootloaders, like the bigger ones from Atmel, to boot from SD cards, NAND flash etc., then u-boot could be the second stage bootloader.

I'm sure there are good tutorial pages about this topic on the web. One way how I did it was installing u-boot on the system with the platform dependent tools (e.g. JTAG to write to some on-board NAND flash). Then connect the serial port of the platform to your PC and in u-boot you can write the Linux kernel and the flash filesystem image.

I have used the jffs2 filesystem. On your desktop you create the filesystem of the platform in a directory, copy all files you need on the platform in this directory (e.g. the cross compiled Qt is installed at /usr/local/Trolltech/QtEmbedded-4.6.1-arm and this directory should be on your platform filesystem then, too), and then use the mkfs.jffs2 and other tools to create the image, which you then can download and flash with u-boot. In your case it might be easier, because you can just copy it (with the unix tool dd) to your SD card from your desktop system.

Another way would be to setup just a basic filesystem with some network tools to mount a NFS server, then start your platform, login to a shell and copy from the NFS server to your filesystem. For testing it is very useful to start your applications from NFS, or even "chroot" to a NFS mount point.

The kernel doesn't have a directory. The Linux kernel is just some bytes, which are loaded to RAM and then executed.

The kernel doesn't do very much without user programs. I don't know uClinux, maybe it is different with this Linux, but you could start some login daemon from within the init process, which then accepts logins from the serial port.

Try to do some research of your own, otherwise I have to take money for my training :-)

Read the datasheet from your microcontroller.

I don't think so. E.g. libQtGui.so.4.6.1 is nearly 10 MB and this is just one library. You'll need more libraries, a font etc. Ok, you don't need to load it all into RAM, but you can expect that some large part of it needs to be used.

You could try to link Qt statically to your application instead of using libraries, if you publish your project under the GPL licence (because the libraries are LGPL), but I don't think that it will be much smaller for a typical GUI application.

Qt Embedded on Linux works very good with 64 MB RAM.

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

filesystem

in

You mean if I cross compiled the library and in my system it is at suppose :

/usr/home/piyush/QT

than same path "/usr/home/piyush/QT" should be in my embedded platform

(with

Here I do not get your point why it would be easier for meto copy to my SD card.

and

useful

point.

according to this can I login in to the shell of kernel of my embedded system and can I pass the commands in the terminal of my embedded board kernel.

I mean can I access the terminal of kernel of my embedded system if this is so than I think I would be able to make directory in the flash memory of my embedded board, isn't huh...........

but how would I get the filesystem present in my desktop by running the command in the terminal of my embedded board kernel.

yes but the kernel can be used to pass the commands in the terminal and if it happens than 80% of problem I think would get solved because what I think that my problem is just to establish various layers on the board on the top of which all my applications can run.

So by accessing the terminal I think I can make directory and I can install the library as well .........am I going right.Is this as same as working with the desktop linux kernel.

what sort of Linux you are talking of.

can you brief me about this one because I am curious about it.

my

Oh sorry for asking this , actually I was also not sure whether to ask this or not , because I searched for it on the google and found a lot of material related to framebuffer but I ask this because I thought that you might have best information about it as you have done this project na .........so don't mind just ignore such posts or just type SOG( meaning search on google) than I will get the point and will do it on my own , you are not supposed to describe me every small thing or easy one but the tough one which are really very tough and are not easily available on the google. I also try to ask the questions after searching a lot but when I get messed than I post that topic on the forum.

I think Linking QT statically means is not easy and is also a very difficult task, if I am correct, please also explain me this one.

Thank you

--------------------------------------- Posted through

You can forget about Qt until you have at least 64M of SDRAM. Linux is big and Qt is bigger. You are not even considering the biggest piece: X or equivalent.

what do you mean by X or equivalent.

would you shed some light on it.

--------------------------------------- Posted through

www.x.org

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Just give Alice some pencils and she will stay busy for hours.

X display manager needs lots of program and buffer memory. You can shift some functions to the package (Qt) or the kernel (bad idea). Either way, you are not going to reduce the memory requirements much. Can't do serious graphics with small SRAM, just go with SDRAM. 64Mx32 SDRAM is around $50, but they usually come in BGA.

You don't need that much memory for X. I managed to install it some years ago on a PC with 8 MByte, so 64 MByte is more than sufficient, e.g. with a

16MBitx32, even if you need to store the framebuffer in the SDRAM, if you don't need very high resolutions:

Some people even managed to run X with 4 MByte:

but then you don't have much space for other programs. And of course, Qt for X11 would be on top of this and needs many extra MByte. If you want to use Qt for an embedded system, you should use Qt embedded, compiled with framebuffer support, because then you don't need X.

Or you could use just X, no Qt, if you like Xlib programming :-)

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

Yes.

Because then you don't need to write your SD card from your embedded system, but you can write it from your desktop system. Create a filesystem on the SD card, mount it, and just "cp" the files. No need to create filesystem images, loopback mounts, etc.

The kernel doesn't provide a shell, it is the Linux system, i.e. a user mode applications like getty and bash, see e.g.

for details.

If there is a login process (or just a bash) running on your system and listening on some port (e.g. if your embedded system has a serial port, it can listen to it), and if your filesystem is read/write mounted: yes, then it is possible that you login to your embedded system and to make directories.

As explained earlier, and if you have Ethernet on your embedded system, one way would be to use NFS:

The kernel itself doesn't provide a terminal interface, like bash. It just provides low-level system calls:

You need a filesystem and something like getty and bash to have a terminal, where you can interactively execute commands.

I was thinking of uClinux, but looks like it is the same with this Linux.

See

and related links. There is no easier way (unless you pay someone to do the work for you) than RTFM.

Creating an embedded Linux system from scratch is a lot of work. You need good knowledge of standard desktop Linux systems, how it boots etc. Then you can learn the special requirements for embedded systems and finally maybe you can setup an embedded Linux. To do this from scratch, maybe a professional developer, who knows already some user mode aspects of Linux, can do it in one month fulltime work. A beginner might need an additional year to learn the basics.

To avoid fighting with the hardware of your platform and the Linux system in parallel, you can do some training with Qemu:

You are right, it is not easy. I don't know, if someone has done it for embedded platforms. In theory it should be just passing "-static" for "configure" and setting the "static" option in your .pro file, but I'm sure there are some more problems.

For Windows someone did it:

and looks like you can get files with less than 4 MByte (runtime RAM requirements are higher).

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

way

Seems that you also tried your hand on one of such project.

Can you tell me about your project or can you provide the link to it or any documentation you have.

So that I can go through it.

Thank you

--------------------------------------- Posted through

Full X on Linux with a 4MByte 386 Was 1993 though....