Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 7 of 7

Thread: Teensy 4.1 stack size of 13k enough?

  1. #1
    Junior Member
    Join Date
    Dec 2021
    Posts
    11

    Teensy 4.1 stack size of 13k enough?

    Hi all,

    I am coding a little project for my model railway using some own code and some libraries (SPI, SD, NativeEthernet and Websocket).
    Compiling the project with -Og results in the following teensy_size output:
    Code:
    teensy_size*: Memory Usage on Teensy 4.1
    teensy_size*: FLASH: code:443968, data:41008, headers:9060   free for files:7632428
    teensy_size*: RAM1: variables:52228, code:441464, padding:17288   free for local variables:13308
    teensy_size*: RAM2: variables:24768  free for malloc\new:499520
    Line 3 means that 13308 bytes are left for the stack and interrupt handling, right? To me, this seems a little low and doing debug work, strange effects happen (e.g. only small packets are sent via ethernet, large ones kill the socket). Compiling with -Os, the code size is reduced to the following teensy_size output:
    Code:
    teensy_size*: Memory Usage on Teensy 4.1
    teensy_size*: FLASH: code:277032, data:31788, headers:9100   free for files:7808544
    teensy_size*: RAM1: variables:41892, code:274568, padding:20344   free for local variables:187484
    teensy_size*: RAM2: variables:24768  free for malloc\new:499520
    Here, I have plenty of space left and the application works without hiccups. I am totally fine with 55k of variables, but the code size is still very heavy.

    I already moved many strings to FLASHMEM but still struggle to reduce code size.

    Is there a way to check the stack size at runtime? Or is there a way to put code into the RAM2 for debugging sessions? Or put the stack on RAM2 instead?
    I also appreciate any other suggestion. With visual micro I have the option to compile my application, libraries and core with different optimization levels, but this is not the best idea, right?

    Thanks
    Daniel

  2. #2
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    10,339
    My rule of thumb is if I am concerned then I am concerned
    You may easily be fine, but sometimes best to be safe than sorry.

    If I run into things like this, some of the steps I might take, include some of the following. Usually I will look for some easy low hanging fruit.

    a) if You have some larger uninitialized buffers - I would consider moving them to RAM2, like:
    Code:
    DMAMEM uint16_t myScreenBuffer[320*240];
    b) If I have large constant tables, I would look to leave those tables in the flash memory and not copied to RAM1(DTCM)
    Code:
    static const uint8_t PROGMEM init_commands[] = {4, 0xEF, 0x03, 0x80, 0x02,
                                            4, 0xCF, 0x00, 0XC1, 0X30, 
                                            5, 0xED, 0x64, 0x03, 0X12, 0X81, 
                                            4, 0xE8, 0x85, 0x00, 0x78, 
    ...
    c) If you can reduce the code that is downloaded to RAM1(ITCM) by enough it will give that memory to DTCM. These are in chunks of 32K.
    That padding 20344 tells you that you used about 12K of the last ITCM page. So if you mark enough code with FLASHMEM like:
    Code:
    FLASHMEM void ILI9341_t3n::begin(uint32_t spi_clock, uint32_t spi_clock_read) {
    Then you could gain that 32k for data...

  3. #3
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,870
    KurtE's "c)" brings attention to first thought here on reading. In the first case:
    Code:
    teensy_size*: FLASH: code:443968, data:41008, headers:9060   free for files:7632428
    teensy_size*: RAM1: variables:52228, code:441464, padding:17288   free for local variables:13308
    That "padding:17288" is going to waste and would return 32K for RAM1 if ~15K of code was not in RAM1:ITCM

    Also ODD Both FLASH and RAM1:DTCM data/variables dropped ~10K when "Compiling with -Os", as shown in two size outputs in post #1

    Not sure if that points to something that could be worked with? When not using "-Os" the code consumes ~20K more data&variables?

  4. #4
    Junior Member
    Join Date
    Dec 2021
    Posts
    11
    Thanks for the idea with bringing initialization code also to FLASHMEM.
    As of now, I do not have large arrays which I can bring there, too.
    I am now close to 32k of padding and the rest I will find, too.
    Although I was bit worried that with added functionality, I will soon be in that area again...

    So I combed through the source and replaced stl libraries with little usage. Seems like #include <sstream> eats up 200k of code section ram:
    Code:
    teensy_size*: Memory Usage on Teensy 4.1
    teensy_size*: FLASH: code:258452, data:27696, headers:8796   free for files:7831520
    teensy_size*: RAM1: variables:33092, code:243512, padding:18632   free for local variables:229052
    teensy_size*: RAM2: variables:24768  free for malloc\new:499520
    I have no clue why as inspecting the file it is included in (only one cpp file), arm-size.exe reports 5744 in the text section and after removing the include, it only reports 2348. Where is the remaining 20000k?
    Who knows what other includes out there cause the remaining code size

    Thanks for your help, I learned alot

  5. #5
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,870
    That is a big change! : free for local variables:229052 - even FLASH code is smaller.

    Assuming that is not compiled '-0s' ?

    Feel free to leave more details on what was changed where to address the issue for others that run into similar issue.

  6. #6
    Junior Member
    Join Date
    Dec 2021
    Posts
    11
    As I said, I removed the #include <sstream> include I used for a custom integer-to-std::string function and replaced it with a manual conversion. The results shared were using only -Og.
    The strange thing is that the file sstream was included in shrinks from 5744 to 2348 according to arm-size.exe. I have no clue where the 200k come from.

    So lessons for all: remove standard library stuff if you can.

  7. #7
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,870
    Quote Originally Posted by danielkr View Post
    As I said, I removed the #include <sstream> include I used for a custom integer-to-std::string function and replaced it with a manual conversion. The results shared were using only -Og.
    The strange thing is that the file sstream was included in shrinks from 5744 to 2348 according to arm-size.exe. I have no clue where the 200k come from.

    So lessons for all: remove standard library stuff if you can.
    Good note. It was the massive 200K that suggested there was more at hand - that '#include <sstream>' must drag in a lot of baggage.

    Stack issue should be resolved now - room to grow!

Posting Permissions

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