- `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>
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 makes sure that newlib's printf is correctly overridden by:
1. Adding wrappers for some more obscure printf() variants
2. Forcing a compilation failure when newlib's stdio is still linked in
while mpaland-printf is used
3. Not adding `-u _printf_float` to the linker flags when mpaland-printf
is used.
This packs the stdio implementation from [1] as alternative to
what the used standard C lib provides with the intent to provide a
thread-safe, smaller, and more feature-complete alternative on
newlib targets.
Compared to `newlib_nano` this reduces `.text` by a bit more than 200 B
while adding support for standard format specifiers such as `RPIu8`,
`PRIu16`, `PRIu64`, `%z`, and `%t`.
Note that `newlib_nano`'s stdio can be thread-safe in reentrant mode
at the cost of RAM (per thread) and latency. Especially the increase
in latency can be prohibitive when real time requirements need to be
met.
[1]: https://github.com/mpaland/printf
