1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

maximum ranges of serial, spi, and I2C?

Discussion in 'Embedded' started by Michael, Jun 13, 2007.

  1. Michael

    Michael Guest

    Hi there - can anybody tell me the maximum ranges of serial, SPI, and
    I2C? Specifically, I'm referring to I2C running at 400Kbps, serial at
    1Mbps, and SPI at 1Mbps. I guess with serial the physical layer used
    changes things around alot - so I'm referring to RS-232. Is there a
    better name than serial? I mean, serial seems pretty vague, though I
    suspect most know what I am referring to.

    Also, how do serial, SPI, and I2C compare in tolerance of noise? I
    would assume that RS-232 serial can handle it the best, while SPI and
    I2C both probably don't tolerate it very well at all.

    On a related note - anybody know how RS-232 and CAN compare in
    handling noise? I suspect that CAN, even though the standard physical
    layer is lower voltage than RS-232, handles it better due to being a
    differential bus.

    Thanks!

    -Michael
     
    Michael, Jun 13, 2007
    #1
    1. Advertisements

  2. 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
     
    Jim Granville, Jun 13, 2007
    #2
    1. Advertisements

  3. 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
     
    Paul Keinanen, Jun 13, 2007
    #3
  4. 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, Jun 13, 2007
    #4
  5. 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

    http://www.abvolt.com
     
    Vladimir Vassilevsky, Jun 13, 2007
    #5
  6. Michael

    Michael Guest

    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
     
    Michael, Jun 14, 2007
    #6
  7. Indeed they are.
    You design a protocol such that only one device transmits at a
    time.
    You tell it.
    Yes.

    Have you heard of google?

    http://www.google.com/search?q=rs-485

    In particular these links are good ones:

    http://en.wikipedia.org/wiki/RS-485
    http://www.lammertbies.nl/comm/info/RS-485.html
     
    Grant Edwards, Jun 14, 2007
    #7
  8. 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
     
    Paul Keinanen, Jun 14, 2007
    #8
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.