Introduction
SPI Bus
SPI stand for Serial Peripheral Interface. The important details learned are as follows:
-
- Slave Select (SS)
- Serial clock (SCLK)
- master input / slave output (MISO)
- master output / slave input (MOSI)
When it properly implemented there is 4 wires required.
Although both of these components have been tested successfully, they have only been done so individually. The ATMEGA328 microprocessor used has one dedicated Serial Peripheral Interface (SPI) Bus. A design feature of SPI allows multiple devices to communicate on a single interface. This is done by using a Slave Select (SS) line to each device and pulling this line low to select that device. The driver will require the connection of both devices to operate as required. The TLC5940 does not fully implement the SPI standard and is missing this SS line. In order to communicate with both devices a second SPI port will have to be emulated using the on chip software. This process of manually influencing the state of the pins on the microcontroller to emulate a port is commonly referred to as “bit banging”.
The TLC5940 Library and BITBANG mode
The first thing to do was understand how each library was working at low level. It was quickly discovered both libraries were making good use of the microcontroller’s timers and interrupt capable ports. Simply moving around port labels in the software would not work. When reading through code supplied with the TLC5940 library an interesting condition was defined “TLC_BITBANG 0”. Through further research it was discovered that the library had originally been written to emulate the SPI port but was later adapted to use the hardware port provided by the microcontroller. With the “TLC_BITBANG” option set to 1 and the ports reconfigured it soon came to light that digital port 10 could not be changed, even in the libraries “bitbang” mode. This posed a problem; pin 10 was not only the hardware SPI’s “Serial Select” pin but also the pin of an internal timer which the TLC5940 library was using. Since a substantial rewrite of the library would be required to move the timers, research was done to see if the Serial Select pin of the SPI interface could work on another port with the wireless library. It turns out that port 10 was being manipulated manually by the wireless library; this meant it could use another port without issue. Upon changing the port the wireless module was encountering issues and exhibiting erratic behaviour. Further research showed that even if another port is used as opposed to 10 the hardware SPI interface requires that port 10 is still defined as an output pin to the microcontroller for it to function correctly.
Conclusion
This issue proved to be quite a setback. Fully understanding the libraries workings whilst still being a beginner in the area took research and trial and error experimentation. Once the issue was resolved both units worked together and were stable doing so. Small test applications were written to transmit data and vary LED’s at high speed and all of them proved successful.
Hi,
I’m trying to get this to work with an Arduino board that has Ethernet built in (Etherten). Did I get you right: you changed the SS pin in the Ethernet library to another pin, and defined pin 10 as an output pin? And then connected the TLC5940 as usual (including pin 10)? I would be glad if you could explain a bit furhter and post a code snipplet.
Thanks!
Hi Michael,
I’m not sure if you’ve sorted your issue but I’m not actually using the Ethernet Library.
You can ask the TLC5940 library to work with either hardware SPI or a software “Virtual SPI” if that makes sense. I had it working with the software SPI and then I could reassign the pins wherever I wanted.
If your still struggling reply back and I’ll try to help you out.
Cheers,
Louis
@Michael: could you solve the issue with the arduino-ethernet-board and the TLC5940?
i have the same problem here, but i am not very familiar with editing such libraries.
any hints for me?
best regards, Stephan