user304: I would like to know how much RAM I am using in my project, as far as I can tell, there's no way to actually work that out (other than going through and calculating it myself). I have got to a stage in a rather large project where I have determined that I am running out of RAM. 
I have determined this because I can add a section and then all hell breaks loose somewhere else in my code for no apparent reason. If I #ifndef something else out, it works again. There is nothing programatically wrong with the new code. 
I suspected for a while that I was getting to the end of available RAM. I don't think I'm using too much stack (although it's possible), what is the best way to determine how much RAM I am actually using?
Going through and trying to work it out, I have problems when I get to enums and structs; how much memory do they cost? 
first edit: ALSO, I have edited my sketch so much since starting, these are not the actual results I initially got, but they are what I am getting now. 
  text     data     bss     dec     hex filename
 17554      844     449   18847    499f HA15_20140317w.cpp.elf
 16316      694     409   17419    440b HA15_20140317w.cpp.elf
 17346      790     426   18562    4882 HA15_20140317w.cpp.elf

The first line (with text 17554) was not working, after much editing, the second line (with text 16316) is working as it should. 
edit: the third line has everything working, serial reading, my new functions, etc. I essentially removed some global variables and duplicate code. I mention this because (as suspected) it's not about this code per sae, it has to be about the RAM usage. Which brings me back to the original question, "how to best measure it" I'm still checking out some answers, thanks.
How do I actually interpret the above information? 
So far my understanding is: 
`TEXT` is program instruction memory
`DATA` is variables (unitialised?) in program memory
`BSS`  is variables occupying RAM

since BSS is considerably less than 1024 bytes, why does the second work, but the first doesn't? If it's DATA+BSS then both occupy more than 1024. 
re-edit: I edited the question to include the code, but now I've removed it because it really had nothing to do with the problem (other than maybe poor coding practices, variable declarations and the like). You can review the code by looking back through the edits if you really want to see it. I wanted to get back to the question at hand, which was more based around: How to measure RAM usage.

user19409: There is a program called Arduino Builder that provides a neat visualization of the amount of flash, SRAM and EEPROM your program is using.
 
The Arduino builder makes up part of the CodeBlocks Arduino IDE solution. It can be used as either a standalone program or through the CodeBlocks Arduino IDE.
Unfortunately Arduino Builder is a little old but it should work for most programs and most Arduinos, such as the Uno.

user65: 
I suspected for a while that I was getting to the end of available RAM. I don't think I'm using too much stack (although it's possible), what is the best way to determine how much RAM I am actually using?

It would be best to use a combination of manual estimation and by using the sizeof operator. If all your declarations are static, then this should give you an accurate picture.
If you are using dynamic allocations, then you may run into a problem once you start deallocating the memory. This is due to memory fragmentation on the heap. 

Going through and trying to work it out, I have problems when I get to enums and structs; how much memory do they cost?

An enum takes as much space as an int. So, if you have a set of 10 elements in a enum declaration, that would be 10*sizeof(int). Also, every variable that uses an enumeration is simply an int.
For structures, it would be easiest to use sizeof to find out. Structures occupy a (minimum) space equal to sum of its members. If the compiler does structure alignment, then it may be more, however this is unlikely in the case of avr-gcc.

user83: When you figure out how to locate the generated .elf file in your temporary directory, you can execute the command below to dump a SRAM usage, where project.elf is to be replaced with the generated .elf file. The advantage of this output is the ability to inspect how your SRAM is used. Do all the variables need to be global, are they really all required?
avr-objdump -S -j .bss project.elf

project.elf:     file format elf32-avr


Disassembly of section .bss:

00800060 <__bss_start>:
        ...

00800070 <measurementReady>:
        ...

00800071 <cycles>:
        ...

00800073 <measurement>:
  800073:       00 00 00 00                                         ....

00800077 <measurementStart>:
  800077:       00 00 00 00                                         ....

0080007b <timerOverflows>:
  80007b:       00 00 00 00

Notice that this doesn't show stack or dynamic memory use as Ignacio Vazquez-Abrams noted in the comments below.
Additionally a avr-objdump -S -j .data project.elf can be checked, but none of my programs output anything with that so I can't tell for sure if it is useful. It supposed to list 'initialized (non-zero) data'.

user84: The main issues you can have with memory usage at runtime are:

no available memory in the heap for dynamic allocations (malloc or new)
no room left on the stack when calling a function

Both are actually the same as the AVR SRAM (2K on Arduino) is used for both (in addition to static data which size never changes during program execution).
Generally, dynamic memory allocation is seldom used on MCUs, only a few libraries typically use it (one of them is String class, which you mentioned you don't use, and that's a good point).
The stack and the heap can be seen in the picture below (courtesy of Adafruit):

Hence, the most expected issue comes from stack overflow (i.e. when the stack grows towards the heap and overflows on it, and then -if the heap was not used at all- overflows on the static data zone of the SRAM. At that time, you have a high risk of either:

data corruption (i.e. the stack ovewrites heap or static data), giving you ununderstandable behavior
stack corruption (i.e. the heap or static data overwrites stack content), generally leading to a crash

In order to know the amount of memory that's left between the top of the heap and the top of the stack (actually, we might call it the bottom if we represent both the heap and the stack on the same image as depicted below), you can use the following function:
int freeRam () {
  extern int __heap_start, *__brkval; 
  int v; 
  return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval); 
}

In the code above, __brkval points to the top of the heap but is 0 when the heap has not been used, in which case we use &__heap_start which points to __heap_start, the first variable that marks the bottom of the heap; &v points of course to the top of the stack (this is the last variable pushed on the stack), hence the formula above returns the amount of memory available for the stack (or the heap if you use it) to grow.
You can use this function in various locations of your code to try and find out where this size is getting dramatically reduced.
Of course, if ever you see this function return a negative number then it is too late: you have already overflown the stack!

user470: You can use the functions provided AVRGCC: Monitoring Stack Usage
The function was intended to check the stack usage but what it reports is the actual RAM that has never been used (during execution). It does so by "painting" (filling) the RAM with a known value (0xC5), and then checking the RAM area counting how many bytes have still the same initial value.
The report will show the RAM that has not been used (minimum free RAM) and therefor you can calculate the max RAM that has been used (Total RAM - reported RAM).
There are two functions:

StackPaint is executed automatically during initialization and "paints" the RAM with the value 0xC5 (can be changed if needed).
StackCount can be called at any point to count the RAM that hasn't been used.

Here is an example of usage. Doesn't do much but is intended to show how to use the functions.
// -----------------------------------------------------------------------------
extern uint8_t _end;
extern uint8_t __stack;

void StackPaint(void) __attribute__ ((naked)) __attribute__ ((section (".init1")));

void StackPaint(void)
{
#if 0
    uint8_t *p = &_end;

    while(p <= &__stack)
    {
        *p = 0xc5;
        p++;
    }
#else
    __asm volatile ("    ldi r30,lo8(_end)\n"
                    "    ldi r31,hi8(_end)\n"
                    "    ldi r24,lo8(0xc5)\n" /* STACK_CANARY = 0xc5 */
                    "    ldi r25,hi8(__stack)\n"
                    "    rjmp .cmp\n"
                    ".loop:\n"
                    "    st Z+,r24\n"
                    ".cmp:\n"
                    "    cpi r30,lo8(__stack)\n"
                    "    cpc r31,r25\n"
                    "    brlo .loop\n"
                    "    breq .loop"::);
#endif
} 


uint16_t StackCount(void)
{
    const uint8_t *p = &_end;
    uint16_t       c = 0;

    while(*p == 0xc5 && p <= &__stack)
    {
        p++;
        c++;
    }

    return c;
} 

// -----------------------------------------------------------------------------

void setup() {

Serial.begin(9600);
}

void loop() {
  // put your main code here, to run repeatedly:
Serial.println(StackCount(), DEC);  // calls StackCount() to report the unused RAM
delay(1000);
}


304: <p>I would like to know how much RAM I am using in my project, as far as I can tell, there's no way to actually work that out (other than going through and calculating it myself). I have got to a stage in a rather large project where I have determined that I am running out of RAM. </p>

<p>I have determined this because I can add a section and then all hell breaks loose <strong>somewhere else in my code</strong> for no apparent reason. If I <code>#ifndef</code> something else out, it works again. There is nothing programatically wrong with the new code. </p>

<p>I suspected for a while that I was getting to the end of available RAM. I don't think I'm using too much stack (although it's possible), what is the best way to determine how much RAM I am actually using?</p>

<p>Going through and trying to work it out, I have problems when I get to enums and structs; how much memory do they cost? </p>

<p><em>first</em> edit: ALSO, I have edited my sketch so much since starting, these are not the actual results I initially got, but they are what I am getting now. </p>

<pre><code>  text     data     bss     dec     hex filename
 17554      844     449   18847    499f HA15_20140317w.cpp.elf
 16316      694     409   17419    440b HA15_20140317w.cpp.elf
 17346      790     426   18562    4882 HA15_20140317w.cpp.elf
</code></pre>

<p>The first line (with text 17554) was not working, after much editing, the second line (with text 16316) is working as it should. </p>

<p><em>edit: the third line has everything working, serial reading, my new functions, etc. I essentially removed some global variables and duplicate code. I mention this because (as suspected) it's not about this code per sae, it has to be about the RAM usage. Which brings me back to the original question, "how to best measure it" I'm still checking out some answers, thanks.</em></p>

<p>How do I actually interpret the above information? </p>

<p>So far my understanding is: </p>

<pre><code>`TEXT` is program instruction memory
`DATA` is variables (unitialised?) in program memory
`BSS`  is variables occupying RAM
</code></pre>

<p>since BSS is considerably less than 1024 bytes, why does the second work, but the first doesn't? If it's <code>DATA+BSS</code> then both occupy more than 1024. </p>

<p><strong><em>re-edit:</em> I edited the question to include the code, but now I've removed it because it really had nothing to do with the problem (other than maybe poor coding practices, variable declarations and the like). You can review the code by looking back through the edits if you <em>really</em> want to see it. I wanted to get back to the question at hand, which was more based around: How to measure RAM usage.</strong></p>
 19409: <p>There is a program called <a href="http://arduinodev.com/arduino-uploader/" rel="nofollow noreferrer">Arduino Builder</a> that provides a neat visualization of the amount of flash, SRAM and EEPROM your program is using.</p>

<p><a href="https://i.stack.imgur.com/rwDID.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/rwDID.png" alt="Arduino Builder"></a> </p>

<p>The Arduino builder makes up part of the <a href="http://arduinodev.com/codeblocks/" rel="nofollow noreferrer">CodeBlocks Arduino IDE</a> solution. It can be used as either a standalone program or through the CodeBlocks Arduino IDE.</p>

<p>Unfortunately Arduino Builder is a little <a href="http://arduinodev.com/arduino-builder-updated/" rel="nofollow noreferrer">old</a> but it should work for most programs and most Arduinos, such as the Uno.</p>
 65: <blockquote>
  <p>I suspected for a while that I was getting to the end of available RAM. I don't think I'm using too much stack (although it's possible), what is the best way to determine how much RAM I am actually using?</p>
</blockquote>

<p>It would be best to use a combination of manual estimation and by using the <code>sizeof</code> operator. If all your declarations are static, then this should give you an accurate picture.</p>

<p>If you are using dynamic allocations, then you may run into a problem once you start deallocating the memory. This is due to memory fragmentation on the heap. </p>

<blockquote>
  <p>Going through and trying to work it out, I have problems when I get to enums and structs; how much memory do they cost?</p>
</blockquote>

<p>An enum takes as much space as an <code>int</code>. So, if you have a set of 10 elements in a <code>enum</code> declaration, that would be <code>10*sizeof(int)</code>. Also, every variable that uses an enumeration is simply an <code>int</code>.</p>

<p>For structures, it would be easiest to use <code>sizeof</code> to find out. Structures occupy a (minimum) space equal to sum of its members. If the compiler does structure alignment, then it may be more, however this is unlikely in the case of <code>avr-gcc</code>.</p>
 83: <p>When you figure out how to locate the generated .elf file in your temporary directory, you can execute the command below to dump a SRAM usage, where <code>project.elf</code> is to be replaced with the generated <code>.elf</code> file. The advantage of this output is the ability to inspect <em>how</em> your SRAM is used. Do all the variables need to be global, are they really all required?</p>

<pre><code>avr-objdump -S -j .bss project.elf

project.elf:     file format elf32-avr


Disassembly of section .bss:

00800060 &lt;__bss_start&gt;:
        ...

00800070 &lt;measurementReady&gt;:
        ...

00800071 &lt;cycles&gt;:
        ...

00800073 &lt;measurement&gt;:
  800073:       00 00 00 00                                         ....

00800077 &lt;measurementStart&gt;:
  800077:       00 00 00 00                                         ....

0080007b &lt;timerOverflows&gt;:
  80007b:       00 00 00 00
</code></pre>

<p>Notice that this doesn't show stack or dynamic memory use as Ignacio Vazquez-Abrams noted in the comments below.</p>

<p>Additionally a <code>avr-objdump -S -j .data project.elf</code> can be checked, but none of my programs output anything with that so I can't tell for sure if it is useful. It <a href="http://mcuoneclipse.com/2013/04/14/text-data-and-bss-code-and-data-size-explained/">supposed to list</a> 'initialized (non-zero) data'.</p>
 84: <p>The main issues you can have with memory usage at runtime are:</p>

<ul>
<li>no available memory in the <strong>heap</strong> for dynamic allocations (<code>malloc</code> or <code>new</code>)</li>
<li>no room left on the <strong>stack</strong> when calling a function</li>
</ul>

<p>Both are actually the same as the AVR <strong>SRAM</strong> (2K on Arduino) is used for both (in addition to <strong>static data</strong> which size never changes during program execution).</p>

<p>Generally, dynamic memory allocation is seldom used on MCUs, only a few libraries typically use it (one of them is <code>String</code> class, which you mentioned you don't use, and that's a good point).</p>

<p>The stack and the heap can be seen in the picture below (courtesy of <a href="http://learn.adafruit.com/memories-of-an-arduino/measuring-free-memory" rel="noreferrer">Adafruit</a>):
<img src="https://i.stack.imgur.com/waoHN.gif" alt="enter image description here"></p>

<p>Hence, the most expected issue comes from stack overflow (i.e. when the stack grows towards the heap and overflows on it, and then -if the heap was not used at all- overflows on the static data zone of the SRAM. At that time, you have a high risk of either:</p>

<ul>
<li>data corruption (i.e. the stack ovewrites heap or static data), giving you ununderstandable behavior</li>
<li>stack corruption (i.e. the heap or static data overwrites stack content), generally leading to a crash</li>
</ul>

<p>In order to know the amount of memory that's left between the top of the heap and the top of the stack (actually, we might call it the bottom if we represent both the heap and the stack on the same image as depicted below), you can use the following function:</p>

<pre><code>int freeRam () {
  extern int __heap_start, *__brkval; 
  int v; 
  return (int) &amp;v - (__brkval == 0 ? (int) &amp;__heap_start : (int) __brkval); 
}
</code></pre>

<p>In the code above, <code>__brkval</code> points to the top of the heap but is <code>0</code> when the heap has not been used, in which case we use <code>&amp;__heap_start</code> which points to <code>__heap_start</code>, the first variable that marks the bottom of the heap; <code>&amp;v</code> points of course to the top of the stack (this is the last variable pushed on the stack), hence the formula above returns the amount of memory available for the stack (or the heap if you use it) to grow.</p>

<p>You can use this function in various locations of your code to try and find out where this size is getting dramatically reduced.</p>

<p>Of course, if ever you see this function return a negative number then it is too late: you have already overflown the stack!</p>
 470: <p>You can use the functions provided <a href="http://www.avrfreaks.net/index.php?name=PNphpBB2&amp;file=viewtopic&amp;t=52249">AVRGCC: Monitoring Stack Usage</a></p>

<p>The function was intended to check the stack usage but what it reports is the actual RAM that has never been used (during execution). It does so by "painting" (filling) the RAM with a known value (0xC5), and then checking the RAM area counting how many bytes have still the same initial value.<br>
The report will show the RAM that has not been used (minimum free RAM) and therefor you can calculate the max RAM that has been used (Total RAM - reported RAM).</p>

<p>There are two functions:</p>

<ul>
<li><p><strong>StackPaint</strong> is executed automatically during initialization and "paints" the RAM with the value 0xC5 (can be changed if needed).</p></li>
<li><p><strong>StackCount</strong> can be called at any point to count the RAM that hasn't been used.</p></li>
</ul>

<p>Here is an example of usage. Doesn't do much but is intended to show how to use the functions.</p>



<pre class="lang-c prettyprint-override"><code>// -----------------------------------------------------------------------------
extern uint8_t _end;
extern uint8_t __stack;

void StackPaint(void) __attribute__ ((naked)) __attribute__ ((section (".init1")));

void StackPaint(void)
{
#if 0
    uint8_t *p = &amp;_end;

    while(p &lt;= &amp;__stack)
    {
        *p = 0xc5;
        p++;
    }
#else
    __asm volatile ("    ldi r30,lo8(_end)\n"
                    "    ldi r31,hi8(_end)\n"
                    "    ldi r24,lo8(0xc5)\n" /* STACK_CANARY = 0xc5 */
                    "    ldi r25,hi8(__stack)\n"
                    "    rjmp .cmp\n"
                    ".loop:\n"
                    "    st Z+,r24\n"
                    ".cmp:\n"
                    "    cpi r30,lo8(__stack)\n"
                    "    cpc r31,r25\n"
                    "    brlo .loop\n"
                    "    breq .loop"::);
#endif
} 


uint16_t StackCount(void)
{
    const uint8_t *p = &amp;_end;
    uint16_t       c = 0;

    while(*p == 0xc5 &amp;&amp; p &lt;= &amp;__stack)
    {
        p++;
        c++;
    }

    return c;
} 

// -----------------------------------------------------------------------------

void setup() {

Serial.begin(9600);
}

void loop() {
  // put your main code here, to run repeatedly:
Serial.println(StackCount(), DEC);  // calls StackCount() to report the unused RAM
delay(1000);
}
</code></pre>
