rs485spi
I want to connect chips that use SPI protocol to communicate (To be specific those chips are ws2801) the distance may reach 100 meters.
How can I solve this issue? After a few days of searching I've come up with two solutions:
Is there any other practical solution?
The 'r' command for bus pirate reads a single byte, so r:16 is attempting to read 16 bytes, not 16 bits. I'd guess you want "r:2 r:2" (or just "r:4")
But, I doubt that's the problem. If it had worked, you'd have seen the 4 bytes then some FFs.
I think it's more likely that your chip is not ready to accept commands over SPI.
I did some work with the CSR BC04 a few years ago. They can be configured to accept commands over the UART, SPI or USB. It's possible that yours isn't accepting commands over SPI. Fixing this may involve reflashing the firmware.
You might give the Bus Pirate SPI sniffer a go and see if you can intercept some valid looking signals when your device is running normally. That would give some confidence that it really is using SPI. Another way to do this would be to use a 2 channel oscilloscope, trigger on CS and look for the SPI clock ticking while CS is asserted.
To be honest, if you're just trying to get SPI going on the Bus Pirate - choose something easier. The first device I used mine on was an RGB LED matrix from Sparkfun.
The single-ended SPI signals can be converted to differential pairs, which are more robust in presence of EMI and can go the distance. Then the differential pairs can be converted back to single-ended SPI signals, and connected directly to peripherals (ADC, I/O expanders, and such). That's what the original forum post is proposing.
MAX490 has 2 different sub-circuits.
One sub-circuits is a differential bus transmitter. It can convert a normal single-ended SPI signal to a differential signal.
The other sub-circuit is a differential bus receiver. It can convert a differential signal back to single-ended.
(fig. 2 in the datasheet)
In order to connect the SPI bus this way, 3x MAX490 would be required on each side. Something like this.
The above approach has a clock delay problem. So it has limitation in bus length and bit rate. This is what @Andy was referring to in his comment.
Here's an application note that further explores clock delay and proposed a solution (and this one too). However, that solution requires 2 separate SPI peripherals on the microcontroller.
Here's another app note on clock delay in the context of high speed SPI.
Best Answer
I found an interesting read from Texas Instruments here called Extending the SPI bus for long-distance communication by Thomas Kugelstadt. It sounds pretty difficult to just make it work keeping it as SPI, but they do say you can get (up to) 100m+.
I would say, definitely do the SPI-to-RS485 conversion. Use the differential drivers through shielded twisted pair cables to get that 100m distance. This is the sort of task it was designed for.
Maybe even use fiber optics for the RS485 if you want minimal noise or delay problems.
The capacitance of 100m of cable will ruin any attempt at synchronous (clock based) high speed serial protocols like SPI, and making the voltage 12V will make the problem even worse, as the slew rate of the transmitting op-amp will need to be much higher than if it was only driving 3.3 or 5V over the same capacitance, because to change logic state it has to produce more change in voltage on the line.
Differential signals used in RS485 can operate at a nice low level (+-1.5V usually) and still be very fast. RS485 can usually do the standard baud rates up to 4000ft of cable. Because 100m is only around 300ft, you can expect the standard 115200 baud rate to work fine, or maybe even try the higher baud rates if your chips will let you, to squeeze as much performance out of your SPI->RS485 link as possible.
After the RS485 transmission, your LED driver chip can then receive SPI protocol commands from the protocol conversion chip, as if there was nothing betweeen the LED chip and the sender.
There WILL be delays for the SPI-> RS485 -> RS485->SPI conversion (see the datasheets of the protocol conversion chips for these numbers) and of course RS485 has a slower overall bandwidth than SPI. There is an NXP chip "SC16IS752" I found which can do this SPI to RS485 for you, otherwise you could look at doing SPI to UART, then attach a RS485 transceiver ship on the output of the UART before going out onto the cables.