I'm working on a simple project with my Arduino. Recently I had to convert one of my variables to a long instead of an int, and in order to keep things simple I just moved over all the numbers that it interacts with (so I don't have to worry about cross-type comparisons and other math). This seems wasteful, but it's just a clock for myself, and I don't care that much.

It has, however, made me wonder about how much memory I am using. I doubt it's an issue, but I realized I don't know any way to check.

So, is there a way to check the amount of memory being used by an Arduino?

Ideally, I'd like to print out the current memory / total available over the serial connection.


2 Answers 2


A lot of the arduino stuff is handled underneath. You will see how much FLASH memory a sketch (program) will take upon compilation, but not the amount of SRAM memory. I recently had to discover this as well, and this is how I did it.

In the arduino IDE directory there is the avr-gcc compiler. It also contains a tool named 'avr-size'. Go to hardware/tools/avr/bin/ and it should be there.

When compiling, the IDE will create a temporary directory in your temp directory and copy all the C(++) files to it. It will compile the libraries, your sketch (it also adds the required things to make it functional) and create a hex and elf file. What you need to do is compile your sketch (by either clicking upload or verify) and look for a build[hash tag] directory in your temp folder. You need to run avr-size.exe and hand it the elf file.

It's quite tedious console work, but I usually navigate to the bin folder, run avr-size.exe and type the path to my temporary folder. This is C:\Users[your username]\AppData\Local\Temp\build[random tag][Sketch name].cpp.elf (Windows 7)

You could probably make up some (batch) script for this, but as the build folder remains constant on each arduino session, I don't bother.

The output of avr-size looks very similar to this (I have compiled an Xbee example program). Console output


  • text - flash data used for code
  • data - Memory with initialized data (the initial value has to be stored in FLASH too!)
  • bss - Memory that is initialized with zero's (the compiler will add some code so it will initialize data & bss)
  • dec & hex are a decimal and hex display of the combined RAM and FLASH size of your program.

The Arduino IDE reported to me this program is 3956 bytes big (FLASH). That's related to 3924 (code flash) + 32 (initial RAM values) = 3956 bytes FLASH. The RAM usage is data+bss combined(!) = 32+320 = 352 bytes SRAM usage.

Note the ATMEGA328 only has 2KiB of SRAM, and problems can already occur if you're below that (I've had unexpected behaviours at 1700 bytes out of 2048). The ATMEGA168 has 1KiB of SRAM. All Arduino mega's have got 8KiB of SRAM.

As an additional note. There are also 'free memory indicators' code available. What they do is try to allocate as much memory , count how big it was and free it up (malloc() & free()). If you initially haven't used malloc yet, this will add more code to your program you sometimes don't have space for. This is not ideal and I neither have found it to give stable results. In my own project I had ethernet+xbee+SD card + own library code running on an Atmega328. There just wasn't enough SRAM available, and FLASH became scarce as well).

And last but not least, this indicator doesn't account for memory allocated with malloc().

  • \$\begingroup\$ So thats the theoretical RAM allocation the compiled app will have? interesting. Still hoping theres some method to just pull the allocated RAM inside a sketch. \$\endgroup\$
    – MrGlass
    Dec 28, 2011 at 16:23
  • 3
    \$\begingroup\$ This is a good answer for fixed RAM allocations, however it's important to realize that it does not count the RAM used by automatic variables local to a function or block which are allocated on the stack at the start of execution of that function and deallocated at the end. That can only be determined by executing (or simulating) a particular path through the program - it is possible with recursion or function pointers to create a pathological situation of nested function calls where the memory consumption would depend on external inputs and could be potentially unlimited. \$\endgroup\$ Dec 28, 2011 at 16:28
  • \$\begingroup\$ I've just added some extra comments on program's that use malloc to figure out what the memory usage is. I don't really trust on these, and I think for an ATMEGA328 you neither should be using malloc (small chip). \$\endgroup\$
    – Hans
    Dec 28, 2011 at 16:29
  • 1
    \$\begingroup\$ @Hans - I wasn't even talking about malloc (though that obviously can be an issue too). Rather, when you create a local variable in a function, it is allocated on the stack at run time, not at compile time. If the function returns the memory is freed, but if the function calls itself, then yet another copy must be allocated. It's possible to analyze some programs and put limits on this, but for other programs where the path of calls depends on the run time inputs, it is potentially unlimited and cannot be determined without knowing the inputs. This can result in a stack overflow. \$\endgroup\$ Dec 28, 2011 at 16:33
  • 2
    \$\begingroup\$ @Hans - yes, fixed allocations free you from surprises, however they mean you can't re-use that memory for a different purpose in another function, unless you explicitly do it manually. Do that and you get into the territory where the bare-metal desire to hand-optimize and the CS desire for clean hierarchy come into conflict. The usual resolution seems to buying chips with more than 2K RAM when the task exceeds the simple and deterministic, and considering efforts to squeeze high level features out of constrained chips to be the programming version of extreme sports. \$\endgroup\$ Dec 28, 2011 at 16:47

Try using the MemoryFree library. This has worked well for me so far.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.