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

Groups > comp.arch.embedded > #30399

Re: Multi-master RS485

Show all headers | View raw

On 31/03/2021 00:34, pozz wrote:
> Il 28/03/2021 00:37, pozz ha scritto:
>> 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.
> 
> Many thanks to all of you that spent some time to answer my question.
> 
> Some additional details. The example I wrote is... just an example and
> not exactly the real application. The system has a central unit and many
> slaves installed in different places of a building (imagine a keypad, a
> sensor and so on). This is a home/building automation application.
> 
> After first connection the master sends many configuration data to
> slaves (around 2-4kB), so CAN bus is not ideal because of its small
> packets (however I can split data on different packets).
> Then the bus stays idle for most of the time. The user could interact
> with a slave and only in that case the slave has something to tell to
> the master.

CAN is a short-range protocol.  If your bus is over about 20-30 m,
forget CAN.  (People do use it for longer distances, at low speeds, but
it's horrible for the task.  And CANOpen and other "standards" look like
they were designed specifically to be as complex and inefficient as
possible.)  For a short range, small message bus on a closed network
entirely under your control, CAN is great.

> 
> Yes, you are right when you say that putting a known limit on the worst
> case can be done with a polling approach. However my goal is not limit
> the worst case, but minimizing the "normal"/mean delay in the
> slave->master->slave transaction.
> I know this mean of delays can be reduced a lot, because the bus is idle
> most of the time, so the probability of a conflict is very very low.
> 
> Even number of slaves was just an example. I can think of systems with
> 50 or 100 slaves and in those cases the polling approach performance
> would be very bad.
> 

You should try to think about having multiple bus segments with fewer
nodes per segment, and some sort of aggregator or gateway that combines
them.

> Do you know of real wired cable used in home/building automation? I
> heard about KNX on twisted pair, but I think the complexity and cost of
> the system would increase very fast.
> 

I think KNX is mainly used in lifts, but I'm not sure.  There are a
large number of "standards" used for building automation, with a variety
of pros and cons, standardisation processes, membership fees,
complexities, etc.

As Don said, often the cost of the wiring is the real price.  But that
can depend on where you are (the ratio of electrician hourly rate to
cable price per meter varies hugely around the world) and the stage the
building is at.  Pulling one more cable while the building is being
constructed, is practically free.  Installing hidden wiring in a
building in heavy use is massively expensive.

So sometimes using existing Ethernet networks, wireless networks (either
Wifi or a dedicated wireless network), or even power-line communication
can be cheaper than wiring.

If you want the newest and coolest solution, try two-wire Ethernet.
Long-range does 2 km point to point, while short range is (IIRC) 40 m on
a multi-drop bus - though I haven't seen any PHYs for short range
two-wire Ethernet as yet.

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