Support @micropython.native on RP2040

[rgov]

I'm unclear whether it is possible or not to support @micropython.native (and native .mpy modules) on the RP2040. #2271 allowed boards to "enable the decorator by adding CIRCUITPY_ENABLE_MPY_NATIVE to mkboardconfig.mk."

For ports/raspberrypi/mkboardconfig.mk, adding CIRCUITPY_ENABLE_MPY_NATIVE = 1 is not sufficient. There are a handful of build errors:

GEN build-raspberry_pi_pico/genhdr/qstrdefs.generated.h
../../py/compile.c: In function 'compile_built_in_decorator':
../../py/compile.c:839:24: error: 'MP_QSTR_native' undeclared (first use in this function); did you mean 'MP_QSTR_active'?
  839 |     } else if (attr == MP_QSTR_native) {
      |                        ^~~~~~~~~~~~~~
      |                        MP_QSTR_active

I found this is because MICROPY_PY_UCTYPES is not enabled. Its definition in py/mpconfig.h makes it dependent on MICROPY_CONFIG_ROM_LEVEL_AT_LEAST_EXTRA_FEATURES but I guess this is not set for the Raspberry Pi port.

After forcing CircuitPython to build, the rp2040js emulator can run the firmware but crashes when you try to use @micropython.native. Unsure if that's a limitation of the emulator or if it's just not possible to use native code on this chip.

[dhalbert]

We have not attempted to keep this running since it was enabled in #2271. Maybe we should turn it off for now.

[tannewt]

For ports/raspberrypi/mkboardconfig.mk, adding CIRCUITPY_ENABLE_MPY_NATIVE = 1 is not sufficient. There are a handful of build errors:

Anytime you see a MP_QSTR build error, try cleaning and rebuilding. Our makefiles don't perfectly rebuild things when changing enable settings.

Can the simulator be connected with gdb? That way you can get a backtrace.

[rgov]

Maybe we should turn it off for now.

I understand that advanced features like native code support are not really aligned with CircuitPython's goals, but I am hoping to compile C modules to loadable .mpy extensions without maintaining a fork of CircuitPython. This is a really nice feature—as long as you don't need to access the MCU's SDK. I don't actually want to use the decorator (and indeed it probably is a bit of a foot-gun for people who apply it too prodigiously because fast.)