floating point numbers are not displayed correctly when using printf/sprintf

[OlegHahm]

example code:
uint32_t value = 4688400; float test_secs = (float)(value); printf("Value: %lu, test_secs: %f, test_secs/1000000: %f\n", value, test_secs, test_secs/1000000.0);
output:

Value: 4688400, test_secs: -593395331576418032070107601347274796814779226477615119074935151325494288374806955180858448199930421815096455549544570545856896334085141326372559621036970412650772246306121905719839090181013742283966753869290184601151471616.000000, test_secs/1000000: 0.000000

[OlegHahm]

This problem seems not to occur with older version of the Code Sourcery toolchain (<2008q3) or the self-built tool chain. It seems also be partly fixed in cdad71d for current Codebench toolchain but re-appears when compiling without optimization (-O0).

[Kijewski]

Is this problem still existent?

[OlegHahm]

Yes.

[haukepetersen]

Can we maybe find a way to omit the usage of printf+float at all?
As I am a big fan of the newlib nano.specs, which don't have the printf+float capability at all, it would be nice if RIOT works completely without using this...

[haukepetersen]

Can we maybe live with this issue, as #1352 solves the problem for to my knowledge the only part in RIOT where we depend on printing floats?!

[LudwigKnuepfer]

We print floats in other places too...

$ git grep 'printf.*%f' | grep 'c:'
dist/tools/linux-border_router/testing.c:    printf("%d, %f\n", runs_per_test, interval);
dist/tools/linux-border_router/testing.c:    sprintf(command, "ping6 -v -f -c %d -i %f -W 1 abcd::d",
drivers/cc110x/cc1100_phy.c:        printf("WOR receive time:         0x%.2X (%f ms)\r\n", cc1100_wor_config.rx_time_reg,
drivers/lm75a/lm75a-temp-sensor.c:    printf("hystTemp = %f\n", lm75A_get_hysteresis_temperature());
drivers/lm75a/lm75a-temp-sensor.c:    printf("overTemp = %f\n", lm75A_get_over_temperature());
drivers/lm75a/lm75a-temp-sensor.c:    printf("initialHystTemp = %f\n", lm75A_get_hysteresis_temperature());
drivers/lm75a/lm75a-temp-sensor.c:    printf("initialOverTemp = %f\n", lm75A_get_over_temperature());
drivers/lm75a/lm75a-temp-sensor.c:    printf("hystTemp = %f\n", lm75A_get_hysteresis_temperature());
drivers/lm75a/lm75a-temp-sensor.c:    printf("overTemp = %f\n", lm75A_get_over_temperature());
sys/net/routing/rpl/of_mrhof.c:    printf("Metric for parent returned: %f", etx_value);
sys/ping/ping.c:    printf("%s%f%s\n", "time=", rtt, "ms");
sys/shell/commands/sc_sht11.c:        printf("Temperature offset set to %f\n", (double) sht11_temperature_offset);
tests/test_bloom/main.c:    printf("%f false positive rate.\n", false_positive_rate);
tests/test_bloom_bytes/main.c:    printf("%f false positive rate.\n", false_positive_rate);

[haukepetersen]

oh damn, I only looked at core... So I guess this issue it not fixable too easily?

[OlegHahm]

But it looks that most of these calls can be rather easily replaced.

[LudwigKnuepfer]

I'm with @OlegHahm

[OlegHahm]

But is there something more elegant than

printf("WOR receive time:         0x%.2X (%u.%u ms)\r\n",
          cc1100_wor_config.rx_time_reg,
          (unsigned) cc1100_wor_config.rx_time_ms,
          (unsigned) ((cc1100_wor_config.rx_time_ms - ((unsigned) cc1100_wor_config.rx_time_ms)) * 1000));

without using libmath?

[OlegHahm]

Anyone with a nice idea?

[haukepetersen]

not really.

[timmmmmey]

It is still happening with CodeBench Lite 2014.05-28 and GNU Tools for ARM Embedded Processors 4.9.3 20141119.
Still no workaround?

[jnohlgard]

Just an idea: try building without nano.specs, i.e. full functionality
newlib. It should be somewhere in the makefile.include for the board or
CPU.
(I am not at my computer right now and I don't know anything about the code
bench tool chain so I can't provide any more information)
On Feb 20, 2015 2:41 PM, "timmmmmey" notifications@github.com wrote:

It is still happening with CodeBench Lite 2014.05-28 and GNU Tools for ARM
Embedded Processors 4.9.3 20141119.
Still no work around?

—
Reply to this email directly or view it on GitHub
#17 (comment).

[cgundogan]

this issue is quite old, but I came across this link command option several days ago: -u _printf_float or -u _scanf_floatrespectively for newlib-nano. According to the docs this should pull in float support for printf/scanf. Can someone test this?

[haukepetersen]

And while testing, do a code size comparison! I guess that would be most interesting here.

[miri64]

Is this still an issue?

[kYc0o]

It is related to #5094 ?

[miri64]

Does #5094 solve it or only partly?

[jnohlgard]

I have a printf test improvement in the works which will reveal other missing format identifiers.
With the current default build options on Mulle the float %f specifier is simply ignored, native works fine without changes. I guess that means that all other newlib_nano platforms are broken too..
Adding LINKFLAGS += -u _printf_float or USEMODULE += printf_float to the Makefile fixes the problem on my machine, but it adds about 8 kB ROM usage..

[jnohlgard]

#5094 solves the problem on mulle. (Add USEMODULE += printf_float to Makefile)

[kYc0o]

Good! Can we close this?

[jnohlgard]

yes, let's close this