Interrupts not available on RPi OS/Bullseye (No WiringPi)

[TMRh20]

With the move to Bullseye, wiringPi is deprecated and no longer available for RPi. This means interrupts will not work on RPi anymore for users that have made the move to Bullseye. Whether using the SPIDEV or BCM driver, we used wiringPi for interrupts. In looking around, most of the GPIO C libraries support standard GPIO functions, but not interrupts, so I'm not sure exactly where to go with this one.

[2bndy5]

RPi.GPIO?
pigpio?

I know these are python bindings, but they are written c++ and boast interrupts.

maybe we should double-down on MRAA support

[TMRh20]

Isn’t that python?

…

On Jan 3, 2022, at 8:03 AM, Brendan ***@***.***> wrote:  RPi.GPIO? — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.

[2bndy5]

I think pigpio can be used from C++. It looks like RPi.GPIO is strictly for CPython.

MRAA looks promising (because we already have the backend for it), but its maintenance has been looking sparse over the last few years. Conversely, MRAA transcends armhf and aarch64 arc types; I was able to compile RF24 for various other platforms in the revised build_linux.yml CI (see commented out portions).

On a side note, CircuitPython has started building their own OS img for the RPi4/CM4 and RPi0W2, but it is still in early stages and I'm not sure if it will allow C++ extended python libs (though they merged in the latest changes from MicroPython which can be used with C++ extended libs).

[2bndy5]

With the move to Bullseye, wiringPi is deprecated and no longer available for RPi

Does this mean we can officially deprecate WiringPi support? (keep it in there but with less maintenance for it) I know many people have migrated to the unofficial mirror. but installing that without puging the wiringPi install from apt will lead to unforeseen problems (related to different install locations without conscious modification when installing the unofficial mirror). BTW, it looks like the unofficial mirror has been on its last legs for a while as well.

[TMRh20]

MRAA would be promising, but I don't think they've updated it for the RPi4. Per this link they only list pin combos for earlier models of the pi, and I can't seem to get it working on my RPi4... It works up to RPi3, but not on my RPi4.
I'll take a closer look at pigpio I guess.

Yeah, I think we can start to look at deprecating wiringPi support since everybody else is lol.

[2bndy5]

pigpio sounds like an exciting new challenge! I think this is the function needed to enable/disable IRQ callbacks.

It looks like the mraa docs haven't been updated since 2.0 (they're at v2.2.0 now). Looked into this... It seems that RPi4 support is very basic at this stage (introduced in v2.1.0), so you may have hit a worthy new issue (regarding interrupts only or basic gpio usage?) for the eclipse/mraa repo.

[TMRh20]

I think basic GPIO or SPI usage, I get a hardware failure error on the rpi4. I’ll have to look into that more…

…

On Jan 3, 2022, at 9:17 AM, Brendan ***@***.***> wrote:  pigpio sounds like an exciting new challenge! I think this is the function needed to enable/disable IRQ callbacks. It looks like the mraa docs haven't been updated since 2.0 (they're at v2.2.0 now). Looked into this... It seems that RPi4 support is very basic at this stage (introduced in v2.1.0), so you may have hit a worthy new issue (regarding interrupts only or basic gpio usage?) for the eclipse/mraa repo. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.

[TMRh20]

Having some problems including pigpio in the workflow for these changes, I think I screwed it up. Could you take a look at it @2bndy5 ? I'm not very familiar with workflows etc. on github. In the pigpio branch...

[2bndy5]

already on it. I'd prefer we install pigpio from latest src as using apt usually yields outdated resources.

[2bndy5]

good news

pigpio has CMake support. This is good because I can't seem to cross-compile pigpio using their hand-crafted Makefile; it doesn't seem to like using variables from the CLI or env 🤷🏼 . Furthermore, the cmake/toolchains/*.cmake scripts I made for RF24 are generic enough to use with pigpio's CMakeLists.txt 💯

bad news

The CMake support in pigpio is apparently a community contribution and may need to be updated as such. For example, the pigpio latest version is 79, but the CMakeLists.txt has the version number hardcoded to 71 (probably from when the CMake contribution was introduced). So, we might have to keep an eye on that in future workflow runs.

moving on

I think using pigpio as a dependency may limit compiling RF24 for other platforms (specifically not broadcom chips). Should we discuss how to make IRQ features optional on Linux?

I personally don't mind because I don't use BeagleBone or other RPi clones. Coincidentally, I think the historic reliance of using wiringPi for IRQ features could prove that end-users aren't using RF24 for non-BCM chips.

[TMRh20]

Should we discuss how to make IRQ features optional on Linux?

Yeah, with the way it looks I'm thinking we will want to make IRQ support optional, keeping the dependencies as minimal as possible for a default install. Pigpio is starting to look like more trouble than it's worth, although it is nice to have interrupts on the RPi, to limit CPU load and have quick response times.

[2bndy5]

Pigpio is starting to look like more trouble than it's worth

Its definitely less trouble than I was having trying to continue supporting the undead wiringPi. I'll be glad to finally put #669 to rest.

I have to look at the src in utility dir again, but I think I can auto-enable IRQ support when the build system detects presence of a BCM chip (like the RPi driver option does).

[TMRh20]

Ok, we will have to remember to put something in the docs about pigpio too

…

On Jan 3, 2022, at 3:32 PM, Brendan ***@***.***> wrote:  Pigpio is starting to look like more trouble than it's worth Its definitely less trouble than I was having trying to continue supporting the undead wiringPi. I'll be glad to finally put #669 to rest. I have to look at the src in utility dir again, but I think I can auto-enable IRQ support when the build system detects presence of a BCM chip (like the RPi driver option does). — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.

[2bndy5]

This just occurred to me: We could provide pigpio as a separate driver entirely. Although, this would make RPi & SPIDEV drivers not use IRQ feature, but this, to me, sounds like the path of least resistance (in terms of a sustainable build system). It also concurs with other drivers that conditionally provide their own IRQ support (as in not wrapped by RF24 utility srcs) like MRAA, RP2040, & other specialized arduino-based platforms (like ATTiny & the Teensy).

TBH, this is kinda the idea I was expecting when taking on pigpio to begin with.

[TMRh20]

I wouldn’t mind adding pigpio as its own driver, but it would still be nice to have interrupt support for the SPIDEV driver at least. I guess it’s easy enough for users to add their own interrupt handling, but it is good to have on a Linux system. I guess the question is who’s going to write the code? I’m up for it but prob can’t do it right away.

…

On Jan 4, 2022, at 10:58 AM, Brendan ***@***.***> wrote:  This just occurred to me: We could provide pigpio as a separate driver entirely. Although, this would make RPi & SPIDEV drivers not use IRQ feature, but this, to me, sounds like the path of least resistance (in terms of a sustainable build system). It also concurs with other drivers that conditionally provide their own IRQ support (as in not wrapped by RF24 utility srcs) like MRAA, RP2040, & other specialized arduino-based platforms (like ATTiny & the Teensy). TBH, this is kinda the idea I was expecting when taking on pigpio to begin with. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.

[2bndy5]

I’m up for it but prob can’t do it right away.

Dito. My head space is in a JS wormhole right now (sincerely trying to learn node.js & npm deployment). Last time I wrote a MCP300x driver for pigpio (in python), I had several tabs open to the same page because navigating the pigpio docs are worse than using doxygen.

would still be nice to have interrupt support for the SPIDEV driver

I did a quick look today into how we might use the Linux kernel to use IRQ independently from other drivers. But that approach might be a little too low level for me; I would prefer to use a middleware API for the SPIDEV driver that provides basic IRQ features (or maybe I'm just not used to reading the Linux kernel docs). It might be worth poaching an approach used for another Linux HW lib (maybe even something that uses I2C like the MCP23017).

---

I am curious also about the standalone driver's performance using pigpio. Mainly because it uses a background system service. I should investigate further, since the daemon may also appropriate HW resources when users try using a mix of GPIO API libs (1 of which would be pigpio) simultaneously. However, we hit upon a similar issue with the RPi driver (#785), so it would be nice to have an option that could potentially avoid forcing users to use different GPIO access libs at the same time.

[TMRh20]

Well I had a chance to port RF24 over to pigpio and it works fine on earlier model RPIs, but not on my RPI4. I think its a GPIO problem, because it looks like the CE pin toggling isn't working. SPI transfers seem to work ok. I may create an issue in pigpio for this if I can dig into it a bit more and get more info.

[2bndy5]

I just compiled the pigpio_driver branch with the pigpio driver on my RPi4 and ran gettingstarted with no problems. However, my RPi4 is apparently still using the buster based OS... I'll have to upgrade and report back; just thought I'd share this little success on backward compatibility.

[2bndy5]

Ok, I completed the update (with apt upgrade performed) on a fresh bullseye img. After running gettingstarted without serious problems (had to use sudo this time for pigpio driver), I had to lower my SPI speed (which seems to be a req for my specific RPi4 setup). After that, there were no problems at all.

@TMRh20 Is there any additional steps to reproduce the problem you're experiencing?

[TMRh20]

No additional steps. That makes me wonder wtf.
For kicks, I ran the prog again and got partial results when I saw this post?? Poltergeists?? It was failing very consistently before...
So I power cycled the radio and lowered my SPI speed down to 1000000 and it is kind of working.
I know I tried that before... Something funky with my RPi4? It seems I'm having to power cycle the radio when things go funky. Tried with 2 different radios, so don't think its a radio issue.

It was getting stuck very consistently at transmission using the gettingstarted example. Right where it sends 4 bytes then toggles the CE pin, then I was getting RF24 HARDWARE FAIL: Radio not responding, verify pin connections, wiring, etc. and was getting back a value of 0111 instead of the TX_DS or MAX_RT flags being set. At first it was still failing some of the time, even with the lowered SPI speed, but right now I have it working kind of consistently lol.

I know for a fact I tried lowering the SPI speed before, maybe I had something funky in the code at that point... I dunno, but I guess its good that it works now lol...
It still fails pretty consistently if I go back to 10mhz SPI, but SPIDEV works fine on this RPI4 at 10mhz...
Works fine on earlier model RPI at 10mhz also.

Another reason I should have a logic analyzer...

[2bndy5]

That's kinda good to hear.

I tried setting up my logic analyzer, but all I managed to do is muck up the SPI connections (consistently got "radio not responding" on setup()); I use direct connections to an adapter board, so there's no good place to tap into the circuit without completely re-wiring. The analyzer's clips (cheapo clips I think) don't take to the board's/module's gpio solider points very well either.

Worth noting that the exact same wiring setup works on my RPi2 at default SPI speed. Furthermore, I had to lower my SPI speed when testing the CMake solution (SPIDEV & RPi drivers) on my RPi4 running Ubuntu. At first I was under the impression that the RPi4's SPI bus impedance was somewhat higher than previous models, but someone else reported consistent results on RPi4 with Ubuntu using the CMake solution & default SPI speed... 🤷

I'm pretty anal about keeping my modules powered down when not in use (power still supplied but radio in "sleep mode"). This was initially due to scheduled power outs and random brown outs here in California, but it lamented into habit during the diligent CMake testing.

[2bndy5]

There's been a difference in the API when using interrupts for MRAA and wiringPi. It usually results in a compilation error like so

brendan@B-DESKTOP:/mnt/c/Users/ytreh/Documents/GitHub/RF24Gateway/build$ make
Scanning dependencies of target RF24GatewayNode
[ 16%] Building CXX object CMakeFiles/RF24GatewayNode.dir/RF24GatewayNode.cpp.o
[ 33%] Linking CXX executable RF24GatewayNode
[ 33%] Built target RF24GatewayNode
Scanning dependencies of target RF24GatewayNodeInt
[ 50%] Building CXX object gwNodeInt/CMakeFiles/RF24GatewayNodeInt.dir/RF24GatewayNodeInt.cpp.o
/mnt/c/Users/ytreh/Documents/GitHub/RF24Gateway/examples/gwNodeInt/RF24GatewayNodeInt.cpp: In function ‘int main(int, char**)’:
/mnt/c/Users/ytreh/Documents/GitHub/RF24Gateway/examples/gwNodeInt/RF24GatewayNodeInt.cpp:44:23: error: ‘INT_EDGE_FALLIN
’ was not declared in this scope
   44 |   attachInterrupt(23, INT_EDGE_FALLING, intHandler);
      |                       ^~~~~~~~~~~~~~~~
/mnt/c/Users/ytreh/Documents/GitHub/RF24Gateway/examples/gwNodeInt/RF24GatewayNodeInt.cpp:44:3: error: ‘attachInterrupt’ was not declared in this scope
   44 |   attachInterrupt(23, INT_EDGE_FALLING, intHandler);
      |   ^~~~~~~~~~~~~~~
make[2]: *** [gwNodeInt/CMakeFiles/RF24GatewayNodeInt.dir/build.make:63: gwNodeInt/CMakeFiles/RF24GatewayNodeInt.dir/RF24GatewayNodeInt.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:144: gwNodeInt/CMakeFiles/RF24GatewayNodeInt.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

So, I've been operating under the assumption that MRAA and wiringPi drivers aren't fully supported for RF24Gateway lib examples that involve using interrupts (and RF24/examples_linux/interruptConfigure.cpp).

[TMRh20]

Yeah there is no interrupt support, but the non-interrupt examples should still work for Mraa and wiringPi

…

On Jan 23, 2022, at 10:43 PM, Brendan ***@***.***> wrote:  There's been a difference in the API when using interrupts for MRAA and wiringPi. It usually results in a compilation error like so ***@***.***:/mnt/c/Users/ytreh/Documents/GitHub/RF24Gateway/build$ make Scanning dependencies of target RF24GatewayNode [ 16%] Building CXX object CMakeFiles/RF24GatewayNode.dir/RF24GatewayNode.cpp.o [ 33%] Linking CXX executable RF24GatewayNode [ 33%] Built target RF24GatewayNode Scanning dependencies of target RF24GatewayNodeInt [ 50%] Building CXX object gwNodeInt/CMakeFiles/RF24GatewayNodeInt.dir/RF24GatewayNodeInt.cpp.o /mnt/c/Users/ytreh/Documents/GitHub/RF24Gateway/examples/gwNodeInt/RF24GatewayNodeInt.cpp: In function ‘int main(int, char**)’: /mnt/c/Users/ytreh/Documents/GitHub/RF24Gateway/examples/gwNodeInt/RF24GatewayNodeInt.cpp:44:23: error: ‘INT_EDGE_FALLIN ’ was not declared in this scope 44 | attachInterrupt(23, INT_EDGE_FALLING, intHandler); | ^~~~~~~~~~~~~~~~ /mnt/c/Users/ytreh/Documents/GitHub/RF24Gateway/examples/gwNodeInt/RF24GatewayNodeInt.cpp:44:3: error: ‘attachInterrupt’ was not declared in this scope 44 | attachInterrupt(23, INT_EDGE_FALLING, intHandler); | ^~~~~~~~~~~~~~~ make[2]: *** [gwNodeInt/CMakeFiles/RF24GatewayNodeInt.dir/build.make:63: gwNodeInt/CMakeFiles/RF24GatewayNodeInt.dir/RF24GatewayNodeInt.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:144: gwNodeInt/CMakeFiles/RF24GatewayNodeInt.dir/all] Error 2 make: *** [Makefile:84: all] Error 2 So, I've been operating under the assumption that MRAA and wiringPi drivers aren't fully supported for RF24Gateway lib (and RF24/examples_linux/interruptConfigure.cpp). — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.

[2bndy5]

✏️ Reminder 📝

Docs revision about IRQ should note difference in drivers' APIs and specify which lib is fully compliant with externally installed drivers

[2bndy5]

I have serious concerns using sudo to run python (specifically when a python venv is active). Its better if we recommend that people don't build RF24 with pigpio driver when installing the python wrapper. I have already disabled interrupt support (via -DRF24_NO_INTERRUPT) when building the python wrapper for RF24 because users can use pigpio's python API or RPi.GPIO API to do interrupt stuff from python scripts.

---

BTW, I haven't needed to use sudo python to run scripts using RF24 when built with SPIDEV, so I think its still worth learning to use the Linux kernel to implement IRQ support.

[2bndy5]

I got frustrated trying to child-proof the py wrapper's build process, so I returned to addressing nRF24/pyRF24#3... It is working, but there are nuances related to what driver was used to build the C++ lib.

Using the pyrf24 pkg will not inherit these nuances because the pkg is built in isolation (doesn't require the C++ libs installed).