GitLab

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.

This happens with some compilers on some architectures, which don't define
size_t as unsigned int. MicroPython's printf() dooesn't support obscure
format specifiers for size_t, so the obvious choice is to explicitly cast
to unsigned, to match %u used in printf().

This patch removes a compilation warning in pyexec.
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@linaro.org>

As part of file naming clean up (moduos_dupterm doesn't implement a
full module, so should skip "mod" prefix, similar to other files in
extmod/).

Clarify the class implements master side of the protocol, also put adhoc
WiPy paramter after the generic, described in the current Hardware API
version.

x86 has bloated alignements, etc. Use ARM binary to catch any code size
increases promptly.

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.