Out of ROM, A segment or the program is too large

Emil · Guest

Hi!
When I compile the compiler says that the program is too large but I know that it's not because I have counted the size of the functions and know that it will fit in the ROM. Now to the problem..I'm using a bootloader and the bootloader can not be changed. This bootloader do not write to some addresses witch is wrong so I have to keep the compiler from placing code in that area. There is free space in the segments but still the compiler trys to place code in the forbidden area or something. Here is the err file

As you can see there is space left in the segments but how can I tell the compiler to place @DIV88 in some segment that is free? There is plenty of room for @DIV88 in Seg 01800-01FFF why don't the compiler try to put it there?
Using CCS version 3.214 and a PIC 16F877A

//EMP

steve.booth · Joined: 18 Oct 2004 Posts: 7

I have seen this before, quite common really.
The problem is that the CCS compiler generates 'one big file' when you compile your code. If you know the hardware inside your PIC, e.g. say a pic16f876, although you have 8k ROM, you actually have 4 x 2k ROM, and your code (specifically a single function) will not span across the ROM memory pages. What you need to do is reduce the size of your function(s), (main doesn't count onviously). This can be done by splitting off functions specifically into subroutine calls rather than in-line , use the #SEPARATE directive infront of the function ( and it's prototype )

This will allow the compiler to fit the code mode efficiently.
_________________
Steve

steve.booth · Joined: 18 Oct 2004 Posts: 7

I have seen this before, quite common really.
The problem is that the CCS compiler generates 'one big file' when you compile your code. If you know the hardware inside your PIC, e.g. say a pic16f876, although you have 8k ROM, you actually have 4 x 2k ROM, and your code (specifically a single function) will not span across the ROM memory pages. What you need to do is reduce the size of your function(s), (main doesn't count onviously). This can be done by splitting off functions specifically into subroutine calls rather than in-line , use the #SEPARATE directive infront of the function ( and it's prototype )

This will allow the compiler to fit the code mode efficiently.
_________________
Steve

steve.booth · Joined: 18 Oct 2004 Posts: 7

I have seen this before, quite common really.
The problem is that the CCS compiler generates 'one big file' when you compile your code. If you know the hardware inside your PIC, e.g. say a pic16f876, although you have 8k ROM, you actually have 4 x 2k ROM, and your code (specifically a single function) will not span across the ROM memory pages. What you need to do is reduce the size of your function(s), (main doesn't count onviously). This can be done by splitting off functions specifically into subroutine calls rather than in-line , use the #SEPARATE directive infront of the function ( and it's prototype )

This will allow the compiler to fit the code mode efficiently.
_________________
Steve

steve.booth · Joined: 18 Oct 2004 Posts: 7

I have seen this before, quite common really.
The problem is that the CCS compiler generates 'one big file' when you compile your code. If you know the hardware inside your PIC, e.g. say a pic16f876, although you have 8k ROM, you actually have 4 x 2k ROM, and your code (specifically a single function) will not span across the ROM memory pages. What you need to do is reduce the size of your function(s), (main doesn't count onviously). This can be done by splitting off functions specifically into subroutine calls rather than in-line , use the #SEPARATE directive infront of the function ( and it's prototype )

This will allow the compiler to fit the code mode efficiently.
_________________
Steve

treitmey · Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA

Steve, They have many brands of de-caffeinated coffee that are very tasty.

Mark · Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA

There is also the option to delete or at least edit those multiple posts Smile

Guest · Posted: Tue Apr 19, 2005 10:58 am

I have seen this before, quite common really.
The problem is that the CCS compiler generates 'one big file' when you compile your code. If you know the hardware inside your PIC, e.g. say a pic16f876, although you have 8k ROM, you actually have 4 x 2k ROM, and your code (specifically a single function) will not span across the ROM memory pages. What you need to do is reduce the size of your function(s), (main doesn't count onviously). This can be done by splitting off functions specifically into subroutine calls rather than in-line , use the #SEPARATE directive infront of the function ( and it's prototype )

This will allow the compiler to fit the code mode efficiently.

Guest · Posted: Tue Apr 19, 2005 10:58 am

I have seen this before, quite common really.
The problem is that the CCS compiler generates 'one big file' when you compile your code. If you know the hardware inside your PIC, e.g. say a pic16f876, although you have 8k ROM, you actually have 4 x 2k ROM, and your code (specifically a single function) will not span across the ROM memory pages. What you need to do is reduce the size of your function(s), (main doesn't count onviously). This can be done by splitting off functions specifically into subroutine calls rather than in-line , use the #SEPARATE directive infront of the function ( and it's prototype )

This will allow the compiler to fit the code mode efficiently.

DragonPIC · Joined: 11 Nov 2003 Posts: 118

feeling like a broken record?
_________________
-Matt