Scenario: module1 depends on some common file from lib/, so specifies it
in its SRC_MOD, and the same situation with module2, then common file
from lib/ eventually ends up listed twice in $(OBJ), which leads to link
errors.
Make is equipped to deal with such situation easily, quoting the manual:
"The value of $^ omits duplicate prerequisites, while $+ retains them and
preserves their order." So, just use $^ consistently in all link targets.
MicroPython "network" module interface requires it to contains classes
to instantiate. But as we have a static network interace, make WLAN()
"constructor" just return module itself, and just make all methods
module-global functions.
Pasting more or less sizable text into ESP8266 REPL leads to random chars
missing in the received input. Apparent cause is that using RTOS messages
to pass individual chars one by one is to slow and leads to UART FIFO
overflow. So, instead of passing chars one by one, use RTOS msg to signal
that input data is available in FIFO, and then let task handler to read
data directly from FIFO.
With this change, lost chars problem is gone, but the pasted text is
truncated after some position. At least 500 chars can be pasted reliably
(at 115200 baud), but 1K never pastes completely.
1. Updated linker script, now user app appears to contain exception vector
table and oesn't work (faults) without it.
2. Commened out support for GPIO pulldown, which was removed in this SDK
version without clear explanation, but apparently because it was released
without proper validation, and now turns out it doesn't work as expected,
or there's a different function there.
As user_init() is not a true main functions, the stack pointer captured within
is not pointing at the base of the stack. This caused gc_collect being called
with sp being higher than stack_end, causing integer overflow and crashing as
gc tried to scan almost the entire address space.
esp8266 port now has working raw and friendly REPL, as well as working
soft reset (CTRL-D at REPL, or raise SystemExit).
tools/pyboard.py now works with esp8266 port.
* UDP currently not supported
* As there is no way (that I know of) the espconn_regist_connectcb()
callback can recognize on which socket has the connection arrived,
only one listening function at a time is supported
Previous to this patch the printing mechanism was a bit of a tangled
mess. This patch attempts to consolidate printing into one interface.
All (non-debug) printing now uses the mp_print* family of functions,
mainly mp_printf. All these functions take an mp_print_t structure as
their first argument, and this structure defines the printing backend
through the "print_strn" function of said structure.
Printing from the uPy core can reach the platform-defined print code via
two paths: either through mp_sys_stdout_obj (defined pert port) in
conjunction with mp_stream_write; or through the mp_plat_print structure
which uses the MP_PLAT_PRINT_STRN macro to define how string are printed
on the platform. The former is only used when MICROPY_PY_IO is defined.
With this new scheme printing is generally more efficient (less layers
to go through, less arguments to pass), and, given an mp_print_t*
structure, one can call mp_print_str for efficiency instead of
mp_printf("%s", ...). Code size is also reduced by around 200 bytes on
Thumb2 archs.
To enable parsing constants more efficiently, mp_parse should be allowed
to raise an exception, and mp_compile can already raise a MemoryError.
So these functions need to be protected by an nlr push/pop block.
This patch adds that feature in all places. This allows to simplify how
mp_parse and mp_compile are called: they now raise an exception if they
have an error and so explicit checking is not needed anymore.
Paul Sokolovsky
Damien George
Bill Owens
Radomir Dopieralski
Josef Gajdusek