This introduces a new feature category to declare which bugs are present
in a given build that we cannot fix in RIOT, but need to work around.
These bugs may be silicon bugs, software bugs in ROM, software bugs in
binary blobs needed for a platform, or bugs in the toolchain.
These features behave the same way as `arch_%` features: Every provided
bug is always used, so that we can inspect `FEATURES_USED` to check
which bugs need to be worked around.
Co-authored-by: crasbe <crasbe@gmail.com>
- `arch_64bit` depends on long long support (rather than just enabling
it by default), as otherwise `%p` will not work correctly
==> add hard dependency
- On 32 bit platforms support of printing long long is not almost free
==> do not enable long long on `arch_32bit` by default
- The ESP SDK contains binary blobs that already link against newlib and
mpaland-printf is not ABI compatible with newlib's stdio, it is only
API compatible.
==> mark mpaland-printf as incompatible to ESP MCUs
Co-authored-by: crasbe <crasbe@gmail.com>
Nucleo144 boards for L5 and U5 have a completely different analog pin configuration. It's a very small change, but due to style changes it seems like a big change. In fact, the configuration has been changed just by adding an #ifdef ... #else ... #end and the six analog pins for L5 and U5 boards.
This tests makes little sense to have for a number of reasons:
1. One should not use `iprintf()` for a number of reasons:
1. It is non-standard and using it over `printf()` makes the code
less portable (e.g. it cannot be used on AVR)
2. The idea of adding a leaner variant of `printf()` in addition to
the larger one is bogus, as apps will end up using both resulting
in a *larger* firmware instead of a smaller
3. RIOT's build system already has the `printf_float` module to
control whether formatting of floating point numbers should be
suppered. This mechanism will actually result in smaller builds,
if floating point support is not needed, as it prevents two
variants of printf to be linked in.
2. The test checks some implementation details (e.g. whether the
address of two functions is identical), rather than correct behavior
of the implementation. This is completely bogus.
According to user manuals the pin configuration for Arduino pins D14/D15 is PB9/PB8. The configuration was mixed up. Furthermore, I2C_DEV(1) is configured correclty with SDA=PB9 and SCL=PB8 that have to be mapped to Arduino pins D14=SDA and D15=SCL, respectively, to be compatibly with Arduino shields.
