Add print(float) to save space (VS double).

[honnet]

Summary

This PR implements the following methods in Print.h and Print.cpp:

• Feature 1: Print::print(float) - - - only double was available
• Feature 2: Print::println(float) - - - only double was available
• Feature 2: Print::printFloat(float) - - - only double was available => maybe it should be called printDouble(double)?

---

Motivation

Some of the new MCUs have a limited memory (ex: 32KB for STM32C011D6) and don't have floating point calculation unit, so a simple accelerometer driver (example) can take more than 100% of the flash if we don't optimize it a bit (the compilation fails at first).

This PR saves up to 10K by avoiding the compiler to use ARM libs for double calculation subroutines such as __aeabi_dsub, __aeabi_dadd, __aeabi_dmul, etc.

---

Validation

The following command allows listing the heaviest functions after compilation:
arm-none-eabi-nm --print-size --size-sort --radix=d -l file.elf | tail -n 3

134242369 00001416 T __aeabi_dmul
134240049 00001724 T __aeabi_dadd
134243785 00001796 T __aeabi_dsub

The problem can also be observed in the assembly code [with C code + comments using debug enabled (-g) if there's enough space]:
arm-none-eabi-objdump -S file.elf

---

Note
The printFloat(float) function repeats a lot of what printFloat(double) does and it should probably be factorized.
I expect that this PR could be rejected for this reason at least, let me know if you have any suggestion of how to implement it (using templates?).

[fpistm]

HI @honnet
Thanks for this PR.
do you evaluate the Serial.printf("%f"); (enable Newlib + prinrtf float support in the menu) or the dtostrf()?

[honnet]

Thanks for the feedback!

Sadly, with the simple accelerometer example, enabling Newlib with prinrtf takes too much space (=> linker error).

...but it says how much memory is missing so I got the following values:

• newlib + float + Serial.print() : 42K
• newlib + float + Serial.printf(): 41K
• dtostrf: 30K

As a comparison, with my PR, the space used is 27K (which is already tight for the 32K available flash).

---

Edit - other example:

For the C011 or C031 (32KB max), the following code will not compile without my PR:
https://github.com/adafruit/Adafruit_MMC56x3/tree/main/examples/compass

[fpistm]

Hi @honnet
I've updated your PR with template to avoid code duplication.
I guess this enhancement could be shared with ArduinoCore-API in order to be aligned:
https://github.com/arduino/ArduinoCore-API/blob/master/api/Print.h

[fpistm]

LGTM

[honnet]

Great!
Thanks a lot for the improvement!

[fpistm]

It is not yet merged 😉

[honnet]

My bad, sorry!

[fpistm]

@honnet seems you rebase and removed all changes....

[honnet]

Damn, I didn't pay attention and I thought I integrated your modifications!

I found a hash in my terminal history, cherry-picked it and pushed it:
main...honnet:Arduino_Core_STM32:main

Does it make the PR usable now, or should I do it again?

[fpistm]

I will restore it tomorrow. Do nothing until I fix the issue.

[honnet]

I just tested a c/cpp compiler option to forbid doubles: -fsingle-precision-constant:
https://github.com/stm32duino/Arduino_Core_STM32/blob/main/platform.txt#L35-L37

It's even more systematic and future proof against libraries that hide implicit doubles (in constants for example).

...but I'm not sure how to make it user friendly:

1. in the Optimize options?
   https://github.com/stm32duino/Arduino_Core_STM32/blob/main/boards.txt#L11490

2. in the C Runtime Library options?
   https://github.com/stm32duino/Arduino_Core_STM32/blob/main/boards.txt#L12404

3. something else? nowhere? (maybe it's just a bad idea)

Is it worth exploring something clean? (any advice would be appreciated)

[fpistm]

You can use build_opt.h feature, it was added to support such kind of request:
https://github.com/stm32duino/Arduino_Core_STM32/wiki/Customize-build-options-using-build_opt.h

[honnet]

Perfect!
Thanks again so much!!