openmano-mpy/ports/windows/Makefile, branch master MicroPython source and hardware configuration for OpenMano windows/Makefile: Support freezing modules. 2020-09-11T00:52:52+00:00 stijn 2020-09-10T12:13:25+00:00 5b94c610971334019e7301026e0fbbf5950e094d Alter the build flags as needed to support freezing modules with a manifest. This makes freezing works just like it does for e.g. the unix port. 
Alter the build flags as needed to support freezing modules with a
manifest.  This makes freezing works just like it does for e.g. the unix
port.
all: Factor gchelper code to one place and use it for unix & ARM ports. 2020-04-29T13:45:19+00:00 Jim Mussared 2020-04-23T06:12:55+00:00 710426024aece6d248c26bef6627bc3fac13f612 No functionality change is intended with this commit, it just consolidates the separate implementations of GC helper code to the lib/utils/ directory as a general set of helper functions useful for any port. This reduces duplication of code, and makes it easier for future ports or embedders to get the GC implementation correct. Ports should now link against gchelper_native.c and either gchelper_m0.s or gchelper_m3.s (currently only Cortex-M is supported but other architectures can follow), or use the fallback gchelper_generic.c which will work on x86/x64/ARM. The gc_helper_get_sp function from gchelper_m3.s is not really GC related and was only used by cc3200, so it has been moved to that port and renamed to cortex_m3_get_sp. 
No functionality change is intended with this commit, it just consolidates
the separate implementations of GC helper code to the lib/utils/ directory
as a general set of helper functions useful for any port.  This reduces
duplication of code, and makes it easier for future ports or embedders to
get the GC implementation correct.

Ports should now link against gchelper_native.c and either gchelper_m0.s or
gchelper_m3.s (currently only Cortex-M is supported but other architectures
can follow), or use the fallback gchelper_generic.c which will work on
x86/x64/ARM.

The gc_helper_get_sp function from gchelper_m3.s is not really GC related
and was only used by cc3200, so it has been moved to that port and renamed
to cortex_m3_get_sp.
all: Enable extra conversion warnings where applicable. 2020-04-18T12:42:28+00:00 stijn 2020-04-09T11:59:11+00:00 30840ebc9925bb8ef025dbc2d5982b1bfeb75f1b Add -Wdouble-promotion and -Wfloat-conversion for most ports to ban out implicit floating point conversions, and add extra Travis builds using MICROPY_FLOAT_IMPL_FLOAT to uncover warnings which weren't found previously. For the unix port -Wsign-comparison is added as well but only there since only clang supports this but gcc doesn't. 
Add -Wdouble-promotion and -Wfloat-conversion for most ports to ban out
implicit floating point conversions, and add extra Travis builds using
MICROPY_FLOAT_IMPL_FLOAT to uncover warnings which weren't found
previously.  For the unix port -Wsign-comparison is added as well but only
there since only clang supports this but gcc doesn't.
unix: Remove custom file implementation to use extmod's VFS POSIX one. 2020-03-18T10:01:07+00:00 Damien George 2020-03-18T06:47:15+00:00 2cdf1d25f59409b6130c0e8b6cf50300aed2d7e6 The implementation in extmod/vfs_posix_file.c is now equivalent to that in ports/unix/file.c, so remove the latter and use the former instead. 
The implementation in extmod/vfs_posix_file.c is now equivalent to that in
ports/unix/file.c, so remove the latter and use the former instead.
windows: Default to binary mode for files. 2019-09-18T12:15:48+00:00 stijn 2017-08-14T10:01:38+00:00 bc86c6252ab1b9a9ee47a44d7ccc9e1a9d74f207 If this is not set it might default to calls to open() to use text mode which is usually not wanted, and even wrong and leading to incorrect results when loading binary .mpy files. This also means that text files written and read will not have line-ending translation from \n to \r\n and vice-versa anymore. This shouldn't be much of a problem though since most tools dealing with text files adapt automatically to any of the 2 formats. 
If this is not set it might default to calls to open() to use text mode
which is usually not wanted, and even wrong and leading to incorrect
results when loading binary .mpy files.

This also means that text files written and read will not have line-ending
translation from \n to \r\n and vice-versa anymore.  This shouldn't be much
of a problem though since most tools dealing with text files adapt
automatically to any of the 2 formats.
windows/Makefile: Make use of CFLAGS_EXTRA, LDFLAGS_EXTRA and SRC_MOD. 2019-09-10T01:20:36+00:00 Andrew Leech 2019-09-06T00:56:03+00:00 380048df64255e869d168b0bf4ebc4b6138a6eb2 To be consistent with the unix port. 
To be consistent with the unix port.
windows: Remove remaining traces of old GNU readline support. 2018-12-15T02:54:55+00:00 Damien George 2018-12-15T02:54:55+00:00 0c46419323f95ac406749ec317eaeaae4e460242 GNU readline support for the unix port was removed in acaa30b6046d449f5f58a8f02c83459702759df7 and in 5e83a75c78dc8c370b25e7ee669295854ea45130, so it's also no longer supported in the windows port. 
GNU readline support for the unix port was removed in
acaa30b6046d449f5f58a8f02c83459702759df7 and in
5e83a75c78dc8c370b25e7ee669295854ea45130, so it's also no longer supported
in the windows port.
windows: Make printing of debugging info work out of the box. 2018-07-05T09:44:18+00:00 stijn 2018-07-03T10:30:42+00:00 106e594580d4de2d680c7ceefc7a1c331b4de3dd Printing debugging info by defining MICROPY_DEBUG_VERBOSE expects a definition of the DEBUG_printf function which is readily available in printf.c so include that file in the build. Before this patch one would have to manually provide such definition which is tedious. For the msvc port disable MICROPY_USE_INTERNAL_PRINTF though: the linker provides no (easy) way to replace printf with the custom version as defined in printf.c. 
Printing debugging info by defining MICROPY_DEBUG_VERBOSE expects
a definition of the DEBUG_printf function which is readily available
in printf.c so include that file in the build. Before this patch
one would have to manually provide such definition which is tedious.

For the msvc port disable MICROPY_USE_INTERNAL_PRINTF though: the
linker provides no (easy) way to replace printf with the custom
version as defined in printf.c.
py/nlr: Fix nlr functions for 64bit ports built with gcc on Windows 2017-12-29T11:24:46+00:00 stijn 2017-12-26T09:52:09+00:00 b184b6ae5334b87472897d0034a7388acafe41cc 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) 
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)
all: Update Makefiles and others to build with new ports/ dir layout. 2017-09-06T04:09:13+00:00 Damien George 2017-09-06T04:09:13+00:00 4a93801c12898898744131f57d79cf216d0861b3 Also renames "stmhal" to "stm32" in documentation and everywhere else. 
Also renames "stmhal" to "stm32" in documentation and everywhere else.