Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #30392

Re: Multi-master RS485

Show all headers | View raw

On 3/28/21 7:59 AM, upsidedown@downunder.com wrote:
> On Sun, 28 Mar 2021 07:20:43 -0400, Richard Damon
> <Richard@Damon-Family.org> wrote:
> 
>> On 3/28/21 12:32 AM, upsidedown@downunder.com wrote:
>>> On Sat, 27 Mar 2021 20:14:54 -0400, Richard Damon
>>>
>>>> The Problem is that RS485 is not designed with this sort of architecture
>>>> in mind. Yes,you could build a protocol which the slave listens first
>>>> and makes sure no one else is talking, Then send the message (with good
>>>> error detection built in) and see if it gets a response (maybe first an
>>>> ACK and then later an order to go ahead). If you don't get the ack, you
>>>> presume that your message got garbled so you send again after some
>>>> random wait designed that you and whoever you conflicted with won't send
>>>> again at the same time. MAybe even the master sends a NAK that it got
>>>> garbage.
>>>>
>>>> Much better would be use a driver that can reliably detect a conflict
>>>> with known results. You send your message and listen for conflicts. If
>>>> you get a conflict you stop sending immediately.
>>>>
>>>> If the system uses a driver where say 0 always wins over a 1, and the
>>>> bit time is longer than the network transmission time, then if two
>>>> drivers start at the same time, whoever send the first 0 when the other
>>>> wants to send a 1 will win and get their message through. The other
>>>> backs off, waits for the message and ack to clear, then does their message.
>>>
>>> It sounds that you are trying to reinvent the CAN bus protocol ?
>>>
>>> You can even use RS-485 transceivers chips (Data out to Transmit
>>> enable, Tx input to fixed "0"). You need a CAN control chip, e.g.
>>> SJA1000 for the master and some simpler for slaves. There are several
>>> uCs with built in CAN controllers usable as slaves.
>>>
>>> With CAN, there are some snags. The maximum net payload is 64 _bits_
>>> (8 bytes) so if more data needs to be transmitted, you may have to use
>>> some higher level protocols above CAN. The other snag is that all
>>> stations must hear each other well within a single _bit_ time to
>>> handle conflicts. This limits the length of the bus and/or maximum bit
>>> rate that can be used e.g. 250 kbit/s with 250 m bus cable. At lower
>>> speeds the range can be extended.
>>>
>>
>> That methodology is used in CAN, it is also used in I2C, and I suspect
>> other systems. It is close to the method used for ethernet on coax (but
>> that uses a slightly different method because the line might be longer
>> than allowing collision detection in a single bit.
> 
> The difference is that in coaxial Ethernet CSMA/CD collisions _both_
> messages are lost and _both_ needs to be retransmitted at a later
> time. In CAN bus, the higher priority message gets through despite a
> collision, only the lower priority message needs to be retransmitted.
> For this reason a much higher bus loading are possible in CAN, while
> in Ethernet high collision rates will kill the traffic completely much
> earlier.
> 
> The dominant/recessivebit  protocol used in CAN may also be used with
> other transports than RS-485 or dedicated CANbus transceivers. One
> could even use  with 20 mA current loop by putting all stations into
> the sane current loop, but the optoisolator photo transistor Vce(max)
> may limit the number of stations in the same loop to about a dozen.
> 
> 

Yes, the Ethernet protocal loses the whole message because the bit time
isn't large comparared to the propagation delay across the system, so
you might not know of the collision until it is too late to get off.

CAN/I2C require a bit time longer than network propagation, so the
transmitter knows after the first collision that it has lost, and the
master that was sending the dominant bit gets control.

As you say, you can use dominant/recessive bit physical layer with many
protocals, even pure asynchronous serial (though that may need a bit of
external logic to get you off the bus before you corrupt the message,
like the 485 with data on the enable.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-25 17:27 +0100
  Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-25 09:33 -0700
    Re: Multi-master RS485 Grant Edwards <invalid@invalid.invalid> - 2021-03-25 16:38 +0000
      Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-25 09:57 -0700
      Re: Multi-master RS485 David Brown <david.brown@hesbynett.no> - 2021-03-25 20:28 +0100
    Re: Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-25 17:57 +0100
      Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-25 10:04 -0700
  Re: Multi-master RS485 upsidedown@downunder.com - 2021-03-25 19:02 +0200
  Re: Multi-master RS485 antispam@math.uni.wroc.pl - 2021-03-26 15:54 +0000
    Re: Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-28 00:37 +0100
      Re: Multi-master RS485 Richard Damon <Richard@Damon-Family.org> - 2021-03-27 20:14 -0400
        Re: Multi-master RS485 upsidedown@downunder.com - 2021-03-28 07:32 +0300
          Re: Multi-master RS485 Richard Damon <Richard@Damon-Family.org> - 2021-03-28 07:20 -0400
            Re: Multi-master RS485 upsidedown@downunder.com - 2021-03-28 14:59 +0300
              Re: Multi-master RS485 Richard Damon <Richard@Damon-Family.org> - 2021-03-28 08:09 -0400
      Re: Multi-master RS485 antispam@math.uni.wroc.pl - 2021-03-28 02:01 +0000
      Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-27 19:57 -0700
      Re: Multi-master RS485 Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2021-03-28 15:52 +0200
        Re: Multi-master RS485 Richard Damon <Richard@Damon-Family.org> - 2021-03-28 13:06 -0400
      Re: Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-31 00:34 +0200
        Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-30 18:51 -0700
        Re: Multi-master RS485 upsidedown@downunder.com - 2021-03-31 06:42 +0300
          Re: Multi-master RS485 Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2021-03-31 09:50 +0200
        Re: Multi-master RS485 David Brown <david.brown@hesbynett.no> - 2021-03-31 10:23 +0200
          Re: Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-31 12:27 +0200
            Re: Multi-master RS485 David Brown <david.brown@hesbynett.no> - 2021-03-31 14:43 +0200
          Re: Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-31 13:39 +0200
            Re: Multi-master RS485 David Brown <david.brown@hesbynett.no> - 2021-03-31 14:46 +0200
            Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-31 06:20 -0700
          Re: Multi-master RS485 upsidedown@downunder.com - 2021-03-31 15:29 +0300
            Re: Multi-master RS485 David Brown <david.brown@hesbynett.no> - 2021-03-31 14:49 +0200

csiph-web