Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #31415
| Newsgroups | comp.arch.embedded |
|---|---|
| Date | 2022-11-29 23:33 -0800 |
| Message-ID | <1bf6f488-e849-4cfb-8625-ef968030cfban@googlegroups.com> (permalink) |
| Subject | Serial Bus Speed on PCs |
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
I am using laptops to control test fixtures via a USB serial port. I'm looking at combining many test fixtures in one chassis, controlled over one serial port. The problem I'm concerned about is not the speed of the bus, which can range up to 10 Mbps. It's the interface to the serial port. The messages are all short, around 15 characters. The master PC addresses a slave and the slave promptly replies. It seems this message level hand shake creates a bottle neck in every interface I've looked at. FTDI has a high-speed USB cable that is likely limited by the 8 kHz polling rate. So the message and response pair would be limited to 4 kHz. Spread over 256 end points, that's only 16 message pairs a second to each target. That might be workable if there were no other delays. While investigating other units, I found some Ethernet to serial devices and found some claim the serial port can run at up to 3.7 Mbps. But when I contacted them, they said each message has a 1 ms delay, so that's only 500 pairs per second, or maybe 2 pairs per second per channel. That's slow! They have multi-port boxes, up to 16, so I've asked them if they will run with a larger aggregate rate, or if the delay on one port impacts all of them. I've also found another vendor with a similar product, and I've asked about that too. I'm surprised and disappointed the Ethernet devices have such delays. I would have expected them to work better given their rather high prices. I could add a module, to interface between the PC serial port and the 16 test fixtures. It would allow the test application on the PC to send messages to all 16 test fixtures in a row. The added module would receive on separate lines, the 16 responses and stream them out to the port to the PC as one, continuous message. This is a bit messier since now, the 16 lines from this new module would need to be marked since they have to plug into the right test fixture each day. Or, if I could devise a manner of assigning priority, the slaves could all manage the priority themselves and still share the receive bus to the serial port on the PC. Again, this would look like one long message to the port and the PC. The application program would see the individual messages and parse them separately. Many of the commands from the PC could actually be shortened to a single, broadcast command since the same tests are done on all targets in parallel. So using an RJ-45 connector, there would be the two pairs for the serial port, and two pairs for the priority daisy-chain. I guess I'm thinking out loud here. LOL, so now I'm leaning back toward the USB based FTDI RS-422 cable and a priority scheme so every target gets many, more commands per second. I just ran the math, and this would be almost 20,000 bits per command. Try to run that at 8,000 times per second and a 100 Mbps Ethernet port won't keep up. I've written to FTDI about the actual throughput I can expect with their cables. We'll see what they come back with. -- Rick C. - Get 1,000 miles of free Supercharging - Tesla referral code - https://ts.la/richard11209
Back to comp.arch.embedded | Previous | Next — Next in thread | Find similar | Unroll thread
Serial Bus Speed on PCs Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-29 23:33 -0800
Re: Serial Bus Speed on PCs Richard Damon <Richard@Damon-Family.org> - 2022-11-30 07:42 -0500
Re: Serial Bus Speed on PCs Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-30 06:21 -0800
Re: Serial Bus Speed on PCs Bernd Linsel <bl1-removethis@gmx.com> - 2022-11-30 16:11 +0100
Re: Serial Bus Speed on PCs Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-30 07:58 -0800
Re: Serial Bus Speed on PCs David Brown <david.brown@hesbynett.no> - 2022-11-30 18:14 +0100
Re: Serial Bus Speed on PCs Dimiter_Popoff <dp@tgi-sci.com> - 2022-11-30 20:52 +0200
Re: Serial Bus Speed on PCs Rick C <gnuarm.deletethisbit@gmail.com> - 2022-12-03 12:42 -0800
Re: Serial Bus Speed on PCs Rick C <gnuarm.deletethisbit@gmail.com> - 2022-12-03 12:55 -0800
Re: Serial Bus Speed on PCs David Brown <david.brown@hesbynett.no> - 2022-12-04 13:21 +0100
Re: Serial Bus Speed on PCs Rick C <gnuarm.deletethisbit@gmail.com> - 2022-12-04 08:54 -0800
Re: Serial Bus Speed on PCs David Brown <david.brown@hesbynett.no> - 2022-12-05 08:57 +0100
Re: Serial Bus Speed on PCs Rick C <gnuarm.deletethisbit@gmail.com> - 2022-12-05 14:12 -0800
Re: Serial Bus Speed on PCs antispam@math.uni.wroc.pl - 2022-12-01 01:08 +0000
Re: Serial Bus Speed on PCs Rick C <gnuarm.deletethisbit@gmail.com> - 2022-12-01 02:48 -0800
Re: Serial Bus Speed on PCs David Brown <david.brown@hesbynett.no> - 2022-12-02 13:30 +0100
Re: Serial Bus Speed on PCs Rick C <gnuarm.deletethisbit@gmail.com> - 2022-12-02 09:01 -0800
Re: Serial Bus Speed on PCs antispam@math.uni.wroc.pl - 2022-12-04 21:30 +0000
Re: Serial Bus Speed on PCs Rick C <gnuarm.deletethisbit@gmail.com> - 2022-12-04 14:57 -0800
Re: Serial Bus Speed on PCs antispam@math.uni.wroc.pl - 2022-12-05 03:33 +0000
Re: Serial Bus Speed on PCs Rick C <gnuarm.deletethisbit@gmail.com> - 2022-12-04 22:39 -0800
Re: Serial Bus Speed on PCs antispam@math.uni.wroc.pl - 2022-12-06 02:30 +0000
Re: Serial Bus Speed on PCs Rick C <gnuarm.deletethisbit@gmail.com> - 2022-12-05 23:41 -0800
Re: Serial Bus Speed on PCs David Brown <david.brown@hesbynett.no> - 2022-12-06 13:32 +0100
Re: Serial Bus Speed on PCs Rick C <gnuarm.deletethisbit@gmail.com> - 2022-12-06 18:03 -0800
Re: Serial Bus Speed on PCs David Brown <david.brown@hesbynett.no> - 2022-12-07 08:08 +0100
Re: Serial Bus Speed on PCs Rick C <gnuarm.deletethisbit@gmail.com> - 2022-12-07 03:36 -0800
Re: Serial Bus Speed on PCs Andrew Smallshaw <andrews@sdf.org> - 2022-12-05 09:58 +0000
Re: Serial Bus Speed on PCs Rick C <gnuarm.deletethisbit@gmail.com> - 2022-12-05 14:03 -0800
csiph-web