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.
Multi-master RS485
Started by ●March 25, 2021
Reply by ●March 27, 20212021-03-27
Reply by ●March 27, 20212021-03-27
pozz <pozzugno@gmail.com> 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.100ms for round trip looks very long. You should be able to do with very short (3-4 bytes, maybe 8 if you add strong cryptography) messages, so at 9600 even with delays for turnaround you should be closer to 20-30 ms. And I do not understand why you wait for OK? Typing on keypad takes some time and it is likely that node will be polled before number is finished. Then node can ask for polling with shorter delay. If only small number of nodes asks for more frequent polling, then master can respect this giving you shorter effective response time. If several (most of) keypads are busy, then clearly master can not quickly serve all of them, but that is exactly situation where nodes talking without polling would lead to trouble.> 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.You can bring down average, but worst case will be bad: in case of conflict you need enough delay to significanlty reduce risk of repeated conflict. And detection of conflicts may be problematic. You may sell more, as during demo salesman can arrange for no conflicts and clients will see best case. But you may get bad publicity, as ocasional, much longer than usual delay will look like malfunction. -- Waldek Hebisch
Reply by ●March 27, 20212021-03-27
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!)
Reply by ●March 28, 20212021-03-28
On Sat, 27 Mar 2021 20:14:54 -0400, Richard Damon <Richard@Damon-Family.org> wrote:>On 3/27/21 7: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.Does the user have to press a single key or enter a multidigit access code ? In the latter case, do the access code processing locally including feedback beeps and only send a complete sequence to the master. When the user enters the first digit, answer to the master poll "data will soon be arriving" i.e. there is a user at the slave. The master can then poll those slaves more frequently which have users at the slave and hence read the full access code with the frequent polls.>> 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.The wire network must be huge, if you are forced to use 300 bits/s:-) If you can use 9600 bits/s i.e. 1 ms character time and a 2 byte poll and 1 byte Ack/Nak that takes 3 ms plus some additional time for Rx/Tx and Tx/Rx delays. I would expect a 5 ms transaction time and 150 ms poll cycle,>> 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.It sounds that you are trying to reinvent the CAN bus protocol ? You can even use RS-485 transceivers chips (Data out to Transmit enable, Tx input to fixed "0"). You need a CAN control chip, e.g. SJA1000 for the master and some simpler for slaves. There are several uCs with built in CAN controllers usable as slaves. With CAN, there are some snags. The maximum net payload is 64 _bits_ (8 bytes) so if more data needs to be transmitted, you may have to use some higher level protocols above CAN. The other snag is that all stations must hear each other well within a single _bit_ time to handle conflicts. This limits the length of the bus and/or maximum bit rate that can be used e.g. 250 kbit/s with 250 m bus cable. At lower speeds the range can be extended.
Reply by ●March 28, 20212021-03-28
On 3/28/21 12:32 AM, upsidedown@downunder.com wrote:> On Sat, 27 Mar 2021 20:14:54 -0400, Richard Damon > >> 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. > > It sounds that you are trying to reinvent the CAN bus protocol ? > > You can even use RS-485 transceivers chips (Data out to Transmit > enable, Tx input to fixed "0"). You need a CAN control chip, e.g. > SJA1000 for the master and some simpler for slaves. There are several > uCs with built in CAN controllers usable as slaves. > > With CAN, there are some snags. The maximum net payload is 64 _bits_ > (8 bytes) so if more data needs to be transmitted, you may have to use > some higher level protocols above CAN. The other snag is that all > stations must hear each other well within a single _bit_ time to > handle conflicts. This limits the length of the bus and/or maximum bit > rate that can be used e.g. 250 kbit/s with 250 m bus cable. At lower > speeds the range can be extended. >That methodology is used in CAN, it is also used in I2C, and I suspect other systems. It is close to the method used for ethernet on coax (but that uses a slightly different method because the line might be longer than allowing collision detection in a single bit.
Reply by ●March 28, 20212021-03-28
On Sun, 28 Mar 2021 07:20:43 -0400, Richard Damon <Richard@Damon-Family.org> wrote:>On 3/28/21 12:32 AM, upsidedown@downunder.com wrote: >> On Sat, 27 Mar 2021 20:14:54 -0400, Richard Damon >> >>> 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. >> >> It sounds that you are trying to reinvent the CAN bus protocol ? >> >> You can even use RS-485 transceivers chips (Data out to Transmit >> enable, Tx input to fixed "0"). You need a CAN control chip, e.g. >> SJA1000 for the master and some simpler for slaves. There are several >> uCs with built in CAN controllers usable as slaves. >> >> With CAN, there are some snags. The maximum net payload is 64 _bits_ >> (8 bytes) so if more data needs to be transmitted, you may have to use >> some higher level protocols above CAN. The other snag is that all >> stations must hear each other well within a single _bit_ time to >> handle conflicts. This limits the length of the bus and/or maximum bit >> rate that can be used e.g. 250 kbit/s with 250 m bus cable. At lower >> speeds the range can be extended. >> > >That methodology is used in CAN, it is also used in I2C, and I suspect >other systems. It is close to the method used for ethernet on coax (but >that uses a slightly different method because the line might be longer >than allowing collision detection in a single bit.The difference is that in coaxial Ethernet CSMA/CD collisions _both_ messages are lost and _both_ needs to be retransmitted at a later time. In CAN bus, the higher priority message gets through despite a collision, only the lower priority message needs to be retransmitted. For this reason a much higher bus loading are possible in CAN, while in Ethernet high collision rates will kill the traffic completely much earlier. The dominant/recessivebit protocol used in CAN may also be used with other transports than RS-485 or dedicated CANbus transceivers. One could even use with 20 mA current loop by putting all stations into the sane current loop, but the optoisolator photo transistor Vce(max) may limit the number of stations in the same loop to about a dozen.
Reply by ●March 28, 20212021-03-28
On 3/28/21 7:59 AM, upsidedown@downunder.com wrote:> On Sun, 28 Mar 2021 07:20:43 -0400, Richard Damon > <Richard@Damon-Family.org> wrote: > >> On 3/28/21 12:32 AM, upsidedown@downunder.com wrote: >>> On Sat, 27 Mar 2021 20:14:54 -0400, Richard Damon >>> >>>> 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. >>> >>> It sounds that you are trying to reinvent the CAN bus protocol ? >>> >>> You can even use RS-485 transceivers chips (Data out to Transmit >>> enable, Tx input to fixed "0"). You need a CAN control chip, e.g. >>> SJA1000 for the master and some simpler for slaves. There are several >>> uCs with built in CAN controllers usable as slaves. >>> >>> With CAN, there are some snags. The maximum net payload is 64 _bits_ >>> (8 bytes) so if more data needs to be transmitted, you may have to use >>> some higher level protocols above CAN. The other snag is that all >>> stations must hear each other well within a single _bit_ time to >>> handle conflicts. This limits the length of the bus and/or maximum bit >>> rate that can be used e.g. 250 kbit/s with 250 m bus cable. At lower >>> speeds the range can be extended. >>> >> >> That methodology is used in CAN, it is also used in I2C, and I suspect >> other systems. It is close to the method used for ethernet on coax (but >> that uses a slightly different method because the line might be longer >> than allowing collision detection in a single bit. > > The difference is that in coaxial Ethernet CSMA/CD collisions _both_ > messages are lost and _both_ needs to be retransmitted at a later > time. In CAN bus, the higher priority message gets through despite a > collision, only the lower priority message needs to be retransmitted. > For this reason a much higher bus loading are possible in CAN, while > in Ethernet high collision rates will kill the traffic completely much > earlier. > > The dominant/recessivebit protocol used in CAN may also be used with > other transports than RS-485 or dedicated CANbus transceivers. One > could even use with 20 mA current loop by putting all stations into > the sane current loop, but the optoisolator photo transistor Vce(max) > may limit the number of stations in the same loop to about a dozen. > >Yes, the Ethernet protocal loses the whole message because the bit time isn't large comparared to the propagation delay across the system, so you might not know of the collision until it is too late to get off. CAN/I2C require a bit time longer than network propagation, so the transmitter knows after the first collision that it has lost, and the master that was sending the dominant bit gets control. As you say, you can use dominant/recessive bit physical layer with many protocals, even pure asynchronous serial (though that may need a bit of external logic to get you off the bus before you corrupt the message, like the 485 with data on the enable.
Reply by ●March 28, 20212021-03-28
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.
Reply by ●March 28, 20212021-03-28
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.
Reply by ●March 30, 20212021-03-30
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. 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. 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.
