Juan,
Have you tried the simulator?
George
Juan Gonzalez Gomez wrote:
> Hi Kustaa,
>
> Thanks for answering ;-)
>
> El lun, 06-04-2009 a las 09:05 +0300, Kustaa Nyholm escribió:
>
>> Hi,
>>
>> I presume the floating point code has been tested and works,
>> in my experience people don't release code that that has
>> not been tested, but of course a bug occasionally creeps in...
>>
>
> I have been working with floating point and sdcc for a long time and
> everything was ok. The problems started when I used negative floating
> points numbers.
>
>
>> Without running your code it would seem to me that
>> the code and your hardware behaves correctly when it
>> is showing all LEDs of ie the value is zero.
>>
>
> Yes, the hardware is ok. I have been using this hardware for many years
> for conducting the experiment of my dissertation. It was about the
> locomotion of modular robots.
>
> The same result are obtained in simulation
>
>
>
>> What you are attempting and assuming that -1 + 2 gives 1,
>> but this presumes that -1 and 2 are presentable
>> *exactly* in 'float' format, which is not the case, I think.
>>
>> So -1 + 2 is ever so slightly less than 1 which when
>> truncated (cast to char) becomes 0 hence all the LEDs are off.
>>
>> You may want to study floating point math a bit more,
>> it is full of pit falls like that, all too easy to
>> step into one.
>>
>
> That was the first idea. Maybe there was a truncation error. I have made
> some more test. This code works ok: (the complete code is attached)
>
> volatile float test;
>
> void main(void)
> {
> TRISB=0x00;
>
> test=5.4;
> PORTB=test;
>
> while(1);
> }
>
> As expected, a number 5 is shown in the leds (also in the simulator)
>
> This second code also works ok:
>
> volatile float test;
>
> void main(void)
> {
> TRISB=0x00;
>
> test=5.6;
> test= 5.6 + (-0.2);
>
> PORTB=test;
>
> while(1);
> }
>
> Again, the number 5 is shown in the leds.
>
> But this code DOES not work:
>
> volatile float test;
> volatile float test2;
>
> void main(void)
> {
> TRISB=0x00;
>
> test=5.6;
> test2=-0.2;
> test= 5.6 + test2;
>
> PORTB=test;
>
> while(1);
> }
>
> The value 0x45 is shown in the leds. The only change was to substitute
> the -0.2 constant by the test2 variable.
>
> Maybe I am doing something wrong. I would like some guys in the list to
> test this examples.
>
> For compiling I am using:
>
> sdcc -Wl-m -Wl-ainhx8m -mpic14 -p16f876a -o test-float3 test-float3.c
>
> This is the sdcc version:
>
> $ sdcc -v
> SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08
> 2.9.0 #5416 (Mar 22 2009) (UNIX)
>
> Thank you very much
>
> Best regards, Juan
>
>
>> br Kusti
>>
>>
>>
>>
>>
>>> From: Juan Gonzalez Gomez <[email protected]>
>>> Reply-To: <[email protected]>
>>> Date: Mon, 6 Apr 2009 03:00:07 +0300
>>> To: <[email protected]>
>>> Conversation: [Sdcc-user] pic14: floating point error
>>> Subject: [Sdcc-user] pic14: floating point error
>>>
>>> Hi,
>>>
>>> I am trying the sdcc 2.9.0 for the PIC16F876A device. I have found
>>> that the floating point operations are not working well when negative
>>> numbers are used.
>>>
>>> The following example works ok:
>>>
>>> #include <pic16f876a.h>
>>> #include <float.h>
>>>
>>> volatile float test;
>>>
>>> void main(void)
>>> {
>>> TRISB=0x00;
>>>
>>> test=1;
>>> PORTB=(unsigned char)(test+2);
>>>
>>> while(1);
>>> }
>>>
>>> There is an 8-led board connected to the port B. When this program is
>>> executed the number 3 (in binary) is shown.
>>>
>>> But if the test variable is assigned to the number -1, it does not work.
>>> The following code does not work. The number 1 should be showed, but all
>>> the leds are off
>>>
>>> #include <pic16f876a.h>
>>> #include <float.h>
>>>
>>> volatile float test;
>>>
>>> void main(void)
>>> {
>>> TRISB=0x00;
>>>
>>> test=-1;
>>> PORTB=(unsigned char)(test+2);
>>>
>>> while(1);
>>> }
>>>
>>> If the test variable is declared as int, it works. So, it seems there
>>> is a problems with negative floating points.
>>>
>>> The program is compiled like this:
>>>
>>> sdcc -Wl-m -Wl-ainhx8m -mpic14 -p16f876a -o float-error float-error.c
>>>
>>> Is this a known bug? Has anyone tested the floating point support for
>>> the pic14?
>>>
>>> Thanks
>>>
>>> Best regards, Juan
>>>
>>>
>>> --
>>> Juan Gonzalez Gomez
>>> Blog: http://www.iearobotics.com/blog/
>>> Web : http://www.iearobotics.com/juan
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Sdcc-user mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Sdcc-user mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> High Quality Requirements in a Collaborative Environment.
>> Download a free trial of Rational Requirements Composer Now!
>> http://p.sf.net/sfu/www-ibm-com
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Sdcc-user mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/sdcc-user
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
