UPDATED: wiki page on "How To Set A Pixel's Color",

UPDATED: wiki page on “How To Set A Pixel’s Color”, with info on how to use Serial.readbytes to read data directly into the led array. http://code.google.com/p/fastspi/wiki/SetLEDColor
A “CRGB” is nothing more than a convenient wrapper for one byte of red, one byte of green, and one byte of blue. You are welcome, and invited, to directly access the underlying memory directly if it suits your purposes. The library assumes that you’re going to do this, and everything will still work the same as if you went through the CRGB:: methods.

Most of the CRGB:: methods compile down to fairly efficient machine code that directly accesses the underlying memory. If you’re trying to optimize for speed, make sure to actually do some real timing runs trying different techniques before you ‘decide’ which one is fastest; our intuitions about what’s faster and what’s slower aren’t always right.

To paraphrase Dr. Bronner, “Profile! Profile! Profile!”

Funny, this piece works:
for (int myCol = 0; myCol < columns; myCol++) {
for (int myRow = 0; myRow < NUM_LEDS; myRow ++) {
myFile.read((char*)(&leds[myRow]), 3);

However, trying to fill the entire array with

myFile.read((char*)leds, NUM_LEDS * 3);

… does not.

Also, I’m getting an average of 2,079 microseconds per loop, or 2,079 microseconds to read in 48 * 3 bytes. At this point I don’t know if I’m hitting the speed of the SD itself or whether it’s the library …

Never mind, it does work and it is much faster … when I slowed it down I could see the updates, but at full blast, the data gets horribly corrupted. Gotsa figure out why …

Ok so I have a question for you now: earlier on, you were the one who suggested the ‘made up’ format for the binary file:

and then the data for each pixel.

Since this is my first attempt at writing a c++ program to do this, when I got to generating the rgb values and saving them, all I could do was to save them as one byte per line, so I have
etc., etc.

Would it made any difference if they were saved differently?

The reason I ask this is because the author of the sd library is suggesting I read in a single line that contains all 48 * 3 values, as opposed to 144 lines.

In binary format though, I don’t know if that makes any difference … does it?

A ‘packed’ binary format (with no line breaks at all) will be much faster.

Wouldn’t that mean I have to unpack the data when I read it back in?

Think of it this way: prepare the image RGB data in memory on the PC EXACTLY the way you want it laid out in memory on the Arduino, and write it all out as one block of binary data onto the SD card. Then the Arduino code can call Serial.readbytes to load the LED data with no further processing required: no parsing ASCII, no linebreaks.

Therein lies the problem or problems. :slight_smile:

I’m going off of what I know, which originally started with me needing separate values for rgb so I can pass it to CRGB(r, g, b) … then I figured that I can read in 3 bytes and feed that into a specific pixel in the array. And now, I know I can read 48 x 3 bytes of data and feed it into the array. So I think it would make sense to says 144 bytes per line in the file. Whether that’s the correct answer or not, I don’t know.

But then there’s the other issue of, how do I actually do that in c++. This is my first time writing something like this, so I’m learning as I go. Right now the processing is getting the three values, and writing them one by one to the file. I have no idea on how to collect them together as a chunk and write that out.

for (myCol = cols - 1; myCol >= 0; myCol--) {
  for (myRow = rows - 1; myRow >= 0; myRow--) {
    ColorRGB rgb(img.pixelColor(myCol, myRow));
    red   = rgb.red()   * 255;
    green = rgb.green() * 255;
    blue  = rgb.blue()  * 255;
    myFile.write(reinterpret_cast <const char*> (&red),   sizeof(red));
    myFile.write(reinterpret_cast <const char*> (&green), sizeof(green));
    myFile.write(reinterpret_cast <const char*> (&blue),  sizeof(blue));

What SD library are you using?

Ashley, when you speak of “lines” you are talking text. If you store it as binary, then each 144 bytes will be copied bit by bit exact from the file to the CRGB array. There is no unpacking.

Maybe I’ll take a crack at this, I’ve been meaning to try out an SD card…

It’s in binary, not text. But I’m going after the c++ .write() call which automatically pushes the pointer to the next line, so I end up with a file that has the values one per line. However, I don’t think that’s the issue here …