Can you use SHIFTIN/SHIFTOUT over RS-232/422/485?

Professor Chaos

I have a sensor module that uses shift registers to 'serialize' 16 inputs. I read the registers using SHIFTIN with clock, load, and data lines.

I can read the shift registers from the BS2 over a few inches of cable, but not more than that.

So... if I use a serial protocol like RS232, 422 etc, can I just feed the clock, load, and data lines through RS transceivers/line drivers at each end and expect the synchronous serial comunications to work?

Mike Green

Not quite true.

First of all, the clock rate from a BS2 is fairly slow (clock pulse width 14us, clock period 46us ... see the PBasic manual). You should be able to do this over a foot or two at least. You may be picking up noise with longer cables. I suggest that you use either a twisted pairs cable or a controlled impedance ribbon cable with alternating signal / ground pairs.

RS232 signalling would work at this speed, but is probably overkill. You can't use an asynchronous serial protocol without a converter, but RS232 or RS423 signal levels and driver/receivers would work ... Keep in mind that these slow down signal transitions to limit noise, but would probably work fine at these speeds.

Professor Chaos

OK, I admit my measurement of "more" was not of the highest resolution. 6 inches = yes; 10 ft UTP = no. This was without any termination or alternating grounds.

Mostly I am curious if the converter solution would work, which I take it it would at BS2 synchronous speeds. I guess I could use some sort of termination (AC?) and gating of logic lines instead, but it's not clear that's particularly easier than running the signals through a line driver.

It does make me wonder what the usual way of connecting sensors from long distances is, short of having some intelligence at the remote end to encode the data.

Phil Pilgrim (PhiPi)

Using your present setup, try terminating each data line at the receive end with a 2.2K resistor to Vdd and a 3.3K resistor to ground. You may see an improvement, since you'll be forcing the lines to carry current, which helps to limit the effects of noise. This should work with HC, HCT, LSTTL, etc. But it may be too much of a load for 4000-series CMOS. (You didn't indicate what kind of shift registers you're using.)

-Phil

Mike Green

Generally, over distances of inches to a few feet, TTL levels should work fine as long as you have a "good" cable and, at the longer end of things, line termination as Phil suggested. Beyond that, some kind of line driver should be used as well. You could just use a buffer at the sending end and a Shottky input buffer at the receiving end.

As you get to longer cables, relative timing of multiple signals tends to become a problem and you either have to slow down the timing (and the clock) or go to an asynchronous signalling method or self-clocking system of some kind.

allanlane5

The simple answer to your question is "Yes", you can use RS-232 drivers and recievers, to extend the distance of a "Synchronous" signal (clock and data) used in "SHIFTOUT". It's better to use the SERIN/SEROUT keywords here, though, since that requries only a single line. And you can use RS232, RS422, or (my favorite) RS423 in this way.

Also, be aware that for SHIFTIN, the BS2 provides the 'clock' for the 'slave' device. A long distance between the BS2 and the 'slave' could shift the clock -- but how long that distance is I couldn't say.

Really, the only reason for using SHIFTIN/SHIFTOUT in this way is if your 'slave' device is so simple it doesn't have a processor of any kind. Which happens, but is rare. I've seen a 3-wire interface for a parallel LCD that used 74HC595 and 74HC164 to accomplish this that used SHIFTIN/SHIFTOUT.

Professor Chaos

Thanks for the info. The slave device is indeed simple - mainly because its creator (me) is simple. It reads the outputs of 16 optocouplers and feeds that back into a stamp (The optocouplers detect the presence of toy trains via AC current). Cascaded SN74HC165 registers collect the data and I read them from the BS2

It seems like a more rational design would be to have a simple controller on the slave device that reads the optocouplers and packages the data for asynchronous transmission. But at the moment the BS2 is the only thing I've got (or understand).

Chris Savage

Professor Chaos,

Just to clarify for future postings the protocol and driver specifications are two different things. RS-232 is not a protocol but an electrical specification as is RS-485/RS-422 etc. The protocol would be the Serial, SPI, I2C, etc. So your question revolves around using a specific protocol on a specific line driver. Quite often RS-422/RS-485 use serial protocol but not necessarily. Standard network connections will use their own protocol which the BASIC Stamp cannot talk directly to. Just wanted to put that out there for those who sometimes confuse the protocol and electrical specification. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

Professor Chaos

Just wanted to report success with this technique, at least at the speed a BS2 uses for synchronous serial protocols. Feeding the clock, load, and data signals through RS-232 transceivers seems to work quite well, though I have not ascertained the maximum length possible.

You can make do with a dual tranceiver at each end, since at each end you need 2 Tx / 1 Rx or 2 Rx / 1 Tx. Since transceivers are cheap this seems like a decent solution.

Mike Green

I'm glad it worked. The larger voltage excursions help with noise rejection. If you ever switch to a much faster Stamp (like the BS2sx or BS2px), you may have some problems with the higher clock rate (about 5 times faster) since the RS232 transceivers deliberately slow the rise and fall time of the signals to reduce noise.

allanlane5

Well, the classic 1488 and 1489 chips DID slow the rise and fall times quite a lot, in order to control radiated noise on the RS-232 lines. (It turns out, fast and sharp rise and fall times have lots of high-frequency harmonics, which radiate really well).

The newer Max232 chips, which support the 115KBaud and above, produce shorter and faster rise and fall times than the old RS-232 spec -- which is a good thing. But that's what Mike is talking about. It would be a good idea to hang a logic analyzer (or even a storage Oscilloscope) off each end to see what signal degradation is happening, if any, just to check.

It would look like 'rounded' edges on clock signals, phase shift on clock signals, and perhaps even lower amplitude on the returned clock signal.

However, thanks for the update and I'm glad it worked for you!