Can I use a sdcard for holding led color values to get around SRAM limitations?

I have a custom made led matrix of ws2812b leds in a 16x10 layout. I want to do around 300 frames. As each led takes 3 bytes of space, I'm surpassing SRAM easily in 2 frames. I'm aware of #progmem (but doing a poor job at implementing it as I'm still new to programming in general), but even with my math I'll still be running into storage problems using that. I've been pretty excited about the creative possibilities as I just got into small electronics recently so I have a Nano, Uno, Mega and Due at my disposal with an sd card adapter for the uno/mega.

I had a few friends over who are familiar with the programming language (but not arduinos) and we struggled to get something to work. We found a few threads where GrumpyMike (who is very helpful from all the research and topics I found) about a similar issue but even with his example code we couldn't get anything together.

I spent about 30 hours on making a very large costume that uses this matrix and didn't even dawn on me how much difficulty we would have or be limited to when trying to put in frames of colors. I've been so busy working on the project physically I haven't been able to get to it mentally with the programming (while attempting to learn as I go). I've spent the last few days but just in a rut atm.

What you need to do is to transfer one frame at a time from the program memory into the SRAM ( read write memory ). Then you need to display that one frame to the Neopixels.

You can't go straight from the program memory to the Neopixels because the libraries expect it in a buffer that you can access normally. I haven't checked but I suspect reading the program memory will be too slow anyway.

but even with my math I'll still be running into storage problems using that.

Yes 300 frames will require - 160 * 3 *10 * 300 is 1.44M of memory, by any stretch that is a lot for an embedded processor.

That suggests you should use an SD card and load the data off that into your one frame buffer, but again I am not sure of the refresh speed you will get.

Thanks for the response Mike. Whats the "10" in the 160 * 3 *10 * 300 formula represent?

I think sd card is the way to go like you mentioned, and testing the refresh speed to see if it is feasible. Still looking around on implementing it.

We were going off of this old thread you posted in to help us: Neopixel and SD card - LEDs and Multiplexing - Arduino Forum

using some of your code but we struggled and just a bit in over are heads with implmenting the basics with the sd card. I'll keep looking and trying and learning.

Whats the "10" in the 160 * 3 *10 * 300 formula represent?

Ah counted that twice it was 16 by 10 but I already covered that by the 160 sorry. It is still a lot of memory though.

There are two other things you can do to minimise the data you need to store.

  1. Set the LEDs in the buffer algorithmicley. That is write code that fills the buffer like you want. For example you only need four lines of code to set all the LEDs to a single colour or a range of LEDs. Your final pattern can be a call to each of these functions, like turn all LEDs off, fire a running slug in red to the end, and so on.

  2. You could compress the data. That is you have four bytes to define only the LEDs that change in the display from one frame to the next. The first byte is the LED number and the other three bytes the colour you want to change it to. The first byte in the frame is a count of how many LED changes there are. While this can use more data than storing each individual LED, normally it is a lot less and you can save a lot of storage space storing your patterns like this.

I'm making a mock tetris game, so I can see your second point doing well as once the tetris block is in position it pretty much will not change color/move for a decent amount of time. This would be quite a bit of work manually inputting it though if I'm imagining on how to implement it correctly. I do understand to be efficient this is a requirement though with programming. Your first point does seem like a good way to handle it also, but a little bit of work (which I don't mind if it is what needs to be done).

I was using a program (LED Matrix Studio) which would let me make the frames of animation and it spits out the hex code that also lines up with the way I wired it. Thats what I was using or trying to work with at the moment due to ease of use.

Thanks again for your response. No worries on the formula issue, I was just like... my math is horribly wrong if it uses 1.4 gigs for this animation ha.

I'm struggling with this maths too. Can someone tell me what I'm missing?

1 LED pixel = 3 bytes
1 frame = 160 pixels = 480 bytes
300 frames = 144,000 bytes or just a bit more than 140K

I've lost a factor of about 10000 somewhere.

Mike mentioned that he accidentally added a multiplier of 10 (he was thinking to do 16x10x3x300), but he had put 160 in which accounts for the 10x16.

I'm making a mock tetris game, so I can see your second point doing well

Well in that case the first point should be even better, just code a Tetris game.

This would be quite a bit of work manually inputting it though if I'm imagining on how to implement it correctly.

Yes but the point is that you don't input it manually, you get the computer to do the work. I have written something in the Processing language that will do most of the work for you.

I'm looking to duplicate an old YouTube video "line piece" that's a comedy bit. So I'm copying the same layout that happens in there. I'd like to put other things on it eventually so im hoping to get a code in place where I can hopefully use a led matrix program that spits out the frames and then I can put that into the spot where the Tetris frames are. Hopefully I described that right

I meant to reply back if I could see what your processing language looked like Mike as I hadn't seen that part of your response when I replied earlier. The site went down all day which made it pretty rough to troubleshoot things as everything comes back to this forum on Google.

If you're not okay showing the code no worries, thought I would give a shot to see what that looked like. Either way thanks for your responses and insight on ways to handle this project.