Help! Possible to drive 6000 LEDs with color data loaded from SD card?

Daan

New member
Hi PJRC Forum!

For a project, I want to drive around 6000 SK6812 RGBW LEDs using OCTO WS2811 (spread over 8 data pins). In itself, that works perfectly fine, so thanks a lot to the person who wrote that amazing library! FastLED could never ;)

The catch is, I want to drive the LEDs with color values that are stored on the SD card. For each LED in one frame, I have a RGB HEX value. So 6000 hex values per frame. I want to run at around 30 fps. Meaning that it needs to read 180000 hex values every second, and then drive/assign them to the right LED using octows2811. Because I want to store minutes to hours of animations, I need to use a SD card to have the storage available. Just storing these arrays on local memory therefore isn't possible. I tried this, and this works, but then you can only store seconds of animations.

For the project I want to use the Teensy 4.1, with its build in micro sd card reader.

My question is, is this concept possible? Will a teensy be able to access the SD card fast enough, and also read fast enough? In order to maintain the 30 fps? This basically means that the reading and accessing of the SD card can not take longer than 1000/30 = 33ms.

Are there any fundamental things that would make this impossible? Would love to know, thanks in advance for any help!
 
I want to run at around 30 fps. Meaning that it needs to read 180000 hex values every second, and then drive/assign them to the right LED using octows2811.

For the project I want to use the Teensy 4.1, with its build in micro sd card reader.

My question is, is this concept possible? Will a teensy be able to access the SD card fast enough, and also read fast enough? In order to maintain the 30 fps?

Each RGB value is 3 bytes, so 180,000*3 540,000 bytes/sec. I just ran the "bench" example from the SdFat library, and for my 32GB Sandisk Ultra card with a 100 MB file, the average read speed is ~22 MB/s. Each 512-byte sector read is 22-23 us. Each of your frames is 6000*3 = 18000 bytes, or about 36 sectors, so you should be able to read each frame in will under 1 ms. Take a look at that example because the file is "pre-allocated", which I know is important for write speed and may also be important for read speed.
 
Even at 4 bytes per pixel, should be plenty fast enough. But to achieve good speed, you must read in large chunks which are a multiple of the sector size (512 bytes). Most modern cards have A1 or A2 spec, which means they're optimized (or at least have performance specs) for access in 4096 byte chunks, so reading in multiples of 4096 bytes might be a good plan.

If your frame size is 24000 bytes, best to use a larger buffer and read 24576 or 32768 bytes. When you're done with the first 24000 bytes, just copy the extra bytes to the beginning of the buffer and do another read from the card to fill enough of the buffer. If you oversize the buffer by 4095 bytes, you'll always have enough space to increase your read to the next multiple of 4096.
 
Even at 4 bytes per pixel, should be plenty fast enough. But to achieve good speed, you must read in large chunks which are a multiple of the sector size (512 bytes). Most modern cards have A1 or A2 spec, which means they're optimized (or at least have performance specs) for access in 4096 byte chunks, so reading in multiples of 4096 bytes might be a good plan.

If your frame size is 24000 bytes, best to use a larger buffer and read 24576 or 32768 bytes. When you're done with the first 24000 bytes, just copy the extra bytes to the beginning of the buffer and do another read from the card to fill enough of the buffer. If you oversize the buffer by 4095 bytes, you'll always have enough space to increase your read to the next multiple of 4096.

Thanks a lot! Very helpful information, I will start with coding then. Amazing that it will be possible, it's perfect for my use case. Thanks again!
 
Back
Top