Error writing to /sys/class/gpio/export, GPIO failure about direwolf HOT 17 OPEN

Thanks for reporting this.
There is a new application program interface to gpio pins.
When I first heard of it, I tried it on the RPi and it did not work yet.
I put it on the back burner and never got back to it.
I guess this will change my priorities.

from direwolf.

I'm not seeing this issue on a fully patched mainline Bookworm (not anything bleeding edge that comes with rpi-update) on an Rpi4. Following the testing links from above:

$ uname -a
Linux rpi4-bookworm 6.1.0-rpi6-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.58-1+rpt2 (2023-10-27) aarch64 GNU/Linux

$ echo "16" > /sys/class/gpio/export
$

$ sudo raspi-gpio get 3
GPIO 3: level=1 fsel=4 alt=0 func=SCL1 pull=UP

Dire Wolf version 1.7
Includes optional support for: gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0 (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8000 ...
Ready to accept KISS TCP client application 0 on port 8001 ...
Virtual KISS TNC is available on /dev/pts/0
Created symlink /tmp/kisstnc -> /dev/pts/0
[0L] KI6ZHD-8>BEACON:KI6ZHD/k KI6ZHD-1/b SCLARA/n 44.128.0.1/ip : Linpac in Santa Clara <0x20>

from direwolf.

Yah, i think this is a Pi5 thing, they have multiple gpio adapters, and you somehow add the adapter address to the pin address to get the actual pin. I don't have all the info, to be honest. I've switched to the "gpiozero" python module which makes it all transparent, but I'm not sure how to implement it in C. the /sys gpio stuff is deprecated (deprecating)

from direwolf.

Ok, I have a Pi5 on order but I don't know when it will ship. I'm surprised we would see different OS behavior depending on the hardware.

from direwolf.

The individual file sysfs interface has been deprecated for some time now. You are supposed to use libgpiod: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git. It's actually a much better interface in my opinion.

from direwolf.

Understood and WB2OSZ has already committed this new interface into DW 1.8-DEV but I'm curious why I cannot reproduce this issue. If it's only exposed when using new Rpi5 hardware, that doesn't make much sense unless it's exposed only give a new kernel or firmware only used on the Rpi5 hardware.

from direwolf.

A preliminary version of PTT with gpiod/libgpiod is now available in the "dev" branch.
I did a little bit of testing on an RPi 3 and it works for a simple case.
It needs more testing under a variety of situations.
Here is how to use it.

(1) Install packages gpiod and libgpiod-dev.
(2) cd to direwolf source dir. "git pull" to get latest source.
(3) Rebuild direwolf, starting with the cmake step so the new packages are noticed.
(4) When direwolf starts, notice that libgpiod is listed in optional features.
(5) run "gpioinfo" command to get list of gpio chip names and corresponding I/O lines.
For an RPi 3, the name is "gpiochip0." I have not tried on other models yet.
(6) In your config file, change PTT line from "PTT GPIO n" to "PTT GPIOD gpiochip0 n" where n is the I/O line number.

from direwolf.

I'm not happy about the additional user complexity of having to determine the gpio chip name. If it turns out to be gpiochip0 for all RPi models, maybe that could be made the default, still leaving the option for specifying for other single board computers.

from direwolf.

Note that many pins also have names, and you can find the pins by their name instead of worrying what chip they’re on. The pin names are defined in the device tree of whatever platform you’re running. That way they’re abstracted from whatever GPIO chip they’re on. Because while the internal stuff will probably come up on gpiochip0, there is no guarantee that it will from the kernel.

from direwolf.