Evaluate the feasibility of supporting the MicroPython runtime

[pavel-kirienko]

The intended use cases are close to those of AP_Periph -- easy creation of unsophisticated hardware nodes.

Certain features will need to be demoted to optional. The obvious ones are:

• Nunavut transcompilation.
• Dependency on PyDSDL in transpiled code.
• Fast serialization based on memory aliasing of NumPy arrays (NumPy, in general, will probably have to go).
• Snooping/spoofing support for UAVCAN/UDP.

It shouldn't be hard to get the library to run on MicroPython, although it is expected that at least at first it is going to be extremely resource-consuming, as it was developed with the main focus on desktop systems.

[coderkalyan]

I'd like to take a look at this, if that's alright.

Fast serialization based on memory aliasing of NumPy arrays (NumPy, in general, will probably have to go). I believe some people have managed to get numpy working on micropython, but it's not expected to be easy so probably a good idea to throw it out.

One thing to mention is that micropython supports C extensions (https://docs.micropython.org/en/latest/develop/cmodules.html), which we could potentially outsource certain tasks to to improve performance in key areas like array manipulation.

[pavel-kirienko]

Yes indeed, there is a highly restricted re-implementation of NumPy for MicroPython, but it is not sufficiently API-compatible with the full NumPy, so some changes will be necessary.

C extensions are good to keep in mind but we would do well to avoid them completely if we can.

This issue seems to be a prerequisite for supporting MicroPython: https://github.com/UAVCAN/pyuavcan/issues/110

I think it makes sense to start with UAVCAN/UDP. If we manage to get it to work, the rest should be fairly trivial.