newlib and picolibc already implicitly add the `0x` prefix for `%p` just
as glibc does, and some of our tests scripts depend on this.
(And subjectively, this looks better.)
This adds https://github.com/mpaland/printf/pull/90 on top of our
patches.
This is required to support printing 64 bit numbers, as is done in the
test.
In addition that 64 bit formatting test is feature gated, so that users
can simply comment out the `USEMODULE += printf_long_long` to fit tiny
boards.
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
This avoids inconsistent output when external code gets linked in that
directly links against newlib's assert implementation (e.g. binary blobs
or packages that do not add `core/lib/include` to the include paths).
This also greatly benefits wrapping printf, as newlib's `__assert_func()`
directly links to internal printf functions of newlib.
Co-authored-by: crasbe <crasbe@gmail.com>
That way users can rely on elimation of dead code from the optimizer
instead of having to use preprocessor conditionals when feature-gating
assert implementations behind `!NDEBUG`.
Co-authored-by: benpicco <benpicco@googlemail.com>
Co-authored-by: crasbe <crasbe@gmail.com>
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
This drops a workaround that initialized newlib's reentrancy structure
on boot to reduce the chances of crashes when using the non-thread-safe
(unless reentrancy hooks are provided) stdio implementation of newlib.
Now that the newlib stdio implementation is only ever used if it is
thread-safe, we no longer need a workaround that reduces the chance
of crashes on concurrent use of stdio.
This makes use of the new bug modeling to declare all platforms that
can use newlib and have no reentrancy hooks as affected by the
non-thread-safe stdio bug. (Which is every platform but ESP* and AVR,
the former because the reentrancy hooks are provided, the latter because
we do not and never will support newlib on them.)
Building on that, the mpaland-printf package is used when newlib is
used and the bug is present. This way we can rely on the stdio being
thread-safe on every platform and not causing random crashes at run
time.
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
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.
