Can you document in your README.md how this library is better than FastLED?

[marcmerlin]

FastLED is the biggest cross platform library for addressable LEDs. It does not support RGBW as of right now, but is otherwise the best lib I've used. Can you document how your library is different/superior in ESP8266 to help users choose?

(on ESP32, it supports RMT, so I think it's better there)

[Makuna]

Please don't take this the wrong way.

I probably wont. It takes effort to test and compare, and time to continue to update it due to changes to both libraries. Too many moving targets.

The Wiki contains stuff I did a few years ago (https://github.com/Makuna/NeoPixelBus/wiki/Smaller-Code) and I am not sure it is even relevant anymore for FastLED. I still hear people talk about the NMI interaction on esp8266 with FastLED and I am shocked he still relies on it as there is no solid solution other than what I did with my several methods (and I am not the only one doing them).

The Wiki is open for editing if you wish to spend time and do the comparisons.

Heck, changes this last December to esp8266 and debug support using UART BROKE my async uart methods when used with any other serial and left me with the only solution is to fix their esp8266 code. Two pulls that have been out and ignored so long other changes came underneath them breaking each one and thus requiring rewrites each time. I just can't continue to spare my time to design around other peoples work. Sorry, a little sensitive about this one as I considered their work hacks they could have easily been supported after my changes were merged; but now requires me to rewrite THEIR stuff.

Yup Esp32 RMT is better if done right. I helped drive improving the API so it could be shared with other libraries, but again, I haven't needed it so it never got finished as I already have hardware support on esp32. There is branch/pull to add RMT support, but it was pre API fixes so I don't plan to support it. I hope he uses the new API, otherwise he will block RMT being used for other purposes like IR receiving and or transmitting at the same time.

[marcmerlin]

Thanks for your answer. I understand where you're coming from and your frustrations. Yes, you're right that FastLED still uses an NMI on ESP8266, although and maybe I've been lucky, it hasn't been an issue on my projects. It's fast enough that I can even run interrupt driven IR and it works at the same time. I did see some other project that uses I2S to do interrupt free DMA output on esp8266: https://github.com/JoDaNl/esp8266_ws2812_i2s/ but as cool as it is, its API for LED control is so limited that I'm not using it anymore. I did mention it on my blog I wrote at the time trying to find out the different libs (and I didn't know about yours back then) http://marc.merlins.org/perso/arduino/post_2017-04-03_Arduino-328P-Uno-Teensy3_1-ESP8266-ESP32-IR-and-Neopixels.html It's very cool alternate way to do DMA neopixels though. I do want to update my blog and mention your lib, though, as it seems like a better DMA API than what esp8266_ws2812_i2s provides, although I'll be honest that I kind of prefer the I2S implementation even if it's neopixel specific.

I can see how your use of the UART is another interesting way to do it, but sucks if the underlying arduino layer breaks you :(

I'm happy to try and write a small paragraph for your README if you'd like (as a PR) and you can correct it if it's not quite right. Ultimately one big issue with projects on github is that there are multiple drivers that seemingly do the same thing and they don't always make it easy to the user "this is why you should use my lib" :)

Now as far as ranting goes :) one big issue I've encountered is the fact that too may libs have incompatible APIs, making it harder to switch from one lib to another as you switch CPUs. So, if I have neopixel code (and I sure do http://marc.merlins.org/perso/arduino/post_2018-05-29_EDM-Party-Shirt-powered-with-FastLED_NeoMatrix-and-Adafruit_GFX_-plus-160Wh-_10Ah-4S_-worth-of-lipos.html ) , it's really a pain to have to write all the LED interaction if I change CPUs and want to use another library with better underlying support, like yours. So, as a suggestion only, if you would consider proving an API compatible with FastLED's, it would make it easier for people to switch to your (better) driver. Just a thought though, I understand it's time and time is not free.

But to put money where my mouth is, I've been doing this for Matrices: https://github.com/marcmerlin/FastLED_NeoMatrix https://github.com/marcmerlin/SmartMatrix_GFX same exact API between Adafruit::NeoMatrix, FastLED::NeoMatrix, and SmartMatrix:GFX I'm now working on a framebuffer with the same API still where you can display on any backend.

I also spent quite a bit of time reviewing the multiple RGBPanel drivers out there and writing up about their pros and cons, to help people choose the right one.

Anyway, back to your suggestion and my offer, if you'd be happy with a small paragraph for your top level README.md, let me know and I'll send one.

[Makuna]

I always support people submitting pulls to my libraries and making wiki changes.

My belief is the readme needs to remain small, but adding a small section that points people to comparisons in the wiki would be good. I treat the Readme as a frozen document and the wiki as a live document.

My wiki covers matrix displays and I also have buffers (again, covered in samples and wiki; but not always the best indepth as they are complex topics); both device dependent (same order as you display) and device independent (RGB).

[marcmerlin]

There you go: https://github.com/Makuna/NeoPixelBus/pull/266

[marcmerlin]

and https://github.com/Makuna/NeoPixelBus/wiki#why-this-library

[marcmerlin]

Given that all the text I wrote, was apparently deleted, I'll post it here so that it can at least be restored and in the meantime, maybe indexed and found:

Why this library?

There are multiple competing libraries, FastLED being the biggest. On ESP822, your choices main are:

• NeoPixelBus

  • Smaller than FastLED, more features and pixel support than esp8266_ws2812_i2s
  • Uses the DMA via the UART, avoiding interrupts (NMIs). FastLED uses interrupts which can be problematic if you use other code that relies on interrupts, or wifi (although FastLED allows other fast interrupts to fire in between pixel updates)
  • Supports RGBW pixels (not supported by the other 2 libraries)

• https://github.com/JoDaNl/esp8266_ws2812_i2s/

  • Uses I2S interface to drive Neopixels via DMA and without relying on the UART
  • Very basic/limited API, code is mostly a proof of concept

• FastLED

  • Very rich API, although at a cost of bigger library size
  • Identical API available across most arduino compatible CPUs
  • Interrupt driven on ESP8266, so it's sensitive to timing (not an issue on ESP32 which uses RMT)

• Adafruit::NeoPixel

  • Basic interrupt driven library which does not support any other interrupt driven code to work. Not recommended.

On ESP32, if you are ok with the bigger code size and different API, FastLED with RMT is likely a better bet as it supports 8 parallel channels for better refresh rate on bigger strings (useful past 256 pixels). If you have 4096 pixels or more, you can use the 16 way output driver from Yves as described on this on this page

[marcmerlin]

As for your comment that this may change over time, that is of course correct. You can add a "as of 2019/04" and someone can always submit fixes. But basically helping users understand why your lib is important and why they should consider it over the other libs, is worthwhile IMO. There are too many libs out there that do similar things, and it's often too confusing to figure out which lib one should choose.

[Makuna]

It got moved, not deleted.

That main page is a jump off page, so it was replaced there with similar text like the other sections (https://github.com/Makuna/NeoPixelBus/wiki#library-comparisons)

With a link to your text here (https://github.com/Makuna/NeoPixelBus/wiki/Library-Comparisons)

Again, keep the Readme generic and link it to the specific new page.