@blackaddr - I think you are reasonably close... As mentioned in the other thread, I hacked up an earlier hacked up program (I believe by @FrankB) which prints out more stuff for the T4...
Also note: That @Paul has recently added more information about the memory up on the main PJRC website, details shown in other thread:
https://forum.pjrc.com/threads/57326...l=1#post219686
Example from: an updated sketch from @defragster on the other thread, my output shows:
Code:
md /c "D:\\arduino-1.8.10\\hardware\\teensy\\..\\tools\\arm\\bin\\arm-none-eabi-gcc-nm -n C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_434165\\bar.ino.elf | D:\\GITHUB\\imxrt-size\\Debug\\imxrt-size.exe"
FlexRAM section ITCM+DTCM = 512 KB
Config : aaaaaaab
ITCM : 23008 B (70.21% of 32 KB)
DTCM : 12992 B ( 2.64% of 480 KB)
Available for Stack: 478528
OCRAM: 512KB
DMAMEM: 8272 B ( 1.58% of 512 KB)
Available for Heap: 516016 B (98.42% of 512 KB)
Flash: 32528 B ( 1.60% of 1984 KB)
I keep meaning to update my program to output some friendlier data, like someone else suggest on the thread.
But in particular: the FlexRam has a total size of 512KB, which has 8 blocks of 32KB (FlexRam config register) which can configure each of these 32KB blocks to either be assigned to ITCM or DTCM (or not all). So our link process assigns most of the code to be copied down to ITCM (Instruction Tightly Coupled Memory) and as many of these 32KB blocks are assigned to it for the code to fit. The remaining blocks are than assigned to DTCM (Data tightly coupled Memory)
By default const memory defines such as arrays, go into ITCM, I believe this also includes strings, like: Serial.printf("This is a string");
Stack goes at the end of DTCM and yes the heap as well as anything defined as DMAMEM go into OCRAM... And yes our startup code enables the caching of this region of memory, which is done in the function: FLASHMEM void configure_cache(void)
Which is part of startup.c
During the T4 beta, at times I would reconfigure the setup for this region to disable the cache... Which for example fixed several DMA issues I was having. But it was sort of throwing out the baby with the bath water... Then again if are only using this region to do DMA...
Note: In a posting a few down from the one I linked to, @Paul in his current github code has added some new defines to allow you to keep some of your code in Flash instead of being copied down to ITCM.
So now you can keep both data and program stuff from taking away from that 512KB.
That is you can keep Data up in flash, by doing the old style stuff like:
Code:
const uint8_t myData[] PROGMEM = {....};
Note the word PROGMEM is important here, unlike T3.x which ignores it.
Now (with Paul's core), code can stay up in flash as well:
Code:
FLASHMEM void MyFunction() {...}
And I believe that you can now also define strings, like you did on AVR to also stay in flash, It has been awhile since I have done that, but I think it is something like:
Serial.printf(F("This is a string"));
There are of course still other qualifiers for defines, like there is: Make sure this function runs in fast memory:
Code:
FASTRUN void MyFunction() {...}
Allocate some memory in the upper 512KB block
Code:
DMAMEM uint8_t my_screen_buffer[320*240*2];
Side note on DMAMEM - I don't think you can have an initialized block here...
Reply With Quote
Originally Posted by DaQue
