Forum Rule: Always post complete source code & details to reproduce any issue!
Page 165 of 173 FirstFirst ... 65 115 155 163 164 165 166 167 ... LastLast
Results 4,101 to 4,125 of 4311

Thread: Teensy 4.0 First Beta Test

  1. #4101
    Hello,

    wanted to move my project over from 3.2 to 4.0. It's an audio project (serial + audio)

    When trying to compile I only see serial option for teensy 4. Will this change soon or does the harware simply not support this?

  2. #4102
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,567
    The non-Serial USB types will be supported in future versions of the software.

  3. #4103
    Quote Originally Posted by PaulStoffregen View Post
    The non-Serial USB types will be supported in future versions of the software.
    OK would really really really love that.

  4. #4104
    Quote Originally Posted by KurtE View Post
    As for access to the bottom pins, @mjs513 shows the one way, which I am also using on my board, I showed earlier.
    Attachment 17126

    Then you can also do it using POGO pins, like Paul did in his beta boards shown below.

    Attachment 17125

    The Beta board shows how you can use the Ribbon cable to connect up the SD adapter and/or use the 6 signal pins for other things, like another SPI port and ...
    Also under the ribbon in the photo is two more Pogo pins, like mine shows that make friction connection with the USB Host pins.

    One interesting thing with Pogo pins, is if you put too many on the board, the chip may start to be pressed up out of the socket and then you might get a mysterious circuit not working, until you press the chip back down.
    Hi Kurt,
    Not sure if you tried yourself to connect the 4pin SDIO at the bottom (8pins) to a micro SD.
    Could somebody help me to find the type of connector required for the SDIO pins, the one use for the ribbon cable? If possible the type and a possible supplier in Europe. J-M

  5. #4105
    Quote Originally Posted by Jean-Marc View Post
    Hi Kurt,
    Not sure if you tried yourself to connect the 4pin SDIO at the bottom (8pins) to a micro SD.
    Could somebody help me to find the type of connector required for the SDIO pins, the one use for the ribbon cable? If possible the type and a possible supplier in Europe. J-M
    Sorry, just saw this link now:
    https://www.pjrc.com/breakout-board-for-teensy-4-0/
    Thanks Paul.

  6. #4106
    Quote Originally Posted by Frank B View Post
    Added a pull-request for MQS.
    My fork has all new changes: https://github.com/FrankBoesing/Audio

    You can directly add small speakers (8 OHM) with a capacitor in series (I used 100uF) - It is not very loud, but in a quite environment it is ok.
    Maybe one of you electronic-specialists could post a simple amplifier? a one - transistor thing?


    I'm not sure if I have the frequencies right - at least I have one more output working now.
    Hi Frank,

    Is the MQS output still supported in the Audio library for the T4?
    On what pin does it output sound? I tried pin2 with 100uF (+ at pin 2 side), speaker in series to ground but I hear nothing.

    Thanks,

    J-M

  7. #4107
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,194
    Quote Originally Posted by Jean-Marc View Post
    Hi Frank,

    Is the MQS output still supported in the Audio library for the T4?
    On what pin does it output sound? I tried pin2 with 100uF (+ at pin 2 side), speaker in series to ground but I hear nothing.

    Thanks,

    J-M
    I don't think the audio GUI knows about MQS yet, but the library supports AudioOutputMQS, left right channel pins (10 12).
    I changed output on WavFilePlayer to use AudioOutputMQS and it worked

    The Teensy 4 pin card shows MQSR and MQSL

  8. #4108
    Thank you Manitou! I never noticed it was on the card. It works also for me with the guitar sample. I thought it was on pin 2 (out2). You know if it can be reconfigured somewhere else. 10 and 12 are often used for SPI the only full SPI available on the header pins.

  9. #4109
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,194
    Check the T4 ref manual, MQS has alternate pin configurations, but the alternate pins may not be brought out on the T4. There is also the pin crossboar (XBAR) that might have a configuration for redirecting MQS output...

  10. #4110
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,256
    Quote Originally Posted by manitou View Post
    Check the T4 ref manual, MQS has alternate pin configurations, but the alternate pins may not be brought out on the T4. There is also the pin crossboar (XBAR) that might have a configuration for redirecting MQS output...
    Unfortunately, the only pins that are brought out on the Teensy 4.0 are Teensy pin 10 (B0_00) for MQS_RIGHT and Teensy pin 12 (B0_01) for MQS_LEFT.

    Page 309 of the manual states the alternate pads for MQS_RIGHT to be:
    • GPIO_AD_B0_04 (Alt1)
    • GPIO_B0_00 (Alt2)
    • GPIO_EMC_13 (Alt3)


    And for MQS_LEFT:
    • GPIO_AD_B0_05 (Alt1)
    • GPIO_B0_01 (Alt2)
    • GPIO_EMC_14 (Alt3)


    So if you wanted to do say a display (output only) and mono sound, it might be possible to use pin 10 for the CS, pin 11 for MOSI1, and pin 12 for MQS_LEFT. I suspect you may have to do some reconfiguration (manually use one of the pins not brought out for MQS_RIGHT and initializing MQS after SPI, but this is a guess). Or if you are willing to solder to pads 26 (MOSI1) and 27 (SCLK1) and use pin 0 for CS1 you could use the second SPI device.

    Or as other threads mention, using hardware I2S would be possible. I just ordered this I2S amplifier to try it out:

  11. #4111
    Quote Originally Posted by MichaelMeissner View Post
    Unfortunately, the only pins that are brought out on the Teensy 4.0 are Teensy pin 10 (B0_00) for MQS_RIGHT and Teensy pin 12 (B0_01) for MQS_LEFT.

    Page 309 of the manual states the alternate pads for MQS_RIGHT to be:
    • GPIO_AD_B0_04 (Alt1)
    • GPIO_B0_00 (Alt2)
    • GPIO_EMC_13 (Alt3)


    And for MQS_LEFT:
    • GPIO_AD_B0_05 (Alt1)
    • GPIO_B0_01 (Alt2)
    • GPIO_EMC_14 (Alt3)


    So if you wanted to do say a display (output only) and mono sound, it might be possible to use pin 10 for the CS, pin 11 for MOSI1, and pin 12 for MQS_LEFT. I suspect you may have to do some reconfiguration (manually use one of the pins not brought out for MQS_RIGHT and initializing MQS after SPI, but this is a guess). Or if you are willing to solder to pads 26 (MOSI1) and 27 (SCLK1) and use pin 0 for CS1 you could use the second SPI device.

    Or as other threads mention, using hardware I2S would be possible. I just ordered this I2S amplifier to try it out:
    Thanks for the tip. Mono sound is is enough. If I could use pin 10 only for audio (CS can be whatever pin) and disable MQS on pin 11.
    As soon the SPI init is called, MQS sound stops. I guess I need to do something in the MQS Audio driver to disable pin 11?

  12. #4112
    Quote Originally Posted by Jean-Marc View Post
    Thanks for the tip. Mono sound is is enough. If I could use pin 10 only for audio (CS can be whatever pin) and disable MQS on pin 11.
    As soon the SPI init is called, MQS sound stops. I guess I need to do something in the MQS Audio driver to disable pin 11?
    MQS sound is now ok. With pin10 mono (not using pin 12). I am still interested to know how to disable fully MQS on pin 12 in case I would use MISO one day.
    I now soldered the SD using SDIO iso SPI. I will post a picture.

  13. #4113
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,331
    Quote Originally Posted by Jean-Marc View Post
    I am still interested to know how to disable fully MQS on pin 12 in case I would use MISO one day.
    Simply set pin to MISO and it will override all previous usage

  14. #4114
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,194
    Quote Originally Posted by Jean-Marc View Post
    MQS sound is now ok. With pin10 mono (not using pin 12). I am still interested to know how to disable fully MQS on pin 12 in case I would use MISO one day.
    I now soldered the SD using SDIO iso SPI. I will post a picture.
    The order of incantations may be tricky. The audio lib (output_mqs.cpp) does CORE_PIN12_CONFIG = 2 as part of MQS init. you could override that with
    SW_MUX_CTL_PAD_GPIO_AD_B0_05 = 1; which directs MQS LEFT to AD_B0_05 (no pin available on T4), and then init SPI .... testing required.

  15. #4115
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,194
    Quote Originally Posted by mjs513 View Post


    Anyway here is the zip of the windows exe and the .c file (hope its the right one I found).
    Attachment 17202

    Thanks for checking.

    Mike
    OK, compiling imxrt-size.c on linux, i don't get anything printed. FIX: the problem is in printnumbers() all printf's need \n instead of \r
    Are the numbers supposed to be good? are the flash/RAM sizes from the Arduino IDE correct ?
    for the SDR FFT benchmark, IDE reports 124480 bytes (6%) of program storage, Global variables use 312576 bytes
    and imxrt-size reports
    ITCM : 29504 B (22.51% of 128 KB)
    DTCM : 266944 B (203.66% of 128 KB)
    OCRAM: 16128 B ( 6.15% of 256 KB)
    Flash: 124480 B ( 7.91% of 1536 KB)


    is there a newer version of imxrt-size ? maybe we need a github site instead of chasing zip files

  16. #4116
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,101
    Quote Originally Posted by manitou
    for the SDR FFT benchmark, IDE reports 124480 bytes (6%) of program storage, Global variables use 312576 bytes
    and imxrt-size reports
    ITCM : 29504 B (22.51% of 128 KB)
    DTCM : 266944 B (203.66% of 128 KB)
    OCRAM: 16128 B ( 6.15% of 256 KB)
    Flash: 124480 B ( 7.91% of 1536 KB)
    Think the compiled numbers are correct but available is incorrect. Paul just recently posted about that: https://forum.pjrc.com/threads/54711...l=1#post211545
    Those limits look like the fixed sizes from the early 1052-based beta hardware.

    On 1062, OCRAM is always 512K, and we now automatically allocate the other 512K between ITCM and DTCM. ITCM is allocated as whatever your code uses, rounded up to the nearest 32K boundary. The rest of that 512K is all DTCM.

    Flash support was increased to 1984K as well.

  17. #4117
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,101
    @PaulStoffregen

    Just ran into a very strange problem with FlexCAN. Went back to working on FlexCAN FD and ran into a problem that it would hang in flexcanFD init function. Specifically on trying to go into freeze mode. After some debugging reverted to 1.47-beta5 and it FlexCAN FD started working again. Then tried 1.47-beta6 and same thing happened with the sketch hanging on trying to go into Freeze mode.

    Not even sure where to start debugging this one.

    EDIT: I did a compare of the imxrt.h files and they are identical.

  18. #4118
    Junior Member
    Join Date
    Aug 2019
    Posts
    1
    board: teensy 4.0 (just arrived this afternoon from robot-italy !)

    library zip: teensyThreads.zip (downloaded from https://github.com/ftrias/TeensyThreads)

    example included: Blink.ino

    the code:

    //============================
    #include <Arduino.h>
    #include "TeensyThreads.h"

    const int LED = 13;

    volatile int blinkcode = 0;

    void blinkthread() {
    while(1) {
    if (blinkcode) {
    for (int i=0; i<blinkcode; i++) {
    digitalWrite(LED, HIGH);
    threads.delay(150);
    digitalWrite(LED, LOW);
    threads.delay(150);
    }
    blinkcode = 0;
    }
    threads.yield();
    }
    }

    void setup() {
    delay(1000);
    pinMode(LED, OUTPUT);
    threads.addThread(blinkthread);
    }

    int count = 0;

    void loop() {
    count++;
    blinkcode = count;
    delay(5000);
    }
    //============================

    using:
    arduino ide 1.8.9
    Teensyduino 1.47-beta 5

    sketch compiling error:

    //----------------------------------------
    C:\Users\artur\Downloads\arduino-1.8.9-windows\arduino-1.8.9\hardware\teensy\avr\libraries\TeensyThreads\ TeensyThreads.cpp: In member function 'int Threads::setMicroTimer(int)':

    C:\Users\artur\Downloads\arduino-1.8.9-windows\arduino-1.8.9\hardware\teensy\avr\libraries\TeensyThreads\ TeensyThreads.cpp:260:46: error: 'IRQ_PIT_CH0' was not declared in this scope

    int number = (IRQ_NUMBER_t)context_timer - IRQ_PIT_CH0;

    Uso la libreria TeensyThreads alla versione 1.0 nella cartella: C:\Users\artur\Downloads\arduino-1.8.9-windows\arduino-1.8.9\hardware\teensy\avr\libraries\TeensyThreads

    Errore durante la compilazione per la scheda Teensy 4.0.
    //----------------------------------------




    Thank you for any suggestions.
    Anyway, great thanks for your great job !

    Arturo

    p.s.
    with teensy 3.2, for me, no errors, run well.

  19. #4119
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,194
    teensyThreads.zip looks to be 2 years old! use git clone, or download master.zip from the "Clone or download" dropdown menu

  20. #4120
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    Quote Originally Posted by mjs513 View Post
    Think the compiled numbers are correct but available is incorrect. Paul just recently posted about that: https://forum.pjrc.com/threads/54711...l=1#post211545
    At some point I should probably learn what do all of these types of memory mean? i.e. what is the difference betwen ITCM and DTCM? Sometimes I hate 3 or 4 letter acronyms!

    I know that I can use searches for this, and do find things like: http://infocenter.arm.com/help/index...h05s02s03.html
    5.2.3. Differences between DTCM and ITCM

    T
    Code:
    here are differences between the DTCM and ITCM interfaces:
    
        DMA to ITCM must not occur unless IRIDLE is asserted
    
        Only back-to-back transfers on the DTCM can be marked as sequential. On the ITCM, idle cycles can occur before requests marked as sequential.
    
        Sequential write transfers do not occur on the ITCM.
    
        The ARM926EJ-S processor does not support simultaneous access by ITCM and DMA. DMA access must only take place when you know that the ARM926EJ-S processor cannot execute code from the ITCM. The TCM interface indicates this by either the IRIDLE or STANDBYWFI signals.
    or: https://stackoverflow.com/questions/...coupled-memory
    ITCM: Instruction Tightly Coupled Memory(can contain data)
    DTCM: Data Tightly Coupled Memory (Can only be data?)
    OCRAM: On Chip RAM

    Again maybe the WIKI should contain some information like on T4, what the different keywords like: PROGMEM, DMAMEM, const, static... imply like which section does each go into and what are the implications to code? Like either don't do DMA from/to ... Or if you do, you need to do ...

  21. #4121
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,101
    Quote Originally Posted by artramo View Post
    board: teensy 4.0 (just arrived this afternoon from robot-italy !)

    library zip: teensyThreads.zip (downloaded from https://github.com/ftrias/TeensyThreads)

    example included: Blink.ino

    the code:
    …...

    Thank you for any suggestions.
    Anyway, great thanks for your great job !

    Arturo

    p.s.
    with teensy 3.2, for me, no errors, run well.
    @manitou is correct. @ftrias just updated the library to work with the T4 a few days ago. See the multithreading thread for more info but the link to the version that now works with the T4 is https://github.com/ftrias/TeensyThreads.

  22. #4122
    I believe the answer to this is "no", but I am wondering if there is an API to read and write from T4's internal flash memory? Back in the days of yore (AVR days) I recall this being possible, but I have no idea if the required instructions would be present for ARM.

  23. #4123
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,698
    Quote Originally Posted by wcalvert View Post
    I believe the answer to this is "no", but I am wondering if there is an API to read and write from T4's internal flash memory? Back in the days of yore (AVR days) I recall this being possible, but I have no idea if the required instructions would be present for ARM.
    Paul posted a demo code segment that read back from FLASH in the BETA thread - reading the RESTORE area code, though the EEPROM area may have read example too as @manitou read that area for meta data. So not an API - but should show access.

  24. #4124
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    To follow on with my comment earlier today:
    Quote Originally Posted by KurtE View Post
    At some point I should probably learn what do all of these types of memory mean? i.e. what is the difference betwen ITCM and DTCM? Sometimes I hate 3 or 4 letter acronyms!
    ...
    I know that I can use searches for this, and do find things like: http://infocenter.arm.com/help/index...h05s02s03.html
    ITCM: Instruction Tightly Coupled Memory(can contain data)
    DTCM: Data Tightly Coupled Memory (Can only be data?)
    OCRAM: On Chip RAM

    Again maybe the WIKI should contain some information like on T4, what the different keywords like: PROGMEM, DMAMEM, const, static... imply like which section does each go into and what are the implications to code? Like either don't do DMA from/to ... Or if you do, you need to do ...
    In case there are others who also are unclear as I am/was about some of this and also trying to understand how these things are initialized, and relationships between them.

    And in my case trying to get more of a handle why a program like unCannyEyes crashed and/or wiped out memory if the large data structures are stored in DTCM versus in program space...

    I am not sure if I should continue it here or in it's own thread. But again maybe someone else may find this interesting?

    The version of UncannyEyes that had tendency to wipe out USB, sometimes could recover using program button, other times the 15+ second recover...
    Code:
    "D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_666019/uncannyEyes0.ino.elf"
    Sketch uses 211648 bytes (20%) of program storage space. Maximum is 1048576 bytes.
    Global variables use 5768 bytes (2%) of dynamic memory, leaving 256376 bytes for local variables. Maximum is 262144 bytes.
    I then used the nm command to dump the names of the structures and the like (same thing that Frank used to print out additional information...
    There are several interesting sections of manual talking about memory:

    Chapter 30: Talks about the FlexRAM of the T4, which I believe has 512KB, and this RAM is divided up into 16 Banks of memory or 32Kb per bank. And each of these banks
    can be assigned to ITCM, or DTCM or OCRAM

    Chapter 2: Shows the Arm Platform Memory map: Things like:
    0-0x7FFFF - ITCM (512KB)
    0x20000000 - 0x2007FFFF - DTCM (512KB)
    0x20200000 - 0x2027FFFF - OCRMA2 (512KB)
    0x60000000 - 0x6FFFFFFF - FLEXSPI ...

    Note: There are some Hardware registers setup at startup time that controls some of this.
    Now what does some of this stuff mean?

    If we look at the start of ResetHandler we see:
    Code:
    __attribute__((section(".startup"), optimize("no-tree-loop-distribute-patterns"), naked))
    void ResetHandler(void)
    {
    	unsigned int i;
    
    #if defined(__IMXRT1062__)
    	IOMUXC_GPR_GPR17 = (uint32_t)&_flexram_bank_config;
    	IOMUXC_GPR_GPR16 = 0x00000007;
    	IOMUXC_GPR_GPR14 = 0x00AA0000;
    	__asm__ volatile("mov sp, %0" : : "r" ((uint32_t)&_estack) : );
    #endif
    	// pin 13 - if startup crashes, use this to turn on the LED early for troubleshooting
    	//IOMUXC_SW_MUX_CTL_PAD_GPIO_B0_03 = 5;
    	//IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_03 = IOMUXC_PAD_DSE(7);
    	//IOMUXC_GPR_GPR27 = 0xFFFFFFFF;
    	//GPIO7_GDIR |= (1<<3);
    	//GPIO7_DR_SET = (1<<3); // digitalWrite(13, HIGH);
    
    	// Initialize memory
    	memory_copy(&_stext, &_stextload, &_etext);
    	memory_copy(&_sdata, &_sdataload, &_edata);
    	memory_clear(&_sbss, &_ebss);
    First we have: IOMUXC_GPR_GPR17 = (uint32_t)&_flexram_bank_config;
    Which defines what each of the 16 banks of FlexMemory is used for (00 not used, 01 OCRAM, 10 DTCM, 11 ITCM).
    Which from my dump of symbols for this case is defined: aaaaaaaf A _flexram_bank_config
    So in my case First two Banks or 64K is ITCM, the other 14 banks or 448K is DTCM


    Next: IOMUXC_GPR_GPR16 = 0x00000007;
    Says: Use FLEXRAM_BANK_CFG to configure, DTCM is enabled, ITCM is enabled

    Next: IOMUXC_GPR_GPR14 = 0x00AA0000;
    Says DTCM and ITCM are both 512KB? Again not sure what that means other than to say that space is valid but maybe does not have memory backing it?

    Also I don't fully understand relationship with which banks are allocated to ITCM versus DTCM and which addresses in ITCM and DTCM ranges are valid? i.e. could I choose any two random banks to be the ITCM and it would work the same? Or does choosing the first two, imply address starting at 0 (in ITCM case), but if first bank was DTCM and second was ITCM then you should put code at 32K starting?

    We then setup stack pointer: __asm__ volatile("mov sp, %0" : : "r" ((uint32_t)&_estack) : );
    20070000 B _estack
    Which looks valid? It is at the boundary just above 14*32KB, but I am assuming it will decrement this value before it actually writes to it...

    Then we have two memory copies (dest, source, dest_last)

    First copy: memory_copy(&_stext, &_stextload, &_etext);
    00000000 T _stext
    60001880 A _stextload
    00009af0 T _etext
    So we are copying: 39664 bytes to ITCM starting at 0

    Then second copy: memory_copy(&_sdata, &_sdataload, &_edata);
    20000000 D _sdata
    6000b37c A _sdataload
    20029320 D _edata
    Or again we are copying: 168736 bytes to DTCM

    And then it clears a memory range: memory_clear(&_sbss, &_ebss);
    20029320 B _sbss
    2002d2c0 B _ebss
    Or again clearing out another: 16288 bytes.

    So far I have not found anything obvious where we are going out of bounds or the like. So again maybe barking at the wrong tree. I may also extract some of the same data sizes and the like for a version of the program that told all of the large data arrays to stay in program space.

    Also want to look a little more into see if there is something that configures if all of the memory banks are active or not. That is I thought I saw some reference to maybe some of the banks are maybe not active in low power mode or... But again need to look a bit more.

    EDIT Some data from a version that add PROGMEM onto the large structures:
    ------------------------
    Code:
    "D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_746535/uncannyEyes_async_st7735.ino.elf"
    Sketch uses 209312 bytes (10%) of program storage space. Maximum is 2031616 bytes.
    Global variables use 62640 bytes (5%) of dynamic memory, leaving 985936 bytes for local variables. Maximum is 1048576 bytes.
    Code:
    aaaaaaaf A _flexram_bank_config
    
    20070000 B _estack
    
    00000000 T _stext
    600286d0 A _stextload
    000091f0 T _etext
    
    
    20000000 D _sdata
    600318cc A _sdataload
    200018e0 D _edata
    
    200018e0 B _sbss
    200062c0 B _ebss

    Also again sorry for this long rambling. I am just trying to get more of handle on how all of these memory pieces played with each other...
    Last edited by KurtE; 08-20-2019 at 11:23 PM. Reason: Added info from version that leaves data in PROGMEM

  25. #4125
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    5,421
    Sorry for endless information But I wanted to make sure it was not just as simple as a large amount of data in DTCM... SO did a quick and dirty version of the ili9341_t3 pictureembed, with two full size 240x320 images and I made sure to not have PROGMEM...

    Code:
    Sketch uses 334864 bytes (16%) of program storage space. Maximum is 2031616 bytes.
    Global variables use 339584 bytes (32%) of dynamic memory, leaving 708992 bytes for local variables. Maximum is 1048576 bytes.
    D:\arduino-1.8.9\hardware\teensy/../tools/teensy_post_compile -file=T4_ili9341_pictureEmbed
    I believe it has more DTCM in it, but less ITCM: And it has
    Code:
    aaaaaaab A _flexram_bank_config
    20078000 B _estack
    
    00000000 T _stext
    60001610 A _stextload
    00004bc0 T _etext
    
    20000000 D _sdata
    600061d4 A _sdataload
    2004ba40 D _edata
    
    2004ba40 B _sbss
    2004e2c0 B _ebss
    And if anyone wants to try it:T4_ili9341_pictureEmbed-190820a.zip

Posting Permissions

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