Teensy 4.1, LVGL, RAM1 optimization

H

Harry888

New member
Hello

I'm new to teensy.
My project is written mostly in C++
I'm using LVGL library.
Now I'm running out of RAM1

teensy_size: Memory Usage on Teensy 4.1:
teensy_size: FLASH: code:388392, data:70840, headers:8732 free for files:7658500
RAM1: variables:137664, code:385304, padding:7912 free for local variables:-6592
teensy_size: RAM2: variables:12416 free for malloc/new:511872


But RAM2 seems to be free.

So I'm at the point where I have to optimize my code.
I've found this page that describes some memory possibilities

github.com

Memory Mapping

Teensy PJRC WIKI . Contribute to TeensyUser/doc development by creating an account on GitHub.
github.com github.com

I have 2 questions:
1.
class XY {};
XY * a = new XY();
Where will be created the a object in RAM1 or in RAM2? (It seems like it is RAM1)
Is it possible to create objects in RAM2?

2. Is it possible to enhance RAM 1 or is the only way to move variables and array to RAM2 ?

Thank you in advance
Harry
 
Some of this is covered on the Teensy 4.1 product page in the memory section.

Teensy® 4.1

www.pjrc.com www.pjrc.com

new and malloc are created in RAM2 (DMAMEM)

You can add DMAMEM to a declare to move it to RAM2, however RAM2 variables cannot be initialized.

Large initialized data tables and the like, which you do not change you can declare with PROGMEM keyword. These
structures are directly accessed from FLASH and do not take space in RAM1 or RAM2.

RAM1, which is 512kb in size is made up of DTCM (data) and ITCM(Instructions i.e. code)
The system allocates 32k chunks to code. The report you show, says that of the 512KB of RAM1 396kb is taken up by the code.
So one way to get more data space is to move as much of the code as possible out of ITCM and left to run from Flash.

The main way to do this, is to add the FLASHMEM keyword to functions, which will cause them to run from the flash.

As mentioned in the above link, access to the flash is not as fast as access to the Tightly Coupled memory (TCM), so you should try
prioritize leaving code that you need to run fast in ITCM.
 
I have divided my code into 2 parts
1. Classes that communicate with the CAN interfaces
2. Classes that use LVGL to show the inputs of CAN interfaces

So I'm able to compile these 2 packages separately

The result of package 1 compilation is:
teensy_size: Memory Usage on Teensy 4.1:
teensy_size: FLASH: code:151536, data:19400, headers:8260 free for files:7947268
teensy_size: RAM1: variables:20480, code:147920, padding:15920 free for local variables:339968
teensy_size: RAM2: variables:12416 free for malloc/new:511872

And the result of package 2 compilation is:
teensy_size: Memory Usage on Teensy 4.1:
teensy_size: FLASH: code:287192, data:58552, headers:8556 free for files:7772164
teensy_size: RAM1: variables:125344, code:284104, padding:10808 free for local variables:104032
teensy_size: RAM2: variables:12416 free for malloc/new:511872

If I compile both packages together, the result is:
teensy_size: Memory Usage on Teensy 4.1:
teensy_size: FLASH: code:388344, data:70840, headers:8780 free for files:7658500
RAM1: variables:137664, code:384344, padding:8872 free for local variables:-6592
teensy_size: RAM2: variables:12416 free for malloc/new:511872

I see that the using of CAN 2 is always the same.

I create my objects in the 1. and in the 2. Package with new().

So I assume the usage of the CAN2 can not be the same.
 
Sorry, I am not sure how much help any of this will be, as I have never used LVGL nor CAN. So can only mention some generic stuff.

If your objects are defined like:

MyObjectClass instance;

By default, all of the instance data for this object will be created in RAM1. The system will know the size of it and that size will be
reflected in the memory usage sizes you see.

Ditto for: DMAMEM MyObjectClass instance;
Like the above, except the data will be in RAM2...

If, however, if you do: something at runtime like: myIstance = new MyObjectClass();
The build system does not reflect these sizes in the build numbers reported.

However: the system will include the code for that class, using the stuff I mentioned earlier. By default, all of it will go into ITCM (RAM1), unless the code is marked FLASHMEM

If a class has Static member variables, those variables will be stored wherever you have defined them in the code. By default, DTCM (RAM1).
 
Thank you for that information !!!

But if all objects are in RAM 2 and the compiler says there is not enough RAM1.

The only things I can optimize are libraries, but I need them.

What do you think?
 
If you look at your numbers:
Code: 
RAM1: variables:137664, code:384344, padding:8872 free for local variables:-6592
You notice that a lot of it it taken up by code: 384344 and another 8K of padding as to round up the code usage to 32kb blocks...

So if for example if you could move about 24K of the code into FLASHMEM... then it will free up a block that was used for
program space and make it available for data.

There have been a few threads recently with similar issues of running out of memory:
Like:

You might take a look at it as well as other threads it links to, to see if there are other tricks you might want to try.
 
After a heavy abuse of Ctrl+V i added a FLASHMEM attribute to the majority of the LVGL functions and was able to reduce the RAM1 footprint by over a 100kB
Before:
Code: 
teensy_size: Memory Usage on Teensy 4.0:
teensy_size:   FLASH: code:230504, data:96236, headers:9128   free for files:1695748
teensy_size:    RAM1: variables:108544, code:220984, padding:8392   free for local variables:186368
teensy_size:    RAM2: variables:12416  free for malloc/new:511872
After:
Code: 
teensy_size: Memory Usage on Teensy 4.0:
teensy_size:   FLASH: code:264200, data:96236, headers:8200   free for files:1662980
teensy_size:    RAM1: variables:108544, code:114504, padding:16568   free for local variables:284672
teensy_size:    RAM2: variables:12416  free for malloc/new:511872
That's ~104K less.
 
You must log in or register to reply here.
Back
Top