FastLED discussion #339
Replies: 10 comments 1 reply
-
Happy Wife = Happy Life :) Thanks! |
Beta Was this translation helpful? Give feedback.
-
Thanks for willing to do a little brainstorming here, and actually explaing some backgrounds! 2. Unfortunately, being 59 years young, my eagle eyes still work on software but not that good on SMD soldering anymore ;-) I’m actually much more of a software guy than a hardware man. Nevertheless, I sometimes still like to tinker around … Thanks for the idea, though! 4. (5.?) Libraries: It’s always pros and cons. A library might not always do what you want, but you profit from many working on it, and code compatible with it. FastLED, for example, is now pretty sophisticated, and with Cory’s modifications, really usable. Not using a lib allows you to follow your own ideas but eventually, less people have to do all the work. It depends, I guess. 6. I totally agree. Using a buffer allows one to a) modify it in-place asynchronously even from more than one piece of code (like pixel auto-fade), b) decouples it from the actual output code. My secret hope would be to use the features of, say FastLED, and maybe output using your drivers. This should allow PWM, serial, and LED strips with clocking, as you say. 7. Thanks for sharing and let me know. I’m glad you still work on this. The NodeMCU is of course much too big for production use, but it’s still a nice prototyping board to hack something together on a breadboard. You could probably count me in for some of the new boards if we can settle this outside Amazon. Re effects in general: I dream of something like …
|
Beta Was this translation helpful? Give feedback.
-
Just so that no possible ideas get lost, here’s a rough estimate of an effects config (containing only "Solid") that I thought of. I realize that many params might actually be device parameters and probably need to be put into some device config. And maybe handled more generally in the main code, so the effect code can stay small. These would be for a "Solid" effect capable of:
All non-specified but existent "features" would be assumed unsupported, so not to over-complicate effects config. {
"Solid": {
"channels_per_pixel": [1, 3, 4],
"features": {
"brightness": {
"supported": true,
"min": 0,
"max": 255,
"default": 127
},
"reverse": {
"supported": false,
"default": false
},
"mirror": {
"supported": false,
"default": false
},
"white_compensation": {
"supported": true,
"default": false,
"channels": {
"4": {
"name": "Neutral White",
"kelvin": 8000,
"mired": 125,
"limit_brightness": 127
}
}
},
"gamma": {
"supported": true,
"min": 0.8,
"max": 2.7,
"default": 2.2
},
"duration": {
"supported": false,
"min": 0.5,
"max": 5,
"default": 1
},
"transition": {
"supported": true,
"min": 0.1,
"max": 3600,
"default": 0.5
},
"rgb_color": {
"supported": true,
"default": [127, 127, 127]
},
"rgbw_color": {
"supported": true,
"default": [0, 0, 0, 127]
},
"mired_color": {
"supported": true,
"default": 154
},
"kelvin_color": {
"supported": true,
"default": 6504
},
"hsv_color": {
"supported": true,
"default": [0, 0, 100]
}
}
}
} |
Beta Was this translation helpful? Give feedback.
-
I have actually experimented with FastLED in the past and found that for the most part on a NodeMCU everything performed fairly comparable, however on an ESP-01 like the ESPixelStick I had substantially more issues. I found that even with Cory's fork I was getting more dropped packets and visual glitches. I didn't look into it too much, but its possible its just FastLED is more computationally expensive causing device to fall behind a bit. That being said higher end ESPs are getting pretty cheap now and it might be worth supporting FastLEDs at least on more powerful chips. It does give a bunch of great features and tons of effects that can be integrated. Also drastically expands the number of supported LED strips. |
Beta Was this translation helpful? Give feedback.
-
The ESP-12 based NodeMCU uses the same ESP8266 as the ESP-01. Just packaged on different boards with different flash configurations and other niceties. Nothing that would affect processing in FastLED. @ahodges9 Where you using an ESPixelStick or an ESP-01 in another carrier board? Power filtering and antenna orientation come into play. The ESP-12 being shielded does help things a bit on the radio side. In regards to the JSON format, I had started work on something a little simpler than above. Basically referencing internal building block effects with configurable parameters. Unfortunately, I've been very busy lately and unable to work on it. |
Beta Was this translation helpful? Give feedback.
-
I have added FastLED to ESPixelstick: https://github.com/bugficks/ESPixelStick/tree/sambilight I was aiming for some generalized support so it would be possible to configure all the various strips with config file/webif but quickly ran into some size restriction problems. all those template instances for every possible strip/chipset/rgb/pin/and what not combinations bloat up the code quite a lot. |
Beta Was this translation helpful? Give feedback.
-
Just to say I’m still here. I’ve been occupied with lots of other projects in the meantime (and rebuilding my lab). Good to see everyone is "on board" again :-) |
Beta Was this translation helpful? Give feedback.
-
What happened with this thread? I'm curious about what path this is going on. The earlier post from @forkineye interests me as I've started working with other FPGA boards and letting the FPGA do the timing makes sense to me and FPGA chips can be purchased for under $5 so this wouldn't be a big cost adder. I'm willing to help with hardware if you guys can handle the firmware. |
Beta Was this translation helpful? Give feedback.
-
We have just gotten the code cleaned up with a great divide between input and output processing (very few cross dependencies). I would have to ask: What is the goal in adding an FPGA? More ports? The ESP 32 version has two WS2811 ports on it. More pixels on a port? The practical limit is 680 and the current implementation handles that easily. Most people seem to be using the ESPixelSticks as chicklets. THey are cheap and easy to integrate into the show. |
Beta Was this translation helpful? Give feedback.
-
It was something I was dabbling with way back with smaller relatively cheap fpgas. Target was 16 universes across 4 ports. Switched gears and back burnered it though. Lots has changed since then. And even though there are no plans to migrate to fastled, I left this open since there some good discussion and ideas in it. |
Beta Was this translation helpful? Give feedback.
-
I got square eyes this weekend reading, testing and diagnosing ESPS, the NeoPixel and FastLED libraries, MQTT and serial stuff. Here’s my findings:
You (@forkineye) did an absolute amazing job with your pixel drivers, integrating both flawless pixel output (even with data-only strips), serial Renard and E1.31 on a tiny device like the ESP-01. For DMX, it’s the most stable thing I ever came across.
My tests are done on Linux (I have no Windows), using several Lolin v3 NodeMCUs and WS2812B strips of varying lengths. I also have some "dumb" RGB strips which I will be trying to feed via a H801. And I’ll get a Wemos D1 mini soon, to have another testing platform, the original ESPixelStick unfortunately having prohibitive shipping cost to Germany. I use Atom to work on the code and upload with either the Arduino IDE or esptool.py. For DMX testing, I use both QLC+ and xLights.
ESPS is robust without end but turns out to be used with MQTT more and more, to provide a "double use" as show and home lighting controller, for instance with Home Assistant (which I also use). It lacks the groundwork for real great built-in effects, though.
Dumb RGB (PWM) output has been abandoned by ESPS (and continued in ESPixelBoard) but somehow I’d love to see "both in one" again.
The NeoPixel, NeoPixelBus and FastLED libraries come to mind.
I’ve been testing and banging my ESP-12 (NodeMCU) real hard with highspeed animations and MQTT (plus Home Assistant) at the same time using Cory’s FastLED over the weekend (it still runs) and couldn’t find a flaw. Tested with 60- and 300-LED WS2812B strips and runs buttery-smooth.
When using the PubSubClient, light effects will be halted whenever the ESP has problems connecting the broker (doesn’t get out of the MQTT loop). This seems not to happen when using the AsyncMqttClient. Conclusion: Stick with AsyncMqttClient.
I don’t currently have an ESP-01 (the one used in the original ESPS) here and thus don’t know if it has the pin, does DMA, has the CPU clock (I used 160MHz), and works. @forkineye?
If anyhow possible (and not interfering with other stuff you did), would it be possible to test Cory’s FastLED with your setup, be it only to have the groundwork for real good effects? (I don’t know how much work it would be a) simply using it or b) adapting it to use your pixel drivers.)
If all else fails (i.e., you like FastLED but it won’t work on the original ESPS), would you consider a "new edition" hardware based on an ESP-12 or even ESP-32?
I’d just love to see ESPixelStick live on, with more features and maybe even more modern hardware. (And the shipping cost drop, so we all could buy the board from you and you being able to make your wife and yourself happy, of course ;-)).
Beta Was this translation helpful? Give feedback.
All reactions