usart printf float

[aeolia_amha]

Posted on May 31, 2010 at 05:25

usart printf float

[Andrew Neil]

Posted on May 17, 2011 at 13:52

Floating point takes a very large amount of code and, therefore, can be quite slow. There are also issues with precision.

For these reasons, most embedded compilers will not include floating point support unless specifically requested. The first thing you need to do is to ask yourself whether you really need floating point. If, after careful consideration, you find that you really do need floating point, then you will have to consult the specific documentation for the tools that you are using to determine how to enable it...''how do you display printf values in floating point numbers in hyperterminal'' Note that Hyperterminal is entirely irrelevant here:

• printf has no knowledge of what output device is being used - let alone what specific peripheral is attached to that device;
• Hyperterminal simply displays characers verbatim as recived - it has no knowledge of where they originated, or what they mean (eg, whether they represent floating point numbers)

From: ongsyping.benison

Posted: Monday, May 31, 2010 5:25 AMSubject: usart printf float

Hi, how do you display printf values in floating point numbers in hyperterminal. I can only display using int numbers based on an example of RTC project.

Is it because of this code that it only works as int numbers:

#ifdef __GNUC__

  /* With GCC/RAISONANCE, small printf (option LD Linker->Libraries->Small printf

     set to 'Yes') calls __io_putchar() */

  #define PUTCHAR_PROTOTYPE int __io_putchar(int ch)

#else

  #define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f)

#endif /* __GNUC__ *.

Thanks.

[aeolia_amha]

Posted on May 17, 2011 at 13:52

Thanks for the info. I now know that the hyperterminal is not limited to int numbers only but only outputs what is programmed.

    I know that floating point takes a huge amount of code but I'm unsure if the STM32 microcontroller can handle it. Since most codes are given in u32 format. A float takes up 64 while double makes 128. I need a floating point input and output because exact computations where arithmetic and trigonometric functions are needed. I also use #include<math.h> are needed for trigonometric functions. Any suggestions on how to implement this?

[Tesla DeLorean]

Posted on May 17, 2011 at 13:52

float is 32-bit, double is 64-bit

The STM32 is certainly capable of running floating point software libraries, not sure how to achieve it with GNU, but seems to work fine with Keil, though I'd recommend expanding the stack to support printf(), and scanf() Check the documentation for your tool chain, probably requires some command line options or libraries to be enabled if it is not coming in by default.

[t1]

Posted on May 17, 2011 at 13:52

''I know that floating point takes a huge amount of code''

No it doesn't. ''but I'm unsure if the STM32 microcontroller can handle it.'' Yes it can. ''though I'd recommend expanding the stack'' Not required it the stack and heap automatically make use of all unused memory. ''If you need exact computations, then you possibly should not be using floating point! I think he means 'precision computations'.  Trigonometric functions will require floating point arithmetic. ''There are also issues with precision.'' Well yes, floating point arithmetic is not precise but when does it become an issue? ''A float takes up 64 while double makes 128. '' A float takes up 32 bits (not very precise) while double makes 64 bits (probably as precise as you need it to be).

[Andrew Neil]

Posted on May 17, 2011 at 13:52

''I need a floating point input and output because exact computations where arithmetic and trigonometric functions are needed''

If you need exact computations, then you possibly should not be using floating point! See, for example:

http://www.techradar.com/news/computing/why-computers-suck-at-maths-644771?artc_pg=1

http://blog.revolutionanalytics.com/2009/11/floatingpoint-errors-explained.html

http://wiki.seas.harvard.edu/geos-chem/index.php/Floating_point_math_issues

If you need exact computations, then you should perhaps be looking at fixed-point or integer maths?

[Andrew Neil]

Posted on May 17, 2011 at 13:52

''Trigonometric functions will require floating point arithmetic''

No, they don't require it - they can be done with fixed point (ie, scaled integer) arithmetic.''floating point arithmetic is not precise but when does it become an issue?'' See, for example, the linked articles. The biggest issue is probably for the unwary user who doesn't think (or even know) of the imprecision and, as a result, makes the common mistakes mentioned in those articles...

[Andrew Neil]

Posted on May 17, 2011 at 13:52

Hmm... the stupid forum seems to have hidden most of my original reply - including the ''linked articles''; they were:

See, for example:

http://www.techradar.com/news/computing/why-computers-suck-at-maths-644771?artc_pg=1

http://blog.revolutionanalytics.com/2009/11/floatingpoint-errors-explained.html

http://wiki.seas.harvard.edu/geos-chem/index.php/Floating_point_math_issues

If you need exact computations, then you should perhaps be looking at fixed-point or integer maths?

[Tesla DeLorean]

Posted on May 17, 2011 at 13:52

Not required it the stack and heap automatically make use of all unused memory.

Apparently you haven't used some of the ST example code with Keil, as 512 bytes of stack is inadequate. The stack will descend into/through the heap, and it will eventually trash the static variables. Now, the WinARM GCC implementation does park the stack at the end of RAM, but that is hardly set in stone. Certainly anyone using an RTOS where smaller stacks are typically allocated should be aware that library functions can eat a lot of stack.

[aeolia_amha]

Posted on May 17, 2011 at 13:52

Basing on the firmware library, it can only display 24 types like u32,su32... But there is no info on how to display number with decimal places. In normal C compilers, like Visual C++, one can easily use printf(''%f'',number). Is there a way to display this?