MicroPython: Roadmap

[Gadgetoid]

• Investigate REPL text() bug - attempting to display a long string causes a hardlock (OOM?)

• Create a new port in https://github.com/pimoroni/micropython/tree/experimental/picosystem to house PicoSystem specific customisations. There doesn't seem to be an easy way to contain these in a BOARD definition without inventing a dozen new customisation hooks. These include overclocking early in main(), changing the size of the gc_heap and baking in the PicoSystem API as builtins.

• Move builtin declarations from py/builtin.h to somewhere sensible (ideally in the port). Copy these across this repo for ongoing maintenance and set up a file copy to patch them back in before MicroPython compile.

• Reduce gc_heap and allocate SCREEN up-front

  When first rolling the MicroPython port, I intended to keep us as close to upstream as possible and not lean on any hacks to the MicroPython codebase to support the PicoSystem API.

  We're now so far from that with the API-surface-as-builtins change that it no longer makes sense to "m_malloc" SCREEN on the gc_heap. It should be moved back to the C/C++ domain and the gc_heap size reduced accordingly.

  This should reduce the area of RAM that MicroPython's GC needs to scan through when running "collect" operations, and subsequently give us a small boost in performance.

• Investigate MICROPY_EVENT_POLL_HOOK

  We should investigate MICROPY_EVENT_POLL_HOOK and what it means to various API features, and how likely we are to trample it again.
  It's clear that not calling this handler during the bootsplash animation is what caused USB to balk in macOS, since we had a long dalay with no USB handling. Oof. See: https://github.com/micropython/micropython/blob/38f8e852e04013e4616097320bf9cf75051a1b6b/ports/rp2/mpconfigport.h#L252-L258

• Is it meaningful for a script to not exit?

  Is there anything in MicroPython analogous to signal.pause()

  While we're hacking on MicroPython we could potentially run our tick() function elsewhere- perhaps dispatching it from MICROPY_EVENT_POLL_HOOK where appropriate (though we mostly wouldn't want to do that in tight loops? so maybe there's a timer alternative?). If we drop while True: tick() then we'll either need while True: pass (ugh) or some other means of preventing Python code from just falling through and exiting.

  Can we have a "run()" API function enter C code perpetually, run the Python loops, gracefully bail when an error is raised, ands call MICROPY_EVENT_POLL_HOOK so the subsystems don't stall?

Ideal API

def update(tick):
    pass
    
def render(tick):
    pass
    
run()  # <-- hand over to C to run things and dispatch calls to update/render?