Am 29.03.2022 um 10:51 schrieb Kent Gibson:
On Tue, Mar 29, 2022 at 10:43:19AM +0200, Hans Kurscheidt wrote:
Am 29.03.2022 um 10:38 schrieb Kent Gibson:
On Tue, Mar 29, 2022 at 10:07:57AM +0200, Hans Kurscheidt wrote:
Am 29.03.2022 um 05:38 schrieb Kent Gibson:
On Mon, Mar 28, 2022 at 07:13:13PM +0200, Hans Kurscheidt wrote:
Am 28.03.2022 um 15:16 schrieb Hans Kurscheidt:
Hi,
what would be the right mode for gpiomon call from
a shellscript executed as root from systemd at system start
waiting on a Pin w/ pullup for invoking shutdown upon rising* edge.
*changed
Lots of interupts, Signals and other GPIO ongoing from other user APPs &
threads in multi-user state.
2b more precise: I wired a GPIO Pin to GND.
Upon the cmd: sudo gpiomon -r -n1 <chip> <offset>
the program exits immediately with 1 event, although there was never a
rising edge due to the fix wire to GND. Is this a feature or a bug, and is
it reproducible?
Not a feature and not reproducible for me on a Raspberry Pi4 with the
setup you describe, so probably a bug specific to your hardware platform,
whatever that may be.
If it is 100% reproduceable for you, and assuming it is an initialisation
issue so you only get the one spurious event, how about using -n2 as a
workaround ;-)?
Cheers,
Kent.
It appears 2b reproduceable 100% on my OrangePi zero+ (Allwinner H5) and
using -n2 does the trick, but isn't gpiod not supposed to work on all
commercial HW platforms and related kernels, rather then only on RPI??
gpiod will work on any platform with a supporting kernel.
How well depends on the underlying hardware and driver.
The RPi4 was merely a counter-example demonstrating that your issue is
not universal, using hardware I happen to have readily available.
Cheers,
Kent.
So if I understand you right, gpiod works on sort of a logical level, while
the HW dependend part depends of the kernel driver implementation of the
specific HW?
libgpiod is a userspace library and tools to access GPIO lines via the
Linux GPIO character device. The actual interfacing to the hardware is
performed by the kernel and appropriate drivers for your hardware.
As your problem does not exhibit on other hardware, the root cause
of your problem probably lies in the driver for your hardware, not in
libgpiod nor the gpiolib subsystem of the kernel.
But you would need to debug it further to be sure.
Cheers,
Kent.
I raised a bug report at tha Armbian forum:
https://forum.armbian.com/topic/20166-opi-zero-h5-gpiodmon-generates-spurious-interrupts-upon-invocation/
I made some trial to understand if it is reproduceable, but I have
difficulties defining, when it happens. After RESET there is no spurious
event. The spurious event appears to happen, when the line was moved:
Could you please make another trial on your RPI w/ the following sequence:
RESET, gpiomon -r -n1 -Bpull-up <chip><line> => No event, -> pull line
up /down, => event (as expected), gpiomon -r -n1 -Bpull-up <chip><line>
=> false event
There might be an issue w/ pending interrupts, when the line is bouncing
when pulled up/down. The 2nd gpiodmon cmd might catch one of the pending
interrupts. (Just an idea). This would hint to an initialisation
problem, that pending line states are not preempted, before the int is
attached.
