The NeoPixel class now handles 4 bytes-per-pixel LEDs (extra byte is
intensity) and arbitrary byte ordering. APA102 class is now derived from
NeoPixel to reduce code size and support fill() operation.
To build, "make 512k".
Disabled are FatFs support (no space for filesystem), Python functionality
related to files, btree module, and recently enabled features. With all
this, there's only one free FlashROM page.
As we're looking towards adding OTA support, calculation of a FlashROM
area which can be used for filesystem (etc.) may become complex, so
introduce C function for that. So far it just hardcodes current value,
0x90000. In the future the function may be extended (and renamed) to
return the size of area too.
This provides time and sleep together with the usual ticks_us/_ms/_diff
and sleep_us/ms family.
We also provide access to Zephyr's high precision timer as ticks_cpu().
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Builtin functions with a fixed number of arguments (0, 1, 2 or 3) are
quite common. Before this patch the wrapper for such a function cost
3 machine words. After this patch it only takes 2, which can reduce the
code size by quite a bit (and pays off even more, the more functions are
added). It also makes function dispatch slightly more efficient in CPU
usage, and furthermore reduces stack usage for these cases. On x86 and
Thumb archs the dispatch functions are now tail-call optimised by the
compiler.
The bare-arm port has its code size increase by 76 bytes, but stmhal drops
by 904 bytes. Stack usage by these builtin functions is decreased by 48
bytes on Thumb2 archs.
In order to have more fine-grained control over how builtin functions are
constructed, the MP_DECLARE_CONST_FUN_OBJ macros are made more specific,
with suffix of _0, _1, _2, _3, _VAR, _VAR_BETEEN or _KW. These names now
match the MP_DEFINE_CONST_FUN_OBJ macros.
Running Python code on a hard interrupt is incompatible with having a GIL,
because most of the time the GIL will be held by the user thread when the
interrupt arrives. Hard interrupts mean that we should process them right
away and hence can't wait until the GIL is released.
The problem with the current code is that a hard interrupt will try to
exit/enter the GIL while it is still held by the user thread, hence leading
to a deadlock.
This patch works around such a problem by just making GIL exit/enter a
no-op when in an interrupt context, or when interrupts are disabled.
See issue #2406.
SDK 2.0.0 goes into boot loop if a firmware is programmed over erased flash,
causing problems with user experience. This change implements behavior
similar to older SDKs': if clean flash is detected, default system
parameters are used.
