Two SPI devices, where one isnt quite SPI

[otm]

Hi everyone,

Full of questions recently.

I'm doing one of those 'well known' projects of an RGB Led Cube.

A good mix of logic and software (the latter of which really does need picking up!).

I know there is a shed load of examples of different techniques, and I am going down a familiar root using the TLC5490 16 channel PWM LED driver.

I am very much trying to not use the online walkthroughs and build from first principles. Everyone can copy someone else and make it, but you dont understand it.

Anyway, background over... real question..

The TLC5940 implements a bit of a hash of the SPI protocol and as such, has no Chip Select.

Say I want to add another SPI device (in this instance think of an SD card), which ultimatly needs the speed of hardware SPI much like the TLC5940 how could it be implemented?

I was going to delve (first time ever) into the world of the Arduino / Atmega chip with Arduino bootloader, and there is a comprehensive library been built for said TLC5940. This library has the option to bitbang the spi interface, but software spi speed suffers greatly.

I was thinking, as the SPI interface NEEDS the SCLK in order for data to flow. Could I simply logically AND the SCLK with an output pin of the arduino effectivly creating my own 'chip' select?

This introduces a propagation delay of the SCLK of a few ns over other data and clock lines needed for the TLC5940 (primarily the Grayscale Clock and the actual data line)

would that propagation delay cause issues? I've never used SPI before (shock even to me), so wouldn't know a) how common it is to logically AND the signal, and b) if it has an impact.

And are my understandings and fears about bitbanging either of the SD cards or TLC5940s functionality true? I know the LED cube would still work with bitbanging the TLC5940, but it is known to introduce errors and erroneous behaviour in the final graphical outcome.


Your thoughts are greatly welcome!

Owen.

 

[ChrisP58]

You implements multiple chips with the TLC5940 by cascading one chip after the other. Clock feeds all chips. You feed the SIN of the second chip from SOUT of the first. Theoretically, you can tie any number of chips in a string.

You just need to send all the data for the last chips through the first.

 

[otm]

Hi Chris,

Thanks for your comments but that much was very much understood.

I know how to cascade the TLC5940, the question relates more to how to add other SPI devices ( mainly an SD card) when the TLC5940 doesn't have the standard Chip Select...

I could use the OE (called BLANK on the TLC5940) but that would mean the TLC5940 would be receiving a load of odd data that would need clearing out before sending the actual image data which is much slower.

Thanks,

Owen

 

[Ian Rogers]

Personally... SD card to hardware... LED driver to software I would implement the LED driver on a full port of a micro. And then you could cascade them without fear of messing with the hardware SD card driver...

 

[Pommie]

When you access the SD card the TLC simply receives the data but you never strobe XLAT so the data never gets latched. Think of XLAT as a kind of CS.

Mike.

 

[otm]

First off, sorry for the late reply, ive been busy with other things....

Thanks for your responses, I must admit one thing, I haven't done, nor do i really know, the calculations to work out the effective baud rate / refresh frequency of Hardware SPI over Software....

There is a TLC library for the arduino that by changing two or three variables makes it bitbang the SPI.

The idea of using XLAT like that is a cool one. I will need to delve into the TLC5940 a bit more to understand the pros and cons of a software SPI.

Likewise, look into an SD card implementation to understand its SPI workings.

If an animation consists of 100 frames its about having time between each frame to load the next one from the SD card without causing any persistence of vision issues (ie refreshing the frames too slow).

Owen.