Why 1 command uses alot of Rom?

[sorasit46]

What's wrong with this code ?

[arunb]

include files use a lot of ROM, its not un-common

[sorasit46]

How can I do?
Before use this command. My program used 83% of Rom.
When add this command, Compiler report "Out of ROM,A segment or the program is too large".
Any suggestions about how to make this command working ?
I'm closing end of project.

[andrewg]

[Ttelmah]

Spot on AddrewG.

Begin with 'one command'. This isn't. The code as posted, has first, three floating point multiplications (because B,C,D, are floating point, the multiplication will be done using FP). Then two integers are converted to FP, and two floating point additions performed (in C, if you perform arithmetic on two numbers of different 'types', the lower type is converted to the higher, and the arithmetic performed using the higher type - so here, as the multiplications have been done with FP, and this result is FP, two FP additions are now done). Then another FP multiplication. Then a Cos is performed on this. Then the ABS function, and then finally a (pointless) division by one (I'd expect the compiler will hopefully have optimised this out - divide anything by 1, and you get the number you started with.....).

So the _statement_, involves four FP multiplications, two FP additions, four FP type conversions, a Cos, and the Abs (and possibly a useless division, depending if the compiler is smart enough to remove it or not....). Not one 'command' in anybodies language. The Cos alone, will be about 10000 machine instruction times. The multiplications about 900, the division (if used), about 1500. The actual 'code size', will be a significant fraction of these counts...

The size of the code involved, will change with the processor. On the PIC16 family, even a simple int16 multiplication, has to be done 'bit by bit'. Typically just under 250 instructions. The same command on a PIC18, drops to just over 30 instructions, with the processor having a hardware 8bit multiply present.

FP maths, is bulky, and slow.

It is quite possible, to write a one line statement, using a few FP operations, that will use _all_ the memory of almost any PIC..

Now, 'arunb', slightly oversimplified. Generally, include files, use little space, _until_ their functions are actually used.
For instance, if you build a simple test project, then include math.h, and recompile, the code size does not change. However now 'use' one of the functions (say just a single Cos), the code size jumps up by 1994 instructions. A multiply uses 294 instructions, a division 394 instructions etc. etc..

Now the size does not keep growing, quite as badly as this. _Once_ the Cos function is used, another cos, uses the same function. _However_ just the act of transferring the required numbers into the temporary registers and back again, will typically take several dozen instructions, so the first Cos, might use 1994 instructions, and subsequent ones perhaps 50 instructions each. Not quite so bad....

An enormous amount depends on what you actually need to do. If you 'must' use FP maths, then you need to be aware of just how large (and slow) the code will become. However for most things, using scaled integers is often possible, and Andrewg, has given some good ideas for this approach.

Best Wishes

[SherpaDoug]

As another example of using integers instead of floating point, I once did a project using CCS to measure the hulls of large ships. I ended up doing the measurements in 24 bit integer millimeters. I could have used 32 bit integer microns. I often measure temperature in integer milli-degrees. Conversion to whole meters or degrees can be handled by the print string formatting at the very end.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[sorasit46]

I'm trial change from float to int .

[dbotkin]

Maybe a different chip would be a better choice. If you don't need the ADC, a 16F648A has twice the memory in a pin-compatible package. If you do need ADC, the 16F88 would be good, or the 16F1828/16F1829 look good (though not the same pinout). A PIC18F1320 or 18F1330 would be a good choice if you have, or are willing to buy, the compiler for it.

If you're stuck with that chip, you may need to look at other ways to make your code more efficient. I have been able to eliminate complex and ROM-consuming mathematical calculations with tables or simpler math. As with many things, there's usually an easy and inefficient way, and then there's a harder but more efficient way.

[Ttelmah]

[sorasit46]

Dbotkin suggest 16F648A .It's good choice. Thank you.

Ttelmah suggest switch to useing integer by generate 'scale integer' ?
How to do? and How I can transferring the required numbers into the temporary registers and back again ?

[Ttelmah]

Do a search on the forum.
The key is to understand that if (for example), you decided to use int32, and treat each unit, as if it was 'thousandths', you could represent numbers up to 4294967.296, with three decimal place accuracy. The compiler has the ability to printout such numbers for you (look at %w). For things like sin/cos, the quickest/code compact route, is a lookup table, combined with linear interpolation. remember since sin/cos, can not exceed '1', the scaled values can be stored in an int16. A 256 element table, then takes just 512bytes of ROM. There is a balancing 'act' between the number of elements in the table, and the interpolation needed, depending on what accuracy you actually need.
Remember also a table for one 'quadrant', can solve the entire circle, and that the same table can be used for sin and cos, by just adjusting by one quadrant.

Best Wishes

[Douglas Kennedy]

A line of code only seems to take up so much space. It is often simple like
x=0 in which case the notation x=0 takes up as much space or more than the machine instruction needed to implement it. Then there is something like cos(a) 6 chars which notate for a highly complex function. Now the machine code is sizable. One way to address this is to have the values computed elsewhere and load the results in a table. Another is a hybrid with a table of coefficients that yield rapid convergence when iterated. MPEG4 uses discrete cosine transfers often this is done with the CORDIC other times with a DSP chip. The PIC is not suited to massive calculations so it pays to trade some ROM for less math. The CORDIC uses base 2 angular rotation and was used decades ago with the earliest MCU's used in the space program. Most find float and the PIC to not be the best fit.

[sorasit46]

oh! I see.
Heart of this solution is " tables ".

thank you