GitLab

With contributions from Oliver Robson (@HowManyOliversAreThere), Sean
Lanigan (@seanlano) and @rprr.

This aligns more closely with the hardware, that there are two, fixed HW
SPI peripherals.  And it allows to recreate the HW SPI objects without
error, as well as create them again after a soft reset.

Fixes issue #4103.

Otherwise only one of HSPI or VSPI can be used at a time.  Fixes
issue #4068.

In order to suit the more common 800KHz by default (instead of 400KHz), and
also have the same behaviour as the esp8266 port.

Resolves #4396.

Note! This is a breaking change. Anyone that has previously used the
NeoPixel class on an ESP32 board may be affected.

The original behaviour of open-drain-high was to use the open-drain mode of
the GPIO pin, and this seems to make driving a DHT more reliable.  See
issue #4233.

Some ports (eg esp8266) need to have specific behaviour for driving a DHT
reliably.

The ESP IDF system already provides a math library, and that one is likely
to be better tuned to the Xtensa architecture.  The IDF components are also
tested against its own math library, so best not to override it.  Using the
system provided library also allows to easily switch to double-precision
floating point by changing MICROPY_FLOAT_IMPL to MICROPY_FLOAT_IMPL_DOUBLE.

So that the user can explicitly deactivate UART(0) if needed.  See
issue #4314.

This introduces some risk to "brick" the device, if the user disables the
REPL without providing an alternative REPL (eg WebREPL), or any way to
reenable it.  In such a case the device needs to be erased and
reprogrammed.  This seems unavoidable, given the desire to have the option
to use the UART for something other than the REPL.

Without the static qualifier these objects will be kept by the linker even
if they are unused.  So this patch saves some RAM when these features are
unused by a board.

If there are many short reads to a socket in a row (eg by readline) then
releasing and acquiring the GIL each time will give very poor throughput.
So first poll the socket to see if it has data, and if it does then don't
release the GIL.

Otherwise, if multiple threads are active, printing data to the REPL may be
very slow because in some cases only one character is output per call to
mp_hal_stdout_tx_strn.

The location for a returned exception was changed to state[0] in
d95947b4

Changes to the layout of the bytecode header meant that this debug code was
no longer compiling.  This is now fixed and a new compile-time option is
introduced, MICROPY_DEBUG_VM_STACK_OVERFLOW, to turn on this feature (which
is disabled by default).  This option is needed because more than one file
needs to cooperate to make this check work.

Under python3 (tested with 3.6.7) bytes with a list of integers as an
argument returns a different result than under python 2.7 (tested with
2.7.15rc1) which causes pydfu.py to fail when run under 2.7.  Changing
bytes to bytearray makes pydfu work properly under both Python 2.7 and
Python 3.6.

Before this fix it returned SOFT_RESET after waking from a deepsleep
(standby).

On MCUs other than F4 the ORE (overrun error) flag needs to be cleared
independently of clearing RXNE, even though both are wired to trigger the
same RXNE IRQ.  In the case that an overrun occurred it's necessary to
explicitly clear the ORE flag or else the RXNE interrupt will keep firing.

Otherwise IRQs may not be enabled for the user UART.irq() handler.  In
particular this fixes the user IRQ_RXIDLE interrupt so that it triggers
even when there is no RX buffer.

Initial implementation of this is taken from the cc3200 port.

This mirrors what is done in mp_init.  Some RTOSs require this symmetry to
get back to a clean state (when doing a soft reset, for example).

It's more robust to have the version defined statically in a header file,
rather than dynamically generating it via git using a git tag.  In case
git doesn't exist, or a different source control tool is used, it's
important to still have the uPy version number available.

The new option MICROPY_HW_SDCARD_MOUNT_AT_BOOT can now be defined to 0 in
mpconfigboard.h to allow SD hardware to be enabled but not auto-mounted at
boot.  This feature is enabled by default to retain previous behaviour.

Previously, if an SD card is enabled in hardware it is also used to boot
from.  While this can be disabled with a SKIPSD file on internal flash,
this wont be available at first boot or if the internal flash gets
corrupted.

The older "bool has_finaliser" gets recast as GC_ALLOC_FLAG_HAS_FINALISER=1
so this is a backwards compatible change to the signature.  Since bool gets
implicitly converted to 1 this patch doesn't include conversion of all
calls.

Both mp_type_array and mp_type_memoryview use the same object structure,
mp_obj_array_t, but for the case of memoryview, some fields, e.g. "free",
have different meaning.  As the "free" field is also a bitfield, assume
that (anonymous) union can't be used here (for the concerns of possible
compatibility issues with wide array of toolchains), and just add a field
alias using a #define.  As it's a define, it should be a selective
identifier, so use verbose "memview_offset" to avoid any clashes.

If you happen to only have a really simple frozen file that doesn't contain
any new qstrs then the generated frozen_mpy.c file contains an empty
enumeration which causes a C compile time error.

GNU readline support for the unix port was removed in
acaa30b6 and in
5e83a75c, so it's also no longer supported
in the windows port.

To support deplop-openocd on target boards that use TEXT0_ADDR only and
have their firmware in a single binary image.

Following an equivalent fix to py/bc.c.  The reason the incorrect values
for the opcode constants were not previously causing a bug is because they
were never being used: these opcodes always have qstr arguments so the part
of the code that was comparing them would never be reached.

Thanks to @malinah for finding the problem and providing the initial patch.

All 4 opcodes that can have caching bytes also have qstrs, so the test for
them must go in the qstr part of the code.  The reason this incorrect
calculation of the opcode size did not lead to a bug is because the caching
byte is at the end of the opcode (byte, qstr, qstr, cache) and is always
0x00 when saving/loading, so was just treated as a single byte no-op
opcode.  Hence these opcodes were being saved/loaded/decoded correctly.

Thanks to @malinah for finding the problem and providing the initial patch.