On Wed, 12 May 2021 10:54:12 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer" <johnd-5o6ditlojsohvde0pjs...@public.gmane.org> wrote:
>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
>
It shouldn't be... That line says the file "Blinky" is owned by user
"debian" and is part of the group "debian"... And group/other have
read/execute permission on the file.
You /run/ the file from your account, and your account is a member of
"gpio" group.
>debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$
>./Blinky
>An unhandled exception occurred at $000282E0:
> ESysfsFileOpenWrite: Cannot open
> file </sys/class/gpio/gpio48/direction> 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
Which only means users with group "gpio" membership now have access to
the file. It does nothing for what permissions the file itself is running
under -- those are defined by the user group membership.
Unfortunately, the PXL source doesn't return the actual error code
which fpGetErrno would report; it raises that exception for any error code
(the help systems says "negative value if there was an error" whereas
fpwrite explicitly says -1 for an error; in either case, having fpgeterrno
value could help pin down what the real problem is).
Handle := fpopen(FileName, O_WRONLY);
if Handle < 0 then
raise ESysfsFileOpenWrite.Create(Format(SCannotOpenFileForWriting,
[FileName]));
I see that setpinmode does do an export of the pin if it is not already
exported... As my tests with Ada program show, I needed a delay (used one
second I believe) after doing an export or I'd get a similar problem with
opening the pin's files. However -- "not already exported" is PXL's
concept, not reality. PXL maintains a bit-map of "exported" pins, meaning
pins IT has done an export for...
function TSysfsGPIO.IsPinExported(const Pin: TPinIdentifier): Boolean;
begin
Result := IsPinBitSet(Pin, ExportedBitmask);
end;
This means the every time you run the program, it starts with the
assumption that the pin is NOT exported, and issues an export operation. I
suspect -- based on my timing issues -- that
procedure TSysfsGPIO.ExportPin(const Pin: TPinIdentifier);
begin
TryWriteTextToFile(FExportFileName, IntToStr(Pin));
SetPinBit(Pin, ExportedBitmask);
end;
needs to have some sleep/delay placed in it before it returns... say
Sleep(1000);
for a 1 second delay (if that runs you could try fine-tuning downwards
until it fails, then add a safety margin to the last working value).
>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.
The program attributes should only be a need to have eXecute permission
on thre file. Everything else should be defined by the /user account/
membership and the permissions of the target files.
I don't know why "sudo" doesn't have the problem, unless, again, it is
a timing matter -- and immediately after the export the direction file
starts with root:root and needs time to be changed to root:gpio. If so,
then sudo would be owner of root and not tied to the group access... and if
so, adding a delay immediately after the export write in PXL may suffice.
After all, the program, as I understand the calling sequences and tests, IS
WRITING TO /sys/class/gpio/export without a problem.
>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
>
Try ls -l This appears to be another change as mine map
1:1
(another reason to create an current Debian 10/buster uSD card). I wouldn't
be surprised if Stretch maps 0.0 to spidev2.0, while 1.0 goes to spidev1.0.
debian@beaglebone:~$ ls -l /dev/spi*
crw-rw---- 1 root spi 153, 0 May 12 12:46 /dev/spidev0.0
crw-rw---- 1 root spi 153, 1 May 12 12:46 /dev/spidev0.1
crw-rw---- 1 root spi 153, 2 May 12 15:58 /dev/spidev1.0
crw-rw---- 1 root spi 153, 3 May 12 15:58 /dev/spidev1.1
/dev/spi:
total 0
lrwxrwxrwx 1 root root 12 May 12 12:46 0.0 -> ../spidev0.0
lrwxrwxrwx 1 root root 12 May 12 12:46 0.1 -> ../spidev0.1
lrwxrwxrwx 1 root root 12 May 12 15:58 1.0 -> ../spidev1.0
lrwxrwxrwx 1 root root 12 May 12 15:58 1.1 -> ../spidev1.1
debian@beaglebone:~$
A year old, so might be based on Stretch is
https://arcanesciencelab.wordpress.com/2020/01/14/the-correct-way-to-enable-spi-ports-on-the-beaglebone-black/
On that page they state
"""
# For SPI1, /dev/spidev1.#
#
config-pin p9_17 spi_cs
config-pin p9_18 spi
config-pin p9_21 spi
config-pin p9_22 spi_sclk
# For SPI0, /dev/spidev2.#
#
config-pin p9_28 spi_cs
config-pin p9_29 spi
config-pin p9_30 spi
config-pin p9_31 spi_sclk
"""
Note the cross -- spidev2 is SPI0. Hmmm, and Molloy states that SPI0 is the
one not available normally...
Confusingly https://beagleboard.org/Support/bone101 shows SPI0 on pins
17/18/21/22, and SPI1 is on 19/20/28/29/30/31/42 -- chart may be a bit in
error as it shows two SPI1_CS0 and two _CS1 (19 and 20 seem the anomaly --
they are only assigned to I2C, SPI, and UART, otherwise blank) Maybe
https://microcontrollerslab.com/beaglebone-black-pinout-pin-configuration-features-applications/
is more trustworthy. Note that it puts SPI0 on 17-22, and SPI1 on 28-31
--
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/ak7o9g5q4imust07amcp23d9dvisn0l6if%404ax.com.
