NRF_LOG print double precision float number

[rolandash]

I am on SDK15.3, NRF52840, armgcc, makefile, console

I need to print a double float number in format of "x.xxxxE-xx". I already know that NRF_LOG can only print float with MARKER, so I use sprintf to format the number into a string buffer first, and then I use NRF_LOG to print that string using "%s" format specifier.

    char abuf[40];
    memset(abuf, 0, sizeof(abuf));

    uint8_t len = sprintf(abuf, "%.5E", 3000.8766);
 
    NRF_LOG_DEBUG("[KF] updated K gain: %s, %d\n", abuf, len);
    

However I only get white spaces or unprintable character.

Anyway I can do this properly?

thank you.

/Roland

[Jørgen Holmefjord]

Hi,

The Makefiles in the SDK does not include float support for printf in armgcc by default. Please try adding the flags from this post to the LIB_FILES, that seems to print the way you want in my test:

# Add standard libraries at the very end of the linker input, after all objects
# that may need symbols provided by these libraries.
LIB_FILES += -lc -lnosys -lm -lrdimon -u _printf_float

<info> app: [KF] updated K gain: 3.00088E+03, 11

Best regards,
Jørgen

[Jørgen Holmefjord]

Are you using a different armgcc version than the default supported in SDK 15.3.0 (7 2018-q2-update)? Which OS are you building on?

I tested again with an unmodified example, and adding these two additional flags (-lrdimon -u _printf_float) makes the output look like I posted above in this example as well.

[rolandash]

Hi,

I upgraded from previous version of SDK, and I am on MacOS, I think I am using following version:

GNU Tools for Arm Embedded Processors 7-2017-q4-major

gcc version 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204]

Will that make a difference?

Can you please upload your test project so I can make a comparison locally?

thank you!

[Jørgen Holmefjord]

This is the project I initially used for testing with SDK 15.3.0: 8360.double_float_test.zip. There is also included a hex-file in the _build directory in case you want to test that.

I'm not sure if the compiler version or OS makes any difference, I'm just asking in order to try to recreate your environment as close as possible. Just tested with SDK 17.0.2 and 9 2019-q4-major, but this still works fine on my setup.

[rolandash]

thanks you Jørgen

I forgot to mention I am using RTT as backend of NRF_LOG

Does that matter?

[Jørgen Holmefjord]

I do not see any ways that the logger backend could be causing this. However, one thing you should try is to use NRF_LOG_PUSH() to push the string to the internal string buffer if this is part of a larger application, and you are using deferred logging. The string may be overwritten on the stack before it is processed by the logger backends. It could look like this is the problem in your latest log message, since the length seems to be correct at 11.

[rolandash]

Although it sounds like making no sense to me, your last hint just made my day :-)

[Takeshi Goda]

hi,jorgen

I also encountered this problem. I struggled for a day and was puzzled.

I tried all the methods in the world.

your last hint makes me feel you are Linus.