PDA

View Full Version : did we mention FP Math?



mslaney
- 16th February 2005, 16:55
I would gladly take the money I saved for Proton Plus and purchase PBP Pro.

Is FP math in the works? When is the next version due to come out?

mister_e
- 16th February 2005, 18:06
For Floating point math... look here (http://www.melabs.com/resources/fp.htm)

upgrade, new version or else : [email protected]

mslaney
- 17th February 2005, 18:38
I'm using 2.45. Don't get me wrong, it's a great compiler! However, it'd be great to type something like this:

myfloat = (2.45 * 299.95)
myfloat = (myfloat / 2.46)

and that's it. No includes, no background conversions etc...

Think of how much easier it would be to convert C to F, read a pot, measure time etc...


I was just kidding about Proton - kind of a low blow, sorry :-)

mister_e
- 17th February 2005, 18:59
well in some case it's more easy to do them in integer...

2.45 * 1.45 will become (245 * 145)

and then you do the the rest with DIG and DEC to display as you want.

something like LCDOUT $fe,1, DEC DIG 1 MyVar,".",Myvar DEC4

but i have to agree that it can be usefull to have built-in floating point maths... in some case

as built in real SIN,COS,LOG or many else other.

mytekcontrols
- 16th June 2005, 20:40
Hi Mike,

Yes I too would love to see this as a built-in option for PBP, but only if it can be done in a more memory efficient way than using Microchip's FP Routines. Speaking of which I just tried to implement this and was surprised out how much memory it took on my 18F252 to include these routines (3000 bytes for 24Bit Math and 4194 bytes for 32Bit Math). I don't really think I have the room to spare on my current project, so I'll have to do it another way, which is unfortunate.

Bruce
- 24th June 2005, 01:43
Floating point with pretty much any PIC compiler just isn't very efficient.
It's handy to have, but I try to avoid using fp unless it's just absolutely
necessary.

CCS C compiler with 16F876a target.


void main()
{
float a;

a = 2.45 * 299.95;
a /= 2.46;
printf("a = %3.3f\r\n",a);
} /* returns a = 298.730 */
ROM used: 670 words (8%)
Largest free fragment is 2048
RAM used: 11 (6%) at main() level
29 (17%) worst case

==========

Proton BASIC compiler, same target;


Dim a As Float

a = 2.45 * 299.95;
a = a / 2.46;
HRSOut "a = ",Dec a,13,10
' returns a = 298.730
Eats-up 487 words 5.94% code space, 47 bytes 12.5% RAM.

C is a little more efficient at managing RAM, but they both chew up a gob
of resources even for simple fp calculations.

If you move up to the 18F series, it's a lot more bearable, but might still be
a challenge squeezing a bunch of fp calcs in there.

mytekcontrols
- 25th June 2005, 01:18
C is a little more efficient at managing RAM, but they both chew up a gob
of resources even for simple fp calculations.

If you move up to the 18F series, it's a lot more bearable, but might still be
a challenge squeezing a bunch of fp calcs in there.


I agree with you Bruce, but as you said, the 18F series would be a better fit for floating point. Especially if you used either the 18F252 or 18F452, which have 1536 bytes of ram available (which is nothing to sneeze about). It would be nice if PBP would have floating point available for at least these particular processors.

As always, thanks again for your valuable insight.

crematory
- 29th July 2005, 17:35
Hello

I agree with all you guys :)

Its the matter of, Do I really need floating point.

I have written a code to control PGA2311 and view the volume reading on LCD. At first place I was very sad, when I looked to the datasheets, the formula to calculate the decible value was a hell:

dB = 31.5 - ( 0.5 * ( 255- vol ) )

I thought the only solution was the floating point, any way, thanks to a friend who told me to use * 10 and * 100 approach :

dB_VALUE : ' Calculations for decible equivalent values
IF ( VOL_L >= 192 ) Then
DB_SIGN = 1
DB = 3150 - ( 5 * ( 2550 - ( vol_l * 10 ) ) )
DB10 = DB / 100
dB1 = DB // 100
DB1 = DB1 / 10
Else
DB_SIGN = 0
dB = ( 5 * ( 2550 - ( vol_l * 10 ) ) ) - 3150
DB10 = DB / 100
dB1 = DB // 100
DB1 = DB1 / 10
EndIF
Return

dB_LCD : ' Show volume on the LCD
FLAG = 1
if ( db10 == 0 ) AND ( DB1 == 0 ) THEN
LCDOut I, clr, " Volume ", DEC DB10, " dB"', DEC VOL_L
FLAG = 0
ENDIF
IF ( flag == 1 ) and ( DB_SIGN == 1 ) Then
LCDOut I, clr, " Volume ", DEC DB10, ".", DEC DB1, " dB"', DEC VOL_L
ENDIF
IF ( flag == 1 ) and ( DB_SIGN == 0 ) Then
LCDOut I, clr, " Volume -", DEC DB10, ".", DEC DB1, " dB"', DEC VOL_L
ENDIF
Return



The compiled code was 970.


When I used PICBasic Plus, and used floating pint stuff, the code was 1680 words. I now really know the Pros and Cons of floating point stuff, so, as an advice, don't ever use it, unless you badly need it :)

See ya

rcbandwidth
- 18th September 2005, 18:50
Hi:Would you have some code to share regarding the PGA2311 chip,I would like to try to experiment with this device.I just purchased picBasic pro.

Thanks Bob C.

BertMan
- 23rd September 2005, 22:32
Hi:Would you have some code to share regarding the PGA2311 chip,I would like to try to experiment with this device.I just purchased picBasic pro.

Thanks Bob C.

Great first post location choice there Bob. Back to the subject....You also have to keep in mind that some devices are preinterfaced with float32 out, which means you have to come up with some kind of solution if you want to use a pic.