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 - #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 <#43 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYAXN4CHLWFPDTB5S45B53YP6UYLAVCNFSM6AAAAABBYBKUROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBVHE3DKMZUGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[OliverPage]

Hey, any updates on Bookworm/Pi5 compatability?

[Gadgetoid]

Despite the apparent lack of progress, I've been slowly poking behind the scenes so not one, but two reliable ways to achieve PWM on the Pi 5 are continuing to work their way through the pipeline.

Linux PWM still somewhat has the wart that it'll continue rampaging on if your program crashes- this was one of the things the GPIO Character Device ABI fixed with its "claim pins" workflow.

I think the rpi-lgpio wrapper might work, though setup would be a little manual. It's been so long I forgot what the issues with installing lgpio into a virtualenv actually were.

You'd need to create a virtualenv (https://pimoroni.github.io/venv-python/) and:

pip install rpi-lgpio growhat numpy pillow

Then clone this repo and try to run the examples directly.

[bsimmo]

I think the issue was there wasn't a module to install with pip until RPi eventually got involved. Probably.

[Gadgetoid]

IIRC all the releases that are there now were there when I ran into the problem, so I poked some people so Ben and Dave were added as maintainers (neither work for RPi though they do RPi adjacent stuff) and now it works? Maybe they yanked and re-issued a release or I've just forgotten what the most recent release was in the intervening months. Weird!

I should probably give it a more thorough test tomorrow, since it's a perfectly fine stand-in while I continue to grapple with Linux PWM.

[OliverPage]

Hey, I finally got around to trying it, and can confirm that the grow hat works on the RPi5!
Unfortunately I am now struggling to get the grow hat to start as a service on boot, I believe that the issue is caused by the fact that I installed the python libraries in a venv, and the script doesn't know this. I would greatly appreciate any help as to how to get the service from a venv.
Thanks in advance!

[Gadgetoid]

In a startup script you should just be able to replace python with the full path to the virtualenv's Python, which might be something like:

/home/<youruser>/.virtualenvs/pimoroni/bin/python

[OliverPage]

Thanks. Do you know where I can find the startup script?
I see that I should edit /etc/systemd/system/grow-monitor.service. The default file look like this:

[Unit]
Description=Grow Monitoring Service
After=multi-user.target

[Service]
Type=simple
WorkingDirectory=/usr/share/grow-monitor
ExecStart=/usr/bin/grow-monitor /etc/default/grow
Restart=on-failure
StandardOutput=syslog+console
StandardError=syslog+console

[Install]
WantedBy=multi-user.target

My assumption is to change ExecStart, but I currently I can't figure out how...

[jlbrewer]

@OliverPage Your ExecStart line should look like this:

ExecStart=/path/to/.virtualenvs/pimoroni/bin/python /usr/bin/grow-monitor /etc/default/grow

(Edit the venv path as needed, mine is based on the installer's initial attempt to set up a venv in /home/user/.virtualenvs/pimoroni )

[OliverPage]

Many thanks! I sorted it a while and forgot to update you guys, nonetheless your response is appreciated.