Raspberry Pi5

[bsimmo]

So, I know it's not going to work, but is there any development toward getting it working on the Pi5 (yes absolute overkill) and PiOS Bookworm, I can see some talk but not sure which branch you are using for it.

Personally, I'll be creating a venv in /opt as I have another python daemon/service working from there under venv's, so just git pulling to do it, creating a venv, hopefully just using requirements for all the pip modules to come down and then that keeps it well away from my other python stuff. (the point of venv's and the main reason for the change by Debian/Python)

import RPi.GPIO as GPIO obviously the biggest killer. So lgpio/gpiozero ?

/opt may well go to Home, depending on which is easier.

[Gadgetoid]

Work in progress is here - https://github.com/pimoroni/grow-python/pull/36

I can't use lgpio or gpiozero because gpiozero uses lpgio as its default back-end, and lgpio does not have a functional package on pypi. Effort has been in switching to libgpiod/gpiod which I've helped make available via pypi - https://pypi.org/project/gpiod/

The downside of gpiod is that it's interested only with the kernel GPIO character device ABI, so things we've come to take for granted in RPi.GPIO such as PWM and watching a pin status/attaching an interrupt (which are mostly handled by tight loops) are not handled at all.

My work in progress code tries to do PWM in Python, something we currently need to do since the pins used to PWM Grow's pumps are not hardware PWM capable. I'm currently down a rabbit hole of trying to figure out how best to nudge about this proposal- https://lore.kernel.org/all/20201205214353.xapax46tt5snzd2v@einstein.dilieto.eu/

[tomjn]

@Gadgetoid would it make sense to do the following:

1. add the new library
2. convert everything that can be to the new library currently
3. abstract out the PWM part
4. on Pi4 use the old library for PWM
5. on Pi5 return a n/a type value and disable that functionality until PWM is implemented in python
6. when PWM is implemented a new PR can be merged that replaces the above

I know this means a period of compromised functionality for Pi5 users, but this is better than it just point blank failing with cryptic message, we can just print out a message that it's upcoming. It also avoids people hacking on the code using the old library

[bsimmo]

I think he's knee deep in getting gpio going across the board.

Now a short/long term option is to use gpiozero*, it's stable W.R.T the way a user puts it together. Then if the new Pi5superGPIO get working add it as another option to the pin library backend.

Pi4 and before can use pigpio/RPi.GPIO as they wish, Pi5 can use lgpio for now until some other pin library is made and can be bolted into the back end. It also allows mock libraries to be used for testing. 😂

Honestly I'm leaving @gadgetoid to curse and create. Hoping RPi don't drop a new RPxxxx out of the door.

But you're then relying on RPi to keep at it with gpiozero* and some of them don't work for RPi anymore.

[Gadgetoid]

The trouble with gpiozero is that it's just a wrapper for existing IO libraries. So under the hood on Pi 5 it uses LG/LGPIO, which has no installation candidate on Pypi, and thus cannot be installed into virtual environments without enabling system-site-packages and rendering the whole virtual environment completely redundant... please hold for a moment while I scream into a pillow...

Okay...

@tomjn that's a sensible idea and should unblock me in the near term. My efforts to nudge about the generic PWM driver on the linux-pwm mailing list have so far run into "I have no idea what I'm doing" territory. Soft PWM in Python on the Pi 5 isn't terrible... at least until it gets interrupted by another process, or crashes- it seems some people like the Pi to retain pin state when an application bails, which is... unwise.

[bsimmo]

I get you with gpiozero, it was just general compatibility, of course with its own restrictions. The python part of lgpio is on pypi? Sure I noticed it there. Joans https://pypi.org/project/lgpio/

I've been reading that pin talk for libgpiod(2) As a side and the throw yet another thing into the expanding ring, I believe waveform80 has created an RPi.GPIO compatible layer that can be used on a Pi5, it need the PI4 removing and the new one with a different name installing. Mentioned buried in the Pi forum somewhere. Hang on https://rpi-lgpio.readthedocs.io/en/release-0.4/index.html

But I am getting confused now between all the gpio sounding modules and libraries.

On Tue, 23 Jan 2024, 12:33 pm Philip Howard, @.***> wrote:

The trouble with gpiozero is that it's just a wrapper for existing IO libraries. So under the hood on Pi 5 it uses LG/LGPIO, which has no installation candidate on Pypi, and thus cannot be installed into virtual environments without enabling system-site-packages and rendering the whole virtual environment completely redundant... please hold for a moment while I scream into a pillow...

Okay...

@tomjn https://github.com/tomjn that's a sensible idea and should unblock me in the near term. My efforts to nudge about the generic PWM driver on the linux-pwm mailing list have so far run into "I have no idea what I'm doing" territory. Soft PWM in Python on the Pi 5 isn't terrible... at least until it gets interrupted by another process, or crashes- it seems some people like the Pi to retain pin state when an application bails, which is... unwise.

— Reply to this email directly, view it on GitHub https://github.com/pimoroni/grow-python/issues/43#issuecomment-1905965342, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACYAXN4CHLWFPDTB5S45B53YP6UYLAVCNFSM6AAAAABBYBKUROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBVHE3DKMZUGI . You are receiving this because you authored the thread.Message ID: @.***>