Skip to content

Commit 7c21960

Browse files
committed
WIP: after merge; before testing
2 parents 4962468 + 25ae98f commit 7c21960

File tree

740 files changed

+36176
-13938
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

740 files changed

+36176
-13938
lines changed

.gitattributes

Lines changed: 0 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -17,8 +17,6 @@
1717
tests/basics/string_cr_conversion.py -text
1818
tests/basics/string_crlf_conversion.py -text
1919
ports/stm32/pybcdc.inf_template -text
20-
ports/stm32/usbd_* -text
21-
ports/stm32/usbdev/** -text
2220
ports/stm32/usbhost/** -text
2321
ports/cc3200/hal/aes.c -text
2422
ports/cc3200/hal/aes.h -text

.gitmodules

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@
77
url = https://github.com/atgreen/libffi
88
[submodule "lib/lwip"]
99
path = lib/lwip
10-
url = http://git.savannah.gnu.org/r/lwip.git
10+
url = https://git.savannah.gnu.org/r/lwip.git
1111
[submodule "lib/berkeley-db-1.xx"]
1212
path = lib/berkeley-db-1.xx
1313
url = https://github.com/pfalcon/berkeley-db-1.xx

.travis.yml

Lines changed: 15 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,6 +6,7 @@ compiler:
66
git:
77
depth: 1
88
env:
9+
- MAKEOPTS="-j4"
910
- TRAVIS_BOARD=feather_huzzah
1011
- TRAVIS_BOARD=arduino_zero
1112
- TRAVIS_BOARD=circuitplayground_express
@@ -57,12 +58,17 @@ before_script:
5758
- ([[ $TRAVIS_BOARD != "feather52832" && $TRAVIS_BOARD != "pca10056" ]] || sudo ports/nrf/drivers/bluetooth/download_ble_stack.sh)
5859
# For huzzah builds
5960
- if [[ $TRAVIS_BOARD = "feather_huzzah" ]]; then wget https://github.com/jepler/esp-open-sdk/releases/download/2018-06-10/xtensa-lx106-elf-standalone.tar.gz && tar xavf xtensa-lx106-elf-standalone.tar.gz; PATH=$(readlink -f xtensa-lx106-elf/bin):$PATH; fi
60-
# For coverage testing (upgrade is used to get latest urllib3 version)
6161
- ([[ -z "$TRAVIS_TEST" ]] || sudo pip install --upgrade cpp-coveralls)
6262
- ([[ $TRAVIS_TEST != "docs" ]] || sudo pip install Sphinx sphinx-rtd-theme recommonmark)
6363
- gcc --version
6464
- ([[ -z "$TRAVIS_BOARD" ]] || arm-none-eabi-gcc --version)
6565
- python3 --version
66+
67+
- sudo apt-get install realpath
68+
# For coverage testing (a specific urllib3 version is needed for requests and cpp-coveralls to work together)
69+
- sudo pip install -Iv urllib3==1.22
70+
- sudo pip install cpp-coveralls
71+
6672

6773
script:
6874
# Build mpy-cross first because other builds depend on it.
@@ -110,9 +116,17 @@ script:
110116
- echo -en 'travis_fold:end:build_docs\\r'
111117

112118

119+
# test when input script comes from stdin
120+
- cat tests/basics/0prelim.py | ports/unix/micropython_coverage | grep -q 'abc'
121+
113122
# run coveralls coverage analysis (try to, even if some builds/tests failed)
114123
#- (cd ports/unix && coveralls --root ../.. --build-root . --gcov $(which gcov) --gcov-options '\-o build-coverage/' --include py --include extmod)
115124

125+
# run tests on stackless build
126+
# - rm -rf ports/unix/build-coverage
127+
# - make ${MAKEOPTS} -C ports/unix coverage CFLAGS_EXTRA="-DMICROPY_STACKLESS=1 -DMICROPY_STACKLESS_STRICT=1"
128+
# - (cd tests && MICROPY_CPYTHON3=python3.4 MICROPY_MICROPYTHON=../ports/unix/micropython_coverage ./run-tests)
129+
116130
after_failure:
117131
- (cd tests && for exp in *.exp; do testbase=$(basename $exp .exp); echo -e "\nFAILURE $testbase"; diff -u $testbase.exp $testbase.out; done)
118132
- (grep "FAIL" ports/qemu-arm/build/console.out)

docs/library/_thread.rst

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
:mod:`_thread` -- multithreading support
2+
========================================
3+
4+
.. module:: _thread
5+
:synopsis: multithreading support
6+
7+
|see_cpython_module| :mod:`python:_thread`.
8+
9+
This module implements multithreading support.
10+
11+
This module is highly experimental and its API is not yet fully settled
12+
and not yet described in this documentation.

docs/library/array.rst

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -16,14 +16,14 @@ Classes
1616
.. class:: array.array(typecode, [iterable])
1717

1818
Create array with elements of given type. Initial contents of the
19-
array are given by an `iterable`. If it is not provided, an empty
19+
array are given by *iterable*. If it is not provided, an empty
2020
array is created.
2121

2222
.. method:: append(val)
2323

24-
Append new element to the end of array, growing it.
24+
Append new element *val* to the end of array, growing it.
2525

2626
.. method:: extend(iterable)
2727

28-
Append new elements as contained in an iterable to the end of
28+
Append new elements as contained in *iterable* to the end of
2929
array, growing it.

docs/library/btree.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@
77
:synopsis: simple BTree database
88

99
The ``btree`` module implements a simple key-value database using external
10-
storage (disk files, or in general case, a random-access stream). Keys are
10+
storage (disk files, or in general case, a random-access `stream`). Keys are
1111
stored sorted in the database, and besides efficient retrieval by a key
1212
value, a database also supports efficient ordered range scans (retrieval
1313
of values with the keys in a given range). On the application interface

docs/library/framebuf.rst

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -150,6 +150,14 @@ Constants
150150

151151
Red Green Blue (16-bit, 5+6+5) color format
152152

153+
.. data:: framebuf.GS2_HMSB
154+
155+
Grayscale (2-bit) color format
156+
153157
.. data:: framebuf.GS4_HMSB
154158

155159
Grayscale (4-bit) color format
160+
161+
.. data:: framebuf.GS8
162+
163+
Grayscale (8-bit) color format

docs/library/micropython.rst

Lines changed: 22 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -35,6 +35,18 @@ Functions
3535
compilation of scripts, and returns ``None``. Otherwise it returns the current
3636
optimisation level.
3737

38+
The optimisation level controls the following compilation features:
39+
40+
- Assertions: at level 0 assertion statements are enabled and compiled into the
41+
bytecode; at levels 1 and higher assertions are not compiled.
42+
- Built-in ``__debug__`` variable: at level 0 this variable expands to ``True``;
43+
at levels 1 and higher it expands to ``False``.
44+
- Source-code line numbers: at levels 0, 1 and 2 source-code line number are
45+
stored along with the bytecode so that exceptions can report the line number
46+
they occurred at; at levels 3 and higher line numbers are not stored.
47+
48+
The default optimisation level is usually level 0.
49+
3850
.. function:: alloc_emergency_exception_buf(size)
3951

4052
Allocate *size* bytes of RAM for the emergency exception buffer (a good
@@ -114,5 +126,14 @@ Functions
114126
the heap may be locked) and scheduling a function to call later will lift
115127
those restrictions.
116128

117-
There is a finite stack to hold the scheduled functions and `schedule`
129+
Note: If `schedule()` is called from a preempting IRQ, when memory
130+
allocation is not allowed and the callback to be passed to `schedule()` is
131+
a bound method, passing this directly will fail. This is because creating a
132+
reference to a bound method causes memory allocation. A solution is to
133+
create a reference to the method in the class constructor and to pass that
134+
reference to `schedule()`. This is discussed in detail here
135+
:ref:`reference documentation <isr_rules>` under "Creation of Python
136+
objects".
137+
138+
There is a finite stack to hold the scheduled functions and `schedule()`
118139
will raise a `RuntimeError` if the stack is full.

docs/library/sys.rst

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -105,15 +105,15 @@ Constants
105105

106106
.. data:: stderr
107107

108-
Standard error stream.
108+
Standard error `stream`.
109109

110110
.. data:: stdin
111111

112-
Standard input stream.
112+
Standard input `stream`.
113113

114114
.. data:: stdout
115115

116-
Standard output stream.
116+
Standard output `stream`.
117117

118118
.. data:: version
119119

docs/library/uctypes.rst

Lines changed: 18 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@ This module implements "foreign data interface" for MicroPython. The idea
1010
behind it is similar to CPython's ``ctypes`` modules, but the actual API is
1111
different, streamlined and optimized for small size. The basic idea of the
1212
module is to define data structure layout with about the same power as the
13-
C language allows, and the access it using familiar dot-syntax to reference
13+
C language allows, and then access it using familiar dot-syntax to reference
1414
sub-fields.
1515

1616
.. seealso::
@@ -31,55 +31,55 @@ Following are encoding examples for various field types:
3131

3232
* Scalar types::
3333

34-
"field_name": uctypes.UINT32 | 0
34+
"field_name": offset | uctypes.UINT32
3535

3636
in other words, value is scalar type identifier ORed with field offset
3737
(in bytes) from the start of the structure.
3838

3939
* Recursive structures::
4040

41-
"sub": (2, {
42-
"b0": uctypes.UINT8 | 0,
43-
"b1": uctypes.UINT8 | 1,
41+
"sub": (offset, {
42+
"b0": 0 | uctypes.UINT8,
43+
"b1": 1 | uctypes.UINT8,
4444
})
4545

4646
i.e. value is a 2-tuple, first element of which is offset, and second is
4747
a structure descriptor dictionary (note: offsets in recursive descriptors
48-
are relative to a structure it defines).
48+
are relative to the structure it defines).
4949

5050
* Arrays of primitive types::
5151

52-
"arr": (uctypes.ARRAY | 0, uctypes.UINT8 | 2),
52+
"arr": (offset | uctypes.ARRAY, size | uctypes.UINT8),
5353

5454
i.e. value is a 2-tuple, first element of which is ARRAY flag ORed
5555
with offset, and second is scalar element type ORed number of elements
5656
in array.
5757

5858
* Arrays of aggregate types::
5959

60-
"arr2": (uctypes.ARRAY | 0, 2, {"b": uctypes.UINT8 | 0}),
60+
"arr2": (offset | uctypes.ARRAY, size, {"b": 0 | uctypes.UINT8}),
6161

6262
i.e. value is a 3-tuple, first element of which is ARRAY flag ORed
6363
with offset, second is a number of elements in array, and third is
6464
descriptor of element type.
6565

6666
* Pointer to a primitive type::
6767

68-
"ptr": (uctypes.PTR | 0, uctypes.UINT8),
68+
"ptr": (offset | uctypes.PTR, uctypes.UINT8),
6969

7070
i.e. value is a 2-tuple, first element of which is PTR flag ORed
7171
with offset, and second is scalar element type.
7272

7373
* Pointer to an aggregate type::
7474

75-
"ptr2": (uctypes.PTR | 0, {"b": uctypes.UINT8 | 0}),
75+
"ptr2": (offset | uctypes.PTR, {"b": 0 | uctypes.UINT8}),
7676

7777
i.e. value is a 2-tuple, first element of which is PTR flag ORed
7878
with offset, second is descriptor of type pointed to.
7979

8080
* Bitfields::
8181

82-
"bitf0": uctypes.BFUINT16 | 0 | 0 << uctypes.BF_POS | 8 << uctypes.BF_LEN,
82+
"bitf0": offset | uctypes.BFUINT16 | lsbit << uctypes.BF_POS | bitsize << uctypes.BF_LEN,
8383

8484
i.e. value is type of scalar value containing given bitfield (typenames are
8585
similar to scalar types, but prefixes with "BF"), ORed with offset for
@@ -88,20 +88,21 @@ Following are encoding examples for various field types:
8888
BF_POS and BF_LEN positions, respectively. Bitfield position is counted
8989
from the least significant bit, and is the number of right-most bit of a
9090
field (in other words, it's a number of bits a scalar needs to be shifted
91-
right to extra the bitfield).
91+
right to extract the bitfield).
9292

93-
In the example above, first UINT16 value will be extracted at offset 0
93+
In the example above, first a UINT16 value will be extracted at offset 0
9494
(this detail may be important when accessing hardware registers, where
9595
particular access size and alignment are required), and then bitfield
96-
whose rightmost bit is least-significant bit of this UINT16, and length
97-
is 8 bits, will be extracted - effectively, this will access
98-
least-significant byte of UINT16.
96+
whose rightmost bit is *lsbit* bit of this UINT16, and length
97+
is *bitsize* bits, will be extracted. For example, if *lsbit* is 0 and
98+
*bitsize* is 8, then effectively it will access least-significant byte
99+
of UINT16.
99100

100101
Note that bitfield operations are independent of target byte endianness,
101102
in particular, example above will access least-significant byte of UINT16
102103
in both little- and big-endian structures. But it depends on the least
103104
significant bit being numbered 0. Some targets may use different
104-
numbering in their native ABI, but ``uctypes`` always uses normalized
105+
numbering in their native ABI, but ``uctypes`` always uses the normalized
105106
numbering described above.
106107

107108
Module contents

0 commit comments

Comments
 (0)