Simultaneously? On Uno, really, no.
You can connect, say, one strip of 30 leds to pin3 and other strip of 40 leds to pin5 - but it won't runs simultaneously on Uno. Uno can't call more than one ws2812 strip at the time. Therefore your two strips 30 and 40 leds will be acted as one of 70 leds.
Connecting multiple strips to Uno has the only advantage - ease of connection. It does not produce any other benefit.
True parallel connection of led strips can only work on powerful controllers such as Due, STM32 or Teensy
Nonsense. Of course it won't be truly "simultaneous". But within the memory limits of an Uno, you can connect multiple LED strips to multiple pins. You would then set colors on each of the CRGB arrays individually (but they could be part of a 2-D array). The single FastLED.show() function call will update all controllers that have been previously registered using FastLED.addLeds(). That update will happen sequentially from strip to strip. It won't be simultaneous on an Uno but it won't be simultaneous on any of the other processors you mentioned either. But it will look that way to the human eye. In fact, the update speed will likely be limited by the ws2812 protocol timing and not the processor.
What I mean:
If you connect two led strips to Uno, each with 100 diodes, then the total refresh time of the picture on two strips will be the same as on one of 200 diodes.
In contrast, on a Due, if you connect up to 11 strips, each with, say, 1000 diodes, the output time will be equal to the output of 1000 diodes only, since they will all be updated in parallel.
This mode is used to get high fps on large panels.
Sorry, but you are mistaken...
Look at the "block" mode in FastLed.
The code below from FastLED.cpp shows the CLEDController objects (referenced in a linked list) being updated sequentially. Please provide a link to the "block mode" reference documentation.
void CFastLED::show(uint8_t scale) {
// guard against showing too rapidly
while(m_nMinMicros && ((micros()-lastshow) < m_nMinMicros));
lastshow = micros();
// If we have a function for computing power, use it!
if(m_pPowerFunc) {
scale = (*m_pPowerFunc)(scale, m_nPowerData);
}
CLEDController *pCur = CLEDController::head();
while(pCur) {
uint8_t d = pCur->getDither();
if(m_nFPS < 100) { pCur->setDither(0); }
pCur->showLeds(scale);
pCur->setDither(d);
pCur = pCur->next();
}
countFPS();
}
Could you explain why you are using a two-dimensional array that does not fit the size of the LED strips? 156 LEDs starting at leds[0][0] will include all of leds[0], all of leds[1], and the first 36 elements of leds[2]. The 34 and 36 LED strips fit within their portion of the array, but are using the same memory as the 156 LED strip. Would be much better to use four separate arrays of the correct length for each strip.
// Define the array of leds
CRGB leds[4][60];
void setup() {
FastLED.addLeds<NEOPIXEL, 6>(leds[0], 156);
FastLED.addLeds<NEOPIXEL, 7>(leds[1], 34);
FastLED.addLeds<NEOPIXEL, 5>(leds[2], 36);
FastLED.addLeds<NEOPIXEL, 4>(leds[3], 10);
fill_solid( &leds[0][0], 156, CHSV(0,0,0)); // set starting state of LEDs to black
fill_solid( &leds[1][0], 34, CHSV(0,0,0)); // set starting state of LEDs to black
fill_solid( &leds[2][0], 36, CHSV(0,0,0)); // set starting state of LEDs to black
fill_solid( &leds[3][0], 10, CHSV(0,0,0)); // set starting state of LEDs to black
FastLED.show();
}
Unfortunately at the time I'd posted, 10 days ago, my status was basic and limited to a certain number of posts. I see I've earned some karma since and some badges so perhaps that'll be improved.
Wasn't able to go old school since I was crunching for a deadline to ship the next day. Just wasn't left enough time by the client to allow for my usual 2-4 week lead time to develop code to power LEDs.
In the end I solved it by putting all the LEDs on one data pin in one mammoth strip of 240-ish LEDs. I found if I hooked up more lights than that the Arduino started to lose the ability to power and properly address the lights due to the long length the signal was running.
I do need to find a way to make this flexible for the client who has limited technical knowledge but still needs to be able to set up the board. So I'll still be pursuing a solution where I can connect five strips each on their own data pin.
The longer explanation if anyone wants to read it: So I have different components of a game board that will be hooked up in a different configuration (location on the terrain table), different quantities, different ordering the electrical path, each time if wired in one long chain. Each component will have one of four lighting schemes. Red plants, purple plants, blue road stripes, green buildings, multi colored buildings. The scheme determined by their appearance. So my initial idea for ease of set up was to have all red plants on one pin, all purple on another, blue road on another, green buildings on yet another, and multicolored building on the fifth. I figured the client would be able to understand that easier than trying to wire each element together in the right sequence of one long chain... that ultimately wasn't able to be powered anyway. So five data pins is kind of a must. Unless the same problem will still be present on different data pins. FYI the power source was sufficient to supply the power so I'm assuming the issue was the data signal was unable to travel the full length of the wire I was asking it to travel. Odd results were appearing like multicolored LEDs and dimming. Seemed like a simple wire length
resistance issue.
I'll do some more work, refine my explanation and come back if I encounter any further problems.
Thanks everyone for your attention and effort on this.
Pic of deliered product with as many lights lighted as the board could handle. Which was 201. Could've added more without the data signal loss but ran out of time and didn't make sense if 100% of them weren't going to be lit properly.
Here (below) is the rendering the client approved. I'll be delivering it to GenCon in its final form so I have until August now to solve this. The full idea is the base boards can be reconfigured in any order, and elements can be placed anywhere. Board size is 6' long by 3' wide. Will be running all wires underneath. Not on top as shown in my previous post. The pic of my previous post was at Adepticon in Chicago this past weekend. BTW the road is animated now. Borrowed from the example code Cylonl to make it obvious the road pattern wasn't painted on as some onlookers thought. Borrowed a laptop at the show and coded it there.
Thank you. 3 months worth of work. Ultimately not a lot of time for something so detailed and involved but was worth it to make the show date. FYI the difference in road configuration between photo and rendering demonstrates one aspect of the boards intended modularity. I've got the road solved. Very simple. But having to add separate LED strips for each color of plant and considering all the possible ways the base boards can be configured complicated things quite a bit. But I think I've got a solid plan to accomplish. Just a matter of getting either the Arduino to cooperate or find a board that can handle what I need.
