Strange SE Limitation

NoSmoke · Post by **NoSmoke** » Fri Jan 15, 2010 3:51 am

I have SwordFishSE and have recently tried the FloatToStr function. Even a nominal program with that instruction gives:

"Program variable allocation exceeds Swordfish Special Edition (SE) maximum"

My example program is:

..........
Device=18f4520
Clock=8

Include "convert.bas"
dim zz as string, z as float

zz=FloatToStr(z,2)
...........

Does FloatToStr suck up most or all of the allowed 256 RAM locations or are there other undocumented SE limitation(s)?

TIA for any enlightenment........

gramo · Post by **gramo** » Fri Jan 15, 2010 6:02 am

The FloatToStr function in the system library "convert.bas" will exceed the free version limitations, if you want an alternative then try using the FloatToStrSE module found in the User Wiki http://www.sfcompiler.co.uk/wiki/pmwiki ... oatToStrSE (written by Florin Medrea)

gramo · Post by **gramo** » Fri Jan 15, 2010 6:05 am

Not that floats are a good idea anyway - scaled integer maths is by far a better choice for 99% of applications

NoSmoke · Post by **NoSmoke** » Sat Jan 16, 2010 2:47 am

gramo wrote:The FloatToStr function in the system library "convert.bas" will exceed the free version limitations, if you want an alternative then try using the FloatToStrSE module found in the User Wiki http://www.sfcompiler.co.uk/wiki/pmwiki ... oatToStrSE (written by Florin Medrea)

OK & thanks. Am still wondering though why FloatToStr exceeds the limits (I understand the limit is 256 RAM location usage). I don't know how many RAM locations FloatToStr uses but I would guess not that many. Are there any other limitations such as program memory usage (or some other)?

I'd like to try all that stuff out b/f buying the complete version.......

NoSmoke · Post by **NoSmoke** » Sat Jan 16, 2010 2:52 am

gramo wrote:Not that floats are a good idea anyway - scaled integer maths is by far a better choice for 99% of applications

I can appreciate why scaled integer math would run faster and take less storage but why not use flt pt if storage and sufficient cycles are available?

Also, how to display a flt pt value? Do all calcs in integer and convert the result to flt pt at the end?

Francis · Post by **Francis** » Sat Jan 16, 2010 11:11 am

I think that they mean you have exceeded the total programme space allowed for the Lite (assessment) version (?). Not necessarily exceeded RAM locations (code dependent) though float functions do take a lot. I've certainly had headaches with 12/1320 and Float and had to use a more manual approach to the arithmetic.

gramo · Post by **gramo** » Sat Jan 16, 2010 11:14 am

I can appreciate why scaled integer math would run faster and take less storage but why not use flt pt if storage and sufficient cycles are available?

From my POV - Scaled integer maths is white hat programming when considering the devices in use. Becoming familiar with the approach will allow code to easily be transposed into larger programs.

Also, how to display a flt pt value? Do all calcs in integer and convert the result to flt pt at the end?

There are any number of methods, though a quick and easy way to display a number is to use the Digit function from the utils.bas library

It also pretty easy to make a function that returns the converted number into a string.

gramo · Post by **gramo** » Sat Jan 16, 2010 11:28 am

Are there any other limitations such as program memory usage (or some other)?

I'd like to try all that stuff out b/f buying the complete version.......

Swordfish SE only has two limitations from what I understand;

1) 200 byte RAM limitation
2) No USB support

From there, the rest of the program is free to trial. The FloatToStr function is extremely RAM hungry and will exceed the 200 byte RAM limitation if used.

All that said, it is quite hard to reach 200 bytes of RAM for *normal* trial type programs. Play around with the structured/modular approach SF offers, it will soon become apparent just how far ahead the compiler is.

octal · Post by **octal** » Sat Jan 16, 2010 6:26 pm

gramo wrote:...

1) 200 byte RAM limitation

it's 256 since more than one year Gramo. So for chips like 18F1320 or 18F1220 that have exactly 256 Bytes of ram, it's like if you are working with full version of SF.
SF is the only compiler I'm aware of that has NO code (flash) generation limit in its demo version.

Regards

NoSmoke · Post by **NoSmoke** » Sun Jan 17, 2010 8:29 pm

gramo wrote:
I can appreciate why scaled integer math would run faster and take less storage but why not use flt pt if storage and sufficient cycles are available?
From my POV - Scaled integer maths is white hat programming when considering the devices in use. Becoming familiar with the approach will allow code to easily be transposed into larger programs.

Also, how to display a flt pt value? Do all calcs in integer and convert the result to flt pt at the end?
There are any number of methods, though a quick and easy way to display a number is to use the Digit function from the utils.bas library

It also pretty easy to make a function that returns the converted number into a string.

Upon further reflection and, looking at some programming examples, I can see the virtues of scaled integer calcs. For these small devices, it does look like the best way to go alright. Your assistance is appreciated......