looking for tips for reducing ROM footprint

[kender]

Colleagues,

My project was evolving for years, and now I’m out of program memory. I’m using 18F4620, which has the most Flash in its line. Are there any CCS-specific tricks that can free-up some code memory?

I’m sure, this subject was discussed previously on the forum. But I couldn’t find those threads.

Any suggestion, insight, reference is appreciated!

- Nick
_________________
Read the label, before opening a can of worms.

[collink]

[PCM programmer]

Look at the ASM code in the .LST file. Look for routines that use a lot of
ROM compared to what they do. The functions may have features that
you don't use and yet it's in the source code, so it gets compiled and it
wastes ROM. Example: Several different radixes may be supported
for a string to integer conversion routine (such as hex, decimal, octal, etc)
but you only need decimal. You could make your own version of the
routine and cut out all the unnecessary source code.

You may be using built-in functions that are replicated with inline code for
each call, such as write_eeprom(). This is very wasteful, but you can
fix this compiler behavior by adding a "wrapper" function to write to
an eeprom location, and then call the wrapper instead. Look for ASM
routines that are replicated over and over again in the .LST file.

You may be doing ROM tables inefficiently. For example, #rom has the
option of using an 'int8' qualifier. This allows you to pack 2-bytes per
ROM word, instead of just one.

Floating point math eats ROM. Try to avoid using functions in math.h.
Find some clever way to do use integer math instead. Quite often there
is one.

I think the most important thing is to review the .LST file and see where
the problems are. If you're using math.h routines, it will be obvious that
it uses 100's and 100's of ROM words, and something must be done about it.

[andrewg]

I've recently been tinkering with the CCS MMC/SD/FAT library code, and found that I could shave 1K off the code. What they are doing is passing structure pointers into functions, then dereferencing using the -> operator. That takes a relatively large amount of code. The fix is to copy the structure to a local copy at the start of the function, use the . operator instead, and copy the local copy back at the end of the function. One memorable function started out at 422 words and ended up 192 words. Watch out for the extra RAM the local copies take up, though.
_________________
Andrew

[kender]

Gentlemen, thank you for the suggestions. I will try your approaches, and I will keep you posted.

I've noticed that seemingly simple* writing to structures takes a lot of instructions. I wonder if there's a way to improve that. For example:

[PCM programmer]

[EdWaugh]

Hi all,

Interesting discussion here and some good suggestions. I am having a similar problem and by using PCM Programmer's encapsulating floating point math as functions I have managed to save some space. Does anyone have any tips for identifying functions that are appearing very often in the hex so these can also be encapsulated?
I also had another idea relating to kender's structure problem. I typically do this kind of access to lots of items in the same structure so be calculating the ptr first you save space by doing it only once (perhaps this is what PCM Programmer meant). You start with this:

[collink]