micropython / micropython/micropython-lib
NRF24L01 Driver's Test Program Mis-handles Non-default Pins
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 2.9k
- Forks
- 1.1k
- Avg merge
- 7d 6h
- Merged PRs (30d)
- 3
Description
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.
if usys.platform == "pyboard":
cfg = {"spi": 2, "miso": "Y7", "mosi": "Y8", "sck": "Y6", "csn": "Y5", "ce": "Y4"}
elif usys.platform == "esp8266": # Hardware SPI
cfg = {"spi": 1, "miso": 12, "mosi": 13, "sck": 14, "csn": 4, "ce": 5}
elif usys.platform == "esp32": # Software SPI
cfg = {"spi": -1, "miso": 32, "mosi": 33, "sck": 25, "csn": 26, "ce": 27}
elif usys.platform == "rp2": # PI PICO
cfg = {"spi":0, "miso": 16, "mosi": 19, "sck": 18, "csn": 7, "ce": 6}
else:
raise ValueError("Unsupported platform {}".format(usys.platform))
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:
if cfg["spi"] == -1:
spi = SPI(-1, sck=Pin(cfg["sck"]), mosi=Pin(cfg["mosi"]), miso=Pin(cfg["miso"]))
nrf = NRF24L01(spi, csn, ce, payload_size=8)
else:
nrf = NRF24L01(SPI(cfg["spi"]), csn, ce, payload_size=8)
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.
if cfg["spi"] == -1:
spi = SPI(-1, sck=Pin(cfg["sck"]), mosi=Pin(cfg["mosi"]), miso=Pin(cfg["miso"]))
nrf = NRF24L01(spi, csn, ce, payload_size=8)
elif cfg["spi"] == -2:
spi = SPI(0, sck=Pin(cfg["sck"]), mosi=Pin(cfg["mosi"]), miso=Pin(cfg["miso"]))
nrf = NRF24L01(spi, csn, ce, payload_size=8)
else:
nrf = NRF24L01(SPI(cfg["spi"]), csn, ce, payload_size=8)
I also updated the config to use that stub -2 value:
cfg = {"spi": -2, "miso": 16, "mosi": 19, "sck": 18, "csn": 7, "ce": 6}
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with micropython/drivers/radio/nrf24l01/nrf24l01test.py, especially the configuration section and the SPI/NRF24L01 construction branches. Run the test program with the Raspberry Pi Pico configuration and verify that its configured SPI bus and non-default sck, mosi, miso, csn, and ce pins are all used; done means the test no longer requires a sentinel SPI value for that setup.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- embedded-iot
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100