On 12/23/25 07:46, andy pugh wrote:
On Tue, 23 Dec 2025 at 10:15, Robert Schöftner <[email protected]> wrote:
this tool supplied with libgpiod scans for chips and lines:
https://github.com/brgl/libgpiod/blob/master/tools/gpiodetect.c
There is sample code that replicates the previously built-in
gpio_line_find_by_name:
https://github.com/brgl/libgpiod/blob/master/examples/find_line_by_name.c
This uses dirent.h
I am still annoyed that the new API is so much less functional than
the old one.
(Especially as I wrote the original hal_gpio for fun, have never used
it myself, and now have the task of rewriting it when it doesn't feel
like fun)
Whether the existing driver could work with RTAI in the kernel I have
never tested, not having a non-ARM PC with usable GPIO (and RTAI being
x86-only AFAIK)
But the driver does have conventional provision for using different
versions of the RTAPI.
Andy, I might be totally in the dark, but the preempt-rt interrupts
appear to be much
closer to RTAI in arrm64 kernel than in wintel stuff. Running this kernel
from the bookkworm build about a year old that Mr Webster built for me:
Debian GNU/Linux 12 (bookworm) 6.1.54-rt15 #1_RT Wed Sep 20 20:36:44
AEST 2023
aarch64
I log latency at around 12 u-secs if firefox is not running, worst case
if I leave it running
for hours is 49 u-secs. Plenty fast enough to run my 11x56 Sheldon dead
smoothly. Zero stutters.
The interface is RPSPI.
Merry Christmas everybody.
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
