Possible to read config at startup and detect busy pins

[andrewdavidmackenzie]

A question, more than an issue....

In pigg I have this issue to work on:

andrewdavidmackenzie/pigg#39

Is it possible that pins are in use (via rppal as it happens) by another app of mine, and I can detect that at start-up and mark those pins as "unavailable", but I can continue to use other free pins?

So, two separate binaries, one using some GPIO pins, the other using different GPIO pins?

[golemparts]

Is it possible that pins are in use (via rppal as it happens) by another app of mine, and I can detect that at start-up and mark those pins as "unavailable", but I can continue to use other free pins?

It's not currently possible, but it's something to consider to add support for.

The GPIO (v1/v2) API does register the consumer of a specific pin, but we're only using it for interrupts at the moment. Everything else is done through direct register access because of GPIO API limitations (see my comment here for details). Additionally, any other (non-RPPAL) application that accesses the GPIO pins in some other way wouldn't show up in the GPIO API as the consumer, so it still wouldn't catch all cases of a pin in-use by another application.

I do think it's worth re-evaluating the GPIO API once we've moved to v2, and move more systems from using direct register access to going through the API instead, where it makes sense.

The main roadblock that previously prevented me from moving everything to using the GPIO API was the lack of support for reading which alt function mode a pin is set to, which is needed to show a GPIO pin status overview. Part of the reason why that was an issue at the time was because it initially looked like we'd lose access to direct GPIO register access entirely. Now that we have access to both I could combine their use, and use register access for functionality that isn't available through the API.

[andrewdavidmackenzie]

Noted. Thanks for the reply.