Closed htot closed 5 years ago
:smile:
and documents how to migrate from sysfs to libgpiod (which we need to do for mraa as well - which is the major obstacle to make acpi enabled image the default)
Do you mean that mraa doesn't expect to see newer kernels on Edison, so doesn't use the new interface? This can be fixed, yes. The only thing is that mraa doesn't use libgpiod, it uses the new chardev interface directly, but OTMH this shouldn't be a problem.
@alext-mkrs thanks for reviewing. I'll resolve your comments and merge,
On mraa: you explained before that mraa doesn't want dependency on libgpiod but I don't think the chardev interfaces is used yet on eds. We are on mraa 1.9 and afaiu intel_edison_fab_c.c is used which uses sysfs.
merged
Understood. Yes, mraa can be updated similar to other platforms supported, which have this functionality.
This fixes issue #44 (on the acpi enabled kernel pin numbering has changed breaking the blink-led program).
On acpi the preferred way to access gpio is through libgpiod. The blink-led script is python2.7. libgpiod supports python3 bindings, however the sumo provided recipe does not enabled this. 1) get libgpiod from master 2) enabled python3 bindings 3) spi hogs a pin needed for blinking the led, disable spi for now 4) fixup blink-led to run with python3 and switch to using libgpiod when acpi is detected 5) remove python packages from initramfs as we exceed maximum size
I tested this both with and without acpi enabled kernel.
In a later stage I intend to enable kernel led driver for acpi enabled image, with led trigger (timer, heartbeat, morse) which will probably obsolete blink-led as a service. Until then this works and documents how to migrate from sysfs to libgpiod (which we need to do for mraa as well - which is the major obstacle to make acpi enabled image the default).