Size 64 was incorrect and will lead to stack corruption. Size 88 was
verified empirically. Also, allow to skip defining it if MD5_CTX
preprocessor macro is already defined (to avoid header conflict).
ESP8266 SDK2.0 fixes (at least, I can't reproduce it) an infamous bug
with crash during scan. 36K seams to be a safe value based on a download
test (test_dl.py), over 1GB was downloaded. More testing is needed, but
let's have other people participate by committing it now.
There is no automatic reconnect after wlan.active(False);
wlan.active(True). This commit provide the possibility to run
wlan.connect() without parameter, to reconnect to the previously
connected AP.
resolve#2493
It's mandatory function which should be present in every port. Even if
it's not, in the stdlib intro we waarn users that a particular port can
lack anything of described in the docs.
Now the function properly uses ring arithmetic to return signed value
in range (inclusive):
[-MICROPY_PY_UTIME_TICKS_PERIOD/2, MICROPY_PY_UTIME_TICKS_PERIOD/2-1].
That means that function can properly process 2 time values away from
each other within MICROPY_PY_UTIME_TICKS_PERIOD/2 ticks, but away in
both directions. For example, if tick value 'a' predates tick value 'b',
ticks_diff(a, b) will return negative value, and positive value otherwise.
But at positive value of MICROPY_PY_UTIME_TICKS_PERIOD/2-1, the result
of the function will wrap around to negative -MICROPY_PY_UTIME_TICKS_PERIOD/2,
in other words, if a follows b in more than MICROPY_PY_UTIME_TICKS_PERIOD/2 - 1
ticks, the function will "consider" a to actually predate b.
It's implemented in terms of usleep(), and POSIX doesn't guarantee that
usleep() can sleep for more than a second. This restriction unlikely
applies to any real-world system, but...
The tick timer needed to be reworked because the ASF delay functions also
use the SysTick timer. Now, it uses TC5 and calls out to the autoreset
logic every tick. Fixes#43.
Added neopixel status colors and corrected the latch time from ms to us.
Fixes#42.
Based on the earlier discussed RFC. Practice showed that the most natural
order for arguments corresponds to mathematical subtraction:
ticks_diff(x, y) <=> x - y
Also, practice showed that in real life, it's hard to order events by time
of occurance a priori, events tend to miss deadlines, etc. and the expected
order breaks. And then there's a need to detect such cases. And ticks_diff
can be used exactly for this purpose, if it returns a signed, instead of
unsigned, value. E.g. if x is scheduled time for event, and y is the current
time, then if ticks_diff(x, y) < 0 then event has missed a deadline (and e.g.
needs to executed ASAP or skipped). Returning in this case a large unsigned
number (like ticks_diff behaved previously) doesn't make sense, and such
"large unsigned number" can't be reliably detected per our definition of
ticks_* function (we don't expose to user level maximum value, it can be
anything, relatively small or relatively large).
