What's really taking up all my SRAM?

Hi Arduino-ers.

I'm working on re-factoring some software for the pro mini into reusable libraries and have run into and SRAM issue.

My code size looks like:

text data bss dec hex filename
16328 456 2659 19443 4bf3 ...ino.elf

My question is, how do I figure out what is really taking up all that bss?

I understand that this is where uninitialized global or static variables live, but is it possible to inspect an intermediary file in the build and see what symbols are being loaded there?

Well, looking at your code, I see that it's ...

natester:
Hi Arduino-ers.

I’m working on re-factoring some software for the pro mini into reusable libraries and have run into and SRAM issue.

My code size looks like:

text data bss dec hex filename
16328 456 2659 19443 4bf3 …ino.elf

My question is, how do I figure out what is really taking up all that bss?

I understand that this is where uninitialized global or static variables live, but is it possible to inspect an intermediary file in the build and see what symbols are being loaded there?

Probably all of our “constant strings”.

The way the AVR’s access memory(Harvard Architecture) means that constant strings have to be copied from ‘Program Space’ to ‘Data Space’ By default EVERY constant string in your code is assigned space from your RAM. So, if you have:

Serial.println("Now is the time for all good men to come to the aid of thier fellow country men.  This can be Accomplished by the use of force in the governing of the populace.");

You will loose 160 bytes of avaliable RAM.

A better way is to use the F("") macro.

Serial.println(F("Now is the time for all good men to come to the aid of thier fellow country men.  This can be Accomplished by the use of force in the governing of the populace."));

This structure will only store the constant once in the FLASH ‘Program Space’, it does not use any RAM space.

Chuck.

thx ChrisTenone & chucktodd, the code is here:

the more general question of, where in the binary/assembly for bss section usage by symbol should be somewhere not in the code but in the object files, no?

Nvm, I found avr-objdump :slight_smile:

Avr-nm -SC --size-sort *.elf

text   data    bss    dec    hex filename

16328    456   2659  19443   4bf3 ...ino.elf

Probably all of our "constant strings".

In this case, the bss ("uninitialized data") is consuming much more memory the data section, so strings (which end up in data), are probably not the main culprit. In this case, I sorta suspect multiple copies of bitmap screen data (one in the app, one or more in the driver.)

text data bss dec hex filename
16328 456 2659 19443 4bf3 ...ino.elf

Well, that's not what I got when I compiled the version you linked to. I saw a more reasonable:

text data bss dec hex filename
25590 72 1427 27089 69d1 MW_OSD.ino.elf

That's still pretty big in the bss area. Running avr-nm -SC --size-sort *.elf | grep -i " b "
shows the big consumers as:

008005ad 00000025 b mode
008005dd 00000036 B fontData
00800561 0000004c B Settings
00800402 00000052 B screenPosition
008004b4 00000064 B sensorfilter
00800161 00000096 b serialBuffer
0080063e 0000009d B Serial
00800222 000001e0 B screen