| View previous topic :: View next topic |
| Author |
Message |
raman00084@gmail.com
Joined: 28 Jul 2014
Posts: 38
|
| floating point issue in dspic |
 Posted: Tue Apr 28, 2020 11:07 am |
 |
|
I am using dspic 33ep512mu810. My issue is if i save a floating point number in eeprom it is not saving correctly.
For example if i save float32 val=88.75 then in eeprom it is saving 88.74.
How to handle this issue ? Kindly help. |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Tue Apr 28, 2020 11:21 am |
|
|
Explain how you are saving this to EEPROM, and how you are looking
at what is saved. |
|
|
raman00084@gmail.com
Joined: 28 Jul 2014
Posts: 38
|
|
| Posted: Tue Apr 28, 2020 1:12 pm |
|
|
| Ttelmah wrote: | Explain how you are saving this to EEPROM, and how you are looking
at what is saved. |
I am seeing in 40x4 lcd display.
float data_f =99.99;
write_fram_float32(1235, data_f);
data_f = read_fram_float32(1235);
lcd_gotoxy(1, 1);
printf(lcd_putc2, "%f",data_f );
The result i am getting in lcd is 99.98 |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9096
Location: Greensville,Ontario
|
|
| Posted: Tue Apr 28, 2020 2:25 pm |
|
|
so... 99.98 vs 99.99 ??
looks fine to me as any digital number is usually +-1 of the last digit...
it could be the print function, for same reason( rounding or aproximation )
you'd have to show the 'raw' data bytes and then 'play computer' to convert into a floating point number and do the 'display' routine as well. |
|
|
gaugeguy
Joined: 05 Apr 2011
Posts: 288
|
|
| Posted: Tue Apr 28, 2020 2:56 pm |
|
|
| 99.99 cannot be represented exactly in floating point format. Unlike integer values or scaled integer values floats typically are stored with some amount of error. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Tue Apr 28, 2020 11:21 pm |
|
|
It is very important to understand that FP, does not actually ever store
a decimal number.
The fp representation stores binary numbers 'representing' the fp number.
Now a number like 0.5, can be exactly represented this way, but 0.1
can't. 0.125 can but 0.3333 can't.
Now the error should not be the size you are descibing, which is why
I queried exactly _how_ you are doing these operations.
Show the code being used in your read_fram and write_fram functions.
Test that the data does appear right first. So:
| Code: |
float data_f =99.99;
lcd_gotoxy(1, 1);
printf(lcd_putc2, "%f",data_f ); //is this right?
write_fram_float32(1235, data_f);
data_f = read_fram_float32(1235);
lcd_gotoxy(1, 2);
printf(lcd_putc2, "%f",data_f );
|
It's critical to understand that in C numbers by default are not 'rounded'.
So if you have a number like 0.1, that is actually represented as 0.099999
to the nearest representation, and you then print this using 4 digits,
you will by default see 0.0998.
If you want to give 4/5 rounding, if displaying 4 digits you need to add
0.00004999 to the number before printing. or use %g to print.....
Are you sure you are not overflowing the stack?. I've seen screwy printf
results with these chips very early on, because they use a lot of stack...
With the .LST reporting only 32locations used, I've still seen problems
until the stack is enlarged!... |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
