TLC5947 Support

[xonestonex]

I would like to add support for the AdaFruit 24-Channel LED Driver that is based on the TLC5947 chip. The Chip has a 12-bit depth for each channel. My question is, if its better to implement a 12-bit T_COLOR_FEATURE or do an 12-bit upscale/downscale for the color regular features (NeoRbgFeature, NeoRbg48Feature, ...) in the T_METHOD implementation.
Doing it in the T_COLOR_FEATURE would allow to send the whole buffer directly using hardware SPI instead byte by byte and scaling, but for RGB (36-bit) the PixelSize value would be wrong.

What do you think?

[Makuna]

Several high level design facts of this library:

1. Two wire protocols like SPI (used on DotStars class of LEDs) are different than single wire protocols (used on NeoPixel class of LEDs). The two wire expose the ability for either software or hardware SPI by the sketch author in a standard way. You can see this with any of the DotStar methods examples. The TLC5947 would be classified as one of these.
2. The Feature::ColorObject (used by SetPixelColor) is not the same as the bits used in the pixel buffer. It is the job of the color "Feature" to translate the ::ColorObject to native format stream buffer and back (even if there is loss in one direction or the other). The stream buffer is always supposed to be in native format.

I don't believe there is a need for custom Method for sending. The generic DotStar methods (both bitbang and SPI) should work fine.

The interesting design question here (from the perspective of that board) is what are the 24 separate channels representing? Are they 8 sets of RGB? Are they 6 sets of RGBW? Are they 24 sets of X only? Are there any other combinations that they can be assuming you are not mixing on the same strip?

The Feature::ColorObject is the Device Independent Color, and in this case of a chip that supports 12 bits per color element, RgbColor (8bit per channel) would not provide as much resolution and Rgb36Color (16bit per channel) would provide too much. Supporting two Features that provide each might be interesting for "memory" conservation on the sketch writers side, but at least provide one supporting 16 bits per channel.

So do you create NeoTlc5947Rgb36Feature (Rgb36Color), NeoTlc5947Rgbw36Feature (Rgbw48Color), NeoTlc5947X16Feature (uint16_t)?
And then do you also create NeoTlc5947RgbFeature (RgbColor), NeoTlc5947RgbwFeature (RgbwColor), NeoTlc5947XFeature (uint8_t)?

Did I miss anything?

[xonestonex]

The 24 channels can represent any kind of LEDs (CCT, RGB, RGBW, RGBCCT, ...) but I would only implement RGB and RGBW first. I would not support mixed LED types.
My Problem with the implementation of the 12 bit as color feature is, that you need 36 bit for RGB and this would result in a Feature::PixelSize of 4.5. Using an integer of 4 or 5 would result in wrong values for code that uses Feature::PixelSize or NeoPixelBus::PixelsSize() like NeoBufferMethod or code in projects that use this library.

[Makuna]

and I missed something ;-)

Yeah, using the feature to pack and unpack won't work here then.

Then we can only do this in the Method.

DotStarTlc5947Method
A copy of the DotStarGenericMethod (drop the begin frame end frame as its not needed here); but it will need to implement double buffering and translates at show from normal buffer (8bit or 16 bit per element) to a device dependent 12bit per element. This translation may require a template class (see T_SPEED from NeoEsp8266DmaMethod for a model) but initially don't worry about it.

Review NeoEsp8266DmaMethod for some guidelines on double buffering and naming. FillBuffers shows translation, _data for exposed buffer and _is2Buffer is the internal buffer (_tlc5947Buffer).

[xonestonex]

Thanks.

I will make a PR when I'm done with it.

[xonestonex]

PR #551 done.