Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30390
| Subject | Re: Multi-master RS485 |
|---|---|
| Newsgroups | comp.arch.embedded |
| References | <s3idlk$dm7$1@dont-email.me> <s3l03h$gob$1@z-news.wcss.wroc.pl> <s3ofjd$4tv$1@dont-email.me> <2UP7I.42523$RS3.2262@fx18.iad> <8kvv5gh272bm5jthkpt8p8hnfa7fdj0s77@4ax.com> |
| From | Richard Damon <Richard@Damon-Family.org> |
| Message-ID | <eEZ7I.58356$QT3.46106@fx33.iad> (permalink) |
| Organization | Forte - www.forteinc.com |
| Date | 2021-03-28 07:20 -0400 |
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.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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