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

[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.

[richard]

the CLEAR cmd already does that

   CHK?RP  FSR0L
   movlw   low (RAM_END)
   movwf   FSR0L
   movlw   high (RAM_END)
   movwf   (FSR0L) + 1
loop    clrf    POSTDEC0
   movf    FSR0L, W
   iorwf   FSR0H, W
   bnz     loop
   clrf    INDF0

you are still left with the dilemma on how to fill all the "ram" your pbp code has claimed to a value other than 0
so you can detect the end of pbp's allocation, might as well examine the .lst
have found pedja's pgm is not correct when include files are used {as warned}

you could always do it like most c compilers
they just keep allocating ram from the heap until the stack underflows ,then let the pgm crash and burn

[Art]

I meant filling all of the RAM you declared yourself within PBP in a for loop (within PBP) first.
If all of the RAM is delayed as arrays, this is easily done with a for next loop.
Then even if you didn’t want arrays, you could still alias the individual elements and forget they are array elements.

I’m assuming that PBP will put all of your variables after it’s own system variables, even if they are scattered,
which I believe it always will.

byte i
byte PBPvar

FOR i = $20 TO $80

@ movf _i , W
@ movwf FSR
@ movf INDF , W
@ movwf _PBPvar

LCDOUT “PBPvar"

NEXT i

If your pic has greater than 8 bit registers you can set the high byte once, outside of the loop.

This is not tested of course, but the basic idea.. list locations 0x20 - 0x80 (and I don’t actually know where your RAM is in the 18F chip).
bank switch in PBP and repeat.

[richard]

the point is how do know you that you have no vars stored past "$80" without checking the lst file every time you add or remove a var , esp if you need to be ABLE TO ALLOCATE EVERY FREE BYTE POSSIBLE OUTSIDE OF PBP
[dAM hit the caps lock]