RAM issue

Guest · Posted: Mon Aug 25, 2008 1:25 pm

First, some info

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Are you using the CCS IDE or MPLAB ?

If you're using the CCS IDE, are you using "Multiple compilation units" ?

Ttelmah · Guest

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

Guest · 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

crystal_lattice · Joined: 13 Jun 2006 Posts: 164

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

Guest · 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.

Guest · 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.

Ttelmah · Guest

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

Guest · 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.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

If you can strip down the code to a tiny little program and post it
(a complete program), then we probably find the problem.

Guest · 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:

Ttelmah · Guest

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

Guest · 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.

Ttelmah · Guest

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

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