on bcm2835, grabs CE1 unnecessarily

[combs]

Describe the bug

On my Pi 4 running current Raspbian, I am using GPIO 7 for another purpose (I2C 4 SCL).

The bug: When I initialize RF24, it forces GPIO 7 to become CE1 for SPI0, even if my RF24 device is attached (and configured to use) CE0.

https://github.com/nRF24/RF24/blob/master/utility/RPi/bcm2835.c#L699

In my ideal world, it would initialize only CE0 or CE1, depending on which CE is chosen by the user.

raspi-gpio get output, pins 5-11, before RF24 init:

GPIO 5: level=1 fsel=2 alt=5 func=SCL3 pull=UP
GPIO 6: level=1 fsel=2 alt=5 func=SDA4 pull=UP
GPIO 7: level=1 fsel=2 alt=5 func=SCL4 pull=UP
GPIO 8: level=1 fsel=1 func=OUTPUT pull=UP
GPIO 9: level=0 fsel=4 alt=0 func=SPI0_MISO pull=DOWN
GPIO 10: level=0 fsel=4 alt=0 func=SPI0_MOSI pull=DOWN
GPIO 11: level=0 fsel=4 alt=0 func=SPI0_SCLK pull=DOWN

raspi-gpio get output, pins 5-11, after RF24 init:

GPIO 5: level=1 fsel=2 alt=5 func=SCL3 pull=UP
GPIO 6: level=0 fsel=2 alt=5 func=SDA4 pull=UP
GPIO 7: level=1 fsel=4 alt=0 func=SPI0_CE1_N pull=UP
GPIO 8: level=1 fsel=4 alt=0 func=SPI0_CE0_N pull=UP
GPIO 9: level=0 fsel=4 alt=0 func=SPI0_MISO pull=DOWN
GPIO 10: level=0 fsel=4 alt=0 func=SPI0_MOSI pull=DOWN
GPIO 11: level=0 fsel=4 alt=0 func=SPI0_SCLK pull=DOWN

My application code is using the Python binding and looks like this:

            self.radio = RF24(self.cePin, self.csnCENumber, self.spiSpeed)

where "nrf_ce":22, "nrf_csn_ce": 0

Additional context

note: I have tried the spi0-1cs dtoverlay; RF24 still force-enables the CE1 pin.

I have also tried dtparam=spi=off and RF24 creates the SPI bus automatically (handy!) but grabs CE1. Can't see any logic that would avoid CE1 grab if CE0 is specified.

[2bndy5]

Hmm. This is interesting. Have you tried using the SPIDEV driver instead of the RPi driver?

Since we really don't modify the bcm2xxx src, I would think this bug needs to be elevated upstream, but I might be missing something... I also have no idea where the bcm2xxx src is hosted from (its docs only provide a direct download - nothing is said about version control)

[2bndy5]

from http://www.airspayce.com/mikem/bcm2835/

When bcm2835_spi_begin() is called it changes the bahaviour of the SPI interface pins from their default GPIO behaviour in order to support SPI. While SPI is in use, you will not be able to control the state of the SPI pins through the usual bcm2835_spi_gpio_write(). When bcm2835_spi_end() is called, the SPI pins will all revert to inputs, and can then be configured and controled with the usual bcm2835_gpio_* calls.

[2bndy5]

@combs You could research the issue more at the google groups discussions page pointed to by the bcm2xxx libs home page

https://groups.google.com/g/bcm2835/search?q=bcm2835_init

[combs]

Oh right, I don't know why I didn't think to try the SPIDEV driver already. Bet that'll fix it. Will try tomorrow or Monday and report back. Thank you!

[2bndy5]

ping

[combs]

Oops, thanks. I got this working in my project with the SPIDEV driver. I believe this was caused by the behavior in bcm2835.h. (More about why I need three i2c buses here, if you're curious.)

I will do some more careful testing sometime soon and reopen this issue if there's anything in RF24 causing it.

Thank you for all of your work on this library!