maximum ranges of serial, spi, and I2C?

If you look at i2c, you will often find a capacitance spec and the FM+ has higher current drivers, which allows lower pullups, and thus tolerates more cable length.

SPI is a nominal 5V TTL/CMOS bus, so has no cable drive specs.

RS232/RS485/ProfiBUS etc are the stds for longer cable runs, and you can find the specs on the cable drivers. CAN also adds a handshake delay, so has lower MAX bauds than RS485/422.

All systems have a speed/distance trade off : The longer the cable, the lower the speed.

If you do not need 'clip on' compatible operation, you can extend most BUS lengths with better cable drivers and handling.

-jg

The RS-232 specification only allows for 15 m and I very much doubt that if all the requirements even in the newer versions of the RS-232 is observed that you even could run 1 Mbit/s through it.

A much better serial interface form is the RS-422/485 standard. It is differential and the impedance levels match with the transmission line (twisted pair) impedance. You should be able to run more than 100 m at

1 Mbit. Profibus-DP (which is essentially RS-485) can reach 100 m at 12 Mbit/s even in a multidrop configuration with some attention to detail.

Those are unbalanced systems, so they suffer from ground potential differences (including ground bounce) even with quite short distances. Balanced, differential mode systems, such as RS-422/485, CAN etc. will tolerate ground potential problems within the common mode voltage range (typically -5 .. +12 V and if large common voltages may exist, use optoisolation) and cancels most common mode electrostatic and magnetic interference.

Paul

That old myth. The RS232 spec (old versions) actually quoted that at

15m on a poor cable, a certain frequency, and lots of pairs used, for modem signalling, that the noise level got to a certain level. There was NO length spec, as it is very cable type dependent. There was no mention of this being outside of the noise spec.

I have seen tests done at 38k baud that were done with front door bell (admission bell) wire still on drums, where over distances greater than

1km there was minimal degradation. This was using RS232B class drivers.

In 70's and 80's I have worked in companies where there was RS232 cable runs to lots of VTxxx terminals, where the *minimum* cable run was 20m to get out of computer rooms and into ducting runs.

Choose your cable carefully. Yes, still observe what your distance/speed tradeoffs are.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

Bear in mind that all of RS422, RS232, RS485 are hardware specs, and that no error control or correction is embedded in any of them. That is something you add when designing your own protocol.

--
 
 
 
 
                        cbfalconer at maineline dot net

SPI and I2C are not intended for the distant communication. They should be used for the connections within a module. Running I2C or SPI on the outside of a device is a bad idea.

I2C sucks because of the open drain. SPI is somewhat better. RS-232 is much better.

They are comparable. It depends on the PHY and the system layout.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

RS-485 is another that we have been considering. I have read that multi-master systems are possible with 485. What sort of protection is there from collisions with 485? As far as I can find, there are none - so everything would have to be done in software. Also - how exactly would one achieve RS-485 communication with a typical microcontroller? Most uCs have tx and rx lines for serial communication. From my understanding these same lines could be used for RS-485. Is that accurate? If so - if you have a half duplex RS-485 link, how does the transceiver know whether to drive the line or listen? Is there a direction control on 485 transceivers or something?

Thanks,

-Michael

Indeed they are.

You design a protocol such that only one device transmits at a time.

Yup.

Yes.

You tell it.

Yes.

Have you heard of google?

In particular these links are good ones:

--
Grant Edwards                   grante             Yow!  I want to kill
                                  at               everyone here with a cute
                               visi.com            colorful Hydrogen Bomb!!

Do you mean multi-master or multi-slave ?

For multi-slave just use any master-slave protocol with addressable slaves. The master must allow sufficient time for each slave to response, including the response transfer time and any request processing latency in the slave.

Thus, in order to keep a decent throughput, the slave should respond quickly to the request e.g. doing the processing in a high priority task or even in the interrupt context.

For a true multi-master system, just pass a token message to an other master and remain silent, until some other master passes the token message back to you. Some protection against lost tokens must be used in the protocol.

It should not be needed with a proper protocol. Anyway, the transceivers are short circuit protected, so conflicts do not harm the hardware (although the chips may run quite warm, if the cable between the offending transceivers is short).

Any decent UART should have a RTS (RequestToSend) that can be programmed to be active, while bits are still being transmitted. This RTS line is used to control the data direction on the RS-485 transceiver chip.

If such automatic control is not available, you have to control the RTS line by software (as with the common 14550 series UARTs) or use a separate parallel uC port for it.

However, there are a few pitfalls with a few such UARTs that need software RTS control. It is important, that the control line is turned off immediately after the last (stop) bit of the last character has actually been sent, since the other end may start to send a response message. However, if you turn it off too early, the most significant bits of the last character is cut off and the receiver will receive a character with the high bits set.

If you get "All_bits_sent" interrupt, then it is easy to turn of the transmitter from the interrupt service routine, however, for the 14550 series UARTs you only get an interrupt when the last character was transferred to the Tx shift register, but it is just starting to be shifted out from the shift register. You have to poll the shift register status register very frequently (a bad idea in multitasking systems) to see, when the character has been fully sent.

One other way of doing this on stupid UARTs, such as the 14550 series, is to keep the receiver active and listen to the echo of your own transmission and when the last character echoed generates an RX-interrupt, turn off the transmitter from the interrupt service routine. Of course, the RX-FIFO (if exist) should be disabled to get a quick response to the RTS line.

Paul