Hi Experts,

We are designing a controller PCB using Linux on an ARM CPU.

We would like to run Lazarus generated programs with a GUI on this hardware.

Now we would like to know how much RAM is necessary (besides the "Business Logic" variables the program uses).

I suppose we will need to use some Widget Set (QT ?, GKT ?) and X11 Server, even though the GUI should only be visible via VNC via TCP/IP.

The controller (TI AM1808) does have graphics hardware, but I don't suppose that this makes much difference.

What (free) Widget set should be used ?

How much RAM is necessary ?

Thanks for any hints,
-Michael

2011/7/14 Michael Schnell :

Though I can't help with main question about the RAM needs, I dare adding to your w.s. list fpGUI.
I would consider it for an embedded platform and I think it supports X11.

Roberto

Roberto P. wrote

Though I can't help with main question about the RAM needs, I dare adding to your w.s. list fpGUI.

Of course fpGUI is my top desire on that behalf, but unfortunately it's not yet as perfect with thread synchronization as GTK2 is (I did not yet test QT). I am trying to help Greame on that behalf, but right now, I can't be sure that this will be doable.

I would consider it for an embedded platform and I think it supports X11.

Yep it does support X11 and would help to get rid of the burden of a heavy external widget set library.

Thanks,
-Michael

As determined by the distro you select. GTK2 is probably a safe choice due to its ubiquity, Qt has to have approximately the correct version libraries+shim+lazarus and in practice I've only got it working on x86 Debian "Squeeze".

and X11 Server, even though the GUI should only be visible via VNC via TCP/IP.

Watch out here: I believe that there's some form of bug in (at least some variants of) VNC which prevents it working on ARM. Remember that you can also tunnel X over SSH.

Depends. As I've mentioned before, I find I can run programs on an NSLU2 "Slug" with only 32Mb, but I suspect that the issue here is how much "important" stuff (daemons etc.) gets swapped out and how long it would take to swap it back in if needed in a hurry. If there's a five-second hiatus every time somebody touches SSH with a port-scanner it's going to be a very effective DoS.

Compiling Lazarus itself is /right/ out in 32Mb, see http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators#Relative_Performance and note the relative speeds of compiling FPC and Lazarus on a Slug and on an emulated processor with much more RAM.

As a general point, note Ludo's recent patches.

I've had enough success with it to be generally impressed, would be nice if it were sufficiently mature to be an option for the Lazarus IDE.

I note mention of an alternative to X11 called "Wayland" which Ubuntu might start pushing at some point. If this ever happens (and is done in such a way as to not antagonise the rest of the industry) I wonder what effect it would have on things like fpGUI which bypass the popular widget sets?

Mark Morgan Lloyd wrote

I've had enough success with it to be generally impressed, would be nice if it were sufficiently mature to be an option for the Lazarus IDE.

+1

I suppose Graemes 1st priority is the stand alone Version rather than the Lazarus integration.

Sounds interesting :)

-Michael

Mark Morgan Lloyd wrote

Watch out here: I believe that there's some form of bug in (at least some variants of) VNC which prevents it working on ARM. Remember that you can also tunnel X over SSH.

Hmmm. I did not yet hear of problems of VNC on ARM. Maybe this is limited to AMS without MMU ?

The plan is to remotely attach to a running program and not to start a program remotely. So I suppose remote X is not an option.

I did some tests with the slug. The thingy we are designing will have 128 or 256 MB, so chances are a lot better.

Thanks,
-Michael

Not knowing, can't say. What I do notice is that Debian for ARM doesn't bundle RealVNC but does include TightVNC, the latter works after a fashion but for some reason doesn't start a window manager..

The plan is to remotely attach to a running program and not to start a program remotely. So I suppose remote X is not an option.

If you wanted to attach to a single, running program rather than to a desktop there might be scope for fudging the VNC startup to give that program full control of the (simulated) X server.

On the emulated system I've got 256Mb and it appears usable. The only thing I'd query here is whether, during the lifetime of the hardware, the software loaded on it will bloat to the extent to which 256Mb is no longer enough.

???? 14/7/2011 3:17 ??, ?/? Michael Schnell ??????:

The controller (TI AM1808) does have graphics hardware, but I don't suppose that this makes much difference. What (free) Widget set should be used ?

I successfully tried the GTK+ on DirectFB (
http://directfb.org/wiki/index.php/Projects:GTK_on_DirectFB ) with gumstix, but not for production use. ( From their site "The GTK on DirectFB (shortly GTK-DFB from now on) project consists in a GDK library which acts as a glue between the GTK+ toolkit and the DirectFB windowing system (similarly, the GTK-X11 libary acts as a glue between GTK+ and X11 and GDK-WIN32 does the same for Windows GDI). " )

regards,

2011/7/14 Michael Schnell :

The plan is to remotely attach to a running program and not to start a program remotely. So I suppose remote X is not an option.

There is also NX (freenx) which behaves very similar to Microsoft RDP/Terminalserver (except that it uses X instead). You can disconnect from a runing session and later attach to it again without having to close the session. It is orders of magnitude faster than VNC, you can even run it through ISDN or Modem connections reasonably well.

Roberto P. wrote

I would consider it for an embedded platform and I think it supports X11.

The final goal is porting a huge Delphi program. AFAIK fpGUI still lacks several visual Components the Delphi VXL provides. So I would need to add them (while extending fpGUI makes a lot of sense, this might need a lot of work).

If this would not be about porting from Delphi, I'd rather consider MSE, which provides decent "active"non-GUI applications out of the box as it does not have that much Windowish remains that Lazarus inherited from Delphi.

-Michael

Bernd wrote

There is also NX (freenx)

I understand that, even if reconnecting is possible, NX needs to start the applications remotely (as children of the desktop created by NX). As this is for monitoring deeply embedded Gadgets from time to time, this is not an option.

Thanks,
-Michael

Thanks,
I'll take a look.

-Michael

Michael Schnell wrote

Of course fpGUI is my top desire on that behalf, but unfortunately it's not yet as perfect with thread synchronization as GTK2 is

Please note Michael Schnell is ONLY referring to the LCL-fpGUI widgetset. If you use fpGUI directly (no LCL involved), then there are no ,
- Graeme -

Mark Morgan Lloyd wrote

such a way as to not antagonise the rest of the industry) I wonder what effect it would have on things like fpGUI which bypass the popular widget sets?

If Wayland actually takes off, then I'll obviously implement a Wayland backend for fpGUI too. But as far as I know, they want to implement Wayland in such a way that existing X11 application will continue running - so there should be a problem with the current fpGUI (which uses X11 directly)

Regards,
- Graeme -

Roberto P. wrote

Though I can't help with main question about the RAM needs, I dare adding to your w.s. list fpGUI. I would consider it for an embedded platform and I think it supports X11.

I have heard of quite a few developers using fpGUI directly (not via the LCL-fpGUI widgetset which is still in Alpha state) on embedded devices - with great success. They reported that the executables are smaller than LCL equivalents, apps use less memory and have a much smaller library dependency.

Paul Breneman has even made a small FPC cross-compilation distribution of FPC & fpGUI targeting WinCE on ARM devices, in a small 2-5MB download. I'm pretty sure something similar could be created for targeting Linux embedded devices too.
http://www.turbocontrol.com/helloworld.htm

I unfortunately don't do software development on embedded devices, so can't be of any further help in that regards.

Regards,
- Graeme -

Graeme Geldenhuys wrote

running - so there should be a problem with the current fpGUI (which uses X11 directly)

Typo alert. That should read: "...so there shouldn't be a problem..."

Regards,
- Graeme -

This is obviously great, but unfortunately our project needs to result in a common source tree for Delphi (apps running on Windows) and Lazarus (apps running on ARM Linux). For a very long time converting the (complete huge) Windows stuff to Lazarus will not be possible. So I need to stick to LCL (GTK or fpGUI Widget Type)

I unfortunately don't do software development on embedded devices, so can't be of any further help in that regards.

I will go on considering LCL-fpGUI and once we start working on this I will try to add the bits that are missing to make it work for me. (But of course I will need some help from the experts on this. )

Thanks,
-Michael

Graeme,

I've now got FPC & fpGUI minimal distros for Linux for i386 and ARM here: http://www.turbocontrol.com/easyfpgui.htm

Paul

Michael Schnell wrote

The plan is to remotely attach to a running program and not to start a program remotely. So I suppose remote X is not an option.

In that specific case I think I'd consider splitting the "daemon" and "UI" apart, and connecting between them with something like XML conveyed over SSH.

That would, potentially, put a lot of schema validation etc. in the daemon, but that sort of thing is probably much more predictable than a mass of LCL, widget set, X and so on.

This of course is what I would do if this would be new software specifically designed for the task in question. But actually we face a huge project done with Delphi that needs to be ported (and modified as little as possible, as the same source tree needs to keep on being maintainable in some hundred legacy installations.)

Thanks,
-Michael

Just to give you an idea of memory usage: a 256 MB ARM Debian etch (QEMU) system is using 17M of memory when logged in. With XFCE launched and one terminal window the usage is 76M. Launching Lazarus (gtk2) and after compiling a small program (8 units in editor), memory usage is 84M. Usage is what you get with the free command: used -/+ buffers/cache. XFCE is small but there is much smaller. I've taken Lazarus as big/huge program not knowing what your project involves. The system in not optimized neither as you would for a real embedded system either (lpd and other daemons running).

Ludo

Ludo Brands wrote

Just to give you an idea of memory usage: a 256 MB ARM Debian etch (QEMU) system is using 17M of memory when logged in. With XFCE launched and one terminal window the usage is 76M.

Much less than 100 MB !

So it should be no problem to run a big Lazarus Program with GUI (requiring X11, GTK or ???, and whatever required) on a 256 MB system.

Sounds good.

Thanks a lot

-Michael

"should be a problem" or "should not be a problem"?

i'm suspecting "not" was inadvertently out? ;)

that's what i thought... please ignore my last :?

This is when I miss NNTP newsgroups (which were purposely designed for group discussions). I would have been able to cancel my last post, fix the mistake and repost it - without anybody being the wiser.

Regards,
- Graeme -

How can you have accountable discussions when people can delete their posts? Is there a time limit for doing such things?

Henry

Henry Vermaak wrote

How can you have accountable discussions when people can delete their posts?

Viewing the discussion as a tree structure; replies to a specific deleted post will simply move up one level. Some NNTP servers and clients also support the "replace post" command, where a later post can replace an existing post (even better for fixing spelling mistakes). Replies to the original post will stay as is.

For a true history of message threads, there are websites like Gmane and Google Groups that archive posts without deleting anything. But as far as I know, a group admin can also ask to have a specific message removed from the archive (applies both to Gmane and Google Groups).

User's don't normally delete their messages, but at least the option is there (to prevent embarrassment, or due to some heated discussion with later regret etc.).

Is there a time limit for doing such things?

There is no time limit as far as I know, though I'm not 100% sure.

Regards,
- Graeme -

Graeme Geldenhuys wrote

On 07/20/2011 10:29 AM, Henry Vermaak wrote: >

[...]

IIRC, deletion of post only possible until a reply is posted to it (but I may be wrong)

L.

Regards, - Graeme -