-
Notifications
You must be signed in to change notification settings - Fork 1k
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
RF24/RF24.h + wiringPi.h = Segmentation Fault #613
Comments
Are you sure you compiled correctly with wiringPi? The bcm2835_peri_read () in output would indicate you are using the bcm2835 driver.
For wiringPi you want:
./configure —driver=wiringPi
make
sudo make install
Then plz make sure you are using the correct pin #s for wiring Pi.
I haven’t tested it myself but don’t see why it would be a problem unless you are trying to use a pin that RF24 is using. Have you tested different pins and tested without RF24?
… On Aug 2, 2020, at 7:36 AM, Allen Landsidel ***@***.***> wrote:
Using wiringPi v2.60 from the "unofficial" github repo, and RF24 1.36 from here on a CanaKit RPi 3b+ running Raspbian 10. I've been successfully using the RF24 library to communicate between this RPi and several Arduino's, using C/C++ on both ends.
I want to add GPIO capability to the RPi alongside the RF24 support, so I added <wiringPi.h> before <RF24/RF24.h> in the RPi project and added some code, which resulted in a Segmentation Fault.
The call to wiringPiSetup() succeeds, but the following call to pinMode(25, INPUT); causes the SIGSEV when uncommented.
The gdb backtrace says the issue is happening in RF24 which seems odd, I would expect it to be in WiringPi. Is RF24 overriding the pinMode() call?
(gdb) bt
#0 0x76f1fb58 in bcm2835_peri_read () from /usr/local/lib/librf24.so.1
#1 0x76f1fc38 in bcm2835_peri_set_bits () from /usr/local/lib/librf24.so.1
#2 0x000133dc in main (argc=<optimized out>, argv=<optimized out>) at ./src/server.cpp:80
server.cpp:80 is the aforementioned line, pinMode(25, INPUT);
Is there an alternative way to get WiringPi playing nicely with RF24, or if not, is there a recommended GPIO library to use alongside RF24?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
I'm pretty sure I didn't use that driver configuration option when building RF24 since I wasn't using wiringPi at the time. I'm rebuilding it now and will let you know, thanks. |
That looks like it solved the issue, thanks. The pin numbering isn't showing the correct mapping in |
I think that’s normal. RPi docs seem to refer to the CSN/CS pins as CE
Unfortunate because RF24 has CSN/CS and CE for the separate control pins.
… On Aug 2, 2020, at 8:50 AM, Allen Landsidel ***@***.***> wrote:
That looks like it solved the issue, thanks. The pin numbering isn't showing the correct mapping in gpio readall I think (CS0 on the board is marked CE0 in gpio) but I'm investigating that.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using wiringPi v2.60 from the "unofficial" github repo, and RF24 1.36 from here on a CanaKit RPi 3b+ running Raspbian 10. I've been successfully using the RF24 library to communicate between this RPi and several Arduino's, using C/C++ on both ends.
I want to add GPIO capability to the RPi alongside the RF24 support, so I added
<wiringPi.h>
before<RF24/RF24.h>
in the RPi project and added some code, which resulted in a Segmentation Fault.The call to
wiringPiSetup()
succeeds, but the following call topinMode(25, INPUT);
causes theSIGSEV
when uncommented.The gdb backtrace says the issue is happening in RF24 which seems odd, I would expect it to be in WiringPi. Is RF24 overriding the pinMode() call?
server.cpp:80
is the aforementioned line,pinMode(25, INPUT);
Is there an alternative way to get WiringPi playing nicely with RF24, or if not, is there a recommended GPIO library to use alongside RF24?
The text was updated successfully, but these errors were encountered: