The build process should show ram consumption as well as flash consumption

[GoogleCodeExporter]

What change would like to see?
The build report, at least in verbose mode, should show the amount of RAM 
consumed by the sketch (data + bss) as well as flash memory consumed.

Why?
Currently you can write a sketch where bss + datasize is larger than the ram 
available in the chip, even before stack and heap are considered, and you don't 
get any warning at all, and the information that might have warned you is 
buried in the build directory .elf file "somewhere."
Ideally, the IDE would warn you when you are approaching or exceeding RAM 
limits for the selected board, but this is not currently included in the 
boards.txt info, so in the short term it would be useful to simply include the 
output of the avr-size command.

Would this cause any incompatibilities with previous versions?  If so, how
can these be mitigated?
I don't think so.  The patch attached computes flash size from the .elf file 
instead of the .hex file, but the results seem to be the same.

Attached diff does:
  1) pass "verbose" info from preferences or shift-key down to Sizer
  2) run avr-size on the .elf file instead of the .hex file
  3) cause the avr-size command and its output to be printed to the console in verbose mode.
  4) read tokens for text, data, and bss size and compute flashsize instead of assuming size of .hex file == size of flash.  Not all the values are actually used...

Currently compiled/tested on Mac only; but should not be OS dependent.

Original issue reported on code.google.com by wes...@gmail.com on 9 Nov 2010 at 6:40

• Merged into: #40

Attachments:

• sizer.diffs

[GoogleCodeExporter]

What does the output look like?  I'm reluctant to display the RAM usage without 
showing the total RAM available.  Would it be hard to extend the patch to grab 
the information from boards.txt?

Original comment by dmel...@gmail.com on 17 Nov 2010 at 4:42

• Added labels: Component-IDE

[GoogleCodeExporter]

The current output is just the output from size.  Note that boards.txt does not 
currently include any info about RAM size.  It's  "better than nothing" ?
(Sorry for the late reply.  I had my google code email set to an account that I 
wasn't reading very often.)

Volumes/Downloads/src/arduino-git/Arduino/build/macosx/work/Arduino.app/Contents
/Resources/Java/hardware/tools/avr/bin/avr-size /tmp/applet1234/optifix.cpp.elf
   text    data     bss     dec     hex filename
   7218      22     685    7925    1ef5 /tmp/applet1234/optifix.cpp.elf
Binary sketch size: 7240 bytes (of a 32256 byte maximum)

Original comment by wes...@gmail.com on 22 Jan 2011 at 3:25

[GoogleCodeExporter]

I also prefer the Arduino IDE can print out memory usage. Run avr-size on 
windows. The output message is as below. With this message, the programmer can 
easily be aware of if the skecth exceeds the program or data memory. In this 
example, the program memory overflows but the data memory not.

avr-size -C --mcu=atmega328p PachubeIn.elf

AVR Memory Usage
----------------
Device: atmega328p

Program:   36778 bytes (112.2% Full)
(.text + .data + .bootloader)

Data:       1190 bytes (58.1% Full)
(.data + .bss + .noinit)

Original comment by Jeffrey....@gmail.com on 17 Dec 2011 at 8:27

[GoogleCodeExporter]

Hmm.  I just noticed that "avr-size -C" will apparently how "% Full" info, 
given a CPU name (which we DO know.)  It's not quite as easily parsed (?):

 avr-size -C --mcu=atmega328p foo.elf
AVR Memory Usage
----------------
Device: atmega328p

Program:    2404 bytes (7.3% Full)
(.text + .data + .bootloader)

Data:        192 bytes (9.4% Full)
(.data + .bss + .noinit)

Original comment by wes...@gmail.com on 31 Mar 2012 at 3:46

[GoogleCodeExporter]

This has been requested for quite a while now.   See issue #40, which refers to 
an even earlier request on the forums!

This is one of those issues that experienced users can deal with, but it can 
really trip up beginners.

avr-size -C 

looks like it should be the fix!

Original comment by Robert.A...@gmail.com on 2 Apr 2012 at 4:28

[GoogleCodeExporter]

Original comment by dmel...@gmail.com on 3 Apr 2012 at 2:36

• Changed state: Duplicate