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

Groups > comp.arch.embedded > #30381

Re: Multi-master RS485

Show all headers | View raw

On 3/25/2021 9:57 AM, pozz wrote:
> Il 25/03/2021 17:33, Don Y ha scritto:
>> On 3/25/2021 9:27 AM, pozz 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.
>>>
>>> I'm thinking to "improve" this bus with a multi-master approach, but it 
>>> doesn't appear simple. Do you know of real and working implementation of 
>>> this type on half-duplex RS485 bus?
>>
>> Sure!  An easy way is to time-division-multiplex the bus and assign
>> specific slots to specific nodes.
> 
> This means assigning a predefined slot duration for each node. What happens if 
> a node wants to transmit a big packet? It should split packet in multiple 
> consecutive slots.

Or, the next node defers claiming it's timeslot until it senses the bus has
gone idle.

You have to decide how much you want to put in the lower level protocol
and how much you're willing to put *above* it (e.g., packet reassembly)

> Moreover, is time-division-multiplex efficient? Now with master-slave polling 
> mechanism I already have a time-division-multiplex: for each slave there's a 
> time window in which master sends the token and slave reply with token (and 
> probably data).
> With a pure time-division-multiplex I will save only the time of the master 
> request.

It depends on how big your packets are, how high the bus utilization, etc.
Only *you* can make that determination, from *your* application.

>> You can also use a token-passing protocol to select the next master.
> 
> Same, each node is an "active" node in every loop. I imagine a bus that is idle 
> for most of the time and busy only when a node wants to transmit something.
> In my case real data are very low. Anyway I have to face the event of a conflict.

If there is nothing to transmit, a node just sends a "keep alive" packet.
This also lets other nodes know that the network (and other devices on it)
are intact.

[When should a node "get nervous" that it hasn't been polled, "recently"?]

>> You have to address start-up issues to initialize the first
>> set of accesses.  And, you have to include provisions to handle
>> the case where things go wonky and resynchronization becomes
>> necessary.
>>
>> But, you *can* handle things like a device failing to pass the token
>> or skipping its timeslot in the "normal" protocol.
> 
> This is why I'm searching a "ready-to-use" protocol, if any.

Dunno.  I always roll a protocol that is appropriate for the
application.  That lets me tailor it to get the best performance
for the cost invested.  (my designs are closed so I don't have
to worry about something being *added*, arbitrarily, at a later
date)

The exercise of thinking about the protocol often reveals
vulnerabilities in the design; "what if node X doesn't
take its time slot?  what does that mean for the system,
as a whole?  should the other nodes be able to independantly
detect this and bring the system to a safe/secure state
WITHOUT waiting for the master to command them to do so?"

(what does it *mean* when X is misbehaving?)

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