Go Down

Topic: Arduino IDE not incorrectly showing global memory correctly (Read 1 time) previous topic - next topic

wonderfuliot

Hi,

I am trying to find out the memory occupied by globals with below test code

Code: [Select]


//Force the compiler to allocate space even though the code does not use it
volatile char global_mem[16][40];

void setup() {
}

void loop() {
}


When Arduino Nano is selected as board, it shows below memory usage, which I believe is correct

Global array commented: Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.

Global array uncommented: Global variables use 649 bytes (31%) of dynamic memory, leaving 1399 bytes for local variables. Maximum is 2048 bytes.


However when ESP32 Dev Module is selected as board, it shows below usage irrespective of the array:(, it makes no difference whether array is commented or uncommented

Global variables use 13272 bytes (4%) of dynamic memory, leaving 314408 bytes for local variables. Maximum is 327680 bytes.


Why?


sterretje

The linker in the ESP toolchain might still be able to figure out if the variable is used or not anywhere in the code and throw it away, even though it's volatile.

Does anything change if you make use of the variable?
If you understand an example, use it.
If you don't understand an example, don't use it.

Electronics engineer by trade, software engineer by profession. Trying to get back into electronics after 15 years absence.

rhourahane

For this MCU the Arduino toolkit is based on the ESP32 toolkit. I would assume that it is this and it's support for WiFi and Bluetooth that is taking the space.

Juraj

the Espressif SDK is always linked to your sketch. without it the esp doesn't work

wonderfuliot

The linker in the ESP toolchain might still be able to figure out if the variable is used or not anywhere in the code and throw it away, even though it's volatile.

Does anything change if you make use of the variable?
The compiler/linker is not supposed to do any optimization for volatile, since its built into the language, complier/linker are supposed to follow the language specification.

I modified the code to use those variables but the result is still the same

Code: [Select]



volatile char global_mem[16][40];

void setup() {
  for(uint16_t i=0;i<16;++i){
    memset((void*)global_mem[i], 0, 40);
  }
}

void loop() {
}


wonderfuliot

Posted the issue at esp32 forum but no response yet from Espressif
Link to the same question at ESP32 forum


Juraj

Posted the issue at esp32 forum but no response yet from Espressif
Link to the same question at ESP32 forum


what you do not understand on that, that there are global variables initialized in SDK?

wonderfuliot

what you do not understand on that, that there are global variables initialized in SDK?
Juraj, I think you misunderstood my question. I know that there are lot other libraries and each may allocate globals. Thats fine and understandable.

My question is IF I declare my globals, then the available memory must go down, but it does not happen.
The available memory is same whether I declare globals or not.


Juraj

Juraj, I think you misunderstood my question. I know that there are lot other libraries and each may allocate globals. Thats fine and understandable.

My question is IF I declare my globals, then the available memory must go down, but it does not happen.
The available memory is same whether I declare globals or not.
here is raw output of xtensa-esp32-elf-siz, which is the source for the output in IDE

your sketch

Code: [Select]
section                                                         size         addr
.rtc.text                                                          0   1074528256
.rtc_noinit                                                        0   1342177792
.iram0.vectors                                                  1024   1074266112
.iram0.text                                                    48512   1074267136
.dram0.data                                                     8952   1073479680
.noinit                                                            0   1073488632
.dram0.bss                                                      5008   1073488632
.flash.rodata                                                  48592   1061158944
.flash.text                                                   102568   1074593816


emprty sketch

Code: [Select]
section                                                         size         addr
.rtc.text                                                          0   1074528256
.rtc_noinit                                                        0   1342177792
.iram0.vectors                                                  1024   1074266112
.iram0.text                                                    48512   1074267136
.dram0.data                                                     8952   1073479680
.noinit                                                            0   1073488632
.dram0.bss                                                      4368   1073488632
.flash.rodata                                                  48592   1061158944
.flash.text                                                   102540   1074593816


it looks like the array is not allocated as global. it is possible that the compiler moves it on stack of the function which calls setup() and loop() .dram0.bss changed

wonderfuliot

Well, if the globals are allocated on stack then its really strange.
How do I allocate a global table? :smiley-confuse:

westfw

Quote
I modified the code to use those variables but the result is still the same
Code: [Select]

volatile char global_mem[16][40];

void setup() {
  for(uint16_t i=0;i<16;++i){
    memset((void*)global_mem[i], 0, 40);
  }
}

void loop() {
}

When I compile that (Arduino 1.8.7, ESP32 1.0.0), I see the "global variable" space used change as I change the dimensions of the array (13912 bytes, as written. 13672 bytes for [10][40], 15272 bytes for [50][40]...)
Without the memset, is shows 13272 as you report...

Quote
The compiler/linker is not supposed to do any optimization for volatile, since its built into the language, complier/linker are supposed to follow the language specification.
It won't do any optimization of ACCESSES to volatile variables, but I think it will still delete the strorage entirely if it is not accessed at all....

I'm not sure why the behavior would be different between AVR and Xtensa, though.


Juraj

now i see that in my report the .dram0.bss changed

Go Up