You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been reviewing the portability drivers (using a different Arduino lib to implement them), and I found that the pigpio/spi.cpp doesn't appropriately parse the CSN value (which should correspond to /dev/spidevA.B) like the SPIDEV driver does.
If a user specifies csn_pin = [1 | 0], then the correct SPI bus is initialized, but using the secondary SPI bus requires the user to specify 1x where x is the spiChan param. I believe the correct way to specify the secondary SPI bus in pigpio is to use bit 8 in the spiFlags param.
Additional context
If RF24 allowed for using RF24::begin(_SPI*) in Linux, then it might be easier to use a user-instantiated SPI-wrapping object, but that's more of a breaking change 👎🏼 .
preludes to separate issues I have yet to open (still researching/testing)
I've also been exploring how to restructure the lib using a src folder. This would require extra compiler guards in our drivers' srcs since the Arduino IDE compiles everything found in a lib's src folder. The build system wouldn't suffer breaking changes since that stuff is flexible enough. The #include <RF24.h> would still work as it does now. This seems unimportant, but our root folder is getting rather cluttered (and people browsing GitHub aren't readily seeing our README).
It also occurred to me that our drivers' wrapping classes (tersely named) may conflict with a 3rd party lib's classes. But a namespace (ie RF24_arduino_wrappers) can be used to avoid that. Furthermore, we can add using namespace in the scope of RF24 functions that use the namespaced declarations.
This will ensure our wrapper API would only get used internally (as opposed to polluting the global namespace). This is important because some of our Arduino-wrapping implementations are designed specifically for our use case, not for general usage by other Arduino libs (which might require unexposed functionality).
The text was updated successfully, but these errors were encountered:
I've been reviewing the portability drivers (using a different Arduino lib to implement them), and I found that the pigpio/spi.cpp doesn't appropriately parse the CSN value (which should correspond to
/dev/spidevA.B
) like the SPIDEV driver does.See pigpio docs about
spiOpen()
If a user specifies
csn_pin = [1 | 0]
, then the correct SPI bus is initialized, but using the secondary SPI bus requires the user to specify1x
wherex
is thespiChan
param. I believe the correct way to specify the secondary SPI bus in pigpio is to use bit 8 in thespiFlags
param.Additional context
If RF24 allowed for using
RF24::begin(_SPI*)
in Linux, then it might be easier to use a user-instantiated SPI-wrapping object, but that's more of a breaking change 👎🏼 .preludes to separate issues I have yet to open (still researching/testing)
I've also been exploring how to restructure the lib using a src folder. This would require extra compiler guards in our drivers' srcs since the Arduino IDE compiles everything found in a lib's src folder. The build system wouldn't suffer breaking changes since that stuff is flexible enough. The
#include <RF24.h>
would still work as it does now. This seems unimportant, but our root folder is getting rather cluttered (and people browsing GitHub aren't readily seeing our README).It also occurred to me that our drivers' wrapping classes (tersely named) may conflict with a 3rd party lib's classes. But a namespace (ie
RF24_arduino_wrappers
) can be used to avoid that. Furthermore, we can addusing namespace
in the scope of RF24 functions that use the namespaced declarations.This will ensure our wrapper API would only get used internally (as opposed to polluting the global namespace). This is important because some of our Arduino-wrapping implementations are designed specifically for our use case, not for general usage by other Arduino libs (which might require unexposed functionality).
The text was updated successfully, but these errors were encountered: