| View previous topic :: View next topic |
| Author |
Message |
koenbielen
Joined: 23 Apr 2009
Posts: 42
|
| Compiler V5.0 --> not enough RAM |
 Posted: Tue Oct 08, 2013 7:45 am |
 |
|
Since i changed to V5 of the compiler my old projects seem not to compile anymore,
Executing: "C:\Program Files (x86)\PICC\Ccsc.exe" +FM "Jaga_DBE_Basic.c" #__DEBUG=1 +ICD +DF +LN +T +A +M -Z +Y=9 #__12F683=TRUE
Error[74] Jaga_DBE_Basic.c 826 : Not enough RAM for all variables
1 Errors, 0 Warnings.
Build Failed.
Halting build on first failure as requested.
BUILD FAILED: Tue Oct 08 15:40:01 2013
While with V4 compiler this program worked OK.
I must say that in V4 the program memory was at 98%
is there a way to solve this problem? (other than getting a bigger processor  )
| Code: |
#include <12F683.h>
#define sVersion "0.8"
#device adc=10
#FUSES NOWDT //No Watch Dog Timer
#FUSES INTRC_IO //Internal RC Osc, no CLKOUT
#FUSES NOCPD //No EE protection
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOMCLR //Master Clear pin used for I/O
#FUSES NOPUT //Power Up Timer
#FUSES BROWNOUT // brownout reset
#FUSES NOIESO //Internal External Switch Over mode enabled
#FUSES NOFCMEN //Fail-safe clock monitor enabled
#use delay(clock=8000000)
#use fast_io(A) |
|
|
 |
alan
Joined: 12 Nov 2012
Posts: 350
Location: South Africa
|
|
| Posted: Tue Oct 08, 2013 7:50 am |
|
|
Get rid of the DEBUG, might save enough RAM.
Regards |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
| Re: Compiler V5.0 --> not enough RAM |
| Posted: Tue Oct 08, 2013 8:17 am |
|
|
| koenbielen wrote: |
Error[74] Jaga_DBE_Basic.c 826 : Not enough RAM for all variables
I must say that in V4 the program memory was at 98%
|
The error message is that its running out of RAM, NOT program memory. Remember on PICs they are very different memory spaces.
You need to through your code and minimise the number of variables, both global and local. On most PICs there is no data stack so all local variables have to be statically allocated in RAM. That's why PICs can't really do recursion or re-entry into routines.
You need to make sure all variables are the minimum size to fit the required data. There's no point in having int32 when the values go from 0 to 100. Clearly int8 would do. Reduce the number of floats or replace them with carefully scaled 16 and 8 bit integers. As a bonus, the code will run faster and will generally be more precise.
Reduce the number of temporary variables.
Ensure all structures are arranged so as to allow easy alignment. int32s and int16s need to start on even byte boundaries. This means
| Code: |
struct
{
int8 a;
int32 b;
int16 c;
}
|
may take up more space per instance than:
| Code: |
struct
{
int32 b;
int16 c;
int8 a;
}
|
Do not pass strings in RAM.
Make all strings and buffers the bare minimum size to contain all the data they need to contain. Avoid copying strings and buffers where possible: two copies take up more RAM than one. Use pointers to point at sub-strings etc. though, of course, pointers carry their own risks.
Don't use dynamic allocation of memory: no malloc etc.
There's a lot of other things other folk will tell you about.
However, in almost the whole history of computing, simply getting a bigger processor, with more RAM/speed/whatever, has been the simplest and generally the best option. The PIC12F683 has just 128 bytes or RAM. That's the lot, not even enough for half this message. Let's face it, it's tiny, even by 1950's standards. |
|
|
gpsmikey
Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA
|
|
| Posted: Tue Oct 08, 2013 9:13 am |
|
|
Yes, but his point was that the same code failed to build on V5, but did build on V4.xxx (although it was at 98%). Something about V5 is allocating the PIC RAM somewhat differently so that it goes over the edge. Granted, he should not be that close to the limit, but in this case, V5 appears to not optimize the RAM usage like V4.xxx was. That said, I get nervous when I pass about 70% RAM usage :-)
mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19249
|
|
| Posted: Tue Oct 08, 2013 9:21 am |
|
|
No, you are fractionally missing the point. He reports the program memory was at 98%, but it is the _RAM_ that is being complained about in the failure. Generally, I have seen V5, use slightly less RAM, but slightly more ROM. Since he doesn't say what was being reported in V4, for RAM, we are 'guessing'. For all we know, V4, could have been saying the RAM was at 100%, with no spare at all....
Best Wishes |
|
|
gpsmikey
Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA
|
|
| Posted: Tue Oct 08, 2013 12:47 pm |
|
|
Ah, you're right - I did miss the fact he said "Program memory" - it has been one of those mornings. He may have meant RAM, but did say Program memory. I had read it as RAM. Sigh 
mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19249
|
|
| Posted: Tue Oct 08, 2013 1:09 pm |
|
|
I think we have all been there sometimes...
I call it "straining up under the bear". Seems to describe things perfectly sometimes.
I've seen several programs get a tiny touch larger in ROM, but nothing get bigger in RAM with V5. The default should be *=8, with this compiler and chip, so all the RAM should be available. If he is using interrupts, might be worth trying CCS4 mode, though normally CCS5 saves RAM.
Posting the .sym file from the V4 compile might give us a clue.
Best Wishes |
|
|
koenbielen
Joined: 23 Apr 2009
Posts: 42
|
| DBEBUG |
| Posted: Wed Oct 09, 2013 1:14 am |
|
|
Hi,
When I removed the debug as Alan replied the problem was solved. 
RF Developer, thank you for the info. I will optimize my code.
Thank you everyone.
byby |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19249
|
|
| Posted: Wed Oct 09, 2013 1:49 am |
|
|
The debugger uses about 20% of the RAM, so turning it off, gives a lot more space.
How is the ROM usage, given you were so close on the previous compiler?.
Best Wishes |
|
|
epalite
Joined: 06 Apr 2008
Posts: 16
|
|
| Posted: Tue Dec 03, 2013 3:02 am |
|
|
Hi all,
the v5 (v5.015/016) uses significantly more ROM space. So, what special does it do compared with v4? Anyone can shed the light?
Thanks! |
|
|
oxo
Joined: 13 Nov 2012
Posts: 219
Location: France
|
|
| Posted: Tue Dec 03, 2013 7:36 am |
|
|
<joke>
It needs extra space for all the new bugs they have introduced.
</joke> |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19249
|
|
| Posted: Tue Dec 03, 2013 8:07 am |
|
|
#opt compress
Usually gives smaller sizes than V4.
The optimiser default has been shifted to have a slightly higher priority on 'speed'.
Best Wishes |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
