Malloc implementations for psram

MichaelMeissner

MichaelMeissner

Senior Member+
Rather than continue the discussions about adding a malloc layer for the psram memory on the Teensy 4.1 beta thread, it is probably better to open a new thread about it.

Here are some open source malloc implementations (written in 2014):

Here are some links from that thread:

Obviously we need to be careful about the license of these libraries.
 
I think Paul will add a good version.
We need free() , a good way to handle fragmentation, +maybe a malloc which zeros memory, and a malloc for aligned memory would be great.
(+ reentrancy?)

And... if I think about the T5, maybe it's a good idea to consider the shared memory from the beginning on to prevent potential incompatibilities, later.
 
hmm.. a hack... maybe some tricks with __brkval could save huge amount of work and would need some wrappers only.... ok... a stupid idea.
 
Frank B said:
I think Paul will add a good version.
We need free() , a good way to handle fragmentation, +maybe a malloc which zeros memory, and a malloc for aligned memory would be great.
(+ reentrancy?)

And... if I think about the T5, maybe it's a good idea to consider the shared memory from the beginning on to prevent potential incompatibilities, later.
Click to expand...

Note: my quick and dirty with the name Paul mentioned he wish... currently aligns the allocations on 16 byte boundary. Now frees. Starts at top of EXTMEM and works it's way down and could wipe out anything you declared statically in EXTMEM as I did not find any currently defined where the user allocations ended...

As for zero... Again if we went with something like Windows HeapAlloc, one of the flag options is to zero.
 
KurtE said:
Note: my quick and dirty with the name Paul mentioned he wish... currently aligns the allocations on 16 byte boundary. Now frees. Starts at top of EXTMEM and works it's way down and could wipe out anything you declared statically in EXTMEM as I did not find any currently defined where the user allocations ended...

As for zero... Again if we went with something like Windows HeapAlloc, one of the flag options is to zero.
Click to expand...

With some more hacking I managed to getting working from a library just as a quick and dirty test. Anyway seems to have worked. I replace malloc with malloc_extmem and that crazy graphics sketch worked.

The issue is a problem unless you can say like reserve this amount for variables and use rest for malloc_extmem. How you would do that no idea

EDIT: Cross post on second comment Frank
 
As the linker knows "what is where", it can give you such an adress. Take a look how it's done for __brkval.
 
Oh my..
..sorry kurt..edited your message by accident:(


Frank B said:
You'd need a symbol which is defined in the linker-script that tells you the minimum usable adress.
Click to expand...
Yep - I am know Paul will probably get there soon, probably for next Teensyduino. I have the impression there may be two parts. Those that are initialized and those which are not.

At least that is what the comments in startup.c (configure_external_ram)
Code: 
 // TODO: zero uninitialized EXTMEM variables
// TODO: copy from flash to initialize EXTMEM variables
// TODO: set up for malloc_extmem()
Side comment - I wonder if we have initialized EXTMEM if we should also have initialized DMAMEM. Also wonder if a sketch can not detect if it has external memory or not at compile time, what should happen if the sketch has variables defined for EXTMEM? Again might be good if the sketch writer could then choose at compile time to put in EXTMEM or DMAMEM...

But that is a different conversation.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top