stmhal: Allow event-driven readline() operation by refactoring function using coroutine design

[pfalcon]

Following up to #992 (comment)

I prototyped this refactor on raw_repl, and it worked. @dpgeorge, I'd like to be sure you're ok with going forward with this. For friendly_repl, core of which in readline() function, following changes would be needed:

Loop body

    for (;;) {
        int c = stdin_rx_chr();
        ...
   }

should be extracted to a separate function, accepting "c". Any state which was previously kept in stack variable should be made persistent between function calls (top-level static variable puts into structure). Code before the loop should be turned into "init" function. All other functions calling readline() should undergo similar transformation. More changes will be needed later to actually supporting event-driven operation.

[dpgeorge]

Yes, this might actually be a good change overall: we can put the state in the bss thereby reducing amount of stack required (since the stack used here then reduces available stack for uPy functions). See f5465b9 for similar optimisation I just worked on.

[pfalcon]

Yes, but it will increase static data size (which takes space no matter if its used or not). Of course, that can be addressed later by putting structure on heap ;-). In either case, that will likely increase code size as will require accessing global/by-pointer variables instead of allocating vars to register (partially can be worked around later too). But overall yeah, I guess it's good change as it will allow to use uPy in more environments.

[dpgeorge]

Yes, but it will increase static data size (which takes space no matter if its used or not).

All REPL uPy code is run with the pyexec stack in activation, so it's always using RAM, be it stack, static or heap.

In either case, that will likely increase code size as will require accessing global/by-pointer variables

True.

instead of allocating vars to register

A complex function will push all registers to stack on entry, so uses more stack anyway. I think it's close to break even in terms of RAM usage no matter where the state lives (stack, bss, heap).

But overall yeah, I guess it's good change as it will allow to use uPy in more environments.

I agree. Let's make the change and optimise later.

We should put readline in lib/readline/, and we should factor stmhal/pyexec.c into py/ as an optional component, because many ports are relying on these (stmhal, esp8266, Nuttx, ...)

[pfalcon]

Posted first steps to #1054. Increases stmhal image size by 108 bytes (84 code + 24 bss).

[pfalcon]

Implemented.