GitLab

This requires recently added implementation of machine.Pin from
micropython-lib.

The ESP SDK supports configuring the hostname that is
reported when doing a DHCP request in station mode.  This commit
exposes that under network.WLAN(network.STA_IF).config('dhcp_hostname')
as a read/write value similar to other parameters.

With this patch one can now do "make FROZEN_MPY_DIR=../../frozen" to
specify a directory containing scripts to be frozen (as well as absolute
paths).

The compiled .mpy files are now stored in $(BUILD)/frozen_mpy/.

Now, to use frozen bytecode all a port needs to do is define
FROZEN_MPY_DIR to the directory containing the .py files to freeze, and
define MICROPY_MODULE_FROZEN_MPY and MICROPY_QSTR_EXTRA_POOL.

Previously, it was included only in release builds, but it's important
tool which should be always at the fingertips to be useful (and to
pump up its usage).

To make its inclusion as frozen modules in multiple ports less magic.
Ports are just expected to symlink 2 files into their scripts/modules
subdirs.

Unix port updated to use this and in general follow frozen modules setup
tested and tried on baremetal ports, where there's "scripts" predefined
dir (overridable with FROZEN_DIR make var), and a user just drops Python
files there.

At the WS2812 driver level, a 400ns value was used for T0H (time high to
send a 0 bit) but LED specification says it should be 350ns +- 150ns.
Due to loop overhead the 400ns value could lead to T0H close to 500ns
which is too close from the limit value and gave glitches (bad data to
pixels) in some cases.  This patch makes the calculated T0H value 350ns.

Showing and providing detailed instructions and motivation.

Otherwise this broke esp8266 testsuite.

Previously they used historical "pyb" affix causing confusion and
inconsistency (there's no "pyb" module in modern ports; but people
took esp8266 port as an example, and "pyb" naming kept proliferating,
while other people complained that source structure is not clear).

Somehow, Zephyr uses -fno-omit-frame-pointer, whch bloats code size
considerably (+5K for minimal ARM Thumb2 build).

Use normal mp_int_t/mp_uint_t types, algorithms (hm, formulas) can work
with any type width.

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).