Just a quick question (for sure covered previously, but I was unable to find it): I use a Spark Core to run a 16x16 led array. It listens for TCP connections, and feed the byte values it gets to the led array. Speed is the most important, so I’m trying to fill my CRGB leds[256] as fast as I can. However, being a novice at C, I’m struggling. I’m trying to read 8 “pixels” (8x3 bytes) at a time like this:
for (uint16_t pixel = 0; pixel < 255; pixel+=8) {
client.read(&leds[pixel][0] , 24); // Reading 3 bytes directly into struct * 8 pixels
}
However, the display is messed up. Presumably it’s not so simple as feeding data directly into &leds[0], but how should I go about it, keeping in mind that I am trying to do this as fast as at all possible?
I’m not a SparkCore expert, but in general, if you can do fewer, but larger, IO operations, things go faster.
If I were going to read three bytes for each of 256 cells into an led array, I’d do just this, with no loop needed:
client.read( leds, (256 * 3) );
If for some reason you want or need to do it with a loop, I think your code is pretty close. When you say the display is “messed up”, could you expand on that a bit? For example: are the colors all wrong, or are alternating rows backwards, etc?
Actually, I suppose my main question boils down to this: can I assume that leds (declared as CRGB leds[256]) can be treated as if it was a single array of 768 bytes? So that I can use a pointer to update it? Or is the structure of a CRGB more complicated and my thinking too simplistic? 
Great question, @Ole_Jakob_Skjelten ! You can directly access the leds[] pixel array. See “Data Members” - “Direct Access” notes on this page:
I’ll paste the text here, too, for easier G+ searching by other people in the future:
"You are welcome, and invited, to directly access the underlying memory of this object if that suits your needs. That is to say, there is no “CRGB::setRed( myRedValue )” method; instead you just directly store ‘myRedValue’ into the “.red” data member on the object. All of the methods on the CRGB class expect this, and will continue to operate normally. This is a bit unusual for a C++ class, but in a microcontroller environment this can be critical to maintain performance.
The CRGB object “is trivially copyable”, meaning that it can be copied from one place in memory to another and still function normally."
Aha! Thank you - that’s exactly what I was looking for. The “Low level access” in the WIKI is a dead link, hence my questions here. Ok, then I know what to do
We’re in the process of overhauling the documentation; sorry for the dead link, and glad I could help out!
Now I’m curious: what data are you feeding and reading over the Wifi onto the panel?
Simple bytes. I have made a Python client that can show animated gifs, scrolling text messages (with AA) etc. The Spark Core then starts a basic TCP server listening for connections. The Python client connects and sends the “graphics” over to the Spark Core, which uses FastLED to display the graphics. Normally I’d send a “screenfull” of 768 bytes (16x16 leds) at a time, but weird error leads me to believe I have to segment it to preserve RAM on the Spark Core.
I also made an “emulator” that uses pygame to show what the LEDs would look like in a small window for “offline” testing without the LED, as I travel quite a bit, and can’t drag the LED display with me
It’s all here: https://code.google.com/p/superled/source/browse/#svn%2Ftrunk%2F%20superled
But as I used this project to teach myself Python, the code is, um, not exactly perfect.
Ah- cool! I like the emulator angle too – and I know exactly what you mean about carrying gear around. Nice, and can’t wait to see!