Posted by HSPalm on 2017-01-09 10:27

Okay, so I found a way to use C90 standard in Project Properties -> C/C++ Build -> Settings -> Tool Settings tab -> MCU GCC Compiler -> Dialect -> Language Standard.

But given the grief it gave me about coding style all around even in CMSIS and HAL I definitely am not compiling like this

So any hints on a suitable float to ascii function is appreciated!

Posted by dautrevaux on 2017-01-09 11:02

Hi,

Currently when you select the dialect there, you can only select ISO standard conformance, which is a lot more strict than the standard gnu settings. You can select gnu-C-90 dialect by letting the dialect unspecified in the “Language Standard” menu, but adding “-std=gnu90” in the “Other dialect flags” box (or any other supported dialect, see the C Compiler documentation in Other Manuals)

Bernard (Ac6)

Posted by HSPalm on 2017-01-09 11:29

Thank you for answering, Bernard.

adding -std=gnu90 in the “Other dialect flags” box compiled fine. But it did not seem to trigger the #ifndef STRICT_ANSI.

By the way, for some reason, when I try to use dtoa I get the “undefined reference to ´dtoa’ ” error. But if I try to use gcvtf which is defined right next to dtoa in stdlib.h I only get the warning “implicit declaration of function ´gcvtf’ “.

I’m looking through GCC 5.3.0 manual but I can’t figure out where to find help with usage of the functions, or their implementations? It’s not like Cube HAL where you would just open stdlib.c and read the comments above the gcvtf implementation, for instance

Posted by bugmenot on 2017-01-09 11:58

> I’m looking through GCC 5.3.0 manual but I can’t figure out where to find help with usage of the functions, or their implementations?

Those are not compiler-specific functions, those are standard C library functions, look in your libc documentation/reference.

BTW, why don’t you use the more common and well-known snprintf function?

FYI, gcvt and family are marked as LEGACY in POSIX.1-2001. POSIX.1-2008 removes the specification of gcvt(), recommending the use of sprintf(3) instead (though snprintf(3) may be preferable).

Posted by HSPalm on 2017-01-09 13:44

bugmenot, thank you for clarifying. It did come to me that I was looking in the compiler manual for something that is not compiler specific.
I will use snprintf. I was not aware of this, and will be testing later today. Thanks again.

Posted by bugmenot on 2017-01-09 14:50

> I will use snprintf

In that case, these topics may also be helpful in case if your snprintf refuses to print floats:
http://www.openstm32.org/tiki-view_forum_thread.php?forumId=7&comments_parentId=2488
http://www.openstm32.org/tiki-view_forum_thread.php?comments_parentId=2108
http://www.openstm32.org/tiki-view_forum_thread.php?comments_parentId=2648