New Qt for Embedded Linux Series started
-
Hi All,
for info I have started a new series of HowTo's on the wiki related to building & using Qt for Embedded Linux. The series overview can be found "here":http://developer.qt.nokia.com/wiki/Qt_for_Embedded_Linux.
All comments welcomed. I'll try to get it finished in the next week or so but I will be offline for much of next week so please be patient.
Thanks!
-
I replayed to you in the wrong post...
It's very good idea, thank you for this startup :)
-
Scylla,
for my understanding yo are a bit too generic, please can you give informations on what kind of embedded you are working on?
-
Hi,
[quote author="Scylla" date="1300453813"]This is a good idea. The biggest problem, which I had, was to create touch and keybord driver for special (embedded) hardware. I'm interressting to get "opengl es" running on my hardware (new driver) and a easy to use virtual keyboard.[/quote]
I do not have any experience in writing touch/keyboard drivers for custom hardware. Luckily we were able to use tslib out of the box and then I wrote a simple virtual keyboard. The virtual keyboard is QWidget based but is reasonably useful. I have been meaning to port it to QGraphicsView or QML but have not gotten around to it yet.
-
What I was asking (just to focus the problem) was what kind of cross compiling platform Scylla is using, like openwrt or ltib or what ?
-
We are using the ptxdist from pengutronix to create the root image. We have two different platforms x86 and arm-gnueabi. The problem is that we have a custom keybord around the device display, which has a strange key layout. The other problem is that we use a touchscreen controller which is not usable with tslib (already testet). For this I wrote a driver which is working very well. But it's hard when you have no protocol and you have to debug the protocol. Now on my todo list ist the keybord driver. My intention for my request was to have a documentation for the steps which are needed to create a specific driver. The documenation for the embedded devices is not so good, like for the desktop. I have started with a template from Qt but I don't now anymore where I have found this tempalte. But this was a big help. And such templates and doc's for this should be on the wiki.
I hope you will understand my thoughts ;)
-
Hi,
I understood. I had the same problem to manage a driver that won't work. As a matter of fact I have no idea about a specific keyboard driver, but I can find the code I set for that driver, it can be useful as an example for you, then we can discuss with something more concrete.
I have not yet approached the interaction between gnu-eabi linux embedded and Qt for linux embedded (I will do it next week), so is possible that my thought is silly: when I worked on this driver, I done this for the linux kernel, not for high level interface, is it true?
I post here soon the mentioned example. FYI I developed this for and embedded linux board with Openwrt toolchain, while now I am starting with the ltib toolchain for simplicity with the board I need to work on.
-
As a note. The last year I spend all the time on the x86 platform. This week I have started with the arm platform. It tooks about 2 hours to get Qt running on our target. Most of time tooks the compiling, of course ;) One problem which we faced was a missing feature in the linux kernel (SYSVIPC [=y])! Such information should be on this wiki. I'm sure WE are on the may. I think the embedded platform is very important, that's why I'm here!
Scylla
-
I agree with you about the importance of the embedded platforms.
I hope I can create a specific gorup. And thanks to ZapB that got me the right advices on the platform choices.
-
Me too, I am interested to ptxdist, that I don't know.
I just asked this evening to open a group Qt embedded to host and exchange these knowledge and experiences. I hope that they accept.
Well, Open Wrt is a good place to develop embedded linux, because there are some guys in the mailing list that give a good support. It is essentially a system developed to manage routers. Thus, it has good support for the network almost in all the ways. But Open Wrt is also used for a small eepc open hardware, so there are also at least decent graphic interfaces for some display and peripherals like touch screen, keyboard etc. The understanding of the internal system is not immediate, and the problem is that there is no great documentation for those that use this for the first time but the principle is not so difficult to understand. The toolchain can be configured with good command line tools based on make configurations.
The alternative is ltib. Initially when I decided what toolchain system to use I preferred Open Wrt because it was a totally custom platform so a lot of driver needed to be rebuilt or redone. In the new project, where I want to setup Qt for embedded as the graphic environment I will use ltib. This is essentially related to the hardware platform that need to be used: LPC 3250 on a board similar to the EA3250 (from Embedded Artists). Ltib is a toolchain sponsored by NXP that produces LPC3250. For more informations about the toolchains that can be used there is a discrete support on the site lpclinux.com almost totally dedicated to the platforms that adopt NXP Arm processors.
As all the toolchains, ltib has advantages and disadvantages. A thing that I found not so good when developing but that can be simply bypassed is that the toolchain components are installed in the host system libraries (mostly in subdirectories of /opt) This choice generates some critical situations that need to be known before to start.
I hope that this very short introduction can be useful for you. Can be a good idea a more detailed article to introduce these toolchains approach on the wiki pages of developers.nokia ?
-
To complete the previous post, here is the link for ltib on lpc3250:
As yo can see, there is also another alternative, that is ELDK toolchain. I have not yet tested but I do it before a final decision on the platform to use.
-
This are interesting informations. I will/have to take a look to this.
We are using ptxdist, because we are using the support from "Pengutronix":http://www.pengutronix.de/index_de.html for special kernel driver. Our system is an realtime system (plc) with realtime bussystems like ethercat/canopen, realtime jitter<1us. The board is developed by ourselfs, so no standard hardware. I'm working on the visualization system, of course ;) and on the base system.The toolchain is just a ptxdist project, so it's easy to create the toolchains. The configuration will create with a config menu like the kernel config. This tool is good as long as all needed packages are included. If a specific package/application is not awailable you have to create you own package. The ptxdist is based on a rules system.
I'am also have tested the Android platform. At first with compiling the lib by myself and it's working. Today I have tested the necessita/ministro version and this is create work.
As my boss have seen my Qt application running on my HTC Desire connected to our visualization, he got crazy, took the phone and called his boss ;)
-
This is a good news!
Myself is the boss of myself, and in these project I'm responsible of the software platform at all while my friend / project partner done the hardware project based on my idea, based (2nd level) to the ea3250. The starting point is that the board I am working to develop is those of embedded artists, but it is too expansive against a low cost software and hardware integration platform. I have several product projects to develop on the new board as I am ready with the linux + graphic environment.
So, I need to be sure - reasonable sure - that the choice can be a long term choice. I took a look to your Pengutronix development platform and as I read it seems interesting because very open. As this toolchain has the problems you mentioned, ltib has other problems. If you plan to start with tests on this, please tell me, so I can save at least the time I already spent for silly problems. But blocking. As you know, I imagine, all problems on embedded platforms are silly when you discover why the occurs.
Well, the last thing I have not yet done is to test the ltib alternative as discussed in lpclinux.com.
At the actual date (to be precise in this moment) I have finished to flash the last build with Xephyr X11 server and twm as window manager. The board has a 320x240 fb screen with touch. I see the penguin when the platform start but - this is the actual problem - I am searching on how to configure some file that probably is missing because when I launch startx or xterm or twm or Xephyr I obtain always the message that the display :0 can't be opened.
I think that it can be a hardware problem because /dev/fb0 is present in the device list.I am thinking to something collaborative with you if you are interested, later I write about, let me the time to think exactly on how this can be structured. If you like, obviously :)
-
bq. If you plan to start with tests on this, please tell me, so I can save at least the time I already spent for silly problems. But blocking. As you know, I imagine, all problems on embedded platforms are silly when you discover why the occurs.
That sounds good. Next week I'm on holiday but when I'm back I will start to try.
-
bq. I took a look to your Pengutronix development platform and as I read it seems interesting because very open.
Yes that was important for us. In our first linux device we had used the timesys from timetorm. This tool is based on eclipse and very expensiv. And worst was that after the license is expired you can not use the tool anymore. You can not do anything in the old project :-(
-
I have no X command. Probably I was not clear, because this is the first time I use on an embedded platform a screen display. I compiled the kernel & UImage with the Fb display driver. This is surely correct because I checked with the hardware developer. Then I setup the configuration with X11 that is a tiny x server and twm as window viewer. Thus, what I have in the filesystem as commands startx that is the script the launch Kfbdev (the x-server if I have understood) trying with screen :0 (defined in DISPLAY as an environment variable)
Then the next command is twm -display:0I always obtain the same message : unable to open display ":0"
Following my investigations, the thing that I don't know is where I can search for the configuration file similar to the definitions I find with the common X11 environment in non-embedded linux.
This is my need only to have a complete check of the platform (hardware + software) and next step is to start with Qt
-
As long as I have used and seen x11, there was always an x-server, x-client and an window manager like twm. Kfbdev I don't know. Maybe I have to take a look at this. But why you don't use the qws? This is what I'm using on our device. Anyway, try to set the "DISPLAY=127.0.0.1:0.0", somtimes "DISPLAY=:0" is not enough.
