CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support
Why does removing unused variable cause 'out of ROM' error ?

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
nurquhar



Joined: 05 Aug 2006
Posts: 149
Location: Redditch, UK

View user's profile Send private message Visit poster's website

Why does removing unused variable cause 'out of ROM' error ?
PostPosted: Tue Sep 25, 2007 9:50 pm     Reply with quote
I have a problem with the "out of rom" compiler error. I am using PCM3.249 for PIC16F876A.

Situation is this, I have quite a large program and when it compiles Ok it reports 71% rom usage. However it also gave me a warning that I have an unused variable in main(). A hanging chad from a bit of debugging. So as you would I deleted the redundant statement
Code:
char s[6] ;
from main() and recompiled. Wow Exclamation , it now says I am out of ROM !

If I now put the line in again it compliles fine, except for the warning about 's' being unused. If I change s[6] to be xxx[6] just to be sure the variable is not used it also compliles. If I change it to be
Code:
int wibble ;
or
Code:
boolean wobble ;
then it also compiles fine. If I have no variable then I am out of ROM !!

The compliler seems to be insisting I have a redundant varible in main(), you'd think removing code would make your app smaller right ? Question
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Sep 25, 2007 9:55 pm     Reply with quote
1. Post the pre-processor statements at the top of your program.
If you are using the CCS Wizard, these statements may be in a small .h
file that's created by the Wizard and is given in an #include statement
at the top of your main program.

2. Post the stats on the percentage of ROM and RAM used. Also post
any information on the number of bytes available in a ROM page.
Get this information from the top of the .LST file (after a successful
compile). The .LST file is in your project directory.
nurquhar



Joined: 05 Aug 2006
Posts: 149
Location: Redditch, UK

View user's profile Send private message Visit poster's website

PostPosted: Tue Sep 25, 2007 10:02 pm     Reply with quote
Code from the top of main.c. I am not compiling with ICD so the #ORG is in play.


Code:
// CPU Clock Freq
#define   FOSC   20000000
//#define   FOSC   4000000
#define OSC_DIV   4

//#define BAUDRATE   9600
//#define BAUDRATE   19200
//#define BAUDRATE   33600
#define BAUDRATE   57600
//#define BAUDRATE   115200
//#define BAUDRATE   125000
//#define BAUDRATE   250000

#define INTS_DEBUG

// Use automatice data enable
#define   AUTO_DE

#include <16F876A.H>
#device *=16


//#device ICD=TRUE

// Running in ICD mode ?
#if getenv("ICD") == 1
#define __ICD__
#endif

#ifdef __ICD__
   #error Compiled For ICD
#else
   // Use to reserve memory for Bootloader
   #ORG 0x1CC0,0x1FFF {} //for the 8k 16F876/7
#endif

// When defined cutout certain code
//#define DBGSIM

// Use PIC16F876A
#use delay(clock=FOSC)
#priority timer2
#use fast_io(A)
#use fast_io(B)
#use fast_io(C)

#fuses HS,NOWDT,NOPROTECT,BROWNOUT,PUT,NOLVP,NOCPD,NOWRT,NODEBUG

#ifdef AUTO_DE
#use rs232(baud=BAUDRATE, xmit=PIN_C6, rcv=PIN_C7, PARITY=N, BITS=8, ENABLE=PIN_B0, ERRORS)
#else
#use rs232(baud=BAUDRATE, xmit=PIN_C6, rcv=PIN_C7, PARITY=N, BITS=8, ERRORS)
#endif


#define RAND_MAX   1000

#include <stdlib.h>
#include <ctype.h>
#include <string.h>

#include "HexConvert.h"
#include "specreg.h"
#include "basetypes.h"
#define T2_PS      T2_DIV_BY_4
#include "timers.h"
#include "bootstrap.h"
#include "crc.c"
#include "eeprom.h"


// Include a Rom Unique ID
//
//#define SET_ROM_UID   0x00000001
//#include "romuid.h"

#include "AppCommands.h"

// Constant tables
//
#include "sinewave.h"


char ln[20] ;



From .LST

Code:
CCS PCM C Compiler, Version 3.249, 33800               26-Sep-07 04:46

               Filename: SysLinRGB_01.lst

               ROM used: 5620 words (69%)
                         Largest free fragment is 1216
               RAM used: 126 (34%) at main() level
                         215 (59%) worst case
               Stack:    7 worst case (6 in main + 1 for interrupts)

*
0000:  MOVLW  10
0001:  MOVWF  0A
0002:  GOTO   581
0003:  NOP
Ttelmah
Guest
PostPosted: Wed Sep 26, 2007 4:37 am     Reply with quote
Is the variable declared in 'main', or is it external (so a global variable, like the 'ln' shown at the end of the stuff you posted)?.
Potentially the latter, implies that the variable will be initialised on boot, and will therefore 'move' the physical location where the 'main' code actually positions itself fractionally.

Best Wishes
nurquhar



Joined: 05 Aug 2006
Posts: 149
Location: Redditch, UK

View user's profile Send private message Visit poster's website

PostPosted: Wed Sep 26, 2007 5:50 am     Reply with quote
The variable is the only one declared in main, ie
Code:
void main()
{
char dummy ;


From some further observations when compiling with and without the extra varible defined the size difference is as follows :

With 'dummy'
Code:
CCS PCM C Compiler, Version 3.249, 33800               26-Sep-07 11:20

               Filename: SysLinRGB_01.lst

               ROM used: 5620 words (69%)
                         Largest free fragment is 1216
               RAM used: 126 (34%) at main() level
                         215 (59%) worst case
               Stack:    7 worst case (6 in main + 1 for interrupts)

Without 'dummy'
Code:
CCS PCM C Compiler, Version 3.249, 33800               26-Sep-07 11:23

               Filename: SysLinRGB_01.lst

               ROM used: 5776 words (71%)
                         Largest free fragment is 972
               RAM used: 125 (34%) at main() level
                         215 (59%) worst case
               Stack:    7 worst case (6 in main + 1 for interrupts)


Looking in the LST file and comparing line by line there appear to be extra BCF/BSF instructions when 'dummy' is not used. I think these may be for the RAM bank switching. However I still can't my head around why I need 156 bytes more code to access 1 less variable !! Confused Is there an optimisation level 10 ?
Ttelmah
Guest
PostPosted: Wed Sep 26, 2007 7:18 am     Reply with quote
Depends whether you are using a '18' chip, or a '16'. For the 18 family, there are optimisation levels 10, and 11 on your compiler.
I'd suspect what is happening, is tied up to how ram is used. If (for instance), adding one extra variable to the main, forces memory used in some other routines, to just happen to all shift into one bank, instead of being split across two banks, then the sort of behaviour you are seeing will result. Also remember, that if you have a subroutine, used just once in 'main', then this will almost certainly default to being generated 'inline'. The same comments about bank useage, will apply to these as well.
There was quite a lot of discussion here in the past, about how quite small changes to the order in which variables are declared, can have a major effect on the code size, and efficiency. This appears to be the same behaviour, but triggered in a slightly 'unexpected' way...

Best Wishes
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group