winnermicro · e-tobi · Feb 24, 2020 · Jan 1, 2020 · Mar 7, 2020 · Mar 10, 2020
diff --git a/.gitattributes b/.gitattributes
@@ -7,6 +7,7 @@
 *.bat text eol=crlf
 
 # These are binary so should never be modified by git.
+*.a binary
 *.png binary
 *.jpg binary
 *.dxf binary

diff --git a/.gitignore b/.gitignore
@@ -20,9 +20,10 @@
 ######################
 *.swp
 
-# Build directory
+# Build directories
 ######################
 build/
+build-*/
 
 # Test failure outputs
 ######################

diff --git a/.gitmodules b/.gitmodules
@@ -18,3 +18,21 @@
 [submodule "lib/nrfx"]
 	path = lib/nrfx
 	url = https://github.com/NordicSemiconductor/nrfx.git
+[submodule "lib/mbedtls"]
+	path = lib/mbedtls
+	url = https://github.com/ARMmbed/mbedtls.git
+[submodule "lib/asf4"]
+	path = lib/asf4
+	url = https://github.com/adafruit/asf4
+[submodule "lib/tinyusb"]
+	path = lib/tinyusb
+	url = https://github.com/hathach/tinyusb
+[submodule "lib/mynewt-nimble"]
+	path = lib/mynewt-nimble
+	url = https://github.com/apache/mynewt-nimble.git
+[submodule "lib/btstack"]
+	path = lib/btstack
+	url = https://github.com/bluekitchen/btstack.git
+[submodule "lib/nxp_driver"]
+	path = lib/nxp_driver
+	url = https://github.com/hathach/nxp_driver.git
diff --git a/.travis.yml b/.travis.yml
diff --git a/ACKNOWLEDGEMENTS b/ACKNOWLEDGEMENTS
@@ -762,7 +762,6 @@ today.  The names appear in order of pledging.
  1642 Udine
  1643 Simon Critchley
  1644 Sven Haiges, Germany
- 1645 Yi Qing Sim
  1646 "silicium" ("silicium_one", if "silicium" is busy)
  1648 Andy O'Malia, @andyomalia
  1650 RedCamelApps.com

diff --git a/CODECONVENTIONS.md b/CODECONVENTIONS.md
@@ -11,17 +11,18 @@ It's also ok to drop file extensions.
 
 Besides prefix, first line of a commit message should describe a
 change clearly and to the point, and be a grammatical sentence with
-final full stop. First line should fit within 78 characters. Examples
+final full stop. First line should fit within 72 characters. Examples
 of good first line of commit messages:
 
     py/objstr: Add splitlines() method.
     py: Rename FOO to BAR.
     docs/machine: Fix typo in reset() description.
     ports: Switch to use lib/foo instead of duplicated code.
 
-After the first line, add an empty line and in following lines describe
-a change in a detail, if needed. Any change beyond 5 lines would likely
-require such detailed description.
+After the first line add an empty line and in the following lines describe
+the change in a detail, if needed, with lines fitting within 75 characters
+(with an exception for long items like URLs which cannot be broken). Any
+change beyond 5 lines would likely require such detailed description.
 
 To get good practical examples of good commits and their messages, browse
 the `git log` of the project.
@@ -47,14 +48,27 @@ address on it construes your sign-off of the following:
   a valid and active email address by which you can be contacted in the
   foreseeable future.
 
+Code auto-formatting
+====================
+
+Both C and Python code are auto-formatted using the `tools/codeformat.py`
+script.  This uses [uncrustify](https://github.com/uncrustify/uncrustify) to
+format C code and [black](https://github.com/psf/black) to format Python code.
+After making changes, and before committing, run this tool to reformat your
+changes to the correct style.  Without arguments this tool will reformat all
+source code (and may take some time to run).  Otherwise pass as arguments to
+the tool the files that changed and it will only reformat those.
+
 Python code conventions
 =======================
 
-Python code follows [PEP 8](http://legacy.python.org/dev/peps/pep-0008/).
+Python code follows [PEP 8](https://legacy.python.org/dev/peps/pep-0008/) and
+is auto-formatted using [black](https://github.com/psf/black) with a line-length
+of 99 characters.
 
 Naming conventions:
 - Module names are short and all lowercase; eg pyb, stm.
-- Class names are CamelCase, with abreviations all uppercase; eg I2C, not
+- Class names are CamelCase, with abbreviations all uppercase; eg I2C, not
   I2c.
 - Function and method names are all lowercase with words separated by
   a single underscore as necessary to improve readability; eg mem_read.
@@ -64,7 +78,12 @@ Naming conventions:
 C code conventions
 ==================
 
-When writing new C code, please adhere to the following conventions.
+C code is auto-formatted using [uncrustify](https://github.com/uncrustify/uncrustify)
+and the corresponding configuration file `tools/uncrustify.cfg`, with a few
+minor fix-ups applied by `tools/codeformat.py`.  When writing new C code please
+adhere to the existing style and use `tools/codeformat.py` to check any changes.
+The main conventions, and things not enforceable via the auto-formatter, are
+described below.
 
 White space:
 - Expand tabs to 4 spaces.
@@ -125,7 +144,7 @@ Braces, spaces, names and comments:
             foo(x + TO_ADD, some_value - 1);
         }
 
-        for (int my_counter = 0; my_counter < x; my_counter++) {
+        for (int my_counter = 0; my_counter < x; ++my_counter) {
         }
     }
 

diff --git a/CODEOFCONDUCT.md b/CODEOFCONDUCT.md
@@ -0,0 +1,53 @@
+MicroPython Code of Conduct
+===========================
+
+The MicroPython community is made up of members from around the globe with a
+diverse set of skills, personalities, and experiences.  It is through these
+differences that our community experiences great successes and continued growth.
+When you're working with members of the community, this Code of Conduct will
+help steer your interactions and keep MicroPython a positive, successful, and
+growing community.
+
+Members of the MicroPython community are open, considerate, and respectful.
+Behaviours that reinforce these values contribute to a positive environment, and
+include: acknowledging time and effort, being respectful of differing viewpoints
+and experiences, gracefully accepting constructive criticism, and using
+welcoming and inclusive language.
+
+Every member of our community has the right to have their identity respected.
+The MicroPython community is dedicated to providing a positive experience for
+everyone, regardless of age, gender identity and expression, sexual orientation,
+disability, physical appearance, body size, ethnicity, nationality, race, or
+religion (or lack thereof), education, or socio-economic status.
+
+Unacceptable behaviour includes: harassment, trolling, deliberate intimidation,
+violent threats or language directed against another person; insults, put downs,
+or jokes that are based upon stereotypes, that are exclusionary, or that hold
+others up for ridicule; unwelcome sexual attention or advances; sustained
+disruption of community discussions; publishing others' private information
+without explicit permission; and other conduct that is inappropriate for a
+professional audience including people of many different backgrounds.
+
+This code of conduct covers all online and offline presence related to the
+MicroPython project, including GitHub and the forum.  If a participant engages
+in behaviour that violates this code of conduct, the MicroPython team may take
+action as they deem appropriate, including warning the offender or expulsion
+from the community.  Community members asked to stop any inappropriate behaviour
+are expected to comply immediately.
+
+Thank you for helping make this a welcoming, friendly community for everyone.
+
+If you believe that someone is violating the code of conduct, or have any other
+concerns, please contact a member of the MicroPython team by emailing
+contact@micropython.org.
+
+License
+-------
+
+This Code of Conduct is licensed under the Creative Commons
+Attribution-ShareAlike 3.0 Unported License.
+
+Attributions
+------------
+
+Based on the Python code of conduct found at https://www.python.org/psf/conduct/
diff --git a/LICENSE b/LICENSE
@@ -1,6 +1,6 @@
 The MIT License (MIT)
 
-Copyright (c) 2013, 2014 Damien P. George
+Copyright (c) 2013-2019 Damien P. George
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

diff --git a/README.md b/README.md
@@ -1,4 +1,4 @@
-[![Build Status](https://travis-ci.org/micropython/micropython.png?branch=master)](https://travis-ci.org/micropython/micropython) [![Coverage Status](https://coveralls.io/repos/micropython/micropython/badge.png?branch=master)](https://coveralls.io/r/micropython/micropython?branch=master)
+[![Build Status](https://travis-ci.com/micropython/micropython.png?branch=master)](https://travis-ci.com/micropython/micropython) [![Coverage Status](https://coveralls.io/repos/micropython/micropython/badge.png?branch=master)](https://coveralls.io/r/micropython/micropython?branch=master)
 
 The MicroPython project
 =======================
@@ -64,6 +64,17 @@ You will also need bash, gcc, and Python 3.3+ available as the command `python3`
 (if your system only has Python 2.7 then invoke make with the additional option
 `PYTHON=python2`).
 
+The MicroPython cross-compiler, mpy-cross
+-----------------------------------------
+
+Most ports require the MicroPython cross-compiler to be built first.  This
+program, called mpy-cross, is used to pre-compile Python scripts to .mpy
+files which can then be included (frozen) into the firmware/executable for
+a port.  To build mpy-cross use:
+
+    $ cd mpy-cross
+    $ make
+
 The Unix version
 ----------------
 
@@ -75,8 +86,8 @@ Alternatively, fallback implementation based on setjmp/longjmp can be used.
 
 To build (see section below for required dependencies):
 
-    $ git submodule update --init
     $ cd ports/unix
+    $ make submodules
     $ make
 
 Then to give it a try:
@@ -88,7 +99,7 @@ Use `CTRL-D` (i.e. EOF) to exit the shell.
 Learn about command-line options (in particular, how to increase heap size
 which may be needed for larger applications):
 
-    $ ./micropython --help
+    $ ./micropython -h
 
 Run complete testsuite:
 
@@ -116,13 +127,14 @@ Debian/Ubuntu/Mint derivative Linux distros, install `build-essential`
 Other dependencies can be built together with MicroPython. This may
 be required to enable extra features or capabilities, and in recent
 versions of MicroPython, these may be enabled by default. To build
-these additional dependencies, first fetch git submodules for them:
+these additional dependencies, in the port directory you're
+interested in (e.g. `ports/unix/`) first execute:
 
-    $ git submodule update --init
+    $ make submodules
 
-Use the same command to get the latest versions of dependencies, as
-they are updated from time to time. After that, in the port directory
-(e.g. `ports/unix/`), execute:
+This will fetch all the relevant git submodules (sub repositories) that
+the port needs.  Use the same command to get the latest versions of
+submodules as they are updated from time to time. After that execute:
 
     $ make deplibs
 
@@ -132,11 +144,11 @@ options (like cross-compiling), the same set of options should be passed
 to `make deplibs`. To actually enable/disable use of dependencies, edit
 `ports/unix/mpconfigport.mk` file, which has inline descriptions of the options.
 For example, to build SSL module (required for `upip` tool described above,
-and so enabled by dfeault), `MICROPY_PY_USSL` should be set to 1.
+and so enabled by default), `MICROPY_PY_USSL` should be set to 1.
 
 For some ports, building required dependences is transparent, and happens
-automatically. They still need to be fetched with the git submodule command
-above.
+automatically.  But they still need to be fetched with the `make submodules`
+command.
 
 The STM32 version
 -----------------
@@ -148,8 +160,8 @@ https://launchpad.net/gcc-arm-embedded
 
 To build:
 
-    $ git submodule update --init
     $ cd ports/stm32
+    $ make submodules
     $ make
 
 You then need to get your board into DFU mode.  On the pyboard, connect the

diff --git a/docs/README.md b/docs/README.md
@@ -25,6 +25,21 @@ In `micropython/docs`, build the docs:
 
 You'll find the index page at `micropython/docs/build/html/index.html`.
 
+Having readthedocs.org build the documentation
+----------------------------------------------
+
+If you would like to have docs for forks/branches hosted on GitHub, GitLab or
+BitBucket an alternative to building the docs locally is to sign up for a free
+https://readthedocs.org account. The rough steps to follow are:
+1. sign-up for an account, unless you already have one
+2. in your account settings: add GitHub as a connected service (assuming
+you have forked this repo on github)
+3. in your account projects: import your forked/cloned micropython repository
+into readthedocs
+4. in the project's versions: add the branches you are developing on or
+for which you'd like readthedocs to auto-generate docs whenever you
+push a change
+
 PDF manual generation
 ---------------------
 

diff --git a/docs/conf.py b/docs/conf.py
@@ -74,7 +74,7 @@
 #
 # We don't follow "The short X.Y version" vs "The full version, including alpha/beta/rc tags"
 # breakdown, so use the same version identifier for both to avoid confusion.
-version = release = '1.10'
+version = release = '1.12'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
@@ -159,7 +159,7 @@
 # The name of an image file (within the static path) to use as favicon of the
 # docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
 # pixels large.
-html_favicon = 'favicon.ico'
+html_favicon = 'static/favicon.ico'
 
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,

diff --git a/docs/develop/cmodules.rst b/docs/develop/cmodules.rst
@@ -1,3 +1,5 @@
+.. _cmodules:
+
 MicroPython external C modules
 ==============================
 
@@ -17,6 +19,10 @@ more sense to keep this external to the main MicroPython repository.
 This chapter describes how to compile such external modules into the
 MicroPython executable or firmware image.
 
+An alternative approach is to use :ref:`natmod` which allows writing custom C
+code that is placed in a .mpy file, which can be imported dynamically in to
+a running MicroPython system without the need to recompile the main firmware.
+
 
 Structure of an external C module
 ---------------------------------
@@ -48,7 +54,7 @@ A MicroPython user C module is a directory with the following files:
   See below for full usage example.
 
 
-Basic Example
+Basic example
 -------------
 
 This simple module named ``example`` provides a single function
@@ -71,8 +77,6 @@ Directory::
     #include "py/runtime.h"
     #include "py/builtin.h"
 
-    #define MODULE_EXAMPLE_ENABLED (1)
-
     // This is the function which will be called from Python as example.add_ints(a, b).
     STATIC mp_obj_t example_add_ints(mp_obj_t a_obj, mp_obj_t b_obj) {
         // Extract the ints from the micropython input objects
@@ -119,6 +123,19 @@ Directory::
     # This is not actually needed in this example.
     CFLAGS_USERMOD += -I$(EXAMPLE_MOD_DIR)
 
+Finally you will need to define ``MODULE_EXAMPLE_ENABLED`` to 1. This
+can be done by adding ``CFLAGS_EXTRA=-DMODULE_EXAMPLE_ENABLED=1`` to
+the ``make`` command, or editing ``mpconfigport.h`` or
+``mpconfigboard.h`` to add
+
+.. code-block:: c
+
+    #define MODULE_EXAMPLE_ENABLED (1)
+
+Note that the exact method depends on the port as they have different
+structures. If not done correctly it will compile but importing will
+fail to find the module.
+
 
 Compiling the cmodule into MicroPython
 --------------------------------------
@@ -146,7 +163,7 @@ Building for stm32 port:
 .. code-block:: bash
 
     cd my_project/micropython/ports/stm32
-    make USER_C_MODULES=../../../modules all
+    make USER_C_MODULES=../../../modules CFLAGS_EXTRA=-DMODULE_EXAMPLE_ENABLED=1 all
 
 
 Module usage in MicroPython

diff --git a/docs/develop/index.rst b/docs/develop/index.rst
@@ -10,3 +10,5 @@ See the `getting started guide
    :maxdepth: 1
 
    cmodules.rst
+   qstr.rst
+   natmod.rst