Phasing out most Linux drivers

[2bndy5]

I'm of the opinion that all but SPIDEV should be phased out.

• MRAA isn't well maintained since Intel passed it on to the eclipse github org; contributions don't seem to be well verified/tested. And it stopped working on the RPi4.
• BCM2835 can't really support RPi5 using interactions with CPU registers due to the hardware abstraction on RPi5.
• pigpio is practically in the same position as BCM2835 lib concerning RPi5 support. They'd have to overhaul the lib's internals to behave more like the newer lgpio lib of the same author, but that would introduce breaking changes to the API.
• wiringPi has been limping on via sparse community support since Gordon ended official development. The more I dive into that lib's source, the less appealing it is. Long story made short: its old and not well written.
• Has littlewire ever worked? The source I found is not compatible with the driver API we have. The header that our littlewire driver looks for no longer exists in the littlewire sources, and I can't even figure out when that changed using git blame.

Originally posted by @2bndy5 in #969 (comment)

[2bndy5]

I don't expect to actually remove anything until RPi7 gets produced. We can hard-code the build systems to select SPIDEV despite the presence of other needed libraries. This should be the least breaking approach we can do to dissuade users from selecting other (seemingly unreliable) drivers.

[marksolly]

I see you haven't had a lot of feedback on this yet. I have just stumbled into this library today specifically because of the BCM2835 driver support and needing ultra low latency access to an nRF24 to achieve 160us round trip times from reading RX FIFO to writing to the TX FIFO. This has proven impossible with spidev/ioctl calls. It would be a shame to see direct BCM2835 support dropped while any hardware that supports it remains available for purchase.

[2bndy5]

In my experience, the SPIDEV driver is noticeably faster than the RPi driver (using BCM2835) when running examples in hardware tests. Maybe the radio settings used in the examples affect this observation?

There are other quirks about the BCM2835 library that we cannot control. For example, the BCM2835 lib will "own" the I2C bus when it is used to initialize an SPI bus, and certain pins other than CEx pins (like I2S pins) are set HIGH unexpectedly as well. Controlling a secondary SPI bus' CS pin(s) with the BCM2835 lib isn't the same as controlling the primary SPI bus' CS pin(s), which results in bloated code or unexpected behavior (like not able to share a secondary SPI bus with multiple SPI peripherals).

Again, the BCM2835 lib's days are numbered; there is no way to get that lib working on a RPi5 (and likely future RPi models) because RPi hardware design changed so significantly in RPi5.

The main problem here is maintainability and compatibility. Maintaining 1 Linux driver instead of a multitude (whose source code we cannot control) is a big 👍🏼. Its hard enough to maintain the SPIDEV driver because the Linux kernel docs are famously not helpful, but at least we don't have to worry about what hardware is support with the Linux kernel.

This issue is actually part of our project named "RF24 v2.0 ideas". So, when we address it, there will be a major version bump to signify breaking changes.

History

The main reason there were so many different driver implementations (for GPIO and SPI access) is because the Linux kernel's "sys fs" interface was woefully inadequate. Now that we have migrated to the Linux kernel's "char dev" interface, there is no reason to use any other driver library; it works fast on any Linux (not just RPi OS).

We don't even require libgpiod installed (which isn't pre-installed on most Linux OS distros) since it just wraps around the Linux kernel's char dev interface.