These POSIX wrappers are assumed to be passed a concrete stream object so
it is more efficient (eg on nan-boxing builds) to pass in the pointer
rather than mp_obj_t, because then the users of these functions only need
to store a void* (and mp_obj_t may be wider than a pointer). And things
would be further improved if the stream protocol functions eventually took
a pointer as their first argument (instead of an mp_obj_t).
This patch is a step to getting ussl/axtls compiling on nan-boxing builds.
See issue #3085.
mpy-cross is a host, not target binary. It should not be build with the
target compiler, compiler options and other settings. For example,
If someone currently tries to build from pristine checkout the unix port
with the following command:
make CROSS_COMPILE=arm-linux-gnueabihf-
then mpy-cross will be built with arm-linux-gnueabihf-gcc and of course
won't run on the host, leading to overall build failure.
This situation was worked around for some options in 1d8c3f4cff, so add
MICROPY_FORCE_32BIT and CROSS_COMPILE to that set too.
The aim here is to have spi.c contain the low-level SPI driver which is
independent (not fully but close) of MicroPython objects and methods, and
the higher-level bindings are separated out to pyb_spi.c and machine_spi.c.
Among other things, this requires putting bootloader object files in to
their relevant .a archive, so that they can be correctly referenced by the
ESP IDF's linker script.
Otherwise there is the possibility that n_free starts out non-zero from the
previous iteration, which may have found a few (but not enough) free blocks
at the end of the heap. If this is the case, and if the very first blocks
that are scanned the second time around (starting at
gc_last_free_atb_index) are found to give enough memory (including the
blocks at the end of the heap from the previous iteration that left n_free
non-zero) then memory will be allocated starting before the location that
gc_last_free_atb_index points to, most likely leading to corruption.
This serious bug did not manifest itself in the past because a gc_collect
always resets gc_last_free_atb_index to point to the start of the GC heap,
and the first block there is almost always allocated to a long-lived
object (eg entries from sys.path, or mounted filesystem objects), which
means that n_free would be reset at the start of the search loop.
But with threading enabled with the GIL disabled it is possible to trigger
the bug via the following sequence of events:
1. Thread A runs gc_alloc, fails to find enough memory, and has a non-zero
n_free at the end of the search.
2. Thread A calls gc_collect and frees a bunch of blocks on the GC heap.
3. Just after gc_collect finishes in thread A, thread B takes gc_mutex and
does an allocation, moving gc_last_free_atb_index to point to the
interior of the heap, to a place where there is most likely a run of
available blocks.
4. Thread A regains gc_mutex and does its second search for free memory,
starting with a non-zero n_free. Since it's likely that the first block
it searches is available it will allocate memory which overlaps with the
memory before gc_last_free_atb_index.
- Allow configuration by a board of autorefresh number and burst length.
- Increase MPU region size to 8MiB.
- Make SDRAM region cacheable and executable.
"coverage" build uses different BUILD directory comparing to the normal
build. Previously, any build picked up libaxtls.a from normal build's
directory, but that was fixed recently. So, for each build, we must
build axtls explicitly.
This fixes Travis build in particular.
Use overrideable properties instead of hardcoding the use of the
default cl executable used by msvc toolsets. This allows using
arbitrary compiler commands for qstr header generation.
The CLToolExe and CLToolPath properties are used because they are,
even though absent from any official documentation, the de-facto
standard as used by the msvc toolsets themselves.
Without this patch, on 64-bit architectures the "1 << (small_int_bits - 1)"
is computed using only 32-bit values (since small_int_bits is a uint8_t)
and so will overflow (and give the wrong result) if small_int_bits is
larger than 32.
Requesting a baudrate of X should never configure the peripheral to have a
baudrate greater than X because connected hardware may not be able to
handle higher speeds. This patch makes sure to round the prescaler up so
that the actual baudrate is rounded down.
Input files like basics/string_format.py and float/string_format.py have
the same basename so using that name for writing the output (.exp and .out
files) when both tests fail, results in the output of the first one being
overwritten.
Avoid this by using unique names for the output, replacing path characters
with underscores.
There is no need to have three copies of the exception object on the top of
the native value stack. Instead, the values on the stack should be the
first two items in an nlr_buf_t: the prev pointer and the ret_val pointer.
This is all that is needed and is what the rest of the native emitter
expects is on the stack.
This patch is essentially an optimisation. Behaviour is unchanged,
although the stack layout for native exception handling now makes more
sense.
A native function allocates space on its C stack for mp_code_state_t,
followed by its Python stack, then its locals. This patch makes sure that
the native function actually starts at the start of its Python stack,
rather than at the start of mp_code_state_t (which didn't lead to any
issues so far because the mp_code_state_t is unused after the native
function sets itself up).
On x86 archs (both 32 and 64 bit) a bool return value only sets the 8-bit
al register, and the higher bits of the ax register have an undefined
value. When testing the return value of such cases it is required to just
test al for zero/non-zero. On the other hand, checking for truth or
zero/non-zero on an integer return value requires checking all bits of the
register. These two cases must be distinguished and handled correctly in
generated native code. This patch makes sure of this.
For other supported native archs (ARM, Thumb2, Xtensa) there is no such
distinction and this patch does not change anything for them.
The Python documentation recommends to pass the command as a string when
using Popen(..., shell=True). This is because "sh -c <string>" is used to
execute the command and additional arguments after the command string are
passed to the shell itself (not the executing command).
https://docs.python.org/3.5/library/subprocess.html#subprocess.Popen
Prior to this patch, if VBAT was read via ADC.read() or
ADCAll.read_channel(), then it would remain enabled and subsequent reads
of TEMPSENSOR or VREFINT would not work. This patch makes sure that VBAT
is disabled for all cases that it could be read.
DEBUG_printf and MICROPY_DEBUG_PRINTER is now used instead of normal
printf, and a fault is fixed in mp_obj_class_lookup with debugging enabled;
see issue #3999. Debugging can now be enabled on all ports including when
nan-boxing is used.
This patch in effect renames MICROPY_DEBUG_PRINTER_DEST to
MICROPY_DEBUG_PRINTER, moving its default definition from
lib/utils/printf.c to py/mpconfig.h to make it official and documented, and
makes this macro a pointer rather than the actual mp_print_t struct. This
is done to get consistency with MICROPY_ERROR_PRINTER, and provide this
macro for use outside just lib/utils/printf.c.
Ports are updated to use the new macro name.
The NRF52 define only covers nrf52832, so update the define checks
to use NRF52_SERIES to cover both nrf52832 and nrf52840.
Fixed machine_hard_pwm_instances table in modules/machine/pwm.c
This enables PWM(0) to PWM(3), RTCounter(2), Timer(3) and Timer(4),
in addition to NFC reset cause, on nrf52840.
The first dynamic qstr pool is double the size of the 'alloc' field of
the last const qstr pool. The built in const qstr pool
(mp_qstr_const_pool) has a hardcoded alloc size of 10, meaning that the
first dynamic pool is allocated space for 20 entries. The alloc size
must be less than or equal to the actual number of qstrs in the pool
(the 'len' field) to ensure that the first dynamically created qstr
triggers the creation of a new pool.
When modules are frozen a second const pool is created (generally
mp_qstr_frozen_const_pool) and linked to the built in pool. However,
this second const pool had its 'alloc' field set to the number of qstrs
in the pool. When freezing a large quantity of modules this can result
in thousands of qstrs being in the pool. This means that the first
dynamically created qstr results in a massive allocation. This commit
sets the alloc size of the frozen qstr pool to 10 or less (if the number
of qstrs in the pool is less than 10). The result of this is that the
allocation behaviour when a dynamic qstr is created is identical with an
without frozen code.
Note that there is the potential for a slight memory inefficiency if the
frozen modules have less than 10 qstrs, as the first few dynamic
allocations will have quite a large overhead, but the geometric growth
soon deals with this.
When waking from stop mode most of the system is still in the same state as
before entering stop, so only minimal configuration is needed to bring the
system clock back online.
Damien George
Paul Sokolovsky
forester3
stijn
David Lechner
Martin Dybdal
roland
Peter Hinch
Ayke van Laethem
Stig Bjørlykke
Rich Barlow