Re: [fpc-devel] "embedded" again
Hi, On Mon, 2013-01-21 at 17:27 +0100, Bernd Mueller wrote: > Thomas Schatzl wrote: > >> > >> 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. > > > > Armel means armv5te softfp for fpc as the name of the package indicates. > > shouldn't the compiler work for ARMv4(T) ARM architectures as well? 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 21.01.2013 17:01, Michael Schnell wrote: On 01/21/2013 04:35 PM, 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" 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
In our previous episode, Michael Schnell said: > 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) ... If the kernel is very old (.28), or you see "montavista" somewhere, it is probably armv5 oabi. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
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*) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Thomas Schatzl wrote: 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. Armel means armv5te softfp for fpc as the name of the package indicates. shouldn't the compiler work for ARMv4(T) ARM architectures as well? Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/21/2013 05:10 PM, Mark Morgan Lloyd wrote: 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 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Michael Schnell wrote: On 01/21/2013 04:18 PM, Sven Barth wrote: 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...) I see. I'll ask my colleague who said that Lazarus would "run" on his RPi if he in fact used the debugger. 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/21/2013 04:35 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Am 21.01.2013 16:39, schrieb Michael Schnell: On 01/21/2013 04:18 PM, Sven Barth wrote: 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...) 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". 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/21/2013 04:35 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/21/2013 04:18 PM, Sven Barth wrote: 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...) 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Hi, On Mon, 2013-01-21 at 15:42 +0100, Michael Schnell wrote: > On 01/21/2013 03:32 PM, 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Am 21.01.2013 14:04, schrieb Michael Schnell: On 01/21/2013 01:55 PM, 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/21/2013 03:32 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/21/2013 02:13 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
In our previous episode, Michael Schnell said: > 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). Afaik raspberry pi two alone counts as two favours. The basic Debian armv5 eabi version, and the armv6 vfp(2?) Raspbian. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/21/2013 01:55 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Michael Schnell wrote: 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. 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 markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/17/2013 10:01 AM, Michael Schnell wrote: 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
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). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Michael Schnell wrote: On 01/16/2013 05:31 PM, 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'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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/16/2013 12:03 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/16/2013 05:31 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 1/16/2013 04:57, Marco van de Voort wrote: In our previous episode, waldo kitty said: Otherwise I'd agree :) On old hardware, maybe, but these days ? please define "old hardware"... PII 300mhz is "too old"? PIII 800mhz? and of course, how much RAM would be considered "not enough"? Anything older than the corporate writeoff period (3-5 years) 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 :/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
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 -- Luca ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Hi, On Wed, 2013-01-16 at 12:55 +0100, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/16/2013 12:03 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/16/2013 12:03 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
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 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Hi, On Wed, 2013-01-16 at 11:06 +0100, Michael Schnell wrote: > On 01/15/2013 12:01 PM, Michael Van Canneyt wrote: > > > > On old hardware, maybe, but these days ? > > > The topic of the thread is "embedded". > > Here > In many Linux tool config scripts the keyword "embedded" even still is > used as a synonym for MMU-less. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Michael Schnell wrote: On 01/15/2013 12:01 PM, Michael Van Canneyt wrote: On old hardware, maybe, but these days ? The topic of the thread is "embedded". Here In many Linux tool config scripts the keyword "embedded" even still is used as a synonym for MMU-less. 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/15/2013 12:01 PM, Michael Van Canneyt wrote: On old hardware, maybe, but these days ? The topic of the thread is "embedded". Here In many Linux tool config scripts the keyword "embedded" even still is used as a synonym for MMU-less. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
In our previous episode, waldo kitty said: > >> Otherwise I'd agree :) > > > > On old hardware, maybe, but these days ? > > please define "old hardware"... PII 300mhz is "too old"? PIII 800mhz? and of > course, how much RAM would be considered "not enough"? Anything older than the corporate writeoff period (3-5 years) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Develop on-device [Was: Re: [fpc-devel] "embedded" again]
On 01/15/2013 01:04 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
waldo kitty wrote: On 1/15/2013 06:01, Michael Van Canneyt wrote: On Tue, 15 Jan 2013, Sven Barth wrote: Am 15.01.2013 11:52, schrieb Michael Van Canneyt: That is a weird assumption. I would go for the second one, hands down... I wouldn't if the second one is significantly slower than the first one. Otherwise I'd agree :) On old hardware, maybe, but these days ? 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 markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 1/15/2013 06:01, Michael Van Canneyt wrote: On Tue, 15 Jan 2013, Sven Barth wrote: Am 15.01.2013 11:52, schrieb Michael Van Canneyt: That is a weird assumption. I would go for the second one, hands down... I wouldn't if the second one is significantly slower than the first one. Otherwise I'd agree :) On old hardware, maybe, but these days ? please define "old hardware"... PII 300mhz is "too old"? PIII 800mhz? and of course, how much RAM would be considered "not enough"? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
In our previous episode, Thomas Schatzl said: > > >> ? > > >> > > >> That is a weird assumption. I would go for the second one, hands down... > > > > > > I wouldn't if the second one is significantly slower than the first one. > > > Otherwise I'd agree :) > > > > 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. > > 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. Sheeva, 1.2GHz armv5 iirc +/- 30mins. (fixes branch). (512MB USB HDD) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Develop on-device [Was: Re: [fpc-devel] "embedded" again]
On 01/15/2013 01:15 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Develop on-device [Was: Re: [fpc-devel] "embedded" again]
Am 15.01.2013 12:21, schrieb Michael Schnell: On 01/15/2013 12:01 PM, 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Develop on-device [Was: Re: [fpc-devel] "embedded" again]
Michael Schnell wrote: On 01/15/2013 12:29 PM, 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). 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). 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 ! 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Develop on-device [Was: Re: [fpc-devel] "embedded" again]
On 01/15/2013 12:29 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Develop on-device [Was: Re: [fpc-devel] "embedded" again]
Michael Schnell wrote: On 01/15/2013 12:01 PM, 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. 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 markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/15/2013 12:07 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Develop on-device [Was: Re: [fpc-devel] "embedded" again]
On 01/15/2013 12:01 PM, 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. 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. 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:for http://www.turbocontrol.com/easyfpgui.htm 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 ? Again: sudo apt-get install lazarus 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Hi, On Tue, 2013-01-15 at 11:05 +, Mark Morgan Lloyd wrote: > Sven Barth wrote: > > >> "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... > > > > I wouldn't if the second one is significantly slower than the first one. > > Otherwise I'd agree :) > > 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. > 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Develop on-device [Was: Re: [fpc-devel] "embedded" again]
Am 15.01.2013 12:06, schrieb Thomas Schatzl: 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Hi, On Tue, 2013-01-15 at 12:00 +0100, Michael Schnell wrote: > On 01/15/2013 11:52 AM, 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 ;-) ). 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Am 15.01.2013 12:01, schrieb Michael Van Canneyt: On Tue, 15 Jan 2013, Sven Barth wrote: Am 15.01.2013 11:52, schrieb Michael Van Canneyt: On Tue, 15 Jan 2013, Michael Schnell wrote: On 01/15/2013 11:22 AM, Henry Vermaak wrote: On Tue, Jan 15, 2013 at 10:45:29AM +0100, 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". 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. 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... I wouldn't if the second one is significantly slower than the first one. Otherwise I'd agree :) On old hardware, maybe, but these days ? 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Develop on-device [Was: Re: [fpc-devel] "embedded" again]
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Sven Barth wrote: "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... I wouldn't if the second one is significantly slower than the first one. Otherwise I'd agree :) 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Develop on-device [Was: Re: [fpc-devel] "embedded" again]
Hi, On Tue, 2013-01-15 at 10:45 +0100, Michael Schnell wrote: > On 01/14/2013 08:31 PM, Paul Breneman wrote: > > > > 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! > > 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 ? 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. > 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. 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. > 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 instal
Re: [fpc-devel] "embedded" again
On Tue, 15 Jan 2013, Sven Barth wrote: Am 15.01.2013 11:52, schrieb Michael Van Canneyt: On Tue, 15 Jan 2013, Michael Schnell wrote: On 01/15/2013 11:22 AM, Henry Vermaak wrote: On Tue, Jan 15, 2013 at 10:45:29AM +0100, 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". 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. 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... I wouldn't if the second one is significantly slower than the first one. Otherwise I'd agree :) On old hardware, maybe, but these days ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/15/2013 11:52 AM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Am 15.01.2013 11:52, schrieb Michael Van Canneyt: On Tue, 15 Jan 2013, Michael Schnell wrote: On 01/15/2013 11:22 AM, Henry Vermaak wrote: On Tue, Jan 15, 2013 at 10:45:29AM +0100, 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". 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. 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... I wouldn't if the second one is significantly slower than the first one. Otherwise I'd agree :) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On Tue, 15 Jan 2013, Michael Schnell wrote: On 01/15/2013 11:22 AM, Henry Vermaak wrote: On Tue, Jan 15, 2013 at 10:45:29AM +0100, 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". 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. 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/15/2013 11:22 AM, Henry Vermaak wrote: On Tue, Jan 15, 2013 at 10:45:29AM +0100, 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". 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Michael Schnell wrote: 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 ? 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On Tue, Jan 15, 2013 at 10:45:29AM +0100, 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 trouble at all. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/14/2013 08:31 PM, Paul Breneman wrote: 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! 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. 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 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 hardware at all. In both cases I still think the optimum way to do the hardware specific software development is remote debugging. Thanks for your comments. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Michael Schnell wrote: On 01/11/2013 12:37 PM, 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 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Michael Schnell wrote: On 01/11/2013 12:30 PM, 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. A Slug /does/ have an MMU: otherwise how do you think it manages to run a standard Linux distro? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Sven Barth wrote: Am 11.01.2013 12:02, schrieb Michael Schnell: On 01/11/2013 11:51 AM, Mark Morgan Lloyd wrote: 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). 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. I suspect that Mark means X11 forwarding, thus running Lazarus on the board, but displaying it and interacting with it on a different PC. 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/11/2013 12:37 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/11/2013 12:30 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/11/2013 12:07 PM, 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
Am 11.01.2013 12:02, schrieb Michael Schnell: On 01/11/2013 11:51 AM, Mark Morgan Lloyd wrote: 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). 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 11-1-2013 12:07, Michael Schnell wrote: I don't see how I could install Lazarus on the QNAP, as there is no GUI / Widget system at all. I was told that on the Raspberry Pi, QT can be run, but that it is dead slow. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel On the 256 model 2: yes, on the 512 model 2: No, acceptable. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 11-1-2013 11:54, Jy V wrote: 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 ? 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) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/11/2013 11:54 AM, 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 system at all. I was told that on the Raspberry Pi, QT can be run, but that it is dead slow. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
On 01/11/2013 11:51 AM, Mark Morgan Lloyd wrote: 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). 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
> 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 ? > 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "embedded" again
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). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] "embedded" again
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
