pimoroni / grow-python

Python libs for controlling the Grow HATs
MIT License
57 stars 43 forks source link

Moisture channel 2 (BCM8) conflicts with SPI0 CS0 as of 5.4.51 kernel #1

Open Gadgetoid opened 4 years ago

Gadgetoid commented 4 years ago

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:

import RPi.GPIO as GPIO

GPIO.setmode(GPIO.BCM)
GPIO.setup(8, GPIO.IN)

def test(pin):
    pass

GPIO.add_event_detect(8, edge=GPIO.RISING, callback=test)

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 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/

bsimmo commented 3 years ago

just to say thanks for the explanation. I wondered what that was for. Luckily this one isn't swapping hats. .

earcam commented 11 months ago

Hello,

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.

Thanks