Electronic – Serial comms over 3m cable, shared with USB

cablesi2crs232spiusb

I am designing a system that needs to do serial comms over a standard USB cable, as well as normal USB (but not at the same time). In other words, when plugged in to a PC it will appear as a USB device and when plugged in to an embedded system it will use a simpler serial comms protocol. The USB side is only full speed (12Mb/sec), and the serial comms only need to be 100Kb/sec, although 1Mb/sec would be nice.

The stand-alone device will use a microcontroller for comms. Both the device and the embedded system will be microcontroller based, most likely Atmel XMEGA. One option would be to fit a device with USB OTG/host support, but I want to avoid this complexity, cost and limited choice of microcontrollers.

The XMEGA micros have UART and SPI peripherals on the same pins as USB D+/D-. I could route I2C from two other pins over to them as well, and I don't think it would harm signal quality. Since the USB cable only has two lines if I used SPI it would be unidirectional, which I could cope with. Bi-directional I2C or 3.3V RS232 would be nice though.

Has anyone tried anything like this? I am a little concerned about the capacitance of a 3m USB cable causing problems. None of these serial protocols are differential, but should cope with poor signal edges. You can get line drivers for I2C/SPI/TTL-RS232 but the ones I have looked at seem like they would interfere with USB when not in use. Thinking about it, I2C without a line driver could be problematic due to the need for pull-up resistors.


After doing some research I am leaning towards 3.3V RS232. I could use SPI but synchronous protocols may have issues with a 3m cable at high speeds. If the receiver generates the clock there will be some delay before the sender sees it and the response arrives. If the sender generates the clock there will be no problem with delay (since data will be delayed by the same amount), but it somewhat complicates two-way communications. The other disadvantage of SPI is lack of start/stop bits, but usually isn't a problem because you can use an enable line to start communication at a known point, but I don't have enough lines for one.

Then again, being clocked may be worth the extra effort on the protocol side in order as it should be more robust with signal degradation. Terminating resistors should help deal with reflections.

In any case, reasonably high speed should be possible. The Sony Playstation uses SPI at 3.3v with a 500KHz clock, and works fine with long leads. The N64 uses a single aysnc data line (no clock) at around 333KHz, again over long leads.

Best Answer

My advice is to use a UART and RS485.

If you try to use any non-differential signalling protocol on a lead that long, you will get a terrible BER at useful data rates. Differential half-duplex async is the way to go.

Your concerns about sharing the bus with USB are valid, but RS485 drivers can (generally) be put in a high-impedance mode that might be willing to co-exist with USB.