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

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

[Art]

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.

[richard]

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

[richard]

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

[mculibrk]

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

zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz var byte[1000]

and put somewhere something similar

@_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

[mculibrk]

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.

[CuriousOne]

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?