Full ROM, empty RAM?

[MiniMe]

Hi,

32 KB device... Problem is out "of ROM" near 92 % (rom) and very next step stack problems, while RAM is on 14%.

Most of code is for user interface (char LCD). Many printf, ISR based and button press loop functions.

How i can clean up .. change my code so that i can balance RAM and ROM use. So far as i understand compiler is trying as hard as it can to reduce RAM usage. I might be very wrong so feel free to correct me and say your thought on subject.

I've tried changing preprocessed #OPT nr. to 11, the effect was ok but it slowed down very frequently used functions. Might be usable solution because 33% slowdown (while less than 10% reduced ROM use) is OK.

Are there tutorials on this subject. Specifically for embedded c code efficiency.


Thank you in advance !

[arunb]

Difficult to suggest a solution without looking at the relevant parts of your code.

Printfs usually take up lot of ROM. You should see the .TRE file listing and see which function is taking up most of the ROM.

[Ttelmah]

The use of RAM in the main code, is completely dependent on what variables you have declared.
The compiler uses just the RAM it needs, with no ability to trade RAM for ROM.
The 'exception' to this, is some of the include libraries.
For example, the USB library, has a define option at the start, to tell the compiler to optimise to use less RAM, or less ROM. Setting 'USB_OPT_FOR_ROM' to 'TRUE' before loading the USB libraries, will tell the compiler to change some of the definitions used to save ROM. This is the default behaviour.

On ROM, the key thing is to identify repeated subroutines, and ensure that they are flagged as 'separate'. By default, the compiler will always 'inline' relatively small code routines (since this is _faster_), and this will result in extra ROM being used.
Similarly, 'encapsulate' routines where the same job is done. If you print different numbers using the same printf format in several places, generate your own routine to call printf, with the required format, declare this as separate, and use this instead. This can make an _enormous_ difference....
Generally, the compiler optimises for _speed_. To optimise for ROM usage, requires _you_ to think about how the ROM is used.

Best Wishes

[SherpaDoug]

Floating point math takes a lot of ROM and is slow. Don't use floats unless you REALLY need them.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[kender]

Had a similar problem recently, started a thread here and got useful advice. Here's the thread:
http://www.ccsinfo.com/forum/viewtopic.php?t=43389
_________________
Read the label, before opening a can of worms.

[MiniMe]

arunb, Ttelmah, SherpaDoug, Kender - Thank you !

You replies been much help to me.

Briefly tips are:

-RAM and ROM percentage relation is based on coding.
--In some cases to do a task, ROM use might be compensated by using more ROM or otherwise i guess. Example is USB library where choice is present.

-Avoid floating point operation because it takes a lot of RAM and it is slow.
--Find some clever way to do use integer math instead. Quite often there
is one.

-Code re-factoring: Subroutines. Reusing same code. Putting identical code in separate function and calling it.
--For example Similarly, 'encapsulate' routines where the same job is done. If you print different numbers using the same printf format in several places, generate your own routine to call printf, with the required format, declare this as separate, and use this instead. This can make an _enormous_ difference....

-Generally, the compiler optimises for _speed_. To optimise for ROM usage, requires _you_ to think about how the ROM is used.

-If there are a lot strings compressing them might reduce ROM use.
--Maybe Huffman coding, maybe packing them to 6 bit chars (thus saving 25%)

- Changing optimization level might reduce ROM use but it will slow down some code. Changing optimization level as last step might resolve in execution errors.