GitLab

mp_fun_kw_t takes mp_map_t* (and not const mp_map_t*) to ease passing
this arg to mp_map_lookup(), which may modify its arg, depending on
flags.

With gap between segments minimized, there's not much padding to flash,
so no big speed overhead.

With .rodata being in FlashROM now, gap can be much smaller now. InstRAM
can be max 32K, and with segment headers, that already makes it more than
32K. Then there's some .data still, and the next Flash page boundary is
0x9000. That figure should be more or less future-proof.

TODO: Refactor makeimg to take FlashROM segment offset from file name.

Needed for frozen scripts, and for future growth of binary.

This is helpful when running on deeply embedded targets, but may be
"security risk". Caveat emptor.

Allows to re-run code if it was imported as a module (e.g., on bare-metal
ports).

Allows to re-run code if it was imported as a module (e.g., on bare-metal
ports).

And with "buffering" arg introduced, it's non possible to make it
non-kwonly.

It's ignored (unbuffered, raw I/O is used), but least makes it compatible
with CPython.

Starting with a divisor of 10, pystone_lowmem gives a score of 256.

This was originally used for non-event based REPL processing.  Then it
was unused when event-based processing was activated.  But now that event
based is disabled, and non-event based is back, there has been new ring
buffer code to process the chars.

Event-driven loop (push-style) is still supported and default (controlled
by MICROPY_REPL_EVENT_DRIVEN setting, as expected).

Dedicated loop worked even without adding ets_loop_iter(), though that
needs to be revisited later.

Before this change, if REPL blocked executing some code, it was possible
to still input new statememts and excuting them, all leading to weird,
and portentially dangerous interaction.

TODO: Current implementation may have issues processing input accumulated
while REPL was blocked.

Also, term_obj can be NULL if socket enables REPL duplication signalling
before os.dupterm is called, so it should be checked.

The idea is following: underlying interrupt-driven or push-style data source
signals that more data is available for dupterm processing via call to
mp_hal_signal_dupterm_input(). This triggers a task which pumps data between
actual dupterm object (which may perform additional processing on data from
low-level data source) and input ring buffer.

But now it's generic ring buffer implemented via ringbuf.h, and is intended
for any type of input, including dupterm's, not just UART. The general
process work like this: an interrupt-driven input source puts data into
input_buf, and then signals new data available via call to
mp_hal_signal_input().