I need to use sprintf with floating point numbers (%f format specifier) in a project based on rpmsg_lite_str_echo_rtos on the cortex-M (NXP Processor).I use the recommended arm-gnu-toolchain-12.3.rel1-mingw-w64-i686-arm-none-eabiI see that when I call
sprintf(str, "%d" 3);
the number 3 is printed to the string str.
But if I have a floating point number and I use "%f" format specifier
sprintf(str, "%f" 3.5);
I getASSERT ERROR " Balloc succeeded ": file "/data/jenkins/workspace/GNU-toolchain/arm-12/src/newlib-cygwin/newlib/libc/stdlib/mprec.c" Line "783" function name ""
It seems similar to this errorforum.pjrc.com/index.phpthat points to this fixgithub.com/.../f88aece242178ff0c187d56e34a79645fbc44a23
Is there a way to have sprintf working with floating point numbers?
Sorry for pushing, but no news idea on what happens here with nanolib?
Hi Stam Markianos-Wright
thanks for your answer.
You're right and newlib-nano doesn't contain floating point support.
With --specs=nano.specs floating point numbers ar enot printed at all (I imagine the printing function is expanded to "do nothing").
This is the reason why I removed the --specs=nano.specs option (as suggested here https://community.toradex.com/t/enable-floating-point-support-sprintf/8035/3)
But after I remove --specs=nano.specs to use the standard newlib, I see the Balloc error.
The error comes at runtime (i.e., during execution), and it doesn't matter if the str is on the stack, or on the heap.
I use FreeRTOS, and after a lot of investigation, I think that the issue comes from here
https://nadler.com/embedded/NXP_newlibAndFreeRTOS.html
This is for NXP uP, but the behavior is general: newlib is not threadsafe by default, and a lot of attention must me used when using it with FreeRTOS.
Can you confirm that in the toolchain newlib allows to reimplement the following hooks?
sbrk, __malloc_lock/unlock
Do you have suggestions on how to implement the under FreeRTOS?
Yes, I have definitely seen cases of sbrk being overriden by users, and I don't see any reason why you won't be able to do the same with the __malloc_lock/unlock symbols: i.e. it should be fine.Sadly I do not have any advice I can give for FreeRTOS, that is likely a question best asked on some FreeRTOS-related forum.
Thank you for the link to https://nadler.com. It was a really interesting read! If you have any advice on how we can improve the Arm GNU Toolchain, please let us know any we'll take your feedback on board.