![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
Guest
|
RAM issue |
Posted: Mon Aug 25, 2008 1:25 pm |
|
|
First, some info
Code: | #include <18F6627.h>
#device ADC=8 ICD=TRUE
#use delay(clock=7372800,RESTART_WDT)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7,ERRORS,RESTART_WDT)
#fuses HS,WDT16384,NOBROWNOUT,BORV27,PROTECT,NODEBUG //WDT set for 65.536s
#zero_ram |
compiler version 4.078
Problem
I have a large program which is currently sitting at:
memory usage: ROM=87% RAM=61%-87%
In this file are a .c and .h file that comprise the functionality of a very specific part of my hardware. I have wrapped the '#include' tags for these two files as well as all calls to these files in '#if Flag == 1' wrappers so that I can completely remove the functionality. Once I do this I get:
Not enough RAM for all variables.
If I comment out the wrapper around the '#include file.h' declaration meaning that only the header file will be included in the compilation, it compiles just fine and I once again get:
memory usage: ROM=75% RAM=60%-87%
If I then reenable that wrapper, thus cutting out the .h file as well as .c and all extra calls, and also do some stripping of the other code I can get:
memory usage: ROM:61% RAM=44%-98%
In this last case the .c and .h file and all the associated calls have been removed as well as a function which was fairly heavy on RAM usage.
Anyone seen this before? |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Aug 25, 2008 1:57 pm |
|
|
Are you using the CCS IDE or MPLAB ?
If you're using the CCS IDE, are you using "Multiple compilation units" ? |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Mon Aug 25, 2008 2:01 pm |
|
|
How is 'Flag' defined?.
The preprocessor, only works with it's own definitions. You can't use C variables. What you describe, can happen if you do, or the #endif is not present. It is usually safer to use the #ifdef test first, so that no maths comparison is done, if the value is not defined.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
RAM issues |
Posted: Mon Aug 25, 2008 3:20 pm |
|
|
I am using the CCS IDE, single compilation unit
as to the flag questions, I am going to:
Options->Project Options->Global Defines:
then I enter the name under identifier and give it a value of 0 or 1
An example would be for a flag call GPS_DEBUG
#if GPS_DEBUG == 1
#ENDIF |
|
![](templates/subSilver/images/spacer.gif) |
crystal_lattice
Joined: 13 Jun 2006 Posts: 164
|
|
Posted: Tue Aug 26, 2008 5:13 am |
|
|
I would add to what Ttelmah has said, I use the #define GPS_Debug at the top of my code and comment it out as needed, then in my main code I use a approach as shown below. This has the benifit, as outlined by Ttelmah, that you don't need any "specific" type of variable and no math comparison is performed
Code: |
#Define GPS_Debug
#ifdef GPS_Debug
printf("GPS String: %s",buff);
#endif
|
|
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
OK |
Posted: Tue Aug 26, 2008 11:48 am |
|
|
I see the merrit in that approach to using defines but that will most likely not address my problem. |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
changes made |
Posted: Tue Aug 26, 2008 1:29 pm |
|
|
I made the change to #ifdef declarations throughout. Problem still persists of course, but you are both right, using the #ifdef is the cleaner way to go. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Tue Aug 26, 2008 2:46 pm |
|
|
OK.
The reason I raised it in particular, is I have seen the numeric version go screwy, if the value is not defined.
One thought. In the 'project options' box, make sure that your include files are _not_ included. Otherwise the compiler will include them anyway, and if they then appear in a different location, with routines now 'outside' the main code, this will result in more RAM being used.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
revelations and what not |
Posted: Tue Aug 26, 2008 4:13 pm |
|
|
I did notice what you were talking about the code going "screwy", after I made the recommended changes when the flags were not defined.
I have stripped out a ton of code and isolated the issue, I think, to a buffer. Its screwy too.
when I set it to a value of 0x10 I can compile and it works just fine resulting in:
RAM=33% - 71%
when set to 0x100 it compile to
RAM=39%-73%
when set to 0x119 it compiles to
RAM=40%-85%
and finally when set to 0x120 I no longer have enough RAM
What the heck!
And lastly if I put back all the code as previously discussed, the code that should be removed by a compiler tag and set the buffer to 0x200 it compiles just fine.
RAM=62%-88%
I emplor the almighty PICC gods to save me from my own ignorance! Please.
Thanks for all the responses thus far, I am greatful for your time and effort. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Aug 26, 2008 4:53 pm |
|
|
If you can strip down the code to a tiny little program and post it
(a complete program), then we probably find the problem. |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
hmmm |
Posted: Tue Aug 26, 2008 5:33 pm |
|
|
the program is rather large at about 20000 lines so it would be a bit hard to strip down. I have, as a last test, taken the version of code that has been stripped down, set my buffer size to 0x200 and included the header file only for the removed code and it compiles fine.
RAM: 62%-88%
There are no functions, or variables or anything from that file actually used in the code.
I then start striping functions away -> no change
then variables and I get the following pattern as I remove then in chunks:
RAM: 60%-86%
RAM: 58%-84%
RAM: 56%-82%
At this point I am left with the following code in the header file:
Code: |
#define BLOCK_SIZE 0x10
typedef struct{
char Display[BLOCK_SIZE];
} TMenuStrings;
TMenuStrings MenuStrings[14];
|
Resulting in RAM=51% - 85%
change the code to
Code: |
#define BLOCK_SIZE 0x10
typedef struct{
char Display[BLOCK_SIZE];
} TMenuStrings;
TMenuStrings MenuStrings[18];
|
results in RAM=53% - 80%
change it to
Code: |
#define BLOCK_SIZE 0x10
typedef struct{
char Display[BLOCK_SIZE];
} TMenuStrings;
TMenuStrings MenuStrings[8];
|
Resulting in RAM=49% - 98%
This must be an issue with how the RAM is being organized, I can't think of another reason for this type of behavior. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Wed Aug 27, 2008 3:03 am |
|
|
Your array in the first case, is 14*16 bytes in size - 224 bytes.
In the second, 18*16 - 288 bytes, and in the third, 128 bytes. You don't show whether this is being declared inside a function, as a 'local' variable, or as a 'global' variable?. What you show, is typical in the first case. For local variables, the compiler 're-uses' RAM, that is being used in other routines, if it has to. However if it doesn't have to, will instead place the variable as if it was global, and get a higher 'peak' usage as a result. It would appear that this is what is happening in the third case. The compiler is simply deciding, that since it has got enough space, without such re-use, why not use more memory?. In the first and third cases, there is obviously not quite enough free memory to allow this, so the compiler switches to the 're-use' strategy.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
the code |
Posted: Wed Aug 27, 2008 10:08 am |
|
|
The code submitted in my last post was the contents of a .h file that was added to the main compilation file via a #include instruction. This is a global declaration. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Wed Aug 27, 2008 10:21 am |
|
|
Just because it is in an include, doesn't make it global. Many includes can be inside functions, especially when dealing with ones added/removed using defines.
However, if it is global, try one thing. Remove the 'zero_ram' declaration.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
|
Posted: Wed Aug 27, 2008 11:14 am |
|
|
To verify that it is a global declaration I added calls within several different functions within different files to read and write values to the array of structures as it is shown above. The code compiled fine and accessing the array of structures worked from all points.
Tired removing the #zero_ram declarations but this had no effect.
Thanks for the effort, I do appreciate it |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|