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

Groups > comp.arch.embedded > #30386

Re: Multi-master RS485

Show all headers | View raw

On 3/27/21 7:37 PM, pozz wrote:
> Il 26/03/2021 16:54, antispam@math.uni.wroc.pl ha scritto:
>> pozz <pozzugno@gmail.com> wrote:
>>> Are there any *real* implementation of multi-master half-duplex RS485
>>> bus?
>>>
>>> I often use half-duplex RS485 and I always use a master-slave polling
>>> protocol. This choice dramatically reduce the complexity of the system
>>> and it works well with a limited number of nodes.
>>>
>>> When the nodes are 10 or 20 and they usually send only a few bytes in a
>>> minuted, the polling scheme is inefficient. The bus is alway busy for
>>> polling, but the real data are very small.
>>
>> What do you really want?  That is what is your "efficiency"
>> criterion.  For embedded system a lot of folks consider
>> worst case delay.  For normal design worst case is when
>> all nodes have data to transmit.  Clearly, "last node"
>> have to wait on all previous nodes.  So, best "efficiency"
>> would be sum of transmit times for data.  On top ot that
>> you have various overhead: bus turnaround times, time
>> for polling or token passing, possible timeout in case
>> of fixed time slots.  AFAICS polling messages from master
>> to slave may be very small, so they should at most
>> double time: you have twice as many messages compared
>> to case when each node "magically" knows when to
>> transmit.  You can play some tricks, like group poll,
>> when nodes are ordered (numbered) and each node in
>> the group is supposed to send its data, starting from
>> first.  Of course, it means that each node must be
>> capable of detecting end of transmission from
>> lower numbered node.  Token passing may be slightly
>> more efficient, as data messages may serve double
>> duty of passing token to next node: so you save
>> cost of polling messages.
>>
>> But you basically fight with constant factor of 2.
>> If you need more improvement, then you need bigger
>> change.  Say faster links or star topology.  In
>> star topology intermediate nodes may aggregate
>> messages, so you can significantly decrease number
>> of messages going to maser node.  And it is easier
>> to provide fast links to limited number of "hub"
>> nodes, than to have fast links everywhere.  But
>> as downside, there is more complexity and potentially
>> lower reliability...
>>
> 
> Suppose you have a bus with 20-30 nodes: one master is the central unit,
> the other are slaves that get a code from a keypad. When a code is typed
> on the keypad, it is transmitted to the master. If it is ok, master
> sends an ack to the slave that get the code so it enabled an electric
> lock and the door is unlocked.
> 
> With a polling scheme, master must sends a poll request continuously and
> the the slaves answer, most of the time, with no data. It appears to me
> a very inefficient approach.
> 
> What's the worst case, i.e. the delay between pressing OK button on the
> keypad and the door opening? It is the sum of 30 (number of slaves)
> polling requests and replies. If a single request takes 100ms, the worst
> case should be around 3 seconds.
> I'd like to reduce this time to 100ms.
> 
> It is impossible with polling approach. However the bus is idle (without
> real data) most of the time. I could avoid polling at all and instruct
> the slave to transmit when it wants. I think the probability of a
> conflict with another slave is very low and I could reach the
> requirement of 100ms above. However I sholud design the behaviour with a
> conflict, even rare, happens.

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.

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