| Age | Commit message (Collapse) | Author |
|---|
|
With MICROPY_ENABLE_GC set to false the alternate memory manager may not
clear all memory that is allocated, so it must be cleared in m_malloc0.
|
|
|
|
In both parse.c and qstr.c, an internal chunking allocator tidies up
by calling m_renew to shrink an allocated chunk to the size used, and
assumes that the chunk will not move. However, when MICROPY_ENABLE_GC
is false, m_renew calls the system realloc, which does not guarantee
this behaviour. Environments where realloc may return a different
pointer include:
(1) mbed-os with MBED_HEAP_STATS_ENABLED (which adds a wrapper around
malloc & friends; this is where I was hit by the bug);
(2) valgrind on linux (how I diagnosed it).
The fix is to call m_renew_maybe with allow_move=false.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Also, drop ::only directive.
|
|
|
|
|
|
|
|
|
|
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.
|
|
Using MICROPY_PY_UTIME_TICKS_PERIOD config var.
|
|
|
|
|
|
|
|
|
|
To fix coverage build.
|
|
mp_hal_ticks_ms, mp_hal_ticks_us taken from unix port, mp_hal_ticks_cpu
dummy.
|
|
|
|
Ported from unix port.
|
|
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...
|
|
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).
|
|
|
|
|
|
So, now it's possible to just do normal Python's "import time".
|
|
|
|
|
|
uart_irq_input_hook_set() was renamed to uart_console_in_debug_hook_install()
and accepts different params.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The integration with Zephyr is fairly clean but as MicroPython Hardware API
requires pin ID to be a single value, but Zephyr operates GPIO in terms of
ports and pins, not just pins, a "hierarchical" ID is required, using tuple
of (port, pin). Port is a string, effectively a device name of a GPIO port,
per Zephyr conventions these are "GPIO_0", "GPIO_1", etc.; pin is integer
number of pin with the port (supposed to be in range 0-31).
Example of pin initialization:
pin = Pin(("GPIO_1", 21), Pin.OUT)
(an LED on FRDM-K64F's Port B, Pin 21).
There is support for in/out pins and pull up/pull down but currently
there is no interrupt support.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@linaro.org>
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
|
|
This patch modifies the HW macro definition in order to let micropython
report correctly the BOARD and the SOC on which it is working on.
|
|
With other ports. Other ports declare it in mphalport.h, it can be
inline or macro.
|
