On Mon, 10 May 2021 22:29:01 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer" <johnd-5o6ditlojsohvde0pjs...@public.gmane.org> wrote:
>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.
>
Okay... The following will be a bit of a rambling mess as I can't find
a clean way to separate all the file searching I'm doing... I tried to mark
what seem crucial points with
****************
the point
****************
>>
>> >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.
>
I've downloaded the source https://asphyre.net/products/pxl , and can't
even find a mention of beagles (checked for "eagle", BBB, etc.). Whereas
the R-Pi has a dedicated module. {Side note: The MDI interface of Lazarus
is painful to me -- too many independent windows that have to be pulled
forward after every change from it to some other application}
PS C:\Users\Wulfraed\Desktop\pxl-v110\Source> Select-String -Pattern beagle
-Path *
PS C:\Users\Wulfraed\Desktop\pxl-v110\Source> Select-String -Pattern eagle
-Path *
PS C:\Users\Wulfraed\Desktop\pxl-v110\Source> Select-String -Pattern bone
-Path *
Jedi.Compilers.inc:1315:// Revision 1.30 2005/12/04 10:10:58 obones
Jedi.Compilers.inc:1318:// Revision 1.29 2005/11/01 20:46:20 obones
PS C:\Users\Wulfraed\Desktop\pxl-v110\Source> Select-String -Pattern bbb
-Path *
PXL.Linux.videodev2.pas:212:function V4L2_PIX_FMT_RGB444: Cardinal; inline;
{ 16 xxxxrrrr ggggbbbb }
PXL.Linux.videodev2.pas:289: xxxxrrrrrrrrrrxxxxgggggggggg
xxxxggggggggggxxxxbbbbbbbbbb... }
***********************************************************************
... But since you are specifying lower-level SysFS calls, it should be
generic.
***********************************************************************
>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
Unfortunately Adafruit_GPIO has been deprecated in favor of
CircuitPython libraries via the BLINKA interface package... <G> Makes
crawling through it problematic.
****************************************************
At the core, if it has to export the pin, it uses
****************************************************
"""
const char gpio_export[] = "/sys/class/gpio/export";
if ((fd = open(gpio_export, O_WRONLY)) < 0) {
syslog(LOG_ERR, "Adafruit_BBIO: gpio_export(): %u couldn't open
\"%s\": %i-%s",
gpio, gpio_export, errno, strerror(errno));
ret = BBIO_SYSFS;
goto exit;
}
len = snprintf(str_gpio, sizeof(str_gpio), "%d", gpio);
if(write(fd, str_gpio, len) < 0) {
syslog(LOG_ERR, "Adafruit_BBIO: gpio_export: %u couldn't write
\"%s\": %i-%s",
gpio, gpio_export, errno, strerror(errno));
ret = BBIO_SYSFS;
goto exit;
}
"""
************************************************************************
It looks PXL display doesn't test/export GPIO pins -- it directly
accesses whatever was provided.
************************************************************************
"""
constructor TCustomDrivenDisplay.Create(const AGPIO: TCustomGPIO;
const ADataPort: TCustomDataPort; const APinDC: Integer;
const APinRST: Integer);
begin
FGPIO := AGPIO;
FDataPort := ADataPort;
FPinDC := APinDC;
FPinRST := APinRST;
inherited Create;
if FPinRST <> -1 then
FGPIO.PinMode[FPinRST] := TPinMode.Output;
if (FPinDC <> -1) and (FDataPort is TCustomPortSPI) then
FGPIO.PinMode[FPinDC] := TPinMode.Output;
end;
"""
**********************************************************************************
If those GPIOs have not been exported on your system, you may have to
manually invoke the export function before trying to create your display.
**********************************************************************************
Something like
FGPIO.ExportPin(PinDC);
debian@beaglebone:~$ ls -l /sys/class/gpio/e*
--w--w---- 1 root gpio 4096 May 10 22:26 /sys/class/gpio/export
debian@beaglebone:~$
which is writeable by group gpio members (on a Buster system)
debian@beaglebone:~$ groups debian
debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users
systemd-journal input bluetooth netdev i2c gpio admin spi iio docker tisdk
weston-launch xenomai cloud9ide pwm eqep remoteproc
debian@beaglebone:~$
and debian user is a member of gpio, spi, i2c
>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=64000000))
>####################################################################################
>
>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.
>
FYI: from the bottom of the C-language module for spidev one finds...
"""
>>> import Adafruit_GPIO as GPIO
>>> import Adafruit_GPIO.SPI as SPI
>>> spi = SPI.SpiDev(1, 0)
>>> spi2 = SPI.SpiDev(0,0)
>>>
>>> import spidev
>>> dir(spidev)
['SpiDev', '__doc__', '__file__', '__loader__', '__name__', '__package__',
'__spec__', '__version__']
>>> spidev.__file__
'/usr/local/lib/python3.7/dist-packages/spidev.cpython-37m-arm-linux-gnueabihf.so'
>>> print(spidev.__doc__)
This module defines an object type that allows SPI transactions
on hosts running the Linux kernel. The host kernel must have SPI
support and SPI device interface support.
All of these can be either built-in to the kernel, or loaded from
modules.
Because the SPI device interface is opened R/W, users of this
module usually must have root permissions.
"""
The question then becomes: what is different -- since the deprecated
Adafruit_GPIO.SPI seems to be able to touch them... (It imports the spidev
module).
The device open() call is just:
"""
if (snprintf(path, SPIDEV_MAXPATH, "/dev/spidev%d.%d", bus, device) >=
SPIDEV_MAXPATH) {
PyErr_SetString(PyExc_OverflowError,
"Bus and/or device number is invalid.");
return NULL;
}
if ((self->fd = open(path, O_RDWR, 0)) == -1) {
PyErr_SetFromErrno(PyExc_IOError);
return NULL;
}
"""
And those devices are in the SPI group, so being a member of the group
should allow access to those devices.
*******************************************************************************
Not sure what happens if opening spidev1.x, since to my knowledge
spidev1.x is not active unless the appropriate device tree is loaded. It
seemed to open, but maybe will fail if I tried I/O on it.
*******************************************************************************
>So before we get too far off topic again do you know what to do to for setting
>up GPIO access without sudo?
Run a Buster edition? At the least (and given how cheap uSD cards are
becoming) install Buster on an 8-16GB uSD and see if it changes the
behavior. Most GPIOs are already exported/configured on my system by
default.
"""
debian@beaglebone:~$ ls -l `sudo find / -iname gpio48`
[sudo] password for debian:
lrwxrwxrwx 1 root gpio 0 May 10 22:26 /sys/class/gpio/gpio48 ->
../../devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio48
/sys/devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio48:
total 0
-rwxrwx--- 1 root gpio 4096 May 10 22:26 active_low
lrwxrwxrwx 1 root gpio 0 May 10 22:26 device -> ../../../gpiochip1
-rwxrwx--- 1 root gpio 4096 May 10 22:26 direction
-rwxrwx--- 1 root gpio 4096 May 10 22:26 edge
-rwxrwx--- 1 root gpio 4096 May 10 22:26 label
drwxrwx--- 2 root gpio 0 May 10 22:26 power
lrwxrwxrwx 1 root gpio 0 May 10 22:26 subsystem ->
../../../../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 May 10 22:26 uevent
-rwxrwx--- 1 root gpio 4096 May 10 22:26 value
debian@beaglebone:~$ ls -l `sudo find / -iname gpio60`
lrwxrwxrwx 1 root gpio 0 May 10 22:26 /sys/class/gpio/gpio60 ->
../../devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio60
/sys/devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio60:
total 0
-rwxrwx--- 1 root gpio 4096 May 10 22:26 active_low
lrwxrwxrwx 1 root gpio 0 May 10 22:26 device -> ../../../gpiochip1
-rwxrwx--- 1 root gpio 4096 May 10 22:26 direction
-rwxrwx--- 1 root gpio 4096 May 10 22:26 edge
-rwxrwx--- 1 root gpio 4096 May 10 22:26 label
drwxrwx--- 2 root gpio 0 May 10 22:26 power
lrwxrwxrwx 1 root gpio 0 May 10 22:26 subsystem ->
../../../../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 May 10 22:26 uevent
-rwxrwx--- 1 root gpio 4096 May 10 22:26 value
debian@beaglebone:~$
"""
"""
debian@beaglebone:~$ cat /sys/class/gpio/gpio48/value
1
debian@beaglebone:~$ cat /sys/class/gpio/gpio48/direction
in
debian@beaglebone:~$ cat /sys/class/gpio/gpio48/label
P9_15
debian@beaglebone:~$ echo out > /sys/class/gpio/gpio48/direction
debian@beaglebone:~$ cat /sys/class/gpio/gpio48/direction
out
debian@beaglebone:~$ echo 0 > /sys/class/gpio/gpio48/value
debian@beaglebone:~$ cat /sys/class/gpio/gpio48/value
0
debian@beaglebone:~$
"""
Not a "sudo" in sight! (I used sudo on the "find" operation just to
reduce the error messages for inaccessible files)
If you can't do those from the regular user shell, I don't think any
program will succeed. If you can, I'd put the blame on the library you are
trying to use. You mentioned it is a bit old -- it may be trying to
configure pins using the old capemgr /slots/ system. {Ignore that last
sentence -- obviously the source is just using SysFS I/O; the GPIO failure
may be due to lack of an export on Stretch}}
--
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/m6kl9gh9q6en9t9h5iftal4u57mug1m1ss%404ax.com.
