interpreters/micropython: Add Micropython support to NuttX (WIP)

[mransom-campbell]

I could use some feedback on this. It is still a WIP but it is taking longer than expected so I wanted to get this out there.

Summary

Micropython is a Python implementation for Microcontrollers. I think it is a perfect fit for NuttX.

This PR adds NuttX as a Unix "Variant" under Micropython. This allows lots of features like files, sockets, etc.. to work without maintaining a separate Micropython port for NuttX.

Notes:

• Hardest part was integrating the build systems. Currently Micropython is built using the Micropython ports/unix Makefile during the "context" step. Building during the build step would be better but I couldn't get that to work.
• I previously manually specified all the .c files but that broke as soon as I updated Micropython. I am far from a Make expert so if
  anyone has a better solution let me know.
• Currently clones my fork of Micropython (https://github.com/mransom-campbell/micropython/tree/nuttx). I will upstream those changes once I do some cleanup.
• Would it be better to download the latest Micropython release and apply patches like the Duktape NuttX support?

TODO:

• Add NuttX support to Micropython Unix port.
• Create Makefile and KConfig for NuttX Apps.
• Fix warnings when sockets/ussl are enabled (NuttX builds will -Werror)
• Fix Micropython float support (problems with NuttX math library)
• Fix Micropython stack check size.
• Add Micropython default Heap size as configuration option.
• Run Micropython test suite

Impact

Application.mk: changed OBJS to be += so Applications can add their own object files manually.

Testing

I have tried a few things on a stm32 board and Renesas RX board, everything seems to work. The full Micropython test suite should be run before this PR is merged.

[cederom]

Awsome work @mransom-campbell ! I also got interested in MicroPython and NuttX :-) How can I help? :-)

[mransom-campbell]

@cederom thanks for your interest! I actually got stuck trying to run the Micropython test suite. Here's the approaches I tried:

• Run test suite on Nuttx simulation: Doesn't work because I couldn't get the arguments to be passed to the Micropython task, and the simulation doesn't exit at the end by default.
• Run test suite on Nuttx arm dev board: Doesn't work because the Unix port of Micropython doesn't support the 'Raw' REPL mode required to run the test suite on hardware.

If you could help get the test suite working on either of those approaches that would be helpful.

I have a solution to the Float issue but I haven't pushed that to this branch yet.

I was working on this for a Research project at work so I'm not sure how much more time I can dedicate to this.

[cederom]

• Thanks @mransom-campbell :-)
• I am new to NuttX so it can take some time until I get familiar with all internals.. but I have starting point and clear goal, test suite, thanks! :-)
• So far I did run NuttX Simulator and NuttX firmware on ESP32-C3 DevKit.
• I am working on FreeBSD. I can see there is a MicroPython 1.17 port here so I can have reference point.
• What problems do you see with hardware drivers? I am mostly interested in running MP on MCU (RISC-V).
• What is your rough work / time estimation to complete MP on NuttX? How much time did you spend already to get familiar with the internals?
• I will try to build from your repo / branch and report back.
• I already cloned you repo :-) Will you have time to review PRs from me or I should push here directly?
• Step by step, incremental progress :-)

[cederom]

Update:

• I am finishing some projects based on MicroPython so I got some experience with it.
• I now need something faster for upcoming projects so I will get into NuttX internals in upcoming months.
• The best scenario for me is to have MicroPython for rapid prototyping and proof-of-concept and then NuttX RTOS as the target efficient solution.
• Having MP on NuttX would allow invisible switch from MP ptototype to RTOS and this is the goal :-)
• Also I would like this solution to allow code portability between bare-metal MicroPython and MicroPython on NuttX both ways.
• I would like MicroPython to be just another application on NuttX so probably a new target will show up in MicroPython (i.e. just like Unix target).
• MicroPython target port would utilize generic peripherals drivers of NuttX. That way we will become independent of underlying hardware.
• Using custom NuttX drivers should be possible from MicroPython on NuttX by read/write to/from character/block devices. That would make code not backward portable to bare metal MicroPython though.
• No specific date on when it will work, I will have to see how much work with peripheral drivers will be out there in bare metal MP to NuttX, but lets assume 2022H2 :-)

[nimish]

I've been able to get these rebased to the latest master, including the minor changes to the unix target in upython, but it fails on finding a micropython_main despite my best efforts to ensure that symbol exists.

If you can get a basic interpreter to build, then I think this is doable pretty quickly

Of course, moving the device drivers might be harder.

[nimish]

Actually, https://github.com/adafruit/circuitpython/tree/main/ports/cxd56 since CircuitPython supports the NuttX SPRESENSE board, it could be quicker. The drivers would need to be generalized a bit, but otherwise it looks clean enough.

[xiaoxiang781216]

I've been able to get these rebased to the latest master, including the minor changes to the unix target in upython, but it fails on finding a micropython_main despite my best efforts to ensure that symbol exists.

Source code which contain main need to be added to MAINSRC since the build need rename the main symbols to avoid the conflict.

If you can get a basic interpreter to build, then I think this is doable pretty quickly

Of course, moving the device drivers might be harder.

[nimish]

nsh> upy
MicroPython v1.19.1-24-gffb0e674b-dirty on 2022-06-25; nuttx [GCC 11.2.1] version
Use Ctrl-D to exit, Ctrl-E for paste mode
hello

Got it to work, with caveats:
the repl doesn't echo and doesn't really respond to special chars, something to do with readline I think.

This is on a SPRESENSE CXD5602 board. Can exit via sys.exit()

[slorquet]

a full port of micropython must not be based on the unix port but on the embed port.

micropython/micropython#13632 (comment)

This is very easy to embed in the Nuttx build system, I have that part working somewhere.

I also have some WIP for a nuttx micropython, but it has to be clever and integrate properly, for example with mbedtls, already provided by NuttX. we should not be using the mbdedtls from micropython itself.

Every other integration point has to be checked, or the port will be awkward.

[yamt]

a full port of micropython must not be based on the unix port but on the embed port.

while i have some sympathies, i suspect it depends on what you want to do in your python code.

[f4grx]

I would say it depends on the project it is integrated in, in this instance NuttX.

Micropython is still micropython, and whats available in it does not directly depend on the kind of port structure, but rather its configuration.