Forum Rule: Always post complete source code & details to reproduce any issue!
Page 6 of 7 FirstFirst ... 4 5 6 7 LastLast
Results 126 to 150 of 152

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

  1. #126
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,582
    Quote Originally Posted by defragster View Post
    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.

  2. #127
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,984
    Quote Originally Posted by Frank B View Post
    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?

  3. #128
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,366
    What I don't know (actually expect the answer is no) is if I can do something like:

    Code:
    extern FLASHMEM {
    ....
    }
    like you might do with:
    Code:
    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:
    Code:
    #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...

  4. #129
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,582
    Quote Originally Posted by KurtE View Post
    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

  5. #130
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    816
    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/TeensyTime...r/src/config.h and here how to use it https://github.com/luni64/TeensyTimerTool#configuration
    So far I'm quite happy with it.

  6. #131
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,582
    T4:
    This loads _everything_ to flash:
    (even "Fastrun")

    Code:
    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.

  7. #132
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,582
    Quote Originally Posted by KurtE View Post
    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.

  8. #133
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,582
    @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?
    Code:
    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
    Last edited by Frank B; 02-20-2020 at 05:57 PM.

  9. #134
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,984
    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 ...

  10. #135
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,582
    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.

  11. #136
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,582
    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.

  12. #137
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,582
    Quote Originally Posted by Frank B View Post
    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.

  13. #138
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,582
    attached a working boards.txt for "Teensy40Flash" - name the ld file from above imxrt1062f.ld
    that should work, I hope
    Attached Files Attached Files
    Last edited by Frank B; 02-23-2020 at 02:00 PM.

  14. #139
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,582
    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.
    Last edited by Frank B; 02-23-2020 at 02:02 PM.

  15. #140
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,366
    @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:

    Code:
    #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.

  16. #141
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,984
    @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.

  17. #142
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,582
    LOL... as you want...
    Click image for larger version. 

Name:	2020-02-22 19_43_51-Start.png 
Views:	13 
Size:	24.4 KB 
ID:	19140

    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?
    Attached Files Attached Files
    Last edited by Frank B; 02-22-2020 at 06:05 PM.

  18. #143
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,984
    Looks like it should be usable @Frank - quick compare is all I can do now … work calls.

  19. #144
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    816
    Quote Originally Posted by Frank B View Post
    .. 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...

  20. #145
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,582
    sure...
    is it -DUSB_DUAL_SERIAL and -DUSB_TRIPLE_SERIAL ?
    (a fake serial would be better for debugging - needs no comport)

  21. #146
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,582
    @luni:

    add these lines:
    Code:
    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

  22. #147
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    816
    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.
    Last edited by luni; 02-22-2020 at 07:19 PM.

  23. #148
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    816
    Thanks, there was a small bug, this one works:
    Code:
    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

  24. #149
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,582
    ah..ok...I thought is was for Teensy4.0

  25. #150
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    816
    Problem was that you set the define for Serial instead of 2xSerial

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •