GitLab

Following best-practice use of the const feature, to make it compatible
with Python.

All float constants in the core should use this macro to prevent
unnecessary creation of double-precision floats, which makes code less
efficient.

This helps to test floating point code on Cortex-M hardware.

As part of this patch the link-time-optimisation was disabled because it
wasn't compatible with software FP support.  In particular, the linker
could not find the __aeabi_f2d, __aeabi_d2f etc functions even though they
were provided by lib/libm/math.c.

This allows it to be used only when the hardware supports VFP
instructions, preventing compile errors.

With MICROPY_ENABLE_GC set to false the alternate memory manager may not
clear all memory that is allocated, so it must be cleared in m_malloc0.

In both parse.c and qstr.c, an internal chunking allocator tidies up
by calling m_renew to shrink an allocated chunk to the size used, and
assumes that the chunk will not move.  However, when MICROPY_ENABLE_GC
is false, m_renew calls the system realloc, which does not guarantee
this behaviour.  Environments where realloc may return a different
pointer include:

(1) mbed-os with MBED_HEAP_STATS_ENABLED (which adds a wrapper around
malloc & friends; this is where I was hit by the bug);

(2) valgrind on linux (how I diagnosed it).

The fix is to call m_renew_maybe with allow_move=false.

Size 64 was incorrect and will lead to stack corruption. Size 88 was
verified empirically. Also, allow to skip defining it if MD5_CTX
preprocessor macro is already defined (to avoid header conflict).

ESP8266 SDK2.0 fixes (at least, I can't reproduce it) an infamous bug
with crash during scan. 36K seams to be a safe value based on a download
test (test_dl.py), over 1GB was downloaded. More testing is needed, but
let's have other people participate by committing it now.

There is no automatic reconnect after wlan.active(False);
wlan.active(True). This commit provide the possibility to run
wlan.connect() without parameter, to reconnect to the previously
connected AP.

resolve #2493

It's mandatory function which should be present in every port. Even if
it's not, in the stdlib intro we waarn users that a particular port can
lack anything of described in the docs.

Also, drop ::only directive.

Now the function properly uses ring arithmetic to return signed value
in range (inclusive):
[-MICROPY_PY_UTIME_TICKS_PERIOD/2, MICROPY_PY_UTIME_TICKS_PERIOD/2-1].

That means that function can properly process 2 time values away from
each other within MICROPY_PY_UTIME_TICKS_PERIOD/2 ticks, but away in
both directions. For example, if tick value 'a' predates tick value 'b',
ticks_diff(a, b) will return negative value, and positive value otherwise.
But at positive value of MICROPY_PY_UTIME_TICKS_PERIOD/2-1, the result
of the function will wrap around to negative -MICROPY_PY_UTIME_TICKS_PERIOD/2,
in other words, if a follows b in more than MICROPY_PY_UTIME_TICKS_PERIOD/2 - 1
ticks, the function will "consider" a to actually predate b.

Using MICROPY_PY_UTIME_TICKS_PERIOD config var.

To fix coverage build.

mp_hal_ticks_ms, mp_hal_ticks_us taken from unix port, mp_hal_ticks_cpu
dummy.

Ported from unix port.

It's implemented in terms of usleep(), and POSIX doesn't guarantee that
usleep() can sleep for more than a second. This restriction unlikely
applies to any real-world system, but...

Based on the earlier discussed RFC. Practice showed that the most natural
order for arguments corresponds to mathematical subtraction:

ticks_diff(x, y) <=> x - y

Also, practice showed that in real life, it's hard to order events by time
of occurance a priori, events tend to miss deadlines, etc. and the expected
order breaks. And then there's a need to detect such cases. And ticks_diff
can be used exactly for this purpose, if it returns a signed, instead of
unsigned, value. E.g. if x is scheduled time for event, and y is the current
time, then if ticks_diff(x, y) < 0 then event has missed a deadline (and e.g.
needs to executed ASAP or skipped). Returning in this case a large unsigned
number (like ticks_diff behaved previously) doesn't make sense, and such
"large unsigned number" can't be reliably detected per our definition of
ticks_* function (we don't expose to user level maximum value, it can be
anything, relatively small or relatively large).