these are function prototypes not used in circuitpython. The
declarations began to conflict with ones in the upstream SDK
at some point, so delete them.
Recent vendor SDKs ship libs with code in .text section, which previously
was going into .irom0.text. Adjust the linker script to route these
sections back to iROM (follows upstream change).
Commit efbf08266b moved _estack in order to ensure 8-byte alignment
of the stack, but the address of _bootloader_dbl_tap must remain
right at the end of SRAM.
I verified by reading the source that the 4-byte-aligned address is
used for all samd21 / samd51 boards in
adafruit/circuitpython@efbf08266b. However, I only tested on
trinket_m0.
Closes: #739
.. this allows developers who want to work with both micropython and
circuitpython to enable appveyor on their fork, but not get errors
when pushing circuitpython changes.
In the appveyor configuration for your fork, simply enable the
checkbox "Skip branches without appveyor.yml".
While it is traditional to have buttons on pins that are pulled up, and
have the button connect them to the ground, some CircuitPython boards
(notably the CPX) have the button pins pulled low and the button
connects them to VCC.
This patch makes the gamepad only change the pin's pull if it wasn't
already set when passed to the constructor, and also makes it consider
a button pressed when its value is the opposite of its pull.
When requested via 'run-tests -j', more than one test will be run
at a time. On my system, (i5-3320m with 4 threads / 2 cores), this
reduces elapsed time by over 50% when testing pots/unix/micropython.
Elapsed time, seconds, best of 3 runs with each -j value:
before patchset: 18.1
-j1: 18.1
-j2: 11.3 (-37%)
-j4: 8.7 (-52%)
-j6: 8.4 (-54%)
In all cases the final output is identical:
651 tests performed (18932 individual testcases)
651 tests passed
23 tests skipped: buffered_writer...
though the individual pass/fail messages can be different/interleaved.
micropython: ../../py/objtype.c:1100: super_attr: Assertion `MP_OBJ_IS_TYPE(self->type, &mp_type_type)' failed.
e.g., when making calls like
super(1, 1).x
Fixes the following assertion failures when the arguments to type()
were not of valid types:
micropython: ../../py/objtype.c:984: mp_obj_new_type: Assertion `MP_OBJ_IS_TYPE(bases_tuple, &mp_type_tuple)' failed.
micropython: ../../py/objtype.c:994: mp_obj_new_type: Assertion `MP_OBJ_IS_TYPE(items[i], &mp_type_type)' failed.
e.g., when making calls like
type("", (), 3)
type("", 3, {})