Forum Rule: Always post complete source code & details to reproduce any issue!
-
Senior Member+
Malloc implementations for psram
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.
-
-
Senior Member+
I should mention, that the conversation for a Quick and dirty version up on the other thread, latest one: https://forum.pjrc.com/threads/60532...l=1#post239433
-
Senior Member+
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.
-
Senior Member+
hmm.. a hack... maybe some tricks with __brkval could save huge amount of work and would need some wrappers only.... ok... a stupid idea.
-
Senior Member+

Originally Posted by
Frank B
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.
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.
-
Senior Member+

Originally Posted by
KurtE
did not find any currently defined where the user allocations ended...
You'd need a symbol which is defined in the linker-script that tells you the minimum usable adress.
-
Senior Member+

Originally Posted by
KurtE
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.
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
-
Senior Member+
As the linker knows "what is where", it can give you such an adress. Take a look how it's done for __brkval.
-
Senior Member+
Oh my..
..sorry kurt..edited your message by accident

Originally Posted by
Frank B
You'd need a symbol which is defined in the linker-script that tells you the minimum usable adress.
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 defragster; 05-15-2020 at 06:19 PM.
Reason: restore
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules