BasicMicro - Forums

Hi,

Before I start with my problem I'd like to ask, is the RAM Memory Free reported by Basic Micro Studio is a reliable measure of the amount of RAM a microcontroller will have on boot up? If so then i'm experiencing very strange behaviour with the values that it's reporting.


I've got a byte array allocated in my program that contains controller object i've created. Each of these is 64 bytes in size, so i've simply done this in my program.



What i'm experiencing is that as I increase the value of num controllers, the RAM Memory Free reported by Basic Micro Studio decreases by 64 byte increments as expected, and then will suddenly jump down by 1K at a particular point. Initially I thought it was the calculation that was at fault, so I hardcoded the value in this case 1071 but it still reported the lost K. If I instead used 1070 as the array size, it would suddenly return that lost K.

It seems the position of the declatation has an effect on this, as if I put it last (after all other variables) I could only put 1000 before the K jump occured. If i put it right at the start of my program, before enabling hserial and other things, the reverse of the issue occured, where by I could increase the array by 200 and the ram free wouldn't drop. All very strange.


Is this a known issue, as I find when the jump occurs my program fails to operate correctly on my ARC-32. I can only presume this is because there isn't enough RAM free for the board to operate, but does it really need 900B for the basic interpreter, stack and hservo?

Thanks in advance.
-1

Edit: Just rearranged my code so that I enable HServo and HSerial after all my constants and array declarations. Now I can get my array up to 1592 bytes, leaving me 1584 bytes free. If I add an extra byte to that, I suddenly get -10 bytes free (a whole 1.5K vanished ), and Studio will no longer let me load the program onto the board.

The AtomPro 3687 chips have 2 blocks of ram in them(each 2048 bytes). The compiler must keep all memory in an array in one block of tam. So once you go over the size of the block of ram it will shift to the second. Arrays have a max limit of 2048(the size of each block fo ram). Also if you define the array after other variables defined with the same type(eg byte in this case) it will be allocated after the other bytes. But another gotcha is words and longs are always allocated before bytes because of boundary requirements. In your case your array size is larger than the number of bytes left in the first block so it is being shifted to the second. To use the bytes that are being wasted you need to define new bytes before the big byte array. Longs and words will automatically be allocated before the byte array.

_________________
Tech Support
Basic Micro - Robotic Technology Evolved

Well that certainly explains it Nathan, Thanks! I guess not many people choose to allocate such large arrays in their programs, it certainly seems as though I'm pushing the ARC to its limits.

So in my particular case it would be wise for me to divide my array into sections, either as two large blocks, or many smaller ones, and then perform some indexing logic to select the correct one to use. It would be really great if I could get up to using 3K for these controller objects .

Thanks again Nathan, you've been a wealth of information on so many occasions for me and I really appreciate it. Its all worth it I assure you.
-1

You will definitely have to break it up into at least 2 chuncks if you are going to be using 3k. I've used almost the entire ram before so it can be done, it just gets a little complicated because of the split memory on the 3687. I could have made it automatically handle the split but it was a huge penalty in speed to all variable access, not just the split parts, so I decided it wasn't worth it.

_________________
Tech Support
Basic Micro - Robotic Technology Evolved