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
Spent some time troubleshooting if I had bad drivers, firmware, or chip, but eventually figured out that the way the current nrf24l01test.py file handles SPI buses and non-default pinouts is misleading at best.
Basically, the config section enables you to add more boards and configs that could be supported, or update pinouts, like I did here with my Raspberry Pi Pico board.
However, when it actually comes time to construct the NRF24L01 class object, it's done using only the default pinouts everywhere except the esp32 board. (Notice how the only time the custom mosi, sck, and miso values are used is on the cfg["spi"] == -1 check:
I've fixed this for my testing purposes by creating some stub value of cfg["spi"] = -2 and then forcing the bus to the 0 bus since that's the one that I'm using with the other SPI pinout.
I suspect this could be done more elegantly by adding a flag in the cfg dictionary and checking that for non-defaults and documenting how to turn on non-default pins in the comments right above the config section. I know my fix corrects my mistake, but I'm not sure the most "appropriate" fix for the library's official testing to properly keep it generalized for other users.
The text was updated successfully, but these errors were encountered:
Spent some time troubleshooting if I had bad drivers, firmware, or chip, but eventually figured out that the way the current nrf24l01test.py file handles SPI buses and non-default pinouts is misleading at best.
Basically, the config section enables you to add more boards and configs that could be supported, or update pinouts, like I did here with my Raspberry Pi Pico board.
However, when it actually comes time to construct the NRF24L01 class object, it's done using only the default pinouts everywhere except the
esp32
board. (Notice how the only time the custommosi
,sck
, andmiso
values are used is on thecfg["spi"] == -1
check:I've fixed this for my testing purposes by creating some stub value of
cfg["spi"] = -2
and then forcing the bus to the0
bus since that's the one that I'm using with the other SPI pinout.I also updated the config to use that stub
-2
value:I suspect this could be done more elegantly by adding a flag in the
cfg
dictionary and checking that for non-defaults and documenting how to turn on non-default pins in the comments right above the config section. I know my fix corrects my mistake, but I'm not sure the most "appropriate" fix for the library's official testing to properly keep it generalized for other users.The text was updated successfully, but these errors were encountered: