adafruit · tannewt · Jul 30, 2018 · May 2, 2018 · May 2, 2018 · May 2, 2018
diff --git a/.gitattributes b/.gitattributes
@@ -18,8 +18,6 @@
 tests/basics/string_cr_conversion.py -text
 tests/basics/string_crlf_conversion.py -text
 ports/stm32/pybcdc.inf_template -text
-ports/stm32/usbd_* -text
-ports/stm32/usbdev/** -text
 ports/stm32/usbhost/** -text
 ports/cc3200/hal/aes.c -text
 ports/cc3200/hal/aes.h -text

diff --git a/.gitmodules b/.gitmodules
@@ -7,7 +7,7 @@
 	url = https://github.com/atgreen/libffi
 [submodule "lib/lwip"]
 	path = lib/lwip
-	url = http://git.savannah.gnu.org/r/lwip.git
+	url = https://git.savannah.gnu.org/r/lwip.git
 [submodule "lib/berkeley-db-1.xx"]
 	path = lib/berkeley-db-1.xx
 	url = https://github.com/pfalcon/berkeley-db-1.xx

diff --git a/.travis.yml b/.travis.yml
@@ -26,7 +26,6 @@ env:
   - TRAVIS_BOARD=gemma_m0
   - TRAVIS_BOARD=feather52832
   - TRAVIS_BOARD=pca10056
-  - TRAVIS_TEST=qemu
   - TRAVIS_TEST=unix
   - TRAVIS_TEST=docs
 
@@ -49,9 +48,7 @@ notifications:
 before_script:
   - sudo dpkg --add-architecture i386
 
-  - ([[ -z "$TRAVIS_TEST" ]] || sudo apt-get install -y qemu-system)
   - ([[ -z "$TRAVIS_BOARD" ]] || (wget https://s3.amazonaws.com/adafruit-circuit-python/gcc-arm-embedded_7-2018q2-1~trusty1_amd64.deb && sudo dpkg -i gcc-arm-embedded*_amd64.deb))
-  - ([[ $TRAVIS_TEST != "qemu" ]] || (wget https://s3.amazonaws.com/adafruit-circuit-python/gcc-arm-embedded_7-2018q2-1~trusty1_amd64.deb && sudo dpkg -i gcc-arm-embedded*_amd64.deb))
 
   # For nrf builds
   - ([[ $TRAVIS_BOARD != "feather52832" && $TRAVIS_BOARD != "pca10056" ]] || sudo ports/nrf/drivers/bluetooth/download_ble_stack.sh)
@@ -80,10 +77,6 @@ script:
   - ([[ $TRAVIS_TEST != "unix" ]] || make -C ports/unix coverage -j2)
   - echo -en 'travis_fold:end:unix\\r'
 
-  - echo 'Building qemu' && echo -en 'travis_fold:start:qemu\\r'
-  - ([[ $TRAVIS_TEST != "qemu" ]] || make -C ports/qemu-arm test -j2)
-  - echo -en 'travis_fold:end:qemu\\r'
-
   # run tests without coverage info
   #- (cd tests && MICROPY_CPYTHON3=python3.4 ./run-tests -j1)
   #- (cd tests && MICROPY_CPYTHON3=python3.4 ./run-tests -j1 --emit native)
@@ -115,4 +108,3 @@ script:
 
 after_failure:
   - (cd tests && for exp in *.exp; do testbase=$(basename $exp .exp); echo -e "\nFAILURE $testbase"; diff -u $testbase.exp $testbase.out; done)
-  - (grep "FAIL" ports/qemu-arm/build/console.out)
diff --git a/conf.py b/conf.py
@@ -108,6 +108,7 @@
                     "ports/cc3200",
                     "ports/cc3200/FreeRTOS",
                     "ports/cc3200/hal",
+                    "ports/esp32",
                     "ports/esp8266/boards",
                     "ports/esp8266/common-hal",
                     "ports/esp8266/modules",

diff --git a/docs/library/array.rst b/docs/library/array.rst
@@ -21,9 +21,9 @@ Classes
 
     .. method:: append(val)
 
-        Append new element to the end of array, growing it.
+        Append new element ``val`` to the end of array, growing it.
 
     .. method:: extend(iterable)
 
-        Append new elements as contained in an iterable to the end of
+        Append new elements as contained in `iterable` to the end of
         array, growing it.
diff --git a/docs/library/btree.rst b/docs/library/btree.rst
@@ -7,7 +7,7 @@
    :synopsis: simple BTree database
 
 The ``btree`` module implements a simple key-value database using external
-storage (disk files, or in general case, a random-access stream). Keys are
+storage (disk files, or in general case, a random-access ``stream``). Keys are
 stored sorted in the database, and besides efficient retrieval by a key
 value, a database also supports efficient ordered range scans (retrieval
 of values with the keys in a given range). On the application interface

diff --git a/docs/library/framebuf.rst b/docs/library/framebuf.rst
@@ -150,6 +150,14 @@ Constants
 
     Red Green Blue (16-bit, 5+6+5) color format
 
+.. data:: framebuf.GS2_HMSB
+
+    Grayscale (2-bit) color format
+
 .. data:: framebuf.GS4_HMSB
 
     Grayscale (4-bit) color format
+
+.. data:: framebuf.GS8
+
+    Grayscale (8-bit) color format
diff --git a/docs/library/micropython.rst b/docs/library/micropython.rst
@@ -35,16 +35,17 @@ Functions
    compilation of scripts, and returns ``None``.  Otherwise it returns the current
    optimisation level.
 
-.. function:: alloc_emergency_exception_buf(size)
+   The optimisation level controls the following compilation features:
 
-   Allocate *size* bytes of RAM for the emergency exception buffer (a good
-   size is around 100 bytes).  The buffer is used to create exceptions in cases
-   when normal RAM allocation would fail (eg within an interrupt handler) and
-   therefore give useful traceback information in these situations.
+   - Assertions: at level 0 assertion statements are enabled and compiled into the
+     bytecode; at levels 1 and higher assertions are not compiled.
+   - Built-in ``__debug__`` variable: at level 0 this variable expands to ``True``;
+     at levels 1 and higher it expands to ``False``.
+   - Source-code line numbers: at levels 0, 1 and 2 source-code line number are
+     stored along with the bytecode so that exceptions can report the line number
+     they occurred at; at levels 3 and higher line numbers are not stored.
 
-   A good way to use this function is to put it at the start of your main script
-   (eg ``boot.py`` or ``main.py``) and then the emergency exception buffer will be active
-   for all the code following it.
+   The default optimisation level is usually level 0.
 
 .. function:: mem_info([verbose])
 
@@ -90,29 +91,3 @@ Functions
    This function can be used to prevent the capturing of Ctrl-C on the
    incoming stream of characters that is usually used for the REPL, in case
    that stream is used for other purposes.
-
-.. function:: schedule(func, arg)
-
-   Schedule the function *func* to be executed "very soon".  The function
   is passed the value *arg* as its single argument.  "Very soon" means that
-   the MicroPython runtime will do its best to execute the function at the
-   earliest possible time, given that it is also trying to be efficient, and
-   that the following conditions hold:
-
-   - A scheduled function will never preempt another scheduled function.
-   - Scheduled functions are always executed "between opcodes" which means
-     that all fundamental Python operations (such as appending to a list)
-     are guaranteed to be atomic.
-   - A given port may define "critical regions" within which scheduled
-     functions will never be executed.  Functions may be scheduled within
-     a critical region but they will not be executed until that region
-     is exited.  An example of a critical region is a preempting interrupt
-     handler (an IRQ).
-
-   A use for this function is to schedule a callback from a preempting IRQ.
-   Such an IRQ puts restrictions on the code that runs in the IRQ (for example
-   the heap may be locked) and scheduling a function to call later will lift
-   those restrictions.
-
-   There is a finite stack to hold the scheduled functions and `schedule`
-   will raise a `RuntimeError` if the stack is full.
diff --git a/docs/library/sys.rst b/docs/library/sys.rst
@@ -105,15 +105,15 @@ Constants
 
 .. data:: stderr
 
-   Standard error stream.
+   Standard error ``stream``.
 
 .. data:: stdin
 
-   Standard input stream.
+   Standard input ``stream``.
 
 .. data:: stdout
 
-   Standard output stream.
+   Standard output ``stream``.
 
 .. data:: version
 

diff --git a/docs/library/uctypes.rst b/docs/library/uctypes.rst
@@ -10,7 +10,7 @@ This module implements "foreign data interface" for MicroPython. The idea
 behind it is similar to CPython's ``ctypes`` modules, but the actual API is
 different, streamlined and optimized for small size. The basic idea of the
 module is to define data structure layout with about the same power as the
-C language allows, and the access it using familiar dot-syntax to reference
+C language allows, and then access it using familiar dot-syntax to reference
 sub-fields.
 
 .. seealso::
@@ -31,55 +31,55 @@ Following are encoding examples for various field types:
 
 * Scalar types::
 
-    "field_name": uctypes.UINT32 | 0
+    "field_name": offset | uctypes.UINT32
 
   in other words, value is scalar type identifier ORed with field offset
   (in bytes) from the start of the structure.
 
 * Recursive structures::
 
-    "sub": (2, {
-        "b0": uctypes.UINT8 | 0,
-        "b1": uctypes.UINT8 | 1,
+    "sub": (offset, {
+        "b0": 0 | uctypes.UINT8,
+        "b1": 1 | uctypes.UINT8,
     })
 
   i.e. value is a 2-tuple, first element of which is offset, and second is
   a structure descriptor dictionary (note: offsets in recursive descriptors
-  are relative to a structure it defines).
+  are relative to the structure it defines).
 
 * Arrays of primitive types::
 
-      "arr": (uctypes.ARRAY | 0, uctypes.UINT8 | 2),
+      "arr": (offset | uctypes.ARRAY, size | uctypes.UINT8),
 
   i.e. value is a 2-tuple, first element of which is ARRAY flag ORed
   with offset, and second is scalar element type ORed number of elements
   in array.
 
 * Arrays of aggregate types::
 
-    "arr2": (uctypes.ARRAY | 0, 2, {"b": uctypes.UINT8 | 0}),
+    "arr2": (offset | uctypes.ARRAY, size, {"b": 0 | uctypes.UINT8}),
 
   i.e. value is a 3-tuple, first element of which is ARRAY flag ORed
   with offset, second is a number of elements in array, and third is
   descriptor of element type.
 
 * Pointer to a primitive type::
 
-    "ptr": (uctypes.PTR | 0, uctypes.UINT8),
+    "ptr": (offset | uctypes.PTR, uctypes.UINT8),
 
   i.e. value is a 2-tuple, first element of which is PTR flag ORed
   with offset, and second is scalar element type.
 
 * Pointer to an aggregate type::
 
-    "ptr2": (uctypes.PTR | 0, {"b": uctypes.UINT8 | 0}),
+    "ptr2": (offset | uctypes.PTR, {"b": 0 | uctypes.UINT8}),
 
   i.e. value is a 2-tuple, first element of which is PTR flag ORed
   with offset, second is descriptor of type pointed to.
 
 * Bitfields::
 
-    "bitf0": uctypes.BFUINT16 | 0 | 0 << uctypes.BF_POS | 8 << uctypes.BF_LEN,
+    "bitf0": offset | uctypes.BFUINT16 | lsbit << uctypes.BF_POS | bitsize << uctypes.BF_LEN,
 
   i.e. value is type of scalar value containing given bitfield (typenames are
   similar to scalar types, but prefixes with "BF"), ORed with offset for
@@ -88,20 +88,21 @@ Following are encoding examples for various field types:
   BF_POS and BF_LEN positions, respectively. Bitfield position is counted
   from the least significant bit, and is the number of right-most bit of a
   field (in other words, it's a number of bits a scalar needs to be shifted
-  right to extra the bitfield).
+  right to extract the bitfield).
 
-  In the example above, first UINT16 value will be extracted at offset 0
+  In the example above, first a UINT16 value will be extracted at offset 0
   (this detail may be important when accessing hardware registers, where
   particular access size and alignment are required), and then bitfield
-  whose rightmost bit is least-significant bit of this UINT16, and length
-  is 8 bits, will be extracted - effectively, this will access
-  least-significant byte of UINT16.
+  whose rightmost bit is *lsbit* bit of this UINT16, and length
+  is *bitsize* bits, will be extracted. For example, if *lsbit* is 0 and
+  *bitsize* is 8, then effectively it will access least-significant byte
+  of UINT16.
 
   Note that bitfield operations are independent of target byte endianness,
   in particular, example above will access least-significant byte of UINT16
   in both little- and big-endian structures. But it depends on the least
   significant bit being numbered 0. Some targets may use different
-  numbering in their native ABI, but ``uctypes`` always uses normalized
+  numbering in their native ABI, but ``uctypes`` always uses the normalized
   numbering described above.
 
 Module contents

diff --git a/docs/library/uio.rst b/docs/library/uio.rst
@@ -8,7 +8,7 @@
 
 |see_cpython_module| :mod:`cpython:io`.
 
-This module contains additional types of stream (file-like) objects
+This module contains additional types of ``stream`` (file-like) objects
 and helper functions.
 
 Conceptual hierarchy

diff --git a/docs/library/ujson.rst b/docs/library/ujson.rst
@@ -14,11 +14,24 @@ data format.
 Functions
 ---------
 
+.. function:: dump(obj, stream)
+
+   Serialise ``obj`` to a JSON string, writing it to the given *stream*.
+
 .. function:: dumps(obj)
 
    Return ``obj`` represented as a JSON string.
 
+.. function:: load(stream)
+
+   Parse the given ``stream``, interpreting it as a JSON string and
+   deserialising the data to a Python object.  The resulting object is
+   returned.
+
+   Parsing continues until end-of-file is encountered.
+   A :exc:`ValueError` is raised if the data in ``stream`` is not correctly formed.
+
 .. function:: loads(str)
 
-   Parse the JSON ``str`` and return an object.  Raises ValueError if the
+   Parse the JSON *str* and return an object.  Raises :exc:`ValueError` if the
    string is not correctly formed.
diff --git a/docs/library/ure.rst b/docs/library/ure.rst
@@ -17,8 +17,9 @@ Supported operators are:
 ``'.'``
    Match any character.
 
-``'[]'``
-   Match set of characters. Individual characters and ranges are supported.
+``'[...]'``
+   Match set of characters. Individual characters and ranges are supported,
+   including negated sets (e.g. ``[^a-c]``).
 
 ``'^'``
 
@@ -38,18 +39,19 @@ Supported operators are:
 
 ``'|'``
 
-``'()'``
+``'(...)'``
    Grouping. Each group is capturing (a substring it captures can be accessed
    with `match.group()` method).
 
-Counted repetitions (``{m,n}``), more advanced assertions, named groups,
-etc. are not supported.
+**NOT SUPPORTED**: Counted repetitions (``{m,n}``), more advanced assertions
+(``\b``, ``\B``), named groups (``(?P<name>...)``), non-capturing groups
+(``(?:...)``), etc.
 
 
 Functions
 ---------
 
-.. function:: compile(regex_str)
+.. function:: compile(regex_str, [flags])
 
    Compile regular expression, return `regex <regex>` object.