32k controller limit

[flounder22001]

whenever i intialize _USE_CMU_CAMERA to be able to use the camera the .hex file size goes to 60k and the controller's limit is 32k

if anyone else has had this problem and has found a way around it , it would be really nice if you caould help us.

[AIBob]

I was just wondering whose CMU cam code you are using? The official IFI code?

[whakojacko]

i never looked at the size, but ive been turning on and off that macro for testing stuff and its always loaded fine

[flounder22001]

i'm using the official default code supplied by first (or ifi)

whackjacko: can you check the size of the .hex file with the macro on and tell me what it is?

[AIBob]

To look at what is filling up your 32KB, you can just loop at the .map file....
if that is not there, then you can produce it by going to:
Project -> Build Options... -> Project :::::: <MPLINK Linker> Check "Generate map file"

[Alan Anderson]

Originally Posted by flounder22001

whenever i intialize _USE_CMU_CAMERA to be able to use the camera the .hex file size goes to 60k and the controller's limit is 32k.

The file size is not the same thing as the code size. The .hex file contains more than just the raw bits which end up in the flash memory of the controller. Look in the .map file to find out how much space the program is actually taking.

[Astronouth7303]

Originally Posted by Alan Anderson

The file size is not the same thing as the code size. The .hex file contains more than just the raw bits which end up in the flash memory of the controller. Look in the .map file to find out how much space the program is actually taking.

Indeed. It's in Intel-Hex (google for it if you really want to know). Mine is 69 KB, but the MAP file says that the code is using 72% of my program memory (or 24K).

[Don Reid]

We saw this after trying to combine the Navigation code and the camera code. I noticed that the default project settings turn off a lot of the optimizations the compiler can do, resulting in larger slower code. This may be needed for the simulator or a debugger, but without them the code was 1/2 the size.

I also saw that the largest module was vprintf (~4k). If you get rid of all printf calls, this will go away. You can sill use puts(), itoa(), ltoa() ... which are smaller.

Of course there is no substitute for going through the code and removing anything you don't need. Some of the sample code could be made smaller and faster (but probably less readable) too.

[Plloyd]

Thanks guys, this discussion is very helpful... to many more than just myself I am certain.
However, I am still confused about how we can use external memory, and the consequences of doing that (runs slower?)
Also, how do you modify the optimization settings of the project?

Thanks,
Plloyd

[Don Reid]

Originally Posted by Plloyd

Also, how do you modify the optimization settings of the project?

There is a tool on the MPLAB toolbar for the build options, or find it under
the Project menu. There is a line like this:

-D_FRC_BOARD -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-

The -O*- settings are turning off various optomizations. Remove them
to turn things back on.