-
Notifications
You must be signed in to change notification settings - Fork 3
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
supplement SPIDEV & RPi drivers with copy of linux/gpio.h #49
Conversation
- updates RF24 submodule to nRF24/RF24@af7fbec - check in copy of linux/gpio.h (& exclude from clang-format checks) - adjust root CMakeLists.txt to supplement build with linux/gpio.h (only for SPIDEV & RPi drivers)
0178a84
to
635d3b0
Compare
This comment was marked as resolved.
This comment was marked as resolved.
I'm
I'm going to revert the progress on exposing the GPIO & interrupt function in this PR. Maybe I'll revisit this later, but I'm more inclined to recommend another approach that doesn't use |
4eba61d
to
0967702
Compare
I'm getting network layer problems with the new SPIDEV GPIO implementation. I think its a build system problem though. Taking a break for now... (these new error messages are nice indeed) |
Ok, I fixed the build. The C++ libs are built as shared binaries (libcpp_rf24*.so files). Then the appropriate python bindings will link into the shared binaries. This means a slightly faster build time (from source) and a smaller binary distributable size. If running a 64-bit OS on a RPi (doesn't have to be RPi OS, could be Ubuntu), then the test release (built on aeddaf3) is available via
This also doesn't break with piwheels (which we rely on for 32-bit binary distributions) as the source distribution is still installable if cmake and python3-dev are installed. TBH, this is how the package build process should have been from the start. But I was so fed up with CMake at the time that I went with the old hacky solution which surprisingly worked. |
I forgot to mention, the network layers are using the same GPIO cache as the core RF24 layer because they all link to the same shared binaries (libcpp_rf24.so). So it is back to a working condition. I don't have an RPi5 to verify, but it should work the same as the C++ installs, except this package uses isolated binary drivers (not the |
switch from RPi.GPIO to gpiod
resolves #48
RF24_NO_INTERRUPT
(since pigpio is no longer required dependency for IRQ support)expose GPIO & interrupt functions in newdigital_io
modulegpiod
instead ofRPi.GPIO
. This change means we're not actually usingmultiprocessing
in the example. Python dev should be clever enough to adapt the example to suit their needs.