The cleanup includes the following changes:
- The `esptool.py` is no longer installed as a RIOT package, but as a pure Python package, as published by Espressif. The installation takes place in a virtual Python environment in the `dist/tools/esptools/venv` directory.
- The installation of the `esptool.py` is now version-sensitive.
- The `esptool.py` from the Python package is always used.
- The option for users to use a custom `esptool.py` has been removed because newer versions of `esptool.py` use renamed options that are not compatible with older versions of `esptool.py`. Using a custom `esptool.py` therefore makes no sense.
It makes no sense to have a separate `esp_ble_$(CPU_FAM)` feature for each ESP32x variant. The ESP32x has either a BLE controller or not. Therefore, a single common `esp_ble` feature is sufficient.
`esptool.py` is now used as a package within a virtual Python environment. Since `esptool.py` is used for compilation on the one hand and for flashing on the other, `esptool.py` is installed in two separate virtual Python environments, one for compilation and one for flashing only. This is required
1. to be able to flash a precompiled application only without compiling the package and
2. to be able to compile an application in RIOT Docker and flash it on the host system.
This adds a default `TTY_BOARD_FILTER` for use with the Tigard debugger,
so that when the programmer is a Tigard that tigard is also used by
default for the serial connection.
In addition, this allows selecting the TTY via the programmer serial
number.
Co-authored-by: crasbe <crasbe@gmail.com>
Add a uard around macro BTN0_PIN definition to allow the user to redefine
it in order to use the SPI module.
Add a guard around SAUL parameters that use BTN0_PIN to avoid error when
it is redefined.
The Adafruit Clue and Itsybitsy nRF52 also use the Adafruit nRF52
Bootloader which has a common module that can be used.
Especially the Itsybitsy nRF52 (mis)uses the nrfutil programmer
target and has a lot of redundant code.
Furthermore, the Double Tap Magic Value used by both boards
is incorrect for using the USB Bootloader.
This changes the documentation of how to configure stdio, especially
with regard on how to configure the stdio frontends with
`printf_float`, `printf_long_long`, and `stdin`.
Co-authored-by: crasbe <crasbe@gmail.com>
When executing `make generate-Makefile.ci` in the base directory,
the make system would try to call `riotgen` with `Makefile.ci`,
which does not work. Likewise with any other target like
`make generate-bogus`. The pattern rule for the prerequisites was
not evaluated by make, therefore the check did not work as
intended.
This adds the new `printf_long_long` module that can be used to enable
printing of `long long` and `unsigned long long`.
This has been implemented for `mpaland-printf`. In addition, this module
is a default module for 32-bit and 64-bit systems if `mpaland-printf` is
used, 64 bit support is not too expensive for them. (And on 64-bit
systems support for long long is needed for support of `%p`, which is
pretty basic.)
This is mainly useful for MSP430, where otherwise `mpaland-printf` would
require more memory than newlib's implementation.
This adds `-Wno-unterminated-string-initialization` to the `CFLAGS` if
(and only if) the compiler supports this.
This also adds `-Wno-maybe-uninitialized`. This warning has been
supported for quite some time, but the diagnostics triggers more often
with newer GCC releases.
Modules can now add the following snipped to their `Makefile`:
MODULE_SUPPORTS_STATIC_ANALYSIS := 1
When the application is then build with `make STATIC_ANALYSIS=1`, all
modules that opted in to static analysis get build with static analysis.
Replace elf2uf2 usage with picotool, fix compilation when arm g++ is installed, adjust documentation to new workflow, picotool udev warning (thanks to crasbe)
Treat documentation issues flagged by LLVM as hard errors.
LLVM tends to be a lot less picky about documentation issues compared
to Doxygen (e.g. no warning about missing doc), but warns about things
that really are not intentional (e.g. `@param foo` when the argument has
been renamed to `bar`, `@return` when the return type is `void`, ...).
Having this as a base line requirement seems pretty sane.
