ESP32 (WT32-ETH01) and TLC5973 LED Driver - Flickering issue

[mansch08]

Hello everyone,

I’m facing issues with the TLC5973 LED driver when paired with the WT32-ETH01 microcontroller. In my project, I use the TLC5973 to control LEDs. When I try dimming just one color, everything works perfectly. However, as soon as I dim two or three colors, at high brightness flickering starts to occur.

I have a stable power supply and adding a capacitor didn’t make a difference. After some debugging and using an oscilloscope, I noticed that some of the PWM pulses from the TLC appear shorter than they should be. This might explain the flickering.

I’ve attempted several things but turning off the WiFi and Bluetooth on the WT32-ETH01 with WiFi.mode(WIFI_OFF); and btStop(); commands seemed to help a lot, but the flickering is still not entirely gone. Therefore I assume it could be an Issue with the timing or Interrupts which occur.

Has anyone had experience with this hardware combination or can offer tips on optimizing the timing? Is it feasible to rewrite the library to be better suited for the TLC5973 and the WT32-ETH01?

My code looks like this:

#include <TLC5973.h>
#include <WiFi.h>
#include "esp_bt.h"


byte LED = 4;
uint16_t N = 1; // One LED on each output

TLC5973 strip = TLC5973(N, LED);

int fadeValue = 0;              // Start with LED off
bool increasing = true;         // Direction of fade
const long intervalFade = 10;    // interval for fading (milliseconds)
unsigned long previousMillis = 0;

void setup() {
//  WiFi.mode(WIFI_OFF); //To turn Wifi off
//  btStop();
  Serial.begin(9600);
  strip.begin();
  strip.setPixelColor(0, 0, 0, 0);
  strip.show();
}

void loop() {

  unsigned long currentMillis = millis();

  if (currentMillis - previousMillis >= intervalFade) {
    if (increasing) {
      fadeValue += 1;
      if (fadeValue >= 4095) {
        increasing = false;
      }
    } else {
      fadeValue -= 1;
      if (fadeValue <= 0) {
        increasing = true;
      }
    }

    strip.setPixelColor(0, fadeValue, fadeValue, fadeValue);
    strip.show();

    previousMillis = currentMillis;
  }
  
}

The routine which sends the data looks like this:

void TLC5973::show(){
   noInterrupts(); // Need 100% focus on instruction timing
   for(uint16_t i = 0; i < numWords; i=i+3){
      writeWord( 0x03AA);    //Start 
      writeWord( pixels[i] );
      writeWord( pixels[i+1] );
      writeWord( pixels[i+2] );
      waitGSLAT(4);
   }
   waitGSLAT(4);
   interrupts();
}

The TLC5973 documents are based on the development from:
https://github.com/miandehe/Arduino-TLC5973.git

Any help or recommendations would be greatly appreciated!

Thanks in advance.

[mrengineer7777]

I looked at the library. It bit bangs data on a 1-Wire interface. That's going to be very sensitive to timing. Are you seeing variations in the input signal (SDI) of the TLC5973? If not, then it's possible the bit rate on incoming data doesn't match the 12Mhz internal clock.

Update: TLC5973 datasheet says the timebase (tCYCLE) is established by measuring the distance between the first 2 rising edges on the SDI line.

The library you linked does disable interrupts*, so in theory the bit timing should be consistent. If this doesn't work, you can use a hardware timer to get precise interrupts for each bit.

Also consider looking for one-wire libraries for Dallas Semiconductor products. Here's one written for IDF (the layer below Arduino-esp32): https://github.com/DavidAntliff/esp32-owb/tree/master

*Disabling interrupts in FreeRTOS works on the current core. WT32-ETH01 appears to be a dual core device, so Arduino layer runs on Core 1 and interrupts will be disabled on Core 1. WiFi functionality should run on Core 0. Not sure which core runs ethernet.

[patrick-loibl]

Hello again everyone,

I'm working with julian on that project. Firstly, I wanted to thank @mrengineer7777 for the insights. Your feedback gave us an important perspective on how sensitive the bit-banging process can be with the 1-Wire interface and it led me to explore the timing more deeply. We would like to give a short interim standoff:

Since our last discussion, we made some significant discoveries and progress on the matter. We decided to use the RMT functionality of the ESP32. Given that we was already using that Arduino-based library from miandehe/Arduino-TLC5973 (https://github.com/miandehe/Arduino-TLC5973.git), our intention was to further optimize the original code for the ESP32 and potentially avoid the pitfalls of bit-banging entirely, especially with the multitasking challenges brought by the WT32-ETH01 and the use of wifi.

Here's a snippet of our new approach:

#include <driver/rmt.h>

// Konstanten für RMT Timing 
#define RMT_TICKS_PER_US (80 / 2) // 80MHz clock, 2 ticks pro μs
#define RMT_PULSE_TICKS (50 * RMT_TICKS_PER_US) // 50us Pulse
#define RMT_SHORT_TICKS (10 * RMT_TICKS_PER_US) // 10us Short
#define RMT_LONG_TICKS (40 * RMT_TICKS_PER_US) // 40us Long

// RMT Objekt
rmt_config_t rmtConfig;
rmt_item32_t rmtItems[MAX_LED_COUNT * 24];

// RMT initialisieren    
void begin() {

  rmtConfig.channel = RMT_CHANNEL;
  rmtConfig.gpio_num = RMT_PIN;
  rmtConfig.clk_div = 2;
  
  rmt_config(&rmtConfig);
  rmt_driver_install(rmtConfig.channel, 0, 0);

}

// Bit senden
void sendBit(uint8_t bit) {

  if(bit) {
    rmtItems[index].level0 = 1;
    rmtItems[index++].duration0 = RMT_PULSE_TICKS;
    rmtItems[index].level0 = 0;
    rmtItems[index++].duration0 = RMT_SHORT_TICKS; 
  } else {
    rmtItems[index].level0 = 1;
    rmtItems[index++].duration0 = RMT_SHORT_TICKS;
    rmtItems[index].level0 = 0;
    rmtItems[index++].duration0 = RMT_LONG_TICKS;
  }

}

// Byte senden  
void sendByte(uint8_t byte) {

  for(int i=0; i<8; i++) {
    sendBit(byte & 0x80);
    byte <<= 1; 
  }

}

// Daten senden
void show() {
  
  int index = 0;
  
  // Startbit
  sendBit(0); 
  
  // Datenbytes
  for(int i=0; i<numLEDs; i++) {
    sendByte(red[i]);
    sendByte(green[i]); 
    sendByte(blue[i]);
  }

  // Stopbit
  sendBit(0);

  // Über RMT senden
  rmt_write_items(rmtConfig.channel, rmtItems, index, false);

}

We didn't test it yet, its just a combinations of snippets we found in other projects inline. We've also come across another library, by Caffein93 on GitHub (https://github.com/caffeine93/esp32-tlc59731-driver). It's designed with RMT in mind but unfortunatly its made for the ESP-IDE. However, I'm working within the Arduino-IDE for my ESP32 development, so integrating this would be another challenge.

We would be happy if someone could review our code and help us explain if there is anything we are missing.

I'm still open to suggestions and would particularly appreciate insights on:

• Leveraging the RMT functionality optimally with the TLC5973 and the ESP32/WT32-ETH01 in an Arduino-IDE environment.
• Potential pitfalls or challenges when blending libraries or functionalities from both ESP-IDE and Arduino-IDE.
• If anyone has faced similar issues and has insights or workarounds that they've found effective.

While We've made some progress, the journey has reminded me of the intricacies of embedded programming and the nuances of different microcontroller architectures.

Your continued support and knowledge sharing is much appreciated!

Warm regards,

Partick & Julian

[Xylopyrographer]

More a word of encouragement than anything else.

It is very possible to convert an esp-idf library to the Arduino IDE. I did this to create the LiteLED library— which uses the RMT peripheral— from the led_strip esp-idf library by the Uncle Rus team.

Biggest thing was ensuring all the header files needed are ported or redefined in the Arduino library.

Remembering that arduino-esp32 sits on top of esp-idf (which sits atop FreeRTOS) means calls to the bottom two layers can be done directly in your Arduino IDE sketch. That can help in porting and simplifying things.

[patrick-loibl]

Thank you for your words of encouragement and insights!

It's really inspiring to hear that you've managed to convert an esp-idf library to the Arduino IDE. I've been contemplating a similar approach with the TLC5973 and your mention of the LiteLED library is intriguing.

Given that I'm unfamiliar with the specifics of porting header files:

Could you describe the process you went through to port or redefine the necessary header files for the Arduino library? Were there any challenges or specific tools you found particularly helpful? We're really beginners in this matter...

Are there any key differences or nuances between esp-idf headers and what's expected in the Arduino IDE that I should be aware of? I think WS2812 is pretty similar to the TLC5973 in terms of the overall function so I think its compareable...

It would be really helpful if you could provide more information.

Your point about the layered nature of arduino-esp32, esp-idf, and FreeRTOS is not really clear to me .. Does it mean I can integrate a ESP-IDF Code into the Arduino Code?

Thank you once again for your valuable input.
Warm regards,

[Xylopyrographer]

The process (as I remember it) was to copy into the same folder as the sketch the header and cpp files from the ESP-IDF library of interest. Keep hitting the Verify button in the Arduino IDE and reworking the code until the errors are gone. From there, wrap the resulting ESP-IDF code into a class and make a library out of it. IN my case I was stripping a lot of stuff out of the ESP-IDF component so it took quite a bit to get rid of all the unwanted dependancies. Kinda like unspooling a ball of yarn. Best way to do it? Not sure, but I learned a lot and got there pretty quick.

If you poke into any of the files in the arduino-esp32 core package, you will see all sorts of ESP-IDF code in there. Check out the contents of [additional-path]/Arduino15/packages/esp32/hardware/esp32/2.0.14/libraries (note '2.0.14' will change depending on the core version installed).

There are many examples and tutorials that do a far better job that I would explaining how to use ESP-IDF and FreeRTOS calls within an Arduino sketch. Here's one on using FreeRTOS by one of the arduino-esp team members -> https://www.youtube.com/watch?v=fBWu8sCuat4&t=615s&ab_channel=EspressifSystems