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 1 of 5 [1] 2 3 4 5 Next page →
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-01 22:28 -0700 |
| Subject | Shared Communications Bus - RS-422 or RS-485 |
| Message-ID | <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com> |
I have a test fixture that uses RS-232 to communicate with a PC. It actually uses the voltage levels of RS-232, even though this is from a USB cable on the PC, so it's only RS-232 for maybe four inches. lol I'm redesigning the test fixtures to hold more units and fully automate a few features that presently requires an operator. There will now be 8 UUTs on each test fixture and I expect to have 10 to 20 test fixtures in a card rack. That's 80 to 160 UUTs total. There will be an FPGA controlling each pair of UUTs, so 80 FPGAs in total that the PC needs to talk to. Rather than working on a way to mux 80 RS-232 interfaces, I'm thinking it would be better to either daisy chain, or connect in parallel all these devices. The protocol is master-slave where the master sends a command and the slaves are idle until they reply. The four FPGAs on a test fixture board could be connected in parallel easily enough. But I don't think I want to run TTL level signals between so many boards. I could do an RS-422 interface with a master to slave pair and a slave to master pair. The slaves do not speak until spoken to, so there will be no collisions. RS-485 would allow all this to be over a single pair of wires. But the one big issue I see people complain about is getting PC software to not clobber the slaves, or I should say, to get the master to wait long enough that it's not clobbering it's own start bit by overwriting the stop bit of the slave. I suppose someone, somewhere has dealt with this on the PC and has a solution that doesn't impact bus speed. I run the single test fixture version of this at about 100 kbps. I'm going to want as much speed as I can get for 80 FPGAs controlling 160 UUTs. Maybe I should give that some analysis, because this might not be true. The tests are of two types, most of them are setting up a state and reading a signal. This can go pretty fast and doesn't take too many commands. Then there are the audio tests where the FPGA sends digital data to the UUT, which does it's thing and returns digital data which is crunched by the FPGA. This takes some small number of seconds and presently the protocol is to poll the status until it is done. That's a lot of messages, but it's not necessarily a slow point. The same test can be started on every UUT in parallel, so the waiting is in parallel. So maybe the serial port won't need to be any faster. Still, I want to use RS-422 or RS-485 to deal with ground noise since this will be spread over multiple boards that don't have terribly solid grounds, just the power cable really. I'm thinking out loud here as much as anything. I intended to simply ask if anyone had experience with RS-485 that would be helpful. Running two wires rather than eight would be a help. I'll probably use a 10 pin connector just to be on the safe side, allowing the transceivers to be used either way. -- Rick C. - Get 1,000 miles of free Supercharging - Tesla referral code - https://ts.la/richard11209
[toc] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-02 10:28 +0100 |
| Message-ID | <tjtd7g$145er$1@dont-email.me> |
| In reply to | #31284 |
On 02/11/2022 06:28, Rick C wrote: > I have a test fixture that uses RS-232 to communicate with a PC. It > actually uses the voltage levels of RS-232, even though this is from > a USB cable on the PC, so it's only RS-232 for maybe four inches. > lol > > I'm redesigning the test fixtures to hold more units and fully > automate a few features that presently requires an operator. There > will now be 8 UUTs on each test fixture and I expect to have 10 to 20 > test fixtures in a card rack. That's 80 to 160 UUTs total. There > will be an FPGA controlling each pair of UUTs, so 80 FPGAs in total > that the PC needs to talk to. > > Rather than working on a way to mux 80 RS-232 interfaces, I'm > thinking it would be better to either daisy chain, or connect in > parallel all these devices. The protocol is master-slave where the > master sends a command and the slaves are idle until they reply. The > four FPGAs on a test fixture board could be connected in parallel > easily enough. But I don't think I want to run TTL level signals > between so many boards. > > I could do an RS-422 interface with a master to slave pair and a > slave to master pair. The slaves do not speak until spoken to, so > there will be no collisions. > RS-422 is normally a point-to-point interface. It is one line in each direction, but using balanced pairs instead of a TTL signal. You would not normally connect multiple receivers or transmitters to an RS-422 bus, as the standard practice is that each transmitter is always driving the pair it is attached to - there is no multi-drop. > RS-485 would allow all this to be over a single pair of wires. But > the one big issue I see people complain about is getting PC software > to not clobber the slaves, or I should say, to get the master to wait > long enough that it's not clobbering it's own start bit by > overwriting the stop bit of the slave. I suppose someone, somewhere > has dealt with this on the PC and has a solution that doesn't impact > bus speed. I run the single test fixture version of this at about > 100 kbps. I'm going to want as much speed as I can get for 80 FPGAs > controlling 160 UUTs. Maybe I should give that some analysis, > because this might not be true. RS-485 is easy from a PC using appropriate USB devices. We make heavy use of FTDI's chips and cables - they handle the drive enables for the RS-485 automatically so that from the PC side you just read and write to the serial port. The reception of the last byte from a slave is not finished until the stop bit has been properly received by the master - that means at least half-way through the sending of the stop bit. Then there is a delay before the data gets sent back to the host PC, a delay through the kernel and drivers before it reaches the user program, time for the program to handle that message, time for it to prepare the next message, delays through the kernel and drivers before it gets to the USB bus, latency in the USB device that receives the USB message and then starts transmitting. There can be no collision unless all that delay is less than half a bit time. And no matter how fast your computer is, you are always going to need at least one full USB polling cycle for all this, which for USB 2.0 is 0.125 us. That means that if you have a baud rate of 16 kbaud or higher, there is no possibility of a collision. > > The tests are of two types, most of them are setting up a state and > reading a signal. This can go pretty fast and doesn't take too many > commands. Then there are the audio tests where the FPGA sends > digital data to the UUT, which does it's thing and returns digital > data which is crunched by the FPGA. This takes some small number of > seconds and presently the protocol is to poll the status until it is > done. That's a lot of messages, but it's not necessarily a slow > point. The same test can be started on every UUT in parallel, so the > waiting is in parallel. So maybe the serial port won't need to be > any faster. > > Still, I want to use RS-422 or RS-485 to deal with ground noise since > this will be spread over multiple boards that don't have terribly > solid grounds, just the power cable really. > > I'm thinking out loud here as much as anything. I intended to simply > ask if anyone had experience with RS-485 that would be helpful. > Running two wires rather than eight would be a help. I'll probably > use a 10 pin connector just to be on the safe side, allowing the > transceivers to be used either way. > You need to do some calculations to see if you can get enough telegrams and enough data through a single serial port. You'll be hard pushed to find a USB serial port device of any kind that goes above 3 Mbaud, and you need to be careful about your selection of RS-485 drivers for those kinds of rates. You will also find that much of your bandwidth is taken up with pauses between telegrams and reply latency, unless you make your telegrams quite large. When we have made testbenches that required serial communication to multiple parallel devices, we typically put a USB hub in the testbench and use multiple FDTI USB to serial cables. You only make one (or possibly a few) of the testbenches - it's much cheaper to use off-the-shelf parts than to spend time designing something more advanced. You can buy a /lot/ of hubs and USB cables for the price of the time to design, build and program a custom card for the job. It also makes the system more scalable, as the communication to different devices runs in parallel. We have also done systems where there is a Raspberry Pi driving the hub and multiple FTDI converters. The PC is connected to the Pi by Ethernet (useful for galvanic isolation), and the Pi runs forwarders between the serial ports and TCP/IP ports. To be fair, I don't recall any testbenches we've made that needed more than perhaps 8 serial ports. If I needed to handle 80 lines, I would probably split things up - a Pi handling 8-10 lines from a local program, communicating with a PC master program by Ethernet.
[toc] | [prev] | [next] | [standalone]
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Date | 2022-11-02 11:54 +0100 |
| Message-ID | <tjti8a$129ep$1@dont-email.me> |
| In reply to | #31288 |
Il 02/11/2022 10:28, David Brown ha scritto: > On 02/11/2022 06:28, Rick C wrote: > RS-485 is easy from a PC using appropriate USB devices. We make heavy > use of FTDI's chips and cables - they handle the drive enables for the > RS-485 automatically so that from the PC side you just read and write to > the serial port. > > The reception of the last byte from a slave is not finished until the > stop bit has been properly received by the master - that means at least > half-way through the sending of the stop bit. Then there is a delay > before the data gets sent back to the host PC, a delay through the > kernel and drivers before it reaches the user program, time for the > program to handle that message, time for it to prepare the next message, > delays through the kernel and drivers before it gets to the USB bus, > latency in the USB device that receives the USB message and then starts > transmitting. There can be no collision unless all that delay is less > than half a bit time. And no matter how fast your computer is, you are > always going to need at least one full USB polling cycle for all this, > which for USB 2.0 is 0.125 us. That means that if you have a baud rate > of 16 kbaud or higher, there is no possibility of a collision. However this depends on the speed of slave too, because it could be slow to move *its* direction from TX to RX. If the master starts transmitting after the stop bit from the slave, but *before* it changes *its* direction from TX to RX, the first bytes could be corrupted. Unfortunately, not all UARTs in MCUs are able to drive automatically the DE (Drive Enable) signal, so it sometimes happens that DE is a normal GPIO. If you are lucky, you have the TXC (transmit complete) interrupt that fires *after* stop bit is transmitted, a safe time to move DE signal. In this case interrupt delay is short, but you could have other active interrupts that occasionally could delay the TXC interrupt for some time.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-02 14:27 +0100 |
| Message-ID | <tjtr7f$16c7a$1@dont-email.me> |
| In reply to | #31289 |
On 02/11/2022 11:54, pozz wrote: > Il 02/11/2022 10:28, David Brown ha scritto: >> On 02/11/2022 06:28, Rick C wrote: > >> RS-485 is easy from a PC using appropriate USB devices. We make heavy >> use of FTDI's chips and cables - they handle the drive enables for the >> RS-485 automatically so that from the PC side you just read and write >> to the serial port. >> >> The reception of the last byte from a slave is not finished until the >> stop bit has been properly received by the master - that means at >> least half-way through the sending of the stop bit. Then there is a >> delay before the data gets sent back to the host PC, a delay through >> the kernel and drivers before it reaches the user program, time for >> the program to handle that message, time for it to prepare the next >> message, delays through the kernel and drivers before it gets to the >> USB bus, latency in the USB device that receives the USB message and >> then starts transmitting. There can be no collision unless all that >> delay is less than half a bit time. And no matter how fast your >> computer is, you are always going to need at least one full USB >> polling cycle for all this, which for USB 2.0 is 0.125 us. That means >> that if you have a baud rate of 16 kbaud or higher, there is no >> possibility of a collision. > > However this depends on the speed of slave too, because it could be slow > to move *its* direction from TX to RX. If the master starts transmitting > after the stop bit from the slave, but *before* it changes *its* > direction from TX to RX, the first bytes could be corrupted. True, and it that is an important point. > > Unfortunately, not all UARTs in MCUs are able to drive automatically the > DE (Drive Enable) signal, so it sometimes happens that DE is a normal GPIO. > If you are lucky, you have the TXC (transmit complete) interrupt that > fires *after* stop bit is transmitted, a safe time to move DE signal. I think the OP has FPGA's for the slave side of the equation, so there should not be a delay in switching their drivers off after the last byte is sent. Even if it is a microcontroller and has no hardware control for the DE line, pretty much any half-decent microcontroller from this century has a TXC interrupt and can react and turn off the driver within a few microseconds. I am assuming he is not trying to do this project using PIC's or 8051's ! > > In this case interrupt delay is short, but you could have other active > interrupts that occasionally could delay the TXC interrupt for some time. > If this kind of thing is a risk, then it's not hard to put a short delay on the PC side between receiving a reply and sending out the next telegram. But it's good that you brought it up, so that the OP can decide if it /is/ a risk.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-02 12:20 -0700 |
| Message-ID | <b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com> |
| In reply to | #31288 |
On Wednesday, November 2, 2022 at 5:28:21 AM UTC-4, David Brown wrote: > On 02/11/2022 06:28, Rick C wrote: > > I have a test fixture that uses RS-232 to communicate with a PC. It > > actually uses the voltage levels of RS-232, even though this is from > > a USB cable on the PC, so it's only RS-232 for maybe four inches. > > lol > > > > I'm redesigning the test fixtures to hold more units and fully > > automate a few features that presently requires an operator. There > > will now be 8 UUTs on each test fixture and I expect to have 10 to 20 > > test fixtures in a card rack. That's 80 to 160 UUTs total. There > > will be an FPGA controlling each pair of UUTs, so 80 FPGAs in total > > that the PC needs to talk to. > > > > Rather than working on a way to mux 80 RS-232 interfaces, I'm > > thinking it would be better to either daisy chain, or connect in > > parallel all these devices. The protocol is master-slave where the > > master sends a command and the slaves are idle until they reply. The > > four FPGAs on a test fixture board could be connected in parallel > > easily enough. But I don't think I want to run TTL level signals > > between so many boards. > > > > I could do an RS-422 interface with a master to slave pair and a > > slave to master pair. The slaves do not speak until spoken to, so > > there will be no collisions. > > > RS-422 is normally a point-to-point interface. It is one line in each > direction, but using balanced pairs instead of a TTL signal. You would > not normally connect multiple receivers or transmitters to an RS-422 > bus, as the standard practice is that each transmitter is always driving > the pair it is attached to - there is no multi-drop. That is simply not true. Data sheets for RS-422 devices often show multidrop applications and how to best terminate them. > > RS-485 would allow all this to be over a single pair of wires. But > > the one big issue I see people complain about is getting PC software > > to not clobber the slaves, or I should say, to get the master to wait > > long enough that it's not clobbering it's own start bit by > > overwriting the stop bit of the slave. I suppose someone, somewhere > > has dealt with this on the PC and has a solution that doesn't impact > > bus speed. I run the single test fixture version of this at about > > 100 kbps. I'm going to want as much speed as I can get for 80 FPGAs > > controlling 160 UUTs. Maybe I should give that some analysis, > > because this might not be true. > RS-485 is easy from a PC using appropriate USB devices. We make heavy > use of FTDI's chips and cables - they handle the drive enables for the > RS-485 automatically so that from the PC side you just read and write to > the serial port. I've yet to be convinced of this. Admittedly, my last interaction with RS-485 was many years ago, but there were some four or five different devices being integrated with a PC, and no two of them handled it the bus the same way. The PC in particular, would cut on and off the driver in the middle of bits. No one put a bias on the bus, so it was indeterminate when no one was driving. It was a horrible failure. Every time I've seen this discussed, the driver control has been an issue. > The reception of the last byte from a slave is not finished until the > stop bit has been properly received by the master - that means at least > half-way through the sending of the stop bit. That's not sufficient. Everyone's halfway is a bit different and start bit detection may not be enabled on some device when the next driver outputs a start bit, or the last driver may not be turned off when the next driver starts. > Then there is a delay > before the data gets sent back to the host PC, a delay through the > kernel and drivers before it reaches the user program, time for the > program to handle that message, time for it to prepare the next message, > delays through the kernel and drivers before it gets to the USB bus, > latency in the USB device that receives the USB message and then starts > transmitting. There can be no collision unless all that delay is less > than half a bit time. And no matter how fast your computer is, you are > always going to need at least one full USB polling cycle for all this, > which for USB 2.0 is 0.125 us. That means that if you have a baud rate > of 16 kbaud or higher, there is no possibility of a collision. If your numbers are accurate, that might be ok, but I'm looking for data rates closer to 1 Mbps. Admittedly, I have not done an analysis of what will actually be required, but 128 UUT, or possibly 256, can do a lot of damage to a shared bus. At 1 Mbps, 128 UUT results in an effective bit rate maximum of 7.8 kbps. With 256 UUTs, that's 3.9 kbps. No, I don't think this will work properly at much slower speeds than 1 Mbps. At 16 kbps, the effective rate to each UUT is just 62.5 bps, not kbps. > > The tests are of two types, most of them are setting up a state and > > reading a signal. This can go pretty fast and doesn't take too many > > commands. Then there are the audio tests where the FPGA sends > > digital data to the UUT, which does it's thing and returns digital > > data which is crunched by the FPGA. This takes some small number of > > seconds and presently the protocol is to poll the status until it is > > done. That's a lot of messages, but it's not necessarily a slow > > point. The same test can be started on every UUT in parallel, so the > > waiting is in parallel. So maybe the serial port won't need to be > > any faster. > > > > Still, I want to use RS-422 or RS-485 to deal with ground noise since > > this will be spread over multiple boards that don't have terribly > > solid grounds, just the power cable really. > > > > I'm thinking out loud here as much as anything. I intended to simply > > ask if anyone had experience with RS-485 that would be helpful. > > Running two wires rather than eight would be a help. I'll probably > > use a 10 pin connector just to be on the safe side, allowing the > > transceivers to be used either way. > > > You need to do some calculations to see if you can get enough telegrams > and enough data through a single serial port. You'll be hard pushed to > find a USB serial port device of any kind that goes above 3 Mbaud, and > you need to be careful about your selection of RS-485 drivers for those > kinds of rates. You will also find that much of your bandwidth is taken > up with pauses between telegrams and reply latency, unless you make your > telegrams quite large. I assume by "telegrams", you mean the messages. They will be small by necessity. The protocol is interactive with a command message and a reply message. Read a register, write a register. > When we have made testbenches that required serial communication to > multiple parallel devices, we typically put a USB hub in the testbench > and use multiple FDTI USB to serial cables. You only make one (or > possibly a few) of the testbenches - it's much cheaper to use > off-the-shelf parts than to spend time designing something more > advanced. You can buy a /lot/ of hubs and USB cables for the price of > the time to design, build and program a custom card for the job. It > also makes the system more scalable, as the communication to different > devices runs in parallel. USB hubs are a last resort. I've found many issues with such devices, especially larger than 4 ports. > We have also done systems where there is a Raspberry Pi driving the hub > and multiple FTDI converters. The PC is connected to the Pi by Ethernet > (useful for galvanic isolation), and the Pi runs forwarders between the > serial ports and TCP/IP ports. There is a possibility of using an rPi on an Ethernet cable to the PC with direct comms to each test fixture board, but that's more work that I'm interested in. > To be fair, I don't recall any testbenches we've made that needed more > than perhaps 8 serial ports. If I needed to handle 80 lines, I would > probably split things up - a Pi handling 8-10 lines from a local > program, communicating with a PC master program by Ethernet. That's the advantage of the shared bus. No programming required, other than extending the protocol to move from "selecting" a device on the FPGA, to selecting the FPGA as well. -- 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-02 21:49 +0100 |
| Message-ID | <tjul46$18dkn$3@dont-email.me> |
| In reply to | #31294 |
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: >>> I have a test fixture that uses RS-232 to communicate with a PC. >>> It actually uses the voltage levels of RS-232, even though this >>> is from a USB cable on the PC, so it's only RS-232 for maybe four >>> inches. lol >>> >>> I'm redesigning the test fixtures to hold more units and fully >>> automate a few features that presently requires an operator. >>> There will now be 8 UUTs on each test fixture and I expect to >>> have 10 to 20 test fixtures in a card rack. That's 80 to 160 UUTs >>> total. There will be an FPGA controlling each pair of UUTs, so 80 >>> FPGAs in total that the PC needs to talk to. >>> >>> Rather than working on a way to mux 80 RS-232 interfaces, I'm >>> thinking it would be better to either daisy chain, or connect in >>> parallel all these devices. The protocol is master-slave where >>> the master sends a command and the slaves are idle until they >>> reply. The four FPGAs on a test fixture board could be connected >>> in parallel easily enough. But I don't think I want to run TTL >>> level signals between so many boards. >>> >>> I could do an RS-422 interface with a master to slave pair and a >>> slave to master pair. The slaves do not speak until spoken to, >>> so there will be no collisions. >>> >> RS-422 is normally a point-to-point interface. It is one line in >> each direction, but using balanced pairs instead of a TTL signal. >> You would not normally connect multiple receivers or transmitters >> to an RS-422 bus, as the standard practice is that each transmitter >> is always driving the pair it is attached to - there is no >> multi-drop. > > That is simply not true. Data sheets for RS-422 devices often show > multidrop applications and how to best terminate them. > RS-422 is not multidrop. Occasionally you will see multiple receivers on a bus, but not multiple transmitters. Of course the same driver chips can be used in different combinations of wiring and drive enables. An RS-422 driver chip can be viewed as two RS-485 driver chips - alternatively, a RS-485 driver can be viewed as an RS-422 driver with the two differential pairs connected together. Really, all you are talking about is a differential driver and a differential receiver. So yes, you can do multidrop using an RS-422 driver chip. But it is not RS-422, which is a point-to-point serial bus standard. > >>> RS-485 would allow all this to be over a single pair of wires. >>> But the one big issue I see people complain about is getting PC >>> software to not clobber the slaves, or I should say, to get the >>> master to wait long enough that it's not clobbering it's own >>> start bit by overwriting the stop bit of the slave. I suppose >>> someone, somewhere has dealt with this on the PC and has a >>> solution that doesn't impact bus speed. I run the single test >>> fixture version of this at about 100 kbps. I'm going to want as >>> much speed as I can get for 80 FPGAs controlling 160 UUTs. Maybe >>> I should give that some analysis, because this might not be >>> true. >> RS-485 is easy from a PC using appropriate USB devices. We make >> heavy use of FTDI's chips and cables - they handle the drive >> enables for the RS-485 automatically so that from the PC side you >> just read and write to the serial port. > > I've yet to be convinced of this. Admittedly, my last interaction > with RS-485 was many years ago, but there were some four or five > different devices being integrated with a PC, and no two of them > handled it the bus the same way. The PC in particular, would cut on > and off the driver in the middle of bits. No one put a bias on the > bus, so it was indeterminate when no one was driving. It was a > horrible failure. > > Every time I've seen this discussed, the driver control has been an > issue. I can tell you it works perfectly with FTDI's RS-485 cables - every time, every OS, regardless of the software. Some RS-485 drivers rely on RTS for the drive enable - this was the standard for RS-232 to RS-485 converters from the old days of 9-pin and 25-pin serial ports on PC's. With such drivers, it is certainly possible to get things wrong. With the drive enable handled directly by the UART hardware on the USB chip, it is /far/ harder to get it wrong. I would expect there to be many alternatives to FTDI that work similarly well, but that's the ones we generally use. <https://ftdichip.com/product-category/products/cables/?series_products=55> > >> The reception of the last byte from a slave is not finished until >> the stop bit has been properly received by the master - that means >> at least half-way through the sending of the stop bit. > > That's not sufficient. Everyone's halfway is a bit different and > start bit detection may not be enabled on some device when the next > driver outputs a start bit, or the last driver may not be turned off > when the next driver starts. > "At least half-way" means "at least 50% of the bit time". As long as the start bit from the next message is not sent until at least 50% of a bit time after the stop bit is detected, it will not conflict and all listening devices will be ready to see the start bit. (Devices that needed two stop bits haven't existed in the last 50 years.) You asked specifically about bus turnaround at the host side - I assume that is because on the slave devices, you have control of the drive enables and bus turnaround happens with negligible latency. > >> Then there is a delay before the data gets sent back to the host >> PC, a delay through the kernel and drivers before it reaches the >> user program, time for the program to handle that message, time for >> it to prepare the next message, delays through the kernel and >> drivers before it gets to the USB bus, latency in the USB device >> that receives the USB message and then starts transmitting. There >> can be no collision unless all that delay is less than half a bit >> time. And no matter how fast your computer is, you are always going >> to need at least one full USB polling cycle for all this, which for >> USB 2.0 is 0.125 us. That means that if you have a baud rate of 16 >> kbaud or higher, there is no possibility of a collision. > > If your numbers are accurate, that might be ok, but I'm looking for > data rates closer to 1 Mbps. USB serial ports generally use the 48 MHz base USB reference frequency as their source clock to scale down by a baud rate divisor, and common practice is 16 sub-bit clocks per line bit (so that you can have multiple samples for noise immunity). Thus baud rates of integer divisions of 3 MBaud are common. Certainly the FTDI chips handle 1, 2 and 3 MBaud. (I haven't had need of such speeds with RS-485, but have happily used the common 3v3 TTL cables at 3 MBaud.) > Admittedly, I have not done an analysis > of what will actually be required, but 128 UUT, or possibly 256, can > do a lot of damage to a shared bus. At 1 Mbps, 128 UUT results in an > effective bit rate maximum of 7.8 kbps. With 256 UUTs, that's 3.9 > kbps. No, I don't think this will work properly at much slower > speeds than 1 Mbps. At 16 kbps, the effective rate to each UUT is > just 62.5 bps, not kbps. > As long as you are /above/ 16 kbaud, you should be fine (at the PC side). At 1 Mbaud, you do not need to worry about the PC starting a new telegram before the last received stop bit is completed. > >>> The tests are of two types, most of them are setting up a state >>> and reading a signal. This can go pretty fast and doesn't take >>> too many commands. Then there are the audio tests where the FPGA >>> sends digital data to the UUT, which does it's thing and returns >>> digital data which is crunched by the FPGA. This takes some small >>> number of seconds and presently the protocol is to poll the >>> status until it is done. That's a lot of messages, but it's not >>> necessarily a slow point. The same test can be started on every >>> UUT in parallel, so the waiting is in parallel. So maybe the >>> serial port won't need to be any faster. >>> >>> Still, I want to use RS-422 or RS-485 to deal with ground noise >>> since this will be spread over multiple boards that don't have >>> terribly solid grounds, just the power cable really. >>> >>> I'm thinking out loud here as much as anything. I intended to >>> simply ask if anyone had experience with RS-485 that would be >>> helpful. Running two wires rather than eight would be a help. >>> I'll probably use a 10 pin connector just to be on the safe side, >>> allowing the transceivers to be used either way. >>> >> You need to do some calculations to see if you can get enough >> telegrams and enough data through a single serial port. You'll be >> hard pushed to find a USB serial port device of any kind that goes >> above 3 Mbaud, and you need to be careful about your selection of >> RS-485 drivers for those kinds of rates. You will also find that >> much of your bandwidth is taken up with pauses between telegrams >> and reply latency, unless you make your telegrams quite large. > > I assume by "telegrams", you mean the messages. They will be small > by necessity. The protocol is interactive with a command message and > a reply message. Read a register, write a register. > Telegram, message, packet - whatever term you prefer. At faster baud rates, the inevitable pauses between messages take proportionately more of the total bandwidth. Longer messages will be more efficient. But you'll have to do the sums yourself to see what rates you need, and whether or not this will be an issue. > >> When we have made testbenches that required serial communication >> to multiple parallel devices, we typically put a USB hub in the >> testbench and use multiple FDTI USB to serial cables. You only make >> one (or possibly a few) of the testbenches - it's much cheaper to >> use off-the-shelf parts than to spend time designing something >> more advanced. You can buy a /lot/ of hubs and USB cables for the >> price of the time to design, build and program a custom card for >> the job. It also makes the system more scalable, as the >> communication to different devices runs in parallel. > > USB hubs are a last resort. I've found many issues with such > devices, especially larger than 4 ports. > We find they work fine - I have very rarely seen any issues with off-the-shelf hubs, regardless of the number of ports. (They are almost all made with 1-to-4 hub chips, which is why hubs are often found in sizes of 4 ports, 7 ports, or 10 ports.) A key complication with multiple serial ports on hubs is if you are using Windows, it can be a big pain to keep consistent numbering for the serial ports. You may have to use driver-specific libraries (like FTDI's DLL's) to check serial numbers and use that information. It's far easier on Linux where you can make a udev configuration file that gives aliases to your ports ordered by physical tree address. > >> We have also done systems where there is a Raspberry Pi driving the >> hub and multiple FTDI converters. The PC is connected to the Pi by >> Ethernet (useful for galvanic isolation), and the Pi runs >> forwarders between the serial ports and TCP/IP ports. > > There is a possibility of using an rPi on an Ethernet cable to the PC > with direct comms to each test fixture board, but that's more work > that I'm interested in. > Or you could use one Pi for a set of boards - whatever is physically convenient. > >> To be fair, I don't recall any testbenches we've made that needed >> more than perhaps 8 serial ports. If I needed to handle 80 lines, I >> would probably split things up - a Pi handling 8-10 lines from a >> local program, communicating with a PC master program by Ethernet. > > That's the advantage of the shared bus. No programming required, > other than extending the protocol to move from "selecting" a device > on the FPGA, to selecting the FPGA as well. > If you are familiar with socat, the Pi doesn't necessarily need any programming either. (In our case we wanted some extra monitoring and logging, which was more than we could get from socat - so it was a couple of hundred lines of Python in the end.)
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-02 16:27 -0700 |
| Message-ID | <ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com> |
| In reply to | #31297 |
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: > >>> I have a test fixture that uses RS-232 to communicate with a PC. > >>> It actually uses the voltage levels of RS-232, even though this > >>> is from a USB cable on the PC, so it's only RS-232 for maybe four > >>> inches. lol > >>> > >>> I'm redesigning the test fixtures to hold more units and fully > >>> automate a few features that presently requires an operator. > >>> There will now be 8 UUTs on each test fixture and I expect to > >>> have 10 to 20 test fixtures in a card rack. That's 80 to 160 UUTs > >>> total. There will be an FPGA controlling each pair of UUTs, so 80 > >>> FPGAs in total that the PC needs to talk to. > >>> > >>> Rather than working on a way to mux 80 RS-232 interfaces, I'm > >>> thinking it would be better to either daisy chain, or connect in > >>> parallel all these devices. The protocol is master-slave where > >>> the master sends a command and the slaves are idle until they > >>> reply. The four FPGAs on a test fixture board could be connected > >>> in parallel easily enough. But I don't think I want to run TTL > >>> level signals between so many boards. > >>> > >>> I could do an RS-422 interface with a master to slave pair and a > >>> slave to master pair. The slaves do not speak until spoken to, > >>> so there will be no collisions. > >>> > >> RS-422 is normally a point-to-point interface. It is one line in > >> each direction, but using balanced pairs instead of a TTL signal. > >> You would not normally connect multiple receivers or transmitters > >> to an RS-422 bus, as the standard practice is that each transmitter > >> is always driving the pair it is attached to - there is no > >> multi-drop. > > > > That is simply not true. Data sheets for RS-422 devices often show > > multidrop applications and how to best terminate them. > > > RS-422 is not multidrop. Occasionally you will see multiple receivers > on a bus, but not multiple transmitters. Not sure of your point. Multi-drop is multiple receivers on a single transmitter. Multi-point is multiple drivers and receivers. Look at a few references. Even wikipedia says, "RS-422 provides for data transmission, using balanced, or differential, signaling, with unidirectional/non-reversible, terminated or non-terminated transmission lines, point to point, or multi-drop. In contrast to EIA-485, RS-422/V.11 does not allow multiple drivers but only multiple receivers." > Of course the same driver chips can be used in different combinations of > wiring and drive enables. An RS-422 driver chip can be viewed as two > RS-485 driver chips - alternatively, a RS-485 driver can be viewed as an > RS-422 driver with the two differential pairs connected together. > Really, all you are talking about is a differential driver and a > differential receiver. Sure, but the point is, nothing in RS-422 precludes multiple receivers, and in fact, every reference I've found (not paying for the actual spec) shows multi-drop receivers. > So yes, you can do multidrop using an RS-422 driver chip. But it is not > RS-422, which is a point-to-point serial bus standard. I don't believe that is correct. If you have a copy of the spec to share, I'd love to look at it. I might have one myself, but it would be a paper copy somewhere unknown. The diagrams showing multi-drop RS-422 is so ubiquitous, I expect they are from the standard itself. > >>> RS-485 would allow all this to be over a single pair of wires. > >>> But the one big issue I see people complain about is getting PC > >>> software to not clobber the slaves, or I should say, to get the > >>> master to wait long enough that it's not clobbering it's own > >>> start bit by overwriting the stop bit of the slave. I suppose > >>> someone, somewhere has dealt with this on the PC and has a > >>> solution that doesn't impact bus speed. I run the single test > >>> fixture version of this at about 100 kbps. I'm going to want as > >>> much speed as I can get for 80 FPGAs controlling 160 UUTs. Maybe > >>> I should give that some analysis, because this might not be > >>> true. > >> RS-485 is easy from a PC using appropriate USB devices. We make > >> heavy use of FTDI's chips and cables - they handle the drive > >> enables for the RS-485 automatically so that from the PC side you > >> just read and write to the serial port. > > > > I've yet to be convinced of this. Admittedly, my last interaction > > with RS-485 was many years ago, but there were some four or five > > different devices being integrated with a PC, and no two of them > > handled it the bus the same way. The PC in particular, would cut on > > and off the driver in the middle of bits. No one put a bias on the > > bus, so it was indeterminate when no one was driving. It was a > > horrible failure. > > > > Every time I've seen this discussed, the driver control has been an > > issue. > I can tell you it works perfectly with FTDI's RS-485 cables - every > time, every OS, regardless of the software. Some RS-485 drivers rely on > RTS for the drive enable - this was the standard for RS-232 to RS-485 > converters from the old days of 9-pin and 25-pin serial ports on PC's. > With such drivers, it is certainly possible to get things wrong. With > the drive enable handled directly by the UART hardware on the USB chip, > it is /far/ harder to get it wrong. So, what range of speeds have you used? It is actually the UART hardware that *does* get it very wrong by working off the transmitter empty signal, which changes in the middle of the bit. The control has to be specially designed to transition at the *end* of the stop bit of the transmitted character. Knowing when it is ok to enable the driver has the same problem. The data is "received" in the middle of the stop bit. So the enable has to be a half bit time later, at the end of the stop bit. 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. > I would expect there to be many alternatives to FTDI that work similarly > well, but that's the ones we generally use. > > <https://ftdichip.com/product-category/products/cables/?series_products=55> > > > >> The reception of the last byte from a slave is not finished until > >> the stop bit has been properly received by the master - that means > >> at least half-way through the sending of the stop bit. > > > > That's not sufficient. Everyone's halfway is a bit different and > > start bit detection may not be enabled on some device when the next > > driver outputs a start bit, or the last driver may not be turned off > > when the next driver starts. > > > "At least half-way" means "at least 50% of the bit time". As long as > the start bit from the next message is not sent until at least 50% of a > bit time after the stop bit is detected, it will not conflict and all > listening devices will be ready to see the start bit. (Devices that > needed two stop bits haven't existed in the last 50 years.) You don't seem to understand that there is nothing timing from the start of the bit. The timing is from the first detected low of the start bit. From there, all timing is done by an internal clock. Check the math, you don't get 50% of the stop bit, guaranteed. That's why they call it "asynchronous" serial. > You asked specifically about bus turnaround at the host side - I assume > that is because on the slave devices, you have control of the drive > enables and bus turnaround happens with negligible latency. I know the master has the most trouble with this. The slaves tend to not have a problem because they are operated by MCUs and can wait a bit time before replying, or even a character time. I suppose they don't have any magic on turning off the driver though, but early is the easy way and generally doesn't cause a problem. The master has trouble on both ends of it's message, needing to be careful to not turn on the driver too soon and not turning it off too late to clobber the reply. > >> Then there is a delay before the data gets sent back to the host > >> PC, a delay through the kernel and drivers before it reaches the > >> user program, time for the program to handle that message, time for > >> it to prepare the next message, delays through the kernel and > >> drivers before it gets to the USB bus, latency in the USB device > >> that receives the USB message and then starts transmitting. There > >> can be no collision unless all that delay is less than half a bit > >> time. And no matter how fast your computer is, you are always going > >> to need at least one full USB polling cycle for all this, which for > >> USB 2.0 is 0.125 us. That means that if you have a baud rate of 16 > >> kbaud or higher, there is no possibility of a collision. > > > > If your numbers are accurate, that might be ok, but I'm looking for > > data rates closer to 1 Mbps. > USB serial ports generally use the 48 MHz base USB reference frequency > as their source clock to scale down by a baud rate divisor, and common > practice is 16 sub-bit clocks per line bit (so that you can have > multiple samples for noise immunity). Thus baud rates of integer > divisions of 3 MBaud are common. Certainly the FTDI chips handle 1, 2 > and 3 MBaud. (I haven't had need of such speeds with RS-485, but have > happily used the common 3v3 TTL cables at 3 MBaud.) At some point you have to worry with the line waveforms. So too fast can cause problems when using *lots* of receivers. > > Admittedly, I have not done an analysis > > of what will actually be required, but 128 UUT, or possibly 256, can > > do a lot of damage to a shared bus. At 1 Mbps, 128 UUT results in an > > effective bit rate maximum of 7.8 kbps. With 256 UUTs, that's 3.9 > > kbps. No, I don't think this will work properly at much slower > > speeds than 1 Mbps. At 16 kbps, the effective rate to each UUT is > > just 62.5 bps, not kbps. > > > As long as you are /above/ 16 kbaud, you should be fine (at the PC > side). At 1 Mbaud, you do not need to worry about the PC starting a new > telegram before the last received stop bit is completed. Not entirely. The master has to turn *off* the driver before the slave replies. At higher speeds that's a problem. But it all depends on how it is being done. This is why I'm going with two busses, one for master transmit and one for master input. > >>> The tests are of two types, most of them are setting up a state > >>> and reading a signal. This can go pretty fast and doesn't take > >>> too many commands. Then there are the audio tests where the FPGA > >>> sends digital data to the UUT, which does it's thing and returns > >>> digital data which is crunched by the FPGA. This takes some small > >>> number of seconds and presently the protocol is to poll the > >>> status until it is done. That's a lot of messages, but it's not > >>> necessarily a slow point. The same test can be started on every > >>> UUT in parallel, so the waiting is in parallel. So maybe the > >>> serial port won't need to be any faster. > >>> > >>> Still, I want to use RS-422 or RS-485 to deal with ground noise > >>> since this will be spread over multiple boards that don't have > >>> terribly solid grounds, just the power cable really. > >>> > >>> I'm thinking out loud here as much as anything. I intended to > >>> simply ask if anyone had experience with RS-485 that would be > >>> helpful. Running two wires rather than eight would be a help. > >>> I'll probably use a 10 pin connector just to be on the safe side, > >>> allowing the transceivers to be used either way. > >>> > >> You need to do some calculations to see if you can get enough > >> telegrams and enough data through a single serial port. You'll be > >> hard pushed to find a USB serial port device of any kind that goes > >> above 3 Mbaud, and you need to be careful about your selection of > >> RS-485 drivers for those kinds of rates. You will also find that > >> much of your bandwidth is taken up with pauses between telegrams > >> and reply latency, unless you make your telegrams quite large. > > > > I assume by "telegrams", you mean the messages. They will be small > > by necessity. The protocol is interactive with a command message and > > a reply message. Read a register, write a register. > > > Telegram, message, packet - whatever term you prefer. At faster baud > rates, the inevitable pauses between messages take proportionately more > of the total bandwidth. Longer messages will be more efficient. But > you'll have to do the sums yourself to see what rates you need, and > whether or not this will be an issue. Not sure what delays you are talking about. Every message is either selecting a slave, or reading a register or writing a register. You are probably thinking like a code banger where you have to worry with software delays. The protocol at the interface to the UUT is serial, at 30 MHz and the turn around is so quick, I had to use a mux to select the first bit and shift the rest of the data from a shift register. All in all it is under a μs for a transfer, and the data can be sent to the PC in ASCII Hex format which even at 1 Mbps is much slower. I can't say what the delays on the PC are. It's never been of interest, but I can't imagine it's much. > >> When we have made testbenches that required serial communication > >> to multiple parallel devices, we typically put a USB hub in the > >> testbench and use multiple FDTI USB to serial cables. You only make > >> one (or possibly a few) of the testbenches - it's much cheaper to > >> use off-the-shelf parts than to spend time designing something > >> more advanced. You can buy a /lot/ of hubs and USB cables for the > >> price of the time to design, build and program a custom card for > >> the job. It also makes the system more scalable, as the > >> communication to different devices runs in parallel. > > > > USB hubs are a last resort. I've found many issues with such > > devices, especially larger than 4 ports. > > > We find they work fine - I have very rarely seen any issues with > off-the-shelf hubs, regardless of the number of ports. (They are almost > all made with 1-to-4 hub chips, which is why hubs are often found in > sizes of 4 ports, 7 ports, or 10 ports.) Exactly, and I find combining them like that has issues. > A key complication with multiple serial ports on hubs is if you are > using Windows, it can be a big pain to keep consistent numbering for the > serial ports. You may have to use driver-specific libraries (like > FTDI's DLL's) to check serial numbers and use that information. It's > far easier on Linux where you can make a udev configuration file that > gives aliases to your ports ordered by physical tree address. Yet another reason to avoid such complications. The reality is there's no gain. The multi-drop is the right way to go here. > >> We have also done systems where there is a Raspberry Pi driving the > >> hub and multiple FTDI converters. The PC is connected to the Pi by > >> Ethernet (useful for galvanic isolation), and the Pi runs > >> forwarders between the serial ports and TCP/IP ports. > > > > There is a possibility of using an rPi on an Ethernet cable to the PC > > with direct comms to each test fixture board, but that's more work > > that I'm interested in. > > > Or you could use one Pi for a set of boards - whatever is physically > convenient. But it's yet another piece to keep working. Much easier to just use the multi-drop. I will keep that idea as a backup plan. But getting RS-422 on an rPi is a hassle. That would need to be a hat, or a shield or whatever they call daughter cards on rPis. Last time I checked, it was hard to find rPis. They are part of the unobtainium universe now, it seems. > >> To be fair, I don't recall any testbenches we've made that needed > >> more than perhaps 8 serial ports. If I needed to handle 80 lines, I > >> would probably split things up - a Pi handling 8-10 lines from a > >> local program, communicating with a PC master program by Ethernet. > > > > That's the advantage of the shared bus. No programming required, > > other than extending the protocol to move from "selecting" a device > > on the FPGA, to selecting the FPGA as well. > > > If you are familiar with socat, the Pi doesn't necessarily need any > programming either. (In our case we wanted some extra monitoring and > logging, which was more than we could get from socat - so it was a > couple of hundred lines of Python in the end.) A couple hundred lines I'd rather not write. Thanks for the comments. -- 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-03 12:42 +0100 |
| Message-ID | <tk09ev$1f0de$1@dont-email.me> |
| In reply to | #31306 |
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: >>>>> I have a test fixture that uses RS-232 to communicate with a PC. >>>>> It actually uses the voltage levels of RS-232, even though this >>>>> is from a USB cable on the PC, so it's only RS-232 for maybe four >>>>> inches. lol >>>>> >>>>> I'm redesigning the test fixtures to hold more units and fully >>>>> automate a few features that presently requires an operator. >>>>> There will now be 8 UUTs on each test fixture and I expect to >>>>> have 10 to 20 test fixtures in a card rack. That's 80 to 160 UUTs >>>>> total. There will be an FPGA controlling each pair of UUTs, so 80 >>>>> FPGAs in total that the PC needs to talk to. >>>>> >>>>> Rather than working on a way to mux 80 RS-232 interfaces, I'm >>>>> thinking it would be better to either daisy chain, or connect in >>>>> parallel all these devices. The protocol is master-slave where >>>>> the master sends a command and the slaves are idle until they >>>>> reply. The four FPGAs on a test fixture board could be connected >>>>> in parallel easily enough. But I don't think I want to run TTL >>>>> level signals between so many boards. >>>>> >>>>> I could do an RS-422 interface with a master to slave pair and a >>>>> slave to master pair. The slaves do not speak until spoken to, >>>>> so there will be no collisions. >>>>> >>>> RS-422 is normally a point-to-point interface. It is one line in >>>> each direction, but using balanced pairs instead of a TTL signal. >>>> You would not normally connect multiple receivers or transmitters >>>> to an RS-422 bus, as the standard practice is that each transmitter >>>> is always driving the pair it is attached to - there is no >>>> multi-drop. >>> >>> That is simply not true. Data sheets for RS-422 devices often show >>> multidrop applications and how to best terminate them. >>> >> RS-422 is not multidrop. Occasionally you will see multiple receivers >> on a bus, but not multiple transmitters. > > Not sure of your point. Multi-drop is multiple receivers on a single transmitter. Multi-point is multiple drivers and receivers. Look at a few references. Even wikipedia says, "RS-422 provides for data transmission, using balanced, or differential, signaling, with unidirectional/non-reversible, terminated or non-terminated transmission lines, point to point, or multi-drop. In contrast to EIA-485, RS-422/V.11 does not allow multiple drivers but only multiple receivers." > OK. I have always associated "multidrop" with multiple receivers /and/ transmitters - I have never come across a need for multiple receivers on a serial bus without them also needing to transmit (such as in your case), or a distinction between "multi-drop" meaning multiple receivers and "multi-point" meaning multiple transmitters. The term "multi-drop" is more commonly taken to mean "multiple devices connected directly to the same bus, transmitting and receiving". The bus has no explicit direction on the electrical connections. Examples include RS-485, CAN, co-ax Ethernet. "Multi-point" is more general and can be any kind of network where there are multiple nodes that can send and receive to all other nodes. That would include a switched Ethernet network as well as the subclass of "multi-drop" networks. But whatever the terms, I think we agree on how RS-422 works. > >> Of course the same driver chips can be used in different combinations of >> wiring and drive enables. An RS-422 driver chip can be viewed as two >> RS-485 driver chips - alternatively, a RS-485 driver can be viewed as an >> RS-422 driver with the two differential pairs connected together. >> Really, all you are talking about is a differential driver and a >> differential receiver. > > Sure, but the point is, nothing in RS-422 precludes multiple receivers, and in fact, every reference I've found (not paying for the actual spec) shows multi-drop receivers. > Yes, it seems that is entirely possible. The only uses I have seen for RS-422 is as a kind of long-range alternative to RS-232. And the only use I have seen for multiple receivers is - like for RS-232 - for monitoring and debugging communication. Still, multiple receivers are not going to help you in your testbench unless they can also transmit. > >> So yes, you can do multidrop using an RS-422 driver chip. But it is not >> RS-422, which is a point-to-point serial bus standard. > > I don't believe that is correct. If you have a copy of the spec to share, I'd love to look at it. I might have one myself, but it would be a paper copy somewhere unknown. The diagrams showing multi-drop RS-422 is so ubiquitous, I expect they are from the standard itself. > > >>>>> RS-485 would allow all this to be over a single pair of wires. >>>>> But the one big issue I see people complain about is getting PC >>>>> software to not clobber the slaves, or I should say, to get the >>>>> master to wait long enough that it's not clobbering it's own >>>>> start bit by overwriting the stop bit of the slave. I suppose >>>>> someone, somewhere has dealt with this on the PC and has a >>>>> solution that doesn't impact bus speed. I run the single test >>>>> fixture version of this at about 100 kbps. I'm going to want as >>>>> much speed as I can get for 80 FPGAs controlling 160 UUTs. Maybe >>>>> I should give that some analysis, because this might not be >>>>> true. >>>> RS-485 is easy from a PC using appropriate USB devices. We make >>>> heavy use of FTDI's chips and cables - they handle the drive >>>> enables for the RS-485 automatically so that from the PC side you >>>> just read and write to the serial port. >>> >>> I've yet to be convinced of this. Admittedly, my last interaction >>> with RS-485 was many years ago, but there were some four or five >>> different devices being integrated with a PC, and no two of them >>> handled it the bus the same way. The PC in particular, would cut on >>> and off the driver in the middle of bits. No one put a bias on the >>> bus, so it was indeterminate when no one was driving. It was a >>> horrible failure. >>> >>> Every time I've seen this discussed, the driver control has been an >>> issue. >> I can tell you it works perfectly with FTDI's RS-485 cables - every >> time, every OS, regardless of the software. Some RS-485 drivers rely on >> RTS for the drive enable - this was the standard for RS-232 to RS-485 >> converters from the old days of 9-pin and 25-pin serial ports on PC's. >> With such drivers, it is certainly possible to get things wrong. With >> the drive enable handled directly by the UART hardware on the USB chip, >> it is /far/ harder to get it wrong. > > So, what range of speeds have you used? It is actually the UART hardware that *does* get it very wrong by working off the transmitter empty signal, which changes in the middle of the bit. The control has to be specially designed to transition at the *end* of the stop bit of the transmitted character. Knowing when it is ok to enable the driver has the same problem. The data is "received" in the middle of the stop bit. So the enable has to be a half bit time later, at the end of the stop bit. For RS-485, my usage has usually been quite slow (9600 baud is very common). Other colleagues have used faster rates. But as I said, it is the slow baud rates that are at higher risk. However, without knowing exact implementation details of all UART hardware, I think you are wrong. There are two "finished byte" signals that are common in UART transmission hardware. The first is "transmit buffer empty" which is set when a byte is transferred from the buffer into the transmitter shift register - most UARTs are at least double-buffered to improve flow. This signal comes a whole character before the end of the transmission - it is useful for the software, but not the hardware. If you have a transmitter that is not double-buffered, this signal would likely come at the beginning of the stop bit, or at the end of the stop bit (depending on how the state machines were made). The second is "transmission complete", which is set at the /end/ of the stop bit sent out on the line. That's when you know everything has been sent - software can move on, and hardware can turn off the driver. I cannot imagine why anyone would design transmission hardware that had a special signal or disabled a driver in the /middle/ of the stop bit. That makes no sense, and would have no use in software or hardware. That is definitely an imagined problem. (For reference, the FTDI datasheets show that the TXDEN output is activated one bit before the start bit - so that the start bit is a 1 to 0 transition, as required for UARTs - and deactivated at the end of the stop bit.) 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.) > > 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. (You still have to consider the latencies and timings to see if you can get enough messages through the system fast enough, but you won't see bus collisions. Consider broadcasts or multicast messages without replies as a way of avoiding latency.) > >> I would expect there to be many alternatives to FTDI that work similarly >> well, but that's the ones we generally use. >> >> <https://ftdichip.com/product-category/products/cables/?series_products=55> >>> >>>> The reception of the last byte from a slave is not finished until >>>> the stop bit has been properly received by the master - that means >>>> at least half-way through the sending of the stop bit. >>> >>> That's not sufficient. Everyone's halfway is a bit different and >>> start bit detection may not be enabled on some device when the next >>> driver outputs a start bit, or the last driver may not be turned off >>> when the next driver starts. >>> >> "At least half-way" means "at least 50% of the bit time". As long as >> the start bit from the next message is not sent until at least 50% of a >> bit time after the stop bit is detected, it will not conflict and all >> listening devices will be ready to see the start bit. (Devices that >> needed two stop bits haven't existed in the last 50 years.) > > You don't seem to understand that there is nothing timing from the start of the bit. The timing is from the first detected low of the start bit. From there, all timing is done by an internal clock. Check the math, you don't get 50% of the stop bit, guaranteed. That's why they call it "asynchronous" serial. > The beginning of the start bit is detected at the receiver by its falling edge. It is /confirmed/ by samples in the middle (or the falling edge gets rejected as noise), but all timing is done from that start time - not from the middle of any bits. It is called "asynchronous" because the transmitter and the receiver do not have any pre-agreed or external synchronisation regarding when the transmission is going to happen. But once it starts, they agree exactly on /when/ it starts (assuming a short enough bus that rise times and transmission line delays are negligible). I must admit that I have been assuming that you have reasonable quality clock references on each side of the communication, so that your baud rates match. In theory you have a total of nearly 5% margin of error for mismatched baud rates, line rise and fall delays, etc., and these can add to the maximum time between the receiver recognising a stop bit and the transmitter finishing sending the stop bit, giving between almost 0 and almost 1 bit time (typically 2/16 to 14/16 bit times). > >> You asked specifically about bus turnaround at the host side - I assume >> that is because on the slave devices, you have control of the drive >> enables and bus turnaround happens with negligible latency. > > I know the master has the most trouble with this. The slaves tend to not have a problem because they are operated by MCUs and can wait a bit time before replying, or even a character time. I suppose they don't have any magic on turning off the driver though, but early is the easy way and generally doesn't cause a problem. The master has trouble on both ends of it's message, needing to be careful to not turn on the driver too soon and not turning it off too late to clobber the reply. > PC's are not good at accurate short delays, but have no problem at making a delay of at least a given time. There is no excuse for a PC program turning on the driver too soon - even if it were not handled automatically by the hardware, adding a "sleep" call to get a minimum delay is basic stuff. In the old days (I remember doing this stuff on 16-bit Windows) it was hard to get a reliable delay that was shorter than about 20 ms, but even then it was possible. The bigger challenge with "manual" driver enable control in PC software is being sure you turn the driver off fast enough, before the other end replies. However - and I know I am repeating myself - the answer is to get a decent USB to RS-485 converter that does this correctly and automatically in hardware. As for delays before replying (or before sending a new message from the master), we have only talked about them in regard to bus drivers. It is standard practice to have an additional delay beyond the minimum, as it gives a bit of extra leeway and makes debugging easier - you can see the start and stop of the messages on an oscilloscope. Modbus RTU, for example, specifies an inter-frame silence time of at least 3.5 characters. > >>>> Then there is a delay before the data gets sent back to the host >>>> PC, a delay through the kernel and drivers before it reaches the >>>> user program, time for the program to handle that message, time for >>>> it to prepare the next message, delays through the kernel and >>>> drivers before it gets to the USB bus, latency in the USB device >>>> that receives the USB message and then starts transmitting. There >>>> can be no collision unless all that delay is less than half a bit >>>> time. And no matter how fast your computer is, you are always going >>>> to need at least one full USB polling cycle for all this, which for >>>> USB 2.0 is 0.125 us. That means that if you have a baud rate of 16 >>>> kbaud or higher, there is no possibility of a collision. >>> >>> If your numbers are accurate, that might be ok, but I'm looking for >>> data rates closer to 1 Mbps. >> USB serial ports generally use the 48 MHz base USB reference frequency >> as their source clock to scale down by a baud rate divisor, and common >> practice is 16 sub-bit clocks per line bit (so that you can have >> multiple samples for noise immunity). Thus baud rates of integer >> divisions of 3 MBaud are common. Certainly the FTDI chips handle 1, 2 >> and 3 MBaud. (I haven't had need of such speeds with RS-485, but have >> happily used the common 3v3 TTL cables at 3 MBaud.) > > At some point you have to worry with the line waveforms. So too fast can cause problems when using *lots* of receivers. > Yes. But I don't think you have a physically long bus, do you? 10 meters, maybe? 3 MBaud and 32 nodes should be fine. > >>> Admittedly, I have not done an analysis >>> of what will actually be required, but 128 UUT, or possibly 256, can >>> do a lot of damage to a shared bus. At 1 Mbps, 128 UUT results in an >>> effective bit rate maximum of 7.8 kbps. With 256 UUTs, that's 3.9 >>> kbps. No, I don't think this will work properly at much slower >>> speeds than 1 Mbps. At 16 kbps, the effective rate to each UUT is >>> just 62.5 bps, not kbps. >>> >> As long as you are /above/ 16 kbaud, you should be fine (at the PC >> side). At 1 Mbaud, you do not need to worry about the PC starting a new >> telegram before the last received stop bit is completed. > > Not entirely. The master has to turn *off* the driver before the slave replies. At higher speeds that's a problem. But it all depends on how it is being done. This is why I'm going with two busses, one for master transmit and one for master input. > Unless you are masochistic or stuck in the last century, the driver turnoff is done by the USB to RS485 driver, not by a PC program in software. (I think for several reasons your hybrid bus is a better choice than a single RS-485 bus - though I would still prefer to look at a hierarchical setup myself.) > >>>>> The tests are of two types, most of them are setting up a state >>>>> and reading a signal. This can go pretty fast and doesn't take >>>>> too many commands. Then there are the audio tests where the FPGA >>>>> sends digital data to the UUT, which does it's thing and returns >>>>> digital data which is crunched by the FPGA. This takes some small >>>>> number of seconds and presently the protocol is to poll the >>>>> status until it is done. That's a lot of messages, but it's not >>>>> necessarily a slow point. The same test can be started on every >>>>> UUT in parallel, so the waiting is in parallel. So maybe the >>>>> serial port won't need to be any faster. >>>>> >>>>> Still, I want to use RS-422 or RS-485 to deal with ground noise >>>>> since this will be spread over multiple boards that don't have >>>>> terribly solid grounds, just the power cable really. >>>>> >>>>> I'm thinking out loud here as much as anything. I intended to >>>>> simply ask if anyone had experience with RS-485 that would be >>>>> helpful. Running two wires rather than eight would be a help. >>>>> I'll probably use a 10 pin connector just to be on the safe side, >>>>> allowing the transceivers to be used either way. >>>>> >>>> You need to do some calculations to see if you can get enough >>>> telegrams and enough data through a single serial port. You'll be >>>> hard pushed to find a USB serial port device of any kind that goes >>>> above 3 Mbaud, and you need to be careful about your selection of >>>> RS-485 drivers for those kinds of rates. You will also find that >>>> much of your bandwidth is taken up with pauses between telegrams >>>> and reply latency, unless you make your telegrams quite large. >>> >>> I assume by "telegrams", you mean the messages. They will be small >>> by necessity. The protocol is interactive with a command message and >>> a reply message. Read a register, write a register. >>> >> Telegram, message, packet - whatever term you prefer. At faster baud >> rates, the inevitable pauses between messages take proportionately more >> of the total bandwidth. Longer messages will be more efficient. But >> you'll have to do the sums yourself to see what rates you need, and >> whether or not this will be an issue. > > Not sure what delays you are talking about. Every message is either selecting a slave, or reading a register or writing a register. You are probably thinking like a code banger where you have to worry with software delays. The protocol at the interface to the UUT is serial, at 30 MHz and the turn around is so quick, I had to use a mux to select the first bit and shift the rest of the data from a shift register. All in all it is under a μs for a transfer, and the data can be sent to the PC in ASCII Hex format which even at 1 Mbps is much slower. I can't say what the delays on the PC are. It's never been of interest, but I can't imagine it's much. > There are /always/ delays - in particular at the PC side. PC's are good for high throughput, but bad for low latency. If they are not a problem, then that's fine. > >>>> When we have made testbenches that required serial communication >>>> to multiple parallel devices, we typically put a USB hub in the >>>> testbench and use multiple FDTI USB to serial cables. You only make >>>> one (or possibly a few) of the testbenches - it's much cheaper to >>>> use off-the-shelf parts than to spend time designing something >>>> more advanced. You can buy a /lot/ of hubs and USB cables for the >>>> price of the time to design, build and program a custom card for >>>> the job. It also makes the system more scalable, as the >>>> communication to different devices runs in parallel. >>> >>> USB hubs are a last resort. I've found many issues with such >>> devices, especially larger than 4 ports. >>> >> We find they work fine - I have very rarely seen any issues with >> off-the-shelf hubs, regardless of the number of ports. (They are almost >> all made with 1-to-4 hub chips, which is why hubs are often found in >> sizes of 4 ports, 7 ports, or 10 ports.) > > Exactly, and I find combining them like that has issues. > Experiences vary, I guess. > >> A key complication with multiple serial ports on hubs is if you are >> using Windows, it can be a big pain to keep consistent numbering for the >> serial ports. You may have to use driver-specific libraries (like >> FTDI's DLL's) to check serial numbers and use that information. It's >> far easier on Linux where you can make a udev configuration file that >> gives aliases to your ports ordered by physical tree address. > > Yet another reason to avoid such complications. The reality is there's no gain. The multi-drop is the right way to go here. > You see a complication where I see a simple configuration. And if you need to use multiple serial ports on a single PC, Linux and a udev configuration is a /huge/ gain. I currently have 7 serial ports in use on my development PC at the moment, connected to debug ports (TTL UARTs) on various boards. /dev/ttySerialPort_2_3 for hub 2 port 3 is vastly superior to "COM74" on a Windows system. (I have no idea if you are using Windows or Linux on your controlling PC here.) > >>>> We have also done systems where there is a Raspberry Pi driving the >>>> hub and multiple FTDI converters. The PC is connected to the Pi by >>>> Ethernet (useful for galvanic isolation), and the Pi runs >>>> forwarders between the serial ports and TCP/IP ports. >>> >>> There is a possibility of using an rPi on an Ethernet cable to the PC >>> with direct comms to each test fixture board, but that's more work >>> that I'm interested in. >>> >> Or you could use one Pi for a set of boards - whatever is physically >> convenient. > > But it's yet another piece to keep working. Much easier to just use the multi-drop. I will keep that idea as a backup plan. But getting RS-422 on an rPi is a hassle. That would need to be a hat, or a shield or whatever they call daughter cards on rPis. Last time I checked, it was hard to find rPis. They are part of the unobtainium universe now, it seems. > Of course availability of parts is of prime concern these days, and projects are often done by buying what you can and then designing around the devices you have found. Pi's have USB - you do your RS-485, RS-422 or whatever on the Pi in exactly the same way as you do it on the PC, using FTDI cables (or an alternative supplier that you are comfortable with). Plug and play. It is about modularisation and scalability. Now, I don't know your product, your manufacturing and test systems, your preferences, or anything other than the information you've written here. But if our production department asked us to make a test bench for handling 80 devices in parallel, my immediate reaction would be to refuse. I'd design a testbench to handle 8, or some number of that order. Then I'd get them to make perhaps 12 of these test benches. That way, they have something scalable and maintainable. If one testbench breaks, they are at 90% production capacity instead of 0%. If they need to increase capacity, they can make a few more benches. If they want to spread testing between two facilities, it's easy. So for /me/, and /my/ company, splitting things up in a hierarchy with Pi's (or something similar) has clear advantages. But you might have very different priorities or organisations that give different dynamics and different trade-offs. > >>>> To be fair, I don't recall any testbenches we've made that needed >>>> more than perhaps 8 serial ports. If I needed to handle 80 lines, I >>>> would probably split things up - a Pi handling 8-10 lines from a >>>> local program, communicating with a PC master program by Ethernet. >>> >>> That's the advantage of the shared bus. No programming required, >>> other than extending the protocol to move from "selecting" a device >>> on the FPGA, to selecting the FPGA as well. >>> >> If you are familiar with socat, the Pi doesn't necessarily need any >> programming either. (In our case we wanted some extra monitoring and >> logging, which was more than we could get from socat - so it was a >> couple of hundred lines of Python in the end.) > > A couple hundred lines I'd rather not write. > > Thanks for the comments. > Thanks for starting the threads here - it's nice to have a bit of real discussion in this group that is often rather quiet.
[toc] | [prev] | [next] | [standalone]
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Date | 2022-11-03 14:00 +0100 |
| Message-ID | <tk0e27$1f1rv$1@dont-email.me> |
| In reply to | #31312 |
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? I wouldn't be surprised if the implementation was different for different manufacturers. >> 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). 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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-03 16:26 +0100 |
| Message-ID | <tk0mih$1g2fh$1@dont-email.me> |
| In reply to | #31314 |
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? > > 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. You also want to have a bit of load so that you have some current on the bus, and thereby greater noise immunity. > 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.
[toc] | [prev] | [next] | [standalone]
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Date | 2022-11-04 08:45 +0100 |
| Message-ID | <tk2fuo$1nau3$1@dont-email.me> |
| In reply to | #31315 |
Il 03/11/2022 16:26, David Brown ha scritto: > On 03/11/2022 14:00, pozz wrote: >> Il 03/11/2022 12:42, David Brown ha scritto: >>> On 03/11/2022 00:27, Rick C wrote: >>>> On Wednesday, November 2, 2022 at 4:49:16 PM UTC-4, David Brown wrote: >>>>> On 02/11/2022 20:20, Rick C wrote: >>>>>> On Wednesday, November 2, 2022 at 5:28:21 AM UTC-4, David Brown >>>>>> wrote: >>>>>>> On 02/11/2022 06:28, Rick C wrote: >> >> >>> You are correct that reception is in the middle of the stop bit >>> (typically sub-slot 9 of 16). The first transmitter will be disabled >>> at the end of the stop bit, and the next transmitter must not enable >>> its driver until after that point - it must wait at least half a bit >>> time after reception before starting transmission. (It can wait >>> longer without trouble, which is why faster baud rates are less >>> likely to involve any complications here.) >> >> Do you mean that RX interrupt triggers in the middle of the stop bit >> and not at the end? Interesting, but are you sure this is the case for >> every UART implemented in MCUs? > > Of course I'm not sure - there are a /lot/ of MCU manufacturers! > > UART receivers usually work in the same way, however. They have a > sample clock running at 16 times the baud clock. The start bit is edge > triggered to give the start of the character frame. Then each bit is > sampled in the middle of its time slot - usually at subbit slots 7, 8, > and 9 with majority voting. So the stop bit is recognized by subbit > slot 9 of the tenth bit (assuming 8-bit, no parity) - the voltage on the > line after that is irrelevant. (Even when you have two stop bits, > receivers never check the second stop bit - it affects transmit timing > only.) What purpose would there be in waiting another 7 subbits before > triggering the interrupt, DMA, or whatever? There's no real purpose, but it's important to know exactly when the RX interrupt is fired from the UART. Usually the next transmitter starts transmitting after receiving the last byte of the previous transmitter (for example, the slave starts replying to the master after receiving the complete message from it). Now I think of the issue related to a transmitter that delays a little to turn around the direction of its transceiver, from TX to RX. Every transmitter on the bus should take into account this delay and avoid starting transmission too soon. So I usually implement a short delay before starting a new message transmission. If the maximum expected delay of moving the direction from TX to RX is 10us, I could think to use a 10us delay, but this is wrong in your assumption. If the RX interrupt is at the middle of the stop bit, I should delay the new transmission of 10us + half of bit time. With 9600 this is 52us that is much higher than 10us. I know the next transmitter should make some processing of the previous received message, prepare and buffer the new message to transmit, so the delay is somewhat automatic, but in many cases I have small 8-bits PICs and full-futured Linux box on the same bus and the Linux could be very fast to start the new transmission. >> I wouldn't be surprised if the implementation was different for >> different manufacturers. >> > > I've seen a bit of variation, including 8 subbit clocks per baud clock, > wider sampling ranges, re-sync of the clock on edges, etc. And of > course you don't always get the details of the timings in datasheets > (and who bothers measuring them?) But the key principles are the same. > >> >>>> None of this matters to me really. I'm going to use more wires, and >>>> do the multi-drop from the PC to the slaves on one pair and use >>>> RS-422 to multi-point from the slaves to the PC. Since the slaves >>>> are controlled by the master, they will never collide. The master >>>> can't collide with itself, so I can ignore any issues with this. I >>>> will use the bias resistors to assure a valid idle state. I may >>>> need to select different devices than the ones I use in the >>>> product. I think there are differences in the input load and I want >>>> to be sure I can chain up to 32 units. >>>> >>> >>> OK. I have no idea what such a hybrid bus should technically be >>> called, but I think it should work absolutely fine for the purpose >>> and seems like a solid solution. I would not foresee any issues with >>> 32 nodes on such a bus, especially if it is relatively short and you >>> have terminators at each end. >> >> In my experience, termination resistors at each end of the line could >> introduce other troubles if they aren't strictly required (because of >> signal integrity on long lines at high baud rates). >> > > RS-485 requires them - you want to hold the bus at a stable idle state > when nothing is driving it. But this is the goal of *bias* resistors, not termination resistors. > You also want to have a bit of load so that > you have some current on the bus, and thereby greater noise immunity. Of course, but termination resistors are usually small (around 100 ohms) because they should match the impedance of the cable. If you want only to introduce "some current" on the bus, you could use resistors in the order of 1k, but this isn't strictly a *termination* resistor. >> The receiver input impedance of all the nodes on the bus are in >> parallel with the two terminators. If you have many nodes, the >> equivalent impedance on the bus is much small and the partition with >> bias resistors could reduce the differential voltage between A and B >> at idle to less than 200mV. >> >> If you don't use true fail-safe transceivers, a fault start bit could >> be seen by these kind of receivers. >> > > Receiver load is very small on modern RS-485 drivers. ST3485 says the input load of the receiver around 24k. When you connect 32 slaves, the equivalent resistor would be 750 ohms, that should be enough to have "some current" on the bus. If you add *termination* resistors in the order of 100R on both sides, you could reduce drastically the differential voltage between A and B at idle state.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-04 10:49 +0100 |
| Message-ID | <tk2n7g$1o0ct$1@dont-email.me> |
| In reply to | #31329 |
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. 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. > 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. > >>> 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.
[toc] | [prev] | [next] | [standalone]
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Date | 2022-11-04 15:37 +0100 |
| Message-ID | <tk3839$1nau3$2@dont-email.me> |
| In reply to | #31330 |
Il 04/11/2022 10:49, David Brown ha scritto: > On 04/11/2022 08:45, pozz wrote: >> Il 03/11/2022 16:26, David Brown ha scritto: >>> On 03/11/2022 14:00, pozz wrote: >>>> Il 03/11/2022 12:42, David Brown ha scritto: >>>>> On 03/11/2022 00:27, Rick C wrote: >>>>>> On Wednesday, November 2, 2022 at 4:49:16 PM UTC-4, David Brown >>>>>> wrote: >>>>>>> On 02/11/2022 20:20, Rick C wrote: >>>>>>>> On Wednesday, November 2, 2022 at 5:28:21 AM UTC-4, David Brown >>>>>>>> wrote: >>>>>>>>> On 02/11/2022 06:28, Rick C wrote: >>>> >>>> >>>>> You are correct that reception is in the middle of the stop bit >>>>> (typically sub-slot 9 of 16). The first transmitter will be >>>>> disabled at the end of the stop bit, and the next transmitter must >>>>> not enable its driver until after that point - it must wait at >>>>> least half a bit time after reception before starting >>>>> transmission. (It can wait longer without trouble, which is why >>>>> faster baud rates are less likely to involve any complications here.) >>>> >>>> Do you mean that RX interrupt triggers in the middle of the stop bit >>>> and not at the end? Interesting, but are you sure this is the case >>>> for every UART implemented in MCUs? >>> >>> Of course I'm not sure - there are a /lot/ of MCU manufacturers! >>> >>> UART receivers usually work in the same way, however. They have a >>> sample clock running at 16 times the baud clock. The start bit is >>> edge triggered to give the start of the character frame. Then each >>> bit is sampled in the middle of its time slot - usually at subbit >>> slots 7, 8, and 9 with majority voting. So the stop bit is >>> recognized by subbit slot 9 of the tenth bit (assuming 8-bit, no >>> parity) - the voltage on the line after that is irrelevant. (Even >>> when you have two stop bits, receivers never check the second stop >>> bit - it affects transmit timing only.) What purpose would there be >>> in waiting another 7 subbits before triggering the interrupt, DMA, or >>> whatever? >> >> There's no real purpose, but it's important to know exactly when the >> RX interrupt is fired from the UART. >> > > I think it is extremely rare that this is important. I can't think of a > single occasion when I have thought it remotely relevant where in the > stop bit the interrupt comes. > >> Usually the next transmitter starts transmitting after receiving the >> last byte of the previous transmitter (for example, the slave starts >> replying to the master after receiving the complete message from it). >> > > No. Usually the next transmitter starts after receiving the last byte, > and /then a pause/. There will always be some handling time in > software, and may also include an explicit pause. Almost always you > will want to do at least a minimum of checking of the incoming data > before deciding on the next telegram to be sent out. But if you have > very fast handling in relation to the baud rate, you will want an > explicit pause too - protocols regularly specify a minimum pause (such > as 3.5 character times for Modbus RTU), and you definitely want it to be > at least one full character time to ensure no listener gets hopelessly > out of sync. In theory, if all the nodes on the bus were able to change direction in hardware (exactly at the end of the stop bit), you will not be forced to introduce any delay in the transmission. Many times I'm the author of a custom protocol because some nodes on a shared bus, so I'm not forced to follow any specifications. When I didn't introduce any delay in the transmission, I sometimes faced this issue. In my experience, the bus is heterogeneous enough to have a fast replying slave to a slow master. >> Now I think of the issue related to a transmitter that delays a little >> to turn around the direction of its transceiver, from TX to RX. Every >> transmitter on the bus should take into account this delay and avoid >> starting transmission too soon. > > They should, yes. The turnaround delay should be negligible in this day > and age - if not, your software design is screwed or you have picked the > wrong hardware. (Of course, you don't always get the choice of hardware > you want, and programmers are often left to find ways around hardware > design flaws.) Negligible doesn't mean anything. If thre's a poor 8 bit PIC (previous transmitter) clocked at 8MHz that changes direction in TXC interrupt while other interrupts are active, and there's a Cortex-M4 clocked at 200MHz (next transmitter), you will encounter this issue. This is more evident if, as you are saying, the Cortex-M4 is able to start processing the message from the PIC at the midpoint of last stop bit, while the PIC disables its driver at the *end* of the stop bit plus an additional delay caused by interrupts handling. In this cases the half bit time is not negligible and must be added to the transmission delay. >> 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. > > 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. Not always. If you have only MCUs that are able to control direction in hardware, you don't need any delay before transmission. > 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. Oh yes, if you have already implemented a pause of 3.5 char times, it is ok. >> 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. > >> >>>> 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. Ok, I thought you were suggesting to add impedance matching (slow) resistors as terminators in any case.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-04 17:36 +0100 |
| Message-ID | <tk3f2t$1t3hc$1@dont-email.me> |
| In reply to | #31333 |
On 04/11/2022 15:37, pozz wrote: > Il 04/11/2022 10:49, David Brown ha scritto: >> On 04/11/2022 08:45, pozz wrote: >>> Il 03/11/2022 16:26, David Brown ha scritto: >>>> On 03/11/2022 14:00, pozz wrote: >>>>> Il 03/11/2022 12:42, David Brown ha scritto: >>>>>> On 03/11/2022 00:27, Rick C wrote: >>>>>>> On Wednesday, November 2, 2022 at 4:49:16 PM UTC-4, David Brown >>>>>>> wrote: >>>>>>>> On 02/11/2022 20:20, Rick C wrote: >>>>>>>>> On Wednesday, November 2, 2022 at 5:28:21 AM UTC-4, David Brown >>>>>>>>> wrote: >>>>>>>>>> On 02/11/2022 06:28, Rick C wrote: >>>>> >>>>> >>>>>> You are correct that reception is in the middle of the stop bit >>>>>> (typically sub-slot 9 of 16). The first transmitter will be >>>>>> disabled at the end of the stop bit, and the next transmitter must >>>>>> not enable its driver until after that point - it must wait at >>>>>> least half a bit time after reception before starting >>>>>> transmission. (It can wait longer without trouble, which is why >>>>>> faster baud rates are less likely to involve any complications here.) >>>>> >>>>> Do you mean that RX interrupt triggers in the middle of the stop >>>>> bit and not at the end? Interesting, but are you sure this is the >>>>> case for every UART implemented in MCUs? >>>> >>>> Of course I'm not sure - there are a /lot/ of MCU manufacturers! >>>> >>>> UART receivers usually work in the same way, however. They have a >>>> sample clock running at 16 times the baud clock. The start bit is >>>> edge triggered to give the start of the character frame. Then each >>>> bit is sampled in the middle of its time slot - usually at subbit >>>> slots 7, 8, and 9 with majority voting. So the stop bit is >>>> recognized by subbit slot 9 of the tenth bit (assuming 8-bit, no >>>> parity) - the voltage on the line after that is irrelevant. (Even >>>> when you have two stop bits, receivers never check the second stop >>>> bit - it affects transmit timing only.) What purpose would there be >>>> in waiting another 7 subbits before triggering the interrupt, DMA, >>>> or whatever? >>> >>> There's no real purpose, but it's important to know exactly when the >>> RX interrupt is fired from the UART. >>> >> >> I think it is extremely rare that this is important. I can't think of >> a single occasion when I have thought it remotely relevant where in >> the stop bit the interrupt comes. >> >>> Usually the next transmitter starts transmitting after receiving the >>> last byte of the previous transmitter (for example, the slave starts >>> replying to the master after receiving the complete message from it). >>> >> >> No. Usually the next transmitter starts after receiving the last >> byte, and /then a pause/. There will always be some handling time in >> software, and may also include an explicit pause. Almost always you >> will want to do at least a minimum of checking of the incoming data >> before deciding on the next telegram to be sent out. But if you have >> very fast handling in relation to the baud rate, you will want an >> explicit pause too - protocols regularly specify a minimum pause (such >> as 3.5 character times for Modbus RTU), and you definitely want it to >> be at least one full character time to ensure no listener gets >> hopelessly out of sync. > > In theory, if all the nodes on the bus were able to change direction in > hardware (exactly at the end of the stop bit), you will not be forced to > introduce any delay in the transmission. Communication is about /reliably/ transferring data between devices. Asynchronous serial communication is about doing that despite slight differences in clock rates, differences in synchronisation, differences in startup times, etc. If you don't have idle pauses, you have almost zero chance of staying in sync across the nodes - and no chance at all of recovery when that happens. /Every/ successful serial protocol has pauses between frames - long enough pauses that the idle time could not possibly be part of a normal full speed frame. That does not just apply to UART protocols, or even just to asynchronous protocols. The pause does not have to be as long as 3.5 characters, but you need a pause - just as you need other error recovery handling. > > Many times I'm the author of a custom protocol because some nodes on a > shared bus, so I'm not forced to follow any specifications. When I > didn't introduce any delay in the transmission, I sometimes faced this > issue. In my experience, the bus is heterogeneous enough to have a fast > replying slave to a slow master. > > >>> Now I think of the issue related to a transmitter that delays a >>> little to turn around the direction of its transceiver, from TX to >>> RX. Every transmitter on the bus should take into account this delay >>> and avoid starting transmission too soon. >> >> They should, yes. The turnaround delay should be negligible in this >> day and age - if not, your software design is screwed or you have >> picked the wrong hardware. (Of course, you don't always get the >> choice of hardware you want, and programmers are often left to find >> ways around hardware design flaws.) > > Negligible doesn't mean anything. Negligible means of no significance in comparison to the delays you have anyway - either intentional delays in order to separate telegrams and have a reliable communication, or unavoidable delays due to software processing. > If thre's a poor 8 bit PIC (previous > transmitter) clocked at 8MHz that changes direction in TXC interrupt > while other interrupts are active, and there's a Cortex-M4 clocked at > 200MHz (next transmitter), you will encounter this issue. > No, you won't - not unless you are doing something silly in your timing such as failing to use appropriate pauses or thinking that 10 µs turnarounds are a good idea at 9600 baud. And I did specify picking sensible hardware - 8-bit PICs were are terrible choice 20 years ago for anything involving high speed, and they have not improved. (Again - sometimes you don't have control of the hardware, and sometimes there can be other overriding reasons for picking something. But if your hardware is limited, you have to take that into account.) > This is more evident if, as you are saying, the Cortex-M4 is able to > start processing the message from the PIC at the midpoint of last stop > bit, while the PIC disables its driver at the *end* of the stop bit plus > an additional delay caused by interrupts handling. > > In this cases the half bit time is not negligible and must be added to > the transmission delay. > Sorry, but I cannot see any situation where that would happen in a well-designed communication system. Oh, and it is actually essential that the receiver considers the character finished half-way through the stop bit, and not at the end. UART communication is intended to work despite small differences in the baud rate - up to nearly 5% total error. By the time the receiver is half way through the received stop bit, and has identified it is valid, the sender could be finished the stop bit as its clock is almost 5% faster (50% bit time over the full 10 bits). The receiver has to be in the "watch for falling edge of start bit" state at this point, ready for the transmitter to start its next frame. > > >>> 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. >> >> 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. > > Not always. If you have only MCUs that are able to control direction in > hardware, you don't need any delay before transmission. > > >> 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. > > Oh yes, if you have already implemented a pause of 3.5 char times, it is > ok. > Yes, exactly. > >>> 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. >> >>> >>>>> 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. > > Ok, I thought you were suggesting to add impedance matching (slow) > resistors as terminators in any case.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-04 10:11 -0700 |
| Message-ID | <3d9e5c38-93be-4504-b891-e0087053ebc7n@googlegroups.com> |
| In reply to | #31336 |
On Friday, November 4, 2022 at 12:36:51 PM UTC-4, David Brown wrote: > On 04/11/2022 15:37, pozz wrote: > > Il 04/11/2022 10:49, David Brown ha scritto: > >> On 04/11/2022 08:45, pozz wrote: > >>> Il 03/11/2022 16:26, David Brown ha scritto: > >>>> On 03/11/2022 14:00, pozz wrote: > >>>>> Il 03/11/2022 12:42, David Brown ha scritto: > >>>>>> On 03/11/2022 00:27, Rick C wrote: > >>>>>>> On Wednesday, November 2, 2022 at 4:49:16 PM UTC-4, David Brown > >>>>>>> wrote: > >>>>>>>> On 02/11/2022 20:20, Rick C wrote: > >>>>>>>>> On Wednesday, November 2, 2022 at 5:28:21 AM UTC-4, David Brown > >>>>>>>>> wrote: > >>>>>>>>>> On 02/11/2022 06:28, Rick C wrote: > >>>>> > >>>>> > >>>>>> You are correct that reception is in the middle of the stop bit > >>>>>> (typically sub-slot 9 of 16). The first transmitter will be > >>>>>> disabled at the end of the stop bit, and the next transmitter must > >>>>>> not enable its driver until after that point - it must wait at > >>>>>> least half a bit time after reception before starting > >>>>>> transmission. (It can wait longer without trouble, which is why > >>>>>> faster baud rates are less likely to involve any complications here.) > >>>>> > >>>>> Do you mean that RX interrupt triggers in the middle of the stop > >>>>> bit and not at the end? Interesting, but are you sure this is the > >>>>> case for every UART implemented in MCUs? > >>>> > >>>> Of course I'm not sure - there are a /lot/ of MCU manufacturers! > >>>> > >>>> UART receivers usually work in the same way, however. They have a > >>>> sample clock running at 16 times the baud clock. The start bit is > >>>> edge triggered to give the start of the character frame. Then each > >>>> bit is sampled in the middle of its time slot - usually at subbit > >>>> slots 7, 8, and 9 with majority voting. So the stop bit is > >>>> recognized by subbit slot 9 of the tenth bit (assuming 8-bit, no > >>>> parity) - the voltage on the line after that is irrelevant. (Even > >>>> when you have two stop bits, receivers never check the second stop > >>>> bit - it affects transmit timing only.) What purpose would there be > >>>> in waiting another 7 subbits before triggering the interrupt, DMA, > >>>> or whatever? > >>> > >>> There's no real purpose, but it's important to know exactly when the > >>> RX interrupt is fired from the UART. > >>> > >> > >> I think it is extremely rare that this is important. I can't think of > >> a single occasion when I have thought it remotely relevant where in > >> the stop bit the interrupt comes. > >> > >>> Usually the next transmitter starts transmitting after receiving the > >>> last byte of the previous transmitter (for example, the slave starts > >>> replying to the master after receiving the complete message from it). > >>> > >> > >> No. Usually the next transmitter starts after receiving the last > >> byte, and /then a pause/. There will always be some handling time in > >> software, and may also include an explicit pause. Almost always you > >> will want to do at least a minimum of checking of the incoming data > >> before deciding on the next telegram to be sent out. But if you have > >> very fast handling in relation to the baud rate, you will want an > >> explicit pause too - protocols regularly specify a minimum pause (such > >> as 3.5 character times for Modbus RTU), and you definitely want it to > >> be at least one full character time to ensure no listener gets > >> hopelessly out of sync. > > > > In theory, if all the nodes on the bus were able to change direction in > > hardware (exactly at the end of the stop bit), you will not be forced to > > introduce any delay in the transmission. > Communication is about /reliably/ transferring data between devices. > Asynchronous serial communication is about doing that despite slight > differences in clock rates, differences in synchronisation, differences > in startup times, etc. If you don't have idle pauses, you have almost > zero chance of staying in sync across the nodes - and no chance at all > of recovery when that happens. /Every/ successful serial protocol has > pauses between frames - long enough pauses that the idle time could not > possibly be part of a normal full speed frame. That does not just apply > to UART protocols, or even just to asynchronous protocols. The pause > does not have to be as long as 3.5 characters, but you need a pause - > just as you need other error recovery handling. The "idle" pauses you talk about are accommodated with the start and stop bits in the async protocol. Every character is sent with a start bit which starts the timing. The stop bit is the "fluff" time for the next character to align to the next start bit. There is no need for the bus to be idle in the sense of no data being sent. If an RS-485 or RS-422 bus is biased for undriven times, there is no need for the driver to be on through the full stop bit. Once the stop bit has driven high, it can be disabled, such as in the middle of the bit. The there is a half bit time for timing skew, which amounts to 5%, between any two devices on the bus. > > Many times I'm the author of a custom protocol because some nodes on a > > shared bus, so I'm not forced to follow any specifications. When I > > didn't introduce any delay in the transmission, I sometimes faced this > > issue. In my experience, the bus is heterogeneous enough to have a fast > > replying slave to a slow master. > > > > > >>> Now I think of the issue related to a transmitter that delays a > >>> little to turn around the direction of its transceiver, from TX to > >>> RX. Every transmitter on the bus should take into account this delay > >>> and avoid starting transmission too soon. > >> > >> They should, yes. The turnaround delay should be negligible in this > >> day and age - if not, your software design is screwed or you have > >> picked the wrong hardware. (Of course, you don't always get the > >> choice of hardware you want, and programmers are often left to find > >> ways around hardware design flaws.) > > > > Negligible doesn't mean anything. > Negligible means of no significance in comparison to the delays you have > anyway - either intentional delays in order to separate telegrams and > have a reliable communication, or unavoidable delays due to software > processing. The software on the PC is not managing the bus drivers. So software delays are not relevant to bus control timing. > > If thre's a poor 8 bit PIC (previous > > transmitter) clocked at 8MHz that changes direction in TXC interrupt > > while other interrupts are active, and there's a Cortex-M4 clocked at > > 200MHz (next transmitter), you will encounter this issue. > > > No, you won't - not unless you are doing something silly in your timing > such as failing to use appropriate pauses or thinking that 10 µs > turnarounds are a good idea at 9600 baud. And I did specify picking > sensible hardware - 8-bit PICs were are terrible choice 20 years ago for > anything involving high speed, and they have not improved. (Again - > sometimes you don't have control of the hardware, and sometimes there > can be other overriding reasons for picking something. But if your > hardware is limited, you have to take that into account.) > > This is more evident if, as you are saying, the Cortex-M4 is able to > > start processing the message from the PIC at the midpoint of last stop > > bit, while the PIC disables its driver at the *end* of the stop bit plus > > an additional delay caused by interrupts handling. > > > > In this cases the half bit time is not negligible and must be added to > > the transmission delay. > > > Sorry, but I cannot see any situation where that would happen in a > well-designed communication system. > > Oh, and it is actually essential that the receiver considers the > character finished half-way through the stop bit, and not at the end. > UART communication is intended to work despite small differences in the > baud rate - up to nearly 5% total error. By the time the receiver is > half way through the received stop bit, and has identified it is valid, > the sender could be finished the stop bit as its clock is almost 5% > faster (50% bit time over the full 10 bits). The receiver has to be in > the "watch for falling edge of start bit" state at this point, ready for > the transmitter to start its next frame. Yes, why would it not be? This is why there's no need for additional delays or "gaps" in the protocol for an async interface. -- 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 11:58 +0100 |
| Message-ID | <tk5fkb$2dl2i$2@dont-email.me> |
| In reply to | #31337 |
On 04/11/2022 18:11, Rick C wrote: > On Friday, November 4, 2022 at 12:36:51 PM UTC-4, David Brown wrote: >> On 04/11/2022 15:37, pozz wrote: >>> Il 04/11/2022 10:49, David Brown ha scritto: >>>> On 04/11/2022 08:45, pozz wrote: >>>>> Il 03/11/2022 16:26, David Brown ha scritto: >>>>>> On 03/11/2022 14:00, pozz wrote: >>>>>>> Il 03/11/2022 12:42, David Brown ha scritto: >>>>>>>> On 03/11/2022 00:27, Rick C wrote: >>>>>>>>> On Wednesday, November 2, 2022 at 4:49:16 PM UTC-4, David Brown >>>>>>>>> wrote: >>>>>>>>>> On 02/11/2022 20:20, Rick C wrote: >>>>>>>>>>> On Wednesday, November 2, 2022 at 5:28:21 AM UTC-4, David Brown >>>>>>>>>>> wrote: >>>>>>>>>>>> On 02/11/2022 06:28, Rick C wrote: >>>>>>> >>>>>>> >>>>>>>> You are correct that reception is in the middle of the stop bit >>>>>>>> (typically sub-slot 9 of 16). The first transmitter will be >>>>>>>> disabled at the end of the stop bit, and the next transmitter must >>>>>>>> not enable its driver until after that point - it must wait at >>>>>>>> least half a bit time after reception before starting >>>>>>>> transmission. (It can wait longer without trouble, which is why >>>>>>>> faster baud rates are less likely to involve any complications here.) >>>>>>> >>>>>>> Do you mean that RX interrupt triggers in the middle of the stop >>>>>>> bit and not at the end? Interesting, but are you sure this is the >>>>>>> case for every UART implemented in MCUs? >>>>>> >>>>>> Of course I'm not sure - there are a /lot/ of MCU manufacturers! >>>>>> >>>>>> UART receivers usually work in the same way, however. They have a >>>>>> sample clock running at 16 times the baud clock. The start bit is >>>>>> edge triggered to give the start of the character frame. Then each >>>>>> bit is sampled in the middle of its time slot - usually at subbit >>>>>> slots 7, 8, and 9 with majority voting. So the stop bit is >>>>>> recognized by subbit slot 9 of the tenth bit (assuming 8-bit, no >>>>>> parity) - the voltage on the line after that is irrelevant. (Even >>>>>> when you have two stop bits, receivers never check the second stop >>>>>> bit - it affects transmit timing only.) What purpose would there be >>>>>> in waiting another 7 subbits before triggering the interrupt, DMA, >>>>>> or whatever? >>>>> >>>>> There's no real purpose, but it's important to know exactly when the >>>>> RX interrupt is fired from the UART. >>>>> >>>> >>>> I think it is extremely rare that this is important. I can't think of >>>> a single occasion when I have thought it remotely relevant where in >>>> the stop bit the interrupt comes. >>>> >>>>> Usually the next transmitter starts transmitting after receiving the >>>>> last byte of the previous transmitter (for example, the slave starts >>>>> replying to the master after receiving the complete message from it). >>>>> >>>> >>>> No. Usually the next transmitter starts after receiving the last >>>> byte, and /then a pause/. There will always be some handling time in >>>> software, and may also include an explicit pause. Almost always you >>>> will want to do at least a minimum of checking of the incoming data >>>> before deciding on the next telegram to be sent out. But if you have >>>> very fast handling in relation to the baud rate, you will want an >>>> explicit pause too - protocols regularly specify a minimum pause (such >>>> as 3.5 character times for Modbus RTU), and you definitely want it to >>>> be at least one full character time to ensure no listener gets >>>> hopelessly out of sync. >>> >>> In theory, if all the nodes on the bus were able to change direction in >>> hardware (exactly at the end of the stop bit), you will not be forced to >>> introduce any delay in the transmission. >> Communication is about /reliably/ transferring data between devices. >> Asynchronous serial communication is about doing that despite slight >> differences in clock rates, differences in synchronisation, differences >> in startup times, etc. If you don't have idle pauses, you have almost >> zero chance of staying in sync across the nodes - and no chance at all >> of recovery when that happens. /Every/ successful serial protocol has >> pauses between frames - long enough pauses that the idle time could not >> possibly be part of a normal full speed frame. That does not just apply >> to UART protocols, or even just to asynchronous protocols. The pause >> does not have to be as long as 3.5 characters, but you need a pause - >> just as you need other error recovery handling. > > The "idle" pauses you talk about are accommodated with the start and stop bits in the async protocol. Every character is sent with a start bit which starts the timing. The stop bit is the "fluff" time for the next character to align to the next start bit. There is no need for the bus to be idle in the sense of no data being sent. If an RS-485 or RS-422 bus is biased for undriven times, there is no need for the driver to be on through the full stop bit. Once the stop bit has driven high, it can be disabled, such as in the middle of the bit. The there is a half bit time for timing skew, which amounts to 5%, between any two devices on the bus. > There are two levels of framing here, and two types of pauses. For UART communication, there is the "character frame" and the stop bit acts as a pause between characters. This is to give a minimum time to allow re-synchronisation of the clock timing at the receiver. It also forms, along with the start bit, a guaranteed edge for this re-synchronisation. More sophisticated serial protocols (CAN, Ethernet, etc.) do not need this because they have other methods of guaranteeing transitions and allowing the receiver to re-synchronise regularly - thus they do not need framing or idling at the character or byte level. But you always want framing and idling between message frames at a higher level. You always have an idle period that is longer than any valid character or part of a message. For example, in CAN communication you have "bit stuffing" any time you have 5 equal value bits in a row. This ensures that in the message, you never have more than 5 bits without a transition, and you don't need a fixed start or stop bit per byte in order to keep the receiver synchronised. But at the end of the CAN frame there is at least 10 bits of recessive (1) value. Any receiver that has got out of synchronisation, due to noise, startup timing, etc., will know it cannot possibly be in the middle of a frame and restart its receiver. In UART communication, this is handled at the protocol level rather than the hardware (though some UART hardware may have "idle detect" signals when more than 11 bits of high level are seen in a row). Some UART-based protocols also use a "break" signal between frames - that is a string of at least 11 bits of low level. If you do not have such pauses, and a receiver is out of step, it has no way to get into synchronisation again. Maybe you get lucky, but basically all it is seeing is a stream of high and low bits with no absolute indicator of position - and no way to tell what might be the start bit of a new character (rather than a 1 bit then a 0 bit within a character), never mind the start of a message. Usually you get enough pauses naturally in the communication, with delays between reception and reply. But if you don't have them, you must add them. Otherwise your communication will be too fragile to use in practice. You /need/ idle gaps to be able to resynchronise reliably in the face of errors (and there is /always/ a risk of errors). > >>> Many times I'm the author of a custom protocol because some nodes on a >>> shared bus, so I'm not forced to follow any specifications. When I >>> didn't introduce any delay in the transmission, I sometimes faced this >>> issue. In my experience, the bus is heterogeneous enough to have a fast >>> replying slave to a slow master. >>> >>> >>>>> Now I think of the issue related to a transmitter that delays a >>>>> little to turn around the direction of its transceiver, from TX to >>>>> RX. Every transmitter on the bus should take into account this delay >>>>> and avoid starting transmission too soon. >>>> >>>> They should, yes. The turnaround delay should be negligible in this >>>> day and age - if not, your software design is screwed or you have >>>> picked the wrong hardware. (Of course, you don't always get the >>>> choice of hardware you want, and programmers are often left to find >>>> ways around hardware design flaws.) >>> >>> Negligible doesn't mean anything. >> Negligible means of no significance in comparison to the delays you have >> anyway - either intentional delays in order to separate telegrams and >> have a reliable communication, or unavoidable delays due to software >> processing. > > The software on the PC is not managing the bus drivers. So software delays are not relevant to bus control timing. > > >>> If thre's a poor 8 bit PIC (previous >>> transmitter) clocked at 8MHz that changes direction in TXC interrupt >>> while other interrupts are active, and there's a Cortex-M4 clocked at >>> 200MHz (next transmitter), you will encounter this issue. >>> >> No, you won't - not unless you are doing something silly in your timing >> such as failing to use appropriate pauses or thinking that 10 µs >> turnarounds are a good idea at 9600 baud. And I did specify picking >> sensible hardware - 8-bit PICs were are terrible choice 20 years ago for >> anything involving high speed, and they have not improved. (Again - >> sometimes you don't have control of the hardware, and sometimes there >> can be other overriding reasons for picking something. But if your >> hardware is limited, you have to take that into account.) >>> This is more evident if, as you are saying, the Cortex-M4 is able to >>> start processing the message from the PIC at the midpoint of last stop >>> bit, while the PIC disables its driver at the *end* of the stop bit plus >>> an additional delay caused by interrupts handling. >>> >>> In this cases the half bit time is not negligible and must be added to >>> the transmission delay. >>> >> Sorry, but I cannot see any situation where that would happen in a >> well-designed communication system. >> >> Oh, and it is actually essential that the receiver considers the >> character finished half-way through the stop bit, and not at the end. >> UART communication is intended to work despite small differences in the >> baud rate - up to nearly 5% total error. By the time the receiver is >> half way through the received stop bit, and has identified it is valid, >> the sender could be finished the stop bit as its clock is almost 5% >> faster (50% bit time over the full 10 bits). The receiver has to be in >> the "watch for falling edge of start bit" state at this point, ready for >> the transmitter to start its next frame. > > Yes, why would it not be? This is why there's no need for additional delays or "gaps" in the protocol for an async interface. > It will be in the right state at the right time, as long as it enters it when the stop bit is identified (half-way through the stop bit) rather than artificially waiting for the end of the bit time. You need gaps in the character stream at a higher level, for error recovery.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-05 09:55 -0700 |
| Message-ID | <377ca797-345a-4daf-aa84-eb0e2fb889a6n@googlegroups.com> |
| In reply to | #31345 |
On Saturday, November 5, 2022 at 6:58:24 AM UTC-4, David Brown wrote: > On 04/11/2022 18:11, Rick C wrote: > > On Friday, November 4, 2022 at 12:36:51 PM UTC-4, David Brown wrote: > >> Communication is about /reliably/ transferring data between devices. > >> Asynchronous serial communication is about doing that despite slight > >> differences in clock rates, differences in synchronisation, differences > >> in startup times, etc. If you don't have idle pauses, you have almost > >> zero chance of staying in sync across the nodes - and no chance at all > >> of recovery when that happens. /Every/ successful serial protocol has > >> pauses between frames - long enough pauses that the idle time could not > >> possibly be part of a normal full speed frame. That does not just apply > >> to UART protocols, or even just to asynchronous protocols. The pause > >> does not have to be as long as 3.5 characters, but you need a pause - > >> just as you need other error recovery handling. > > > > The "idle" pauses you talk about are accommodated with the start and stop bits in the async protocol. Every character is sent with a start bit which starts the timing. The stop bit is the "fluff" time for the next character to align to the next start bit. There is no need for the bus to be idle in the sense of no data being sent. If an RS-485 or RS-422 bus is biased for undriven times, there is no need for the driver to be on through the full stop bit. Once the stop bit has driven high, it can be disabled, such as in the middle of the bit. The there is a half bit time for timing skew, which amounts to 5%, between any two devices on the bus. > > > There are two levels of framing here, and two types of pauses. > > For UART communication, there is the "character frame" and the stop bit > acts as a pause between characters. This is to give a minimum time to > allow re-synchronisation of the clock timing at the receiver. It also > forms, along with the start bit, a guaranteed edge for this > re-synchronisation. More sophisticated serial protocols (CAN, Ethernet, > etc.) do not need this because they have other methods of guaranteeing > transitions and allowing the receiver to re-synchronise regularly - thus > they do not need framing or idling at the character or byte level. > > But you always want framing and idling between message frames at a > higher level. You always have an idle period that is longer than any > valid character or part of a message. <<< snip >>> > 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"? > it has no > way to get into synchronisation again. Maybe you get lucky, but > basically all it is seeing is a stream of high and low bits with no > absolute indicator of position - and no way to tell what might be the > start bit of a new character (rather than a 1 bit then a 0 bit within a > character), never mind the start of a message. I have no idea what you are talking about. You have already explained above how every character is framed with a start and a stop bit. That gives a half bit time of clock misalignment to maintain sync. What would cause getting out of step? With the protocol involved, the characters for commands are unique. So if a devices sees noise on the line and does get out of sync at framing characters, it would simply not respond when spoken to. That would inherently cause a delay. So all data after that would be received correctly. The reason I'm using RS-422 instead of TTL, is the huge improvement in noise tolerance. So if the noise rate is enough to cause any noticeable problems, there's a bad design in the cabling or some fundamental flaw in the design and needs to be corrected. Actually, that makes me realize I need to have a mode where the comms are exercised and bit errors counted. > Usually you get enough pauses naturally in the communication, with > delays between reception and reply. But if you don't have them, you > must add them. Otherwise your communication will be too fragile to use > in practice. You /need/ idle gaps to be able to resynchronise reliably > in the face of errors (and there is /always/ a risk of errors). You haven't made your case. You've not explained how anything gets out of sync. What is your use case? But you finally mention "errors". Are you talking about bit errors in the comms? I've addressed that above. It is inherently handled in a command/response protocol, but since the problem of bit errors should be very, very infrequent, I'm not worried. > >> Oh, and it is actually essential that the receiver considers the > >> character finished half-way through the stop bit, and not at the end. That depends entirely on what is being done with the information. Start bit detection should start as early as possible. Enabling the transmitter driver after the last received character should not happen until the entire character is received, to the end of the stop bit. If the bus has fail-safe provisions, it's actually ok for the transmitter to disable the driver at the middle of the stop bit. The line will already be in the idle state and the passive fail-safe will maintain that. Less chance of bus contention if the next driver is enabled slightly before the end of the stop bit. > >> UART communication is intended to work despite small differences in the > >> baud rate - up to nearly 5% total error. By the time the receiver is > >> half way through the received stop bit, and has identified it is valid, > >> the sender could be finished the stop bit as its clock is almost 5% > >> faster (50% bit time over the full 10 bits). The receiver has to be in > >> the "watch for falling edge of start bit" state at this point, ready for > >> the transmitter to start its next frame. > > > > Yes, why would it not be? This is why there's no need for additional delays or "gaps" in the protocol for an async interface. > > > It will be in the right state at the right time, as long as it enters it > when the stop bit is identified (half-way through the stop bit) rather > than artificially waiting for the end of the bit time. > > You need gaps in the character stream at a higher level, for error recovery. If you have errors. I like systems without errors. Systems without errors are better in my opinion. I'm just sayin'. But it's handled anyway. -- 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 11:00 +0100 |
| Message-ID | <nnd$6f3f0caf$4d60a848@f05e10f4dcc9e72b> |
| In reply to | #31348 |
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. -- Stef Westheimer's Discovery: A couple of months in the laboratory can frequently save a couple of hours in the library.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-07 15:46 +0100 |
| Message-ID | <tkb5o6$3jsb2$1@dont-email.me> |
| In reply to | #31361 |
On 07/11/2022 11:00, 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. > An extra stop bit will help for this particular kind of error (and is a good idea if you get such errors often, as it will improve your percentage timing margins). An occasional pause of at least 11 bit times will help for all sorts of possible errors. Basically, it is a good idea to assume that sometimes things go wrong. There can be noise, interference, cosmic rays, power glitches - even in a system that has bug-free software, quality hardware, and no fallible human anywhere, there's always a risk of faults. That is why most serial protocols have CRC's or other checksums, and at least a basic "if there is no reply, repeat the telegram" handler. > 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. > >
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-07 08:05 -0800 |
| Message-ID | <eecc4db5-f637-44ac-ada8-899a8309ded7n@googlegroups.com> |
| In reply to | #31361 |
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. -- Rick C. +-++ Get 1,000 miles of free Supercharging +-++ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web