4
\$\begingroup\$

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.

\$\endgroup\$

2 Answers 2

Reset to default
3
\$\begingroup\$

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.

\$\endgroup\$
5
  • \$\begingroup\$ Good point. It would mean adding an extra driver chip, as few micros have a 485 peripheral built in, but could be worth it. Do you really think that I am likely to see significant errors over 3m though? For example, the Playstation game console uses SPI over such cabling at around 100KHz clock rate. I seem to recall that the N64 uses non-differential serial at similar rates too. Edit: actually the Playstation uses 500KHz, 3.3v signalling, and with extension cables can easily do over 3m: store.curiousinventor.com/guides/PS2 \$\endgroup\$
    – user
    Commented May 21, 2014 at 12:14
  • \$\begingroup\$ FTDI make a USB-async TTL lead, 1.2m I think; the USB-serial adaptor is in the USB plug end, so it tries to ship async TTL over the 1.2m lead. At data rates over 38.4kbps it has a very noticeable error rate. Clocked protocols are always more reliable than async ones at the same bit rate so I'm not surprised to see 100kbps with the PS and/or N64, but I don't think it's an optimal choice. \$\endgroup\$
    – markt
    Commented May 21, 2014 at 12:21
  • \$\begingroup\$ Do you have any references for the FTDI issue? Note that the N64 uses one data line only, it is not clocked, and runs at around 333KHz. I think the FTDI problem could be due to poor cabling, but USB is at least shielded. \$\endgroup\$
    – user
    Commented May 21, 2014 at 14:06
  • \$\begingroup\$ My reference is my own experience and that of a colleague. It's not poor cabling, the cable appears to be reasonably good quality shielded cable (although it could be cable capacitance). It's because the signalling isn't differential, or even high voltage like RS232. USB is both shielded and differential so very reliable. \$\endgroup\$
    – markt
    Commented May 21, 2014 at 23:18
  • \$\begingroup\$ Okay, well it appears that you must have had some other issues then, because there are plenty of examples that contradict your experience. I was hoping for some insight into that sort of thing. \$\endgroup\$
    – user
    Commented May 22, 2014 at 9:07
-1
\$\begingroup\$

This has been done in many applications, what you need is a mux which routes the signal pins either to the microcontroller usb pins, or to the serial interface pins.

This way the signals always end up where they should go, and the two busses can not interfere with each other.

Regarding the serial protocol it is best to go with a differential bus (USB is differential...)

It is possible to get TTL serial a few meters, but it depends a lot on the speed and cabling!

\$\endgroup\$
1
  • \$\begingroup\$ As I said this particular micro happens to have a UART and SPI bus on the same pins as the USB, so it is just a case of disabling one peripheral and enabling the other to switch over. \$\endgroup\$
    – user
    Commented May 21, 2014 at 12:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.