Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #31284 > unrolled thread
| Started by | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| First post | 2022-11-01 22:28 -0700 |
| Last post | 2022-11-05 00:13 +0000 |
| Articles | 20 on this page of 94 — 10 participants |
Back to article view | Back to comp.arch.embedded
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
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-07 19:02 -0500 |
| Message-ID | <90haL.30702$BRy2.3284@fx48.iad> |
| In reply to | #31370 |
On 11/7/22 11:05 AM, Rick C wrote: > On Monday, November 7, 2022 at 6:00:09 AM UTC-4, Stef wrote: >> On 2022-11-05 Rick C wrote in comp.arch.embedded: >>> On Saturday, November 5, 2022 at 6:58:24 AM UTC-4, David Brown wrote: >>> >>>> 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, >>> >>> You have failed to explain how a receiver would get "out of step". The receiver syncs to every character transmitted. If all characters are received, what else do you need? How does it get "out of step"? >> I have seen this happen in long messages (few kB) with no pauses between >> characters and transmitter and receiver set to 8,N,1. It seemed that the >> receiver needed the complete stop bit and then immediately saw the low >> of the next start bit. Detecting the edge when it was ready to see it, >> not when it actually happened. When the receiver is slightly slower than >> the transmitter, this caused the detection of the start bit (and >> therefor the whole character) to shift a tiny bit. This added up over >> the character stream until it eventually failed. >> >> Lowering the baud rate did not solve the issue, but inserting pauses >> after a number of chars did. What also solved it was setting the >> transmitter to 2 stop bits and the receiver to one stop bit. This was a >> one way stream and this may not be possible on a bi-directional stream. >> >> I would expect a sensible UART implementation to allow for a slightly >> shorter stop bit to compensate for issues like this. But apparently this >> UART did not do so in the 1 stop bit setting. I have not tested if >> setting both ends to 2 stop bits also solved the problem. > > If a UART receiver can not properly receive a message like this, it is defective. The point of the start and stop bits are to provide the synchronization. The receiver simply needs to detect the stop be state (by sampling where the receiver thinks is the middle of the bit) and then immediately start looking for the leading edge of the next start bit. The receiver will then be synchronized to the new character bit timing and it will never slip. That gives up to ±5% combined timing error tolerance. > > If the receiver waits until a later time, such as the expected end of the received stop bit, to start looking for a start bit leading edge, it will not be able to tolerate a timing error where the transmitter is faster than the receiver making the timing tolerance unipolar, i.e. 5% rather than ±5%. > > That's a receiver design flaw, or the transmitter is sending short stop bits, which you can easily see on the scope with a delayed trigger control. > > You should be able to diagnose which end has the problem by connecting a different type of receiver to the stream. If a different receiver UART is able to receive the messages without fault, the problem is obviously the failing receiver. > YOU may consider it a design flaw, but I have seen too many serial ports having this flaw in them to just totally ignore it. Yes, the "robust" design will allow for a short stop bit, but you can't count on all serial adaptors allowing for it. Part of the problem is that (at least as far as I know) the Asynchronous Serial Format isn't actually a "Published Standard", but just an de-facto protocol that is simple enough that it mostly just works, but still hides a few gotchas for corner cases.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-07 17:15 -0800 |
| Message-ID | <90ec4146-b6c8-4b2c-9642-9f838dd82201n@googlegroups.com> |
| In reply to | #31383 |
On Monday, November 7, 2022 at 8:02:19 PM UTC-4, Richard Damon wrote: > On 11/7/22 11:05 AM, Rick C wrote: > > On Monday, November 7, 2022 at 6:00:09 AM UTC-4, Stef wrote: > >> On 2022-11-05 Rick C wrote in comp.arch.embedded: > >>> On Saturday, November 5, 2022 at 6:58:24 AM UTC-4, David Brown wrote: > >>> > >>>> 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, > >>> > >>> You have failed to explain how a receiver would get "out of step". The receiver syncs to every character transmitted. If all characters are received, what else do you need? How does it get "out of step"? > >> I have seen this happen in long messages (few kB) with no pauses between > >> characters and transmitter and receiver set to 8,N,1. It seemed that the > >> receiver needed the complete stop bit and then immediately saw the low > >> of the next start bit. Detecting the edge when it was ready to see it, > >> not when it actually happened. When the receiver is slightly slower than > >> the transmitter, this caused the detection of the start bit (and > >> therefor the whole character) to shift a tiny bit. This added up over > >> the character stream until it eventually failed. > >> > >> Lowering the baud rate did not solve the issue, but inserting pauses > >> after a number of chars did. What also solved it was setting the > >> transmitter to 2 stop bits and the receiver to one stop bit. This was a > >> one way stream and this may not be possible on a bi-directional stream. > >> > >> I would expect a sensible UART implementation to allow for a slightly > >> shorter stop bit to compensate for issues like this. But apparently this > >> UART did not do so in the 1 stop bit setting. I have not tested if > >> setting both ends to 2 stop bits also solved the problem. > > > > If a UART receiver can not properly receive a message like this, it is defective. The point of the start and stop bits are to provide the synchronization. The receiver simply needs to detect the stop be state (by sampling where the receiver thinks is the middle of the bit) and then immediately start looking for the leading edge of the next start bit. The receiver will then be synchronized to the new character bit timing and it will never slip. That gives up to ±5% combined timing error tolerance. > > > > If the receiver waits until a later time, such as the expected end of the received stop bit, to start looking for a start bit leading edge, it will not be able to tolerate a timing error where the transmitter is faster than the receiver making the timing tolerance unipolar, i.e. 5% rather than ±5%. > > > > That's a receiver design flaw, or the transmitter is sending short stop bits, which you can easily see on the scope with a delayed trigger control. > > > > You should be able to diagnose which end has the problem by connecting a different type of receiver to the stream. If a different receiver UART is able to receive the messages without fault, the problem is obviously the failing receiver. > > > YOU may consider it a design flaw, but I have seen too many serial ports > having this flaw in them to just totally ignore it. That is exceedingly hard to imagine, since it would take extra logic to implement. The logic of a UART is to first, detect the start bit which lands the state machine in the middle of said start bit which then times to the middle of all subsequent bits (ignoring timing accuracy). So it thinks it is in the middle of the stop bit when the bit timing is complete. It would need to have more hardware to time to the end of the stop bit. This might be present, for other purposes, but it should not be used to control looking for the start bit. This is by definition of the async protocol, to use the stop bit time to resync to the next start bit. Any device that does not start looking for a new start bit at the point it thinks is the middle of the stop bit, is defective by definition and will never work properly with timing mismatches of one polarity, the receiver's clock being slower than the transmitter clock. I guess I'm not certain that would cause an error, actually. It would initiate the start bit detection logic, and as long as it does not require seeing the idle condition before detecting the start bit condition, it would still work. Again, this is expected by the definition of asynchronous format. This would result in a grosser offset in timing the middle of the bits, so the allowable timing error is less. But it will still work otherwise. 5% is a very large combined error. Most devices are timed by crystals with maybe ±200 ppm error. > Yes, the "robust" design will allow for a short stop bit, but you can't > count on all serial adaptors allowing for it. There's always garbage designs. I'm surprised I never ran into one. I guess being crystal controlled, there was never enough error to add up to a bit. > Part of the problem is that (at least as far as I know) the Asynchronous > Serial Format isn't actually a "Published Standard", but just an > de-facto protocol that is simple enough that it mostly just works, but > still hides a few gotchas for corner cases. True, but anyone designing chips should understand what they are designing. If they don't, you get garbage. I learned that lesson in a class in school where I screwed up a detail on a program I wrote, because I didn't understand the spec. I've always tried to ask questions since and even if they seem like stupid questions, I don't read the specs wrong. -- Rick C. --+-- Get 1,000 miles of free Supercharging --+-- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-08 06:54 -0500 |
| Message-ID | <hsraL.2594$Z3L9.1128@fx41.iad> |
| In reply to | #31386 |
On 11/7/22 8:15 PM, Rick C wrote: > On Monday, November 7, 2022 at 8:02:19 PM UTC-4, Richard Damon wrote: >> On 11/7/22 11:05 AM, Rick C wrote: >>> On Monday, November 7, 2022 at 6:00:09 AM UTC-4, Stef wrote: >>>> On 2022-11-05 Rick C wrote in comp.arch.embedded: >>>>> On Saturday, November 5, 2022 at 6:58:24 AM UTC-4, David Brown wrote: >>>>> >>>>>> 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, >>>>> >>>>> You have failed to explain how a receiver would get "out of step". The receiver syncs to every character transmitted. If all characters are received, what else do you need? How does it get "out of step"? >>>> I have seen this happen in long messages (few kB) with no pauses between >>>> characters and transmitter and receiver set to 8,N,1. It seemed that the >>>> receiver needed the complete stop bit and then immediately saw the low >>>> of the next start bit. Detecting the edge when it was ready to see it, >>>> not when it actually happened. When the receiver is slightly slower than >>>> the transmitter, this caused the detection of the start bit (and >>>> therefor the whole character) to shift a tiny bit. This added up over >>>> the character stream until it eventually failed. >>>> >>>> Lowering the baud rate did not solve the issue, but inserting pauses >>>> after a number of chars did. What also solved it was setting the >>>> transmitter to 2 stop bits and the receiver to one stop bit. This was a >>>> one way stream and this may not be possible on a bi-directional stream. >>>> >>>> I would expect a sensible UART implementation to allow for a slightly >>>> shorter stop bit to compensate for issues like this. But apparently this >>>> UART did not do so in the 1 stop bit setting. I have not tested if >>>> setting both ends to 2 stop bits also solved the problem. >>> >>> If a UART receiver can not properly receive a message like this, it is defective. The point of the start and stop bits are to provide the synchronization. The receiver simply needs to detect the stop be state (by sampling where the receiver thinks is the middle of the bit) and then immediately start looking for the leading edge of the next start bit. The receiver will then be synchronized to the new character bit timing and it will never slip. That gives up to ±5% combined timing error tolerance. >>> >>> If the receiver waits until a later time, such as the expected end of the received stop bit, to start looking for a start bit leading edge, it will not be able to tolerate a timing error where the transmitter is faster than the receiver making the timing tolerance unipolar, i.e. 5% rather than ±5%. >>> >>> That's a receiver design flaw, or the transmitter is sending short stop bits, which you can easily see on the scope with a delayed trigger control. >>> >>> You should be able to diagnose which end has the problem by connecting a different type of receiver to the stream. If a different receiver UART is able to receive the messages without fault, the problem is obviously the failing receiver. >>> >> YOU may consider it a design flaw, but I have seen too many serial ports >> having this flaw in them to just totally ignore it. > > That is exceedingly hard to imagine, since it would take extra logic to implement. The logic of a UART is to first, detect the start bit which lands the state machine in the middle of said start bit which then times to the middle of all subsequent bits (ignoring timing accuracy). So it thinks it is in the middle of the stop bit when the bit timing is complete. It would need to have more hardware to time to the end of the stop bit. This might be present, for other purposes, but it should not be used to control looking for the start bit. This is by definition of the async protocol, to use the stop bit time to resync to the next start bit. Any device that does not start looking for a new start bit at the point it thinks is the middle of the stop bit, is defective by definition and will never work properly with timing mismatches of one polarity, the receiver's clock being slower than the transmitter clock. Depends on how you design it. IF you start a counter at the leading edge of the start bit and then detect the counter at its middle value, then the stop bit ends when the counter finally expires at the END of the stop bit. > > I guess I'm not certain that would cause an error, actually. It would initiate the start bit detection logic, and as long as it does not require seeing the idle condition before detecting the start bit condition, it would still work. Again, this is expected by the definition of asynchronous format. This would result in a grosser offset in timing the middle of the bits, so the allowable timing error is less. But it will still work otherwise. 5% is a very large combined error. Most devices are timed by crystals with maybe ±200 ppm error. IF you don't start the looking for the start bit until the time has passed for the END of the stop bit, and the receiver is 0.1% slow, then every bit you lose 0.1% of a bit, or 1% per character, so after 50 consecutive characters you are 1/2 a bit late, and getting errors. > > >> Yes, the "robust" design will allow for a short stop bit, but you can't >> count on all serial adaptors allowing for it. > > There's always garbage designs. I'm surprised I never ran into one. I guess being crystal controlled, there was never enough error to add up to a bit. As I pointed out, 0.1% means 50 characters. 0.001% means 5000 characters, long enough string of characters and eventually you hit the problem. If you only use short messages, you never have a problem. > > >> Part of the problem is that (at least as far as I know) the Asynchronous >> Serial Format isn't actually a "Published Standard", but just an >> de-facto protocol that is simple enough that it mostly just works, but >> still hides a few gotchas for corner cases. > > True, but anyone designing chips should understand what they are designing. If they don't, you get garbage. I learned that lesson in a class in school where I screwed up a detail on a program I wrote, because I didn't understand the spec. I've always tried to ask questions since and even if they seem like stupid questions, I don't read the specs wrong. > The problem is that if you describe the sampling as "Middle of bit", then going to the end of the stop bit makes sense. If you are adding functionality like RS-485 control that needs to know when that end of bit is, and it is easy to forget that the receiver has different needs than the transmitter.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-08 05:50 -0800 |
| Message-ID | <e43c39f0-7193-4728-b19e-1232216b30a2n@googlegroups.com> |
| In reply to | #31388 |
On Tuesday, November 8, 2022 at 7:54:59 AM UTC-4, Richard Damon wrote: > On 11/7/22 8:15 PM, Rick C wrote: > > On Monday, November 7, 2022 at 8:02:19 PM UTC-4, Richard Damon wrote: > >> YOU may consider it a design flaw, but I have seen too many serial ports > >> having this flaw in them to just totally ignore it. > > > > That is exceedingly hard to imagine, since it would take extra logic to implement. The logic of a UART is to first, detect the start bit which lands the state machine in the middle of said start bit which then times to the middle of all subsequent bits (ignoring timing accuracy). So it thinks it is in the middle of the stop bit when the bit timing is complete. It would need to have more hardware to time to the end of the stop bit. This might be present, for other purposes, but it should not be used to control looking for the start bit. This is by definition of the async protocol, to use the stop bit time to resync to the next start bit. Any device that does not start looking for a new start bit at the point it thinks is the middle of the stop bit, is defective by definition and will never work properly with timing mismatches of one polarity, the receiver's clock being slower than the transmitter clock. > Depends on how you design it. IF you start a counter at the leading edge > of the start bit and then detect the counter at its middle value, then > the stop bit ends when the counter finally expires at the END of the > stop bit. There is still some extra logic to distinguish the condition. There is a bit timing counter, and a counter to track which bit you are in. Everything happening in the operation of the UART is happening at the middle of a bit. Then you need extra logic to distinguish the end of a bit. > > I guess I'm not certain that would cause an error, actually. It would initiate the start bit detection logic, and as long as it does not require seeing the idle condition before detecting the start bit condition, it would still work. Again, this is expected by the definition of asynchronous format. This would result in a grosser offset in timing the middle of the bits, so the allowable timing error is less. But it will still work otherwise. 5% is a very large combined error. Most devices are timed by crystals with maybe ±200 ppm error. > IF you don't start the looking for the start bit until the time has > passed for the END of the stop bit, and the receiver is 0.1% slow, then > every bit you lose 0.1% of a bit, or 1% per character, so after 50 > consecutive characters you are 1/2 a bit late, and getting errors. There you go! You have just proven that no one would design a UART to work this way and for it to be used in the market place. There would be too many applications where the data burst would cause it to not work. Programming around such a design flaw would be such a PITA and expose the flaw, that the part would become a pariah. I recall the Intel USART was such a part for other technical flaws. So they finally came out with a new version that fixed the problems. > >> Yes, the "robust" design will allow for a short stop bit, but you can't > >> count on all serial adaptors allowing for it. > > > > There's always garbage designs. I'm surprised I never ran into one. I guess being crystal controlled, there was never enough error to add up to a bit. > As I pointed out, 0.1% means 50 characters. 0.001% means 5000 > characters, long enough string of characters and eventually you hit the > problem. > > If you only use short messages, you never have a problem. You mean if you have gaps with idle time. > >> Part of the problem is that (at least as far as I know) the Asynchronous > >> Serial Format isn't actually a "Published Standard", but just an > >> de-facto protocol that is simple enough that it mostly just works, but > >> still hides a few gotchas for corner cases. > > > > True, but anyone designing chips should understand what they are designing. If they don't, you get garbage. I learned that lesson in a class in school where I screwed up a detail on a program I wrote, because I didn't understand the spec. I've always tried to ask questions since and even if they seem like stupid questions, I don't read the specs wrong. > > > The problem is that if you describe the sampling as "Middle of bit", > then going to the end of the stop bit makes sense. Sorry, you are not clear. This doesn't make sense to me. What is "going to the end of the stop bit"? > If you are adding functionality like RS-485 control that needs to know > when that end of bit is, and it is easy to forget that the receiver has > different needs than the transmitter. ??? -- Rick C. --+-+ Get 1,000 miles of free Supercharging --+-+ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no_spam@please.net> |
|---|---|
| Date | 2022-11-09 10:45 +1100 |
| Message-ID | <1725c0b259b99fdc$1$72497$daa18cb5@news.thecubenet.com> |
| In reply to | #31390 |
On 9/11/22 00:50, Rick C wrote: > On Tuesday, November 8, 2022 at 7:54:59 AM UTC-4, Richard Damon wrote: >> IF you don't start the looking for the start bit until the time has >> passed for the END of the stop bit, and the receiver is 0.1% slow, then >> every bit you lose 0.1% of a bit, or 1% per character, so after 50 >> consecutive characters you are 1/2 a bit late, and getting errors. > > There you go! You have just proven that no one would design a UART to work this way and for it to be used in the market place. There would be too many applications where the data burst would cause it to not work. Programming around such a design flaw would be such a PITA and expose the flaw, that the part would become a pariah. Yeah, but you can still insist that the stop bit fills 99%, or 90% of the required time, and not get that pathology. This is a branch of the principle "be rigorous in what you produce, permissive in what you accept". I've personally moved away from that principle - I think being permissive too often just masks problems until they re-occur downstream but cannot be diagnosed there. So I'm much more willing to reject bad input (or to complain but still accept it) early on. CH
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-08 16:46 -0800 |
| Message-ID | <7bd645fd-923c-48f9-a6b5-a4dd46a35848n@googlegroups.com> |
| In reply to | #31393 |
On Tuesday, November 8, 2022 at 7:45:14 PM UTC-4, Clifford Heath wrote: > On 9/11/22 00:50, Rick C wrote: > > On Tuesday, November 8, 2022 at 7:54:59 AM UTC-4, Richard Damon wrote: > >> IF you don't start the looking for the start bit until the time has > >> passed for the END of the stop bit, and the receiver is 0.1% slow, then > >> every bit you lose 0.1% of a bit, or 1% per character, so after 50 > >> consecutive characters you are 1/2 a bit late, and getting errors. > > > > There you go! You have just proven that no one would design a UART to work this way and for it to be used in the market place. There would be too many applications where the data burst would cause it to not work. Programming around such a design flaw would be such a PITA and expose the flaw, that the part would become a pariah. > Yeah, but you can still insist that the stop bit fills 99%, or 90% of > the required time, and not get that pathology. I'm not clear on what you are saying. The larger the clock difference, the earlier the receiver has to look for the start bit. It will work just fine with the start bit check being delayed until the end of the stop bit, as long as the timing clocks aren't offset in one direction. Looking for the start bit in the middle of the stop bit gives a total of 5% tolerance, pretty much taking mistiming out of the list of problems for async data transmission. Drop that to 0.05% (your 99% example) and you are in the realm of crystal timing error on the two systems, ±250 ppm. -- Rick C. --++- Get 1,000 miles of free Supercharging --++- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no_spam@please.net> |
|---|---|
| Date | 2022-11-09 22:32 +1100 |
| Message-ID | <1725e749a6cb212c$10$3552867$5aa10cbd@news.thecubenet.com> |
| In reply to | #31394 |
On 9/11/22 11:46, Rick C wrote: > On Tuesday, November 8, 2022 at 7:45:14 PM UTC-4, Clifford Heath wrote: >> On 9/11/22 00:50, Rick C wrote: >>> On Tuesday, November 8, 2022 at 7:54:59 AM UTC-4, Richard Damon wrote: >>>> IF you don't start the looking for the start bit until the time has >>>> passed for the END of the stop bit, and the receiver is 0.1% slow, then >>>> every bit you lose 0.1% of a bit, or 1% per character, so after 50 >>>> consecutive characters you are 1/2 a bit late, and getting errors. >>> >>> There you go! You have just proven that no one would design a UART to work this way and for it to be used in the market place. There would be too many applications where the data burst would cause it to not work. Programming around such a design flaw would be such a PITA and expose the flaw, that the part would become a pariah. >> Yeah, but you can still insist that the stop bit fills 99%, or 90% of >> the required time, and not get that pathology. > > I'm not clear on what you are saying. The larger the clock difference, the earlier the receiver has to look for the start bit. It will work just fine with the start bit check being delayed until the end of the stop bit, as long as the timing clocks aren't offset in one direction. Looking for the start bit in the middle of the stop bit gives a total of 5% tolerance, pretty much taking mistiming out of the list of problems for async data transmission. Drop that to 0.05% (your 99% example) and you are in the realm of crystal timing error on the two systems, ±250 ppm. > Go back to the first words I quoted from Richard: " IF you don't start the looking for the start bit until the time has passed for the END of the stop bit, and the receiver is 0.1% slow, then every bit you lose 0.1% of a bit " But if you wait until 95% of the stop bit time, and allow a new start bit to come early by 5%, then it doesn't matter if "the receiver is 0.1% slow" and you don't lose sync; the 5% early doesn't mount up over "50 consecutive characters". Same if you wait 99% and the new start bit is only 1% early. So your "There you go! You have just proven..." was a bogus situation proposed by Richard, that's trivially avoided, and basically all actual UARTs will do that,
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-09 04:53 -0800 |
| Message-ID | <23c29311-2df5-4bcd-8993-3e3857b30c41n@googlegroups.com> |
| In reply to | #31396 |
On Wednesday, November 9, 2022 at 7:32:25 AM UTC-4, Clifford Heath wrote: > On 9/11/22 11:46, Rick C wrote: > > On Tuesday, November 8, 2022 at 7:45:14 PM UTC-4, Clifford Heath wrote: > >> On 9/11/22 00:50, Rick C wrote: > >>> On Tuesday, November 8, 2022 at 7:54:59 AM UTC-4, Richard Damon wrote: > >>>> IF you don't start the looking for the start bit until the time has > >>>> passed for the END of the stop bit, and the receiver is 0.1% slow, then > >>>> every bit you lose 0.1% of a bit, or 1% per character, so after 50 > >>>> consecutive characters you are 1/2 a bit late, and getting errors. > >>> > >>> There you go! You have just proven that no one would design a UART to work this way and for it to be used in the market place. There would be too many applications where the data burst would cause it to not work. Programming around such a design flaw would be such a PITA and expose the flaw, that the part would become a pariah. > >> Yeah, but you can still insist that the stop bit fills 99%, or 90% of > >> the required time, and not get that pathology. > > > > I'm not clear on what you are saying. The larger the clock difference, the earlier the receiver has to look for the start bit. It will work just fine with the start bit check being delayed until the end of the stop bit, as long as the timing clocks aren't offset in one direction. Looking for the start bit in the middle of the stop bit gives a total of 5% tolerance, pretty much taking mistiming out of the list of problems for async data transmission. Drop that to 0.05% (your 99% example) and you are in the realm of crystal timing error on the two systems, ±250 ppm. > > > Go back to the first words I quoted from Richard: > " > IF you don't start the looking for the start bit until the time has > passed for the END of the stop bit, and the receiver is 0.1% slow, then > every bit you lose 0.1% of a bit > " > But if you wait until 95% of the stop bit time, and allow a new start > bit to come early by 5%, then it doesn't matter if "the receiver is 0.1% > slow" and you don't lose sync; the 5% early doesn't mount up over "50 > consecutive characters". > > Same if you wait 99% and the new start bit is only 1% early. > > So your "There you go! You have just proven..." was a bogus situation > proposed by Richard, that's trivially avoided, and basically all actual > UARTs will do that, If you cherry pick your numbers, you can make anything work. Looking for a start bit at the middle of the stop bit gives you the ±5% tolerance of timing. If you delay when you start looking for a start bit, you reduce this tolerance. So, in that case, if you are happy to provide a ±0.1% tolerance clock under all conditions, then sure, you can look for the start bit later. In the real world, there are users who expect a UART to work the way it is supposed to work, and use less accurate timing references than a crystal. This UART won't work for them and that would become known to users in general. While a claim has been made that such UARTs exist, no one has provided information about one. I would also point out that the above timing analysis is not actually worse case since it does not take into account the 1/16th or 1/8th bit jitter from the first character start bit detection. So the requirements on the timing reference are even tighter when using the sloppy timing for start bit checking.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-09 23:45 -0500 |
| Message-ID | <8m%aL.42192$dJd3.7688@fx11.iad> |
| In reply to | #31390 |
On 11/8/22 8:50 AM, Rick C wrote: > On Tuesday, November 8, 2022 at 7:54:59 AM UTC-4, Richard Damon wrote: >> On 11/7/22 8:15 PM, Rick C wrote: >>> On Monday, November 7, 2022 at 8:02:19 PM UTC-4, Richard Damon wrote: >>>> YOU may consider it a design flaw, but I have seen too many serial ports >>>> having this flaw in them to just totally ignore it. >>> >>> That is exceedingly hard to imagine, since it would take extra logic to implement. The logic of a UART is to first, detect the start bit which lands the state machine in the middle of said start bit which then times to the middle of all subsequent bits (ignoring timing accuracy). So it thinks it is in the middle of the stop bit when the bit timing is complete. It would need to have more hardware to time to the end of the stop bit. This might be present, for other purposes, but it should not be used to control looking for the start bit. This is by definition of the async protocol, to use the stop bit time to resync to the next start bit. Any device that does not start looking for a new start bit at the point it thinks is the middle of the stop bit, is defective by definition and will never work properly with timing mismatches of one polarity, the receiver's clock being slower than the transmitter clock. >> Depends on how you design it. IF you start a counter at the leading edge >> of the start bit and then detect the counter at its middle value, then >> the stop bit ends when the counter finally expires at the END of the >> stop bit. > > There is still some extra logic to distinguish the condition. There is a bit timing counter, and a counter to track which bit you are in. Everything happening in the operation of the UART is happening at the middle of a bit. Then you need extra logic to distinguish the end of a bit. Nope, simplest logic is to have your 8x sub-bit counter start at 0 and count up starting on the leading edge, on the count values of 3, 4, and 5 you sample the bit for noise detection, and roll over from 7 to 0 for the next bit, and count to the next bit. You stop the counter when it rolls from 7 to 0 in the stop bit, and counts past the stop bit. > > >>> I guess I'm not certain that would cause an error, actually. It would initiate the start bit detection logic, and as long as it does not require seeing the idle condition before detecting the start bit condition, it would still work. Again, this is expected by the definition of asynchronous format. This would result in a grosser offset in timing the middle of the bits, so the allowable timing error is less. But it will still work otherwise. 5% is a very large combined error. Most devices are timed by crystals with maybe ±200 ppm error. >> IF you don't start the looking for the start bit until the time has >> passed for the END of the stop bit, and the receiver is 0.1% slow, then >> every bit you lose 0.1% of a bit, or 1% per character, so after 50 >> consecutive characters you are 1/2 a bit late, and getting errors. > > There you go! You have just proven that no one would design a UART to work this way and for it to be used in the market place. There would be too many applications where the data burst would cause it to not work. Programming around such a design flaw would be such a PITA and expose the flaw, that the part would become a pariah. Except that we have bought many USB serial ports with just this flaw in them. So I guess the nobody actually exists. Seem to be based on an FTDI chip, but maybe just a "look alike", where they did bare minimum design work. The key point is that very few applications actually do have very long uninterrupted sequences of characters, and typical PCs will tend to naturally add small spaces just becuase the OS isn't that great. Doesn't require much to fix the issue. > > I recall the Intel USART was such a part for other technical flaws. So they finally came out with a new version that fixed the problems. > >
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-09 21:42 -0800 |
| Message-ID | <79c85448-0160-46a0-b542-08dc4f463eb1n@googlegroups.com> |
| In reply to | #31400 |
On Thursday, November 10, 2022 at 12:46:03 AM UTC-4, Richard Damon wrote: > On 11/8/22 8:50 AM, Rick C wrote: > > On Tuesday, November 8, 2022 at 7:54:59 AM UTC-4, Richard Damon wrote: > >> On 11/7/22 8:15 PM, Rick C wrote: > >>> On Monday, November 7, 2022 at 8:02:19 PM UTC-4, Richard Damon wrote: > >>>> YOU may consider it a design flaw, but I have seen too many serial ports > >>>> having this flaw in them to just totally ignore it. > >>> > >>> That is exceedingly hard to imagine, since it would take extra logic to implement. The logic of a UART is to first, detect the start bit which lands the state machine in the middle of said start bit which then times to the middle of all subsequent bits (ignoring timing accuracy). So it thinks it is in the middle of the stop bit when the bit timing is complete. It would need to have more hardware to time to the end of the stop bit. This might be present, for other purposes, but it should not be used to control looking for the start bit. This is by definition of the async protocol, to use the stop bit time to resync to the next start bit. Any device that does not start looking for a new start bit at the point it thinks is the middle of the stop bit, is defective by definition and will never work properly with timing mismatches of one polarity, the receiver's clock being slower than the transmitter clock. > >> Depends on how you design it. IF you start a counter at the leading edge > >> of the start bit and then detect the counter at its middle value, then > >> the stop bit ends when the counter finally expires at the END of the > >> stop bit. > > > > There is still some extra logic to distinguish the condition. There is a bit timing counter, and a counter to track which bit you are in. Everything happening in the operation of the UART is happening at the middle of a bit. Then you need extra logic to distinguish the end of a bit. > Nope, simplest logic is to have your 8x sub-bit counter start at 0 and > count up starting on the leading edge, on the count values of 3, 4, and > 5 you sample the bit for noise detection, and roll over from 7 to 0 for > the next bit, and count to the next bit. You stop the counter when it > rolls from 7 to 0 in the stop bit, and counts past the stop bit. You've conveniently left out a significant amount of logic. Detecting specific states of the sub-bit counter uses more logic than other function. Most UARTs use 16 sub-samples and so have a 4 bit counter. Counters have a carry chain built in, so the carry out is a free zero count detector. Counters are most efficient in terms of implementation when done as down counters, with various preloads. The counter is loaded with the half bit count while waiting for the leading edge of the start bit. The same zero detection (carry out) that triggers the next load is also the bit center mark. All loads during an active character will load a full bit count (different in the msb only). Every zero detect will mark a bit center. To get to the end of the final stop bit would require loading the counter with another half bit count, so extra logic. More than anything, why would anyone want to think about adding the extra half bit count when it's not part of any requirement? > >>> I guess I'm not certain that would cause an error, actually. It would initiate the start bit detection logic, and as long as it does not require seeing the idle condition before detecting the start bit condition, it would still work. Again, this is expected by the definition of asynchronous format. This would result in a grosser offset in timing the middle of the bits, so the allowable timing error is less. But it will still work otherwise. 5% is a very large combined error. Most devices are timed by crystals with maybe ±200 ppm error. > >> IF you don't start the looking for the start bit until the time has > >> passed for the END of the stop bit, and the receiver is 0.1% slow, then > >> every bit you lose 0.1% of a bit, or 1% per character, so after 50 > >> consecutive characters you are 1/2 a bit late, and getting errors. > > > > There you go! You have just proven that no one would design a UART to work this way and for it to be used in the market place. There would be too many applications where the data burst would cause it to not work. Programming around such a design flaw would be such a PITA and expose the flaw, that the part would become a pariah. > Except that we have bought many USB serial ports with just this flaw in > them. Oh, you mean the Chinese UARTs that most people won't touch because they are full of flaws! Got it. I was talking about real UARTs that people use in real designs. I used to buy CH340 based USB cables for work. But we eventually figured out that they were unreliable and I only use FTDI cables now. The CH340 cables seemed to work, but would quit after an hour or two or three. > So I guess the nobody actually exists. > > Seem to be based on an FTDI chip, but maybe just a "look alike", where > they did bare minimum design work. There are lots of clones. If you have an FTDI chip with this stop bit problem, I'd love to see it. I think FTDI would love to see it too. > The key point is that very few applications actually do have very long > uninterrupted sequences of characters, and typical PCs will tend to > naturally add small spaces just becuase the OS isn't that great. Doesn't > require much to fix the issue. The key point is that a company like FTDI is not going to sell such crap. "Fixing" such issues is only possible if you have control over the system. Not everyone is designing a system from scratch. My brother's company makes a device that interfaces to a measurement device outputting data periodically. For who knows what reason, that company changed the product so it stopped outputting the headers. So a small box was made to add the headers every few lines. The UARTs in it just have to work correctly, since there's no option to modify any other piece of equipment. If they don't work correctly, they get pulled and they use other equipment, and the original maker gets a black eye. Enough black eyes and people don't buy that equipment anymore. -- Rick C. --+++ Get 1,000 miles of free Supercharging --+++ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-04 08:40 -0700 |
| Message-ID | <05989871-748b-4b08-b564-84a323418b45n@googlegroups.com> |
| In reply to | #31330 |
On Friday, November 4, 2022 at 5:49:42 AM UTC-4, David Brown wrote: > 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. > > 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.) > > > > 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. > > > Implementing an explicit delay (or being confident that your telegram > handling code takes long enough) is a good idea. > > 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 made no such assumptions about timings. The figures I gave were for > using a USB 2 based interface on a PC, where the USB polling timer is at > 8 kHz, or 125 µs. That is half a bit time for 4 Kbaud. (I had doubled > the frequency instead of halving it and said the baud had to be above 16 > kBaud - that shows it's good to do your own calculations and not trust > others blindly!). At 1 MBaud (the suggested rate), the absolute fastest > the PC could turn around the bus would be 12 character times - half a > stop bit is irrelevant. You are making an assumption of implementation. There is a processor in the USB cable that is implementing the UART. The driver enable control is most likely is implemented there. It would be pointless and very subject to failure, to require the main CPU to handle this timing. There's no reason to expect the driver disable to take more than a fraction of a bit time, so the "UART" needs a timing signal to indicate when the stop bit has been completed. The timing issue is not about loading another character into the transmit FIFO. It's about controlling the driver enable. > If you have a 9600 baud RS-485 receiver and you have a delay of 10 µs > between reception of the last bit and the start of transmission of the > next message, your code is wrong - by nearly two orders of magnitude. > It is that simple. > > If we take Modbus RTU as an example, you should be waiting 3.5 * 10 / > 9600 seconds at a minimum - 3.65 /milli/seconds. If you are concerned > about exactly where the receive interrupt comes in the last stop bit, > add another half bit time and you get 3.7 ms. The half bit time is > negligible. Your numbers are only relevant to Modbus. The only requirement is that no two drivers are on the bus at the same time, which requires zero delay from the end of the previous stop bit and the beginning of the next start bit. This is why the timing indication from the UART needs to be the end of the stop bit, not the middle. > > 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. > > > So put in a delay. An /appropriate/ delay. You are thinking software, like most people do. The slaves will be in logic, so the UART will have timing information relevant to the end of bits. I don't care how the master does it. The FTDI cable is alleged to "just work". Nonetheless, I will be providing for separate send and receive buses (or call it master/slave buses). Only one slave will be addressed at a time, so no collisions there, and the master can't collide with itself. > >>> 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. > > > Yes - but see below. Bias resistors are part of the termination - it > just means that you have terminating resistors to 5V and 0V as well as > across the balanced pair. > > > >> 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. > > > If you have a cable that is long enough (or speeds fast enough) that it > needs to be treated as a transmission line with controlled impedance, > then you do need impedance matched terminators to avoid reflections > causing trouble. Usually you don't. > > A "terminating resistor" is just a "resistor at the terminator" - it > does not imply impedance matching, or any other specific purpose. You > pick a value (and network) appropriate for the task in hand - maybe you > impedance matching, maybe you'd rather have larger values to reduce > power consumption. > > > >>> 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. > > > If you are pushing the limits of a bus, in terms of load, distance, > speed, cable characteristics, etc., then you need to do such > calculations carefully and be precise in your specification of > components, cables, topology, connectors, etc. For many buses in > practice, they will work fine using whatever resistor you pull out your > box of random parts. For a testbench, you are going to go for something > between these extremes. How long is a piece of string? By keeping the interconnecting cables short, 4" or so, and a 5 foot cable from the PC, I don't expect problems with reflections. But it is prudent to allow for them anyway. The FTDI RS-422 cable seems to have a terminator on the receiver, but not the driver and no provision to add a terminator to the driver. Oddly enough, the RS-485 cable has a terminator that can be connected by the user, but that would be running through the cable separately from the transceiver signals, so essentially stubbed! I guess at 1 Mbps, 5 feet is less than the rise time, so not an issue. Since the interconnections between cards will be about five feet as well, it's unlikely to be an issue. The entire network will look like a lumped load, with the propagation time on the order of the rise/fall time. Even adding in a second chassis, makes the round trip twice the typical rise/fall time and unlikely to create any issues. They sell cables that have 5 m of cable, with a round trip of 30 ns or so. I think that would still not be significant in this application. The driver rise/fall times are 15 ns typ, 25 ns max. -- Rick C. +-+ Get 1,000 miles of free Supercharging +-+ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2022-11-04 22:53 +0000 |
| Message-ID | <tk4558$1i99$1@gioia.aioe.org> |
| In reply to | #31334 |
Rick C <gnuarm.deletethisbit@gmail.com> wrote:
>
> How long is a piece of string? By keeping the interconnecting cables short, 4" or so, and a 5 foot cable from the PC, I don't expect problems with reflections. But it is prudent to allow for them anyway. The FTDI RS-422 cable seems to have a terminator on the receiver, but not the driver and no provision to add a terminator to the driver.
It is pointless to add terminator to driver, there will be mismatch
anyway and resistor would just waste transmit power. Mismatch
at driver does not case trouble as long as ends are properly
terminated. And when driver is at the near end and there are no
other drivers, then it is enough to put termination only at the
far end. So FTDI cable seem to be doing exactly what is needed.
>
> Oddly enough, the RS-485 cable has a terminator that can be connected by the user, but that would be running through the cable separately from the transceiver signals, so essentially stubbed! I guess at 1 Mbps, 5 feet is less than the rise time, so not an issue. Since the interconnections between cards will be about five feet as well, it's unlikely to be an issue. The entire network will look like a lumped load, with the propagation time on the order of the rise/fall time. Even adding in a second chassis, makes the round trip twice the typical rise/fall time and unlikely to create any issues.
>
> They sell cables that have 5 m of cable, with a round trip of 30 ns or so.
Closer to 50 ns due to lower speed in cable.
> I think that would still not be significant in this application. The driver rise/fall times are 15 ns typ, 25 ns max.
Termination is also to kill _multiple_ reflections. In low loss line
you can have bunch of reflection creating jitter. When jitter is
more than 10% of bit time serial communication tends to have significant
number of errors. At 9600 or at 100000 bits/s with short line bit
time is long enough that jitter due to reflections in untermined
line does not matter. Also multidrop RS-485 is far from low loss,
each extra drop weakens signal, so reflections die faster than
in quality point-to-point line.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-04 18:07 -0700 |
| Message-ID | <e130818b-2e12-4dbc-b8a3-ee72a6ef42b3n@googlegroups.com> |
| In reply to | #31338 |
On Friday, November 4, 2022 at 6:53:34 PM UTC-4, anti...@math.uni.wroc.pl wrote: > Rick C <gnuarm.del...@gmail.com> wrote: > > > > How long is a piece of string? By keeping the interconnecting cables short, 4" or so, and a 5 foot cable from the PC, I don't expect problems with reflections. But it is prudent to allow for them anyway. The FTDI RS-422 cable seems to have a terminator on the receiver, but not the driver and no provision to add a terminator to the driver. > It is pointless to add terminator to driver, there will be mismatch > anyway and resistor would just waste transmit power. Mismatch > at driver does not case trouble as long as ends are properly > terminated. And when driver is at the near end and there are no > other drivers, then it is enough to put termination only at the > far end. So FTDI cable seem to be doing exactly what is needed. Yes, that's true for a single driver and multiple receivers. The point is that with multiple drivers, a terminator is needed at both ends of the cable. You have two ends to terminate, because drivers can be in the middle. You could not use FTDI RS-422 cables in the arrangement I am implementing. Every receiver would add a 120 ohm load to the line. Good thing I only need one! > > Oddly enough, the RS-485 cable has a terminator that can be connected by the user, but that would be running through the cable separately from the transceiver signals, so essentially stubbed! I guess at 1 Mbps, 5 feet is less than the rise time, so not an issue. Since the interconnections between cards will be about five feet as well, it's unlikely to be an issue. The entire network will look like a lumped load, with the propagation time on the order of the rise/fall time. Even adding in a second chassis, makes the round trip twice the typical rise/fall time and unlikely to create any issues. > > > > They sell cables that have 5 m of cable, with a round trip of 30 ns or so. > Closer to 50 ns due to lower speed in cable. > > I think that would still not be significant in this application. The driver rise/fall times are 15 ns typ, 25 ns max. > Termination is also to kill _multiple_ reflections. In low loss line > you can have bunch of reflection creating jitter. When jitter is > more than 10% of bit time serial communication tends to have significant > number of errors. At 9600 or at 100000 bits/s with short line bit > time is long enough that jitter due to reflections in untermined > line does not matter. Also multidrop RS-485 is far from low loss, > each extra drop weakens signal, so reflections die faster than > in quality point-to-point line. How do RS-485 drops "weaken" the signal? The load of an RS-485 device is very slight. The same result will happen with multiple receivers on RS-422. I expect to be running at least 1 Mbps, possibly as high as 3 Mbps. One thing I'm a bit confused about, is the wiring of the EIA/TIA 568B or 568A cables. Both standards are used, but as far as I can tell, the only difference is the colors! The green and orange twisted pairs are reversed on both ends, making the cables electrically identical, other than the colors used for a given pair. The only difference is, the different pairs have different twist pitch, to help reduce crosstalk. But the numbers are not specified in the spec, so I don't see how this could matter. Why would the color be an issue, to the point of creating two different specs??? Obviously I'm missing something. I will need to check a cable before I design the boards, lol. -- Rick C. ---- Get 1,000 miles of free Supercharging ---- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2022-11-05 03:46 +0000 |
| Message-ID | <tk4ma3$s3v$1@gioia.aioe.org> |
| In reply to | #31340 |
Rick C <gnuarm.deletethisbit@gmail.com> wrote:
> On Friday, November 4, 2022 at 6:53:34 PM UTC-4, anti...@math.uni.wroc.pl wrote:
> > Rick C <gnuarm.del...@gmail.com> wrote:
> > >
> > > How long is a piece of string? By keeping the interconnecting cables short, 4" or so, and a 5 foot cable from the PC, I don't expect problems with reflections. But it is prudent to allow for them anyway. The FTDI RS-422 cable seems to have a terminator on the receiver, but not the driver and no provision to add a terminator to the driver.
> > It is pointless to add terminator to driver, there will be mismatch
> > anyway and resistor would just waste transmit power. Mismatch
> > at driver does not case trouble as long as ends are properly
> > terminated. And when driver is at the near end and there are no
> > other drivers, then it is enough to put termination only at the
> > far end. So FTDI cable seem to be doing exactly what is needed.
>
> Yes, that's true for a single driver and multiple receivers. The point is that with multiple drivers, a terminator is needed at both ends of the cable. You have two ends to terminate, because drivers can be in the middle.
With 100 Ohm line driver in the middle sees two parts in parallel, so
effectively 50 Ohm. Typical driver impedance is about 40 Ohm, so
while mismatched, mismath is not too bad. Also, with multiple
devices on the line there will be undesirable signals even if you
have termination at both ends.
In unterminated line there will be some loss, so after each reflection
reflected signal will be weaker, in rough approximation multiplied
by some number a < 1 (say 0.8). After n reflections signal will
be multiplied by a^n and for large enough n will become negligible.
Termination at given end with 1% resistor means that about 2% will
be reflected (due to imperfection). This 2% is likely to be negligible.
If transmitter is in the middle, there is still reflection at the
end opposite to termination and at the transmitter. But mismatch
at transmitter is not bad and the corresponding parameter a is
much smaller than in unterminated case. So termination at one
end reduces number of problematic reflections probably about 2-4
times. Which means that you can increase transfer rate by
similar factor. Of course, termintion at both ends is better,
but in multidrop case speed will be lower than in point-to-point
link.
> You could not use FTDI RS-422 cables in the arrangement I am implementing. Every receiver would add a 120 ohm load to the line. Good thing I only need one!
Well, multiple receivers on RS-422 have limited usefulness (AFAIK your
use case is called 4-wire RS-485), so no wonder that FTDI does not
support it. Maybe they have something more expensive that is
doing what you want.
> > > Oddly enough, the RS-485 cable has a terminator that can be connected by the user, but that would be running through the cable separately from the transceiver signals, so essentially stubbed! I guess at 1 Mbps, 5 feet is less than the rise time, so not an issue. Since the interconnections between cards will be about five feet as well, it's unlikely to be an issue. The entire network will look like a lumped load, with the propagation time on the order of the rise/fall time. Even adding in a second chassis, makes the round trip twice the typical rise/fall time and unlikely to create any issues.
> > >
> > > They sell cables that have 5 m of cable, with a round trip of 30 ns or so.
> > Closer to 50 ns due to lower speed in cable.
> > > I think that would still not be significant in this application. The driver rise/fall times are 15 ns typ, 25 ns max.
> > Termination is also to kill _multiple_ reflections. In low loss line
> > you can have bunch of reflection creating jitter. When jitter is
> > more than 10% of bit time serial communication tends to have significant
> > number of errors. At 9600 or at 100000 bits/s with short line bit
> > time is long enough that jitter due to reflections in untermined
> > line does not matter. Also multidrop RS-485 is far from low loss,
> > each extra drop weakens signal, so reflections die faster than
> > in quality point-to-point line.
>
> How do RS-485 drops "weaken" the signal? The load of an RS-485 device is very slight. The same result will happen with multiple receivers on RS-422.
That is general thing, not specific to RS-485. If RS-485 receiver
puts 24 kOhm load on line, that is about 0.4% of line impedance.
When signal passes past receiver there is corresponding power loss.
There is also second effect: receiver created discontinuity, so
there is reflection. And beside resitive part receiver impedance
has also reactive part which means that discontinuity and reflection
is bigger than implied by receiver resistance. With lower load
recevier effect is smaller, but still there is fraction of percent
lost or reflected. Single loss is "very slight", but they add up
and increase effective line loss: with single receiver reflecting/losing
0.5 after 40 receivers 20% of signal is gone. This 20% effectively
adds to normal line loss.
> I expect to be running at least 1 Mbps, possibly as high as 3 Mbps.
You probably should check if you can get such rate with short messages.
If did little experiment using CH340 and CP2104. That was bi-drectional
TTL level serial connection using 15 cm wires. Slave echoed each
received character after mangling it a little (so I knew that it
really came from the slave and not from some echo in software stack).
I had trouble running CH340 above 460800 (that could be limit of program
that I used). But using 1 character messages 10000 round trips took
about 7s, with small influence from serial speed (almost the same
result at 115200 and 230400). Also increasing message to 5 bytes
gave essentially the same number of _messages_.
CP2104 was better, here I could go up to 2000000. Using 5 byte
messages 10000 round trips needed 2.5s up to 1500000, at
2000000 time dropped to about 1.9. When I increased message
to 10 bytes it was back about 2.5s.
I must admit that ATM I am not sure what this means. But this 2.5s
looks significant: this means 4000 round trips per second, which
is 8000 messages, which in turn is number of USB cycles. So,
it seems that normally smallish messages need USB cycle (125 uS)
to get trough USB bus. It seems that sometimes more than one
message may go trough in a cycle (giving smaller times that I
observed), but it is not clear if one can do significantly better.
And CH340 shows that it may be much worse.
FTDI is claimed to be very good, so maybe it is better, but I would
not count on this without checking. Actually, I remember folks
complaining that they needed more than millisecond to get message
trough USB-serial.
OTOH, your description suggest that you should be able to do what
you want with much smaller message traffic, so maybe USB-serial
speed is enough for you.
> One thing I'm a bit confused about, is the wiring of the EIA/TIA 568B or 568A cables. Both standards are used, but as far as I can tell, the only difference is the colors! The green and orange twisted pairs are reversed on both ends, making the cables electrically identical, other than the colors used for a given pair. The only difference is, the different pairs have different twist pitch, to help reduce crosstalk. But the numbers are not specified in the spec, so I don't see how this could matter.
>
> Why would the color be an issue, to the point of creating two different specs???
>
> Obviously I'm missing something. I will need to check a cable before I design the boards, lol.
You may be missing fact that most folks installing network cabling
do not know about transmission lines and reasons for matching pairs.
And even for folks that understand theory, it is easier to check
that colors are in position prescribed in the norm, than to check
pairs. So, colors matter because using colors folks can get correct
connetion without too much thinking. Why two specs? I think
that this is artifact of history and way that standard bodies work.
When half of industry is using one way and other half is using
different but equally good way standard body can not say that
one half is wrong, they must allow both ways.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-05 02:09 -0700 |
| Message-ID | <daeb9fd7-344e-4a9b-a05f-2cb2d7d11a0bn@googlegroups.com> |
| In reply to | #31343 |
On Friday, November 4, 2022 at 11:46:16 PM UTC-4, anti...@math.uni.wroc.pl wrote: > Rick C <gnuarm.del...@gmail.com> wrote: > > On Friday, November 4, 2022 at 6:53:34 PM UTC-4, anti...@math.uni.wroc.pl wrote: > > > Rick C <gnuarm.del...@gmail.com> wrote: > > > > > > > > How long is a piece of string? By keeping the interconnecting cables short, 4" or so, and a 5 foot cable from the PC, I don't expect problems with reflections. But it is prudent to allow for them anyway. The FTDI RS-422 cable seems to have a terminator on the receiver, but not the driver and no provision to add a terminator to the driver. > > > It is pointless to add terminator to driver, there will be mismatch > > > anyway and resistor would just waste transmit power. Mismatch > > > at driver does not case trouble as long as ends are properly > > > terminated. And when driver is at the near end and there are no > > > other drivers, then it is enough to put termination only at the > > > far end. So FTDI cable seem to be doing exactly what is needed. > > > > Yes, that's true for a single driver and multiple receivers. The point is that with multiple drivers, a terminator is needed at both ends of the cable. You have two ends to terminate, because drivers can be in the middle. > With 100 Ohm line driver in the middle sees two parts in parallel, so > effectively 50 Ohm. Typical driver impedance is about 40 Ohm, so > while mismatched, mismath is not too bad. Also, with multiple > devices on the line there will be undesirable signals even if you > have termination at both ends. I don't want to get into a big discussion on termination, but any time a driver is in the middle of the line, it will see two loads, one for each direction of the cable. The termination only impacts the behavior of the reflection. So every driver that is not at the end of the line, will see the characteristic impedance divided by two. However, since the driver is not impedance matched to the line, that should not matter. But to prevent reflections, each end needs to be terminated, to prevent reflections from that end. The disruptions from the driver/receiver connections of intermediate chips will be small, since they are high impedance and minimal capacitance compared to the transmission line. These signals have multiple ns rise and fall times, so even with no terminations, it is unlikely to see effects from reflections from the ends of the line, much less the individual connections. > In unterminated line there will be some loss, so after each reflection > reflected signal will be weaker, in rough approximation multiplied > by some number a < 1 (say 0.8). After n reflections signal will > be multiplied by a^n and for large enough n will become negligible. > Termination at given end with 1% resistor means that about 2% will > be reflected (due to imperfection). This 2% is likely to be negligible. > If transmitter is in the middle, there is still reflection at the > end opposite to termination and at the transmitter. But mismatch > at transmitter is not bad and the corresponding parameter a is > much smaller than in unterminated case. So termination at one > end reduces number of problematic reflections probably about 2-4 > times. Which means that you can increase transfer rate by > similar factor. Of course, termintion at both ends is better, > but in multidrop case speed will be lower than in point-to-point > link. Multidrop is a single driver and multiple receivers. Multipoint is multiple drivers and receivers. One line will be multidrop (from PC) and the other multipoint (to the PC). The Multidrop will be single terminated since the driver needs no termination, it's impedance is well below the line impedance. The Multipoint line has a termination in the FTDI device on the receiver. Another termination will be added to the far end of the run. This is mostly insurance. I would not expect trouble if I used no terminators. I could probably use a TTL level serial cable and no RS-422 interface chips. But that's going a bit far I think. Using RS-422 is enough insurance to make the system work reliably. > > You could not use FTDI RS-422 cables in the arrangement I am implementing. Every receiver would add a 120 ohm load to the line. Good thing I only need one! > Well, multiple receivers on RS-422 have limited usefulness (AFAIK your > use case is called 4-wire RS-485), so no wonder that FTDI does not > support it. Maybe they have something more expensive that is > doing what you want. ??? Who said FTDI does not support multiple receivers? Oh, you mean their cables only. I'm not sure why you say this has limited usefulness. But whatever. That's not a thing worth mentioning really. I'm not using FTDI anyplace other than the PC, so their device does exactly what I want. The only other, differential cable is RS-485, which I don't want to use as you have to pay more attention to timing of the driver enables. > > > > Oddly enough, the RS-485 cable has a terminator that can be connected by the user, but that would be running through the cable separately from the transceiver signals, so essentially stubbed! I guess at 1 Mbps, 5 feet is less than the rise time, so not an issue. Since the interconnections between cards will be about five feet as well, it's unlikely to be an issue. The entire network will look like a lumped load, with the propagation time on the order of the rise/fall time. Even adding in a second chassis, makes the round trip twice the typical rise/fall time and unlikely to create any issues. > > > > > > > > They sell cables that have 5 m of cable, with a round trip of 30 ns or so. > > > Closer to 50 ns due to lower speed in cable. > > > > I think that would still not be significant in this application. The driver rise/fall times are 15 ns typ, 25 ns max. > > > Termination is also to kill _multiple_ reflections. In low loss line > > > you can have bunch of reflection creating jitter. When jitter is > > > more than 10% of bit time serial communication tends to have significant > > > number of errors. At 9600 or at 100000 bits/s with short line bit > > > time is long enough that jitter due to reflections in untermined > > > line does not matter. Also multidrop RS-485 is far from low loss, > > > each extra drop weakens signal, so reflections die faster than > > > in quality point-to-point line. > > > > How do RS-485 drops "weaken" the signal? The load of an RS-485 device is very slight. The same result will happen with multiple receivers on RS-422. > That is general thing, not specific to RS-485. If RS-485 receiver > puts 24 kOhm load on line, that is about 0.4% of line impedance. > When signal passes past receiver there is corresponding power loss. If you are talking about the load resistance, that is trivial enough to be ignored for signal loss. The basic RS-422 devices are rated for 32 loads, and the numbers in the FTDI data sheet (54 ohms load) are with a pair of 120 ohm resistors and 32 loads. > There is also second effect: receiver created discontinuity, so > there is reflection. And beside resitive part receiver impedance > has also reactive part which means that discontinuity and reflection > is bigger than implied by receiver resistance. With lower load > recevier effect is smaller, but still there is fraction of percent > lost or reflected. Single loss is "very slight", but they add up > and increase effective line loss: with single receiver reflecting/losing > 0.5 after 40 receivers 20% of signal is gone. This 20% effectively > adds to normal line loss. The "reactive" part of the receiver/driver load is capacitive. That does not change with the load value. It's mostly from the packaging is my understanding, but they don't give a value in the part data sheet. I expect there's more capacitance in the 6 foot cable than the device. I don't know how you come up with the loss number. > > I expect to be running at least 1 Mbps, possibly as high as 3 Mbps. > You probably should check if you can get such rate with short messages. > If did little experiment using CH340 and CP2104. That was bi-drectional > TTL level serial connection using 15 cm wires. Slave echoed each > received character after mangling it a little (so I knew that it > really came from the slave and not from some echo in software stack). > I had trouble running CH340 above 460800 (that could be limit of program > that I used). But using 1 character messages 10000 round trips took > about 7s, with small influence from serial speed (almost the same > result at 115200 and 230400). Also increasing message to 5 bytes > gave essentially the same number of _messages_. I ran the numbers in one of my posts (here or in another group). My messages are around 10 char with the same echo or three more characters for a read reply. Assuming 8 kHz for the polling rate, an exchange would happen at 4 kHz. A total of 25 char gives 100 kchar/s or 800 kbps on USB or 1,000 kbps on the RS-422/RS-485 interface. So I would probably want to use something a bit faster than 1 Mbps. I think 4k messages per second will be plenty fast enough. With 128 UUT in the system that's 32 commands per second per UUT. I may want to streamline the protocol a bit to incorporate the slave selection in every command. This will be more characters per message, but more efficient overall with fewer messages. The process can be to send the same command to every UUT at the same time. Mostly this is just not an issue, until the audio tests. They take some noticeable time to execute, as they collect some amount of audio data. I might add a test for spurs, since some UUT failures clip the sinewaves due to DC bias faults and harmonic distortion would be a way to check for this. I want the testing to diagnose as much as possible. This would add another slow test. So these should be done on all UUT in parallel. > CP2104 was better, here I could go up to 2000000. Using 5 byte > messages 10000 round trips needed 2.5s up to 1500000, at > 2000000 time dropped to about 1.9. When I increased message > to 10 bytes it was back about 2.5s. > > I must admit that ATM I am not sure what this means. But this 2.5s > looks significant: this means 4000 round trips per second, which > is 8000 messages, which in turn is number of USB cycles. So, > it seems that normally smallish messages need USB cycle (125 uS) > to get trough USB bus. It seems that sometimes more than one > message may go trough in a cycle (giving smaller times that I > observed), but it is not clear if one can do significantly better. > And CH340 shows that it may be much worse. I used to use CH340 cables with my test fixture, but they would stop working after some time, hours I think. I think the cable had to be unplugged to get it working again. Once I realized it was the CH340 cable/drivers, I got FTDI devices and never looked back. They are triple the price, but much, much cheaper in the long run. > FTDI is claimed to be very good, so maybe it is better, but I would > not count on this without checking. Actually, I remember folks > complaining that they needed more than millisecond to get message > trough USB-serial. It's too early to be testing, but I will get to that. I suppose I could do loopback testing with the RS-232 cable I have now. > OTOH, your description suggest that you should be able to do what > you want with much smaller message traffic, so maybe USB-serial > speed is enough for you. If it doesn't run at the speed I'm thinking, it's not a big loss. There's no testing at all done with the current burn in chassis. The UUTs are tested one at a time. You can't get much slower than that. Even if it takes a minute to run a full test, that's on all 128 UUTs in parallel and it will be around 1000 times faster than what we have now! The slow part will be getting all the UUTs loaded on the test fixtures and getting the process started. Any bad UUTs will need to be pulled out and tested/debugged separately. Once they are pulled out, the testing runs until the next day when the units are labeled with a serial number and ready to ship! > > One thing I'm a bit confused about, is the wiring of the EIA/TIA 568B or 568A cables. Both standards are used, but as far as I can tell, the only difference is the colors! The green and orange twisted pairs are reversed on both ends, making the cables electrically identical, other than the colors used for a given pair. The only difference is, the different pairs have different twist pitch, to help reduce crosstalk. But the numbers are not specified in the spec, so I don't see how this could matter. > > > > Why would the color be an issue, to the point of creating two different specs??? > > > > Obviously I'm missing something. I will need to check a cable before I design the boards, lol. > You may be missing fact that most folks installing network cabling > do not know about transmission lines and reasons for matching pairs. > And even for folks that understand theory, it is easier to check > that colors are in position prescribed in the norm, than to check > pairs. So, colors matter because using colors folks can get correct > connetion without too much thinking. The people using the cables don't see the colors. They just plug them in. > Why two specs? I think > that this is artifact of history and way that standard bodies work. > When half of industry is using one way and other half is using > different but equally good way standard body can not say that > one half is wrong, they must allow both ways. But it's not different, really. It's just colors that mean nothing to anyone actually using the cables. They just want to plug them in and make things work. The color of the insulator won't change that at all. If there was something different about the wiring, then I'd say, I get it. But electrically they are identical. It's also odd, that the spec doesn't say how many turns per foot/meter are in the twisted pair. But it is different in each pair to give less crosstalk. -- Rick C. ---+ Get 1,000 miles of free Supercharging ---+ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Stef <me@this.is.invalid> |
|---|---|
| Date | 2022-11-07 10:40 +0100 |
| Message-ID | <nnd$6a130c7b$68b29486@72e1c12e4320b3d3> |
| In reply to | #31340 |
On 2022-11-05 Rick C wrote in comp.arch.embedded: ... > One thing I'm a bit confused about, is the wiring of the EIA/TIA 568B or 568A cables. Both standards are used, but as far as I can tell, the only difference is the colors! The green and orange twisted pairs are reversed on both ends, making the cables electrically identical, other than the colors used for a given pair. The only difference is, the different pairs have different twist pitch, to help reduce crosstalk. But the numbers are not specified in the spec, so I don't see how this could matter. > > Why would the color be an issue, to the point of creating two different specs??? > > Obviously I'm missing something. I will need to check a cable before I design the boards, lol. Yes, only difference is the colors. There are some historical backgrounds, see also https://en.wikipedia.org/wiki/ANSI/TIA-568. In the early days there sometimes was a need for crossover cables. 568A on one end, 568B on the other end. IIRC, you needed one to connect 2 PC's together directly, without a hub. Hubs also had a special uplink port. These days all ethernet PHY's are auto detect and there is no need for special ports or cables anymore. So pick a standard you like or just use what is available. Most cables I have in my drawer here seem to be 568B. Just standard cables, did not pay attention to the A/B when I bought them. ;-) -- Stef The light at the end of the tunnel is the headlight of an approaching train.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-05 12:47 +0100 |
| Message-ID | <tk5iha$2e64h$1@dont-email.me> |
| In reply to | #31334 |
On 04/11/2022 16:40, Rick C wrote: > On Friday, November 4, 2022 at 5:49:42 AM UTC-4, David Brown wrote: >> 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. >>> 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.) >>> >>> 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. >>> >> Implementing an explicit delay (or being confident that your telegram >> handling code takes long enough) is a good idea. >>> 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 made no such assumptions about timings. The figures I gave were for >> using a USB 2 based interface on a PC, where the USB polling timer is at >> 8 kHz, or 125 µs. That is half a bit time for 4 Kbaud. (I had doubled >> the frequency instead of halving it and said the baud had to be above 16 >> kBaud - that shows it's good to do your own calculations and not trust >> others blindly!). At 1 MBaud (the suggested rate), the absolute fastest >> the PC could turn around the bus would be 12 character times - half a >> stop bit is irrelevant. > > You are making an assumption of implementation. There is a processor in the USB cable that is implementing the UART. The driver enable control is most likely is implemented there. It would be pointless and very subject to failure, to require the main CPU to handle this timing. There's no reason to expect the driver disable to take more than a fraction of a bit time, so the "UART" needs a timing signal to indicate when the stop bit has been completed. > I'm making the assumption that you are using appropriate hardware. No processor, just a USB device that has a "transmitter enable" signal on its UART. I'm getting the impression that you have never heard of such a UART (either in a USB-to-UART device, or as a UART peripheral elsewhere), and assume software has to be involved in enabling and disabling the transmitter. Please believe me when I say such UARTs /do/ exist - and the FTDI examples I keep giving are a case in point. > The timing issue is not about loading another character into the transmit FIFO. It's about controlling the driver enable. > Yes, and it is a /solved/ issue if you pick the right hardware. > >> If you have a 9600 baud RS-485 receiver and you have a delay of 10 µs >> between reception of the last bit and the start of transmission of the >> next message, your code is wrong - by nearly two orders of magnitude. >> It is that simple. >> >> If we take Modbus RTU as an example, you should be waiting 3.5 * 10 / >> 9600 seconds at a minimum - 3.65 /milli/seconds. If you are concerned >> about exactly where the receive interrupt comes in the last stop bit, >> add another half bit time and you get 3.7 ms. The half bit time is >> negligible. > > Your numbers are only relevant to Modbus. The only requirement is that no two drivers are on the bus at the same time, which requires zero delay from the end of the previous stop bit and the beginning of the next start bit. This is why the timing indication from the UART needs to be the end of the stop bit, not the middle. > A single transmitter, while sending a multi-character message, does not need any delay between sending the full stop bit and starting the next start bit. That is obvious. And that is why a "transmission complete" signal comes at the end of the start bit sent on the transmitter side. On the receiver side, the "byte received" signal comes in the /middle/ of the stop bit, as seen by the receiver, because that could be at the /end/ of the stop bit as seen by the transmitter due to clock differences. (It could also be at the /start/ of the stop bit as seen by the transmitter.) The receiver has to prepare for the next incoming start bit as soon as it identifies the stop bit. But you want an extra delay of at least 11 bits (a character frame plus a buffer for clock speed differences) between messages - whether they are from the same transmitter or a different transmitter - to allow resynchronisation if something has gone wrong. I've explained in other posts why inter-message pauses are needed for reliable UART communication protocols. They don't /need/ to be as long as 35 bit times as Modbus specifies - 11 bit times is the minimum. If you don't understand this by now, then we should drop this point. > >>> 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. >>> >> So put in a delay. An /appropriate/ delay. > > You are thinking software, like most people do. It doesn't matter whether things are software, hardware, or something in between. > The slaves will be in logic, so the UART will have timing information relevant to the end of bits. I don't care how the master does it. The FTDI cable is alleged to "just work". Nonetheless, I will be providing for separate send and receive buses (or call it master/slave buses). Only one slave will be addressed at a time, so no collisions there, and the master can't collide with itself. > Yes, with the bus you have described, and the command/response protocol you have described, there should be no problems with multiple transmitters on the bus, and you have plenty of inter-message idle periods. However, this Usenet thread has been mixing posts from different people, and discussions of different kinds of buses and protocols - not just the solution you picked (which, as I have said before, should work fine). I think this mixing means that people are sometimes talking at cross-purposes. >> If you are pushing the limits of a bus, in terms of load, distance, >> speed, cable characteristics, etc., then you need to do such >> calculations carefully and be precise in your specification of >> components, cables, topology, connectors, etc. For many buses in >> practice, they will work fine using whatever resistor you pull out your >> box of random parts. For a testbench, you are going to go for something >> between these extremes. > > How long is a piece of string? By keeping the interconnecting cables short, 4" or so, and a 5 foot cable from the PC, I don't expect problems with reflections. But it is prudent to allow for them anyway. The FTDI RS-422 cable seems to have a terminator on the receiver, but not the driver and no provision to add a terminator to the driver. > There is no point in having a terminator at a driver (unless you are talking about very high speed signals with serial resistors for slope control). You will want to add a terminator at the far end of both buses. This will give you a single terminator on the PC-to-slave bus, which is fine as it is fixed direction, and two terminators on the slave-to-PC bus, which is appropriate as it has no fixed direction. (I agree that your piece of string is of a size that should work fine without reflections being a concern.) > Oddly enough, the RS-485 cable has a terminator that can be connected by the user, but that would be running through the cable separately from the transceiver signals, so essentially stubbed! I guess at 1 Mbps, 5 feet is less than the rise time, so not an issue. Since the interconnections between cards will be about five feet as well, it's unlikely to be an issue. The entire network will look like a lumped load, with the propagation time on the order of the rise/fall time. Even adding in a second chassis, makes the round trip twice the typical rise/fall time and unlikely to create any issues. > > They sell cables that have 5 m of cable, with a round trip of 30 ns or so. I think that would still not be significant in this application. The driver rise/fall times are 15 ns typ, 25 ns max. > The speed of a signal in a copper cable is typically about 70% of the speed of light, giving a minimum round-trip time closer to 45 ns than 30 ns. Not that it makes any difference here.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-05 10:23 -0700 |
| Message-ID | <55844769-5be7-47e9-b849-396e655188abn@googlegroups.com> |
| In reply to | #31346 |
On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote: > On 04/11/2022 16:40, Rick C wrote: > > On Friday, November 4, 2022 at 5:49:42 AM UTC-4, David Brown wrote: > >> I made no such assumptions about timings. The figures I gave were for > >> using a USB 2 based interface on a PC, where the USB polling timer is at > >> 8 kHz, or 125 µs. That is half a bit time for 4 Kbaud. (I had doubled > >> the frequency instead of halving it and said the baud had to be above 16 > >> kBaud - that shows it's good to do your own calculations and not trust > >> others blindly!). At 1 MBaud (the suggested rate), the absolute fastest > >> the PC could turn around the bus would be 12 character times - half a > >> stop bit is irrelevant. > > > > You are making an assumption of implementation. There is a processor in the USB cable that is implementing the UART. The driver enable control is most likely is implemented there. It would be pointless and very subject to failure, to require the main CPU to handle this timing. There's no reason to expect the driver disable to take more than a fraction of a bit time, so the "UART" needs a timing signal to indicate when the stop bit has been completed. > > > I'm making the assumption that you are using appropriate hardware. No > processor, just a USB device that has a "transmitter enable" signal on > its UART. How can there not be a processor? I'm using a split bus, with the PC master driving all the slave receivers and all the slave transmitters sharing the PC receive bus. Is the PC not a processor? The slaves have no USB. > I'm getting the impression that you have never heard of such a UART > (either in a USB-to-UART device, or as a UART peripheral elsewhere), and > assume software has to be involved in enabling and disabling the > transmitter. Please believe me when I say such UARTs /do/ exist - and > the FTDI examples I keep giving are a case in point. You are not being clear. I don't know and don't care what is inside the FTDI device. That's just magic to me, or it's like something inside the black hole, unknowable. More importantly, there is no transmitter enable on the RS-422 driver in the FTDI device, because it's not tristateable. > > The timing issue is not about loading another character into the transmit FIFO. It's about controlling the driver enable. > > > Yes, and it is a /solved/ issue if you pick the right hardware. > > > >> If you have a 9600 baud RS-485 receiver and you have a delay of 10 µs > >> between reception of the last bit and the start of transmission of the > >> next message, your code is wrong - by nearly two orders of magnitude. > >> It is that simple. > >> > >> If we take Modbus RTU as an example, you should be waiting 3.5 * 10 / > >> 9600 seconds at a minimum - 3.65 /milli/seconds. If you are concerned > >> about exactly where the receive interrupt comes in the last stop bit, > >> add another half bit time and you get 3.7 ms. The half bit time is > >> negligible. > > > > Your numbers are only relevant to Modbus. The only requirement is that no two drivers are on the bus at the same time, which requires zero delay from the end of the previous stop bit and the beginning of the next start bit. This is why the timing indication from the UART needs to be the end of the stop bit, not the middle. > > > A single transmitter, while sending a multi-character message, does not > need any delay between sending the full stop bit and starting the next > start bit. That is obvious. And that is why a "transmission complete" > signal comes at the end of the start bit sent on the transmitter side. ??? Are you talking about the buffer management signals for the software? > On the receiver side, the "byte received" signal comes in the /middle/ > of the stop bit, as seen by the receiver, because that could be at the > /end/ of the stop bit as seen by the transmitter due to clock > differences. (It could also be at the /start/ of the stop bit as seen > by the transmitter.) The receiver has to prepare for the next incoming > start bit as soon as it identifies the stop bit. Again, this depends entirely on what this signal is used for. For entering the state of detecting the next start bit, yes, that is the perceived middle of the stop bit. > But you want an extra delay of at least 11 bits (a character frame plus > a buffer for clock speed differences) between messages - whether they > are from the same transmitter or a different transmitter - to allow > resynchronisation if something has gone wrong. Again, you seem to not understand the use case. The split bus never has messages back to back on the same pair. It gets confusing because so many people have tried to talk up RS-485 using a single pair. In that case, everything is totally different. Slaves need to wait until the driver has stopped driving the bus, which means an additional bit time to account for timing errors. But RS-485 is not being used. Each bus is simplex, implementing a half-duplex protocol on the two buses. > I've explained in other posts why inter-message pauses are needed for > reliable UART communication protocols. They don't /need/ to be as long > as 35 bit times as Modbus specifies - 11 bit times is the minimum. If > you don't understand this by now, then we should drop this point. You are assuming a need for error tolerance. But a munged message is the problem, not resyncing. A protocol to detect an error and retransmit is very messy. I've tried that before and it messes up the protocol badly. > >> So put in a delay. An /appropriate/ delay. > > > > You are thinking software, like most people do. > It doesn't matter whether things are software, hardware, or something in > between. Of course it does. Since the slaves are all logic, there is no need for delays, at all. The slave driver can be enabled at any time the message has been received and the reply is ready to go. > > The slaves will be in logic, so the UART will have timing information relevant to the end of bits. I don't care how the master does it. The FTDI cable is alleged to "just work". Nonetheless, I will be providing for separate send and receive buses (or call it master/slave buses). Only one slave will be addressed at a time, so no collisions there, and the master can't collide with itself. > > > Yes, with the bus you have described, and the command/response protocol > you have described, there should be no problems with multiple > transmitters on the bus, and you have plenty of inter-message idle periods. > > However, this Usenet thread has been mixing posts from different people, > and discussions of different kinds of buses and protocols - not just the > solution you picked (which, as I have said before, should work fine). I > think this mixing means that people are sometimes talking at cross-purposes. Yes, it gets confusing. > >> If you are pushing the limits of a bus, in terms of load, distance, > >> speed, cable characteristics, etc., then you need to do such > >> calculations carefully and be precise in your specification of > >> components, cables, topology, connectors, etc. For many buses in > >> practice, they will work fine using whatever resistor you pull out your > >> box of random parts. For a testbench, you are going to go for something > >> between these extremes. > > > > How long is a piece of string? By keeping the interconnecting cables short, 4" or so, and a 5 foot cable from the PC, I don't expect problems with reflections. But it is prudent to allow for them anyway. The FTDI RS-422 cable seems to have a terminator on the receiver, but not the driver and no provision to add a terminator to the driver. > > > There is no point in having a terminator at a driver (unless you are > talking about very high speed signals with serial resistors for slope > control). You will want to add a terminator at the far end of both > buses. This will give you a single terminator on the PC-to-slave bus, > which is fine as it is fixed direction, and two terminators on the > slave-to-PC bus, which is appropriate as it has no fixed direction. It does if you are using it in a shared bus with multiple drivers. The line should still be organized as linear with minimal stubs and a terminator on each end. This is not my plan, so maybe I should stop discussing it. > (I agree that your piece of string is of a size that should work fine > without reflections being a concern.) > > Oddly enough, the RS-485 cable has a terminator that can be connected by the user, but that would be running through the cable separately from the transceiver signals, so essentially stubbed! I guess at 1 Mbps, 5 feet is less than the rise time, so not an issue. Since the interconnections between cards will be about five feet as well, it's unlikely to be an issue. The entire network will look like a lumped load, with the propagation time on the order of the rise/fall time. Even adding in a second chassis, makes the round trip twice the typical rise/fall time and unlikely to create any issues. > > > > They sell cables that have 5 m of cable, with a round trip of 30 ns or so. I think that would still not be significant in this application. The driver rise/fall times are 15 ns typ, 25 ns max. > > > The speed of a signal in a copper cable is typically about 70% of the > speed of light, giving a minimum round-trip time closer to 45 ns than 30 > ns. Not that it makes any difference here. The problem I have now is finding parts to use for this. These devices seem to be in a catagory that are hit hard by the shortage. My product uses the SN65C1168EPW, which is very hard to find in quantity. My customer has mentioned 18,000 units next year. I may need to get with the factory and see if they can supply me directly. -- Rick C. --++ Get 1,000 miles of free Supercharging --++ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-05 19:57 +0100 |
| Message-ID | <tk6bmk$2k36a$3@dont-email.me> |
| In reply to | #31349 |
On 05/11/2022 18:23, Rick C wrote: > On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote: >> On 04/11/2022 16:40, Rick C wrote: >>> On Friday, November 4, 2022 at 5:49:42 AM UTC-4, David Brown wrote: >>>> I made no such assumptions about timings. The figures I gave were for >>>> using a USB 2 based interface on a PC, where the USB polling timer is at >>>> 8 kHz, or 125 µs. That is half a bit time for 4 Kbaud. (I had doubled >>>> the frequency instead of halving it and said the baud had to be above 16 >>>> kBaud - that shows it's good to do your own calculations and not trust >>>> others blindly!). At 1 MBaud (the suggested rate), the absolute fastest >>>> the PC could turn around the bus would be 12 character times - half a >>>> stop bit is irrelevant. >>> >>> You are making an assumption of implementation. There is a processor in the USB cable that is implementing the UART. The driver enable control is most likely is implemented there. It would be pointless and very subject to failure, to require the main CPU to handle this timing. There's no reason to expect the driver disable to take more than a fraction of a bit time, so the "UART" needs a timing signal to indicate when the stop bit has been completed. >>> >> I'm making the assumption that you are using appropriate hardware. No >> processor, just a USB device that has a "transmitter enable" signal on >> its UART. > > How can there not be a processor? I'm using a split bus, with the PC master driving all the slave receivers and all the slave transmitters sharing the PC receive bus. > > Is the PC not a processor? Sure, the PC is a processor. It sends a command to the USB device, saying "send these N bytes of data out on the UART ...". The USB device is /not/ a processor - it is a converter between USB and UART. And it is the USB device that controls the transmit enable signal to the RS-485/RS-422 driver. There is no software on any processor handling the transmit enable signal - the driver is enabled precisely when the USB to UART device is sending data on the UART. > > The slaves have no USB. > > >> I'm getting the impression that you have never heard of such a UART >> (either in a USB-to-UART device, or as a UART peripheral elsewhere), and >> assume software has to be involved in enabling and disabling the >> transmitter. Please believe me when I say such UARTs /do/ exist - and >> the FTDI examples I keep giving are a case in point. > > You are not being clear. I don't know and don't care what is inside the FTDI device. That's just magic to me, or it's like something inside the black hole, unknowable. More importantly, there is no transmitter enable on the RS-422 driver in the FTDI device, because it's not tristateable. > As I mentioned earlier, this thread is getting seriously mixed-up. The transmit enable discussion started with /RS-485/ - long before you decided to use a hybrid bus and a RS-422 cable. You were concerned about how the PC controlled the transmitter enable for the RS-485 driver, and I have been trying to explain how this works when you use a decent UART device. You only confuse yourself when you jump to discussing RS-422 here, in this bit of the conversation. The FTDI USB to UART chip (or chips - they have several) provides a "transmitter enable" signal that is active with exactly the right timing for RS-485. This is provided automatically, in hardware - no software involved. If you connect one of these chips to an RS-485 driver, you immediately have a "perfect" RS-485 interface with automatic direction control. If you connect one of these chips to an RS-422 driver, you don't need direction control as RS-422 has two fixed-direction pairs. If you buy a pre-built cable from FTDI, it will have one of these driver chips connected appropriately. > >>> The timing issue is not about loading another character into the transmit FIFO. It's about controlling the driver enable. >>> >> Yes, and it is a /solved/ issue if you pick the right hardware. >>> >>>> If you have a 9600 baud RS-485 receiver and you have a delay of 10 µs >>>> between reception of the last bit and the start of transmission of the >>>> next message, your code is wrong - by nearly two orders of magnitude. >>>> It is that simple. >>>> >>>> If we take Modbus RTU as an example, you should be waiting 3.5 * 10 / >>>> 9600 seconds at a minimum - 3.65 /milli/seconds. If you are concerned >>>> about exactly where the receive interrupt comes in the last stop bit, >>>> add another half bit time and you get 3.7 ms. The half bit time is >>>> negligible. >>> >>> Your numbers are only relevant to Modbus. The only requirement is that no two drivers are on the bus at the same time, which requires zero delay from the end of the previous stop bit and the beginning of the next start bit. This is why the timing indication from the UART needs to be the end of the stop bit, not the middle. >>> >> A single transmitter, while sending a multi-character message, does not >> need any delay between sending the full stop bit and starting the next >> start bit. That is obvious. And that is why a "transmission complete" >> signal comes at the end of the start bit sent on the transmitter side. > > ??? Are you talking about the buffer management signals for the software? > No. > >> On the receiver side, the "byte received" signal comes in the /middle/ >> of the stop bit, as seen by the receiver, because that could be at the >> /end/ of the stop bit as seen by the transmitter due to clock >> differences. (It could also be at the /start/ of the stop bit as seen >> by the transmitter.) The receiver has to prepare for the next incoming >> start bit as soon as it identifies the stop bit. > > Again, this depends entirely on what this signal is used for. For entering the state of detecting the next start bit, yes, that is the perceived middle of the stop bit. > Yes. > >> But you want an extra delay of at least 11 bits (a character frame plus >> a buffer for clock speed differences) between messages - whether they >> are from the same transmitter or a different transmitter - to allow >> resynchronisation if something has gone wrong. > > Again, you seem to not understand the use case. Yes, I understand your new use case, as well as the original discussions and the side discussions. I don't think /you/ understand that there had been a change, because you seem to imagine everything in the thread is in reference to your current solution. > The split bus never has messages back to back on the same pair. It gets confusing because so many people have tried to talk up RS-485 using a single pair. In that case, everything is totally different. Slaves need to wait until the driver has stopped driving the bus, which means an additional bit time to account for timing errors. But RS-485 is not being used. Each bus is simplex, implementing a half-duplex protocol on the two buses. > I agree. I know how your solution works, and have said many times that I think it sounds quite a good idea for the task in hand. > >> I've explained in other posts why inter-message pauses are needed for >> reliable UART communication protocols. They don't /need/ to be as long >> as 35 bit times as Modbus specifies - 11 bit times is the minimum. If >> you don't understand this by now, then we should drop this point. > > You are assuming a need for error tolerance. But a munged message is the problem, not resyncing. A protocol to detect an error and retransmit is very messy. I've tried that before and it messes up the protocol badly. > All communications have failures. Accept that as a principle, and understand how to deal with it. It's not hard to do - it is certainly much easier than trying to imagine and eliminate any possible cause of trouble. > >>>> So put in a delay. An /appropriate/ delay. >>> >>> You are thinking software, like most people do. >> It doesn't matter whether things are software, hardware, or something in >> between. > > Of course it does. Since the slaves are all logic, there is no need for delays, at all. The slave driver can be enabled at any time the message has been received and the reply is ready to go. > I'm sorry you don't understand, and I can't see how to explain it better than to say timing and delays are fundamental to the communication, not the implementation. > >>> The slaves will be in logic, so the UART will have timing information relevant to the end of bits. I don't care how the master does it. The FTDI cable is alleged to "just work". Nonetheless, I will be providing for separate send and receive buses (or call it master/slave buses). Only one slave will be addressed at a time, so no collisions there, and the master can't collide with itself. >>> >> Yes, with the bus you have described, and the command/response protocol >> you have described, there should be no problems with multiple >> transmitters on the bus, and you have plenty of inter-message idle periods. >> >> However, this Usenet thread has been mixing posts from different people, >> and discussions of different kinds of buses and protocols - not just the >> solution you picked (which, as I have said before, should work fine). I >> think this mixing means that people are sometimes talking at cross-purposes. > > Yes, it gets confusing. > There has, I think, been some interesting discussion despite the confusion. I hope you have got something out of it too - and I am glad that you have a bus solution that looks like it will work well for the purpose. > >>>> If you are pushing the limits of a bus, in terms of load, distance, >>>> speed, cable characteristics, etc., then you need to do such >>>> calculations carefully and be precise in your specification of >>>> components, cables, topology, connectors, etc. For many buses in >>>> practice, they will work fine using whatever resistor you pull out your >>>> box of random parts. For a testbench, you are going to go for something >>>> between these extremes. >>> >>> How long is a piece of string? By keeping the interconnecting cables short, 4" or so, and a 5 foot cable from the PC, I don't expect problems with reflections. But it is prudent to allow for them anyway. The FTDI RS-422 cable seems to have a terminator on the receiver, but not the driver and no provision to add a terminator to the driver. >>> >> There is no point in having a terminator at a driver (unless you are >> talking about very high speed signals with serial resistors for slope >> control). You will want to add a terminator at the far end of both >> buses. This will give you a single terminator on the PC-to-slave bus, >> which is fine as it is fixed direction, and two terminators on the >> slave-to-PC bus, which is appropriate as it has no fixed direction. > > It does if you are using it in a shared bus with multiple drivers. The line should still be organized as linear with minimal stubs and a terminator on each end. This is not my plan, so maybe I should stop discussing it. > Ideally, a bus should be (as you say) linear with minimal stubs and a terminator at each end - /except/ if one end is always driven. There is no point in having a terminator at a driver. Think about it in terms of impedance - the driver is either driving a line high, or it is driving it low. At any given time, one of the differential pair lines will have almost 0 ohm resistance to 0V, and the other will have nearly 0 ohm resistance to 5V. When the signal changes, these swap. Connecting a 100 ohm resistor across the lines at that point will make no difference whatsoever. The terminator is completely useless - it's just a waste of power. At the other end of the cable it's a different matter - there's a cable full of resistance, capacitance and inductance between the terminator and the near 0 ohm driver, so the terminator resistor /does/ make a difference. In more sophisticated tristate drivers, you would off (disconnect) the local terminator whenever the driver is enabled. This is done in some multi-lane systems as it can significantly reduce power and make slope control and pulse shaping easier. (It's not something you'd be likely to see on RS-485 buses.) > >> (I agree that your piece of string is of a size that should work fine >> without reflections being a concern.) >>> Oddly enough, the RS-485 cable has a terminator that can be connected by the user, but that would be running through the cable separately from the transceiver signals, so essentially stubbed! I guess at 1 Mbps, 5 feet is less than the rise time, so not an issue. Since the interconnections between cards will be about five feet as well, it's unlikely to be an issue. The entire network will look like a lumped load, with the propagation time on the order of the rise/fall time. Even adding in a second chassis, makes the round trip twice the typical rise/fall time and unlikely to create any issues. >>> >>> They sell cables that have 5 m of cable, with a round trip of 30 ns or so. I think that would still not be significant in this application. The driver rise/fall times are 15 ns typ, 25 ns max. >>> >> The speed of a signal in a copper cable is typically about 70% of the >> speed of light, giving a minimum round-trip time closer to 45 ns than 30 >> ns. Not that it makes any difference here. > > The problem I have now is finding parts to use for this. These devices seem to be in a catagory that are hit hard by the shortage. My product uses the SN65C1168EPW, which is very hard to find in quantity. My customer has mentioned 18,000 units next year. I may need to get with the factory and see if they can supply me directly. > Unfortunately, sourcing components these days is a much harder problem than designing the systems.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-05 13:42 -0700 |
| Message-ID | <608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com> |
| In reply to | #31350 |
On Saturday, November 5, 2022 at 2:57:30 PM UTC-4, David Brown wrote: > On 05/11/2022 18:23, Rick C wrote: > > On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote: > >> On 04/11/2022 16:40, Rick C wrote: > >>> On Friday, November 4, 2022 at 5:49:42 AM UTC-4, David Brown wrote: > >>>> I made no such assumptions about timings. The figures I gave were for > >>>> using a USB 2 based interface on a PC, where the USB polling timer is at > >>>> 8 kHz, or 125 µs. That is half a bit time for 4 Kbaud. (I had doubled > >>>> the frequency instead of halving it and said the baud had to be above 16 > >>>> kBaud - that shows it's good to do your own calculations and not trust > >>>> others blindly!). At 1 MBaud (the suggested rate), the absolute fastest > >>>> the PC could turn around the bus would be 12 character times - half a > >>>> stop bit is irrelevant. > >>> > >>> You are making an assumption of implementation. There is a processor in the USB cable that is implementing the UART. The driver enable control is most likely is implemented there. It would be pointless and very subject to failure, to require the main CPU to handle this timing. There's no reason to expect the driver disable to take more than a fraction of a bit time, so the "UART" needs a timing signal to indicate when the stop bit has been completed. > >>> > >> I'm making the assumption that you are using appropriate hardware. No > >> processor, just a USB device that has a "transmitter enable" signal on > >> its UART. > > > > How can there not be a processor? I'm using a split bus, with the PC master driving all the slave receivers and all the slave transmitters sharing the PC receive bus. > > > > Is the PC not a processor? > Sure, the PC is a processor. It sends a command to the USB device, > saying "send these N bytes of data out on the UART ...". > > The USB device is /not/ a processor - it is a converter between USB and > UART. And it is the USB device that controls the transmit enable signal > to the RS-485/RS-422 driver. There is no software on any processor > handling the transmit enable signal - the driver is enabled precisely > when the USB to UART device is sending data on the UART. Actually, the FTDI device is a processor. I expect it actually has no UART, rather the entire thing is done in software. I recall there being code to download for various purposes, such as JTAG, but I forget the details. I'm pretty sure the TxEn is controlled by FTDI software. > > The slaves have no USB. > > > > > >> I'm getting the impression that you have never heard of such a UART > >> (either in a USB-to-UART device, or as a UART peripheral elsewhere), and > >> assume software has to be involved in enabling and disabling the > >> transmitter. Please believe me when I say such UARTs /do/ exist - and > >> the FTDI examples I keep giving are a case in point. > > > > You are not being clear. I don't know and don't care what is inside the FTDI device. That's just magic to me, or it's like something inside the black hole, unknowable. More importantly, there is no transmitter enable on the RS-422 driver in the FTDI device, because it's not tristateable. > > > As I mentioned earlier, this thread is getting seriously mixed-up. The > transmit enable discussion started with /RS-485/ - long before you > decided to use a hybrid bus and a RS-422 cable. You were concerned > about how the PC controlled the transmitter enable for the RS-485 > driver, and I have been trying to explain how this works when you use a > decent UART device. You only confuse yourself when you jump to > discussing RS-422 here, in this bit of the conversation. Ok, I'll stop talking about what I am doing. > The FTDI USB to UART chip (or chips - they have several) provides a > "transmitter enable" signal that is active with exactly the right timing > for RS-485. This is provided automatically, in hardware - no software > involved. If you connect one of these chips to an RS-485 driver, you > immediately have a "perfect" RS-485 interface with automatic direction > control. If you connect one of these chips to an RS-422 driver, you > don't need direction control as RS-422 has two fixed-direction pairs. > If you buy a pre-built cable from FTDI, it will have one of these driver > chips connected appropriately. Ok, thanks. > >>> The timing issue is not about loading another character into the transmit FIFO. It's about controlling the driver enable. > >>> > >> Yes, and it is a /solved/ issue if you pick the right hardware. > >>> > >>>> If you have a 9600 baud RS-485 receiver and you have a delay of 10 µs > >>>> between reception of the last bit and the start of transmission of the > >>>> next message, your code is wrong - by nearly two orders of magnitude. > >>>> It is that simple. > >>>> > >>>> If we take Modbus RTU as an example, you should be waiting 3.5 * 10 / > >>>> 9600 seconds at a minimum - 3.65 /milli/seconds. If you are concerned > >>>> about exactly where the receive interrupt comes in the last stop bit, > >>>> add another half bit time and you get 3.7 ms. The half bit time is > >>>> negligible. > >>> > >>> Your numbers are only relevant to Modbus. The only requirement is that no two drivers are on the bus at the same time, which requires zero delay from the end of the previous stop bit and the beginning of the next start bit. This is why the timing indication from the UART needs to be the end of the stop bit, not the middle. > >>> > >> A single transmitter, while sending a multi-character message, does not > >> need any delay between sending the full stop bit and starting the next > >> start bit. That is obvious. And that is why a "transmission complete" > >> signal comes at the end of the start bit sent on the transmitter side. > > > > ??? Are you talking about the buffer management signals for the software? > > > No. > > > >> On the receiver side, the "byte received" signal comes in the /middle/ > >> of the stop bit, as seen by the receiver, because that could be at the > >> /end/ of the stop bit as seen by the transmitter due to clock > >> differences. (It could also be at the /start/ of the stop bit as seen > >> by the transmitter.) The receiver has to prepare for the next incoming > >> start bit as soon as it identifies the stop bit. > > > > Again, this depends entirely on what this signal is used for. For entering the state of detecting the next start bit, yes, that is the perceived middle of the stop bit. > > > Yes. > > > >> But you want an extra delay of at least 11 bits (a character frame plus > >> a buffer for clock speed differences) between messages - whether they > >> are from the same transmitter or a different transmitter - to allow > >> resynchronisation if something has gone wrong. > > > > Again, you seem to not understand the use case. > Yes, I understand your new use case, as well as the original discussions > and the side discussions. I don't think /you/ understand that there had > been a change, because you seem to imagine everything in the thread is > in reference to your current solution. > > The split bus never has messages back to back on the same pair. It gets confusing because so many people have tried to talk up RS-485 using a single pair. In that case, everything is totally different. Slaves need to wait until the driver has stopped driving the bus, which means an additional bit time to account for timing errors. But RS-485 is not being used. Each bus is simplex, implementing a half-duplex protocol on the two buses. > > > I agree. I know how your solution works, and have said many times that > I think it sounds quite a good idea for the task in hand. Ok, then the conversation has reached an end. > >> I've explained in other posts why inter-message pauses are needed for > >> reliable UART communication protocols. They don't /need/ to be as long > >> as 35 bit times as Modbus specifies - 11 bit times is the minimum. If > >> you don't understand this by now, then we should drop this point. > > > > You are assuming a need for error tolerance. But a munged message is the problem, not resyncing. A protocol to detect an error and retransmit is very messy. I've tried that before and it messes up the protocol badly. > > > All communications have failures. Accept that as a principle, and > understand how to deal with it. It's not hard to do - it is certainly > much easier than trying to imagine and eliminate any possible cause of > trouble. That's not a premise I have to deal with. I will also die. I'm not factoring that into the project either. I don't need to eliminate "any possible cause of trouble". I only have to reach an effective level of reliability. As I've said, error handling protocols are complex and subject to failure. It's much more likely I will have more trouble with the error handling protocol than I will with bit errors on the bus. So I choose the most reliable solution, no error handling. So without an error handling protocol in the software, I don't need to do anything further to deal with errors. > >>>> So put in a delay. An /appropriate/ delay. > >>> > >>> You are thinking software, like most people do. > >> It doesn't matter whether things are software, hardware, or something in > >> between. > > > > Of course it does. Since the slaves are all logic, there is no need for delays, at all. The slave driver can be enabled at any time the message has been received and the reply is ready to go. > > > I'm sorry you don't understand, and I can't see how to explain it better > than to say timing and delays are fundamental to the communication, not > the implementation. I understand perfectly. I only need to meet the requirements of this project. Not the requirements of some ultra high reliability project. With the RS-422 interface, I expect I could run the entire system continuously, and would not find an error in my lifetime. That's good enough for me. > >>> The slaves will be in logic, so the UART will have timing information relevant to the end of bits. I don't care how the master does it. The FTDI cable is alleged to "just work". Nonetheless, I will be providing for separate send and receive buses (or call it master/slave buses). Only one slave will be addressed at a time, so no collisions there, and the master can't collide with itself. > >>> > >> Yes, with the bus you have described, and the command/response protocol > >> you have described, there should be no problems with multiple > >> transmitters on the bus, and you have plenty of inter-message idle periods. > >> > >> However, this Usenet thread has been mixing posts from different people, > >> and discussions of different kinds of buses and protocols - not just the > >> solution you picked (which, as I have said before, should work fine). I > >> think this mixing means that people are sometimes talking at cross-purposes. > > > > Yes, it gets confusing. > > > There has, I think, been some interesting discussion despite the > confusion. I hope you have got something out of it too - and I am glad > that you have a bus solution that looks like it will work well for the > purpose. > > > >>>> If you are pushing the limits of a bus, in terms of load, distance, > >>>> speed, cable characteristics, etc., then you need to do such > >>>> calculations carefully and be precise in your specification of > >>>> components, cables, topology, connectors, etc. For many buses in > >>>> practice, they will work fine using whatever resistor you pull out your > >>>> box of random parts. For a testbench, you are going to go for something > >>>> between these extremes. > >>> > >>> How long is a piece of string? By keeping the interconnecting cables short, 4" or so, and a 5 foot cable from the PC, I don't expect problems with reflections. But it is prudent to allow for them anyway. The FTDI RS-422 cable seems to have a terminator on the receiver, but not the driver and no provision to add a terminator to the driver. > >>> > >> There is no point in having a terminator at a driver (unless you are > >> talking about very high speed signals with serial resistors for slope > >> control). You will want to add a terminator at the far end of both > >> buses. This will give you a single terminator on the PC-to-slave bus, > >> which is fine as it is fixed direction, and two terminators on the > >> slave-to-PC bus, which is appropriate as it has no fixed direction. > > > > It does if you are using it in a shared bus with multiple drivers. The line should still be organized as linear with minimal stubs and a terminator on each end. This is not my plan, so maybe I should stop discussing it. > > > Ideally, a bus should be (as you say) linear with minimal stubs and a > terminator at each end - /except/ if one end is always driven. There is > no point in having a terminator at a driver. Think about it in terms of > impedance - the driver is either driving a line high, or it is driving > it low. At any given time, one of the differential pair lines will have > almost 0 ohm resistance to 0V, and the other will have nearly 0 ohm > resistance to 5V. When the signal changes, these swap. Connecting a > 100 ohm resistor across the lines at that point will make no difference > whatsoever. The terminator is completely useless - it's just a waste of > power. At the other end of the cable it's a different matter - there's > a cable full of resistance, capacitance and inductance between the > terminator and the near 0 ohm driver, so the terminator resistor /does/ > make a difference. > > In more sophisticated tristate drivers, you would off (disconnect) the > local terminator whenever the driver is enabled. This is done in some > multi-lane systems as it can significantly reduce power and make slope > control and pulse shaping easier. (It's not something you'd be likely > to see on RS-485 buses.) > > > >> (I agree that your piece of string is of a size that should work fine > >> without reflections being a concern.) > >>> Oddly enough, the RS-485 cable has a terminator that can be connected by the user, but that would be running through the cable separately from the transceiver signals, so essentially stubbed! I guess at 1 Mbps, 5 feet is less than the rise time, so not an issue. Since the interconnections between cards will be about five feet as well, it's unlikely to be an issue. The entire network will look like a lumped load, with the propagation time on the order of the rise/fall time. Even adding in a second chassis, makes the round trip twice the typical rise/fall time and unlikely to create any issues. > >>> > >>> They sell cables that have 5 m of cable, with a round trip of 30 ns or so. I think that would still not be significant in this application. The driver rise/fall times are 15 ns typ, 25 ns max. > >>> > >> The speed of a signal in a copper cable is typically about 70% of the > >> speed of light, giving a minimum round-trip time closer to 45 ns than 30 > >> ns. Not that it makes any difference here. > > > > The problem I have now is finding parts to use for this. These devices seem to be in a catagory that are hit hard by the shortage. My product uses the SN65C1168EPW, which is very hard to find in quantity. My customer has mentioned 18,000 units next year. I may need to get with the factory and see if they can supply me directly. > > > Unfortunately, sourcing components these days is a much harder problem > than designing the systems. Indeed. -- Rick C. -+-- Get 1,000 miles of free Supercharging -+-- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web