LED bleed when muxing Shift register 595 and TLC5940

Other Hardware LEDs and Multiplexing
1

Hi All,

I'm running into an issue where I get bleed on my test 8x8 screen when multiplexing the TLC5940 and 595 shift register.
Here is my circuit schematic:

1458×962 44 KB

My library code snippet from my Teensy 3.1 library is as follows (for the MUXING):

With my setup, i've got a multitude of games running on my rasberry pi, which has a custom handshake and communication protocol[1], which then is repeatedly read and stored in my teensy.
This works via having two screen arrays, one which is currently being read from and one that is currently being written to. I have found that if I reduce the read input/draw time ratio then the bleed dims a bit more, but this reduces my effective framerate.

Here's a video to describe the troubles i'm having:

Does anyone have any suggestions?

[1] - My document on serial comms http://docdroid.net/9uwi

2

Hi mHo2,

I can't make much sense of your schematic. At the right and at the bottom it says "To teensy 3.1", but I don't see which connections are going to the teensy.

Bleed, when multiplexing, is often down to the same issue. For each row, you need to switch off all anodes before changing the cathode data, then switch on the relevant anode. Or do it the other way around, i.e. switch off all cathodes, then change the anode that is switched on, then load up the new cathode data. If you don't do one or the other, and instead try to simply update both cathode and anode, you will get bleed. Maybe you already know this, in which case I apologise.

Paul

3

Hey Paul,
thanks for the reply. Yep I was aware of that. I also solved the issue today!

To break it down to anyone looking to do the same thing, here's my custom grayscale send function. I've got a custom Teensy 3.1 TLC5940 library in my hands (unreleased) thanks to the creator of another library!

Here's what the function looks like for PERFECT muxing between a TLC5940/595 (with custom commenting for all y'all!)

//My function
void sendGSData (byte leds)
{
  if (tlc_GSDataChangedSinceLastSend)
   {// If we get here and the last XLAT request hasn't been handled yet, set
    // tlc_needXLAT back to false so we can send the latest data before latching 
    // it in.

  // Turn off XLAT
    tlc_needXLAT = false;
  //Turn off VPRG
    digitalWrite(VPRG_PIN, LOW); // VPRG low says we're setting the GS register
  //Send data via SPI
    sendSPIData12Bit(tlc_GSData, NUM_TLCS * 16);
  //Write to shift register
    digitalWrite(SHIFT_LATCH_PIN, LOW);
    shiftOut(SHIFT_DATA_PIN, SHIFT_CLK_PIN, LSBFIRST, leds); 
    digitalWrite(SHIFT_LATCH_PIN, HIGH);
    tlc_GSDataChangedSinceLastSend = false;
  //Turn on latching
    tlc_needXLAT = true;
    //Actually turn on the shift register
        digitalWrite(15,LOW);
  //Wait for a latch (aka one display cycle)
    while(tlc_needXLAT);
//Turn the shift register off again
    digitalWrite(15,HIGH);
}
  return;}