Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #31329
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Shared Communications Bus - RS-422 or RS-485 |
| Date | 2022-11-04 08:45 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <tk2fuo$1nau3$1@dont-email.me> (permalink) |
| References | (3 earlier) <tjul46$18dkn$3@dont-email.me> <ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com> <tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me> <tk0mih$1g2fh$1@dont-email.me> |
Il 03/11/2022 16:26, David Brown ha scritto: > On 03/11/2022 14:00, pozz wrote: >> Il 03/11/2022 12:42, David Brown ha scritto: >>> On 03/11/2022 00:27, Rick C wrote: >>>> On Wednesday, November 2, 2022 at 4:49:16 PM UTC-4, David Brown wrote: >>>>> On 02/11/2022 20:20, Rick C wrote: >>>>>> On Wednesday, November 2, 2022 at 5:28:21 AM UTC-4, David Brown >>>>>> wrote: >>>>>>> On 02/11/2022 06:28, Rick C wrote: >> >> >>> You are correct that reception is in the middle of the stop bit >>> (typically sub-slot 9 of 16). The first transmitter will be disabled >>> at the end of the stop bit, and the next transmitter must not enable >>> its driver until after that point - it must wait at least half a bit >>> time after reception before starting transmission. (It can wait >>> longer without trouble, which is why faster baud rates are less >>> likely to involve any complications here.) >> >> Do you mean that RX interrupt triggers in the middle of the stop bit >> and not at the end? Interesting, but are you sure this is the case for >> every UART implemented in MCUs? > > Of course I'm not sure - there are a /lot/ of MCU manufacturers! > > UART receivers usually work in the same way, however. They have a > sample clock running at 16 times the baud clock. The start bit is edge > triggered to give the start of the character frame. Then each bit is > sampled in the middle of its time slot - usually at subbit slots 7, 8, > and 9 with majority voting. So the stop bit is recognized by subbit > slot 9 of the tenth bit (assuming 8-bit, no parity) - the voltage on the > line after that is irrelevant. (Even when you have two stop bits, > receivers never check the second stop bit - it affects transmit timing > only.) What purpose would there be in waiting another 7 subbits before > triggering the interrupt, DMA, or whatever? There's no real purpose, but it's important to know exactly when the RX interrupt is fired from the UART. Usually the next transmitter starts transmitting after receiving the last byte of the previous transmitter (for example, the slave starts replying to the master after receiving the complete message from it). Now I think of the issue related to a transmitter that delays a little to turn around the direction of its transceiver, from TX to RX. Every transmitter on the bus should take into account this delay and avoid starting transmission too soon. So I usually implement a short delay before starting a new message transmission. If the maximum expected delay of moving the direction from TX to RX is 10us, I could think to use a 10us delay, but this is wrong in your assumption. If the RX interrupt is at the middle of the stop bit, I should delay the new transmission of 10us + half of bit time. With 9600 this is 52us that is much higher than 10us. I know the next transmitter should make some processing of the previous received message, prepare and buffer the new message to transmit, so the delay is somewhat automatic, but in many cases I have small 8-bits PICs and full-futured Linux box on the same bus and the Linux could be very fast to start the new transmission. >> I wouldn't be surprised if the implementation was different for >> different manufacturers. >> > > I've seen a bit of variation, including 8 subbit clocks per baud clock, > wider sampling ranges, re-sync of the clock on edges, etc. And of > course you don't always get the details of the timings in datasheets > (and who bothers measuring them?) But the key principles are the same. > >> >>>> None of this matters to me really. I'm going to use more wires, and >>>> do the multi-drop from the PC to the slaves on one pair and use >>>> RS-422 to multi-point from the slaves to the PC. Since the slaves >>>> are controlled by the master, they will never collide. The master >>>> can't collide with itself, so I can ignore any issues with this. I >>>> will use the bias resistors to assure a valid idle state. I may >>>> need to select different devices than the ones I use in the >>>> product. I think there are differences in the input load and I want >>>> to be sure I can chain up to 32 units. >>>> >>> >>> OK. I have no idea what such a hybrid bus should technically be >>> called, but I think it should work absolutely fine for the purpose >>> and seems like a solid solution. I would not foresee any issues with >>> 32 nodes on such a bus, especially if it is relatively short and you >>> have terminators at each end. >> >> In my experience, termination resistors at each end of the line could >> introduce other troubles if they aren't strictly required (because of >> signal integrity on long lines at high baud rates). >> > > RS-485 requires them - you want to hold the bus at a stable idle state > when nothing is driving it. But this is the goal of *bias* resistors, not termination resistors. > You also want to have a bit of load so that > you have some current on the bus, and thereby greater noise immunity. Of course, but termination resistors are usually small (around 100 ohms) because they should match the impedance of the cable. If you want only to introduce "some current" on the bus, you could use resistors in the order of 1k, but this isn't strictly a *termination* resistor. >> The receiver input impedance of all the nodes on the bus are in >> parallel with the two terminators. If you have many nodes, the >> equivalent impedance on the bus is much small and the partition with >> bias resistors could reduce the differential voltage between A and B >> at idle to less than 200mV. >> >> If you don't use true fail-safe transceivers, a fault start bit could >> be seen by these kind of receivers. >> > > Receiver load is very small on modern RS-485 drivers. ST3485 says the input load of the receiver around 24k. When you connect 32 slaves, the equivalent resistor would be 750 ohms, that should be enough to have "some current" on the bus. If you add *termination* resistors in the order of 100R on both sides, you could reduce drastically the differential voltage between A and B at idle state.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-01 22:28 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-02 10:28 +0100
Re: Shared Communications Bus - RS-422 or RS-485 pozz <pozzugno@gmail.com> - 2022-11-02 11:54 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-02 14:27 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-02 12:20 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-02 21:49 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-02 16:27 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-03 12:42 +0100
Re: Shared Communications Bus - RS-422 or RS-485 pozz <pozzugno@gmail.com> - 2022-11-03 14:00 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-03 16:26 +0100
Re: Shared Communications Bus - RS-422 or RS-485 pozz <pozzugno@gmail.com> - 2022-11-04 08:45 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-04 10:49 +0100
Re: Shared Communications Bus - RS-422 or RS-485 pozz <pozzugno@gmail.com> - 2022-11-04 15:37 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-04 17:36 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-04 10:11 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-05 11:58 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-05 09:55 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 11:00 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-07 15:46 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 08:05 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-07 19:02 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 17:15 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-08 06:54 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-08 05:50 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Clifford Heath <no_spam@please.net> - 2022-11-09 10:45 +1100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-08 16:46 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Clifford Heath <no_spam@please.net> - 2022-11-09 22:32 +1100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-09 04:53 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-09 23:45 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-09 21:42 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-04 08:40 -0700
Re: Shared Communications Bus - RS-422 or RS-485 antispam@math.uni.wroc.pl - 2022-11-04 22:53 +0000
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-04 18:07 -0700
Re: Shared Communications Bus - RS-422 or RS-485 antispam@math.uni.wroc.pl - 2022-11-05 03:46 +0000
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-05 02:09 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 10:40 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-05 12:47 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-05 10:23 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-05 19:57 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-05 13:42 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-06 11:55 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-06 05:56 -0800
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-06 21:53 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 01:58 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 11:26 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 02:39 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 12:07 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 08:25 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 17:57 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 09:50 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 21:30 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 14:27 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-08 00:07 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 16:50 -0800
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-08 09:02 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-08 06:58 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-06 18:34 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-06 15:37 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-06 19:18 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 02:07 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 02:03 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 11:55 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 08:18 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 18:20 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 10:26 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 22:04 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 14:54 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-07 15:14 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 16:57 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 07:51 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 08:29 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-03 10:36 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 12:32 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-03 13:08 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 13:40 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-03 16:50 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 21:10 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-04 11:13 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-04 08:52 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-04 20:03 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-05 17:25 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-04 11:01 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-02 15:00 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-02 16:31 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-02 17:36 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-02 21:58 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-03 09:57 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 12:02 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-03 12:53 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 13:33 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Dave Nadler <drn@nadler.com> - 2022-11-03 15:37 -0400
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 13:32 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-04 22:47 -0400
Re: Shared Communications Bus - RS-422 or RS-485 chris <chris-nospam@tridac.net> - 2022-11-05 00:13 +0000
csiph-web