🚀 Support GPIO pins > 53

[rtreffer]

Feature Description

Support GPIO pins >= 54 in gpio_settings.

What functionality would you like to see in your phoniebox?

I am using a MCP23017 with the stock overlay (dtoverlay=mcp23017,addr=0x27,gpiopin=17).
This creates /sys/bus/gpio/devices/gpiochip1/ with GPIO pins 496..511.

These pins are currently not usable via RPI.GPIO. It is also not possible to extend the library as the limit of 54 pins is part of the design (e.g. several arrays are of size 54, the generic input read is done via direct memory access, ....).

I would like to use GPIO 497/498 for a KY-040 rotary encoder.

How do you envision the feature to work from a users perspective?

This should be transparent for a user, e.g. this is the configuration I am using:

[VolumeControl1]
enabled: True
Type: RotaryEncoder
PinUp: 498
PinDown: 497
functionCallDown: functionCallVolD
functionCallUp: functionCallVolU

Further information that might help

My idea / goal was to have a small cnc milled adapter board for the MCP23017 that would have debounce capacitors and sockets for all the ports (upcycling an old blaupunkt radio, with 5 buttons / 3 rotary encoders on the top plate that I would like to keep)

I reached the point where I got the ky-040 working via the MCP23017 with the help of the python-periphery library. The downside is that I have to start a python thread for blocking epoll.

The listed config works for volume control 🤷
I could share some code (I haven't done any serious python ever) but I am wondering if anyone is interested and if there have been any thoughts on swapping GPIO libraries or supporting other GPIO libraries.

This might be interesting if the project would ever want to support boards other than the rpi.

[s-martin]

RPI.GPIO is used pretty much everywhere, so it would require some effort to support an additional GPIO library.
From my point of view we could discuss integrating an additional lib to support your use case, but somebody should provide a PR.

[chiefbrain]

I see that gpiozero has been used in v3.
I could make an effort to use WiringPi since I also want to use the mcp23017. A request to add port expanders is open in gpiozero since a while: gpiozero/gpiozero#199 but will never be merged (gpiozero/gpiozero#651).
Are there any specific reasons to use gpiozero?

[s-martin]

Hi,

from what I’ve read in the PR gpiozero/gpiozero#651 the decision by the gpiozero team was to not integrate it in the library directly, but suggesting to expand gpiozero‘s capability.
It seems @agruenberger wanted to do so and you could ask, if there exists an implementation or a module, which supports the required functionality.

From a Phoniebox project perspective these are my two cents, but others (@pabera, @AlvinSchiller may want to jump in):

• V3 (future3) is the right place to add new features.
• gpiozero is the basis for all GPIO stuff and at this time we probably will not switch to another GPIO library
• However, if there‘s an additional library to support that functionality a PR is more than welcome! 🤗
• Adding feature to V2 is not encouraged as this version is becoming legacy right now and new features should be implemented for V3.

As I said new features and PRs are more than welcome!

you can also use our chat for more detailed discussions: https://matrix.to/#/#phoniebox_community:gitter.im