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

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

[richard]

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]

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

[CuriousOne]

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.

[richard]

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

[CuriousOne]

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.