"Bo Berglund" wrote

OK, I have now subscribed to the fpc-other list. Hopefully I can ask "stupid" fpc usage questuions there...

If it would be a FPC specific usage question then it would be a bad idea to post it to fpc-other. However as others have already stated accessing GPIOs on RPi is non specific to FPC and thus it doesn't need to be on fpc-pascal or even fpc-devel.

(any answers please to fpc-other only, I've added it as CC ;) )

Regards,
Sven

If it would be a FPC specific usage question then it would be a bad idea to

post it to fpc-other.

However as others have already stated accessing GPIOs on RPi is non

specific to FPC and thus it doesn't need to be on fpc-pascal or even fpc-devel.

OK, I understand.
I have researched a bit more now given the input I received. Apparently on a Raspberry Pi there are several defined user groups with specific permissions on the /dev/xxx device files. It seems like the user pi is member of a lot of these groups and thus would not really need root to run a program accessing the hardware. However, when I look at the unit pigpio.pas I found in the lazarus wiki following a link in one of the responses I got I see this:

function TIoDriver.MapIo: boolean;
begin
 Result := True;
 fd := fpopen('/dev/mem', O_RdWr or O_Sync); // Open the master /dev/memory
device
  if fd < 0 then
  begin
    Result := False; // unsuccessful memory mapping
  end;
 //
end;

Notice that the file used is /dev/mem

I don't know if there exists a user group named mem, but in any case the user pi is not member of any such group.
Could this be the cause for root to be required?

~ $ groups pi
pi : pi adm dialout cdrom sudo audio video plugdev games users input netdev spi i2c gpio

I asked a similar question in the Raspberry Pi forum and got a reply telling me to modify this to become:

fd := fpopen('/dev/gpiomem', O_RdWr or O_Sync);

While writing this the final compile of lazarus just finished (I have started from scratch using Raspbian Jessie and installed trunk of both fpc and lazarus from svn).
So now I will soon be able to check this....

Best Regards,

Bo Berglund

No, if you do

$ ls -l /dev/mem
crw-r----T 1 root kmem 1, 1 Jan  1  1970 /dev/mem

I'll step through those bits in stages. First, I've prefixed the ls command with $ since this is the prompt that was displayed. You don't enter that, it's just "unixspeak" shorthand showing that the command was entered by an unprivileged user.

Looking at the response, c shows that the thing you're looking at represents a character device. After that you get permissions: the user that owns it has rw- (i.e. read, write, no execute), the group has r-- (read only) and others have --- (i.e. no access at all). Skipping a bit, the owner is root and the group that has limited access is kmem.

If you look in /etc/group, you'll probably see that no users are in the kmem group. The RPi probably has something in the GUI to add/remove users from groups and that should be used if possible, but otherwise you can do it by editing BOTH /etc/group and /etc/gshadow CAREFULLY so that you see something like

kmem:x:15:pi

and

kmem:*::pi

respectively. DO NOT GET THIS WRONG, A SCREWED FILE HERE WILL LOCK YOU OUT.

Look, I've not got much time but going back to another point. The example at
http://wiki.freepascal.org/Lazarus_on_Raspberry_Pi#1._Native_hardware_access shows the /sys tree being manipulated to get access to GPIO pins, and this sort of thing can be the easiest way to start off since you can twiddle things by hand. So initially in /sys/class/gpio we've got

$ ls -l
total 0
-rwxrwx--- 1 root gpio 4096 Jan 1 1970 export
lrwxrwxrwx 1 root gpio 0 Jan 1 1970 gpiochip0 -> ... -rwxrwx--- 1 root gpio 4096 Jan 1 1970 unexport

If I now do

$ echo '17' >export

it creates a new entry

lrwxrwxrwx 1 root gpio 0 Oct 10 13:18 gpio17 -> ...

If I cd into gpio17 there are various things exposed, /but/ you'll see that they're owned by root... that's going to be a problem for production code but is still OK for getting things working by hand.

Switch to root using su [root password here] or sudo su [your password here] as appropriate. Note password prompt now ends in #

# cat direction
in
# echo 'out' >direction
# cat direction
out

and so on.

I'll try to keep an eye on this ML, but our gateway rejects quite a lot of stuff /particularly/ if it's formatted as HTML or has an attachment.

You can add any user to any group you like, by using the groupadd program in the terminal. For example,
usermod -a -G audio pi
would add the pi user to the audio group, allowing them to use audio functions without having to be root or use sudo for the access. Of course, the usermod command needs to be run as root, either with sudo, or as being logged in as root
If you can figure out what group the io pins are in, this could solve your problem.

Thanks,
I have come a lot further now, in fact I am done with the basic reasearch on how to do the I/O.
What I found is that the pigpio.pas file found in the lazarus wiki needs some slight modifications
and then it is perfectly OK to use. No need for any bigger driver than this to do the RPi2 I/O.

I have added a define for RPi2 and used it thus:

[code]
interface
// The following option controls whether the code is optimized for Raspberry
PI 2.
// Added 2015-10-10 by Bo Berglund following web advice to get it working on
the Pi2 hardware
{$DEFINE RPi2}
...
const
  REG_GPIO = {$IFDEF RPi2} $3F000 {$ELSE} $20000 {$ENDIF};//bcm2835/bcm2836
gpio register
...
  // Mapping the RPi GPIO pin functions to GPIO I/O, should be here rather
than in user code
  RPI_P3  =  2; //GPIO2
  RPI_P5  =  3; //GPIO3
  RPI_P7  =  4; //GPIO4
  RPI_P8  = 14; //GPIO14
  RPI_P10 = 15; //GPIO15
  RPI_P11 = 17; //GPIO17
  RPI_P12 = 18; //GPIO18
  RPI_P13 = 27; //GPIO27
  RPI_P15 = 22; //GPIO22
  RPI_P16 = 23; //GPIO23
  RPI_P18 = 24; //GPIO24
  RPI_P19 = 10; //GPIO10
  RPI_P21 =  9; //GPIO9
  RPI_P22 = 25; //GPIO25
  RPI_P23 = 11; //GPIO11
  RPI_P24 =  8; //GPIO8
  RPI_P26 =  7; //GPIO7
...
function TIoDriver.MapIo: boolean;
begin
 Result := True;
 {$IFDEF RPi2}
   fd := fpopen('/dev/gpiomem', O_RdWr or O_Sync); // Open the master
/dev/memory device
 {$ELSE}
   fd := fpopen('/dev/mem', O_RdWr or O_Sync); // Open the master
/dev/memory device
 {$ENDIF}
  if fd < 0 then
  begin
    Result := False; // unsuccessful memory mapping
  end;
 //
end;
[/code]

With this in place the standard user pi will have access to the needed /dev/gpiomem device and no root is required.
I have successfully used several ports to drive a relay board now.

Best Regards,

Bo Berglund

This is good to know. I've not tried using fpc to read io pins on the pi yet, but it's certainly nice to have the option. I will keep this post for when the inevidable occurs, and I decide to use fpc for a project on my pi. Honestly, I didn't even realize it would be possible to read the io pins from fpc, so I didn't event hink about trying it. This opens some nice possibilities. Thanks for the post.