Reduce Footprint of Binary

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I'm using AVR-GCC 20010228bz and develop a program for a AT90S8515.

I'm encountering the problem that the 8kB Flash is not big enough for my program.

What can I do to reduce the size of my executable (OK, I could leave some things out, but thats not a solution ;-)
Or am I obliged to switch to an other controller? This is mostly a cost-issue, because I have to restart developping my hardware (or does an other controller with the same pinout exist with more Flash?)

Thanks for any hints on what I could do!

Elmar

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Mega 163 series is pin compatible with the 8535 and very close to the 8515. It would take minimal re-design to use it instead and it has double the FLASH.

A quick search on findchips.com shows them to be available.

However for GCC you can try messing with the optimization flags in the compiler. O2, O3, and Os will give different results.

Also, 16-bit variables take a lot more code space to work with. If you can convert to 8-bit you'll save a lot especially if you have significant math calculations. Also, use as many temporary vs global variables as you can. These are stored in regsters vs being permanently allocated in SRAM. Register to register calculations are more compact than SRAM-based variable calculations.

There are also storage class directives (register, volotile, etc.) you can issue that will affect things. I'm not clear enough on them to comment though.

Chris

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the mega 161 is a pin-for-pin replacement for the 8515 with double the flash and sram. I don't know if they are generally available.

In my experience the various optimization levels in gcc don't do much. The big wins are, as stated previously, use automatics and keep word size as small as practical.

Other ideas: use structures for data and use pointers to access the data (avr is particularly efficient in pointer dereferencing); pass pointers to subroutines. Simple call and return to a subroutine with one pointer is pretty cheap, so you can pull out even two or three lines of code into a subroutine and win if it is called more than twice. Generate assembly listings (-S) and look at the code - that will give you hints on how to structure your C code, etc. Put all your constants (like text strings) into flash. Look into writing your low level stuff in assembly - you can pull all sorts of tricks that the C compiler can't. Stay away from any complicated C libraries (float, printf) Look at your load map for large modules and rethink them - or don't use them if they are from the C libraries.

admin's test signature