printf double precision but getting just single precision

[Gahlen Feld]

Posted on June 13, 2017 at 08:51

Hello,

I am working on a firmware for the STM32F765.

This MCU was chosen because of its double precision floating point capabilities.I manged to configure the FPU/Compiler (ARM GCC 5.4) to genertate correct DP native assembly instructions.When debugging, I can verify correct DP calculations.

The only thing I cannot manage is to printf results in double precision.

I have tried the formatters %f and %lf but on every printf only single precision is printed out (correctly rounded results but with too less digits).I am using newlib speed optimized (NOT nano), but also the lib stdc++ does the same.Has somebody ever seen the printf output in double precision for an embedded ARM Cortex-M7 code with GCC & if yes, how do I get it running ?

Thank you in advance,

Gahlen

[AvaTar · Accepted solution]

Posted on June 13, 2017 at 10:02

I have tried the formatters %f and %lf but on every printf only single precision is printed out (correctly rounded results but with too less digits).

Take a look at the POSIX spec. of the

printf()

style functions (e.g. the Linux manpages).

For the e,f and g format, it states '...if the precision is missing, it is taken as 6;'.

Try, for example, '%.10lf'

[Uwe Bonnes]

Posted on June 13, 2017 at 11:03

'man fprintf' on my Linux system tells to use '%Lf' or '%llf' for long double arguments.

[Gahlen Feld]

Posted on June 13, 2017 at 10:33

Thank you very much! I did not know this, but exactly this was needed to print out the required precision.

[Gahlen Feld]

Posted on June 13, 2017 at 11:39

I just want to print out 64bit double values with many fractional digits. These have the printf formatters %f or %lf.

What you mean with %Lf or %llf is 128bit quad precision that the Cortec-M7 cannot handle natively.

[AvaTar]

Posted on June 13, 2017 at 11:58

And I'm pretty sure most scanf/printf implementations (libraries) for Cortex M cannot handle long double types.

[Tesla DeLorean]

Posted on June 13, 2017 at 19:29

>>

This MCU was chosen because of its double precision floating point capabilities.

I've never understood the use case for the single precision one....

Glad it was just a format issue, the default will be misleading, I tend to prefer specifying a very large number of decimal place, and using the '%le' variant.

Unfortunately the FPU designs of recent years don't hold intermediate values at higher precision, and this is compounded by the availability of only simpler intrinsic functions.

[Gahlen Feld]

Posted on June 14, 2017 at 11:33

I've never understood the use case for the single precision one....

I am 100% with you... what shall we do with just 7 decimal digits precision? -> single precision is just to have FP in the specs

I tend to prefer specifying a very large number of decimal place

unfortunately most programmers are not scientists at all; the current default value of 6 fractional digits is confusing in this situation because it let me thought that the output was single precision only

Unfortunately the FPU designs of recent years don't hold intermediate values at higher precision

I was a little bit disappointed when I read that the Cortex-M DP FPU has 64bit only, even for the internal intermediate values; I can remember that in the late 80s Motorola's FPUs already applied extended precision for intermediate representations...

this is compounded by the availability of only simpler intrinsic functions

I would be glad just to have native DP sin and cos functions for DQ transformations...

[AvaTar]

Posted on June 14, 2017 at 12:18

I assume three reasons:

• the supposed use cases for a general-purpose microcontroller,
• the costs (design & silicon),
• differentiation of markets (avoid competition with Cortex A).

[Gahlen Feld]

Posted on June 14, 2017 at 14:30

• Cortex-A comes with frequencies that is far out of range for Cortex-M, even in forseeable future
• silicon area for a better FPU sould be neglectable when it comes to costs of 8..10$ for an STM32F765 MCU
• currently the main reason probably is that ARM is not willing to offer a 1st class FPU for its M line (you alread said it), since STM 'only' adds their peripherals
• microcontrollers have been improved magnificently in this decade; I am sure that we will see ones with a full FPU and MMU soon