Hi FPC Experts.

I am doing a project that in the end is supposed to run on a QNAP 219 NAS. A colleague of mine is doing a similar task, that is supposed to run on a Raspberry Pi.

Both these systems run Linux on a decently up to date ARM CPU.

The obvious way to go is to use Lazarus on Windows and/or PC-Linux to create and debug the software, and create "functional" objects in dedicated units and for testing add "GUI" Units to allow for code instrumentation with "internal state" and "simulated actuator" output and for "simulated sensors". Moreover there can be "remote control" objects for attaching real sensors and actuators. The "GUI-Debug" Objects communicate with the functional objects via function calls and Events.

When the code seems to work appropriately, the GUI and simulation units can be replaced by units that (without needing a GUI) can work in the embedded environment. Only a limited amount of final testing needs to be done there.

Now the question is how the project should be compiled for the ARM target.

Both systems allow for installing FPC but are not able to (decently) run a GUI system for Lazarus.

So the options are either to do cross compiling (with Lazarus) or to install FPC on the target and compile the code there.

What is the more viable way ?

BTW. (maybe better handled in the Lazarus Forum): I do know that gdb allows for remote debugging vie TCP/IP. So when cross-compiling it should be possible to remote-debug the project on the ARM-Target from a (Linux) PC using Lazarus. Did anybody test this, yet ?

Thanks for any answers
-Michael

Michael Schnell wrote

Now the question is how the project should be compiled for the ARM target. Both systems allow for installing FPC but are not able to (decently) run a GUI system for Lazarus.

My recollection is that I've had Lazarus running on a "Slug", including gdb. The important point was that I neither had video capability on the host, nor did I start up a desktop using vnc, instead I tunneled Lazarus over ssh and found performance adequate (taking into account the severely limited memory by today's standards).

I am facing similar choice (Odroid X2 Quad Core, 2GB RAM, eMMC), I tried for years to cross-compile and remote debug, but this raises way too many issues (setup of the environment is almost impossible), and this is particularly slow development cycle due to compile, copy, start remotely the process, hook remote-gdb, get to the point where you need to debug, (almost a nightmare)

by far the only viable option is to install Lazarus on the target develop on the target in order to compile and debug on the same device, this should be doable nowadays since devices such as Odroid X2 have 2GB RAM and Quad Core 1.6Ghz and very fast DiskIO using eMMC module,

the idea is to use a Ubuntu/Linaro image for ARM,
and get a decent setup of Lazarus,
if you are willing to setup such a system on Odroid X2, then I am even ready to offer a bounty for the time spent, including all hardware,
so we could share a similar development platform, and similar methodology,

Jyv.

In fact I just replaced my old Debian-enabled Slug (plus an USB disk) by the much more powerful some weeks ago :-) . So now I have the Luxury of a power saving automatically starting and stopping mirrored disk system for my backups :-) :-) .

I suppose by "had Lazarus running on a "Slug", including gdb" and "tunneled Lazarus over ssh" you mean remote debugging (running Lazarus on a PC and the gdb stub on the Slug). I don't see what else in Lazarus might support tunneling via SSH. (Please let me know if I am wrong.) Great to hear that this does work.

-Michael

Jy V wrote

by far the only viable option is to install Lazarus on the target develop on the target in order to compile and debug on the same device, this should be doable nowadays since devices such as Odroid X2 have 2GB RAM and Quad Core 1.6Ghz and very fast DiskIO using eMMC module,

I don't see how I could install Lazarus on the QNAP, as there is no GUI / Widget was told that on the Raspberry Pi, QT can be run, but that it is dead slow.

-Michael

IMHO use virtual machines:
Most of my customers run vmware sphere on their servers. I only have to version and copy the virtual machines.
Mind you: My compilers are still configured for remote and crosscompile but this setup is more or less static: the vm's can simply be replaced with a newer one on live or moved to hardware.
(And ofcourse - in my case for webdevelopment incl. ARM - cycle through a set of ip's before one becomes production)

On the 256 model 2: yes, on the 512 model 2: No, acceptable.

I suspect that Mark means X11 forwarding, thus running Lazarus on the board, but displaying it and interacting with it on a different PC.

Regards,
Sven

Thaddy wrote

IMHO use virtual machines:

What should I run in the virtual machine ? I can't run the QNAP system there (slightly proprietary ARM) and I do have Windows and Linux PCs in hardware.

-Michael

Sven Barth wrote

I suspect that Mark means X11 forwarding, thus running Lazarus on the board, but displaying it and interacting with it on a different PC.

I don't suppose I can run an X11 stub (such as NoMachine NX or whatever the Xorg stub is called) plus a widget set (such as QT) on the QNAP NA device.

I can't imagine how that should be possible on the tiny MMU-less Slug.

-Michael

Michael Schnell wrote

I don't suppose I can run an X11 stub (such as NoMachine NX or whatever the Xorg stub is called) plus a widget set (such as QT) on the QNAP NA device.

later I found this:

http://www.tiaowiki.com/w/Install_NX_Server_on_Raspberry_Pi

So it might be possible, though ....

-Michael

Yes, that's right. Alternatively you can run VNC on it (provided that you've got gdm installed which pulls in enough libraries etc.), but that tends to be inefficient since much memory will be allocated for the desktop.

Older versions of Lazarus and/or GTK were inefficient mapped over a LAN, IIRC that was tracked down to excessive keyboard interaction. Related problems also affected things like Mozilla "big time", this kind of headless operation is not high on the kernel/X11 developers' priorities these days.

A Slug /does/ have an MMU: otherwise how do you think it manages to run a standard Linux distro?

Michael,

This "embedded" thread you started recently has been great. I've tried to keep up with how you are using (or hoping to use) FPC on headless embedded systems for years now. Thanks, and please continue to keep us in the feedback loop!

I've used www.nomachine.com some with desktops but I'll have to use what you linked on my RPi. Then it might allow my RPi to be a simple headless embedded system using the ARM Linux stuff here: http://www.turbocontrol.com/easyfpgui.htm

Thanks,
Paul

Hmm. Unfortunately I don't seem to be able yet to extract a usable result from this thread.

There are different ways to use FPC (and Lazarus) to design and test "embedded" projects for "headless" hardware.

Using a PC to do the biggest part of the software locally, as I described in my original post seems to be commonly agreed upon.

But how to debug and finetune the stuff in the device itself ?

The alternatives are
a) cross compile using FPC and just run it (debugging via code instrumentation)
b) install fpc on the Target and compile and just run it (debugging via code instrumentation)
c) cross compile and remote debug using Lazarus
d) install Lazarus and FPC on the Target, compile and debug.

Now the hardware in question in this thread is Thread is
1) Raspberry Pi
2) a small QNAP NAS
(To me BeagleBone is a very interesting board, as well, much more "professional" than RPi and with $70 not too expensive) All three run Linux on a rather modern ARM.

So at least (a), (b) and (c) are supposed to be possible with these boards. (d1) is verified using the hardware graphic of the device but nor recommended at least for the small version of the RPi due to it's very slow X performance.
(d1) might be possible and recommended with both when installing a remote X system such as NX. I did read a paper about how to install NXfree on RPi (needs configuring and compiling it from the sources) but I don't dare to try this on the QNAP (but I keep it in mind) (d2) is only possible with NX (or a similar remoting software)

(c) seems the most appropriate way to allow for decent debugging performance, but seemingly nobody yet decently tried (or wrote instructions to) to get Lazarus running remote gdb via TCP/IP.

So I am still stuck here.

Sorry, I don't get your meaning here. Did you try to install NX-Server on the RPi (as described in the appropriate paper) ? Did it work ? Did you try to try to install Lazarus on the RPi ? Did it work ?

Of course the "simple GIU" is a viable option for devices like RPi with limited resources but with Graphics hardware. It obviously is not sensible for devices like my QNAP that does not have any Graphics both cases I still think the optimum way to do the hardware specific software development is remote debugging.

Thanks for your comments.
-Michael

Michael Schnell wrote

(c) seems the most appropriate way to allow for decent debugging performance, but seemingly nobody yet decently tried (or wrote instructions to) to get Lazarus running remote gdb via TCP/IP.

One of the options in the lazarus debugger settings is "GDB debugger through SSH". Remote debugging with gdb on the command line also works well for many years.

So I am still stuck here.

You're not "stuck". I've been building lazarus apps natively on my arm netbook for more than a year (first with armel, then armhf). It's too slow to use productively, but could be used to debug. Modern arm laptops (like the chromebook) should have no

One thing I've done in the past (using a couple of different Modula-2 compilers) was to code in such a way that the program would run on a PC as well as on the target. The algorithms were sorted on the PC with full access to debugging facilities, the code was then moved onto the target (protected-mode x86 bare-metal) where the greatest problem was memory-access exceptions which were all caught by a logic analyser.

I'll try to find instructions on this and try to install the gdb "stub" on the QNAP and test this combination ASAP. (SSH already is in place on the QNAP.)

Remote debugging with gdb on the command line also works well for many years.

Do you mean independently of Lazarus and fpc ?

I already did test this with C programming and I all the time use Eclipse to debug embedded software via a USB-JTAG adapter which AFAIK for gdb and the system that controls gdb (here: Eclipse, but could be Lazarus as well) is identically to remote debugging via ICP/IP..

You're not "stuck".

Of course I am not really stuck. :-) :-) .

The program already does work nicely on the Linux PC server and I suppose I in fact don't need to debug it on the ARM. I just need to compile it. And here I have the choice to install fpc on the QNAP (should be possible: I already successfully did install gcc). But I understand that installing fpc on the ARM is done by cross-compiling the compiler on a PC. So it seems even easier to cross-compile the user program itself. Here it should be even better to do that using Lazarus, which is installed on the Linux PC, anyway.

-Michael

So

"Cross-compile app every time"

is easier/better than

"Compile cross compiler once and work natively as of then"

?

That is a weird assumption. I would go for the second one, hands down...

Michael.

I wouldn't if the second one is significantly slower than the first one. Otherwise I'd agree :)

Regards,
Sven

Michael Van Canneyt wrote

I would go for the second one, hands down...

I see.

Thanks (I'll come back when I seem to be unable to cross-compile the compiler or install it on the target ;-) ).

-Michael

On old hardware, maybe, but these days ?

Michael.

Hi,

Do it on the device. Either directly or remote via NX, VNC or even X-forwarding is fast enough on current devices.

Any of the many Cortex A8/A9/A15 (dual/quad) boards available. E.g. Exynos 4/5 boards like Odroid-X2 (135 USD)/U2 (90 USD), Arndaleboard (250 USD), ARMBRIX (135 USD), or any of the i.MX6 boards beginning from ~80 USD iirc. Or any of the Allwinner A10 boards (Hackberry A10 - 65 USD), or "USB-sticks" or mini-PCs that you can get from 40 USD upwards. Then there are the beagleboard variants, the pandaboard, etc. I think there are some allwinner a31 (or so; quad-a7) boards cheaply available too. And probably many others with decent performance and price I guess.

As for future, you can expect Exynos 5 Octa boards (octa core, quad a15
+ quad a7) being available a few months after launch of the first smartphones/tablets containing it. I assume Samsung will show off the first devices on Mobile World Congress 2013 end of February (galaxy s4, galaxy note 3, maybe a new galaxy tab 10) or shortly thereafter.

If you have a little more money, you can get a recent smartphone (e.g. galaxy note 1/2) and a base station (e.g.
http://www.samsung.com/us/mobile/cell-phones-accessories/EDD-S20JWEGSTA for the galaxy note 2, but there's one for the regular note too) that has USB + HDMI connectors too. I think the "lapdocks" available for some phones can serve a similar purpose. Put a debian chroot on it and off you go. Or develop natively on Android - the fpc compiler is already there :)

Or get a chinese not-so-big-brand tablet: for ~200 USD you can get 10" ones with 2048x1536 ips display and at least usb/bluetooth/wifi + hdmi out to connect a regular keyboard. (I saw ones for 215 EUR with these specs when ordering them from Germany, i.e. with taxes, probably shipping within the EU, etc)

Depending on your exact needs and the money you want to spend, the devices you can buy now, already offer 1-4 cores at 1-2 Ghz, typically 1-2GB RAM and some (dev boards, mini pcs) even a real SATA connector. Most of the developer boards also have expansion ports like the rasppi.

At least for the Odroid-X (predecessor for the X2) and allwinner a10 hardware accelerated graphics are available or in development.

They all are reported to run stock linux. So in the "worst" case, if you cannot find the prepackaged solutions or don't want to mess with e.g. Android, just install a debian chroot on them and do an "apt-get install lazarus" and use NX.

So for ARM (on-device) development, really, there are many excellent alternatives for the rasppi. If you are not that tight on money or not really need the rasppi, don't bother with it.

There are so many options at the moment, so actually it's the other way round, there's so *much* choice that it's hard to find the most suitable one for a given price point if you search a little.

See above.

*I* have been using such a device for a few months now, and it's fine. Even Lazarus works fine over dog-slow VNC on such a device (I personally don't use it, but tried). Don't expect core-i7 performance, but it's workable. Really, don't bother with a rasppi as a development machine if you can spare a little more money for an Allwinner A10 for that purpose.

I believe any simulator even on top-end machines is slower than that.

Use "sudo apt-get install lazarus" on the device. Then use VNC, X forwarding or NX. Or simply connect HDMI output to a monitor, add a keyboard and mouse and there you have your new desktop.

Again:

sudo apt-get install lazarus

taken from

http://wiki.lazarus.freepascal.org/Lazarus_on_Raspberry_Pi

I think there is no need to explain how to setup x-forwarding or VNC.

nx:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66&t=11882

(contains some link how to build + some issue fix)

The instructions to get lazarus and nx running are the same on any other (arm-based) linux.

Hth,
Thomas

I agree. It's no big deal waiting an hour for a complete FPC build provided that it's known to be a good release, or a couple of minutes for an app that tests out OK on another platform.

Hi,

There are so many options at the moment, so actually it's the other way round, there's so *much* choice that it's hard to find the most suitable one for a given price point if you search a little.

forgot to add the "Chromebook" as a more well-known option of course.

Thomas

I still have an old arm development board with around 200MHz... and I also don't know (yet) how my new m68k/coldfire board performs (also 200MHz).

Regards,
Sven

Hi,

sudo apt-get install fpc

and

sudo apt-get install lazarus

Or

wget ftp://ftp.freepascal.org/pub/fpc/snapshot/v27/arm-linux-[armel| armhf]/fpc-2.7.1.arm-linux.tar.gz

tar xvfz fpc-2.7.1.arm-linux.tar.gz

./install.sh (or so)

Hth,
Thomas

Add the OUYA console which is also a little, nice ARM board :) (and unlike normal Android phones it's said to be rather open)

Regards,
Sven

Hi,

Just fyi, a complete fpc build takes ~13 mins on a 1.4 Ghz Exynos 4412. This includes the regular cycle + the WPO builds - e.g. in total 5-6 rebuilds of the compiler, and a few times the rtl and finally the packages.

Thomas

Thomas Schatzl wrote

Do it on the device. Either directly or remote via NX, VNC or even X-forwarding is fast enough on current devices.

As on the QNAP there is no graphics hardware, VNC will not work (at least not out of the box). It needs a Frame buffer RAM and if there is none to install X on, you need to do a simulated Framebuffer RAM in the normal RAM. I suppose this is possible, but might slow down things a lot (see RPi with hardware-shared FB RAM). X-forwarding is rather "funny", the X-Terminal being the X-Server for the device. So the best choice is NX.

If you have a little more money, you can get a recent smartphone ...

As said: the hardware inn Question is predefined (for me a QNAP NAS right now). and for "embedded" application you can't use a smartphone, even if you design the hardware yourself. You will need hardware project depending interfaces. In fact this is why I suggested to use a BeagleBone. This "deeply embedded" board is designed very similar to a high-level smartphone.

Nice.
But (like e.g. Suse) the QNAP does not have "apt...". Here two package systems are available: "qpkg" and "optware". There is only a very limited and dedicate choice of applications in the qpkg world. much more on optware, but AFAIK not fpc and Lazarus (I think it would be a *good thing* if the community would be able to provide both on optware "ipkg".

-Michael

Thomas Schatzl wrote

sudo apt-get install fpc and sudo apt-get install lazarus

Nice if the system has apt...

For the QNAP NAS (that runs a slightly tuned Linux distribution) there only is qpkg (by QNAP themselves) and ipkg (by Optware). Both worlds don't offer fpc or Lazarus. So making and installing form the svn seems the only way to go.

-Michael

I'm sorry, but I believe that's misleading. I was routinely able to run the server-end of VNC (i.e. the code that runs on the same machine as the app) on a Slug, on X-based systems it simulates an X server so doesn't need a frame buffer etc. Simulated framebuffers are noting new: Xnest does exactly that, and there's also a standard dummy which is most often used to allow a display manager (gdm or whatever) to run headless.

Mark Morgan Lloyd wrote

I was routinely able to run the server-end of VNC (i.e. the code that runs on the same machine as the app) on a Slug,

I even do have a Slug for testing (the one that recently was replaced by the more powerful QNAP)

How did you install the VNC server ? (hopefully not "apt-get", as this is not available on the QNAP).

on X-based systems it simulates an X server so doesn't need a frame buffer etc.

I did not know that. ( Supposedly I was mislead by what I found out about VNC on Windows.) This suggests that on Linux, VNC might not be slower or more memory hungry than NX.... Great !

Simulated framebuffers are noting new:

Yep. Its obvious how they work, but they might be memory hungry and slow when it comes to X, as the full X server needs to be installed and run on the target.

Her NX and (as you just made me know) VNC is better.

-Michael

In the case of the Debian-based Slug... I'm sorry but it was apt-get. I'd presume that one of the standard sources could be compiled although you'd probably need X-devel stuff, this is getting outside my area of competence but I can say that different variants of VNC have slightly different command-line formats (more detail if you need it).

Windows is very different, in that case VNC works by "scraping" the main screen and then trying to work out what's changed. On unix (for a non-root session, i.e. the server starts in response to LAN activity) it sets up its own X server, that gives it the capability of logging changed areas and under some circumstances it can be significantly more efficient than running X over the LAN.

Yep. Its obvious how they work, but they might be memory hungry and slow when it comes to X, as the full X server needs to be installed and run on the target.

Not /the/ full X server, /an/ X server. And in the case of a dummy that can be pretty simple, since all it's got to do is tell apps that it's got minimal competence and let them sort out how best to proceed. I must admit though that apps (strictly, widget sets) are much less tolerant than they used to be: some have decided problems if they can't get e.g. sufficient colour depth.

The X-Terminal is not the X-Server for the device. The X-Server on your host computer will be the X-Server. The client just uses the x11 library (as it always does) which in turn communicates with the X-Server and one of the underlying protocols is simply TCP... (on your host computer other protocols can be used, e.g. pipe based together with shared memory to speed things up, but you could use TCP on your host as well...)

Regards,
Sven

Sven Barth wrote

The X-Terminal is not the X-Server for the device.

Sorry for inappropriate wording. I meant the X-Terminal is the TCP/IP Server.

-Michael

In our previous episode, Thomas Schatzl said:

Sheeva, 1.2GHz armv5 iirc +/- 30mins. (fixes branch). (512MB USB HDD)

please define "old hardware"... PII 300mhz is "too old"? PIII 800mhz? and of course, how much RAM would be considered "not enough"?

I suffered a massive drop in performance when my 4x PIII 2.9GHz died, and (wanting compatibility with the same type of pluggable disc sleds) I had to fall back to a 2x 800MHz for Qemu etc. People are giving away 2GHz servers because they're five years old, or 2.8GHz games machines because their graphics have fallen behind: unless you have compatibility requirements there's limited excuse for struggling with anything slower.

For production use speed might not matter that much provided that it's offset by lots of CPUs/cores and adequate memory, but for builds you need brute-force CPU because FPC paralellisation isn't particularly fine-grained.

Which is a shame, because today we're collecting a Sun V880 that somebody local wants cleared from their office: 16x 800MHz CPUs in a 100kg+ chassis. Great as a database, web server, or for things like Linux kernel builds; not great for FPC/Lazarus or as a Qemu host. Ho hum.

Mark Morgan Lloyd wrote

In the case of the Debian-based Slug... I'm sorry but it was apt-get.

Funny: Optware is hosted by nslu2-linux.org (->
http://www.nslu2-linux.org/wiki/Optware/Packages?from=Unslung.Packages ). The slug Linux also is supported by there ( ->
http://www.nslu2-linux.org/wiki/SlugOS/HomePage) so I would think it likely, that the Linux distribution for the Slug would use ipkg.

-Michael

In our previous episode, waldo kitty said:

Anything older than the corporate writeoff period (3-5 years)

Michael Van Canneyt wrote

On old hardware, maybe, but these days ?

The topic of the thread is "embedded".

Here <you often use hardware featuring rather restricted resources.

In many Linux tool config scripts the keyword "embedded" even still is used as a synonym for MMU-less.

-Michael

I think there's a distinction to be made between "embedded kernel" which might be MMU-less, and "embedded Linux" which is a standard Linux with filesystem, Busybox and a more-or-less-well obscured telnet port.

Hi,

Neither one of your targets fit my description of "embedded" or having "restricted" cpu or memory resources for running fpc or lazarus. Don't know the demands of your application though.

Calling a beaglebone a restricted device is somewhat odd given that the cpu is clocked at 720Mhz, has 256MB RAM and runs full Linux. There are even beefier "embedded" (I read embedded as designed for industrial applications with higher quality, customization options, support and long-term availability demands than boards with consumer cpus given your targets and your reluctance to use any of my other possibilities) developer platforms available (e.g. IGEPv2 @ 1Ghz/512MB RAM, also cortex-a8 iirc; they recently announced development of a Cortex a15 design too). They're just little harder to find, maybe slightly more expensive and you don't get the very latest and greatest.

The Qnap isn't really an embedded device either from fpc/lazarus POV, with 1.2Ghz/256MB RAM for an *entry* level ARM Qnap. It runs a full desktop Linux in the end. Differences in external connectors or whether it comes with a nice case are not relevant for running either FPC or Lazarus. If the cpu is capable of running full Linux, it runs FPC and Lazarus, maybe slowly. But at 1 Ghz+ this shouldn't be an issue.

Really consider trying Lazarus on the beaglebone natively, it should be reasonable, maybe a bit slow. On the Qnap I don't know if it is useful, it uses some arm11 cpu which is much slower clock for clock than a Cortex-A8, but then the beaglebone is clocked slower. Lazarus is a bit performance demanding.

If you only care about the CPU differences, and not about the heavily modified stock qnap linux, you can also install a debian chroot on the qnap (been there, done that, on a ts-119 long ago) as suggested earlier and use aptitude to install anything you want.

The Qnap applications you write cannot be GUI applications, using command line gdb could be sufficient in the worst case if you don't want to setup remote debugging. It may be more useful to ask in the Lazarus lists about how to setup that than here though. There are enough websites that explain how to setup a remote gdb session.

With the command line gdb, typically with very few commands you can get very far already. Especially if you do your main debugging on the PC anyway. You can also try the gdb integrated TUI (text mode user interface) - so that you can "visually" single-step etc. if that feels more comfortable to you.

Btw, to simplify development and save copying over resulting binaries all the time you could always map the relevant directories onto your local pc e.g. using sshfs or smb and use scripts to call the native compiler. The qnap and the beaglebone have (relatively) low-latency ethernet connectors, so there should be virtually no difference in performance when editing.

Hth,
Thomas

Thomas Schatzl wrote

Neither one of your targets fit my description of "embedded" or having "restricted" cpu or memory resources

Ooops. A NAS is a device doing 24/7 unmanaged work and features no sockets for Monitor, keyboard and mouse. Both Raspbery Pi and BeagleBone are PCBs that don't feature sockets for a harddisk (sata and friends) and are supposed to be installed in small housings to do 24/7 unmanage work.

IMHO thus all three fulfill the criteria for "embedded" electronics.

Of course you are right that nowadays this kind of embedded ARM Linux devices resources (happily !) are not seriously restricted any more.

-Michael

Thomas Schatzl wrote

Really consider trying Lazarus on the beaglebone natively,

In fact this is what this discussion already led me to.

Unfortunately I did not yet find a way to install a VNC server on the QNAP. There seems to be neither a qpkg nor an ipkg for VNC.

-Michael

Thomas Schatzl wrote

On the Qnap I don't know if it is useful, it uses some arm11 cpu which is much slower clock for clock than a Cortex-A8, but then the beaglebone is clocked slower.

I think my TS219 II P with a Marvell 2.0 GHz and 512MB DDRIII RAM really is not bad on that behalf and fulfills your criteria of "modern" quite well, and will easily be able to run Lazarus, if a GUI system can be provided, but alas, no VNC or any other appropriate X-Server found, yet.)

There are enough websites that explain how to setup a remote gdb session.

I'll take another look. A description in the Lazarus Wiki would be optimum.

With the command line gdb, typically with very few commands you can get very far already.

I already did use same, but only for C.

In fact my original question was just about how to create the ARM executable from my sources that already successfully have been tested on a PC. (For this project I really don't expect that debugging on the target is necessary.) The issue of debugging came into the discussion later.

-Michael

Hi,

Michael Schnell wrote

On 01/16/2013 12:03 PM, Thomas Schatzl wrote: > Neither one of your targets fit my description of "embedded" or having > "restricted" cpu or memory resources

... for applications like fpc (or lazarus). *Your* application may have different requirements.

For fpc/lazarus, you need a fast enough cpu (check), sufficient memory (check), sufficient storage (check, in the worst case either network storage over LAN, or simply an USB HDD if onboard flash is not sufficient) and sufficiently good I/O for use (check, Ethernet) and suitable OS (check, Linux).

What again, differentiates a beagleboard or a qnap from your PC if you put them into the same case (or hide them from a user)? I'd guess that except for the performance difference, users would not notice for these particular applications.

The performance aspect is getting better and better day by day as you already mention.

Ooops. A NAS is a device doing 24/7 unmanaged work and features no sockets for Monitor, keyboard and mouse. Both Raspbery Pi and BeagleBone are PCBs that don't feature sockets for a harddisk (sata and friends)

There are quite a few (high-end consumer) cpus that have native sata already. Allwinner A10, Exynos5xxx, there are some i.Mx5 with sata and all but the lowest end i.Mx6 cpus to list a few. Not sure if OMAP5 has one. I heard of some ARM11 chips also having sata. Some of those cpus are old.

USB2 is sufficient for what fpc/lazarus requires too.

Given what functionality NASes provide today there is not much that differentiate them from a PC. Except maybe the different case.

and are supposed to be installed in small housings to do 24/7 unmanage work.

Neither lazarus nor fpc need a monitor, keyboard or mouse, sockets for hdd, a small housing present *on the actual device*. You can also run lazarus 24/7 unmanaged barring any application errors; since fpc is a batch processing tool it does not make a lot sense to say it ever needs to run 24/7 unmanaged.

IMHO thus all three fulfill the criteria for "embedded" electronics.

I am more referring to devices that cannot run on or you don't want to run a no-guarantee-anything multi-purpose OS as such that is designed and used for any purposes. I.e. things much smaller than what you target, and with severe restrictions on the application that is running.

Yes, it's sketchy and ymmv. Imo these are simply miniaturized full-fledged pcs.

Of course you are right that nowadays this kind of embedded ARM Linux devices resources (happily !) are not seriously restricted any more.

That's the point.

Thomas

Al 16/01/2013 13:11, En/na Michael Schnell ha escrit:

I think my TS219 II P with a Marvell 2.0 GHz and 512MB DDRIII RAM really is not bad on that behalf and fulfills your criteria of "modern" quite well, and will easily be able to run Lazarus, if a GUI system can be provided, but alas, no VNC or any other appropriate X-Server found, yet.)

You can install debian on it, then you'll have everything you need (no, I don't own one, I just googled it).
If you don't want to replace the stock firmware maybe you could install a debian chroot and, again, have everything at your disposal.

Bye

hell, that's when we pick up the freebies out of the dumpsters and upgrade our servers and workstations ;) :lol:

sadly, though, we've not been able to go dumpster-diving in recent times :/

Luca Olivetti wrote

You can install debian on it, then you'll have everything you need (no, I don't own one, I just googled it).

You are right, but as I use it mainly for it's intended purpose (NAS) and here the QNAP-tuned Linux distribution offers really nice feature - while not preventing installing additional community software via ipkg or from the sources, I'd like to stay with the original distribution and install fpc via cross-compiling. Maybe I can somehow extract the binary from the fpc apt-get-Debian-ARM package and just copy it to the device. Any idea how this (with a PC finding, downloading and unpacking the files from a Debian package without using apt) might be done ? I also might try to upgrade the (seemingly outdated and not normally upgradeable) Debian on my old Slug to do the task. (Do you know how to do this ?)

If you don't want to replace the stock firmware maybe you could install a debian chroot and, again, have everything at your disposal.

Seems like a nice idea. Up to know am not up to date with what chroot exactly does and how it might be possible to chroot and then install Debian in the "jail".

Thanks a lot for these hints,
-Michael

Thomas Schatzl wrote

With the command line gdb, typically with very few commands you can get very far already.

I have been thinking about this and If it is really possible and viable to use the command-line GDB with programs compiled by fpc, this adds two very useful options to the list of the four alternatives:

a) cross compile using FPC and just run it (debugging via code instrumentation)
b) install fpc on the Target and compile and just run it (debugging via code instrumentation)
c) cross compile and remote debug using Lazarus
d) install Lazarus and FPC on the Target, compile and debug.

e) cross compile using FPC and remote debug with the command line gdb via ssh - gdb-stub - gdb - link (in case Lazarus does not decently support remote debugging)
f) install fpc on the Target and compile and debug with the command line gdb locally, using an ssh terminal log-in.

I think I will try to do (f). At first trying to get fpc running on the target by either cross-compiling it or by extracting the binary from the Debian package (see the other message in this thread).

-Michael

I've used a tool called alien for this sort of thing on Debian, and something comparable for reading .rpms on Slackware. My recollection is that .deb, .rpm etc. use fairly standard file formats, the "added value" is in the metadata and scripting.

Having said which, if you're looking for a binary VNC server for ARM then Debian might not be the best place to start: there's some (licensing?) issue with a patch that went into VNC to make it run on ARM which stops Debian using the standard vnc4server package and they've instead got something with slightly-different parameters (possibly tightvncserver but I'd need to check).

I also might try to upgrade the (seemingly outdated and not normally upgradeable) Debian on my old Slug to do the task. (Do you know how to do this ?)

Don't. Your Slug's probably got Lenny on it which is fairly robust. Knowing that (the processor in) the Slug behaves fairly similarly to SPARC as far as alignment etc. goes, and knowing that there are gross failures in Debian Squeeze and Wheezy on SPARC which particularly affect graphics-related stuff, I'd strongly suggest that you sniff around and find out what you can do on the existing OS before considering an upgrade.

Michael Schnell wrote

I think I will try to do (f). At first trying to get fpc running on the target by either cross-compiling it or by extracting the binary from the Debian package (see the other message in this thread).

If you try to build FPC on/for the target, you might need to explicitly disable debugging support in the fp IDE (i.e. NOGDB=1). It's the only platform for which I've not been able to build libgdb, and when I queried it somebody (Jonas?) said that it was so processor-specific that that wasn't likely to change).

Hi Thomas, Mark and others.

Another colleague of mine now has just got the new "big" version of the Raspberry Pi. He reported that he has been able to just apt-get Lazarus, and it's GUI runs fine in the SSH-remote X server.

He did not know right now what the package that provides this remote X is called, but he was rather sure that same had been installed on the RPi from the beginning, and he is positive that it is an apt-get package.

So for me a viable task would be to find the apt-get packages necessary to run Lazarus, download them to a PC, extract the necessary files and scripts and try to install them on the QNAP NAS.

Does anybody know what pat-get packages are necessary and how to do what I described or something similar ?

Thanks,
-Michael

Dear Michael!

Remote X is done using X-forwarding

ssh -X

Your raspberry requires minimal set of Xlibs installed.

Typically I test i386-compiled application from i386 build-host (where i'm at x86_64), because I dislike chroots.

regards,
Anton

-X will frequently be the default when ssh is installed. This is from an unmodified /etc/ssh/sshd_config on a Squeeze system:

X11Forwarding yes

..and it's definitely in that state at least as far back as Lenny. So all you have to do is login (if your usernames are consistent a simple ssh your_rasperry will suffice) and then run e.g. /usr/local/share/lazarus/lazarus

In order to suppress debugging messages and make sure that a casual ^C can't kill your session, I've got a little script /usr/local/bin/QQ which looks like this

#!/bin/bash
$@ >/dev/null 2>&1 &

So once you've got a shell session via ssh, and assuming you've got a lazarus binary on your path, all you have to do is QQ lazarus and it's running in exactly the same way as though you had it on your local desktop: note that the window caption /does/ tell you what machine it's running on.

There's other ways of doing it, for example with ssh certificates and a link on your local desktop. Since a high proportion of what I do is via shell sessions anyway, I've never felt any need to put time into that.

I understand that this is the command to be issued at the PC to contact the remote device.

My question is how to install something at a non-Debian headless Linux device to allow for such a login to remote a gui session.

-Michael

This in fact turned out to be rather easy.

I am going to start a new forum thread to discuss what worked and what did not work.

-Michael

Your headless system have to
X-libs and gtk2 libs installed.

This is the list of debian packages typical Lazarus-built Linux GUI application depends.
It is useful in sense - what to download from public repositories. The name of packages contain project name.

libatk1.0-0 (>= 1.12.4),
libc6 (>= 2.2.5),
libcairo2 (>= 1.2.4),
libgcc1 (>= 1:4.1.1),
libgdk-pixbuf2.0-0 (>= 2.22.0),
libglib2.0-0 (>= 2.12.0),
libgtk2.0-0 (>= 2.24.0),
libpango1.0-0 (>= 1.14.0),
libx11-6

this is a list of libraries on which typical Lazarus-built Linux GUI application depends.

libatk1.0-0 - GTK2 accessibility toolkit
libc6 - LIBC
libcairo2 - Cairo
libexpat1 - XML parser
libffi5 - foreign function interface
libfontconfig1 - fontconfig - this depends on freetype, libexpat and zlib libfreetype6
libgdk-pixbuf2.0-0 - GDK pixbuffers
libglib2.0-0 - GNOME-lib
libgtk2.0-0 - GTK
libpango1.0-0 - pango
libpcre3 - perl compatible regexp
libpixman-1-0 - pixel manipulator for X and Cairo
libpng12-0 - PNG support
libselinux1 - LIBC depencence, on tiny distros may absent libx11-6 - XLIB
libxau6 - //-
libxcb1
libxcb-render0
libxcb-shm0
libxcomposite1
libxcursor1
libxdamage1
libxdmcp6
libxext6
libxfixes3
libxi6
libxinerama1
libxrandr2
libxrender1
zlib1g - ZLib

Actual list for your tiny system may be significantly smaller. For instance libselinux1 may disappear as soon it is not supported in your distribution.

Btw what says ldd for your cross-compiled binary at your target system?

So you have to build them with cross-compiler and copy to your headless system.

Is it so painful to run at your headless system GDB server - and at client - full Lazarus connected to that GDB?

But in both cases Xlibs and gtk2 libs have to be installed at target system.

regards,
Anton

Anton Kavalenka wrote

X-libs and gtk2 libs installed.

This is what I did suppose.

Unfortunately the Linux distribution does not not support Debian (apt-get) packages, but only QNS ".qpkg" and Optware ".ipkg" packages. I'll take a look if something like "X-lib" and "gtk2" is provided by Optware. I already have been able to install fpc by manually downloading, extracting and "distributing" the Debian fpc package. But with the count of packages you list in your message, this does not make much sense. Especially it might be very tedious to find out all the dependencies.

Btw what says ldd for your cross-compiled binary at your target system?

I did not yet try to cross-compile anything, but I happily did install fpc.

Is it so painful to run at your headless system GDB server - and at client - full Lazarus connected to that GDB?

I don't know. This in fact is what I initially suggested (as I do similar "embedded" remote-gdb debugging using a Target PCB connected via a JTAG adapter and Eclipse on the PC), but in fact remote gdb does not seem not to be very "officially" supported by Lazarus.

But in both cases Xlibs and gtk2 libs have to be installed at target system.

Not if the target project does not have a GUI. (This in fact is what I intend to do.)

Thanks a lot,
-Michael

Dependencies have to be resolved by package manager. Just find the equivalent packages.

> Btw what says ldd for your cross-compiled binary at your target system? I did not yet try to cross-compile anything, but I happily did install fpc.

So copy there lazarus and try to build it. At least no-gui lazbuild would be built and you'd be able to compiler LCL applications.

How do you suppose running Lazarus in remote X without X-libs and GTK2?

Only nogui widgetset won't require X-libs and GTK2.

Thanks a lot, -Michael

regards,
Anton

Anton Kavalenka wrote

Dependencies have to be resolved by package manager. Just find the equivalent packages.

No chance: No such packages on Optware:
http://www.dd-wrt.com/wiki/index.php/Quick_list_of_Optware_packages

So copy there lazarus and try to build it. At least no-gui lazbuild would be built and you'd be able to compiler LCL applications.

fpc already works, Lazarus will need a GUI which is not available.

How do you suppose running Lazarus in remote X without X-libs and GTK2?

I understood that you suggested not "remote GUI" but "remote debugging" (i.e. using a "gdb stub" on the target and having the gdb used by Lazarus on a PC attache to the stub via ssh), here you don't need any GUI on the target when debugging command-line tools.

Only nogui widgetset won't require X-libs and GTK2.

I am just up to doing command-line tools that don't have a TApplication instance (aka "widgetset") at all. the "nogui widgetset" is not helpful anyway, as it does not provide an event queue to allow for things like TTimer and thread->mainthread signaling.

-Michael

So complex approach for such simple task.

Just plain old ObjectPascal:

thread1:
lst:TThreadList;
getmem(pMsg,sizeof(pMessageStruct^));
// init message fields
lst.Add(pMsg);
thread2:
ll:=lst.Lock;
try
   pMessage:=ll[0];
// do something with message
   freemem(pMessage)
   ll.delete(0);
finally
   lst.Unlock;
end;

g)

Seemingly everybody forgot about fp, which AFAIK has a very decent TUI (Text based user interface) and can work locally with gdb on a system that does not offer a GUI.

I never used it, but years ago I use Borland/Turbo Pascal for rather simple stuff, and colleagues of mine create very complex programs with same.

I suppose fp can be used nicely on a headless ARM device via telnet or ssh.

-Michael

Yes, but as I said earlier in the thread ARM is the only platform that I've not got libgdb compiled for, and Jonas (I think) said it wasn't surprising in view of the number of ARM variants.

Mark Morgan Lloyd wrote

Yes, but as I said earlier in the thread ARM is the only platform that I've not got libgdb compiled for, and Jonas (I think) said it wasn't surprising in view of the number of ARM variants.

I learned that Lazarus is supposed to run on a Raspbery Pi. So I suppose fp will run and be able to work with gdb, too.

I am not sure about the difference in ARM-flavors between Raspberry Pi and QBNNAP, though (the two devices I mentioned in the initial message).

-Michael

In our previous episode, Michael Schnell said:

Afaik raspberry pi two alone counts as two favours. The basic Debian armv5 eabi version, and the armv6 vfp(2?) Raspbian.

Marco van de Voort wrote

Afaik raspberry pi two alone counts as two favours. The basic Debian armv5 eabi version, and the armv6 vfp(2?) Raspbian.

Does the Lazarus Debian package automatically detect the ARM flavor and behave appropriately ?

-Michael

In our previous episode, Michael Schnell said:

> Afaik raspberry pi two alone counts as two favours. The basic Debian armv5 > eabi version, and the armv6 vfp(2?) Raspbian. Does the Lazarus Debian package automatically detect the ARM flavor

I do not understand. There is no such thing as an universal arm package. So there is no "the" lazarus debian package for arm.

You need all code (Pascal or otherwise) compiled for your respective flavor.

Afaik Debian supports armv5 softfp and armv7 "hardfp" versions (which are downloadable as distinct architectures).

As an armv6, the very popular RPi falls in the hole between them, people set up a 3 flavour, raspbian that is armv6 hf based.

In theory, the apt-get of one of these distributions should bring in a Lazarus version compiled for that version.

On my armv5 devices I only run fpc till now (not full lazarus), but that works fine (apt-get on my wheezy got me 2.6.0 iirc)

On my rpi with raspbian (there is no real reason to run anything else), lazarus afaik installs fine with apt-get.

Marco van de Voort wrote

I do not understand. There is no such thing as an universal arm package. So there is no "the" lazarus debian package for arm.

Of course you are right, but to the user it looks like. I suppose apt-get and friends is installed with the distribution that of course does know the system is it meant to run on.

Now the user just does "apt-get install fpc" or similar and after that fpc should be usable.

So the apt-get installation seems to select the correct package for the flavor.

What I meant is: the fpc package(es) seem to be provided by the fpc team. To they provide multiple of them (I only found a single one) here:

http://packages.debian.org/squeeze/armel/fp-compiler/download -> http://ftp.de.debian.org/debian/pool/main/f/fpc/fp-compiler_2.4.0-2_armel.deb

so I supposed it would contain the necessary stuff for all supported flavors. But maybe I did not look hard enough.

Thanks,
-Michael

Having a working GDB and a working debugger in the fp IDE are two different things, because unlike Lazarus the fp IDE does not use the command line based interface, but uses a library version of GDB which is AFAIK since some versions no longer compiled by default... (and might not be compiled for ARM at all...)

Regards,
Sven

Hi,

Armel means armv5te softfp for fpc as the name of the package indicates. On newer processors you might use vfpv2, but this requires recompilation of the rtl. Only fpc trunk supports armhf. Any precompiled package on the internet is likely to be armel/softfp.

There is a separate package for arm-linux-armhf on the ftp at the moment (ftp://ftp.freepascal.org/pub/fpc/snapshot/v27/arm-linux-armhf vs. ftp://ftp.freepascal.org/pub/fpc/snapshot/v27/arm-linux-armel).

Note that if you use default installation paths, one will overwrite files from the other.

Short story: make sure to install and use the correct compiler.

Long story: The armel/armhf distinction is made by linux user space. The kernel is oblivious to that, i.e. armel statically linked binaries run on armhf user space too.

You can use an *armel fpc* trunk compiler on armhf systems to generate *armhf* binaries *if* you make sure that the correct ppu's are used. And you pass the correct options to generate armhf code. You can bootstrap an armhf compiler with the armel compiler.

There may be issues with the kernel regarding emulation of some obsolete instructions though. armhf mandates armv7 processors, but for fpc, armel is compiled for the armv5te processors with softfp support. This means that an armel binary compiled with fpc will e.g. use the obsolete "swp" instruction that is emulated by the kernel. However if you don't compile the kernel with emulation for the swp instruction turned on, any (fpc) executable that uses it will crash.

Additionally, what may confuse the situation further, at least on debian you can install both armel and armhf libraries side-by-side in a multiarch (like x86/amd64 on intel) configuration. I do not know how other distros handle this. I assume most of them only support armhf - so when compiling for them on them, the armhf trunk compiler may be preferable.

I do not know what is used/installed on raspbian - since it is debian it will likely use the multiarch solution and its binaries are armel.

Another side note: armel and armhf indicate how floating point values are passed. Armel means that all floating point values are passed in integer registers always, armhf means that fp values are generally passed in floating point registers. The softfp/vfpv2 distinction for armel indicates how the fp operations are performed. Softfp means that all fp operations are performed by software, vfpv2 means that fp operations are performed by the hardware. Although fp values are still passed in integer registers, they're copied to fp registers before performing the operation. From an ABI point of view softfp and vfpv2 are compatible. However, vfpv2 executables will crash if run on a processor not having vfpv2 hardware. You're on your own selecting the correct code path.

There is no 2.6.x armhf compiler. There are no plans to backport these changes afaik.

Thomas

I see.

I'll ask my colleague who said that Lazarus would "run" on his RPi if he in fact used the debugger.

From your mail it seems less likely that the fp can use the debugger that that Lazarus can :-( , as a working command line gdb comes with gcc and its availability should be rather "standard".

-Michael

Thomas Schatzl wrote

Short story: make sure to install and use the correct compiler.

Yep. The one I installed from the Debian squeeze package was able to successfully compile a hello world program. So it (1) does run and (2) does not compile complete nonsense. Its a beginning at least :-) .

Nonetheless I'll follow you suggestion to use the "tar" distribution. But how to do this in full accordance with the ARM flavor.

I'll work through you other comments when at home. (The QNAP is part of my home server equipment) ...

Thanks a lot !
-Michael

Yes, it's much more easy to setup Lazarus' debugger correctly (no matter if locally or remote) than to setup fp's debugger, because the latter needs to be compiled correctly for this...

Regards,
Sven

Thomas Schatzl wrote

Any precompiled package on the internet is likely to be armel/softfp.

My favorite would be to install all "packages" (rtl, fcl, ...) as source files (like "trunk") and have them compiled on demand with the project make. I do know that Lazarus does this with the LCL, but I don't know how to configure an "fpc project" in that way (in fact I don't even know if there are such things like "fpc packages" and "fpc projects". for compiling my Lazarus-inherited "project" I just did "fpc heiz.lpr"

-Michael

Sven is trying to make the point that the fp IDE and Lazarus use the debugger completely differently: fp (as I've said at least twice) uses libgdb which doesn't (to the best of my knowledge) run on ARM, Lazarus talks to standard gdb.

From your mail it seems less likely that the fp can use the debugger that that Lazarus can :-( , as a working command line gdb comes with gcc and its availability should be rather "standard".

Lazarus is OK with the GDB on all platforms I've tested including ARM, except that getting down to the register level can be a bit problematic on some systems: Martin's rather chasing a moving target.

I did understand Svens wording (see my answer to his other mail). Nonetheless I am interested in my colleague's experiences with Lazarus on the RPi, while for me the Target is the QNAP that might be rather different from RPi regarding ARM flavor and Linux distribution.

-Michael

shouldn't the compiler work for ARMv4(T) ARM architectures as well?

Regards, Bernd.

In our previous episode, Thomas Schatzl said:

There is no 2.6.x armhf compiler. There are no plans to backport these changes afaik.

Afaik Mazen created a backport patch for the debian port. It is not merged in fixes_2_6, but it is available as a debian specific patch in fpcbuild of 2.6.x, to be applied while deb building (install/debian/patches/armhf*)

In our previous episode, Michael Schnell said:

If the kernel is very old (.28), or you see "montavista" somewhere, it is probably armv5 oabi.

It's better to compile "packages" like rtl and fcl only once, because
1. some units (especially System.pp) require special options, include paths, etc (we supply makefiles for a reason)
2. if you compile your project with debug options you'll step into rtl/fcl/etc. sources each time you debug (and this can get very annoying if it jumps into e.g. the lowlevel dynamic array handling routines)

Regards,
Sven

Hi,

Armv4(t) is supported by the compiler - just like any other of the hundreds of supported ARM configurations - but the fpc team relies on bug reports (as usual, preferably with fix) from the community for them. Nobody is going to intentionally break or remove support for them.

On the other hand, arm/linux the machines that actually run and test the compiler daily include armv5te/softfp (fixes+trunk), armv7a/vfpv3 (trunk) and armv7a/armhf (trunk) only.

So if some breaking change creeps in, it will be detected the next day and fixed immediately (in theory :)

From these, snapshots for only the first and last variants are put on

the ftp.

Hth,
Thomas