T4.0 Memory - trying to make sense of the different regions

[Frank B]

Paul has selectively placed some init code in TEENSY4 tree into FLASHMEM … but that doesn't likely cover some fat things like printf() and other such libraries.

The decision what needs to be where is not always easy.
For printf -don't know if it is possible to move it without special linkerfile.
The other libs -from core- already use FLASHMEM.

 

[defragster]

The decision what needs to be where is not always easy.
For printf -don't know if it is possible to move it without special linkerfile.
The other libs -from core- already use FLASHMEM.

Indeed - I knew I saw FLASHMEM in cores, I didn't stop to look how much.

One extreme case would be alternate LD file that leaves ALL code on Flash unless FASTRUN - that would still use 32KB min - would be interesting to see how that runs. Code cache is bigger than K66, not sure how K66 FLASH internal compares to 1062 external on read to execute speed?

printf on K66 brought in a lot of code, not sure how many other utils do that?

 

[KurtE]

What I don't know (actually expect the answer is no) is if I can do something like:

extern FLASHMEM {
....
}

like you might do with:

extern "C" {
...
}

And if it were still Christmas ...

I am with Frank and wishing for easier ability for each project(sketch) to better control different settings and features... I personally HATE libraries that have internal setting files that assume you only have one setup... Like RA8875 or ...

Again I don't know how easy some of these work or don't, and I know some of these have been talked about before, but they probably require a lot of @Paul's time which is probably already reasonably full . But maybe some can be experimented with by others and if they work do a Pull Request... Example different linker scripts. How hard is it to change some of the default locations? I don't know never tried, but if not hard. Then can we create a couple or a few and then simply add new menu item in boards.txt to choose which one?


I still don't understand the usage/power of has_include?
That is with something like we are trying with some of the font files that looks like:

#if __has_include(<RA8875.h>)
	#include "RA8875.h"
#elif __has_include(<ILI9488_t3.h>)
	#include "ILI9488_t3.h"
#elif __has_include(<ILI9341_t3n.h>)
	#include "ILI9341_t3n.h"
#elif __has_include(<ILI9341_t3.h>)
	#include "ILI9341_t3.h"
#elif __has_include(<ST7735_t3.h>)
	#include "ST7735_t3.h"
#endif

Can this be used with libraries (or core), with something like:
#if __has_include("user_settings.h")
#include "user_settings.h"
#endif
Again at some point would like to experiment with this.


FLASHMEM or not to FLASHMEM...
The difficulty I have with going through library code and adding FLASHMEM to everything is, it is so project dependent. That is suppose I should go through ILI9341_t3n and mark everything as FLASHMEM? Especially if in some projects, the display is only updated at low frequency, like maybe the time a well pump last ran... BUT then the next project may be to display an RPM meter and the person needs the display code to run as fast as possible? So then maybe I should invent some new define, like: DISPLAY_CODE_SPEED which can be set to FLASHMEM or not. But then how granular? Maybe this sketch only uses ILI fonts? So the GFX font support could/should be left in FLASH (or gone)... Maybe I use tft.printf(...) so now I want printf support in fast memory, other times maybe not...

 

[Frank B]

Again I don't know how easy some of these work or don't, and I know some of these have been talked about before, but they probably require a lot of @Paul's time which is probably already reasonably full . But maybe some can be experimented with by others and if they work do a Pull Request... Example different linker scripts. How hard is it to change some of the default locations? I don't know never tried, but if not hard. Then can we create a couple or a few and then simply add new menu item in boards.txt to choose which one?

I can try today. No risk - no fun Have no idea if it will work

 

[luni]

I still don't understand the usage/power of has_include?
That is with something like we are trying with some of the font files that looks like:

I'm using the technique for the TeensyTimerTool. Here the code:https://github.com/luni64/TeensyTimerTool/blob/master/src/config.h and here how to use it https://github.com/luni64/TeensyTimerTool#configuration
So far I'm quite happy with it.

 

[Frank B]

T4:
This loads _everything_ to flash:
(even "Fastrun")

MEMORY
{
    ITCM (rwx):  ORIGIN = 0x00000000, LENGTH = 512K
    DTCM (rwx):  ORIGIN = 0x20000000, LENGTH = 512K
    RAM (rwx):   ORIGIN = 0x20200000, LENGTH = 512K
    FLASH (rwx): ORIGIN = 0x60000000, LENGTH = 1984K
}

ENTRY(ImageVectorTable)

SECTIONS
{
    .text : {
        KEEP(*(.flashconfig))
        FILL(0xFF)
        . = ORIGIN(FLASH) + 0x1000;
        KEEP(*(.ivt))
        KEEP(*(.bootdata))
        KEEP(*(.vectors))
        KEEP(*(.startup))
        *(.flashmem*)
        *(.progmem*)
        *(.fastrun*)
        *(.text*)
                . = ALIGN(4);
                KEEP(*(.init))
                __preinit_array_start = .;
                KEEP (*(.preinit_array))
                __preinit_array_end = .;
                __init_array_start = .;
                KEEP (*(.init_array))
                __init_array_end = .;
        . = ALIGN(16);
    } > FLASH

    .data : {
        *(.rodata*)
        *(.data*)
        . = ALIGN(16);
    } > DTCM  AT> FLASH

    .bss ALIGN(4) : {
        *(.bss*)
        *(COMMON)
        . = ALIGN(32);
        . = . + 32; /* MPU to trap stack overflow */
    } > DTCM

    .bss.dma (NOLOAD) : {
        *(.dmabuffers)
        . = ALIGN(16);
    } > RAM

    _stext = 0;
    _etext = 0;
    _stextload = 0;

    _sdata = ADDR(.data);
    _edata = ADDR(.data) + SIZEOF(.data);
    _sdataload = LOADADDR(.data);

    _sbss = ADDR(.bss);
    _ebss = ADDR(.bss) + SIZEOF(.bss);

    _heap_start = ADDR(.bss.dma) + SIZEOF(.bss.dma);
    _heap_end = ORIGIN(RAM) + LENGTH(RAM);

    _itcm_block_count = 0;
    _flexram_bank_config = 0xAAAAAAAA | ((1 << (_itcm_block_count * 2)) - 1);
    _estack = ORIGIN(DTCM) + ((16 - _itcm_block_count) << 15);

    _flashimagelen = SIZEOF(.text) + SIZEOF(.data);
    _teensy_model_identifier = 0x24;

    .debug_info     0 : { *(.debug_info) }
    .debug_abbrev   0 : { *(.debug_abbrev) }
    .debug_line     0 : { *(.debug_line) }
    .debug_frame    0 : { *(.debug_frame) }
    .debug_str      0 : { *(.debug_str) }
    .debug_loc      0 : { *(.debug_loc) }

}

..So we have to find a way to enable "fastrun" again.
At a first sight, it seems to work. But it is more or less untested. A simple sketch works.

I'm off to do some shopping. More later. Maybe. If I find a way to enable fastrun again. Perhaps take a look at the t3.x linkerfiles (?!)

..you see, I do not know what I'm doing.. lol.. don't do much with linkerfiles.

 

[Frank B]

FLASHMEM or not to FLASHMEM...
The difficulty I have with going through library code and adding FLASHMEM to everything is, it is so project dependent. That is suppose I should go through ILI9341_t3n and mark everything as FLASHMEM?

Init only - or things where speed does not matter.

 

[Frank B]

@Defragster, WMXZ: tried the *.ld above?

Coremark is now 2316 - ok, it fits into the cache.

When trying to move only FASTRUN to ITCM, I always get a relocation error - not sure why. Jumps too far now?

c:/arduino/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/armv7e-m/fpu/fpv5-d16\libgcc.a(_udivmoddi4.o):(.ARM.exidx+0x0): relocation truncated to fit: R_ARM_PREL31 against `.text'

On the other hand.. if you want all in flash - do you need FASTRUN? So just try the linkerscript above.
I guess you don't need help to adjust boards.txt

Just got a delivery and more important things wait. Have fun

 

[defragster]

Hi Frank - nice you got the important delivery

Just looking and have not tried the FLASH only .ld. If the .ld file could be changed/selected at build time then alternate versions could go with Tools options

As for "if you want all in flash - do you need FASTRUN?" : if all code was in FLASH there may still be a 32KB ITCM block or can that go to ZERO ( you didn't show 'memory usage' ). Having 32KB of critical code there would make the CPU cache of 32KB more useful and the user might know what parts are critical to put in that 32KB ITCM block - _isr or just loop() and main code.

… something to look at ...

 

[Frank B]

With the script above, ITCM is zero.
As I said - have not found a way to re-enable FASTRUN. Maybe this weekend. At least it would be nice to know the reason for the linkage error.

 

[Frank B]

Just add a new "board" to boards.txt with the new file. Maybe name it "Teensy 4-flashmem" or something like that. Copy and paste from Teensy4 and edit the name of the ld file.

 

[Frank B]

Just add a new "board" to boards.txt with the new file. Maybe name it "Teensy 4-flashmem" or something like that. Copy and paste from Teensy4 and edit the name of the ld file.

hm, ok, that does not work.
so just change the name of the file in the teensy40 section in boards txt.

 

[Frank B]

attached a working boards.txt for "Teensy40Flash" - name the ld file from above imxrt1062f.ld
that should work, I hope

 

[Frank B]

Edit:

Ok, new try rename linkerfile above to imxrt1062f.ld

FASTRUN works. The pervious version from an hour ago had a problem with the calculated number of ITCM blocks. This is fixed.
Edit:
The attached file in #138 allows FASTRUN, but allocates at least one block ITCM.
The version from POST #131 ignores FASTRUN and puts everything into the flash.

 

[KurtE]

@Frank B - Looks interesting, Will be fun to try out, once I get some other distractions under control.

What I am wondering about this, is how hard would it be to have the boards.txt instead of creating a whole new board type, would instead add a new menu to the Teensy 4 that was something like: "Memory Options" or "Linker options" or choose a better name, which would have items, that would correspond to default and one for keeping program in flash...

This I am pretty sure will require changes to platform.txt to handle these new options.

One reason I mention this, is because I am pretty sure Paul made the differences to the builds with these last few releases (both release and the current beta) that now pass the standard board type definition as a define... And with the current changes in core and the like I know we are now seeing code like:

#if defined(ARDUINO_TEENSY41) 
<do stuff specific to Teensy 4.1>
#elif defined(ARDUINO_TEENSY40)
<do stuff specific to Teensy 4>
#endif

Now I know some places may have simple the #else to cover the T4.. But maybe not... My guess is the code wont look for ARDUINO_TEENSY40FLASH0
We could probably add it and issue with #else is you will probably want to do something similar for T4.1 when it comes out.

 

[defragster]

@Frank_B it does look interesting - certainly a great way to test the concept of alternate linking. I gave the Teensy_4 stuff a quick look - but didn't make the swap when it looked like it might not work with TSET_COMPILE.cmd? Did you have it working with that just passing those common elements?

set model=teensy40
set speed=600
set opt=o2std
set usb=serial

As KurtE noted it might take an extra setting to pass a menu option for that - unless it was part of "set opt" and I didn't look close enough.

 

[Frank B]

LOL... as you want...


No need to edit platform.txt.
@Tim: set memory=
should do it.

.. Have fun til next update

Perhaps one should write an automated Arduino-patcher... maybe a batchfile+linux+ios script which calls diff/patch (I can send you windows-executables if needed).
It should handle the defs.h patch, too.
Ehmm.. the batch-expert is Tim? Unfortunately, the defs.h can not handle this new memory type option. Any ideas? Can ld use a file for its options?

 

[defragster]

Looks like it should be usable @Frank - quick compare is all I can do now … work calls.

 

[luni]

.. Have fun til next update

Very cool indeed!

Off Topic:
Since you are working on boards.txt anyway, can I talk you into adding a (completely unrelated ) option for the new double and triple serial setting (USB_DUAL_SERIAL) and (USB_TRIPLE_SERIAL)? See here (https://github.com/PaulStoffregen/cores/pull/438) for details...

 

[Frank B]

sure...
is it -DUSB_DUAL_SERIAL and -DUSB_TRIPLE_SERIAL ?
(a fake serial would be better for debugging - needs no comport)

 

[Frank B]

@luni:

add these lines:

teensy40.menu.usb.2xserial=2x Serial
teensy40.menu.usb.serial.build.usbtype=USB_DUAL_SERIAL
teensy40.menu.usb.3xserial=3x Serial
teensy40.menu.usb.serial.build.usbtype=USB_TRIPLE_SERIAL

 

[luni]

Exactly.

(a fake serial would be better for debugging - needs no comport)

I take what I get, and comports are for free and they also allow for easy logging from the teensy directly in pc app if you use the normal serial for command/data transmission.

 

[luni]

Thanks, there was a small bug, this one works:

teensy31.menu.usb.2xserial=2xSerial
teensy31.menu.usb.2xserial.build.usbtype=USB_DUAL_SERIAL
teensy31.menu.usb.3xserial=3xSerial
teensy31.menu.usb.3xserial.build.usbtype=USB_TRIPLE_SERIAL

 

[Frank B]

ah..ok...I thought is was for Teensy4.0

 

[luni]

Problem was that you set the define for Serial instead of 2xSerial