Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Gadgetoid opened this issue Jul 27, 2020 · 3 comments
Open
Labels
bug Something isn't working enhancement New feature or request

Comments

@Gadgetoid
Copy link
Member

Gadgetoid commented Jul 27, 2020

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/

@Gadgetoid Gadgetoid added bug Something isn't working enhancement New feature or request labels Jul 27, 2020
@bsimmo
Copy link

bsimmo commented Aug 23, 2021

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

@earcam
Copy link

earcam commented Oct 20, 2023

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

@jlbrewer
Copy link

jlbrewer commented Feb 26, 2025

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants