# Arduino Mega 2560 like board but with more ram

I am making a POV RGB LED Globe that plays animations on its surface. Currently I am using a Arduino Mega 2560 with 256k of Flash Memory. My program and the boot loader take up 20k of memory leaving me with 236k.

There are 64 RGB LEDs using 8 bits of brightness that change color 64 times a revolution. $\left( 64 \cdot 64 \cdot 3 \cdot 8 \right) \div 1024 = 12\mbox{ kB}$ == 12288 BYTES

Each frame of animation takes up 12288 BYTES (12k) of memory. That only leaves me with 19 Frames of animation. Good but not great, at 10 frames a sec thats only 2 secs of animations. I was hoping for ~64 frames of animation or 768k RAM. (768+20=788k total)

I have tried a few load 'on the fly' and steaming methods (SD, Wireless) but they can't keep up with the data required while streaming the data to the LEDs. I am going to try using a simple compression method next but I don't have high hopes that the system will be able to uncompress the data while steaming the color information out to the LEDs.

I have currently tested 10 frames of animation using the Arduino Mega 2560 and it works. Kind of, there are still some bugs. But I don't really want to switch off an Arduino board if I can help it.

My questions are:

1. Are there pre-built Arduino boards with more ram?
2. Can I add RAM to an existing Arduino board?
3. Suggest a different Dev board thats is VERY similar to the Arduino with a c++ compiler.

Edit: I am using the "PROGMEM" keyword to store my animations in the Flash memory not the SRAM. http://www.arduino.cc/playground/Learning/Memory

• (64 * 64 * 3 ) / 1024 != 12288. Also, we have gorgeous LaTeX support through MathJax,, so that could be $\left( 64 \cdot 64 \cdot 3 \right) \div 1024 = 12\mbox{ kB}$ (right click to view source) – Kevin Vermeer May 10 '11 at 2:31
• By my calculations, your data requirements are only about 40 kB/second, which should be pretty easy with on-the-fly loading, SD cards, or (some) wireless networking options, as well as serial Flash memory (I think you want Flash, not RAM, for this). Could you explain how you ascertained that they can't keep up? – Kevin Vermeer May 10 '11 at 3:03
• 12kB a frame and 10 frames a sec for a total of 120 kB a sec. \left( 12 \cdot 10 \right) = 120\mbox{ kB} But you are right that does not make sense. The SD card should be able to keep up at that rate. I will edit the question with my experience with the SD card. – Steven smethurst May 11 '11 at 4:41
• @Steven - Surround math with \$ signs to invoke LaTeX formatting. However, I'm missing the point where you need to multiply by three - Do you have 8 bits for each color of the RGB LEDs? – Kevin Vermeer May 11 '11 at 12:36
• @reemrevnivek - Yes, 8 bits of brightness per color on the RGB LEDs. Sorry I should have been more clear. In other words it takes 3 BYTES or 24 bits for every single RGB LED. – Steven smethurst May 12 '11 at 23:43

Try using an I2C SRAM chip.

Maybe a 256 kbit N256S0830HDA @ 3V from AMI fits the bill: http://www.modtronix.com/products/components/ram/n256s0830hda.pdf

See http://arduino_related.livejournal.com/1414.html for a tutorial.

• Thats fantastic thank you, I think this is exactly what I am looking for. – Steven smethurst May 11 '11 at 4:46

Data compression may be an option. You probably don't NEED every iteration of the 255/255/255 data set. Even sticking with 256 colors would be more than enough for what you are trying to do.

Then each LED only needs 1 byte of information to store it's brightness setting, increasing the amount of frames available to 57, which would be pretty close to the 64 you were looking for.

If there's enough I/O pins left, you may try to connect the SRAM chip and manually control it. You could try to use extra latches to store the address, to reuse the same set of pins for both data and address busses (e.g. MCS-51 based systems used to use 74HCT373 to latch the lower part of the address bus, see here). This approach should allow for faster data transfers compared to I2C SRAM chips.

Note, that the memory of the size you need will most likely come in a TSOP package or similar.

• The requirement looks to be actually for flash rather than RAM, and there are plenty of those in 8-pin SOIC packages which will be easy to solder - just only solder one corner pin and verify alignment before soldering any others. And after doing a few of those, TSOP will not be intimidating. – Chris Stratton Nov 12 '14 at 16:44

You can't really expand the addressable RAM; the chip has whatever it has inside it and doesn't present a memory bus outside. You could add an SD shield such as this one and use it as a solid-state disk, much as you're doing now with the on-board flash.

Some people use several Arduinos (or other processor), each one running a small section of a LED display.

For example, perhaps you could use 8 Arduinos, each one responsible for 8 RGB LEDs of your total of 64 RGB LEDs. (While more Arduino Megas would work, this also opens up the option of using smaller, lighter, lower-cost Arduinos, such as the Arduino Pro Mini, that have far fewer pins than the Arduino Mega).

This allows you to scale up your display to any number of LEDs, far more than any one Arduino could handle.

• This is still not cost effective. Microcontroller on-chip storage is orders of magnitude more expensive than external memory chips made with a fabrication process optimized for storage. So while there is indeed a point at which adding additional processors makes sense (or where it makes sense to have a universal product manufactured at scale you can sometimes use more than one of), it makes sense to load each board up with additional storage before you add more boards. – Chris Stratton Nov 12 '14 at 16:42
• @ChrisStratton: I agree that "there is indeed a point at which adding additional processors makes sense". Feel free to edit this answer if there is a better way to express that statement. – davidcary Nov 12 '14 at 17:16