problems with array definition locking up program with COOL Video!

I am working on a project for Burning Man and am having problems with defining an additional array in my program.
I am using an array of unsigned longs in order to hold the RGB values for individual LEDs. I want to save the color that was originally set to an LED with another array which I am defining as an array of bytes. When I add the additional array Rdisp, the program freezes and won't do anything. I am thinking there is something going on here maybe with memory that I don't realize.

Here is the code:

#define LEDCount 160
unsigned long Disp[LEDCount];
byte Rdisp[LEDCount];

There are only two lines of code using this new array.
Here is the use of the code:

Disp[LED]= HSVtoRGB(1,Rdisp[LED], Saturation, 0x01);

The HSVtoRGB procedure just converts HSV to RGB and has an option byte at the beginning.
Here is the procedure declaration:
// ______________________________________________________________
long HSVtoRGB(byte option,byte inHue, byte inSaturation, byte inBrightness)

If I remove Rdisp declaration and use, everything works just fine.

Any ideas?

Here is a link to a video of the project if you are interested.

Perhaps you have run out of RAM?

The Disp array is 160 X 4(long)byte = 640 bytes. The Rdisp is 160 bytes. So that is 700 bytes, which leaves 300 bytes. I am using two libraries (wire and fastspiled) which will add to that I suppose. Not sure about the complexity of the memory scheme of the Arduino. Are you limited to 2k (SRAM of Pro328) of memory for your variables? I would think it would just page in stuff when it needed it but maybe I have too much confidence in the OS of the chip.

So the only think I can think of is that maybe I am crossing a page boundary or something like that in the program for the array and its having problems with that... but I defining it at the beginning of the program, so I thought I would get everything on a single page if that is the case. Is there a way to designate a location in memory to define your variables at?

It sounds very much as though you are out of RAM, but you would need to post all your code (between code tags - # button above) to get a better diagnosis.

Are you limited to 2k (SRAM of Pro328) of memory for your variables?


I would think it would just page in stuff when it needed it but maybe I have too much confidence in the OS of the chip.

No, it doesn't. You can pull static data out of progmem (search the forum) yourself though.

I put this code in that I found to look figure out the SRAM being used

Serial.print("free memory = ");
Serial.print(" - memory used = ");

int availableMemory()
int size = 2047;
byte *buf;
while ((buf = (byte *) malloc(--size)) == NULL);
return size;

And it was definitely a memory issue. I am really confused as to what is using so much memory. I changed the Wire library's buffer from 32 to 8 bytes since I am only sending 5 right now (leaving some for expansion) and that saved me 48bytes because there are 2 buffers. But I suspect a big suck is the Serial library and potentially the FastspiLED library... however I could not find it. Also spent quite a bit of time cleaning up and reusing variables. Its amazing how quickly 2k goes!

thanks for the help!

Ladyada gives a tip for shaving the serial buffer:

Besides your arrays, the current running program uses memory (called the stack) which include return values from loop(), local variables in loop(), etc.

Since you're using the fourth byte of the RGB longs, I won't suggest moving to BYTEs (3 bytes for RGB rather than 4, or 25% saving), but other options to reduce space may be to limit ranges of colors (eg, 32 instead of 256), or use a specific color table - for example, if you limit your display to 256 colors at a time, then each RGB value instead becomes a 1-byte index into this color table.

Thanks sir! I found the serial hack the yesterday but it only mentioned wiring_serial.c and not HardwareSerial. Thus I did not find it till today! Saved me 104 bytes! YES!

So basically between yesterday and today I managed to free up over 300 bytes! Thanks to ALL so much for all the advice!

The 2nd to the last pattern was what I was working on. Getting the random dots/stars to keep their color they start at. Looks awesome!

I have to store each of the 160 LEDs RGB value to pass to the FastSPILED library so not sure I can get away from having that... As far as the RGB considerations are concerned, I am using HSV to RGB to create those RGB values and am modifying Hue and Brightness(Value) but keeping Saturation at the full value. I am certain I could probably save something somewhere for not modifying the Saturation but don't have the time to figure that out. Besides... I have 150 free bytes as it is not... with keeping SRAM usage in mind, I should have plenty of variables available for use! Is there a way to define multiple names for a single variable? Sure this is likely possible with the #define directive but I don't program in C everyday so its not in the frontal cortex (backed up on tape somewhere surely)

You can use unions so a physical location has two or more names, whether that's what you want to use, however, is another matter.

Remember that local variables in a function disappear after the function ends. So if you need (say) 100 bytes of workspace for one routine and then don't need it after, put that code in a function, and the system will clear up after you.

Also, if you're using a lot of strings, you can reclaim their space (sometimes) by moving them to program storage.


Bravo! Excited to see this at Burning Man! Looks exciting!