Most pin I/O can be done just knowing the pin number as a simple
integer, and it's more efficient this way (code size, speed) because it
doesn't require a memory lookup to get the pin id from the pin object.
If the full pin object is needed then it can be easily looked up in the
pin table.
The idea is that if dupterm object can handle exceptions, it will handle
them itself. Otherwise, object state can be compromised and it's better
to terminate dupterm session. For example, disconnected socket will keep
throwing exceptions and dump messages about that.
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.
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().
Enabling standard assert() (by removing -DNDEBUG) produces non-bootable
binary (because all messages go to .rodata which silently overflows).
So, for once-off debugging, have a custom _assert().
Initialize RTC period coefficients, etc. if RTC RAM doesn't contain valid
values. time.time() then will return number of seconds since power-on, unless
set to different timebase.
This reuses MEM_MAGIC for the purpose beyond its initial purpose (but the whole
modpybrtc.c need to be eventually reworked completely anyway).
