Interfacing multiple SX circuits

boan

Hi

I'm developing a motorized fader automation system.·An SX28·is controlling·each (interfacing ADC, LED, PWM DC motor etc) fader, and then the data is sent to a PC (or received in playback mode) for storage. Today i'm using an UART implementation (But this is only during this early stage development). In the future it is not realistic to use the serial port since the number of faders will be >16.

I have a·SX48 and FTDI parallell USB·circuit which i plan to connect 16 subcircuits (as described above) and i'm thinking of the best way to connect them. The speed requirements are not such a big issue. Is the SPI interface recomended? I mean i have 24 pins available on the "Master" but i want to use as few pins as possible on the "SLAVEs". Does anyone have recommendations?

I'm sure someone have experience from interfacing multiple SX circuits. Any problems i can expect, pointers, Code snippets...?

I've looked at the SPI master and slave code example from Ubicom. Is this what U have used or?

Cheers!
//boan

Bean

I would look at a multi-drop serial protocol.
Something like DMX512, although I don't think DMX512 is bi-directional.
Bean.

boan

Ok, that can be one alternative if there are bi-directional implementations

I think i need full duplex and more or less the same bitrate UL / DL. Another input to the PC will be a SMPTE generator (i.e. 25 frames granularity per second) so the channel values must as least be updated with the same frequency. Every fader value is 10bit so > 4kbit/s is probably sufficient. (16 * 25 * 10) = 4000

//Anders

allanlane5

The SPI interface is a little difficult on the 'Slave' side. It would be better to use a 'party-line' RS-485 implementation, signaling using SERIN/SEROUT commands. This gives you full duplex, 4000 feet of distance, and the RS485 transcievers already allow 'collisions' without circuit damage.

I assume your current RS232 implementation uses a port-per-fader approach, so for RS485 you'll need to implement some hand-shake protocol logic. For example the 'Master' can request data from each 'Slave', so the 'Slave's don't all send at the same time and garble data.

PJMonty

Actually, DMX512 is RS-485. Since RS-485 is just a serial electrical spec, DMX512 adds all the rest of the details (data specs, plugs and jacks, baud rate, etc) that make up a complete interface spec. However, DMX512 is a uni-directional protocol, and also a pretty lame one in my opinion.

Basically it runs a constant data stream at 250 Kbits a second, where there is a special handshake at the start to indicate the beginning of a frame of data. In this case, the frame is just 512 sequential bytes of data. Each device attached to the data stream is given an address from 0 to 511, and as the data comes in on each frame, each device plucks the single byte from the stream that is intended for it.

Yes, this means that if you had the full load of 512 devices attached, and you wanted to send 10 bytes of data to a particular device, you would actually have to send 10 frames of 512 bytes each where each frame had a byte of the data for the intended device. Of course, you'd also be sending data to all the other devices, whether they needed it or not. Hence, you might have to pad frames with a lot of zeros if other devices didn't need updating at that moment. Also, it means that you'd be sending 10 * 512 = 5120 byte of data just to get 10 bytes to the intended target. It's incredibly inefficient.

The only thing that can make data transmission a little faster is that there is also a handshake to end a frame early. So, if you only had devices with addresses 0, 1, and 2, you can just send frames with 3 bytes in them. Of course, if you had devices 0, 1, and 511, you would have to send the entire frame of 512 bytes because it's just a binary stream of sequential data, with no ability to address data to a device other than it's physical position in the stream.

What you should look into is MIDI Show Control. It's MIDI, but with messages designed specifially for things like light dimmers, smoke machines, pyrotechnics, etc.

Thanks, PeterM

Guenther Daubach

Boan,

for projects similar to yours, I have successfully used the I²C protocol. Although designed for "Inter-IC" communications, I'm using it to even transfer information across a building. If speed is not the primary concern (e.g. 100 or 400 kbps or even higher as described in the I²C specs), longer data lines are no problem. The I²C bus is controlled by open collector devices, i.e. pull-up resistors are required on the clock (SCL) and data (SDA) lines. On distributed systems, I provide pull-ups on each device connected to the bus, of course, making sure that the resulting parallel resistance still can be driven (i.e. pulled low) by the connected devices. This helps to increase noise immunity. There are also I²C buffers or signal conditioner components available but I never needed to use them when running the bus at about 25 kbps.

The I²C protocol per se (and SPI not either) has no "built in" error detection/correction features. But as you are free to send whatever kind of data via the bus, you may add check sums when necessary. This is how I do it - I add a final check sum to each data packet, and when the receiving slave detects a check sum error, it simply does not acknowledge the last byte, and the master re-sends the packet again until it receives an acknowledge. Vice versa, when the master requests data from a slave, and the slave's anwser contains an error, the master can issue another request. This, plus some other safety measures, allowed me to run a system including PWM-controlled motor drivers, relay-controlling output devices, etc. without major problems on the bus. In one of my applications, the system is controlled from a master application running on a pocket PC "talking" to the I²C system via an RS-232/I²C converter.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

Günther

boan

Thank you all! I think i will have to look some more at I²C...

//Anders