The machine.sleep() function can be misleading because it clashes with
time.sleep() which has quite different semantics. So change it to
machine.lightsleep() which shows that it is closer in behaviour to
machine.deepsleep().
Also, add an optional argument to these two sleep functions to specify a
maximum time to sleep for. This is a common operation and underlying
hardware usually has a special way of performing this operation.
The existing machine.sleep() function will remain for backwards
compatibility purposes, and it can simply be an alias for
machine.lightsleep() without arguments. The behaviour will be the same.
If MICROPY_PERSISTENT_CODE_LOAD or MICROPY_ENABLE_COMPILER are enabled then
code gets enabled that calls file reading functions which may be disabled
if no readers have been implemented.
To fix this, introduce a MICROPY_HAS_FILE_READER variable, which is
automatically set if MICROPY_READER_POSIX or MICROPY_READER_VFS is set but
can also be manually set if a custom reader is being implemented. Then
disable the file reading calls if this is not set.
For architectures where size_t is less than 32 bits (eg 16 bits) the args
must be casted to uint32_t so the left shift will work. For architectures
where size_t is greater than 32 bits (eg 64 bits) this new casting will not
lose any bits because the end result must anyway fit in a uint32_t.
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.
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.
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.
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.
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.
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.
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.
Damien George
Sean Burton
Paul Sokolovsky
Matt Trentini
stijn
Dave Hylands
roland
Tobias Badertscher
Andrew Leech