There's no need to have these as separate functions, they just take up
unnecessary code space and combining them allows to factor common code, and
also allows to support arbitrary string descriptor indices.
The routine waits for the DMA to finish, which is signalled from a DMA IRQ
handler. Using WFI makes the CPU sleep while waiting for the IRQ to arrive
which decreases power consumption. To make it work correctly the check for
the change in state must be atomic and so IRQs must be disabled during the
check. The key feature of the Cortex MCU that makes this possible is that
WFI will exit when an IRQ arrives even if IRQs are disabled.
CPython doesn't allow SEEK_CUR with non-zero offset for files in text mode,
and uPy inherited this behaviour for both text and binary files. It makes
sense to provide full support for SEEK_CUR of binary-mode files in uPy, and
to do this in a minimal way means also allowing to use SEEK_CUR with
non-zero offsets on text-mode files. That seems to be a fair compromise.
Build and test 32bit and 64bit versions of the windows port using gcc
from mingw-w64. Note a bunch of tests which rely on floating point
math/printing have been disabled for now since they fail.
This commit fixes two things:
1. Do not allocate on the heap in readblocks() - unless the block size
is bigger than 512 bytes.
2. Raise an error instead of returning 1 to indicate an error: the FAT
block device layer does not check the return value. And other
backends (e.g. esp32 blockdev) also raise an error instead of
returning non-zero.
The number of registers used should be 10, not 12, to match the assembly
code in nlrx64.c. With this change the 64bit mingw builds don't need to
use the setjmp implementation, and this fixes miscellaneous crashes and
assertion failures as reported in #1751 for instance.
To avoid mistakes in the future where something gcc-related for Windows
only gets fixed for one particular compiler/environment combination,
make use of a MICROPY_NLR_OS_WINDOWS macro.
To make sure everything nlr-related is now ok when built with gcc this
has been verified with:
- unix port built with gcc on Cygwin (i686-pc-cygwin-gcc and
x86_64-pc-cygwin-gcc, version 6.4.0)
- windows port built with mingw-w64's gcc from Cygwin
(i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc, version 6.4.0)
and MSYS2 (like the ones on Cygwin but version 7.2.0)
Damien George
Hemanth kumar
Ayke van Laethem
stijn
Peter D. Gray
Jim Mussared