MicroPython support added back in (an unofficial library feature)

[2bndy5]

try:
    from ubus_device import SPIDevice
except ImportError:
    from adafruit_bus_device.spi_device import SPIDevice

Above is the import statement from the rf24.py file (as of v1.2.0 release). First it looks for a module named ubus_device which contains a class named SPIDevice, then falls back to looking for the widely available adafruit_bus_device.spi_device module. This ubus_device file is not located in this library's releases as it is an adapted version of the CircuitPython dependency adafruit_bus_device.spi_device containing the original code written by "Scott Shawcroft for Adafruit Industries" (both files share a MIT license).

The necessary files needed to make this library work on MicroPython are located in my separate repository called CircuitPython_2_Micropython. These files are:

1. ubus_device This is a substitute for adafruit_bus_device.spi_device that wraps MicroPython's machine.SPI class into a context manager compatible module.
2. udigitalio This file contains a class named DigitalInOut. This file is meant to be a substitute for CircuitPython's digitalio module and wraps MicroPython's machine.Pin class into an interface compatible with digitalio.DigitalInOut class. This file isn't directly imported by rf24.py, but it is needed to declare the nRF24L01's CE & CSN pins' objects that are passed to the RF24 constructor.

These files were tested on a tinypico (ESP32) with rf24.py, ubus_device.py, & udigitalio.py all located at the filesystem's root directory. I should mention that the udigitalio.py file is not compatible with the ESP8266 platform running MicroPython due to differences in the pull up/down resistors available (tested on a nodeMCU board). The following snippet demonstrates how to use the above listed files (located at root directory of the platform's file system) in MicroPython:

import machine
from udigitalio import DigitalInOut
from rf24 import RF24

# change these pin numbers accordingly
# DigitalInOut class creates an internal machine.Pin object from only the identifying pin number
ce_pin = DigitalInOut(32)
csn_pin = DigitalInOut(33)

# instantiate an object for the SPI bus
# see the micropython docs on machine.SPI
spi = machine.SPI(0)  # 0 or 1 identify the hardware SPI bus, any other number invokes a bitbanged alternative

# instantiate a RF24 object using the above pin and spi bus  objects
nrf = RF24(spi, csn_pin, ce_pin)

# continue code like normal from the examples in this repository's examples folder.

[2bndy5]

I'm also currently working on getting the above wrapper implementation integrated into this circuitpython_nrf24l01 library. The dev branch has support for micropython as well as the spidev & RPi.GPIO python c-extensions on linux (for even faster performance). I plan on rolling out this solution with an RF24Network class (RF24Mesh may be introduced separately/later).

[2bndy5]

Due to the use of time.monotonic() and time.monotonic_ns() in v2.1.0, I'm dropping MicroPython support as I would have to write a wrapper for practically every MicroPython API (SPI interfaces, GPIO interfaces, and now utime module). This is simlpy not sustainable as it is not my fault that MicroPython intentionally doesn't keep compatibility with CPython API (but CircuitPython does). It not unusual for MicroPython API to differ for each supported board (aka "ports"), so I want to avoid that nightmare as well.

With that said, the solution in the first comment of this discussion will only work for versions v1.x to v2.0. Sorry if this causes any inconvenience. Remember that C++ libs can be used on any MCU that MicroPython can run on. So, I urge users to use the C++ equivalent libraries.

• RF24
• RF24Network
• RF24Mesh

[zcattacz]

So, it's just lacking the shims only ?

[zcattacz]

Hi @2bndy5 thanks for replying, no I just mean if the lib, so far, still only need shims to work on micropython. If not what other potential major gap you can suggest.
It's sure understandable if you want to focus on the algorithm and compatibility, can't be bothered by the constant external changes.
Just trying to estimate the difficult of using this lib on micropython. I also test my upy code on cpython, I am ok with creating my own shims.

[2bndy5]

Let me know what you come up with. And, yes support for micropython would just need shims. IIRC, the tricky parts are

• implementing __enter__() and __exit__() for the SPI shim (so this lib can do with self._spi as spi:)
• creating a shim for utime to act as time was too involved (not a thin wrapper) for me to pursue/maintain.
• the digitalio shim might need some non-op Push/Pull attributes on some boards that don't allow configuring drive behavior of certain GPIO pins.

You could look into adafruit-blinka as I think they've implemented some wrappers that can be used on Micropython (since I last assessed micropython support for this lib). You'd still have to write a wrapper for utime -> time...

[2bndy5]

Beware, I'm switching the RF24Mesh layer to use a set (instead of a list) to aggregate contacts during a mesh child node's bonding process (see PR commit c6c5569). AFAIK, micropython does not have support for the builtin set collection type (see uPy docs here and here).

I'm still not convinced writing shims for uPy support is worth it. CirPy is much more user-friendly and portable in my experience.

[zcattacz]

Thank you. Good to know it still easy to use. I am looking at 433MHz radios, the nRF24 radio turns out to be less ideal in my current application. Maybe it's due to lack of LoS. I'll revisit this when I use 2.4G comm in other projects.
Please keep up the good work. :-)

[2bndy5]

Maybe it's due to lack of LoS

If you mean Los of Signal, then the only way to really measure that is with broadcasting at specified intervals. It doesn't matter what radio you use. A radio can only assume Loss of Signal if the expected behavior of the implemented wireless protocol is violated (e.g. broadcasting interval is not satisfied).

I'm not sure how other radios would assess this (via chip firmware or software library or both). The nRF24L01 is extremely flexible in terms of implementing custom defined protocol, thus the Enhanced ShockBurst (ESB) protocol (as implemented in nRF24L01's firmware) is called a "proprietary protocol". And all wireless protocols are just behavioral specifications layered on top of other wireless protocols.