I have a 200 LED WS2812 addressable strip which I want to subdivide into 100 2-LED sets, so when I reference to led[1] I'm actually making a reference to leds 2 & 3.
I could create manually 100 CRGBSet arrays of 2 items and store them into a single master array. But if next time I have an 1000 LED strip that would be way too much repetitive code to write manually. Is there a better way to approach this?
#include "FastLED.h"
#define NUM_LEDS 200
#define Data_Pin 13
#define chipset WS2812
#define BRIGHTNESS 50
// Array of all LEDs on the strip
CRGB stripLeds[NUM_LEDS];
//Define each 2 LED pixel
CRGBSet leds(stripLeds, NUM_LEDS);
CRGBSet leds1(leds(0,1));
CRGBSet leds2(leds(2,3));
CRGBSet leds3(leds(3,4));
.
.
CRGBSet leds100(leds(198,199));
//Store them on a single array where each element is a 2 LED wide pixel
struct CRGB * stripArray[] ={leds1, leds2, leds3... leds100};
Do you intend to always treat each set of two LEDs as if it were a single LED? If so, might be simpler to just modify the library routine that generates the LED data signal, so that it generates two LED's worth of data for each pixel.
I'll give this a try. The reason I want this is because I will mostly be using premade animations like this one, so I just want to modify the name of the array they use to address the pixels.
There's no doubt that my idea would require getting to know any canned processes a bit better…
It may be that @david_2018's suggestion would be a global solution for all the canned stuff you have.
But I am curious about the requirement. How are these pixels arranged physically?
Is each square poxel in that demo you linked to be two real pixels instead of one?
Besides I will admit I don't see how what you propose but don't like even works. But I use these at a very low level, so miss out on any structuring or naming advantages the library may afford.
That's because I might be wrong, I'm very new to arduino and programming so most of the things I get stuck with, are actually simple programming concepts, but I just don't know them as I am facing troubles and trying to solve them as I go. I understand these questions are annoying so I'm thankful for the patience and help.
My setup is something like this serpentine matrix. It's a single LED strip broken into rows. I have a grid, consisting in boxes, each box is lit by 2 LEDs, so when an animation is played, I want each box to be lit by a single color, so I have to treat every 2 consecutive LEDs as a single pixel.
Is each square poxel in that demo you linked to be two real pixels instead of one?
Yes, so instead of modifying every animation code I get, I would make a naming system and use that.
Sorry if it doesn't make any sense, I apreciate you even replying
NP. Just sitting here with a cup of coffee waiting on my beach buddy to let me know she's on her way…
and still curious about the physical arrangement.
I wonder aloud, so to speak, if it would be easier/possible to have two convential NxM matrices of LEDs, and place them so one was just offset to the other.
Not possible with premade arrays of LEDs, but if you were making them out of cut up strips or individually smart LEDs you could do that.
You'd still need to tinker with the software at a low-ish level… again every virtual pixel the program wants to change would become two real pixel calls
or
the two disjoint (not interleaved) matrices, now needing identical contents, could be driven off the same output pin.
If you could run two 100-LED strips parallel to each other, so that each block of two LEDs was composed of adjacent LEDs on the two strips, then all you need to do is drive the LED strips from the same pin. ( think I'm just rephrasing what alto777 said )
Another method is to use a dummy 100-pixel array for all the animation code, then copy that over to the actual 200-pixel array to send to the LED strip, expanding each pixel from the dummy array into two in the actual array during the copy.
It could actually be done with a single 200-pixel array, but only using the first 100 pixels for the animation code. When it is time to send the data to the LED strip, expand the 100 pixels to fill the 200 pixel array, call the display function, then if necessary compact the 200 pixels back down to 100 - this would be needed if the animation works off of the current contents of the buffer.
Now that you mentioned the phisical matrix offset method, it's actually 2 matrix of 100 led each, one comprised of the odds and the other from the even LEDs.
Not sure how to tackle that from code only but sounds like a path I should explore
Now this is the third mention of the easiest path given where I think you have arrived:
Simply connect the output pin to both strips.
Best practives would say put a series resistor (470 ohms) in each line from the output pin to DIn or whatever the input pin is called on you strips.
Digital outputs have a good deal of driving capability; digital inputs require very little current. So it is OK to drive several inputs with one output.
Yeah, I understood that my English is not the best.
I was thinking out loud if I could do it 100% from code by making 2 "virtual" matrices, basically 2 arrays, one containing all the odd LEDs and the other the even ones. And feeding them both to the animation simultaneously.
