2
\$\begingroup\$

(this is more hardware design, rather than software question).

Hi all. I plan to build an Arduino shield (board) with multiple LED drivers (TLC5941). They are accessible via SPI. The problem is that SPI communication wires may get loo long, causing signal interference.

Guessing my board should get another cheap controller to talk both to Arduino and LEDs; so, the question to all the experienced Arduino pros here is:

is it smart to connect peripherals (SPI) using some cheap controller as a cache? (at least this way allows me to send only modified values from Arduino => lesser code) or the SPI bus is interference-proof enough(at least if the board is designed correctly)?

\$\endgroup\$
8
\$\begingroup\$

Define "long". When you say "shield" I'm thinking of something that may plug directly in to the Arduino, so the signal path is maybe 3-5 inches. AVRs/Arduinos will have no problem communicating at that distance (unless you try really hard to cause one); even a distance like 2-3 meters should be fine up to a few MHz.

For SPI specifically, as it is entirely master driven, the only way you could get problems is when receiving from the slave, then only if the clock edge took so long to get to the slave, when it sent out the next bit, the master was already expecting the next bit. The hard theoretical limit imposed by the TLC5941 would be 10-meters total length when running at 30 MHz (c / 30 MHz).

Arduinos don't typically run that fast anyways, so you might be able to get up to 5 meters at the Arduino's standard 16 MHz if terminated with some resistors. If you don't need extreme speed and could run at 100-500 kHz, you could probably make it across a football field with decent wire.

EM interference effects would have to be extreme to mess with a 0-5V signal. Unless you're running it inside a microwave, fuggedaboutit. SPI is not LVDS.

For ease of use and simplicity, I2C drivers might be the way to go (e.g. NXP PCA9635). I2C only uses 2 lines (clock and data), versus the 3 + 1 per slave for SPI. They will be slower than SPI drivers, but unless you're trying to update some 64 LED array at 60 Hz (or similar), should be fine.

\$\endgroup\$
  • 1
    \$\begingroup\$ 64 LEDs, with 8 bits for each, at 60 Hz, is 30kbps of data. The 8-bit address, 8-bit register code, and various ack/setup bits cramp the speed a bit, but only by 70% or so. I2C can usually handle 400 kHz, but that NXP chip is capable of 1 MHz "Fast Mode Plus" I2C and should therefore be able to handle over 1000 LEDs on a single bus. Don't worry about the speed difference in I2C and SPI for this use case. \$\endgroup\$ – Kevin Vermeer Sep 21 '11 at 17:11
  • \$\begingroup\$ Why not just run SPI at 400 kHz, instead of switching to I2C just to run slower? \$\endgroup\$ – Joel B Sep 21 '11 at 18:55
1
\$\begingroup\$

The FastSPI library might be useful to you (more information on the author's blog.)

This library aims to provide an efficient, high performance interface to various led controllers. It will allow developers to choose performance criteria important to them (maximum cpu usage, number of color levels, refresh rates) and calibrate accordingly, and within reason (there are resources limits in a 16Mhz environment!).

Initial support:

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy