Factor out mp_os_urandom() of each port into extmod/modos.c, which then
calls the port-specific function mp_hal_get_random().
Move mp_hal_get_random() to mphalport where suitable. At the
MIMXRT and SAMD it is left in modos.c, since there are different
implementation depending on the MCU family.
At the ALIF, ESP32, CC3200 and RP2 port the file modos.c was removed,
since it was empty after moving mp_hal_get_random().
Tested for the cc3200, esp32, esp8266, mimxrt, nrf, rp2, samd, stm32
and unix ports. Compiled for the alif and the renesas port.
Signed-off-by: robert-hh <robert@hammelrath.com>
The aim of this commit is to clarify the command line options available.
While they are available as well as in the CLI with --help, it's useful to
document them and provide a few examples.
Signed-off-by: Jos Verlinde <jos_verlinde@hotmail.com>
Call `mp_event_handle_nowait()` in the VFS reader buffer refill path so
that pending scheduled events (USB task, network poll, etc.) get processed
during long-running import/parse/compile operations.
Without this, importing a large Python module from the filesystem blocks
for too long causing TinyUSB event queue to overflow. For example, on
renesas-ra, running a script that imports iperf3 via mpremote run, asserts,
most likely due to SOF interrupts not getting processing:
queue_event at lib/tinyusb/src/device/usbd.c:382
dcd_event_handler at lib/tinyusb/src/device/usbd.c:1318
dcd_event_sof at lib/tinyusb/src/device/dcd.h:237
dcd_int_handler at tinyusb/src/portable/renesas/rusb2/dcd_rusb2.c:964
<signal handler called>
disk_ioctl at extmod/vfs_fat_diskio.c:125
validate at lib/oofatfs/ff.c:3359
f_read at lib/oofatfs/ff.c:3625
file_obj_read at extmod/vfs_fat_file.c:75
mp_stream_rw at py/stream.c:60
mp_reader_vfs_readbyte at extmod/vfs_reader.c:59
next_char at py/lexer.c:174
mp_lexer_to_next at py/lexer.c:713
mp_parse at py/parse.c:1167
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
This commit introduces a test that should check whether viper load or
store operations won't clobber either the buffer address or the index
value being used.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
This commit lets the native emitter preserve the value of the index
register when performing register-indexed loads or stores for halfword
or word values on RV32.
The original code was optimised too aggressively to reduce the generated
code's size, using compressed opcodes that alias the target register to
one of the operands. In register-indexed load/store operations, the
index register was assumed to be allocated somewhere safe, but it was
not always the case.
To solve this, now all halfword and word register-indexed operations
will use REG_TEMP2 to store the scaled index register. The size penalty
on generated code varies across operation sizes and enabled extensions:
- byte operations stay the same size with or without Zba
- halfword operations will be 2 bytes larger without Zba, and will stay
the same size with Zba
- word operations will be 4 bytes larger without Zba, and 2 bytes larger
with Zba
There is also a minor firmware footprint increase to hold the extra
logic needed for conditional register clobbering, but it shouldn't be
that large anyway.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
This commit lets the native emitter preserve the value of the index
register when performing register-indexed loads or stores of halfword or
word values on Thumb.
The original code was optimised too aggressively for a register-starved
architecture like Thumb, and the index value in the sequence to generate
was assumed to be allocated somewhere safe. This is valid on other
architectures, but not on Thumb.
To solve this, load operations do clobber a temporary register that
should be safe to use, REG_TEMP2, to store the scaled register offset.
REG_TEMP2's value is only used within the scope of a single ASM API
instruction. Save operations unfortunately use a register that is
aliased to REG_TEMP2, since they need to have three values in registers
to perform the operation. This means the index register needs to be
pushed to the stack before performing the scale + store operation, and
then popped from the stack. That's a 4 bytes penalty on each store and
a minor speed hit on generated code (plus a minor footprint increase of
the firmware image).
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
When the timeout parameter of `esp32.RMT.wait_done()` is set to a non-zero
value, the underlying `rmt_tx_wait_all_done` blocks (it passes the timeout
to `xQueueReceive`). Thus we should release the GIL so that other
MicroPython threads are not blocked from running.
Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>
Replace the custom rosc_random_u8()/rosc_random_u32() implementation with
the pico_rand API from the Pico SDK. The RP2040 datasheet notes that ROSC
"does not meet the requirements of randomness for security systems because
it can be compromised", and the current 8-bit LFSR conditioning is not a
vetted algorithm under NIST SP 800-90B.
pico_rand uses various hardware RNG sources depending on the available
platform (including the RP2350 hardware TRNG) and is officially supported
and maintained as part of the Pico SDK.
This changes os.urandom(), the mbedTLS entropy source, the PRNG seed, and
the lwIP random function to all use pico_rand, and removes the custom ROSC
random functions from main.c.
Signed-off-by: Michel Le Bihan <michel@lebihan.pl>
The Pololu Zumo 2040 Robot is supported in pico-sdk now so we should not
include the header file here anymore, similarly to other boards. This is
necessary for future changes from the SDK to be reflected in MicroPython
builds.
Signed-off-by: Paul Grayson <paul@pololu.com>
It's already provided because `MICROPY_PY_IO` is enabled.
Tested on `bbc_microbit_v2`, there is now only a single open.
Signed-off-by: Damien George <damien@micropython.org>
The `builtins.help` function is automatically included when
`MICROPY_PY_BUILTINS_HELP` is enabled, which is true for this port.
The `builtins.open` function is automatically included when
`MICROPY_PY_IO` is enabled, which is true when `MICROPY_VFS` is enabled on
this port. If `MICROPY_MBFS` is enabled instead of the VFS then `open`
must be explicitly provided.
Tested on:
- ARDUINO_NANO_33_BLE_SENSE: now has only a single `help` and `open`
- MICROBIT: now has only a single `help` and `open`
- MICROBIT with MICROPY_MBFS enabled: `help` and `open` both still exist
and `open` works with mbfs
Signed-off-by: Damien George <damien@micropython.org>
The webassembly port does not have anything that needs polling when waiting
for events, so it can just use the default (empty) definitions of
`MICROPY_INTERNAL_WFE` and `MICROPY_INTERNAL_EVENT_HOOK`.
Signed-off-by: Damien George <damien@micropython.org>
- `timer.c`
- `TIM_ENTRY(7, ...)` sets IRQ based on specific STM32G4 part
- `system_stm32.c`
- Support parts without external clock
- `boards/NUCLEO_G474RE/mpconfigboard.h`
- Explicitly enable `MICROPY_HW_RTC_USE_LSE`
Signed-off-by: Thomas Propst <tom.propst@gmail.com>
This commit performs a few minor changes to the structures used to store
board pin information, in order to reduce the impact on the .rodata
section of the firmware of instances of those structures.
The pin objects structure ("machine_pin_obj_t") instead has its QSTR
variable holder changed from "qstr" to "qstr_short_t", and some elements
of that structure have been rearranged to remove enough padding bytes
inside structure elements to let the linker allocate less data for
instances of that structure.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
Convert the stm32 port from the old `MICROPY_EVENT_POLL_HOOK` macro to use
the new `mp_event_wait_xxx()` functions in conjunction with
`MICROPY_INTERNAL_WFE`.
This change should be functionally equivalent to the existing behaivour
because `mp_event_wait_ms()` and `mp_event_wait_indefinite()` are equal to
`mp_handle_pending(true); __WFI()`, which is what `MICROPY_EVENT_POLL_HOOK`
was.
Note that the `CYW43_EVENT_POLL_HOOK` macro needed to be overridden,
otherwise it would just call `mp_event_handle_nowait()` which would create
power hungry busy loops.
Signed-off-by: Damien George <damien@micropython.org>
The old code was only handling `\r` and ignoring `\n`, which is a problem
for systems that only send `\n` as a newline. This commit handles it
better, supporting both characters.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
Add support for RISC-V RV32IMC native code emitter in the zephyr port. It
will be automatically enabled by default, but can be overridden by defining
`MICROPY_EMIT_RV32` and/or `MICROPY_EMIT_INLINE_RV32`.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
By putting the heap in the noinit area instead of the bss area, zephyr
won't memset it to zero during start. This improves startup time, in
particular if the heap is very big. The system heap of zephyr is also in
the same section.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
Zephyr and MicroPython both have a variant of FatFs, but having both
enabled leads to build fails.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
If the return value is set only when certain condition are true,
the compiler sometimes raises an error.
Signed-off-by: robert-hh <robert@hammelrath.com>
This commit migrates handling of certain narrow (ie. 16-bits) opcodes
from a per-opcode dedicated code snippet to the existing table-driven
opcode handler.
The final ESP8266 firmware binary is 64 bytes shorter, without any
change in the existing behaviour and with a reduced source code lines
count too.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
This commit introduces support for writing inline assembler code
snippets when targeting Xtensa cores that use register windows (eg.
the whole ESP32 family).
Opcodes support is still limited to what the ESP8266 supports (as in,
LX3 cores opcodes), however each LX core version is guaranteed to
support all previous versions' opcodes as well. The ESP32 does not have
the inline assembler enabled by default, following the existing
expectations when it comes to firmware footprint.
Since now emitted functions may have one of two possible exit sequences,
the L32I test had to be fixed. It would return the word containing the
L32I opcode itself, but the upper 8 bits of the word came from the
following opcode - which can change depending on the exit code sequence.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
Explicitly specify the wanted cast otherwise this results in
warning C4244: '=': conversion from 'unichar' to 'char',
possible loss of data
when building with msvc with most warnings enabled.
Signed-off-by: stijn <stijn@ignitron.net>
This provides the DEBUG_printf definition which is needed when
defining MICROPY_DEBUG_VERBOSE, and is consistent with all other ports.
Signed-off-by: stijn <stijn@ignitron.net>
This is the only location in the code base that uses `mp_obj_tuple_del()`,
so we can reduce code size by reworking the iter code not to use that
function.
The zip iter implementation should now have slightly better GC behaviour:
it only allocates the return tuple if needed, instead of allocating it and
then freeing it when the zip iterator is exhausted.
Signed-off-by: Damien George <damien@micropython.org>
Both mbedTLS and axTLS have support for producing more detailed error
strings. However, these are not used if the error is raised in stream
protocol functions (read/write/ioctl).
This commit adds support for more detailed error messages from streams.
Under the hood it's using a new MP_STREAM_RAISE_ERROR ioctl request to pass
the error code back to the stream implementation which can raise a more
detailed error. If the ioctl is not implemented, we fall back to the old
behaviour and raise an OSError with the error code.
Currently the detailed messages are only implemented for TLS sockets since
those already had helper functions for raising detailed exceptions, but can
be easily implemented in any other stream.
Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>
This argument isn't expected to be passed from Python code, but - as
pointed out - it doesn't make sense how the irq() mechanism works
otherwise.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
As we add the object files to the linker command line directly,
they go after the other library dependencies and therefore don't
resolve their dependencies. Turns out the only dependent symbol of
the btree library is abort_, so explicitly include it in the link.
The old way of linking the entire library is cleaner, but stopped working
with ESP-IDF V5.5...
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
The esp32 port (and esp8266) doesn't read from dupterm in
`mp_hal_stdin_rx_chr()` is because it uses `os.dupterm_notify()` instead,
which forces a read of the dupterm sources from Python. That function
should be called when it's known that there is input to read.
Nevertheless, this commit adds code to explicitly poll dupterm in
`mp_hal_stdin_rx_chr()`, following other ports like rp2.
Signed-off-by: Matthias Urlichs <matthias@urlichs.de>
This is a follow up to 6436f8b93f that
catches more cases of a failed raw REPL.
If the target device is broken in a certain way then it can have a serial
write error instead of just not returning any data. In that case the error
raised by `pyboard.py` is "could not enter raw repl: Write timeout", which
is slightly different to "could not enter raw repl" (the latter is raised
when a serial read fails to return the correct data).
The patch here accounts for all cases of a failed raw REPL by using
`str.startswith()` instead of a string equality.
This can be tested on RPI_PICO_W and RPI_PICO2_W which currently crash in
the specific way needed to trigger the write timeout when running the
`tests/extmod/socket_badconstructor.py` test. In particular adding the
following code to the end of a test (eg `tests/extmod/random_extra.py`)
will trigger the issue:
import socket
try:
s = socket.socket(socket.AF_INET, socket.SOCK_RAW, None)
except TypeError:
pass
With the fix here, the `run-tests.py` and `run-natmodtests.py` will abort
early if that code is added (prior to the fix they would continue to run
all tests and take a long time).
Signed-off-by: Damien George <damien@micropython.org>
As per the implementation of m_malloc0, if
MICROPY_GC_CONSERVATIVE_CLEAR is set then all RAM is guaranteed to be
zero-init by gc_alloc.
py/objstr.c: Guard the explicit zero init in bytes_make_new
against being run, initialising the RAM to zero a second time, if this
flag is set.
Signed-off-by: Phil Howard <github@gadgetoid.com>