TOPIC:

Hi All

I've converted the pigpio (see abyz.co.uk/rpi/pigpio/index.html) .h header file to be able to use from within Lazarus on the Pi/Pi2 (hopefully it should work on all models) - I was having difficulty with some of the other libraries which either haven't been updated to to the Pi2 or are limited in functionality and this one seemed to have nearly everything in it so it made more sense to try and use this one rather than fix a limited library, this one appears to have virtually everything :) .

In order to build on the Pi I had to copy a particular hard float version of libgcc.a into the same folder as the pigpio library (I've included my libgcc.a from the Pi in the zip, I found two on my Pi2 and I guess it might have been linking the wrong one - some are missing some "long long" divide functions and give errors when building) - the pigpio library uses the "rt" and pthreads libraries so I'm already linking these in using {$linklib ...} in the unit header (see attached - I've separated out the pigpio types and consts into a separate unit).

It seems to work - tbh only used some basic gpio functionality against the PiLiter board so far (shop.ciseco.co.uk/pi-liter-8-led-strip-for-the-raspberry-pi/) but it seems to work well (demo also in the attached) but only when compiled in Lazarus on the Pi2 itself. What I'd like to do is be able to cross compile via CodeTyphon. (I think) I've tried every combination of $linklib or $link with all the libraries it complains about but just can't get any application to link (and most of the libraries it complains about don't have to be specified when compiling on the Pi itself}.

On the Pi you probably need to install the pigpio library following this link; abyz.co.uk/rpi/pigpio/download.html and then copy the two pigpio .pas files from the attached zip file into the root pigpio folder as the .h and .c files - I've put my PiLiter demo in a Lazarus folder with all the demo programs Joan has included.

Anyway, can anyone advise on what the linking should look like for cross-compiling - ideally I'd like the library to be able to compile locally (as it does already) and cross-build from other platforms so whether this might need some {$ifdef...} type inclusion to link in the necessary libraries when cross-compiling but unnecessary when building locally, so there's minimal needed to get it going.

TheBlackSheep

Sir
we will test your Code but

1)-my suggestion:

Modify pigpio.pas for
-Dynamic Link to libpigpio.so (we can help on this)
-Remove linklib libgcc.a, it's NOT the same in all Debian ARM releases
-Make a test program to check the new Dynamic Link pigpio.pas loaded functions

and some links:
github.com/LeMaker/ClassA20/blob/master/GPIO.pas
github.com/askarel/hsb-scripts/blob/master/io/pigpio.pas

native pascal gpio driver implementations...

Hi Sternas

Hope you are well!

I don't think either of those two libraries will work out of the box with RasPi2 (the base GPIO has moved on a RPI2 and there's a function to call to detect what it should be now).

Joan's PIGPIO has a lot more than just GPIO stuff, PWM, Servo control (similar to servoblaster), hooks for gpio edge triggers, serial support, SPI, I2C as well as waveform support - see the PISCOPE stuff. Probably the most comprehensive library I've come across.

I guessed the inclusion of libgcc.a might be an issue but couldn't get the dynamic link to the .so to work.

TheBlackSheep

Do you want to help you with with Dynamic Link of pigpio.pas ?
I can add this as daily task to my lab programmers for tomorrow.

Just took a quick look for the libpigpio.so and couldn't see one being created/installed in the Makefile - do I understand this correctly that that effectively means that when you compile/link via the ".a" file you are building the pigpio code directly into the executable and talking directly to the hardware rather than through a shared object library?

Any assistance would be good but I wouldn't want to sidetrack your guys from time getting to CT5.3 - I (as I'm sure many others are) waiting in great anticipation for the next release

I can work with the current version I have for the minute so there's certainly no urgency unless someone else has a more comprehensive library - initially I was looking for GPIO (with edge trggers/callbacks) and Servo control specifically but I'm planning to add a display at some point and that will probably expand that requirement (serial/I2C) - it would be good to have one library that does it all.

Sir
the problem is the classic "Static Linking vs Dynamic Link"
With Static Linking you can hide external library code to your executable,
but you can't control the correct functionality of the your code.
You must Static Linking and some external library requirements like libgcc.a
which is one of the core libraries in Linux.

I and my programmers (5 "old dogs" and 6-10 new from local university ) vote for
Dynamic Link.