Need help on #separate

[HHoward]

I am working on big project with a few c files included in main.c together. For all published functions, I have to declare prototype for caller located in separated file to see.

To over come "Not enough ROM" problem, I have to use #separate to divide the code too.

Here is my problem, with #separate, error reports:

"Function definition different from previous definition"

There two ways to eliminate the error:
1. Do not using prototype
2. Do not using #separate

Unfortunately, I must use #separate because the limitation of ROM. the first solution could work if I put all the code into one file and make sure caller is always behind the function in the file. That is very difficult arrangement.

I am looking for third solution. Thanks

Howard
Her is my example code , I am using PCWH:




[/code]
#include <18F442.h> // could be any device
#use delay(clock=80000000)
#use rs232(baud=19200, xmit=PIN_C6, rcv=PIN_C7)

// comment out prototype, no error
void The_first_func(void);
void The_second_func(void);
void The_third_func (void);


#separate
void The_first_func( )
{
printf("1\n\r");
}

#separate
void The_second_func( )
{
printf("\t2!\n\r");
}

#separate
void The_third_func ( )
{
printf("\t\t3\n\r");
}


void main ( )
{
The_first_func( );
The_second_func( );
The_third_func ( );

}
[code]

[PCM programmer]

[HHoward]

It Works. I thought I did that way before. Somehow, I messed up.

Thanks for help and quick response.

[jfix]

when I put a #separate in front of the protype I get back to the Out of ROM error. Any hints?

[C Turner]

Not having any details of your code, I can't be sure if this will help, but I've noticed that if I am starting to run out of RAM, adding just one more RAM variable will sometimes cause the "Not enough ROM" problem to show up.

As near as I can figure, when near capacity, the RAM organization suddenly gets rather kludgy and the compiler suddenly piles on the bank switching and/or "alternative" (and more complex) array indexing code suddenly appears. On a recent 16F project, I noticed that the "threshold" appeared to be at about 75-80% of RAM: Defining just one more byte of RAM would suddenly cause the code to bloat and cause the "Not enough ROM" message. (It appears that you may be using a 18F series - and this may simply be a non-issue.)

To maximize RAM efficiency, I defined the largest RAM usage first (arrays, int32's etc.) and then ended up with the "#bit" variables last. I was so short on RAM that I even used #locate to put a few variables into unused hardware registers.

Another killer is lookup tables. Being that this application had a lot of "canned" LCD screens, I set up a number of very large lookup tables in which all canned LCD screens were in just one large array rather than several smaller ones, and I used the MSB to indicate the last byte of the particular entry in the lookup table. #defines were used to provide handy indices to the table for the LCD lookup functions. This was quite a pain as each entry into the table had to be manually calculated, but once it was set up, it was no longer much of a problem. With newer 18F parts, it's pretty easy to put two bytes into one program word and use the "read program eeprom" function rather than use a standard array (with the "retlw" table or similar) in which storage may not be nearly as efficient.

Some of the CCS functions are pretty terrible in how they get compiled into code. A good example of this are the "read_eeprom()" and "write_eeprom()" functions - and especially the latter. For some reason, the compiler will put the entire chunk of assembly into the code when these are used, and if you call "write_eeprom()" frequently, it can chew up space PDQ. The easy workaround to this would be to create a function, say, "wrt_eeprom()" that simply calls "write_eeprom()" and solves the problem: A few other CCS functions do this as well.

Finally, sometimes it helps just to move functions around within the source code: With version 3, this seemed to make quite a difference whether a particular function was near the beginning, or near the end, as the compiler didn't seem to be all that great about trying to figure out what should go into which bank of EEPROM. Again, with the 18F parts, this may not be as much of an issue.

I take it that you have already done some staring at the .LST to figure out what the biggest hog is, as well as the tree and statistics files: Those are excellent resources to help figure out what it is that's slurping up program memory.

CT