On 10/19/22 05:51, Lukas Zeller wrote:
Hi,
Lukas, thanks for this. I've read through everything and I agree with your
concerns. I'll note also that Linus W's commentary is from 2018.
On 19 Oct 2022, at 08:55, Petr Štetiar <[email protected]> wrote:
IMO there should be `ugpiod` daemon available over ubus, probably written in
ucode using libgpiod bindings. It should provide ubus events for GPIO inputs
and should be able to control GPIO outputs using ubus calls.
What would that mean for performance, compared to more direct call chains
as when using legacy /sys/class/gpio and current libgpiod? I suspect it would
be much slower via an extra daemon.
Regarding performance, this is a practical concern. In one case using a GPIO-
driven 3-color LED, using explicit user-space tools (albeit a clunky vendor
program), to blink, there was a enough of a delay between the blinks to give
a disconcerting display when trying to blink white. I'm sure there's a better
way to do this, but changing the code to direct file access to the GPIOs
produced a more satisfactory result.
And I still haven't seen a rationale for the "non-fixed" base - I understand
there's probably a desire for abstraction somewhere, but figuring out
offsets becomes a hassle. I get that some boards have some wacky
GPIO assignments due to chip design, but this is surely a DTS concern.
I'm sure also it's trivial to extend the legacy GPIO export function to
export named GPIOs too (if it doesn't already, I haven't looked).
So for the moment, there doesn't seem to be general-purpose solution
in OpenWrt, especially for script use. I'll gladly migrate to that if
there is one in future, but I think for now I need to stick to my
patch and named GPIO exports in the DTS.
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
