First, parallel output is now the default (no need to do anything special). You can add up to 8 strips and the driver will push bits out to all of them using the RMT peripheral (the magic of interrupts). There is a #define you can use to force serial output if you really want it (but why?!?!).
Second, you can compile it to use the standard RMT driver (from the ESP core) rather than our custom driver. This feature is useful if you have other parts of your code that need the RMT peripheral. Just make sure that you choose a channel at the upper range to avoid colliding with the FastLED channels (which start at 0). The downside is that it requires us to allocate a big buffer and translate all the pixel data into RMT items ahead of time – a 32X blowup in memory use.
Let me know if you run into any problems or have any suggestions.
Enjoy!
Excellent! Will this be merged into the one that shows up in the library manager soon? I just deleted what I had and added the ZIP file but it wants to update it every time I start the IDE.
+Sam, looking at the parallel example and not seeing the pins defined. I see other pins commented out for other boards. I see a header with a pin order for esp32 and PORTA_FIRST_PIN 32 in the header file. Never played with this example but I have three small strips I’d like to try. Sorry for the lame question but others might want to know too.
Works nice with my App Inventor BLE app. I modified the demo to pick the 6 patterns with buttons. Very fun way to interact with my leds. Is anybody else doing this with fastLED? A nice app inventor app that abstracts the pattern making would be better than just playing a few that are coded on the ESP32.
@Steve_Anken I’m not sure I completely understand the question, but parallel output is now the default, no matter how you set up the strips. For example, I just called FastLED.addLeds three times with three different pins/arrays. Then when you call show() they all get sent at the same time.
@Steve_Anken OK, I see what you’re saying. I have not implemented support for the existing parallel examples, which use a different FastLED controller.
@Sam_Guyer I haven’t played with this yet, but from the way you’re describing it, its all seamless behind the scenes? So you can declare each strip with its own pin individually, and they’ll all be published simultaneously?
As opposed to the original parallel output implementation where you defined it like PORTA<NUM_STRIPS*LEDS_PER_STRIP…
If so - that’s awesome!!! And are there restrictions as to which pins you can use? Or are any of the GPIO pins eligible? And can your strips be different lengths?
@chad_steinglass Yes, you can just add strips to any pin, the way you would for serial output, and the driver will push all the data simultaneously. It’s the magic of parallel computing! The RMT device is actually a separate little CPU, so I can just kick off the signal on each strip and then move on to the next one.
The only tricky part was making sure that it waits for all the strips to complete before returning from FastLED show. I didn’t want to get into trouble with race conditions on the state of the CRGB array.
