When you say convert it to binary … care to elaborate?
As for the SD library, it’s faster than the stock library that comes with the IDE, and it’s way smaller.
I’m also wondering about pre-reading everything into an external flash, like Atmel’s dataflash modules, then access that while it’s running.
You are currently reading 5 bytes off of the sd card for every byte of data that you then have to explode to rgb data - you could shave off 40% of your transfer time and get rid of all time spent converting the data as well as the time being spent parsing 0x00, into a single byte of memory.
Well, I’m up for change. The code I’m using now is the original code for this specific POV system. Written by some guys in the Czech Republic. 
(That’s not to say they didn’t know what they’re doing!)
But, the limitations of the system became very apparent really fast. For example, each color has 4 intensity values, 00, 01, 10, and 11. Values (pre-shifting) are 0b1rr00000, 0b1gg00000, 0b1bb00000. Then they shift it all >>2 for green, >>4 for blue, put it all together and store that value. I would like to get more colors out of it, at the cost of space.
And then there’s the issue of having to reupload new code every time you want to change the displays.
Urgh.
Change processor with more SRAM memory. Use a teensy? Then, The teensy has a a DMA(?) that allows you to have memory accessed while you are doing other things…
While I do appreciate the suggestion to change AVRs (and ultimately I will,
but not for this purpose), it still won’t solve the problem. As a
performer, I’m stuck with a set of data unless I also carry a laptop with
me to reprogram and upload a new set. This is undesirable. If I can make
it work with an external storage device, like an SD card, then all I have
to do is swap cards. This is why I want to do this, to remove the
dependence of needing a computer to reprogram everytime. I can focus on
making a one time program and never touch it again. Just swap the SD and
you’re good to go.
As I said, I will swap AVRs for one that has builtin USB, not for the
larger SRAM.
If I was doing this, here would be my rough order of operations - first, switch from ascii readable files - they’re great for hand editing, and seeing what’s in them - but terrible for performance. A program to “convert” those ascii readable files to a better binary format should be pretty straightforward to do. Secondly, you could double, or even triple buffer, your reading. It makes for slightly slower startup (or, you could have the first two patterns be in memory, but that makes your logic a little bit more awkard elsewhere). Then you can interleave reading with pushing data out at a somewhat relaxed rate.
This, by the way, is one of the reasons i a) want to get DMA writing of data working on the teensy 3/due. and b) want the DMA code/interface to be as generic as the new SPI interface in FastSPI_LED2 is, so that it can be used for things other than just leds (e.g. like reading data from sdcard
I can’t wait to do a writeup on all the things that have nothing to do with LEDs that our library can be used for (unlike the first version of the library, this version has fully abstracted out high performance pin and spi access thought could be used independently
(also, I don’t know about anyone else here, but part of the thrill for me is the challenge to see just how much I can do with how little hardware - you should see people’s reaction when i tell them a single tiny arduino is running hundreds of rgb leds and patterns
How would you read in that binary data and pass it to CRGB()?
Basically, the file would simply be a set of rgb data, 3 bytes per pixel - then you could do:
SdFile.read(void*(leds + numPixelsReadSoFar), numPixelsToRead);
Then bytes go from sdcard right into ram - no translation/transformation, just sweet sweet data transfer.
(note - i’m not sure i’m looking at the right docs for the sdfat library - but it looks like there’s a method to read X bytes into a buffer of memory - memory is memory - this is also why I decided to standardize the CRGB class and RGB ordering, and deal with re-ordering at the controller level, to make direct mapping things like this a LOT easier to do
Yeah, in theory I understand what you’re saying. In reality though, I’ve never dealt with writing/reading binary files. I wouldn’t know how to create one, nor how to read it (though the latter I can probably figure out simply by trial and error and example code found on Google (and posted above.)
Still trying to wrap my head around this. What would I be storing, an array like {r, g, b} per pixel? Then read each one in and extract r, g, and b?
no - one problem is you’re thinking of the data file as a text file to read in - which happens often.
Instead, if you think of the file as a set of bytes, exactly like the rgb bytes sit in memory with you have CRGB leds[32]; <-- 96 bytes of data.
It means you can’t edit the file with a text editor, instead you’d need to have something that took in the text files you were used to working with and wrote them back out as binary files.
E.g. in C - on a unix/osx system, if i wanted to set a bunch of rgb data then write it out to a file i could do:
CRGB leds[NUM_LEDS];
int main(int argc, char *argv[])
{
// open the file for writing
FILE *fp = fopen(“myfile.bin”, “w”);
fwrite(leds, sizeof(CRGB), NUM_LEDS, fp);
fclose(fp);
}
this would write out one set of rgb led data.
Hrm, ok. I am looking for the “converting of an image file to the data I need” stage. So I was looking at some of ImageMagick’s routines and how they extract data from images. When you ask it for the color at a specific x,y coordinate on an image, it returns a value which once shifted gives you the r, g, and b values. So for example, $rgb = imagecolorat($img, $x, $y) would return say an $rgb value of 4344396.
Now you have
$r = ($rgb >> 16) & 0xFF;
$g = ($rgb >> 8) & 0xFF;
$b = $rgb & 0xFF;
That turns into r=66, b=74, g=76.
So that’s where I was trying to figure out, what am I storing, those {r, g, b} values, the single $rgb value (and parse back out when I read it back in)?
I mean, I can write that single (large) number to a binary file (binary, not text), but does it really make a difference if I need to parse it back once I read it in?
some of it is how much data you’re reading in. My suggestion, though was to write the r, g, and b values out - because then it’s 3 bytes being read in (vs. 4 bytes for what $rgb would be if you wrote it out as a binary int, or such) and no work to do to the data once you read it in as far as translations go.
So you’d store the r, b, and g values. Then you can just take the data from the file and it fits perfectly into the data structure that the led library is using, there’s no parsing at all - just reading data in and putting it right into memory.
Ok, so that’s my next step then, figure out how to store those individual r, g, and b values for each pixel that will make reading it back in easy and fast (with minimal to no post-processing, just read and pass.)
Is the code you are starting from available? It might be easiest to just show an edited version.