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

Groups > comp.arch.embedded > #30394

Re: Multi-master RS485

Show all headers | View raw

On 3/28/21 9:52 AM, Hans-Bernhard Bröker wrote:
> Am 28.03.2021 um 00:37 schrieb pozz:
> 
>> 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.
> 
> That will never be possible.  If 30 those slaves simultaneously trigger
> a request, then at least one of them will have to wait for the
> communication to all the others to be done before it can get its reply.
> 
> The worst case for a bus of 30 slaves cannot possibly be exactly as
> quick as the optimum case for a single slave.
> 
> The only way that could work is if there is no bus at all, but rather a
> star topology: each slave has its own, dedicated connection to the
> master. I'll assume that this untenable because of the cabling costs.
> 
>> It is impossible with polling approach. However the bus is idle
>> (without real data) most of the time. 
> 
> That makes no sense at all.  If the bus is so idle, why are you polling
> so slowly?  Why would you poll at any less than the maximum possible
> communication rate, while at the same being concerned about too long a
> response time?
> 
> But I'll second upsidedown's hint: you appear to be trying rather
> unnecessarily hard to reinvent CAN.

On thing to note, if you are worried about WORSE case performance even
under full load, the synchronous polling is probably the best option. If
every keypad got the last key press at exactly the same time, the
shortest maximum delay would have the master go at full speed and
interrogate each slave and process it. This eliminates all the loses due
to conflicts and re-transmitting.

If you do use a CAN bus style arbitration, and can make the protocol not
lose frames in the case of a conflict, and the 'high priority' slaves
will wait long enough between mesages to give everyone a chance to send
their message, then that might get a bit faster as the amount thqt needs
to be sent is less, but the protocol overheads to wait to see the bus is
idle might eat that up.

The asyncronous messaging with arbitration is probably faster at
'average' delay under lighter loads. This is just the way these things
tend to work.

Another option is to use a dominate/recessive bus drive and the master
sense out a query request, and with a fixed timing any slave that has a
request replies with its address, and sees if someone else answer too,
and drops out on conflict. (This method is used on the SMB Bus). The
master can then poll at a base rate, and then if it gets a reply,
immediate ask for more requests until it gets a no request pending answer.

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