Is there any advantage to fastSpi over Adafruit Neo Pixel lib?
Supports a wider range of led controllers (ws2811, ws2812, tm1809/3/4, ucs1903, ws2801, lpd8806, sm16716, dmx controllers, depending how ambitious i get, possibly the tm1829, and apa102), support for setting brightness globally independently of the rgb values (makes a global dimmer knob a lot easier, and higher performance all around), rgb led buffer is under user, not library control which allows writing more generic led pattern/control code that focus on arrays of rgb led structures, vs. anything library/chip specific, ability to handle arbitrary re-ordering of RGB on the strips (so far i’ve seen every possible ordering of RGB as strips/chips get mis-wired), a high performance library of code for working with hsv as well as 8 bit color related values in general, more exact timing control for the ws2811 strips (some manufacturers strips have tighter timing constraints).
For the next release (some time mid-late summer, vs. the one that Mark and I are hopefully finishing up in the next two evenings) will support interleaving multiple ws2811 strings across multiple pins for higher performance, tighter integration of the hsv code to interleave hsv to rgb conversion into writing led data out to the strip, DMA support on the teensy 3.0 (possibly due if its arm architecture isn’t a complete mess).
Justin, IMO the Adafruit libraries were a good alternative to the earlier FastSPI_LED libraries for some purposes. For example, with Adafruit each chipset had its own library and you only needed to link the library for the chip you were using, so they were smaller. (FastSPI_LED had all the chips in one library). There was also different flexibility regarding pins and methods between FastSPI_LED and the Adafruit libraries, so one or the other might be better for a given situation.
The new FastSPI_LED2 library looks like a major advance. Using C++ templates, Dan has managed to combine the generality of selecting chipsets, pins, hardware/software SPI, etc with the efficiency of compiling just the parts of the library you actually need. You get a small, fast executable which implements just the chipset you need on the pins you need with the method you need (eg: hardware SPI). So I think this new library is going to pretty much surpass the Adafruit libraries on all fronts. There may some niche in which the Adafruit libraries will still have an advantage, but I’m not yet aware of it.
Thanks @Zeph_Smith and @Daniel_Garcia . I’ve got AdaFruit running 8 strips and it is a little slow. Would switch for higher data rate for sure. I had to expose the underlying pixel data in the Adafuit lib to get it to do what I needed, but that was not too hard.
Unfortunately with the ws2811 (aka NeoPixel) - the strips are what is limiting the data rate - only 800kbps. On the teensy 3 Paul has written OctoWS2811 to drive 8 strips in parallel using DMA. I won’t have my parallel ws2811 output stuff for a bit, yet. Hmmm, if one was ok with doubling memory usage there is a way we could do 8-way ws2811 output on the arduino, (giving you an aggregate of 6.4Mbps data output). The downside is the higher memory usage, though
Anyway - off to meet up with my partner in crime on this, and hope to have library news tonight or tomorrow!