Searching for ideas: as many of you may have noticed,

Archive FastLED Archive
1

Searching for ideas: as many of you may have noticed, I’ve been working on a POV display. By itself, it works great: the images are stored in PROGMEM and the code pulls stuff out of there. There are two issues with this though:
a) you’re always limited by the amount of memory the microcontroller has, and
b) in order to update the data, you need to recompile the code with the new data and upload it to the microcontroller

So, my goal is to add the ability to have an SD card that holds the images data sets. When it comes time to update, just replace the SD card with new data files.

Here’s the problem: reading an SD card takes for-e-ver! An 18K text file takes about 725ms to read in, let alone parsing the data. I can’t possibly be displaying one image on the POV system and change to the next one without a very noticeable pause, where nothing’s being displayed. I need to be able to switch from one to the next with no pause or break.

So this is where I need ideas. What would you do? One idea I have is to add external flash memory to the system. When it’s first turned on, it reads the SD card and dumps everything into flash memory. Then, as the system runs, it ought to be able to access that memory a lot faster than the SD card. If I have to wait 10-30 seconds at the beginning to save on the time it takes in between switching from one data set to the next, great. But I don’t know if that’s truly any better.

So, ideas, suggestions, declaration of insanity … Hit me!

2

whats your total size of program?

3

The actual program itself, which (at the moment) is only parsing the data and driving the LEDs, is about 4K. I suspect it will grow a little more once I tie all the pieces together (the SD library will take about 10-11K.) The patterns to be displayed however vary in size.

4

You could also read the new images in chunks - basically you have the image that is currently being displayed, and between each frame you read in, maybe 1/50th of the data for the next image to read in. Staggering your access and weaving things in and out.

Also - any chance you could preparse the data? that is, store the bytes in the file on the sdcard in the exact same way that they’re going to be in memory?

5

You’ve seen the code, it reads in a HEX value and uses R, G, and B masks to extract the necessary information for each color. I assume storing a single ‘0x74’ piece of data takes less space than storing {rr,gg,bb} for each pixel.

6

And I did think of the interleaving part, but some of the POV delays are less than 1ms … I don’t know that I can fetch data from the SD card in that amount of time, even if I read one single byte …

7

how big is the program likely to be with patterns etc?

8

sorry, i assumed that you would be on the arduino platform, but what platform are you using?

9

1ms is 16,000 cycles on the arduino :wink: The claim is you can read data off of an SD card as high as 600KB/s - that’s 600 bytes/ms - what are you using to talk to the SD card code wise?

Also - while 24 bits may be 3 times as much memory as the compressed format is using, the cpu time that you’re not spending doing the masking/building is that much more time that you have for pulling data off of the sd card.

sd card space is cheap, cpu time isn’t :slight_smile:

10

erm… sideways thought that i don’t even know if its possible, but can you have 2 arduinos, one with the code and the other with the patterns, and then pull the patterns from the second arduino?

11

You have the same communication issue pulling data from the other arduino as you do from the sdcard, roughly

12

http://diydrones.com/profiles/blogs/705844:BlogPost:48347
may be of help?

13

@Kelvin_Mead This is all on an Arduino platform. Right now, I can get somewhere between 5 to 9 images to fit within the 32K on an Uno. This is why I want to offload all of the image data. This will allow me to have more images as well.

@Daniel_Garcia Right now I’m using SdFat (http://code.google.com/p/sdfatlib/) which accesses the SD via SPI. At full blast (SPI_FULL_SPEED), an 18K text file (85 lines) is taking on average 717ms to read in (open file, read till no data, close file.) Reading a single line (open file, read line, close file) is reporting 3-4ms.

14

Keep the file open between reads - only close when you are done with the file. how long to read a single line not counting the open/close?

15

@Kelvin_Mead The idea isn’t to keep throwing larger and larger AVRs at it. It’s trying to come up with a workable solution first. :slight_smile:

16 
t = micros();
myFile.read();
t = micros() - t;

That reports, on average, t = 1176 microseconds.

Keep in mind, the line it’s reading is “0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x24,0x00,0x02,0x00,0x00,0x00,0x24,0x24,0x24,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,”

17

Oh man - preconvert that shit to binary, ditch the ASCII parsing entirely

18

And that specific pattern has a delay of 756 microseconds between string updates.

19

Also - that’s only 1ms :slight_smile:

20

I bet it’d be faster reading binary - I also suspect sdfat is not the fastest …