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

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:

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

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.

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

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
Attachment 8346
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.

Fixed: Attachment 8348
DISCLAIMER: Use it at own risk!

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.

the CLEAR cmd already does that

Code:

---

  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:biggrin:

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.

Code:

---


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.

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]

I didn’t know you could mem allocate in PBP at run time at all.
How do you do that?

0x20 - 0x80 is just an arbitrary range I pulled out of the air.
It should be the entire RAM area of the particular pic’s memory map of one bank.
Then the same area is usually mirrored in other banks, so I’d just change the bank and run the same code again.

its all done in asm but whats allocated is not accessable to pbp directly

simple way , create a word var as an address register, and another as an index , pbp can run with them

and in asm you can transfer data to or from any location using the fsr , indirect address is address+offset

its most useful as a buffer,
but its way simpler to allocate a whatever size buffer you think you need in pbp the normal way unless dynamic allocation is your only option

Quote:

---

It should be the entire RAM area of the particular pic’s memory map of one bank.
Then the same area is usually mirrored in other banks, so I’d just change the bank and run the same code again.

---

there is no need to do it that way , most pic chips that have enough ram to consider this treatment will be pic18 or enhanced core pic16's
with an ability for linear memory access anyway , otherwise there is no point
scanning the memory is dead easy , marking the used area is the difficult part.
lumping all your vars into arrays and using EXT referencing for each individual var is impractical , and what about include files

Thanks for all the suggestions...

The idea of an external program seems most "secure" but it's not really "friendly"... and it could be simply done if using ASM only (no PBP) but the point was in using/extending PBP...

This "unfriendliness" is because of the fact that you should manually or with this program, alter an variable definition so to have that information available in runtime.

What I mean with this something like having a FLASH location with a dw _SYS_FREE_START_ (holding the value of first free ram location) so it could be used by the program for "dynamic allocations".

What I'm trying to accomplish is a "poor man" malloc() functionality (no, free(), no realloc()...) and for this I need the "free" info in runtime. So, with various programs and similar, you have to "manually" change that value in source and recompile to get the desired effect.

After some fiddling around and I think I found a "relatively good" solution:

declare an byte array which name is alphabetically last in order and which is bigger than any other defined byte array in your program. This kind of variable seems to be placed last in ram.

This method assumes:
- no direct allocations (with $address modifier) used in the program or at least you must be sure such addresses are before your other allocations
- no specific BANK n modifiers (other than BANKA/BANK0 or be sure to have enough other variables to use some bank "later" - example: if you use BANK 3 be sure to have enough variables to fill BANK0, 1, 2)
- enough free space to declare an byte array bigger than other used byte arrays (this seems reasonable if you need a malloc() anyway)


So, for example, if you declare

Code:

---

zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz var byte[1000]

---

and put somewhere something similar

Code:

---

@_RAM_FREE dw _zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

---

you should be relatively sure the flash at address _RAM_FREE has the address of the first available RAM location.

That can value could be put in a word var instead of flash for later use (as I mentioned - malloc())

So... if anyone needs a "dumb" malloc()...

This "malloc()" stuff can be easily used on 18F and on 16F "enhanced core" PICs... but mainly from ASM.

Regards,
MCulibrk

Quote:

---

Originally Posted by Art

I didn’t know you could mem allocate in PBP at run time at all.
How do you do that?

---

Oh, no... I'm not trying to allocate at runtime from PBP.
I'm using a lot of assembly (big part) but still using some part in PBP for easier/quicker implementation of not (time) critical stuff.

I allocate all "shared" (between PBP and assembly) variables in PBP as there is no way to tell PBP to "skip" some asm allocated RAM.
On the other hand... the assembly code have no idea of the "first free" RAM location available to be able to safely allocate anything.

Yes, "sort of" option is to allocate RAM from a given "high enough" RAM base address and hope to not overwrite anything from PBP (but this is not good as you may easily break that by later changing the PBP code with some more allocations... or, on the other hand, leave some (big) part of RAM unused...

As I mentioned, I need to allocate few variable sized arrays (buffers) which cannot be done at compile-time as the required sizes are not known. The buffers get allocated when the PIC receives some commands via USART containg the requested buffer sizes.

Assembly routines take care of all this "dynamic allocations" and "moving addresses" (as you cannot change the start address of a variable in PBP once allocated, so I cannot just allocate something in PBP and later change the allocations). But this buffers are used by PBP code too (via usercommand "xx").

All the mentioned options of "searching" for free RAM or just "blindly" using it are not possible as there are no way to know for sure where free ram is.

I'm not sure if my question is exactly related but, I'll ask it here.

As I was able to get running 144x32 pixels ST7920 LCD module (Physically and comand-wise compatible with Hitachi HD44780 based 1602 LCD displays) with simple LCDOUT statements (no ASM, hard to guess commands and so on). Now I'm developing an "upgrade" code, which will use this display module with my own charset. Due to relatively high pixel density (144x32 vs 80x16 on HD44780), it is possible to display 18 chars X 4 lines text with 8x8 font on this module. These modules have built-in fonts (about 8192 characters!) but they're either big or ugly. So own character library is a must.

So my idea is as follows (I already started coding it, and so far it appears to be going in the right direction).

Use external EEPROM like 24C32, to hold graphic data for 128 characters, 8x8 pixels each.
Develop a code, which reads appropriate character from external EEPROM and sends it to display according to user specified position.
The main issue is that you can't that simply update specified location of this display module. Updates always are done in 16 bit increments - space for 2 chars. So when writing say character to position #3, I should take care about what is shown at position #4, and actually re-draw it, along with position #3. For this I plan to have array consisting of 72 elements (18x4), which will be updated and looked up before sending data to display, to avoid the character loss.
There will be some other routines too, for reading and sending data to display. I estimate that all this will use about 2KB of code memory. But what about RAM? PBP manual says, arrays are limited to 96 bytes on PIC16 series. I guess this is related to amount of free ram. And if my array uses 72 bytes, will be there ram left for other my code? I mean, the code might compile to 2-3kb, but there will be no RAM to run additional code. Is such situation possible?

Attachment 9083

Quote:

---

But what about RAM? PBP manual says, arrays are limited to 96 bytes on PIC16 series. I guess this is related to amount of free ram.

---

some pic16 are limited to 80 bytes, its not about free sram but due to the fact that pbp uses "banking" to access the sram, the limit is the amount of gp ram available in a bank.
arrays of much larger size can be used with linear memory access [you will not be interested since the word asm is involved]

Quote:

---

And if my array uses 72 bytes, will be there ram left for other my code? I mean, the code might compile to 2-3kb, but there will be no RAM to run additional code. Is such situation possible?

---

absolutely

Ok, thanks.
So I guess, it will be better to use dedicated PIC chip to do the display serving, and use another chip for general purposes.

Quote:

---

So I guess, it will be better to use dedicated PIC chip to do the display serving

---

it will be better to employ a PIC chip suited to the task, you may as well use a nexington or whatever they are called it's usually vastly easier
than trying to design a multi pic system

I tried Nextion, it is way too expensive, has bad quality, no daylight visible screens, not so robust. not so fast on booting and IDE is awful.
I'm trying to experiment with "BIG" PIC chips. Mostly with ones with built-in LCD driver, so I can hook matrix directly.