PBP RAM allocation - how to find available or total used RAM?

[mculibrk]

Hi!

I'm working with a PIC18F and desperately need to figure a way to determine the size of free RAM.

I went through the PBP documentation and it says PBP will allocate RAM in some "predetermined order": (from first to last)
LONG, WORD, BYTE, BIT, LONG_ARRAYS, WORD_ARRAYS, BIT_ARRAYS

So I tried declaring some variables at the very end of the program to hopefully be placed at the end and then a simple RAM_END - lastVar (in assembly) would give the free ram... BUT...
The variables are not allocated at all as described in the manual. Words, bytes, arrays (smaller one) are scattered all over the place...
I get the the "best" result declaring some "odd sized" byte array like lastVar var byte[19] which seems to be "at the end" (at least, at the moment). But is there any rule?? How can I be sure it will stay "at the end"?

I tried declaring arrays of various sizes (1, 2, 3, 4, 5..7, 19, 123, 500...) and for some reason the 19-entry array is put last, example code:

define OSC 64


var0 var byte[133] system
var1 var word
var2 var word
var3 var byte
var4 var byte
var5 var byte[5]
var6 var word[2]
var7 var bit[30]


vGLOB var byte[8] SYSTEM


aTemp1 var vGLOB[0]    
aTemp2 var vGLOB[1]    
aTemp3 var vGLOB[2]    
aTemp4 var vGLOB[4]    


bTemp1 var vGLOB[2]
bTemp2 var vGLOB[2] 
bTemp3 var vGLOB[3] 


bitval var bit


var8 var byte


ramUsed dw _last_ram0
ramFree dw RAM_END-_last_ram

;.....


END


_last_ram0 var byte[19]
_last_ram var byte[7]
_last_ram2 var byte[1]
_dum_b1 var byte
_last_ram3 var bit[8]
_dum_b2 var byte 
_last_ramX var byte[2]
_dum_b3 var byte
_last_ramW var word[2]
_dum_b4 var byte
_dum_b5 var bit

Anyone have some idea how to "surely" determine the first free location or remaining free RAM?

Thanks!

MCulibrk

[Art]

PBP should put its own system variables first to ensure they are in bank 0.
From there, one way might be to declare a bunch of the biggest arrays
that are supported, alias the elements of the arrays once you've determined
where PBP put them (at least they will be continuous chunks).
From there, if you don't add any more macro type commands that require
more RAM for PBP, the locations of your arrays shouldn't change.

[mculibrk]

Thanks for the comment but you're missing the point of my problem.

It's not a problem of "moving variables" per se. I know that PBP allocates its (system) variables first etc. The problem is how to determine the first free or last last used location
in RAM.

I need that because I would like to configure some buffers at runtime (cannot use static allocation/reservation!) and for that to function "reliably" I need to know the last used/first free RAM location.
(basically I need 2-3 buffers/arrays of variable sizes which all together could use up to "max free ram". I cannot configure the relative sizes during compile time)

The easiest way could be as I tried by manually declare a "variable" of specific type at the end... but that is not working as described in PBP manual under "RAM Allocation" - so it's not reliable.

The only other way I can think of right now, is to parse the .LST file, find there all the declarations of XXXX equ RAM_START + nnn (and check the declaration in the comment about the size) to deduce the "first free" ram location. But this is really an "ugly" way...

Regards,
MCulibrk

[pedja089]

I needed same thing, more than one time...
And I finally decided to create small app to monitor .lst file.
If you trust me, you can try it.
Right click, Save link as >>Removed, Bug... <<
Remove .txt extension, unpack RAR archive
Password: pedja089

It doesn't handle arrays with constants for size, eg
X con 4
MyArray VAR BYTE[X]
And it doesn't handle include files.
But if you have any variable declared after any unsupported lines, it will handle it. Or it should... I didn't want to recreate half of assembler to get that 2 things to works...
Basically it looks for last "RAM_START +", extract number, and try to get line before that, to check type of variable, and if it is array. So it can give correct size.
DISCLAIMER: Use it at own risk!
EDIT:
It uses .net framework 3.5. So you need to have it installed or higher.

[pedja089]

Fixed: PicBasicRamMonitor.rar.txt
DISCLAIMER: Use it at own risk!

[Art]

I understand now. What output does the program have if it was able to simply tell you?
I can see it happening in about 15 lines. About 5 lines of inline assembler would go a long way here,
because the file select register does not care what you or PBP is doing with RAM,
and can simply cycle the entire RAM map (switching banks inbetween) and list all of the values..

From there, if you populated all of YOUR RAM with an arbitrary value, the unused segments could
easily be identified (or the largest free space found).
An then finally, reset YOUR RAM back to zero as if the program had just started.

Off to tea right now, but if that’s what you mean, will be back later tonight.