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


Groups > comp.arch.embedded > #30390

Re: Multi-master RS485

Subject Re: Multi-master RS485
Newsgroups comp.arch.embedded
References <s3idlk$dm7$1@dont-email.me> <s3l03h$gob$1@z-news.wcss.wroc.pl> <s3ofjd$4tv$1@dont-email.me> <2UP7I.42523$RS3.2262@fx18.iad> <8kvv5gh272bm5jthkpt8p8hnfa7fdj0s77@4ax.com>
From Richard Damon <Richard@Damon-Family.org>
Message-ID <eEZ7I.58356$QT3.46106@fx33.iad> (permalink)
Organization Forte - www.forteinc.com
Date 2021-03-28 07:20 -0400

Show all headers | View raw


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.

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