Recent

Author Topic: Lazarus / RaspberyPi Hardware Library  (Read 90512 times)

woodengineer

  • New Member
  • *
  • Posts: 20
Lazarus / RaspberyPi Hardware Library
« on: June 29, 2012, 02:58:47 am »
Hello,
please find attached a wrapper unit for Gordon Henderson's
wiringPi C library (https://projects.drogon.net/raspberry-pi/wiringpi) and a little Lazarus test program.
This library allows access to the RaspberryPi's GPIO pins as well as the PWM pin.
The RaspberryPi is an inexpensive $25 SBC that runs linux. Check it out at http://www.raspberrypi.org.
BTW Lazarus runs quite well on the Pi.
Have fun, I know I will! :D
Alex
« Last Edit: June 30, 2012, 03:30:01 pm by woodengineer »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11352
  • FPC developer.
Re: Lazarus / RaspberyPi Hardware Library
« Reply #1 on: June 29, 2012, 10:58:25 am »
Which distro did you run Lazarus with?

woodengineer

  • New Member
  • *
  • Posts: 20
Re: Lazarus / RaspberyPi Hardware Library
« Reply #2 on: June 29, 2012, 03:45:19 pm »
Hello,
I am running ArchLinux, XFCE4, fpc 2.6 and Lazarus 0.9.30.4.
Got the fpc arm binaries from the freepascal website and then compiled Lazarus from source.
Works quite nice, haven't found any problems, just don't expect 2sec compile times.
But compared to e.g. Mono it fly's.
A "Build all" of this posts Hardware library sample app takes about 5sec (console).
A Gui app with a form and a button on it about  1:30sec and about 50sec on subsequent builds .
Also played around with Geany and FpGui which is faster, but not as comfortable as Lazarus.
Hope this helps.

Alex

DirkS

  • Sr. Member
  • ****
  • Posts: 251
Re: Lazarus / RaspberyPi Hardware Library
« Reply #3 on: June 29, 2012, 05:35:30 pm »
Marco,

FYI: I have FPC / Laz running on the debian wheezy distro for armel (http://www.raspberrypi.org/archives/1435 / http://www.raspberrypi.org/phpBB3/viewtopic.php?f=50&t=8071).
I just used apt-get to install both. Versions: FPC 2.6.0-3 (2012.05/07); Laz 09.30.4-1 Rev 35971

I tried to use BigChimp's fpcup (using fpcup-linux-armel from https://bitbucket.org/reiniero/fpcup), but that did not work (or not completely).

Gr.
Dirk.

ludob

  • Hero Member
  • *****
  • Posts: 1173
Re: Lazarus / RaspberyPi Hardware Library
« Reply #4 on: June 29, 2012, 06:02:35 pm »
Quote
I tried to use BigChimp's fpcup (using fpcup-linux-armel from https://bitbucket.org/reiniero/fpcup), but that did not work (or not completely).
Do you stilll have any details or log files of what went wrong?
I've only tested it with --only=fpc,lazarus since the default install tries to install too much for my small arm system.

jwdietrich

  • Hero Member
  • *****
  • Posts: 1232
    • formatio reticularis
Re: Lazarus / RaspberyPi Hardware Library
« Reply #5 on: June 30, 2012, 02:17:25 pm »
I am happy to read that Lazarus has arrived at the Pi.
function GetRandomNumber: integer; // xkcd.com
begin
  GetRandomNumber := 4; // chosen by fair dice roll. Guaranteed to be random.
end;

http://www.formatio-reticularis.de

Lazarus 2.2.6 | FPC 3.2.2 | PPC, Intel, ARM | macOS, Windows, Linux

DirkS

  • Sr. Member
  • ****
  • Posts: 251
Re: Lazarus / RaspberyPi Hardware Library
« Reply #6 on: July 01, 2012, 06:45:49 am »
Quote
I tried to use BigChimp's fpcup (using fpcup-linux-armel from https://bitbucket.org/reiniero/fpcup), but that did not work (or not completely).
Do you stilll have any details or log files of what went wrong?
I've only tested it with --only=fpc,lazarus since the default install tries to install too much for my small arm system.
It's actually an fpc error (ran fpcup with --only=fpc,lazarus):
Quote
make[3]: Entering directory `/home/pi/fpc/utils/fpcmkcfg'
/bin/mkdir -p units/arm-linux
__missing_command_DATA2INC -b -s fppkg.cfg fppkg.inc fppkg
make[3]: __missing_command_DATA2INC: Command not found
make[3]: *** [fppkg.inc] Error 127
make[3]: Leaving directory `/home/pi/fpc/utils/fpcmkcfg'
make[2]: *** [fpcmkcfg_all] Error 2
make[2]: Leaving directory `/home/pi/fpc/utils'
make[1]: *** [utils_all] Error 2
make[1]: Leaving directory `/home/pi/fpc'
make: *** [build-stamp.arm-linux] Error 2
make: Leaving directory `/home/pi/fpc'

Info: Running make install for FPC:
Note that fpcup *does* continue with 'make install', which it probably should not do (?).
I killed the procedure at this point and the fpcup log file does not give any useful info.

Gr
Dirk
« Last Edit: July 01, 2012, 06:51:34 am by DirkS »

rmudryk

  • Newbie
  • Posts: 6
Re: Lazarus / RaspberyPi Hardware Library
« Reply #7 on: August 12, 2012, 04:17:25 am »
Did a fresh download of weezy 7-15 from the raspberry pi website http://downloads.raspberrypi.org/images/raspbian/2012-07-15-wheezy-raspbian/2012-07-15-wheezy-raspbian.zip 

sudo apt-get update
sudo apt-get upgrade

sudo apt-get install fpc
sudo apt-get install lazarus
sudo apt-get install libfbclient2

this is a estimation

http://www.inprox.net/pi/Raspberry-PI-Lazarus.png

Rob

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11352
  • FPC developer.
Re: Lazarus / RaspberyPi Hardware Library
« Reply #8 on: August 13, 2012, 11:51:09 am »
__missing_command_DATA2INC -b -s fppkg.cfg fppkg.inc fppkg

That means

(1) you are attempting to compile a FPC without a full install of FPC.
(2) the codebase (svn checkout, unzipped source snapshot) has messed up datetime stamps


Point (1) means that you didn't fulfill the requirements to build FPC, and (2) is that you (or fpcup) didn't
even try to implement the workarounds.

(2) typically happens if you decompress a source archive made on a different OS, or do a SVN checkout on a
non standard filesystem that has different datestamp systems (like network drives), and/or use checkouts
between multiple OSes (that might have different time synchronization characteristics)
 
A workaround on *nix when bootstrapping on a new system is to "touch" the .inc files generated by data2inc and/or
other generator programs.  On Windows this is useless since touch doesn't come with windows or FPC.  Apparently FPCUP doesn't
implement it (it would require creating a list  what exactly is generated by data2inc)

ludob

  • Hero Member
  • *****
  • Posts: 1173
Re: Lazarus / RaspberyPi Hardware Library
« Reply #9 on: August 13, 2012, 01:26:09 pm »
The real problem is that fpcup starts with only a bootstrap compiler and binutils. At some stage in the make all process, data2inc is build in the fpc/utils directory and a little later fpmake calls data2inc but can't find it. Later in the make install process data2inc is copied to the fpc/bin/arm-linux directory but that is too late. Fpcup has solved this by adding the fpc/utils dir to the path before launching make. Perhaps the OP is using an older version of fpcup.

So yes it is (1) but IMHO also a shortcoming in the fpc make file.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11352
  • FPC developer.
Re: Lazarus / RaspberyPi Hardware Library
« Reply #10 on: August 13, 2012, 03:39:32 pm »
The real problem is that fpcup starts with only a bootstrap compiler and binutils. At some stage in the make all process, data2inc is build in the fpc/utils directory and a little later fpmake calls data2inc but can't find it. Later in the make install process data2inc is copied to the fpc/bin/arm-linux directory but that is too late. Fpcup has solved this by adding the fpc/utils dir to the path before launching make. Perhaps the OP is using an older version of fpcup.

So yes it is (1) but IMHO also a shortcoming in the fpc make file.

Yes and no. Of course the current state is imperfect and not terribly well documented, but the requirements are/were always clear. We hope that we can concentrate many of these requirements in fppkg/fpmake system but that is long term only.

A _full_ install is needed for automated bootstrap, but tweaking with just a cmdline compiler is possible on *nix targets with some care. (this is mainly meant to facilitate bootstrapping to a new target, and never was meant to be automable). The problem is mainly (2), while in general SVN is in a consistent state, ocassionally people make mistakes (and not check in the generated version) and some operations on checkouts can corrupt timestamps by fractions enough to select a different codepath by make. The automatic regenneration guards against that, but adds a dependency.

Some other problems are the creation of initial fpc.cfgs, symlinks (and I assume fpcup has already run into those, (2) is one of the rare ones)

FPCUP tries to do it fully automated without a full install, then it will run into exception (2). I think the workaround with fpc/utils is not correct (*) and then this will fail. If you really want to work around this, you need to touch all data2inc generated .incs.

(*) IIRC data2inc might be called in compiler/utils before data2inc is generated, and during crosscompiling a native target compiler will never reach te fpc/utils directory, only a cross compiler will.
« Last Edit: August 13, 2012, 05:18:19 pm by marcov »

fredycc

  • Sr. Member
  • ****
  • Posts: 264

BigChimp

  • Hero Member
  • *****
  • Posts: 5740
  • Add to the wiki - it's free ;)
    • FPCUp, PaperTiger scanning and other open source projects
Re: Lazarus / RaspberyPi Hardware Library
« Reply #12 on: August 13, 2012, 04:48:21 pm »
We hope that we can concentrate many of these requirements in fppkg/fpmake system but that is long term only.
I'd certainly be willing to help work on this, if only on the testing part, but I'm not sure what exactly needs to be done/what the requirements are.
Want quicker answers to your questions? Read http://wiki.lazarus.freepascal.org/Lazarus_Faq#What_is_the_correct_way_to_ask_questions_in_the_forum.3F

Open source including papertiger OCR/PDF scanning:
https://bitbucket.org/reiniero

Lazarus trunk+FPC trunk x86, Windows x64 unless otherwise specified

ludob

  • Hero Member
  • *****
  • Posts: 1173
Re: Lazarus / RaspberyPi Hardware Library
« Reply #13 on: August 13, 2012, 07:46:58 pm »
Quote
A _full_ install is needed for automated bootstrap
Quote
IIRC data2inc might be called in compiler/utils before data2inc is generated
So the "shortcoming in the fpc make file" was really an understatement.  data2inc is an internal dependency for make, created by make, but not always in time.
Quote
while in general SVN is in a consistent state, ocassionally people make mistakes (and not check in the generated version) and some operations on checkouts can corrupt timestamps by fractions enough to select a different codepath by make. The automatic regenneration guards against that, but adds a dependency.
But isn't that the wrong way around? Instead of putting internally build files under svn control and put a safeguard in place, logic says that one should only put sources under version control and build always. No more problems with different codepaths. Lazarus has a similar problem with some lrs resource files under version control.  It also happens that developers forget to regenerate them before committing the new sources with sometimes build failures as a result.
Quote
If you really want to work around this, you need to touch all data2inc generated .incs.
A touch will just fool the guard. The inc doesn't not correspond with the source if the developer forgot to regenerate them. So, touch will avoid the data2inc missing error but the outcome is a fpc that does not correspond with the sources.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11352
  • FPC developer.
Re: Lazarus / RaspberyPi Hardware Library
« Reply #14 on: August 13, 2012, 10:10:00 pm »
Quote
A _full_ install is needed for automated bootstrap
Quote
IIRC data2inc might be called in compiler/utils before data2inc is generated
So the "shortcoming in the fpc make file" was really an understatement.  data2inc is an internal dependency for make, created by make, but not always in time.

The dependency on the bootstrap is a full FPC install. A full FPC install contains data2inc. There is no shortcoming.

There is a  "cmdline compiler only" shortcut ONLY on open source *nix (since other platforms require "make" "binutils" etc) for people that know what they are doing. But that is a workaround for quick and dirty work, not an official supported solution.

The cmdline compiler-only route was never official. It just works mostly, and was somewhat documented in the buildfaq to help people keep machines up to date with minimal dependencies.

That doesn't mean that you can't think about building on the standalone compiler, but big changes in the current codebase wrt fpcmake are unlikely,
since it is both a production and declared legacy. As usual with longterm infrastructural work on the successor has stalled.

Quote
Quote
while in general SVN is in a consistent state, ocassionally people make mistakes (and not check in the generated version) and some operations on checkouts can corrupt timestamps by fractions enough to select a different codepath by make. The automatic regenneration guards against that, but adds a dependency.
But isn't that the wrong way around? Instead of putting internally build files under svn control and put a safeguard in place, logic says that one should only put sources under version control and build always.

That's something for any new system to attempt. The old system already depends on way too many externals that are immutable (starting with make)

Quote
No more problems with different codepaths. Lazarus has a similar problem with some lrs resource files under version control.  It also happens that developers forget to regenerate them before committing the new sources with sometimes build failures as a result.

Actually the filesystem thing (having sources shared between multiple OSes or on network drives, extracting archives made on different OSes that cause date rounding errors during file creation) is more common.

Quote
Quote
If you really want to work around this, you need to touch all data2inc generated .incs.
A touch will just fool the guard. The inc doesn't not correspond with the source if the developer forgot to regenerate them. So, touch will avoid the data2inc missing error but the outcome is a fpc that does not correspond with the sources.

Then your only choice is to follow the official way, and always require a proper installation.

I don't think touching is so bad. It might mask a very short transient problem in rare cases, but it will save you a lot of trouble where people have moved files across filesystem bounderies. Most of such forgotten makefile regenerations are for platforms that are still under development anyway. (which is why they go unnoticed)
« Last Edit: August 13, 2012, 10:36:45 pm by marcov »

 

TinyPortal © 2005-2018