Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #31345
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Shared Communications Bus - RS-422 or RS-485 |
| Date | 2022-11-05 11:58 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <tk5fkb$2dl2i$2@dont-email.me> (permalink) |
| References | (8 earlier) <tk2fuo$1nau3$1@dont-email.me> <tk2n7g$1o0ct$1@dont-email.me> <tk3839$1nau3$2@dont-email.me> <tk3f2t$1t3hc$1@dont-email.me> <3d9e5c38-93be-4504-b891-e0087053ebc7n@googlegroups.com> |
On 04/11/2022 18:11, Rick C wrote: > On Friday, November 4, 2022 at 12:36:51 PM UTC-4, David Brown wrote: >> On 04/11/2022 15:37, pozz wrote: >>> Il 04/11/2022 10:49, David Brown ha scritto: >>>> On 04/11/2022 08:45, pozz wrote: >>>>> 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. >>>>> >>>> >>>> I think it is extremely rare that this is important. I can't think of >>>> a single occasion when I have thought it remotely relevant where in >>>> the stop bit the interrupt comes. >>>> >>>>> 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). >>>>> >>>> >>>> No. Usually the next transmitter starts after receiving the last >>>> byte, and /then a pause/. There will always be some handling time in >>>> software, and may also include an explicit pause. Almost always you >>>> will want to do at least a minimum of checking of the incoming data >>>> before deciding on the next telegram to be sent out. But if you have >>>> very fast handling in relation to the baud rate, you will want an >>>> explicit pause too - protocols regularly specify a minimum pause (such >>>> as 3.5 character times for Modbus RTU), and you definitely want it to >>>> be at least one full character time to ensure no listener gets >>>> hopelessly out of sync. >>> >>> In theory, if all the nodes on the bus were able to change direction in >>> hardware (exactly at the end of the stop bit), you will not be forced to >>> introduce any delay in the transmission. >> Communication is about /reliably/ transferring data between devices. >> Asynchronous serial communication is about doing that despite slight >> differences in clock rates, differences in synchronisation, differences >> in startup times, etc. If you don't have idle pauses, you have almost >> zero chance of staying in sync across the nodes - and no chance at all >> of recovery when that happens. /Every/ successful serial protocol has >> pauses between frames - long enough pauses that the idle time could not >> possibly be part of a normal full speed frame. That does not just apply >> to UART protocols, or even just to asynchronous protocols. The pause >> does not have to be as long as 3.5 characters, but you need a pause - >> just as you need other error recovery handling. > > The "idle" pauses you talk about are accommodated with the start and stop bits in the async protocol. Every character is sent with a start bit which starts the timing. The stop bit is the "fluff" time for the next character to align to the next start bit. There is no need for the bus to be idle in the sense of no data being sent. If an RS-485 or RS-422 bus is biased for undriven times, there is no need for the driver to be on through the full stop bit. Once the stop bit has driven high, it can be disabled, such as in the middle of the bit. The there is a half bit time for timing skew, which amounts to 5%, between any two devices on the bus. > There are two levels of framing here, and two types of pauses. For UART communication, there is the "character frame" and the stop bit acts as a pause between characters. This is to give a minimum time to allow re-synchronisation of the clock timing at the receiver. It also forms, along with the start bit, a guaranteed edge for this re-synchronisation. More sophisticated serial protocols (CAN, Ethernet, etc.) do not need this because they have other methods of guaranteeing transitions and allowing the receiver to re-synchronise regularly - thus they do not need framing or idling at the character or byte level. But you always want framing and idling between message frames at a higher level. You always have an idle period that is longer than any valid character or part of a message. For example, in CAN communication you have "bit stuffing" any time you have 5 equal value bits in a row. This ensures that in the message, you never have more than 5 bits without a transition, and you don't need a fixed start or stop bit per byte in order to keep the receiver synchronised. But at the end of the CAN frame there is at least 10 bits of recessive (1) value. Any receiver that has got out of synchronisation, due to noise, startup timing, etc., will know it cannot possibly be in the middle of a frame and restart its receiver. In UART communication, this is handled at the protocol level rather than the hardware (though some UART hardware may have "idle detect" signals when more than 11 bits of high level are seen in a row). Some UART-based protocols also use a "break" signal between frames - that is a string of at least 11 bits of low level. If you do not have such pauses, and a receiver is out of step, it has no way to get into synchronisation again. Maybe you get lucky, but basically all it is seeing is a stream of high and low bits with no absolute indicator of position - and no way to tell what might be the start bit of a new character (rather than a 1 bit then a 0 bit within a character), never mind the start of a message. Usually you get enough pauses naturally in the communication, with delays between reception and reply. But if you don't have them, you must add them. Otherwise your communication will be too fragile to use in practice. You /need/ idle gaps to be able to resynchronise reliably in the face of errors (and there is /always/ a risk of errors). > >>> Many times I'm the author of a custom protocol because some nodes on a >>> shared bus, so I'm not forced to follow any specifications. When I >>> didn't introduce any delay in the transmission, I sometimes faced this >>> issue. In my experience, the bus is heterogeneous enough to have a fast >>> replying slave to a slow master. >>> >>> >>>>> 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. >>>> >>>> They should, yes. The turnaround delay should be negligible in this >>>> day and age - if not, your software design is screwed or you have >>>> picked the wrong hardware. (Of course, you don't always get the >>>> choice of hardware you want, and programmers are often left to find >>>> ways around hardware design flaws.) >>> >>> Negligible doesn't mean anything. >> Negligible means of no significance in comparison to the delays you have >> anyway - either intentional delays in order to separate telegrams and >> have a reliable communication, or unavoidable delays due to software >> processing. > > The software on the PC is not managing the bus drivers. So software delays are not relevant to bus control timing. > > >>> If thre's a poor 8 bit PIC (previous >>> transmitter) clocked at 8MHz that changes direction in TXC interrupt >>> while other interrupts are active, and there's a Cortex-M4 clocked at >>> 200MHz (next transmitter), you will encounter this issue. >>> >> No, you won't - not unless you are doing something silly in your timing >> such as failing to use appropriate pauses or thinking that 10 µs >> turnarounds are a good idea at 9600 baud. And I did specify picking >> sensible hardware - 8-bit PICs were are terrible choice 20 years ago for >> anything involving high speed, and they have not improved. (Again - >> sometimes you don't have control of the hardware, and sometimes there >> can be other overriding reasons for picking something. But if your >> hardware is limited, you have to take that into account.) >>> This is more evident if, as you are saying, the Cortex-M4 is able to >>> start processing the message from the PIC at the midpoint of last stop >>> bit, while the PIC disables its driver at the *end* of the stop bit plus >>> an additional delay caused by interrupts handling. >>> >>> In this cases the half bit time is not negligible and must be added to >>> the transmission delay. >>> >> Sorry, but I cannot see any situation where that would happen in a >> well-designed communication system. >> >> Oh, and it is actually essential that the receiver considers the >> character finished half-way through the stop bit, and not at the end. >> UART communication is intended to work despite small differences in the >> baud rate - up to nearly 5% total error. By the time the receiver is >> half way through the received stop bit, and has identified it is valid, >> the sender could be finished the stop bit as its clock is almost 5% >> faster (50% bit time over the full 10 bits). The receiver has to be in >> the "watch for falling edge of start bit" state at this point, ready for >> the transmitter to start its next frame. > > Yes, why would it not be? This is why there's no need for additional delays or "gaps" in the protocol for an async interface. > It will be in the right state at the right time, as long as it enters it when the stop bit is identified (half-way through the stop bit) rather than artificially waiting for the end of the bit time. You need gaps in the character stream at a higher level, for error recovery.
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