MY9221 support

[lolimpol]

Feature request for the MY9221 chip. 16bit with 12 channels and thus the possibility to control 3 RGBW leds, 4 RGB's or 2 RGBWWW. That conveniently contains the reason for this feature request over the FW1906: the possibility to use RGBWWW led's at 16 bit. Additionally, logic high input is 0.7V allowing for 3.3V use without a logic level shifter. This potentially also makes implementing the MY9291 easier, a 16 bit 2000hz refresh rate single channel RGBW chip.

Information page: https://www.advateklighting.com/pixel-protocols/my9221
Datasheet: MY9221_DS_1.0.pdf
Alternative: https://files.seeedstudio.com/wiki/Rainbowduino_v3.0/res/MY9221_DS_1.0.pdf

[Makuna]

Interesting chip. Supports variable bit depth for greyscale. Is also a two wire (data and clock) chip.

Problematic issues I spot:
Relies on the clock being half the speed of the data, as it samples bits on rising and falling edges of clock. No SPI peripherals (internal to uc) support this. So, DMA and asynchronous sending may not be possible on any platform.
Requires a special protocol for the RESET signal. Holding clock while outputting data. No SPI peripheral support this.

Basically, this means it must be done with bitbang and thus a synchronous call, wasting CPU time to send the data. While this is normal for AVR platform to only support synchronous data transfer, more modern platforms like ESP and nRF52840 (Nano 33 BLE) support asynchronous calls using DMA and thus allow the CPU to prepare the next frame while the active frame is being sent. This may also mean a slower output speed based on the uC clock and instructions timing.

[Makuna]

To confirm, did you want the TLC5971 or the TLC69711? The protocol is different between them.

[thickbut]

I believe the only thing different about them is that TLC5971 can support 20Mhz data transfer while TLC59711 can only do 10Mhz. And the TLC59711 has an extra Watchdog Timer function. They should both have the same protocols and data packet structure. For both chips, the application section of the datasheet actually describes 3 protocols you can use: one where you let the internal oscillator do the PWM for the LEDs, and two other protocols where PWM is dependent on the external SPI clock. I assume maybe you saw one of each but on separate datasheets.

[lolimpol]

Doesn't seem like a big difference to me, any use for the watchdog timer on the TLC59711? Which one is easier to implement?

[thickbut]

I believe the watchdog timer is just for checking if the external clock line has disconnected. It's an unadjustable feature so implementation would be the same.

BTW, is a 2000Hz refresh rate at 16-bit necessary for your application? The TLC5971x chips can't go that fast at 16-bit and I doubt the MY92xx chips can do it either despite their datasheet claim. At a 10MHz internal oscillator frequency, you can only get 10MHz / 2^16 PWM clocks per refresh = 153hz maximum update limit at 16-bit. If you are more worried about flicker, the chip does temporal dithering from an effective 9-bit 19.5kHz PWM rate, so flicker should not be visible even at 153hz updates. I think it would look kind of smoothed out for bit depths higher than 9-bit. And I believe a change in brightness of 1/(2^16) = 1/65536 will not manifest as flicker at 153hz anyway.

It might be possible to update the chips faster than 153hz if you lower the bit depth and interrupt the internal PWM from sending a full 65536 clocks every refresh. I don't know if the chip prevents you from forcing a refresh while it's in the middle of PWMing the LEDs. But at 12-bit color you would be able to do 10MHz / 2^12 = 2.4kHz updates. Again, this is because the chip does temporal dithering at a base of 19.5kHz at 9-bits so the duty cycle wouldn't change if you cut off the PWM early.

[lolimpol]

2000hz isn't a requirement. Sk6812 has a frequency of 1.2khz and that's more than enough. They will be used for home lighting, no slow motion video or anything of the likes. 153hz would be sufficient.

[Makuna]

I already have the settings object for the TLC59711 ready, but I am working on how to generalize the concept that settings are sent per chip where a chip could be four RGB, three RGBW, or two RGBWWW. The general design has been that the "chip" size defined by the feature, so it was one of a RGB, RGBW, RGBWW, or RGBWWW; with various bit depths. So a little more complex but still doable.

Did you create an issue for the TCP59711?

[lolimpol]

I have not yet, great to hear the progress though! Shall I create an Issue?

[Makuna]

Not merged into master yet as I haven't received my chips. But, you can pick up the branch Tlc59711 to give it a try.
The logic analyzer shows the correct data and timing are being done.

NOTES:
The root color object to use is either Rgb48Color or Rgbw64Color to get full 16bit per element resolution.
Tlc59711RgbFeature or Tlc59711RgbwFeature are the features to use.
Tlc59711SpiMethod is the method to use. All the normal Spi speed method naming patterns should work, like Tlc59711Spi2MhzMethod.
You must call the strip.SetPixelSettings() method with a Tlc69711Settings object before your first call to Show(). See below for examples. You can call this to change the settings at any time, like to globally dim all the leds without setting each one. Also note the Tlc69711Settings supports all the settings these chips support.

Like all SPI two wire LEDs, for most platforms you can use the following model of constructor and begin calls.

NeoPixelBus<Tlc59711RgbFeature, Tlc59711Spi1MhzMethod> strip(PixelCount, DotClockPin, DotDataPin);
...
strip.Begin();
...
strip.SetPixelSettings(Tlc69711Settings()); // full global brightness as an example

On the ESP32 platform, the pin settings must be done on the Begin() like...

NeoPixelBus<Tlc59711RgbFeature, Tlc59711Spi1MhzMethod> strip(PixelCount);
...
strip.Begin(DotClockPin, -1, DotDataPin, -1); // clk, miso, mosi, select
...
strip.SetPixelSettings(Tlc69711Settings(63)); // half global brightness as another example

[lolimpol]

I'm gonna try implementing it into WLED and see how it goes. Sounds like you thought of everything though. Thanks!

[Makuna]

I created #781 to track the issue.

[Makuna]

@lolimpol After working with the TLC59711, it has quirks.

It currently requires data be sent in reverse in two ways.

• First Each chip is sent in order from last to first.
• Second, Each pixel on the chip is sent last to first.

Note that the LED element (think R of RGB) is sent in reverse order BUT the 16 bit element itself is sent normal MSB; this isn't unusual or a concern. So BGR would have been feature.

The data buffer as accessed through the strip.Pixels() is unfortunately assumed by WLED that pixel order is pixel 0 to pixel n. This never should have been assumed but every LED up to this chip followed that. So as to stay compatible, the buffer order is left alone and reversed when sent.

[Makuna]

After more testing, the branch was merged in. There are some big caveats with this chip.

This chip relies on strict timing in the data stream between chips to latch data from the stream on a per chip bases. This timing is relative to the clock used for the data transfer. This is problematic, as the uC will vary what it can achieve while the data sending would be the same. The results are, it confuses which data is for which chip and you will see flashing on output from a previous chips data; even though the static state after the send is usually correct. But if you are doing fast updates one after another, the flashing leds is unusable.

This is a horrible design to rely on timing AND a clock-based data signal which is all about not relying on strict timing.

SO, limit your speeds to 2Mhz (now the default) as an even the fast ESP32 can NOT maintain the timing requirements for multi-chip installation even on a branch that was double buffered (but not DMA).

For a single chip installation, full 10Mhz speed will work fine.