we need a space where all the external drivetrain's counterpart code lives.

[2bndy5]

I have a port of this library for circuitpython MCUs that can't use the threading module acting as a counterpart to the NRF24L01 interface. We also have that C++port in the arduino-miner repo to act as a counterpart for the USB interface.

These solutions need a better home, for just 10 cent a day, you too could....blah blah blah

[2bndy5]

I started merging my own non-threading dependent port into the appropriate classes. It still needs testing, but the switch between threaded and non-threaded functionalities should be automatic and seamless; meaning the same python code should be able to run on any MCU we throw at it (python interpreter required of course). This only begins to solve the problem of where to keep the counterpart libraries as we still need to address where to keep the Arduino port of this library. Since its not written in python, I'm erring with a separate repository (maybe install-able from the Arduino Library Manager or side-loaded).

Also I'd like to somehow include a counterpart class to the NRF24L01 for receiving commands from the existing NRF24L01 transmitting class. This may require augmenting the class name a bit.