This function was made private/static in IDF commit
c67f4c2b4c2bb4b7740f988fc0f8a3e911e56afe, so it add back here.
Signed-off-by: Damien George <damien@micropython.org>
Tests framebuf1 and framebuf2 do not take the need for byte-aligned
strides into consideration when calculating buffer lengths.
Accordingly, the buffers allocated are slightly too small. Fixed
buffer length calculations.
Signed-off-by: Duncan Lowther <Duncan.Lowther@glasgow.ac.uk>
Structure descriptor in test extmod/uctypes_array_assign_le
is 6 bytes long, due to member "arr3" having length 4
(2 * UINT16) and offset 2, but only 5 bytes are allocated.
Increased buffer length to 6 bytes.
Signed-off-by: Duncan Lowther <Duncan.Lowther@glasgow.ac.uk>
The mod_binascii_a2b_base64() function allocates a buffer which may be
too small. It needs to be no less than three-quarters of the input
length, but is calculated as (<length> / 4) * 3 + 1, which may be less
due to integer division. Changed to (<length> * 3) / 4 + 1.
Signed-off-by: Duncan Lowther <Duncan.Lowther@glasgow.ac.uk>
This allows existing code that does `import uasyncio` or
`import uasyncio as asyncio` to continue working.
It uses the same lazy-loading as asyncio to prevent loading of unused
features.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Mostly updates comments, but also renames the UASYNCIO enum value to
ASYNCIO.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
The asyncio module now has much better CPython compatibility and
deserves to be just called "asyncio".
This will avoid people having to write `from uasyncio import asyncio`.
Renames all files, and updates port manifests to use the new path. Also
renames the built-in _uasyncio to _asyncio.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Instead of having a special set of arguments to test for each math-module
function, just test all functions with all sets of arguments. This gives
improved test cases to prevent regressions.
Signed-off-by: Damien George <damien@micropython.org>
Commit c046b23ea2 prevented frozen boot code
from being interrupted by Ctrl-C, but that means a corrupt filesystem will
forever lock up an esp32/esp8266 board. This commit fixes that by
explicitly enabling Ctrl-C before running the forever loop.
Signed-off-by: Damien George <damien@micropython.org>
This commit adds initial support for STM32H5xx MCUs. The following
features have been confirmed to be working on an STM32H573:
- UART over REPL and USB CDC
- USB CDC and MSC
- internal flash filesystem
- machine.Pin
- machine.SPI transfers with DMA
- machine.ADC
- machine.RTC
- pyb.LED
- pyb.Switch
- pyb.rng
- mboot
Signed-off-by: Damien George <damien@micropython.org>
The G0 USB peripheral behaves more like MICROPY_HW_USB_IS_MULTI_OTG=0 than
that config =1. This fixes the configuration of the PMA FIFO buffers.
Signed-off-by: Damien George <damien@micropython.org>
For debugging purposes, to see output from other peripherals.
Also reset the pyb_stdio_uart state at the end of soft reset, in case it
points to a heap-allocated object.
Signed-off-by: Damien George <damien@micropython.org>
PEP-498 allows for conversion specifiers like !r and !s to convert the
expression declared in braces to be passed through repr() and str()
respectively.
This updates the logic that detects the end of the expression to also stop
when it sees "![rs]" that is either at the end of the f-string or before
the ":" indicating the start of the format specifier. The "![rs]" is now
retained in the format string, whereas previously it stayed on the end
of the expression leading to a syntax error.
Previously: `f"{x!y:z}"` --> `"{:z}".format(x!y)`
Now: `f"{x!y:z}"` --> `"{!y:z}".format(x)`
Note that "!a" is not supported by `str.format` as MicroPython has no
`ascii()`, but now this will raise the correct error.
Updated cpydiff and added tests.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
So that the delegation functions don't need to be put somewhere global,
like in mpconfigport.h. That would otherwise make it hard for extension
modules to use delegation.
Signed-off-by: Damien George <damien@micropython.org>
Starting with 2757acf6, the `top` variable in `nlr_jump()` in
`nlraarch64.c` was assigned to register `x19` by the compiler. However,
the assembly code writes over that register with
ldp x19, x20, [%0, #32]
since `%0` is now `x19`. This causes the next line
ldp lr, x9, [%0, #16]
to load the wrong values.
To fix the issue, we move the value of the `top` variable from an unknown
register to a known register at the beginning of the asm code then only use
known/hard-coded registers after that.
Fixes issue #11754.
Signed-off-by: David Lechner <david@pybricks.com>
This change enables the ULP (FSM) for all ESP32 variants rather than
requiring it to be enabled for each board specifically.
It also ensures the correct header file is included for each variant.
Lastly, it updates the IDF version we're builing against to v4.4.2, as that
version contains important fixes to make the ULP actually work on S2/S3
chips. See: https://github.com/espressif/esp-idf/commit/a0e3d48
Signed-off-by: Wilko Nienhaus <wilko.nienhaus@gmail.com>
In 5fe2a3f1 the ESP32 port underwent a change to how `MICROPY_PORT_DIR`
is defined. This commit normalizes the `rp2` port to use the same
underlying variable mechanism (`CMAKE_CURRENT_LIST_DIR`).
Signed-off-by: Brian 'redbeard' Harrington <redbeard@dead-city.org>
This migrates the CMake variable `MICROPY_PORT_DIR` from the ESP-IDF
defined project to the component. Previously used instances of the variable
within the project definition have been migrated to
`CMAKE_CURRENT_LIST_DIR`. Within the component (the `main` subdirectory in
the ESP32 port) we define `MICROPY_PORT_DIR` using `CMAKE_CURRENT_LIST_DIR`
and subsequently use the `MICROPY_PORT_DIR` value in all locations where
`PROJECT` had previously been used.
Context:
In commit 9b90882146, initial support was added for building with the newly
introduced CMake support provided by the ESP-IDF.
Specifically, the commit message states:
> This commit adds support for building the esp32 port with CMake, and in
particular, it builds MicroPython as a component within the ESP-IDF. Using
CMake and the ESP-IDF build infrastructure makes it much easier to maintain
the port, especially with the various new ESP32 MCUs and their required
toolchains.
`PROJECT_DIR` is a variable populated by the ESP-IDF specifically and is
not stable when used with "[Pure CMake components][1]" as documented in the
ESP-IDF. It is intended to be used in the scope of the parent of the
current file (the "project") as opposed to the current file ("the
component"). Crossing into the parent scope like this works solely when the
"project" is MicroPython, but not when used as a component by other ESP-IDF
projects.
Analyzing this file, the intention is to reference the "Project" which in
the example is the parent directory. Within the [CMake variables][2]
documentation, there is one specifically defined for referencing the
directory for the CMake listfile currently being processed:
[`CMAKE_CURRENT_LIST_DIR`][3].
After making the change from `PROJECT_DIR` to `CMAKE_CURRENT_LIST_DIR`, the
reach into the parent scope defined by the ESP-IDF and the resulting CMake
interface violation is removed.
Similar to the component definition, the project `CMakeLists.txt` uses the
variable `CMAKE_SOURCE_DIR` which CMake defines as "The path to the top
level of the source tree." This commit changes the variable to
`CMAKE_CURRENT_LIST_DIR` for the reasons cited above.
[1]: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/build-system.html#writing-pure-cmake-components
[2]: https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html
[3]: https://cmake.org/cmake/help/latest/variable/CMAKE_CURRENT_LIST_DIR.html
Signed-off-by: Brian 'redbeard' Harrington <redbeard@dead-city.org>
Following how mkrules.cmake works. This makes it easy for a port to enable
frozen code, by defining FROZEN_MANIFEST in its Makefile.
Signed-off-by: Damien George <damien@micropython.org>
Damien George