malloc/free for EXTMEM and DTCM

Hi Frank,

For me it is hard to say, I would probably go with a) as you have the white space.

It is hard to know at times what information is needed or wanted an in what form.
Example suppose you copy 20 bitmaps to a Flash memory chip that has LittleFS on it, and maybe the flash is getting full?
Do you want to know how big each file is? many times yes. As if I copy a bitmap from one media to another, you want to know how many bytes there are. Likewise when you open the file you may want to verify the bitmap by knowing the size of file versus header information.

But other times, like why I am I running out of space. Maybe you want/need to know how much disk space does that file consume.
 
Hi Kurt, I think FS are out of the scope of this tool.
If the files are added as PROGMEM Const, they are included.
And it can only know what is fixed at compiletime.

I've added a stack warning if 99% of RAM1 is used (see code)
Windows-exe is updated, but I didn't bother updating the Linux-versions..
 
Sorry I did not want to imply that the File system information should be included here as again this tool would not know anything.

I was trying to mention it as an analogy of the code:
You see that the code takes: 5.89 kB
of Memory, but it actually consumes 32KB of RAM1...

The majority of the time a user may not care. BUT: if they are running low on RAM1, and their code is 32KB + 10 bytes, They can gain 32KB of data space if the probably mark one function as FLASHMEM. Again not overly intuitive.

Also somehow here and/or T4.x product page or memory details page, may want to again a section, on transitioning a T3.x program to a T4. Why do I have less memory...


Again likewise on T3.x when you mark a large array as const, the data does not consume the RAM. To do this on T4.x you need to mark that data as PROGMEM...
Again outside scope of the tool.
 
Last edited by a moderator:
Kurt, maybe a runtime memInfo() would be good to have in the core.

(As this was not the first time I pressed the wrong button without realizing it, I think about removing the "+" from my account... we have no spam anymore...)

Edit: Linux- 32Bit and 64Bit variants on Github updated, as well as Windows. More details in Post #85
 
Last edited:
LFSintegrity show this - pretty near an EDGE case 64KB to 96 KB ITCM:
Code:
RAM1:  22.79% of 512 kB used.
   [B]Code (ITCM, 32 kB Blocks):   65.71 kB[/B]
   Variables (DTCM):            20.69 kB
   Available for Variables:    395.31 kB

RAM2:   2.36% of 512 kB used.
   Variables (DMAMEM):          12.09 kB
   Available for Heap:         499.91 kB

EXTMEM: not used.

FLASH:   1.11% of 7936 kB used.
   Code and Constants:          88.13 kB

So having to do MATH (and assume the last digit) I see I broke into block @3 of ITCM for 1752 bytes of code.

And marking :: FLASHMEM void setup() {
RAM1: 22.79% of 512 kB used.
Code (ITCM, 32 kB Blocks): 65.48 kB

Another small func down a few bytes - Still 96KB : FLASHMEM void makeRootDirs() {
Code (ITCM, 32 kB Blocks): 65.43 kB

And another small func down a few bytes - Still 96KB : FLASHMEM void printDirectory() {
Code (ITCM, 32 kB Blocks): 64.93 kB

Moving three printf strings as F() actually adds code. Is the F() code larger than a simple string?
Code (ITCM, 32 kB Blocks): 64.99 kB

Took the F() strings out of the added @mjs513 speedBench() code and it did not change:.
Code (ITCM, 32 kB Blocks): 64.93 kB

Opps - So the math works out - knowing how to do it ... which I was WRONG on as the kB's are really 1024 sets of bytes. thought I was aiming to get below 65536 Bytes, not

NOTE this agrees with the LINKER/build output:
Code:
Memory region         Used Size  Region Size  %age Used
            [B]ITCM:         96 KB       512 KB     18.75%[/B]
            DTCM:       21184 B       512 KB      4.04%
             RAM:       12384 B       512 KB      2.36%
           FLASH:       90436 B      7936 KB      1.11%
            ERAM:          0 GB        16 MB      0.00%

Okay putting the speedBench() to FLASHMEM:
Code:
RAM1:  16.54% of 512 kB used.
   Code (ITCM, 32 kB Blocks):   62.57 kB
   Variables (DTCM):            20.69 kB
   Available for Variables:    427.31 kB

RAM2:   2.36% of 512 kB used.
   Variables (DMAMEM):          12.09 kB
   Available for Heap:         499.91 kB

EXTMEM: not used.

FLASH:   1.11% of 7936 kB used.

Then undoing the other func()'s from FLASHMEM:
Code:
RAM1:  16.54% of 512 kB used.
   Code (ITCM, 32 kB Blocks):   63.35 kB
   Variables (DTCM):            20.69 kB
   Available for Variables:    427.31 kB

RAM2:   2.36% of 512 kB used.
   Variables (DMAMEM):          12.09 kB
   Available for Heap:         499.91 kB

EXTMEM: not used.

FLASH:   1.11% of 7936 kB used.
   Code and Constants:          88.27 kB
 
I've added exidx to the calculation, it was missing.
However you might see no difference, due to the rounding to kB.
 
Code I wrote last year compiles but I have to reduce my heap size when using the 8MB RAM chip.
If I use the full amount in the snippet below it causes an immediate freeze.
I need to trim my heap space back to some lower number. I'm now trying 7898116 and it works.

What has changed?

// extern uint8_t external_psram_size;
constexpr size_t myHeapSize = 1024 * 1024 * 8; // 8MB
EXTMEM uint8_t myHeap[myHeapSize];


size_t oom(struct smalloc_pool * whichPool, size_t sizeReported) {
Serial.println("OOM");
sendDisplayText("OOM");
return sizeReported;
}

void initExtMem() {
checkStaticMemory();
// https://forum.pjrc.com/threads/63695-malloc-free-for-EXTMEM-and-DTCM?highlight=sm_malloc
::sm_set_default_pool(myHeap, myHeapSize, 1, &oom);
checkStaticMemory();
}
 
Back
Top