Running RF24 library on Orange PI

[mtiutiu]

Hello,
I managed to run this library(which is really great btw) on a Orange PI device using an older branch with no issues at all. I used the BBB arch as a template with spidev as this matches perfectly with this board. After using the latest updates I noticed something strange happening: the spidev device is opened infinitely and the system runs out of file descriptors resulting in program crash after a while.

Now what I did to partially fix this issue was to make sure that in the init method for spi the file descriptor(if it's valid) gets closed before doing an open again.

Modified spi.cpp file from arch/BBB subfolder:

void SPI::init()
{
    int ret;

    // close fd if it's already open
    if(this->fd > 0) {
        close(this->fd);
    }

    this->fd = open(this->device.c_str(), O_RDWR);
    if (this->fd < 0)
    {
        perror("can't open device");
        abort();
    }
...

I guess that somewhere the spidev device is initialized again and again in some method from the library where it shouldn't be. I'm using the python wrapper in my application btw. I checked my application and I don't call the init method in an infinite loop so I'm assuming that there may be an implementation problem in the library - I see that the init method is called now at each spi transfer.

This is just a partial fix I would say as it doesn't really fix the root cause and I don't have too much time to investigate more. Maybe this will help someone with a similar issue or maybe it can be added as an enhancement to the library. As a side note: I'm not an experienced programmer and I'm still learning - this is my first issue published on github so please don't be too harsh on me:).

[TMRh20]

this is my first issue published on github so please don't be too harsh on me

Hehe, specifically identifying the issue and providing a workaround is a pretty good first try.

Kind of sounds like a case of fix one thing break another. I have a feeling this issue is related to: #138

In short there seems to have been some changes to kernel driven SPI using spidev on RPi. I haven't been able to look into it further myself, but it looks like your workaround fixes the workaround I implemented for it initially...

[TMRh20]

Fix/workaround added to master branch, to be added in next release.