PDA

View Full Version : SPI TLC5940 AND SD Card at same time.



Donziboy2
05-13-2013, 11:26 AM
Im working on a design very similar to Matt Pandina (https://plus.google.com/u/0/112449749826562830126/posts), except I want to attempt it on something other then a customized Atmega328p.

The current usage is to send data via SPI to the TLC5940's while they are displaying the previous data, then read from an SDcard the data for the next run. This requires very tight timings, atm Matt goes thru all three phases RGB in around 500uS, which is one scan line. 166uS per color, and sending 96 bytes per color, 3 colors in all.

166.667uS = 6000Hz
24bytes x 4 TLC = 96 Bytes
6000 x 96 = 576000 bytes/s or 4608000 bits/s this would be the absolute minimum for this refresh rate, you would want at-least another 15% leeway

The Teensy 3.0 has DMA SPI, does this mean you can read from an SDcard while you bitbang out to the TLC's on a different set of pins? How fast could you do it?
Since the Teensy 3.0 has more memory you could possible stay several lines ahead of the TLC's?

I have 3 prototype PCB's built so I can run tests, atm I have been working out more details on the Mosfets for sourcing the leds.

TLC5940 Datasheet (http://www.ti.com/lit/ds/symlink/tlc5940.pdf)

Donziboy2
05-14-2013, 10:45 PM
So I take it no one has thoughts? Is this possible?

linuxgeek
05-14-2013, 11:20 PM
I don't think it should be a problem. Check out IntervalTimer and sdfat.

sdfat is pretty fast, as long as you use the right calls. Download it, and look at the examples. I was using it to write to sdcard while sampling at 100kHz simultaneously. Use multiple 512 byte buffers to write or read. And then use interval timer to use interrupts to send the SPI data. At least that's how I would think of doing it, but there might be better ways. I only had to use 2x512 byte buffers, but you might need more considering that each time-slice you need 288 bytes.

Donziboy2
05-15-2013, 02:00 AM
Actually the data for the TLC's gets sent in 96 Byte chunks, at a rate of 6KHz, 288 bytes is all 3 color sets. Guess I should have explained it better... I will fix that.

But is there really enough time to send a request and get data while sending data to the TLC's? The TLC's also dont use CS so they cant be on the same pins as the SD Card.

linuxgeek
05-15-2013, 05:29 AM
Actually the data for the TLC's gets sent in 96 Byte chunks, at a rate of 6KHz, 288 bytes is all 3 color sets. Guess I should have explained it better... I will fix that.

But is there really enough time to send a request and get data while sending data to the TLC's? The TLC's also dont use CS so they cant be on the same pins as the SD Card.

I don't know. I'm actually not a very good person to ask about this. But run the bench.ino sketch and look at the latencies. If you can use most of your RAM(10k), it seems like you could have 104 cycles of sending data to be able to read the next sd block.

I would send the TLC data in an interrupt, reading from buffers.

In loop(), I would populate the buffers from the sdcard. If there's an occasional hiccup, I'm not sure it would be very noticeable. It should just send the non-refreshed data again, which shouldn't be very noticeable.

But beware, I could be completely off-base.

Donziboy2
05-16-2013, 11:08 AM
So if I request a chunk from the sdcard can I still bitbang the TLC's while I am waiting for the data to come in? Do I have to stop the TLC banging when the data comes or can the hardware move it to memory without interrupting the TLC bitbang?

Even with a buffer wont I run into a gap eventually?

linuxgeek
05-16-2013, 03:29 PM
If you are sending data to the TLCs in an interrupt, it will keep going regardless. Then, you try to populate the buffers in the loop(), which will do it as fast as it can when not in the TLC interrupt.
Even if you had a gap, I'm not sure it would be very noticeable as you would just be sending unrefreshed data to the TLCs.

If that's not fast enough, you might need to use DMA.

Donziboy2
05-16-2013, 06:24 PM
What is the average latency for the sdfat thou?
New data for the tlc's will need to be sent every 133uS, it takes 38.5uS to send all 96 bytes to the TLC's with 4 tlc's, using SPI, bitbanging will probably be slower.
The data that is sent every time will be different, I am displaying 64 x 64 or greater images. Using POV to give the illusion of a picture. The refresh rate has to be fairly close or it will be noticeable.

Here is an example of what I am trying to do, he is a lot further ahead then me > Matt Pandina's 64LED Light display (https://plus.google.com/112449749826562830126/posts/VFP2LESnhQN)