Best speed one can expect from SPI ...


I have done some speed tests and found that I can refresh 8 bytes to a 595 at +- 68Khz which translates to +- 5.4Mhz as the bit level. This includes the latching and using SPI at divisor/2.

Is this the fastest refresh rate one can expect from shift registers?

I am stuck between choosing a TLC5450 and TPIC6B596 for a rotating persistence of vision display. It seems to me that with the current timing I am getting, shifting 12 bits per LED for the TLC5940 will be pushing the limits of my refresh requirements which is 64 LEDs at 2Khz.

The TLC's 'strange' 4096 tick interval on the PWM gray scale clock for refresh of data may also complicate matters in a system that is already very much fixed interval orientated. Can I even get the 16MHz clock of the arduino out to the TLC5450 to achieve a 3.9KHz refresh?

You could always use an external 16 MHz TTL output oscillator to drive both, such as

Thanks! That is something I haven't thought of .. :)

However .. how would I know the 4096 grayscale cycle has expired e.g. time to latch on the the TLC chip?

Control the Blank signal? I am thinking a 256uS long Blank Signal ANDed with the 16MHz clock, thus your code would control how long it lasted.

Err .. ok, I'll admit it, you lost me .. :~

Can you give me a basic description of how to do that and I'll research it some more?

Thx and gotcha on the AND side ..

However how would I know when its time to take BLANK pin on the TLC HIGH to reset the grey scale clock counter and use XLAT to latch the data? As I understand it, it must be done on the 4096th clock count or the outputs just switch off?

In the "demistifying the tlc5940" e-book the author is using the AVR to generate the grey scale clock and thus can count the clock pulses ..


I'd have to read the datasheet some more - I took it home, will peruse tonight.

Ok, I managed to save it locally.
The way I read this on page 19:

The grayscale PWM cycle starts with the falling edge of BLANK. The first GSCLK pulse after BLANK goes low
increases the grayscale counter by one and switches on all OUTn with grayscale value not zero. Each following
rising edge of GSCLK increases the grayscale counter by one. The TLC5940 compares the grayscale value of
each output OUTn with the grayscale counter value. All OUTn with grayscale values equal to the counter values
are switched off. A BLANK=H signal after 4096 GSCLK pulses resets the grayscale counter to zero and
completes the grayscale PWM cycle (see Figure 21).

When the counter reaches a count of FFFh, the counter stops counting and all outputs turn off. <<<

Pulling BLANK high before the counter reaches FFFh immediately resets the counter to zero."

You need to supply at 4096 GSCL pulses after you take Blank low, then the counter sits there until you take Blank High, and then low starts the next cycle.
So feed the AND gate with inverted Blank, or use a NAND gate, there are multiple ways to gate the GSCL signal.

Ok, I think you are saying to try match the speed of the the data transfer together with the XLAT to the 4096 clock cycle of the grayscale counter. So just switch BLANK when the data is done and latched and the whole cycle starts again.

This effectively reduces the refresh rate to that of the data transfer cycle and one just loses some 'resolution' on the grayscale cycle, which should be easy to recalculate correctly given the known time to refresh the data.

So .. if I need 80 LEDS at 12 bit data per LED, that is 960 bits. 960 bits at SPI max 4MHz can be refreshed at 4.1Khz If the gray scale clock runs at 16Mhz with a cycle of 4096 'ticks', it will refresh at 3.9KHz. Just enough time to get the data in.

If all of this holds true then I suspect a rotating POV with its own refresh rate requirement of 2.5Khz (same amount of 'intervals' on the rotation as LEDs on the string e.g. 80 times 32 revolutions per second) may be a bit tight?

Irrespective of this I think I would very much like to build a TLC5940 with external oscillator circuit. CrossRoads would you be willing do a collaborative effort on this. If you can maybe give a basic circuit layout I'll build it and code it as far as possible. Would make for a nice project for the community, me thinks. Maybe throw in a programmable oscillator for scaleability on the refresh rate vs nr. of LEDs?

I can do something with you, but may be a little slow getting to it. I am on vacation this week and will be working on my fencing club. 80 LEDs, so you will have 5 TLC5940s to control?

No rush at all.

It occurs to me that it might be doable with the TLC5940s if I can get the grayscale refresh rate to match that of the POV or just slightly slower. This would mean I wont be getting true gray scale but rather pixels vs lines horisontal resolution.

I am looking at a voltage controlled oscillator (SN74LS624N DIP package) at the moment which I can set via PWM to match the (perhaps somewhat variable) rotation speed and so far I can't see any reason why it won't work.

The benefit of this will be that I can do the required BLANK signals in the same timer interrupt that I would use to divide the full rotation into its 80 divisions and which is then also the trigger to start the data clocking.

Pseudo code:

void TimerInterrupt { pinBLANK = HIGH; // reset greyscale counter pinXLAT = HIGH; pinXLAT = LOW; // to latch data if (CurrentCalculatedRotationSpeed !=LatestCalculatedRotationSpeed) { setVCOPinPWM = LatestCalculatedRotationSpeed + 1; // change the clock speed of voltage controlled oscillator CurrentCalculatedRotationSpeed = LatestCalculatedRotationSpeed; ReattachTimerInterruptAtNewSpeed(); } pinBLANK = LOW; // restart cycle ClockNewDataIn(); // send new data }