avr-gcc floating point problems
in [Embedded]
|
Prev: ATI Catalyst 10.3 Preview Edition
Next: Network fabric
From: Cesar Rabak on 19 Mar 2010 14:28 Em 18/3/2010 17:39, linnix escreveu: > On Mar 18, 11:21 am, Habib Bouaziz-Viallet<h.bouazizvial...(a)free.fr> > wrote: >> Le Thu, 18 Mar 2010 10:47:44 -0700, linnix a �crit : >> >>> unsigned char u; >>> float f; >> >>> u = (unsigned char) f; >> >> In what kind of situation you need to cast a float to that unsigned >> char ??? >> If you want to extract the integer part of the float, let me tell you >> that this way is a bit silly. >> >> Question yourself before asking to C. >> >> Habib > > f is result of k1 * sine x + k2 * cosine y. > > How would you extract the integer part without casting? I would use round(), trunc(), ceil() or floor() as each could better fit. -- Cesar Rabak GNU/Linux User 52247. Get counted: http://counter.li.org/
From: Hans-Bernhard Bröker on 19 Mar 2010 14:43 [F'up2 set --- this has nothing to do with electronics design] Habib Bouaziz-Viallet wrote: > David Brown a �crit : >> On 19/03/2010 10:34, Habib Bouaziz-Viallet wrote: >>> In that case i'm quite sure gcc promote internally the (unsigned char)f >>> to an int. You're sure of something incorrect there. > That is exactly the point. Why in the earth someone would need to > convert a float (doing sine and cosine) to a unsigned char ??? That's none of your business. It's perfectly allowed C code, so the compiler _must_ support it. > When you make a cast from a float to an unsigned int it would result a > zero if the float is negative (not quite sure either ... just conjecture) Well, wrong again. Values from 0 (inclusive) to -1 (exclusive) convert to zero, all other negative values cause undefined behaviour. > BTW i don't know what would be the result if the target has a FPU (like > our big bunch desktop machines) ... :-) That has nothing to do with it, in principle.
From: Habib Bouaziz-Viallet on 19 Mar 2010 16:17 Hans-Bernhard Br�ker wrote: > [F'up2 set --- this has nothing to do with electronics design] > > Habib Bouaziz-Viallet wrote: >> David Brown a �crit : >>> On 19/03/2010 10:34, Habib Bouaziz-Viallet wrote: > >>>> In that case i'm quite sure gcc promote internally the (unsigned char)f >>>> to an int. > > You're sure of something incorrect there. > >> That is exactly the point. Why in the earth someone would need to >> convert a float (doing sine and cosine) to a unsigned char ??? > > That's none of your business. It's perfectly allowed C code, so the > compiler _must_ support it. > >> When you make a cast from a float to an unsigned int it would result a >> zero if the float is negative (not quite sure either ... just conjecture) > > Well, wrong again. Values from 0 (inclusive) to -1 (exclusive) convert > to zero, all other negative values cause undefined behaviour. > >> BTW i don't know what would be the result if the target has a FPU >> (like our big bunch desktop machines) ... :-) > > That has nothing to do with it, in principle. > .... A bunch of misunderstanding as usual. But where have you been while others are struggling about that funny business ? Playing with sine and cosine and casting results to unsigned ... pity ! And you're a pity also comming here and explain me what is permitted as a programmer. Habib
From: linnix on 19 Mar 2010 16:45 On Mar 19, 1:17 pm, Habib Bouaziz-Viallet <h.bouazizvial...(a)free.fr> wrote: > Hans-Bernhard Bröker wrote: > > [F'up2 set --- this has nothing to do with electronics design] > > > Habib Bouaziz-Viallet wrote: > >> David Brown a écrit : > >>> On 19/03/2010 10:34, Habib Bouaziz-Viallet wrote: > > >>>> In that case i'm quite sure gcc promote internally the (unsigned char)f > >>>> to an int. > > > You're sure of something incorrect there. > > >> That is exactly the point. Why in the earth someone would need to > >> convert a float (doing sine and cosine) to a unsigned char ??? > > > That's none of your business. It's perfectly allowed C code, so the > > compiler _must_ support it. > > >> When you make a cast from a float to an unsigned int it would result a > >> zero if the float is negative (not quite sure either ... just conjecture) > > > Well, wrong again. Values from 0 (inclusive) to -1 (exclusive) convert > > to zero, all other negative values cause undefined behaviour. > > >> BTW i don't know what would be the result if the target has a FPU > >> (like our big bunch desktop machines) ... :-) > > > That has nothing to do with it, in principle. > > ... A bunch of misunderstanding as usual. > > But where have you been while others are struggling about that funny > business ? > > Playing with sine and cosine and casting results to unsigned ... pity ! Why? The result is a phase correction output driving 8 bit D/A. The D/A does not understand float. There is no problem with the code or compiler. However, WinAVR math library files are not properly setup. Certain floating point ops cause confusions with the linker. I wish the error messages are easier to understand.
From: Tauno Voipio on 19 Mar 2010 16:52
On 18.3.10 7:47 , linnix wrote: > In response to another thread, I am still getting these problems with > WinAVR 2010. I think the linker is hitting some AVR limits. There > are similar reports on the web as well. > ------------------------------------------------------------------------------------------------- > > unsigned char u; > float f; > > u = (unsigned char) f; > > --------------------------------------------------------------------------------------------------- > c:/wavr10/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/ > avr35\libc.a(fp_powsodd.o): In function `__fp_powsodd': > (.text.avr-libc.fplib+0x10): relocation truncated to fit: > R_AVR_13_PCREL against symbol `__mulsf3' defined in .text section in > c:/wavr10/bin/../lib/gcc/avr/4.3.3/avr35\libgcc.a(_mul_sf.o) > c:/wavr10/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/ > avr35\libc.a(fp_powsodd.o): In function `__fp_powsodd': > (.text.avr-libc.fplib+0x20): relocation truncated to fit: > R_AVR_13_PCREL against symbol `__mulsf3' defined in .text section in > c:/wavr10/bin/../lib/gcc/avr/4.3.3/avr35\libgcc.a(_mul_sf.o) Did you use the proper -mmcu= option on the GCC command line? The errors point thet the compiler has generated code for 13 bit addresses (8 kiB memory), and the code exceeds the 13 bit address range. -- Tauno Voipio tauno voipio (at) iki fi |