RE: [beagleboard] Re: Using GPIOs without Using sudo

[John Dammeyer]

BTW, caught this posting
https://forum.beagleboard.org/t/gpio-export-problem/29737

Apparently exporting twice to the same pin will cause it to go away.  If I 
understand the issue correctly.  All the more reason to test to see if it's 
already there and then not export if so.

John


> -Original Message-
> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
> Behalf Of John Dammeyer
> Sent: May-18-21 10:40 AM
> To: beagleboard@googlegroups.com
> Subject: RE: [beagleboard] Re: Using GPIOs without Using sudo
> 
> Hi Dennis,
> > Suggest
> >
> > if (not (IsPinBitSet(Pin, ExportedBitmask)
> > or IsPinBitSet(Pin, ExportDefinedBitmask)) then begin
> >
> > That way you don't waste time with the TryReadCharFromFile() if you already
> > know it was externally exported.
> 
> The ExportDefinedBitmask I created is the only extra bit available in that 
> array of bytes indexed by pin number.  But like the
> ExportedBitmask it's unknown until the system tries to read from it at which 
> point it's defined.  I added it because I didn't think any
> application has the right to unexport a pin that was already exported on 
> start up.
> 
> Even with just the 1/2 second delay, you can see the difference in speed of 
> the test application when the pin is already exported
> compared to when it's not.
> 
> 
> > >
> > >
> > I'd put the delay immediately after
> >
> >   // Wasn't exported when program started so now let's export it.
> >   if TryWriteTextToFile(FExportFileName, IntToStr(Pin)) then
> > begin
> >  SetPinBit(Pin, ExportedBitmask);
> >   *** put delay statement here  ***;
> > end;
> >
> Yes.  Could be put there too.  I'll take a closer look to see if that 
> introduces a side effect.  I had a reason for not doing it in the export
> procedure.  Just don't remember why...
> 
> >
> > >
> > >
> > >The only issue I've run into is the repeat until loop.  Seems like the 
> > >file is readable in about 100mS but fails with the write unless
> the
> > delay is 500mS.
> > >
> >
> > Which "file" (there are so many created under each exported pin) 
> 
> The initial usage of the pin must be to set the direction which then does the 
> export so that's the file I try and read from.  Trying to get
> pin value before setting direction results in a fault.
> 
> 
> >
> > It may be that the OS default for those files permits reading -- but
> > the group hasn't been changed yet so only root can write. Sometime after
> > the creation, the logic that sets up special groups runs and changes the
> > file to a group that allows you to write.
> 
> Hmm.   Maybe it's better to try and get the file attributes and then it would 
> execute the loop decrement section instead.  At the
> moment it never executes that part of the code.
> 
> In either case I just need to test that code on the Pi3 and Pi4 to make sure 
> Blinky blinks.  On the Beagle the code now makes it
> through the Reset and DIR select for the SPI bus test code but dies on the 
> IOCTL call.
> 
> The simple C code in the 
> \\BEAGLEBONE\debian\exploringBB\chp08\spi\spidev_test does work so the 
> question is what's broken in
> the pxl library?
> 
> And now that I have the Mikroe Click board rewired I have two beagles with 
> CAN bus drivers in the kennel.
> 
> I have a Click board with a SPI based RAM chip which will be the easiest to 
> interface with rather than a breadboard with an SPI
> 320x240 LCD SPI controlled display.
> 
> Baby steps eh?
> John
> 
> >
> >
> > --
> > Dennis L Bieber
> >
> > --
> > For more options, visit http://beagleboard.org/discuss
> > ---
> > You received this message because you are subscribed to the Google Groups 
> > "BeagleBoard" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to beagleboard+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/beagleboard/40a7ag9gv2635mshemm4euqic4370aodfr%404ax.com.
> 
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/011e01d74c0c%24e13144e0%24a393cea0%24%40autoartisans.com.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/016c01d74c32%24d1fe2ad0%2475fa8070%24%40autoartisans.com.

RE: [beagleboard] Re: Using GPIOs without Using sudo

[John Dammeyer]

Hi Dennis,
>   Suggest
> 
>   if (not (IsPinBitSet(Pin, ExportedBitmask)
>   or IsPinBitSet(Pin, ExportDefinedBitmask)) then begin
> 
> That way you don't waste time with the TryReadCharFromFile() if you already
> know it was externally exported.

The ExportDefinedBitmask I created is the only extra bit available in that 
array of bytes indexed by pin number.  But like the ExportedBitmask it's 
unknown until the system tries to read from it at which point it's defined.  I 
added it because I didn't think any application has the right to unexport a pin 
that was already exported on start up.

Even with just the 1/2 second delay, you can see the difference in speed of the 
test application when the pin is already exported compared to when it's not.  


> >
> >
>   I'd put the delay immediately after
> 
>   // Wasn't exported when program started so now let's export it.
>   if TryWriteTextToFile(FExportFileName, IntToStr(Pin)) then
>   begin
>  SetPinBit(Pin, ExportedBitmask);
> *** put delay statement here  ***;
>   end;
> 
Yes.  Could be put there too.  I'll take a closer look to see if that 
introduces a side effect.  I had a reason for not doing it in the export 
procedure.  Just don't remember why...

> 
> >
> >
> >The only issue I've run into is the repeat until loop.  Seems like the file 
> >is readable in about 100mS but fails with the write unless the
> delay is 500mS.
> >
> 
>   Which "file" (there are so many created under each exported pin) 

The initial usage of the pin must be to set the direction which then does the 
export so that's the file I try and read from.  Trying to get pin value before 
setting direction results in a fault.


> 
>   It may be that the OS default for those files permits reading -- but
> the group hasn't been changed yet so only root can write. Sometime after
> the creation, the logic that sets up special groups runs and changes the
> file to a group that allows you to write.

Hmm.   Maybe it's better to try and get the file attributes and then it would 
execute the loop decrement section instead.  At the moment it never executes 
that part of the code.

In either case I just need to test that code on the Pi3 and Pi4 to make sure 
Blinky blinks.  On the Beagle the code now makes it through the Reset and DIR 
select for the SPI bus test code but dies on the IOCTL call.

The simple C code in the \\BEAGLEBONE\debian\exploringBB\chp08\spi\spidev_test 
does work so the question is what's broken in the pxl library?

And now that I have the Mikroe Click board rewired I have two beagles with CAN 
bus drivers in the kennel.  

I have a Click board with a SPI based RAM chip which will be the easiest to 
interface with rather than a breadboard with an SPI 320x240 LCD SPI controlled 
display.

Baby steps eh?
John

> 
> 
> --
> Dennis L Bieber
> 
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/40a7ag9gv2635mshemm4euqic4370aodfr%404ax.com.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/011e01d74c0c%24e13144e0%24a393cea0%24%40autoartisans.com.

RE: [beagleboard] Re: Using GPIOs without Using sudo

[John Dammeyer]

Hi Dennis,
 
I've got a pretty stable pxl gpio library working now.
 
Here is the original ExportPin function with the problem you identified where 
the OS needs time to create the files but fails when it tries to write out.
 
procedure TSysfsGPIO.ExportPin(const Pin: TPinIdentifier);
begin
  TryWriteTextToFile(FExportFileName, IntToStr(Pin));
  SetPinBit(Pin, ExportedBitmask);
end;



A bit of a mystery in how it works other than it creates an OS fault to signal 
issues.  My new function is more complicated:
{
The ExportPin procedure has been expanded to test to see if it is already 
exported.  If it was already there then a new bit flag is set so that when
the application calls to unexport pins, the ones that were there are left 
alone.
}
procedure TSysfsGPIO.ExportPin(const Pin: TPinIdentifier);
var val : StdChar;
begin
  // First check to see if we already exported this pin inside this application.
  if (not IsPinBitSet(Pin, ExportedBitmask)) then begin
// Check to see if the pin was set before program started by reading from 
it.
// If the read fails then the /sys/class/gpio/gpio__ folder does not exist.
if (TryReadCharFromFile(FAccessFileName + IntToStr(Pin) + 
'/direction',val)) then begin
  // It's already exported and folder exists so don't bother trying again.
  SetPinBit(Pin, ExportDefinedBitmask);   // Set that it was already 
exported on start
  SetPinBit(Pin, ExportedBitmask);// and that it's exported.
end
else begin // File didn't exist
  // Wasn't exported when program started so now let's export it.
  if TryWriteTextToFile(FExportFileName, IntToStr(Pin)) then
 SetPinBit(Pin, ExportedBitmask);
end;
 end;
end;


The only problem with the above procedure is that it's not a function that 
returns a successful or not successful export.  So we don't know if the pin was 
actually exported yet.
 
So where does the delay suggestion you made come in?  When we try and set the 
direction of the pin!  Which is done in the user application.  
// Switch LED pin for output.
GPIO.PinMode[PinLED] := TPinMode.Output;


 
The delay is not done in the original but should come after the call to export 
it or ExportPin needs to be changed to a function and the delay done there.  
Here's the original.
 
procedure TSysfsGPIO.SetPinMode(const Pin: TPinIdentifier; const Mode: 
TPinMode);
begin
  if Pin > MaximumSupportedPins then
raise EGPIOInvalidPin.Create(Format(SGPIOSpecifiedPinInvalid, [Pin]));

  if not IsPinExported(Pin) then
ExportPin(Pin);

  if Mode = TPinMode.Input then
  begin
WriteTextToFile(FAccessFileName + IntToStr(Pin) + '/direction', 'in');
ClearPinBit(Pin, DirectionBitmask);
  end
  else
  begin
WriteTextToFile(FAccessFileName + IntToStr(Pin) + '/direction', 'out');
SetPinBit(Pin, DirectionBitmask);
  end;

  SetPinBit(Pin, DirectionDefinedBitmask);
end;


 
Instead I've done as you suggested but let the program try with short intervals.
 
{
When we try and set the pin mode we first test to see if the pin was 
exported.
When the program first runs we don't know yet if it existed as exported but 
after
that even if the pin mode is set again we will know because of the new 
alreadyexportedflag
and the exported flag.
}
procedure TSysfsGPIO.SetPinMode(const Pin: TPinIdentifier; const Mode: 
TPinMode);
var
  escapeCounter : integer;
begin
  if Pin > MaximumSupportedPins then
raise EGPIOInvalidPin.Create(Format(SGPIOSpecifiedPinInvalid, [Pin]));

  if not IsPinExported(Pin) then begin  // First time we don't know if the pin 
was already exported.
ExportPin(Pin);  // So we have to try which will set the proper flags.
if not IsPinAlreadyExported(Pin) then begin  // If it wasn't already 
exported then wait to see if it now is.
escapeCounter := 10;// Wait 5 seconds max for OS to create file 
structure.
repeat 
  Sleep(500);  // Let the OS have time to create the files.
  if (TryReadCharFromFile(FAccessFileName + IntToStr(Pin) + 
'/direction',val)) then 
escapeCounter := 0
  else 
dec(escapeCounter);
until escapeCounter <= 0;
end;
  end;
  // Finally set the direction.
  if Mode = TPinMode.Input then
  begin
WriteTextToFile(FAccessFileName + IntToStr(Pin) + '/direction', 'in');
ClearPinBit(Pin, DirectionBitmask);
  end
  else
  begin
WriteTextToFile(FAccessFileName + IntToStr(Pin) + '/direction', 'out');
SetPinBit(Pin, DirectionBitmask);
  end;

  SetPinBit(Pin, DirectionDefinedBitmask);
end;


The only issue I've run into is the repeat until loop.  Seems like the file is 
readable in about 100mS but fails with the write unless the delay is 500mS.
 
John
 
 
> -Original Message-
> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
> Behalf Of Dennis Lee Bieber
> Sent: May-12-21 9:24 AM
> To: Beagleboard
> Subject: [beagleboard] Re: Using GPIOs without Using s

RE: [beagleboard] Re: Using GPIOs without Using sudo

[John Dammeyer]

Hi Dennis,
I've been playing with that yesterday.  
I think the library needs to be changed in a couple of places.  As you pointed 
out, it doesn't really know if the GPIO pin was already exported until it tries 
to do it and then flags that it's exported in the flags variable.

The problem is if the export fails it then not only checks an invalid flag 
setting and does the unexport but that ends up removing an exported pin that 
was already there when the program stops.  I don't like that behaviour.  I 
thought I saw that it only changes it to input from output but yet it's gone 
when the program finishes so that will take some more investigation.

What I found yesterday is by adding the delay you suggested down in the library 
after the TryWriteTextToFile() that I now get run from command line 
performance.  Most of yesterday was a bit of a write-off dealing with a missing 
SIM card for my wife's new iPhone 12 and some running around to get other 
problems solved.

>From puTTY I reliably get this now.
debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$ ./Blinky
Blinking LED, press any key to exit...
debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$

Today I want to change that low level code to:
1. Not set the exported flag if the pin is already there so it won't be 
unexported at the end but only set to what it was before the program ran.   
This means we also won't try to export it at the start.
2. If it was found to not be there then add the delay but within a repeat until 
with shorter sleep times and a loop counter.

I'll report back when it's done.  

John




> -Original Message-
> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
> Behalf Of Dennis Lee Bieber
> Sent: May-13-21 9:04 AM
> To: Beagleboard
> Subject: [beagleboard] Re: Using GPIOs without Using sudo
> 
>   o/~ Talking to myself in public... o/~
> 
> On Wed, 12 May 2021 17:22:04 -0400, in gmane.comp.hardware.beagleboard.user
> Dennis Lee Bieber 
> wrote:
> 
>   I'd strongly recommend editing this and doing whatever needs to be done
> to rebuild the PXL library (if it doesn't just compile from sources
> everytime) OR...
> 
> >procedure TSysfsGPIO.ExportPin(const Pin: TPinIdentifier);
> >begin
> >  TryWriteTextToFile(FExportFileName, IntToStr(Pin));
> 
> Sleep(1000);  <
> 
> >  SetPinBit(Pin, ExportedBitmask);
> >end;
> 
> ... modifying the source program (for test: Blinky) to explicitly export
> pins and delay before trying to do anything with them...
> 
> """
> begin
>   GPIO := TSysfsGPIO.Create;
> 
>   GPIO.ExportPin(PinLED); 
>   Sleep(1000);
> 
>   try
> // Switch LED pin for output.
> GPIO.PinMode[PinLED] := TPinMode.Output;
> 
> WriteLn('Blinking LED, press any key to exit...');
> """
> 
>   Modifying the library (and fine-tuning the sleep duration to the
> minimum that is reliable) should ensure that any implicit pin export works
> safely. Modifying the application source, OTOH, means if one exports ALL
> NEEDED pins at the start, only one sleep would suffice for the batch,
> rather than getting a sleep on each implicit export.
> 
>   *** WORRY ABOUT SPI AFTER THE GPIO PROBLEM IS SOLVED***
> 
> 
> 
> --
> Dennis L Bieber
> 
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/nriq9ghfakl67f0tdb9mm6qdqriiiundg6%404ax.com.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0b0f01d7481a%242b713cf0%248253b6d0%24%40autoartisans.com.

RE: [beagleboard] Re: Using GPIOs without Using sudo

[John Dammeyer]

Hi Dennis,
As you described below I have the permissions sets as below for both gpio48 and 
gpio60.

debian@ebb:/sys/class/gpio$ echo 48 > export
debian@ebb:/sys/class/gpio$ ls -l gpio48
lrwxrwxrwx 1 root gpio 0 May 12 10:22 gpio48 -> 
../../devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio48
debian@ebb:/sys/class/gpio$

And user debian has belongs to these groups including 'gpio'

debian@ebb:/sys/class/gpio$ groups debian
debian : debian adm kmem dialout cdrom floppy sudo audio dip video plugdev 
users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep admin spi 
tisdk weston-launch xenomai
debian@ebb:/sys/class/gpio$

So now let's play with gpio48 which has an LED attached to it.

debian@ebb:/sys/class/gpio/gpio48$ ls
active_low  device  direction  edge  label  power  subsystem  uevent  value
debian@ebb:/sys/class/gpio/gpio48$ cat direction
in
debian@ebb:/sys/class/gpio/gpio48$ echo out > direction
debian@ebb:/sys/class/gpio/gpio48$ cat direction
out
debian@ebb:/sys/class/gpio/gpio48$ cat value
0

LED is currently OFF

debian@ebb:/sys/class/gpio/gpio48$ echo 1 > value
debian@ebb:/sys/class/gpio/gpio48$ cat value
1
debian@ebb:/sys/class/gpio/gpio48$

LED is ON.
No "sudo" required.

Now let's look at groups.
debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$ ls -l 
Blinky
-rwxr-xr-x 1 debian debian 270880 May 11 15:08 Blinky

Hmmm.  Not part of the gpio group

debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$ ./Blinky
An unhandled exception occurred at $000282E0:
 ESysfsFileOpenWrite: Cannot open 
file  for writing.
  $000282E0  WRITETEXTTOFILE,  line 68 of 
/home/debian/lazarus/pxl/Source/PXL.Sysfs.Types.pas
 $00021CB4  TSYSFSGPIO__SETPINMODE,  line 200 of 
/home/debian/lazarus/pxl/Source/PXL.Sysfs.GPIO.pas

So let’s add it to the gpio group:  

 
debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$ chgrp 
gpio Blinky
debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$ ls -l 
Blinky
-rwxr-xr-x 1 debian gpio 270880 May 11 15:08 Blinky


debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$ ./Blinky
An unhandled exception occurred at $000282E0:
 ESysfsFileOpenWrite: Cannot open 
file  for writing.
  $000282E0  WRITETEXTTOFILE,  line 68 of 
/home/debian/lazarus/pxl/Source/PXL.Sysfs.Types.pas
 $00021CB4  TSYSFSGPIO__SETPINMODE,  line 200 of 
/home/debian/lazarus/pxl/Source/PXL.Sysfs.GPIO.pas

So at the command line level I can work with gpio48 turning on and off the 
output (and the LED).

>From the program I cannot since I don't have permission without using sudo to 
>write to ...gpio48/direction

After every compile I could run the application from the command line with a 
sudo but that's not the solution I need.  Nor to each time change the 
permissions at the command line level.  If we can figure out what the 
attributes of the program are supposed to be so it runs without the sudo then I 
can potentially change something with the Lazarus IDE or Free Pascal Compiler 
to properly configure the executable.  But at the moment I can't get the 
executable to run.

I recall reading that permissions of the gpio48 folder aren't enough.  That the 
links may be a problem but each of the entries in gpio48 are also in the gpio 
group.

debian@ebb:/sys/class/gpio/gpio48$ ls -l
total 0
-rwxrwx--- 1 root gpio 4096 May 12 10:47 active_low
lrwxrwxrwx 1 root gpio0 May 12 10:47 device -> ../../../gpiochip1
-rwxrwx--- 1 root gpio 4096 May 12 10:47 direction
-rwxrwx--- 1 root gpio 4096 May 12 10:47 edge
-rwxrwx--- 1 root gpio 4096 May 12 10:47 label
drwxrwx--- 2 root gpio0 May 12 10:47 power
lrwxrwxrwx 1 root gpio0 May 12 10:47 subsystem -> 
../../../../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 May 12 10:47 uevent
-rwxrwx--- 1 root gpio 4096 May 12 10:47 value
debian@ebb:/sys/class/gpio/gpio48$
  
So still basically lost.  What sort of permissions does the executable "Blinky" 
need in order to be able to write to .../gpio/gpio48/direction?

Thanks
John

Oh, and one other thing with respect to the SPI.  Here's another weird thing 
about the Beagle.  Notice how the numbering is shifted from 0 relative to 1 
relative.  So I believe when the program tries to open spidev1.0 it's really 
still going for the physical spi0 port.  But I could be wrong.

debian@ebb:/sys/class/gpio/gpio48$ ls /dev/spi*
/dev/spidev1.0  /dev/spidev1.1  /dev/spidev2.0  /dev/spidev2.1

/dev/spi:
0.0  0.1  1.0  1.1



> -Original Message-
> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
> Behalf Of Dennis Lee Bieber
> Sent: May-12-21 9:24 AM
> To: Beagleboard
> Subject: [beagleboard] Re: Using GPIOs without Using sudo
> 
> On Tue, 11 May 2021 18:51:22 -0700, 

RE: [beagleboard] Re: Using GPIOs without Using sudo

[John Dammeyer]

Followed what this user reported step by step.
https://stackoverflow.com/questions/41586162/access-gpio-on-beaglebone-as-non-root-user

No matter.  ./Blinky still requires sudo as explained in the comments at the 
start of the program.

So after creating the 
80-gpio-permissions.rules
And creating the
udev-gpio-permissions.sh

And then going through the 
udevadm control --reload-rules
and reboot

What should be done next?

Thanks
John




> -Original Message-
> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
> Behalf Of Dennis Lee Bieber
> Sent: May-11-21 5:48 PM
> To: Beagleboard
> Subject: [beagleboard] Re: Using GPIOs without Using sudo
> 
> On Tue, 11 May 2021 20:29:59 -0400, in gmane.comp.hardware.beagleboard.user
> Dennis Lee Bieber 
> wrote:
> 
> 
> 
> >   procedure Get_Value (Pin : in String; Value : out Integer) is
> >
> >  Pin_File : File_Type;
> >  Pin_Path : constant String := Sysfs_Path & "/gpio" & Pin & "/value";
> >  In_Value : String  := " ";
> 
>   Whoops -- artifact from earlier attempts, In_Value is no longer needed.
> 
> 
> --
> Dennis L Bieber
> 
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/ic9m9g9v70473o3bpfomrtc5f83dngc104%404ax.com.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/098d01d746d5%244b17ac60%24e1470520%24%40autoartisans.com.


Blinky.lpr
Description: Binary data

RE: [beagleboard] Re: Using GPIOs without Using sudo

[John Dammeyer]

Actually I was suggesting the really simple way with apt install but there is 
another.

The fpupdeluxe is a windowing install application that allows you to create any 
version for any target on your PC.  I did install it on my Beagle and yes,  
hours later it's done but that's because the beagle is a bit of a pig.  Went 
much faster on a Pi3 and on both a LinuxCNC PC and WIN-7 PC lightning fast.  
And you can install which target you want to compile for. 

The key here is that for the most part you write once, compile either anywhere 
or on the same machine for anywhere along with an IDE for much faster program 
development.  The blinky.lpi project that I referred to is a command line 
program.  

But I'm trying to keep this discussion pointed in the direction of the subject 
line.  The problem with access to GPIO seems to exist in both the Pi and Beagle 
world.  One posting mentioned how his software broke when the Pi OS was 
upgraded to 4.14.

The issues seem to be the same.  Something with udev and creating the correct 
scripts and files.
https://stackoverflow.com/questions/41586162/access-gpio-on-beaglebone-as-non-root-user

The problem with the above link is that step 1 running 
80-gpio-permissions.rules doesn't work for me because it doesn't exist on my 
system and the contents of that file aren't listed.

However they are in the reference but in that reference the revision of the 
kernel is 4.4.36
https://github.com/adafruit/adafruit-beaglebone-io-python/issues/137

My experience with changing Beagle versions is fraught with disaster where the 
change then breaks all sorts of stuff that was working.  This is why I'm 
staying on 4.11 which is what the book uses and at least there's 1.25" of paper 
all pointing to the same OS.  

So.   Should I just blindly, in the command line way, type all that stuff with 
no idea of why I'm doing it, run it and if it works be happy? 

As an example  the second link uses:
chown -R nick:digital /sys/devices/gpio

The first link above uses
chown -R debian:root /sys/devices/gpio

I think debian:root is what I want to do but I don't understand why the 
nick:digital allows root access.  Why not nick:root?

And the second link with nick's /usr/local/bin/udev-gpio-permissions.sh has a 
lot more lines in it.

As I said, this appears to have been an ongoing issue for more than 7 years.   
And perhaps the latest OS fixes it?  But then I have to go through the process 
of rebuilding an entire system.  Like going from WIN-7 to WIN-10.  What a pain.

John



> -Original Message-
> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
> Behalf Of Dennis Lee Bieber
> Sent: May-11-21 5:30 PM
> To: Beagleboard
> Subject: [beagleboard] Re: Using GPIOs without Using sudo
> 
> On Tue, 11 May 2021 09:43:49 -0700, in gmane.comp.hardware.beagleboard.user
> "John Dammeyer"  wrote:
> 
> 
> >To try this program do sudo apt install lazarus.
> >
>   I think not... Not for an experiment at least. No offence intended, but
> it wants to install over 1GB of stuff -- which is a 33% increase in the
> content of my uSD card!, and would require me to attach a keyboard and
> display to work with the GUI.
> 
>   Now, a simple command line only program would be a different matter
> (does FPC support command line only? -- FPC may be small enough to justify
> installing for testing via SSH, but not Lazarus... *** nope, just FPC is
> most of the load, 900+MB)
> 
>   An example using GNAT (Ada). There is no (or I don't know of one)
> library for GPIO access in GNAT Ada, so everything is SysFS I/O. I had to
> set the pin number to string as the simple integer'image(pin) was
> generating leading spaces, which resulted in invalid file name. Everything
> is in one (117 line) file -- no nasty forms, etc.
> 
> debian@beaglebone:~/BBB_IO$ ls
> main.adb
> debian@beaglebone:~/BBB_IO$ cat main.adb
> with Ada.Text_IO; use Ada.Text_IO;
> with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;
> 
> procedure Main is
> 
>Sysfs_Path : constant String := "/sys/class/gpio";
>GPIO_Pin   : constant String := "48";
>Pin_Value  : Integer;
> 
>procedure Export_Pin (Pin : in String) is
> 
>   Export_File : File_Type;
>   Export_Path : constant String := Sysfs_Path & "/export";
> 
>begin
>   Put_Line ("Opening " & Export_Path);
>   Open (Export_File, Mode => Out_File, Name => Export_Path);
> 
>   Put_Line ("Writing pin number: " & Pin);
>   Put (Export_File, Pin);
> 
>   Put_Line ("Closing " & Export_Path);
>   Close (Export_File);
> 
>   New_Line;
> 
>end Export_Pin;
> 
>procedure Set_Direction (Pin : in String; Direction : in String) is
>   Pin_File : File_Type;
>   Pin_Path : constant String := Sysfs_Path & "/gpio" & Pin &
> "/direction";
> 
>begin
>   Put_Line ("Opening " & Pin_Path);
>   Open (Pin_File, Mode => Out_File, Name => Pin_Path);
> 
>   Put_Line ("Writing direction: " & Direction);
>

Re: [beagleboard] Re: Using GPIOs without Using sudo

[jmelson]

OK, I am not using a current kernel, so can't really address the issues 
with group settings.  But, here's one thing that will work:
if you have a user program xyz, do :
sudo chown root:root xyz
sudo chmod u+s xyz

TYhis makes the program owned by rootm, and uses the privileges of root 
when that program is run.  You DO need root privileges to MAKE these 
settings, but then the program will run and be able to access the GPIO 
without the user needing the privileges.

Making the user a member of the right group should also make any program 
run by that user have the necessary privilege.  It depends on what is in 
the /etc/group file as to what group you need to be a member of.

Jon

On Tuesday, May 11, 2021 at 12:29:23 AM UTC-5 jo...@autoartisans.com wrote:

> > From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] On 
> Behalf Of Dennis Lee Bieber
> > "John Dammeyer"  wrote:
>
> > >The SPI bus ADAfruit application for a 320x240 display written in 
> Python runs properly rendering LENNA.JPG onto the LCD display.
>
> > The key outputs are the DC and RESET which are on gpio48 and gpio60. An 
> "ls" of the /sys/class/gpio folder shows on start up those
> > two are not visible.
> > >
> > 
> > SPI and I2C rely upon a different PINMUX configuration than GPIO...
> > GPIO is pretty much all "mode 7". SPI0 pins are "mode 0" and SPI1 pins 
> are
> > "mode 3".
> > http://www.ofitselfso.com/BeagleNotes/BeagleboneBlackPinMuxModes.php
>
> Hi Dennis,
> I think you missed the above line in my initial posting where the signals 
> DC and RESET are used for controlling the LCD display. They have absolutely 
> nothing to do with SPI.
>
> > 
> > >to create the gpio48 folder and as super user the VXP library can do 
> that but then it fails on the write to SPI.
>
> In fact if I run the program without running it as super user the failure 
> messages that occur happen because gpio48 and gpio60 cannot be created due 
> to access rights.
>
> The PXL library appears to be designed and tested with a BBB (based on the 
> photos and wiring diagram) but because the library is older, the moving 
> target (AKA BeagleBone OS) is likely the culprit for it not working. 
>
> Here's the constructor which shows I'm trying to get to spidev1.0 and the 
> PinDC and PinRST are gpio48 and gpio60 respectively.
>
>
> ===
> constructor TApplication.Create;
> begin
> FGPIO := TSysfsGPIO.Create;
> FDataPort := TSysfsSPI.Create('/dev/spidev1.0');
>
> FDisplay := TDisplay.Create(TDisplay.OLED128x128, FGPIO, FDataPort, PinDC, 
> PinRST);
>
> FDisplaySize := (FDisplay as TDisplay).ScreenSize;
>
> FDisplay.Initialize;
> FDisplay.Clear;
>
> LoadGraphics;
> end;
>
> ===
>
> And then here's the python code that does work.
>
>
> 
> from PIL import Image
>
> import Adafruit_ILI9341 as TFT
> import Adafruit_GPIO as GPIO
> import Adafruit_GPIO.SPI as SPI
>
> # BeagleBone Black configuration.
> DC = 'P9_15'
> RST = 'P9_12'
> SPI_PORT = 1
> SPI_DEVICE = 0
>
> # Create TFT LCD display class.
> disp = TFT.ILI9341(DC, rst=RST, spi=SPI.SpiDev(SPI_PORT, SPI_DEVICE, 
> max_speed_hz=6400))
>
> 
>
> In both cases SPI device 1.0. All I'm doing is compiling an example from 
> the PXL library and the original subject line is still my primary interest. 
> Likely this issue will be solved by the Lazarus group since it's likely a 
> Linux on BBB problem.
>
> So before we get too far off topic again do you know what to do to for 
> setting up GPIO access without sudo?
>
> Thanks
> John
>
>
> > >
> > 
> > SPI0 appears on P9_17, _18, _21, and _22 (raw GPIO # 5, 4, 3, 2, aka
> > gpio0_5, ...). SPI1 are on P9_28, _29, _30, _31 (raw GPIO # 113, 111, 
> 112,
> > 110, aka gpio3_17, _15, _16, _14).
> > 
> > GPIO # 48 (gpio1_16) on P9_15 has no modes for SPI.
> > 
> > 
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/12eed06d-2d12-402a-a82f-0ca2603d4a8fn%40googlegroups.com.

RE: [beagleboard] Re: Using GPIOs without Using sudo

[John Dammeyer]

> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
> Behalf Of Dennis Lee Bieber
> "John Dammeyer"  wrote:

> >The SPI bus ADAfruit application for a 320x240 display written in Python 
> >runs properly rendering LENNA.JPG onto the LCD display.

> The key outputs are the DC and RESET which are on gpio48 and gpio60.  An "ls" 
> of the /sys/class/gpio folder shows on start up those
> two are not visible.
> >
> 
>   SPI and I2C rely upon a different PINMUX configuration than GPIO...
> GPIO is pretty much all "mode 7". SPI0 pins are "mode 0" and SPI1 pins are
> "mode 3".
> http://www.ofitselfso.com/BeagleNotes/BeagleboneBlackPinMuxModes.php

Hi Dennis,
I think you missed the above line in my initial posting where the signals DC 
and RESET are used for controlling the LCD display.  They have absolutely 
nothing to do with SPI.

> 
> >to create the gpio48 folder and as super user the VXP library can do that 
> >but then it fails on the write to SPI.

In fact if I run the program without running it as super user the failure 
messages that occur happen because gpio48 and gpio60 cannot be created due to 
access rights.

The PXL library appears to be designed and tested with a BBB (based on the 
photos and wiring diagram) but because the library is older, the moving target 
(AKA BeagleBone OS) is likely the culprit for it not working. 

Here's the constructor which shows I'm trying to get to spidev1.0 and the PinDC 
and PinRST are gpio48 and gpio60 respectively.

===
constructor TApplication.Create;
begin
  FGPIO := TSysfsGPIO.Create;
  FDataPort := TSysfsSPI.Create('/dev/spidev1.0');

  FDisplay := TDisplay.Create(TDisplay.OLED128x128, FGPIO, FDataPort, PinDC, 
PinRST);

  FDisplaySize := (FDisplay as TDisplay).ScreenSize;

  FDisplay.Initialize;
  FDisplay.Clear;

  LoadGraphics;
end;
===

And then here's the python code that does work.


from PIL import Image

import Adafruit_ILI9341 as TFT
import Adafruit_GPIO as GPIO
import Adafruit_GPIO.SPI as SPI

# BeagleBone Black configuration.
DC = 'P9_15'
RST = 'P9_12'
SPI_PORT = 1
SPI_DEVICE = 0

# Create TFT LCD display class.
disp = TFT.ILI9341(DC, rst=RST, spi=SPI.SpiDev(SPI_PORT, SPI_DEVICE, 
max_speed_hz=6400))


In both cases SPI device 1.0.  All I'm doing is compiling an example from the 
PXL library and the original subject line is still my primary interest.  Likely 
this issue will be solved by the Lazarus group since it's likely a Linux on BBB 
problem.

So before we get too far off topic again do you know what to do to for setting 
up GPIO access without sudo?

Thanks
John


> >
> 
>   SPI0 appears on P9_17, _18, _21, and _22 (raw GPIO # 5, 4, 3, 2, aka
> gpio0_5, ...). SPI1 are on P9_28, _29, _30, _31 (raw GPIO # 113, 111, 112,
> 110, aka gpio3_17, _15, _16, _14).
> 
>   GPIO # 48 (gpio1_16) on P9_15 has no modes for SPI.
> 
> 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/085701d74626%248ddb9ac0%24a992d040%24%40autoartisans.com.

Re: [beagleboard] Re: Using GPIOs without Using sudo

[Alexander Zangerl]

On Mon, 10 May 2021 22:25:54 -0400, Dennis Lee Bieber writes:
>debian@beaglebone:~$ sudo echo 48 > /sys/class/gpio/export
>[sudo] password for debian:
>echo: write error: Operation not permitted
>
>   To my knowledge, the redirection part is still done as the debian user,
>only the echo is being done by sudo.

you're absolutely correct, but there's more than one way to do that.
for example, 
sudo sh -c "echo 48 > /sys/class/gpio/export"
would do all the stuff as root.

>debian@beaglebone:~$ sudo su
*shudder* *twitch*


-- 
Best Regards,
Alexander Zangerl
IT Engineer

BREATHE-SAFE intelligent cabin air filtration
Keeps your lungs and cabin dust free!
Head Office: 62 Mica Street, Carole Park QLD 4300 Australia
Western Australia: 169 Chisholm Crescent, Kewdale WA 6105 
Tel: +61 7 3276 7833 M. +61 415 482 341 E. a...@breathe-safe.com

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/12784-1620700409.442939%40oPjB.cQRa._wK_.

RE: [beagleboard] Re: Using GPIOs without Using sudo

[John Dammeyer]

First of all thank you for responding.  Comments below.
> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
> Behalf Of Dennis Lee Bieber
> On Mon, 10 May 2021 10:09:14 -0700, in gmane.comp.hardware.beagleboard.user
> "John Dammeyer"  wrote:
> 
>   Suspect I'm not really going to be of much help -- but a few
> comments...
> 
> >I'm still not sure of the actual process with this revision of the OS.
> >debian@ebb:~/lazarus$ uname -a
> >Linux ebb 4.14.108-ti-r136 #1stretch SMP PREEMPT Mon Jun 8 15:38:30 UTC 2020 
> >armv7l GNU/Linux
> >
>   Stretch is getting a bit long in the tooth -- is there some reason you
> need to stay on it (Debian organization is in the midst of finalizing the
> replacement for Buster!).
> 
It's been a love/hate relationship with the Beagle.  I have about 5 books that 
are useless because the OS changed so the experiments don't work.  Regardless 
of how wonderful the newest revision of the BBB OS is, if changes don't match 
the documentation that's out there then the changes are useless.  It's why I 
had to buy the second edition of Derek Molloy's book.  No more $SLOTS.


>   You also appear to have changed your Beagle's host name to match that
> Malloy used for his -- the initials of "e/xploring b/eagleb/one". Just an
> observation.

Good observation.  After fighting the various books,  web pages etc. I decided 
I'd start at page 1 and work my way through the second edition so that what was 
written matched what I was doing.  So if he's using 4.14 so am I.
> 
> >
> >And then create the shell script as outlined but with user debian in group 
> >gpio?
> >Eg:
> >chown -R nick:digital /sys/devices/gpio
> >
> >becomes
> >chown -R debian:gpio /sys/devices/gpio
> >
>   I'm somewhat surprised at that. My understanding is that adding the
> "debian" user to the GROUP gpio should allow that user to access anything
> that is part of the gpio group, using the group permissions rather than
> owner permissions -- so should not need to be changed to debian as owner.
> 
>   Unfortunately, I can't state anything specific. Buster doesn't seem to
> have the same layout.

And now we run into the real problem.  The web pages out there are in many 
cases useless because they might refer to older versions of the OS or newer 
versions.  

What started this particular stream of discovery was that I jumped ahead a bit 
rather than continue page by page.My desire is to create the same library 
of C++ functions for Lazarus (Free Pascal) and ultimately update the sockets.pp 
code to support socketCAN which it currently doesn't.

I've written a few utilities already that use the CANUSB from Lawicel and the 
same source code compiled on each host runs on Windows, LinuxCNC, Pi3 and the 
Beagle talking to the CANUSB and an active CANopen project.

To deal with CAN bus on the Pi3/Pi4 requires access to the SPI bus for the 
MCP2515.  On the Beagle it's the on chip CAN device.  And if I want to talk to 
sensors like I2C or One-Wire plus inexpensive LCD displays I need access to the 
hardware.  

So I installed the PXL library and that's where I ran into the next roadblock.  
First you can't, from within the IDE and debugging, work with SPI bus without 
running Lazarus as root.  Or it just won't work with the /sys/class/gpio 
folders.  And that's the reason for wanting to free up access to the gpio.

The SPI bus ADAfruit application for a 320x240 display written in Python runs 
properly rendering LENNA.JPG onto the LCD display.  The key outputs are the DC 
and RESET which are on gpio48 and gpio60.  An "ls" of the /sys/class/gpio 
folder shows on start up those two are not visible.  

It's possible to use:
$ sudo echo 48 > /sys/class/gpio/export 
to create the gpio48 folder and as super user the VXP library can do that but 
then it fails on the write to SPI.

=
debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/DisplaySPI$ 
sudo ./DisplaySPI
[sudo] password for debian:
An unhandled exception occurred at $00032BB0:
 ESysfsSPITransfer: Cannot transfer 
<1> data byte(s) through SPI bus.
   $00032BB0  TSYSFSSPI__TRANSFER,  line 247 of 
/home/debian/lazarus/pxl/Source/PXL.Sysfs.SPI.pas
   $00032AC4  TSYSFSSPI__WRITE, 
 line 228 of /home/debian/lazarus/pxl/Source/PXL.Sysfs.SPI.pas
=

I don't yet know the reason for this.  The error happens here:
  Res := fpioctl(FHandle, SPI_IOC_MESSAGE(1), @Data);

The fpioctl is in the Free Pascal interface library so that's not something to 
be dealt with in this forum.

I thought it best to solve the simple problem first which to not use sudo so I 
can run Lazarus from the debian user desktop and be able to debug with break 
points etc.  The comment by Robe