Closed Moonbase59 closed 3 years ago
1) Thanks! It all started on a flight with me sketching timing diagrams on paper and seeing how I could fudge the UART around to offload the ws2811 stream generation.
2) For dumb strips, you can use a cheap RS485 module and DM-103 DMX Decoder, then flash the serial version of the firmware. This is what I do for the washers inside my windows for Halloween - https://diychristmas.org/vb1/showthread.php?7274-ESPixelStick-RS485-DMX-Hack
4) This may come back in the future, but I need to re-structure some things first as the code and front-end was getting too cluttered.
5) I don't foresee us migrating to a library. I actually started with Makuna's NeoPixelBus when I was prototyping. At the time, it was bit-bang only and disabling interrupts causes nothing but issues on an ESP8266. After I came up with the UART method, he implemented it in the library. I then later took his UART async ideas and rolled them into this. I've read up on the DMA method, but haven't implemented yet.
7) GPIO3 is exposed as "RX" on the ESP-01 - https://circuits4you.com/wp-content/uploads/2016/12/ESP-01-Pin-Out.png
8) I'll take a look at it. If anything, it would be adapting the methods or using them as study for our own implementation. What would be ideal is an effects library where we can just pass it a buffer to be manipulated, agnostic to the physical output method. I don't want to exclude serial output or PWM (if it comes back) from effects. Maybe fork one of the projects and strip it down to just that? Or there may be something available, I haven't looked yet.
9) I have a ESP-12 based prototype, however I still plan on sticking with the UART method for backwards compatibility. It's main purpose is to add clocked pixel support (ws2801) and breakout the other pins for stackable mods (like rs485 output) - https://www.flickr.com/photos/sporadic/36098561862/in/album-72157635842416245/ and https://www.flickr.com/photos/sporadic/36223600856/in/album-72157635842416245/. I have another design in the works as well that offloads all the pixel generation to a small FPGA, but not ready to go there yet. I don't want to alienate those who want to build their own or just use something like a NodeMCU. I've looked at the ESP32 as well, however the SDK had many issues the last time I checked it out.
Happy Wife = Happy Life :) Thanks!
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 …
Effects should probably be informed of the actual physical layout, so we could use more than one strip or at least know more about what’s connected. For "dumb" strips, NUM_LEDS=1 would probably suffice, for other configurations it might be nice to work on kind of "flexible LED array" that could be, say RGB, RGBW, RGBWW, with the option to know whether to include the non-RGB channels in calculations or not. Thus, we could simply output to an RGBW strip by a) using only RGB and leaving the W alone to be controlled separately, or b) include all RGBW in the effect’s calculations to maybe remove the white part from the RGB and instead use the fourth channel for that.
This would also make it easy to maybe connect two strips to different pins and specify if effects should handle these as two entities or one long strip.
Thinking this a little further, we could even separate a long strip into several "logical" parts that could be handled individually (i.e., mirror every 2nd). This could easily make matrixes possible, simply by specifying that we have, say, 16 logical strips in a "long" one and every 2nd should be reversed (if using an "S" type connection, non-reversed on "Z" type).
Well, whatever. Just thinking out loud to consolidate ideas we both might have … :-)
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]
}
}
}
}
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.
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.
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.
'.text' will not fit in region 'iram1_0_seg'
all those template instances for every possible strip/chipset/rgb/pin/and what not combinations bloat up the code quite a lot.
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 :-)
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.
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.
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.
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.
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 ;-)).