Damien Hoyen wrote:
> Hello,
>
> Is somebody was able to use with Yagarto - GCC 4.2.2
> the SPRINTF() function successfully with FLOAT ?
>
> for example :
> sprintf(Tmp,"Test float value %f",1.241);
>
> return in Tmp (of course, without "") :
> "Test float value £.££££££"     where £ is: a not printable character
>
>
> I can't understand why the sprintf function generate bad output string
> when I ask to convert FLOAT variable (I have no problem with integer).
> (in fact, all the "printf" family function, i suppose (I detected this
> strange result with vsnprintf)).
>
> Please note: I don't receive: error or warning during the compilation
> (see below for flag).
> Remaining of program runs perfectly.
>
> Any idea ?
>
> Thanks in advance.
>
> Damien
>
>
> Hardware : ST STR912 ARM9, demo board Olimex
> Software : Yagarto GCC 4.2.2, Eclipse 3.3.2
>

Hello,
I am just facing the same issue (see my post "Yagarto and floating
Point"), I also use an Olimex STR912E.
From now, my solution is to use Idealist toolchain that works fine. But
I would like to understand what happen, so I will follow up your post.
So let me know if you have a solution.
Good luke.

Newlib can be built without floating support support (to make it
smaller), so perhaps that is your problem.

In embedded systems with limited memory resource and no FPU it is
generally best to avoid floating point altogether, especially if it is a
real-time system.

Clifford

... forgot to mention. If that is the problem, you will need to rebuild
Newlib (see http://venus.billgatliff.com/node/3 for example).

You wouldn't get a compiler error or warning, because the format string
is parsed by the library code at run-time, not the compiler - and the
compiler knows nothing about whether or not the library provides full
support or not in any case.

I am guessing that the printing of a dummy string, is just Newlib's way
of failing gracefully when faced with unsupported format specifiers that
are nonetheless valid C code.

I do not use Yagarto, but perhaps the distribution comes with more than
one variant of the library.

Clifford Slocombe wrote:
> Newlib can be built without floating support support (to make it
> smaller), so perhaps that is your problem.
>
> In embedded systems with limited memory resource and no FPU it is
> generally best to avoid floating point altogether, especially if it is a
> real-time system.
>
> Clifford

Hi Clifford,
Well...i am switching to arm design from a current 8051 design, you know
a 8 bit only microcontroller with 64kB maximum! I use a Keil dev tool
which is well known for this family and I do code with floating point
and all sprintf/printf stuff, and it takes something between 5kB and
10kB to implement that.
Then I am a bit surprised when I read that printf must be avoid on arm
32 bits device with up to 2MB integrated flash !!
Moreover, the Idealist chain which gives good results with my project
including floating point arithmetic and sprintf leads to around 50k. It
does not work with Yagarto/Ride/Crosswork tools I tried, and they give
roughly the same amount of code. All without any compile nor link error.
There must be something wrong with floating point and the way gcc is
build for arm tool chain, but I am not advanced enough to solve it, so
if there is any expert online?

Joel Jomed wrote:
> Then I am a bit surprised when I read that printf must be avoid on arm
> 32 bits device with up to 2MB integrated flash !!

If that is what you have, use the full implementation of stdio by all
means. Some parts have as little as 8k and no external bus. It also
depends on how much application code you are putting on your part - not
all applications have the headroom, and not all projects have the budget
or BOM target cost to afford a roomy part. It is not always so much a
matter of size but speed. Software implemented floating point arithmetic
is laboriously slow, it is usually no good for numerically intensive
real-time applications. Few ARM parts have an FPU, NXP's LPC3xxx series
and Freescale's iMX-31 being notable exceptions. Also 32bit code density
is seldom going to be as good as an 8 bit device, if only because the
instructions are four times larger!

It is not that floating point is not supported because ARM parts cannot
do it, it is rather that some applications cannot afford it, so you have
the choice, you can build Newlib with or without floating point support.
In 18 years as an embedded systems developer I have seldom needed
floating point, and I certainly would not bother to use it just for
display. It is easy enough to display a fixed point value for human
readability.

> Moreover, the Idealist chain which gives good results with my project
> including floating point arithmetic and sprintf leads to around 50k. It
> does not work with Yagarto/Ride/Crosswork tools I tried, and they give
> roughly the same amount of code. All without any compile nor link error.
> There must be something wrong with floating point and the way gcc is
> build for arm tool chain, but I am not advanced enough to solve it, so
> if there is any expert online?

I am not sure you understood my earlier answer. Newlib is the standard C
library implementation provided with Yagarto (and WinARM for that
matter). It is the library that is the issue here, not the compiler. As
far as I can tell IDEaliST is an IDE not a toolchain.

I wonder why you would not use Keil uVision ARM tools if you are used to
Keil. Keil is now wholly owned by ARM.

I use WinARM and its Newlib stdio certainly handles floating point
format specifiers normally.

Clifford Slocombe wrote:
> Joel Jomed wrote:
>> Then I am a bit surprised when I read that printf must be avoid on arm
>> 32 bits device with up to 2MB integrated flash !!
>
> If that is what you have, use the full implementation of stdio by all
> means. Some parts have as little as 8k and no external bus. It also
> depends on how much application code you are putting on your part - not
> all applications have the headroom, and not all projects have the budget
> or BOM target cost to afford a roomy part. It is not always so much a
> matter of size but speed. Software implemented floating point arithmetic
> is laboriously slow, it is usually no good for numerically intensive
> real-time applications. Few ARM parts have an FPU, NXP's LPC3xxx series
> and Freescale's iMX-31 being notable exceptions. Also 32bit code density
> is seldom going to be as good as an 8 bit device, if only because the
> instructions are four times larger!
>
> It is not that floating point is not supported because ARM parts cannot
> do it, it is rather that some applications cannot afford it, so you have
> the choice, you can build Newlib with or without floating point support.
> In 18 years as an embedded systems developer I have seldom needed
> floating point, and I certainly would not bother to use it just for
> display. It is easy enough to display a fixed point value for human
> readability.
>
>> Moreover, the Idealist chain which gives good results with my project
>> including floating point arithmetic and sprintf leads to around 50k. It
>> does not work with Yagarto/Ride/Crosswork tools I tried, and they give
>> roughly the same amount of code. All without any compile nor link error.
>> There must be something wrong with floating point and the way gcc is
>> build for arm tool chain, but I am not advanced enough to solve it, so
>> if there is any expert online?
>
> I am not sure you understood my earlier answer. Newlib is the standard C
> library implementation provided with Yagarto (and WinARM for that
> matter). It is the library that is the issue here, not the compiler. As
> far as I can tell IDEaliST is an IDE not a toolchain.
>
> I wonder why you would not use Keil uVision ARM tools if you are used to
> Keil. Keil is now wholly owned by ARM.
>
> I use WinARM and its Newlib stdio certainly handles floating point
> format specifiers normally.

Hi Clifford,
Thanks for your reply and help.
I like the KEIL tool but I am fed up with the dongle, this key you
forget when having a patch to do on the field (it happened to me in
Africa last year...)...and not enough money to buy two or three
licences/dongles!
The main advantage of GCC Open Source for me being the low cost "lets
see" phase and the perennialty. It is why an Eclipse+GCC was a practical
good choice (then Yagarto).
Do you know where I can get WinARM and if it support ARM966E-S?
Many thanks again,
Joel

Joel Jomed wrote:

> The main advantage of GCC Open Source for me being the low cost "lets
> see" phase and the perennialty. It is why an Eclipse+GCC was a practical
> good choice (then Yagarto).

Its hard to argue with free.

> Do you know where I can get WinARM and if it support ARM966E-S?

It comes pretty high up in Google when you search on "WinARM".
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/#winarm. It
is currently GCC 4.1.1, so whatever that supports, I am using it with an
ARM9 so you will have no problems.