Program error - "can not fit the section"

[miketwalker]

For some reason I've suddenly started getting an error saying:

Error - section '.code_adcread.o' can not fit the section.

When I comment a bit of code out, it will build again though. When I check my memory map, I'm only using 86% of the memory... so why is it building when I comment some code out (and it isnt too much I have to comment out) yet I still seem to have a reasonable bit of memory to work with?

-Mike

[AIBob]

It may be longer than it appears to be.
You may have declared thing that you are not using, included excess things, and some other things, I recommend that you check over the code again, you may notice somthing you did on accident.

[Dave Flowerday]

I'm only using 86% of the memory... so why is it building when I comment some code out (and it isnt too much I have to comment out) yet I still seem to have a reasonable bit of memory to work with?
Microchip's C compiler has a limit on the amount of space that any one object file can consume (yes, it seems dumb to me too), so this is probably why you're seeing the error. Try moving some functionality from that file (probably adcread.c?) to another file instead.

[Mark McLeod]

I found the Program Space is max'ed out at 90% of total, rather than the 100% you naturally expect.

[miketwalker]

It seems like their is overall very little space for coding. I removed most of the code in the default routines, and I haven't put too much code in for my positioning system, yet it's taking up most of the memory. It's very weird, I just can't see how I'd be taking up all of the memory with my code, unless there in fact is very very little programming space on these controllers.

I'll look into the limit of space with the single object file, I have my calibration/sensors/positioning calculations all in one file so perhaps the problem lies in there... however the user_camera.c file seems to use more space then my thing, which makes me wonder. Oh well, thanks for the ideas! I'll try playing around with it some more.

[Dave Flowerday]

It seems like their is overall very little space for coding.
I agree. 32K was plenty for remote-control robots, but now they're asking us to do a lot of autonomous work which can be quite a bit more complicated to code. Honestly, I'm not sure how some teams even manage to make it work! We've offloaded a good percentage of stuff to our custom circuit and we're still running dangerously close to the limit on our RC. The last few days we've had to put a lot of effort into optimization, mainly by looking at the generated assembly file (.lst) and looking for any lines of C that generated too much assembly and working on optimizing them. We're also ready to move back to our stripped-down printf library that we used last year, and to turn back on most of the compiler optimization if needed to gain some extra space. That's something you could look into as well - unfortunately I'm not sure where the setting is in MPLAB since we run it all command-line with makefiles, but somewhere in there is a bunch of flags like this:
-p=18F8520 -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa- -nw=2066
You could look into removing some of those options (they turn off individual compiler optimizations) to free up some space, but be aware that it could introduce problems with your code (by exposing bugs that were hidden before without optimization, etc). If you're just playing around a good one to try removing is (-Ou-) as that turns off the "dead code" removal - if that optimization is on then the compiler will remove any code which isn't called by anyone (which should be a fairly safe optimization).

[Chris_Elston]

I agree. 32K was plenty for remote-control robots, but now they're asking us to do a lot of autonomous work which can be quite a bit more complicated to code. Honestly, I'm not sure how some teams even manage to make it work!


Oh my goodness, don't even get me started. Our team is literally BALD...everytime we code it we run out of space...very sad...

[AIBob]

I agree. 32K was plenty for remote-control robots, but now they're asking us to do a lot of autonomous work which can be quite a bit more complicated to code. Honestly, I'm not sure how some teams even manage to make it work! What my team did is just get rid of all the stuff in the default code that we do not use, and the FRC does not require; for instance the print functions last year were too big, so Mr. McLeod made special print functions that were much smaller and we used those.

[TechnocratiK]

Using the compiler optimizations helps a bunch. I haven't had the time to prove this, but I don't think the compiler treats floating point operations as functions. What I noticed was that changing my code from floating point operations to integer operations made a very big difference. In fact, it let me fit Kevin's camera code in no prob (not to mention made it run a hell of a lot faster). I wonder if creating and using a function like:

float fmul(float x, float y) {
return (x * y);
}

would actually save code space...
Well, it would, if one didn't enable procedural abstraction, which does exactly this: treat operations as functions. A "-Opa-" on your command line signifies that you have this disabled, which can make a pretty big difference.

One big advantage to removing the debug options is that it cuts out the extra functions in the math library that one would never use, like asinh.

[Don Reid]

We got this error today after adding several autonomous scripts in commads.h.
The way that code is set up, it creates a large variable command_list in RAM
and also specifies that it be initialize which uses ROM space.

The processor we have has much less RAM space that ROM!

You don't need that data as a read/write variable, it will never change.

So we found that it could be declared like this:

rom struct commands comand_list[]....
^^

The "rom" tells the compiler to just put the data into ROM and not use RAM space. Be sure to change the declaration in robots.h and the defenition in commands.h to match.