This feature is controlled at compile time by MICROPY_PY_URE_MATCH_GROUPS,
disabled by default.
Thanks to @dmazzella for the original patch for this feature; see #3770.
This function may be called from a UART IRQ, which may interrupt the system
when it is erasing/reading/writing flash. In such a case all code
executing from the IRQ must be in iRAM (because the SPI flash is busy), so
put mp_keyboard_interrupt in iRAM so ctrl-C can be caught during flash
access.
This patch also takes get_fattime out of iRAM and puts it in iROM to make
space for mp_keyboard_interrupt. There's no real need to have get_fattime
in iRAM because it calls other functions in iROM.
Fixes issue #3897.
Before this patch the context manager's __aexit__() method would not be
executed if a return/break/continue statement was used to exit an async
with block. async with now has the same semantics as normal with.
The fix here applies purely to the compiler, and does not modify the
runtime at all. It might (eventually) be better to define new bytecode(s)
to handle async with (and maybe other async constructs) in a cleaner, more
efficient way.
One minor drawback with addressing this issue purely in the compiler is
that it wasn't possible to get 100% CPython semantics. The thing that is
different here to CPython is that the __aexit__ method is not looked up in
the context manager until it is needed, which is after the body of the
async with statement has executed. So if a context manager doesn't have
__aexit__ then CPython raises an exception before the async with is
executed, whereas uPy will raise it after it is executed. Note that
__aenter__ is looked up at the beginning in uPy because it needs to be
called straightaway, so if the context manager isn't a context manager then
it'll still raise an exception at the same location as CPython. The only
difference is if the context manager has the __aenter__ method but not the
__aexit__ method, then in that case uPy has different behaviour. But this
is a very minor, and acceptable, difference.
This will allow implementations other than axTLS.
This commit includes additions of checks and clarifications of exceptions
related to user input.
To make the interface cleaner, I've disallowed switching from encrypt to
decrypt in the same object, as this is not always possible with other
crypto libraries (not all libraries have AES_convert_key like axTLS).
Allow including crypto consts based on compilation settings. Disabled by
default to reduce code size; if one wants extra code readability, can
enable them.
Target RAM size is no longer set using Kconfig options, but instead using
DTS (device tree config). Fortunately, the default is now set to a high
value, so we don't need to use DTS fixup.
CONFIG_NET_NBUF_RX_COUNT no longer exists in Zephyr, for a while. That
means we build with the default RX buf count for a while too, and it works,
so just remove it (instead of switching to what it was renamed to,
CONFIG_NET_PKT_RX_COUNT).
These can be optionally specified, but all ports are expected to be able to
accept them, at the very least ignore, though handling of "type" param
(SOCK_STREAM vs SOCK_DGRAM) is recommended.
The API follows guidelines of https://www.python.org/dev/peps/pep-0272/,
but is optimized for code size, with the idea that full PEP 0272
compatibility can be added with a simple Python wrapper mode.
The naming of the module follows (u)hashlib pattern.
At the bare minimum, this module is expected to provide:
* AES128, ECB (i.e. "null") mode, encrypt only
Implementation in this commit is based on axTLS routines, and implements
following:
* AES 128 and 256
* ECB and CBC modes
* encrypt and decrypt
Prior to this patch, if both USB FS and HS were enabled via the
configuration file then code was included to handle both of their IRQs.
But mboot only supports listening on a single USB peripheral, so this patch
excludes the code for the USB that is not used.
Only one of pcd_fs_handle/pcd_hs_handle is ever initialised, so if both of
these USB peripherals are enabled then one of these if-statements will
access invalid memory pointed to by an uninitialised Instance. This patch
fixes this bug by explicitly referencing the peripheral struct.
This patch adds support to mboot for programming external SPI flash. It
allows SPI flash to be programmed via a USB DFU utility in the same way
that internal MCU flash is programmed.
Prior to this patch the QSPI driver assumed that the length of all data
reads and writes was a multiple of 4. This patch allows any length. Reads
are optimised for speed by using 32-bit transfers when possible, but writes
always use a byte transfer because they only use a single data IO line and
are relatively slow.
The DMA peripheral is limited to transferring 65535 elements at a time so
in order to send more than that the SPI driver must split the transfers up.
The user must be aware of this limit if they are relying on precise timing
of the entire SPI transfer, because there might be a small delay between
the split transfers.
Fixes issue #3851, and thanks to @kwagyeman for the original fix.
Damien George
Yonatan Goldschmidt
Paul Sokolovsky
jcea
rolandvs