Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 8 of 8

Thread: SPI TLC5940 AND SD Card at same time.

  1. #1
    Senior Member
    Join Date
    Mar 2013
    Posts
    651

    SPI TLC5940 AND SD Card at same time.

    Im working on a design very similar to Matt Pandina, 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
    Last edited by Donziboy2; 05-15-2013 at 03:05 AM. Reason: Better explination.

  2. #2
    Senior Member
    Join Date
    Mar 2013
    Posts
    651
    So I take it no one has thoughts? Is this possible?

  3. #3
    Senior Member
    Join Date
    Jan 2013
    Location
    San Francisco Bay Area
    Posts
    645
    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.

  4. #4
    Senior Member
    Join Date
    Mar 2013
    Posts
    651
    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.
    Last edited by Donziboy2; 05-15-2013 at 03:07 AM.

  5. #5
    Senior Member
    Join Date
    Jan 2013
    Location
    San Francisco Bay Area
    Posts
    645
    Quote Originally Posted by Donziboy2 View Post
    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.

  6. #6
    Senior Member
    Join Date
    Mar 2013
    Posts
    651
    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?

  7. #7
    Senior Member
    Join Date
    Jan 2013
    Location
    San Francisco Bay Area
    Posts
    645
    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.

  8. #8
    Senior Member
    Join Date
    Mar 2013
    Posts
    651
    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
    Last edited by Donziboy2; 05-16-2013 at 07:40 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •