GitLab

As already mentioned in the docs, not all constants may be available on all
ports, so this is optional to implement.

Previously specifying None as the pull value would leave the pull up/down
state unchanged.  This change makes it so -1 leaves the state unchanged and
None makes the pin float, as per the docs.

In this port JavaScript is the underlying "machine" and MicroPython is
transmuted into JavaScript by Emscripten.  MicroPython can then run under
Node.js or in the browser.

Adds a new board configuration for the frdm_kw41z board, including support
for the fxos8700 accelerometer/magnetometer/die temperature sensor.

Adds the fxos8700 accelerometer/magnetometer/die temperature sensor to the
frdm_k64f board configuration.

Prompted by code size analysis, after arduino_101 build overflowing ROM.

I.e. on-die temperature sensor.  Upstream made more fine-grained channels
for different kinds of temperature.

Underlying k_call_stacks_analyze() was gone in Zephyr, reimplement using
k_thread_foreach().

The system provided one is in ROM and is more accurate.

Functions in these files may be needed when certain features are enabled
(eg dual core mode), even if the linker does not give a warning or error
about unresolved symbols.

The override #define's should go in the board's mpconfigboard.h file.

The default speed of the QSPI interface is 72Mhz whereas the standard AF
pin speed (high) is only rated to 50Mhz, so increase speed to very-high.

How to use this feature is documented in docs/develop/cmodules.rst.

This system makes it a lot easier to include external libraries as static,
native modules in MicroPython.  Simply pass USER_C_MODULES (like
FROZEN_MPY_DIR) as a make parameter.

During make, makemoduledefs.py parses the current builds c files for
MP_REGISTER_MODULE(module_name, obj_module, enabled_define)

These are used to generate a header with the required entries for
"mp_rom_map_elem_t mp_builtin_module_table[]" in py/objmodule.c

This adds support to freeze .mpy files that contain native code blocks.

This commit adds support for saving and loading .mpy files that contain
native code (native, viper and inline-asm).  A lot of the ground work was
already done for this in the form of removing pointers from generated
native code.  The changes here are mainly to link in qstr values to the
native code, and change the format of .mpy files to contain native code
blocks (possibly mixed with bytecode).

A top-level summary:

- @micropython.native, @micropython.viper and @micropython.asm_thumb/
  asm_xtensa are now allowed in .py files when compiling to .mpy, and they
  work transparently to the user.

- Entire .py files can be compiled to native via mpy-cross -X emit=native
  and for the most part the generated .mpy files should work the same as
  their bytecode version.

- The .mpy file format is changed to 1) specify in the header if the file
  contains native code and if so the architecture (eg x86, ARMV7M, Xtensa);
  2) for each function block the kind of code is specified (bytecode,
  native, viper, asm).

- When native code is loaded from a .mpy file the native code must be
  modified (in place) to link qstr values in, just like bytecode (see
  py/persistentcode.c:arch_link_qstr() function).

In addition, this now defines a public, native ABI for dynamically loadable
native code generated by other languages, like C.