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

Groups > comp.arch.embedded > #30388

Re: Multi-master RS485

Show all headers | View raw

On 3/27/2021 4:37 PM, pozz wrote:

> 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.

That's because you are envisioning a request/ack per slave.  So, the maximum
latency is O(Kn) and increases with increasing 'n'.

You can reduce K.  Or, you could design the system so that the master
is not involved in that decision making process.  E.g., the master can
*tell* each node whether it can respond to a local keypress by unlocking the
door -- and reporting that after-the-fact if the master needs to track that
info.

To reduce K, you can initiate a polling frame at t=0.  Each node watches the
bus for I*L time (L being the time in which any lower numbered node can
reply; I being the ID of the current node).

Any node wanting the master's attention (or, wanting to tell the master
"yes, *my* keypad was activated!") seizes the bus at its timeslot and
generates an appropriate response.  All nodes with "higher* IDs
add the time required for this response (which could be known /a priori/
if you can ensure replies to THAT type of polling request are always
a fixed duration) to the delay that they wait before taking *their*
turn.

You can also change the polling order (for individual polls *or* for
this sort of group poll) to reflect where you are most likely to
encounter slave requests.  E.g., if node X has seen keypad activity,
recently, it may inherently be less/more inclined to see activity in
the near future.

For example, requests to access the janitorial supply closet may be
infrequent during *normal* occupancy. Requests to access the CEOs
office may be infrequent "afterhours" -- when the janitor's
activities are more commonplace.

You seem to be wanting a generic solution -- and then complaining that
it isn't very efficient for YOUR application!

> 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.

Then you need to be able to detect collisions on the bus (e.g., CD/MA).
With EIA485, that's not always possible as the signal your node
"sees" isn't exactly the signal that every OTHER node is seeing.

At the very least, the master would have to be able to ensure the
bus returns to an idle condition that the protocol *enforces*...
so that it can then verify what it thinks just transpired.

And, other nodes (who may have competed for the wire -- and *apparently*
lost) can note that their messages were NOT heard (as evidenced by the
fact that the master replied to someone OTHER than them!)

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