Code style question… I have a 2 dimensional array of LEDs, I want to address things by both row and column. Physically, it’s one long ws2811 strip. How would people implement the software side?
I was thinking I’d end up with a a 2d array of pointers into the actual leds array. (and either c style pointers, or just the index positions). But, I’m wondering if there’s a best practice here.
I’ve always just done the one long strip alternating back and forth. Lets say it doubles back every 16 pixels. I have a method that all my led changing calls go through that takes an index and a color. if the index is in an even row don’t change it, but if its an odd row, invert it on that row, so basically:
int row = (Index/16);
int column = (Index%16);
if(row%2==0){
realIndex = (row*16)+(16-column )-1;
}
so I basically have methods that “assume” that the index is going from 0 to whatever but in a consistent “left to right for each row” manner, but I also have methods that take a row and column (or x and y) which just translate to the right index. Very handy when doing line drawing methods etc.
Right now, I’m basically doing this:
#define NUM_ROWS 11
#define NUM_COLUMNS 5
#define NUM_LEDS 55
for(int i = 0; i < NUM_LEDS; i = i +1 ) {
matrix[i/NUM_ROWS][i % NUM_COLUMNS] = i;
}
Which should let me bulk address anything in a row or column
I would go with a two dimensional array and let the compiler do the access and optimization.
Seph: are you trying to map from X,Y to pixel number (so that you can do stuff like plot(x,y,color) ) or are you trying to map from pixel number to the X,Y coordinates that it represents?
Broadly, in either case, RAM tends to be so scarce that the trade-offs most often favor not using a lookup table (which takes up RAM), but a lookup function, like:
CRGB& XYled(uint8_t x, uint8_t y) {
int index = (y * ROWS) + x;
return &(leds[index]);
}
Then you can, for example, do this:
XYled(3,7) = CRGB::HotPink;
Obviously, you have to adjust your “index = …” line to match your particular geometry etc.
Yeah, it’s a few more lines of logic for less ram. Usually an led arrangement can be described with code, I find its a little different for each project.
Heh. My other software work is showing. I’m more used to optimizing out that kind of lookup function with a memory table. Okay, I can invert that here.
Mostly I want to say things like “do FOO to row X”. But I can do that by iterating over all the leds and selecting for things that match a given row.
Yeah, here things are different, at least on AVR especially: 2048 bytes of RAM is all you get for stack, globals, LED buffer, wince heap, and shudder dynamic allocation (eg malloc).
On the other hand, while CPU cycles are scarce and precious, they’re still technically “unbounded.” (Ignoring here ‘real time’ constraints. But even so, an Arduino Uno gives you 16,000,000 clock cycles per second – and still only 2,048 bytes of RAM.)
This is also partly why people move static data to flash (PROGMEM).
EEPROM is really easy to use too!