You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It attempts to set up edge detection on SPI's default CE0 pin.
Run this without SPI enabled and it will work fine.
Run it with SPI enabled, and it will fail with "RuntimeError: Failed to add edge detection".
This has changed from previous behaviour and is no doubt the fault of changes as of the 5.x Linux kernel (the new mutually exclusive gpiochip instead of sysfs) and is, furthermore, no doubt fully intended behaviour depite the fact it breaks some potential back-compatibility cases including the use of CS0 to read a moisture channel on the Grow board.
Yes in retrospect using a channel "reserved" by the SPI device in this way was probably never a wise thing to do. But what's done is done.
The fix is simple enough. You must re-allocate the offending chip select channel to a different pin. There's a dtoverlay for this:
dtoverlay=spi0-cs,cs0_pin=14 # Re-assign CS0 from BCM 8 so that Grow can use it
This allocates CS0 to BCM14 (UART transmit) (currently unused by Grow) so that the above code will work in both cases.
This line should be added to the Grow installer to be placed in /boot/config.txt and we should consider moving that pin in a future revision (groan).
We should also communicate the addition of this line to end-uers, since it has the very real possibility of making SPI devices appear not to work if they're in the habit of swapping between HATs. (double groan)
I desperately needed to use the only hardware UART on a Pi Zero, so just moved the unused CS0 pin assignment to GPIO26, dtoverlay=spi0-2cs,cs0_pin=26
A neater workaround for my case, would be to use dtoverlay=spi0-1cs,cs0_pin=7 and change the ST7735 initialization to use CS0? Frees a pin
I'd also had a quick try with spi0-0cs, but didn't work out-of-the-box, and wasn't sure if 1) display had CS permanently enabled, 2) what spidev doc's no_cs flag meant by "although the driver may still own the CS" - which would possibly free two pins?
Anyway am very happy with the grow-hats - given there's a trivial workaround for HW serial, and i2c is neatly broken out, doubt I'll be trying to pilfer more pins soon.
This was apparently added to the install script code (and as an exception handler in the Moisture code) some time ago and is in the current (0.0.3) version but the requirements have changed for Bookworm. config.txt is now located at /boot/firmware/config.txt and spi0-cs is now named spi0-2cs.
I may take a stab at trying to fix the install script later but no promises...I'm leaving a note here for the historical record.
I'm curious though: is this even still an issue for Bookworm, given all the GPIO changes?
As of the recently Kernel 5.4.51 it's no longer possible to
add_event_detect
on an SPI Chip-Select pin while the SPI interface is enabled.To replicate use the following code snippet on a 5.4.51 Pi vs the previous kernel:
It attempts to set up edge detection on SPI's default CE0 pin.
Run this without SPI enabled and it will work fine.
Run it with SPI enabled, and it will fail with "RuntimeError: Failed to add edge detection".
This has changed from previous behaviour and is no doubt the fault of changes as of the 5.x Linux kernel (the new mutually exclusive gpiochip instead of sysfs) and is, furthermore, no doubt fully intended behaviour depite the fact it breaks some potential back-compatibility cases including the use of CS0 to read a moisture channel on the Grow board.
Yes in retrospect using a channel "reserved" by the SPI device in this way was probably never a wise thing to do. But what's done is done.
The fix is simple enough. You must re-allocate the offending chip select channel to a different pin. There's a dtoverlay for this:
This allocates CS0 to BCM14 (UART transmit) (currently unused by Grow) so that the above code will work in both cases.
This line should be added to the Grow installer to be placed in
/boot/config.txt
and we should consider moving that pin in a future revision (groan).We should also communicate the addition of this line to end-uers, since it has the very real possibility of making SPI devices appear not to work if they're in the habit of swapping between HATs. (double groan)
I have raised a counterpart issue against RPi.GPIO to notify others who might have fallen into this trap: https://sourceforge.net/p/raspberry-gpio-python/tickets/184/
The text was updated successfully, but these errors were encountered: