I can not use Ram area

mehmetem · Joined: 29 Jul 2011 Posts: 12

I'm using ccs v4.114 compiler. I used dspic33fj32mc204. I realised that when my variables inreases ( 21 pieces int16 and 182 pieces int8 2 pieces float and some local variables) exceeds 256 byte my code does not work well. When compiling code at output message was Memory usage: ROM=40% RAM=17%-20%. I'm using now grater Ram sized dspic33fj64mc804. But still I can use same size 256 bytes. In this instance output message was Memory usage: ROM=21% RAM=2%-3%. I used #BUILD(STACK=0x3000:0x4000) for stack area. In this instance output message was Memory usage: ROM=21% RAM=26%-27%. Also I'm using #device *=16 but still I can not use more variable. What do you think about it? How can I use more variables?
_________________
trainee

Ttelmah · Joined: 11 Mar 2010 Posts: 19537

1) You don't need so much stack.
The stack is used by temporary variables, not by general variables. Just specify a size, increasing it a little may well be necessary if you have large maths functions with other functions called inside, but better to let the compiler locate it. Goes on to '2'...
2) Are you using ICD?. Thing is that when debug is enabled, some RAM locations at the top of memory are reserved for the ICD. By forcing the stack to be located here, you could be creating problems. If you just specify the stack as a 'size', the compiler will automatically move it down to clear the reserved locations. So:
#BUILD (STACK=512)

is all that is needed.
3) *=16, has no meaning on any chip latter than a PIC16. Forget it. It is not even present, in the PCD manual. You are using an instruction from PCM/PCH. Hopefully the compiler will ignore it.
4) Now, the compiler you are using, is relatively early for these chips. There were some definite 'oddities' on the earlier compilers, but I must admit I was using compilers around this time with these chips, and no problems with KB RAM arrays. Are you using structures, or simple variables?. There were (and still are in some cases), 'issues' with some types of data structure. By the low 4.1xx compilers, 99% of stuff was working fairly well.

Now, I just compiled a ten line program, with the smaller of these chips, on your compiler version, setting up a 32*int16 array, and a 512*int8 array. Wrote random numbers to each location in the 512 byte array, and the accesses were correct. Then combined pairs of the bytes into the int16 array, and still OK. 54% RAM used.

Best Wishes

mehmetem · Joined: 29 Jul 2011 Posts: 12

Thank you for your kind attention and assistance.
1- I did not use large math functions. So I do not need so much stack.
2- I'm not using ICD.

Ttelmah · Joined: 11 Mar 2010 Posts: 19537

I'd just declare yerPtr, as:

int8 *yerPtr;

and initialise it explicitly in the code. Same applies to your other pointers later.

Initialisation 'in declaration', is a thing that often didn't work. Could explain many problems.

I'd reorder the declarations. Do all the int16 declarations first. Then the int8 ones, and make sure that all int8 declarations are in multiples of 2. The DsPIC's require int16 values to start on a word boundary, and the compiler was not 100% capable of ensuring this happened at this point.

Why so many const declarations?. While good for something like a lookup table, for general values, why not use an enum, or a #define?. Latter uses no storage at all, while the const involves wasting ROM...

Get rid of PROTECT when developing. This just results in extra erase cycles being needed on the chip, using up lives. Only enable PROTECT, when the code is working...

Are you _sure_ about ICD?. If you are using MPLAB as a development environment (for example), this defaults to enabling ICD....

I'd suggest you step back. Throw away 90% of your code, and just try doing your data declarations. I'd suggest you have something else, like a "#define second = ????", causing the problem when you add this to the variable declarations.

Have compiled your data declarations, with your compiler version, and a basic chip setup for the MC204, still including another 576 bytes of other variables, and an up to 66% RAM usage.

mehmetem · Joined: 29 Jul 2011 Posts: 12

mehmetem · Joined: 29 Jul 2011 Posts: 12

I have a problem; with

Ttelmah · Joined: 11 Mar 2010 Posts: 19537

It almost certainly means there is a syntax error somewhere miles earlier.

The compiler has a habit (getting slightly less in the newer versions), when certain types of syntax error occur, of 'ploughing on', then giving a completely different error dozens (even hundreds) of lines later, at the point where one of it's internal expansion tables 'overflows', because of the earlier error.

This is why you will see a lot of the 'old hands', recommending using other syntax testing tools like LINT, to check the basic code.

Best Wishes

FvM · Joined: 27 Aug 2008 Posts: 2337 Location: Germany

I don't hear a clear description of ovserved problems.

"My analogue readings and pwm outputs halted" is the clearest, but still vague because the issue apparently
wasn't traced anyhow. Why pwm stops? Registers altered, chip rebooted, particular variables changed unintended?

I know that you might sometimes experience infrequent random errors that are hard to trace. But in your case,
there seems to be obvious issues. Debugging is the method to trace them down to the primary cause.