GitLab

Try to put sections in more logical order, and information about cc3200tool
to be the default flashing method.

cc3200tool, https://github.com/ALLTERCO/cc3200tool is a (mostly, some
binary blobs present) open-source, Linux-friendly tool to flash a cc3200
devices. It's an alternative to fully proprietary, Windows-only Uniflash
from TI.

The provided make targets are for erasing flash, flashing the uPy
bootloader and firmware, and flashing vendor's WiFi firmware "servicepacks"
(the latter needs to be downloaded from vendor side, a link is present
inside Makefile).

There should be target to deploy uPy over wired (UART) connection, and
wired and OTA targets should be named differently.

To allow access and testing without complex access methods like WiFi.
Enabled for both WiPy and TI LaunchXL.

Sys-tick resolution is 1ms and a value of 2 will give a delay between 1ms
and 2ms (whereas a value of 1 gives a delay between 0ms and 1ms, which is
too short).

The HAL_UART_Transmit function has changed in the latest HAL version such
that the Timeout is a timeout for the entire function, rather than a
timeout between characters as it was before.  The HAL function also does
not allow one to reliably tell how many characters were sent before the
timeout (if a timeout occurred).

This patch provides a custom function to do UART transmission, completely
replacing the HAL version, to fix the above-mentioned issues.

One never needs to format integers with a base larger than 16 (but code
can be easily extended beyond this value if needed in the future).

This function should be able to parse integers with any value for the
base, because it is called by int('xxx', base).

UART REPL support was lost in os.dupterm() refactorings, etc. As
os.dupterm() is there, implement UART REPL support at the high level -
if MICROPY_STDIO_UART is set, make default boot.py contain os.dupterm()
call for a UART. This means that changing MICROPY_STDIO_UART value will
also require erasing flash on a module to force boot.py re-creation.

This fixes an obvious case of non-fair scheduling of 2 tasks with the same
deadline.

There is a minor functional change with this patch, that the GPIO are now
configured in fast mode, whereas they were in high speed mode before.  But
the SDIO should still work because SD CK frequency is at most 25MHz.

They are the same as the existing raw constants (namely 0, 1, 2) but we
want to explicitly show that one can use the HAL's constants if necessary
(eg the mpconfigboard.h files do use the HAL's constants to define the
pull state of certain configurable pins).

Without this the timer will have random values for its State and Lock
entries.  The object can then be in a locked state leading to some HAL
functions returning immediately with an error code (which is unchecked).

This patch fixes such a bug which did manifest itself as PWM not working
correctly for LEDs.

Now that specialized utimeq module has been implenented, revert previous
adhoc changes to uheapq.

This reverts commit 0cbc0722.

Passing -v -v -v on the command line of the coverage build will now print
the parse tree (as well as other things at this verbosity level).

The lexer is very mature and this debug function is no longer used.  If
it's really needed one can uncomment it and recompile.