onsdag den 30. november 2022 kl. 15.01.04 UTC+1 skrev Ricky:> On Wednesday, November 30, 2022 at 8:48:31 AM UTC-4, upsid...@downunder.com wrote: > > On Tue, 29 Nov 2022 18:00:06 -0800 (PST), Ricky > > <gnuarm.del...@gmail.com> wrote: > > > > >I have been digging into the various interfaces I could use and it seems when serial ports are involved, the handling of the data gets slow. It doesn't matter much what the claimed baud rate is on the serial port, there is significant overhead for handling a "message". > > Why do you insist of putting all your 256 slaves on a single serial > > bus and poll them sequentially? Any half duplex protocol is going to > > have a lot of overhead and at high nominal line speeds the effective > > throughput is going to be well below nominal speed. > Why is that? What is the nature of this, "overhead"? The slaves are FPGAs. They use a 33 MHz clock to talk to the UUT using an SPI type interface with two data in pins, so less than 1 uS to send the command and get the response. Where's this implicit overhead? > > The overhead is in the adapters. I have not heard back from FTDI, but people have mentioned that the USB bus operates on polling, and full-speed polls at up to 1,000 per second while hi-speed operates at up to 8,000 per second. If there are no other delays, that could give me around 1 Mbps throughput and 16 message pairs per UUT per second, which would be marginally adequate. > > Split your 256 slaves into say 8 buses of 32 slaves each or even 32 > > multidrop buses with 8 slaves each. > 32 buses are more than I have boards. > > You can then scan each bus > > independently and use a lower nominal line speed on each bus. > I still need an adapter that provides the 16 serial ports. I've asked a couple of vendors if this would work with their equipment and not heard back yet. > > On > > Windows, you could have 8 or 32 in depended processes, each scanning a > > single bus segment. > Zero need for multiple processes. > > The physical implementation could be a single 8 > > port or 32 port RS-485 PCIe card or four 8 port Ethernet/RS-485 > > converter. In the latter case for ultimate performance you could add > > two or four ethernet ports to the PC for driving one or two 8 port > > Eth/RS-485 adapters. > It's hard to fit a PCIe card in the laptops being used. > > Redo your speed calculations with 8 or 32 slaves on a single RS-485 > > bus. > That can't be done until I hear back from the vendors. > > Of course, if you like RS-232 (or RS-422) very much, get 256 RS-232 > > ports on PCIe cards or Eth/RS-232 converters. Primitive converters > > can be quite cheap these days. You may need some 32 port Ethernet > > switches also- If your current application only handles a single slave > > on one RS-232 line, you just need 256 Windows processes in the PC. If > > course, if your current process is boated, this may consume a lot of > > resources. > A PC with 256 cables running to 16 boards seems like a bit of overkill. > > I'm surprised the Ethernet adapter vendors didn't design their products to be a bit more speed aware. I can only think the data is going through a processor, when it should be handled in hardware, like an FPGA. I used to design network test gear, and we handled a 77 MHz interface by passing the data through the FPGA with the processor only managing the control and status from the UI. A 100 Mbps Ethernet interface should not have 1 ms delays to handle a single message. >you could have zero delays and it still wouldn't matter when the OS adds ms and timeslaces are tens of ms
Shared Communications Bus - RS-422 or RS-485
Started by ●November 2, 2022
Reply by ●November 30, 20222022-11-30
Reply by ●November 30, 20222022-11-30
On Wednesday, November 30, 2022 at 10:33:54 AM UTC-4, lang...@fonz.dk wrote:> onsdag den 30. november 2022 kl. 15.01.04 UTC+1 skrev Ricky: > > On Wednesday, November 30, 2022 at 8:48:31 AM UTC-4, upsid...@downunder.com wrote: > > > On Tue, 29 Nov 2022 18:00:06 -0800 (PST), Ricky > > > <gnuarm.del...@gmail.com> wrote: > > > > > > >I have been digging into the various interfaces I could use and it seems when serial ports are involved, the handling of the data gets slow. It doesn't matter much what the claimed baud rate is on the serial port, there is significant overhead for handling a "message". > > > Why do you insist of putting all your 256 slaves on a single serial > > > bus and poll them sequentially? Any half duplex protocol is going to > > > have a lot of overhead and at high nominal line speeds the effective > > > throughput is going to be well below nominal speed. > > Why is that? What is the nature of this, "overhead"? The slaves are FPGAs. They use a 33 MHz clock to talk to the UUT using an SPI type interface with two data in pins, so less than 1 uS to send the command and get the response. Where's this implicit overhead? > > > > The overhead is in the adapters. I have not heard back from FTDI, but people have mentioned that the USB bus operates on polling, and full-speed polls at up to 1,000 per second while hi-speed operates at up to 8,000 per second. If there are no other delays, that could give me around 1 Mbps throughput and 16 message pairs per UUT per second, which would be marginally adequate. > > > Split your 256 slaves into say 8 buses of 32 slaves each or even 32 > > > multidrop buses with 8 slaves each. > > 32 buses are more than I have boards. > > > You can then scan each bus > > > independently and use a lower nominal line speed on each bus. > > I still need an adapter that provides the 16 serial ports. I've asked a couple of vendors if this would work with their equipment and not heard back yet. > > > On > > > Windows, you could have 8 or 32 in depended processes, each scanning a > > > single bus segment. > > Zero need for multiple processes. > > > The physical implementation could be a single 8 > > > port or 32 port RS-485 PCIe card or four 8 port Ethernet/RS-485 > > > converter. In the latter case for ultimate performance you could add > > > two or four ethernet ports to the PC for driving one or two 8 port > > > Eth/RS-485 adapters. > > It's hard to fit a PCIe card in the laptops being used. > > > Redo your speed calculations with 8 or 32 slaves on a single RS-485 > > > bus. > > That can't be done until I hear back from the vendors. > > > Of course, if you like RS-232 (or RS-422) very much, get 256 RS-232 > > > ports on PCIe cards or Eth/RS-232 converters. Primitive converters > > > can be quite cheap these days. You may need some 32 port Ethernet > > > switches also- If your current application only handles a single slave > > > on one RS-232 line, you just need 256 Windows processes in the PC. If > > > course, if your current process is boated, this may consume a lot of > > > resources. > > A PC with 256 cables running to 16 boards seems like a bit of overkill. > > > > I'm surprised the Ethernet adapter vendors didn't design their products to be a bit more speed aware. I can only think the data is going through a processor, when it should be handled in hardware, like an FPGA. I used to design network test gear, and we handled a 77 MHz interface by passing the data through the FPGA with the processor only managing the control and status from the UI. A 100 Mbps Ethernet interface should not have 1 ms delays to handle a single message. > > > you could have zero delays and it still wouldn't matter when the OS adds ms and timeslaces are tens of msWhy do you think the OS will add ms? Have you run this sort of application before? -- Rick C. +--- Get 1,000 miles of free Supercharging +--- Tesla referral code - https://ts.la/richard11209
Reply by ●November 30, 20222022-11-30
On Wednesday, November 30, 2022 at 6:01:04 AM UTC-8, Ricky wrote:> On Wednesday, November 30, 2022 at 8:48:31 AM UTC-4, upsid...@downunder.com wrote: > > On Tue, 29 Nov 2022 18:00:06 -0800 (PST), Ricky > > <gnuarm.del...@gmail.com> wrote: > > > > >I have been digging into the various interfaces I could use and it seems when serial ports are involved, the handling of the data gets slow. It doesn't matter much what the claimed baud rate is on the serial port, there is significant overhead for handling a "message".> The overhead is in the adapters. I have not heard back from FTDI, but people have mentioned that the USB bus operates on polling, and full-speed polls at up to 1,000 per second while hi-speed operates at up to 8,000 per second. If there are no other delays, that could give me around 1 Mbps throughput and 16 message pairs per UUT per second, which would be marginally adequate.Maybe, instead of USB intermediate connect, you should have (the master) running an RS422 card, for expandability maybe a four-port version like this <https://fastcomproducts.com/products/fastcom-4224-pcie/> and have the slaves reply to the buffer memories in its UART <https://assets.maxlinear.com/web/documents/xr17v358.pdf> Those smart UARTs have big FIFOs, and lots of 'em. No USB-style latency involved. The slaves have to tristate their drive, but the master doesn't, so off-the-shelf RS422 should be OK.
Reply by ●December 1, 20222022-12-01
On Wednesday, November 30, 2022 at 3:48:40 PM UTC-4, whit3rd wrote:> On Wednesday, November 30, 2022 at 6:01:04 AM UTC-8, Ricky wrote: > > On Wednesday, November 30, 2022 at 8:48:31 AM UTC-4, upsid...@downunder.com wrote: > > > On Tue, 29 Nov 2022 18:00:06 -0800 (PST), Ricky > > > <gnuarm.del...@gmail.com> wrote: > > > > > > >I have been digging into the various interfaces I could use and it seems when serial ports are involved, the handling of the data gets slow. It doesn't matter much what the claimed baud rate is on the serial port, there is significant overhead for handling a "message". > > The overhead is in the adapters. I have not heard back from FTDI, but people have mentioned that the USB bus operates on polling, and full-speed polls at up to 1,000 per second while hi-speed operates at up to 8,000 per second. If there are no other delays, that could give me around 1 Mbps throughput and 16 message pairs per UUT per second, which would be marginally adequate. > Maybe, instead of USB intermediate connect, you should have (the master) running > an RS422 card, for expandability maybe a four-port version like this > > <https://fastcomproducts.com/products/fastcom-4224-pcie/> > > and have the slaves reply to the buffer memories in its UART > > <https://assets.maxlinear.com/web/documents/xr17v358.pdf>Sounds nice, but they seem to be conflicted about what they are claiming. From the web page, "Maximum data rates are estimates. They are greatly affected by a number of different factors. See the data rates section of the manual for more details." So I click on the manual link and find, "The Fastcom: 422/4-PCIe and 422/8-PCIe (referred to hereafter as Fastcom: 422/X-PCIe) are capable of operating at virtually any baud rate up to an astounding maximum serial data rate of 25 Mbps. There is no fine print or asterisks pointing to notes; this card is capable of running at the maximum data rate, without any jumpers or hardware changes, right out of the box." So they don't seem to be sure of themselves. At least it doesn't require me to write software. A vendor of a multi-port Ethernet box is suggesting I get around their limitations, but writing my own software to run on their box! These PCIe boards would have the best chance of maximum throughput I'm sure. Nothing to get in the way other than my application and their drivers.> Those smart UARTs have big FIFOs, and lots of 'em. No USB-style latency involved. > > The slaves have to tristate their drive, but the master doesn't, so off-the-shelf RS422 > should be OK.The problem is, I don't have a PCIe slot on the laptops to plug into. They also offer a single port USB device that claims high baud rates, but baud rate is not the issue. Data rate is the issue, or more accurately, message rate. I suppose the laptops can be canned and a commercial computer used. Maybe use the commercial computer headless and Ethernet it to the laptop as the UI. Ugh, more complexity. Monitors are cheap and LARGE! So the laptops could be deep sixed. Now I just need a good commercial PC. Thanks for the info. This might be the best way to go so far. I just wish they had something other than that damn connector on the back. I'll need to adapt the DB9 connectors with an inline adapter cable. I think I just threw up in my mouth! I'll have to write them to see if they think this will work. I shouldn't even need a multiport card for this. One port running at anything over 1.5 Mbps would give me the speed I'd like, if there's not significant overhead. I don't know if I've mentioned this, but I can get around the message level delays... possibly, by sending a command to all the slaves at once. Blast out 128 commands, and let the slaves reply while I'm still transmitting. I had been using the ping-pong sequencing to manage collisions on the RX bus (to the master). I can use a daisy chained hand shake line, to indicate to the first board that I am sending commands. When the first slave receives its command, it will send its reply, then flag the next board that it can reply, etc. When the master sees all the slave responses, the handshake is removed until the next command is sent. This could even be used with a single broadcast command, rather than addressing each slave. In particular, this would help with enumeration. Facilitating the protocol with the prioritization of responses, could greatly improve the responsiveness of the USB implementation. The large string would be a single message, which might be sent in multiple chunks because of the size (128 * 15 char = ~2048 char), still, a big improvement over 15 char messages. It's very late and I'm very tired. I hope I wasn't rambling too much. A lot of this was stream of consciousness. -- Rick C. +--+ Get 1,000 miles of free Supercharging +--+ Tesla referral code - https://ts.la/richard11209
Reply by ●December 2, 20222022-12-02
On 2022-12-01, Ricky <gnuarm.deletethisbit@gmail.com> wrote:> > The problem is, I don't have a PCIe slot on the laptops to plug > into. They also offer a single port USB device that claims high baud > rates, but baud rate is not the issue. Data rate is the issue, or > more accurately, message rate.How fast do you want / need? -- Jasen.
Reply by ●December 2, 20222022-12-02
On Thursday, December 1, 2022 at 11:30:44 PM UTC-5, Jasen Betts wrote:> On 2022-12-01, Ricky <gnuarm.del...@gmail.com> wrote: > > > > > The problem is, I don't have a PCIe slot on the laptops to plug > > into. They also offer a single port USB device that claims high baud > > rates, but baud rate is not the issue. Data rate is the issue, or > > more accurately, message rate. > How fast do you want / need?I'd like to get ~30 message pairs per second per end point. With 128 end points, that's around 4,000 message pairs per second or 8,000 messages (4,000 in each directon). 15 chars per message is 150 bits in each direction, for around 600,000 kbps each way, but they are essentially half duplex, so the bit rate would need to be above 1.2 Mbps. The bit rate is easy to find, but everyone has overhead in handling the messages. So the result is either slower, or much slower. I'm starting to look into what was suggested quite some time back, an Ethernet adapter on each test fixture board. Then, even with a lower message handling rate on each port, it's made up by the quantity of ports... unless there are other software limitations in the PC with sending short messages. One way around the short message thing, is to find a way to concatenate the messages. Commands from the master could easily be sent out as one long message. The replies from the slaves need to be coordinated to prevent multiple slaves trying to drive the bus at the same time. The RJ-45 cable can have two additional RS-422 pairs, which would carry a daisy chain talk enable signal. The master sends the aggregate message, or maybe a broadcast message and enables the first slave card. The first slave sends all of its replies (more than one endpoint per card) and then passes the enable to the next card which does similarly. Someone suggested the master could insert some sort of fill data into it's aggregate message, that would allow for the slave reply to be sent. So the next slave doesn't receive its command until the previous slave has already sent its reply. I'm concerned about this being someone invisible and hard to debug. The slaves could monitor the reply stream, so they know when it is their turn. It would either wait for the final reply from the previous board based on the reply id number, or the previous board could send a simple command to "release" the bus to the next number slave. That could be a bit tricky, if the test fixture boards are not sequentially numbered. I'm thinking of using a thumbwheel on the front panel to set the board ID number. The operator would need to change all the higher numbered boards if one is removed. Not huge, but a bit of a PITA. In normal operation, this would not be a typical thing. It would also require the slaves to monitor the reply data as well as the command data (two separate data paths, 4-wire RS-485 ). Maybe I should simply get an FTDI serial USB interface and see how fast it runs. There is no actual speed requirement as yet. Maybe I need to get the software written and test it out, rather than spending so much time with this detail. -- Rick C. +-+- Get 1,000 miles of free Supercharging +-+- Tesla referral code - https://ts.la/richard11209
Reply by ●December 2, 20222022-12-02
On Friday, December 2, 2022 at 5:01:14 AM UTC-5, upsid...@downunder.com wrote:> On Thu, 1 Dec 2022 23:25:03 -0800 (PST), Ricky > <gnuarm.del...@gmail.com> wrote: > > >On Thursday, December 1, 2022 at 11:30:44 PM UTC-5, Jasen Betts wrote: > >> On 2022-12-01, Ricky <gnuarm.del...@gmail.com> wrote: > >> > >> > > >> > The problem is, I don't have a PCIe slot on the laptops to plug > >> > into. They also offer a single port USB device that claims high baud > >> > rates, but baud rate is not the issue. Data rate is the issue, or > >> > more accurately, message rate. > >> How fast do you want / need? > > > >I'd like to get ~30 message pairs per second per end point. With 128 end points, that's around 4,000 message pairs per second or 8,000 messages (4,000 in each directon). 15 chars per message is 150 bits in each direction, for around 600,000 kbps each way, but they are essentially half duplex, so the bit rate would need to be above 1.2 Mbps. > One way to access a large number of stations with typically only a few > bits or bytes each at very short cycle times is to use EtherCAT > https://en.wikipedia.org/wiki/EtherCAT > > A single Ethernet frame is daisy chained through all station. Each > station can extract bits from the frame and replace with their input > data to be sent away. The propagation delay in each station is just a > few bit times on 100 Mbit/s Ethernet. > > The system works just like a local train in which each person just > travels between a few stations.The claims seem to support that it would be good for my application, but a quick look didn't show many vendors. I found these guys, but they sure don't put much information on their web pages. https://www.anybus.com/technical-support/pages/files-and-documentation---compactcom?ordercode=AB6677 They use a bunch of canned images on their support page, the kind that you get with low cost web sites. More importantly, I found a document for "Host Application Implementation Guide" and it looks like this would be a lot of work to come up the learning curve. I did find where they can use a serial interface. What I have not found, is what would be needed on the PC side. On the PC it needs to be a COM port. I see no indication that this software is provided. Maybe I'll look at this later. Right now it is too much work just to get up the learning curve. But thanks for the info. -- Rick C. +-++ Get 1,000 miles of free Supercharging +-++ Tesla referral code - https://ts.la/richard11209
Reply by ●December 2, 20222022-12-02
On Friday, December 2, 2022 at 5:34:40 AM UTC-5, upsid...@downunder.com wrote:> On Wed, 30 Nov 2022 06:00:58 -0800 (PST), Ricky > <gnuarm.del...@gmail.com> wrote: > > >On Wednesday, November 30, 2022 at 8:48:31 AM UTC-4, upsid...@downunder.com wrote: > >> On Tue, 29 Nov 2022 18:00:06 -0800 (PST), Ricky > >> <gnuarm.del...@gmail.com> wrote: > >> > >> >I have been digging into the various interfaces I could use and it seems when serial ports are involved, the handling of the data gets slow. It doesn't matter much what the claimed baud rate is on the serial port, there is significant overhead for handling a "message". > >> Why do you insist of putting all your 256 slaves on a single serial > >> bus and poll them sequentially? Any half duplex protocol is going to > >> have a lot of overhead and at high nominal line speeds the effective > >> throughput is going to be well below nominal speed. > > > >Why is that? What is the nature of this, "overhead"? The slaves are FPGAs. They use a 33 MHz clock to talk to the UUT using an SPI type interface with two data in pins, so less than 1 uS to send the command and get the response. Where's this implicit overhead? > A FPGA is nice to receive bytes and do some ECC test and reply back > with ACK/NAK. If the slave can receive nultiple types of requests, > someone has to decode the request and generate a response to the > request. Fine if the FPGA can do this without any CPU action on the > slave.There is an existing test fixture that tests one UUT over a serial port from the PC. The FPGA implements the UART and processes commands from the PC and forms the reply returned to the PC. I don't get why this would be of any concern. The FPGA does this without involving the CPU on the slave, because there is no CPU on the slave. This is a dumb device controlled by the PC.> To do this on the FPGA you may have to load the response into the FPGA > _before_ the master sends the request. If the master can send > different requests in any order, responses to _all_ these requests > must be laded into the FPGA before any request is received.??? I have no idea what you are trying to say. What are you talking about loading into the FPGA??? Maybe this will help. Currently, the commands are just access to registers. There are registers in the FPGA on the test fixture. There are registers in the UUT. The UUT is access through a custom 66 Mbps serial port. The PC sends a command something like 13 84 W<cr><lf> and the slave answers 13 84 W 34<cr><lf> 13 is the address, 84 is the data and 'W' indicates a write. The slave echos back the command with the data written, (an actual read operation, not just the same data that was received) to verify all the information was transmitted correctly. This is all ASCII data which the FPGA converts to binary before accessing the appropriate register. I'll skip the details of the serial interface to the UUT registers, but the ASCII protocol mimics it. There will be a few characters added to incorporate an address for an endpoint. The current protocol uses a select command to indicate the endpoint (test fixture FPGA, UUT1 or UUT2, there a second UUT socket on the board that has not been used yet). I'm thinking the new protocol will be more efficient with an address added for the end point. 01 23 45 W<cr><lf> from the PC and the reply 01 23 45 W<cr><lf> 67 See why there's no CPU? Very simple to implement.> For instance with Profibus DP you can send up to 128 bytes to the > slave and in the response upload 128 bytes in a single transaction. > There are fixed buffers for up/download, which are handled by an FPGA. > The buffers are processed until the slave is accessed again (double > buffering).Total excess for this application. Most of the work is things like "set an output bit high and verify on the input", which would take some 10 or so register accesses I would estimate.> Profibus DP is an RS-485 environment with asynchronous characters with > a few bytes overhead. On 1.5 Mbit/s about 4 ms cycle time can be done > with a few slaves and short messages. At 12 Mbit/s cycle times down to > 1 ms are possible.Even 1 ms cycle time on a single message is a bit slower than I'm shooting. With 128 UUTs (which is really 256 end points if you count the test fixture controllers) the message rate per UUT drops to 8 per second. Still, that might serve adequately. I'll be adding more tests to this iteration, so the testing will be slower, but testing 128 units at once! More importantly, the testing and overnight burn in will all be done on the same fixture, so the boards are inserted and removed just once. k I'm spending too much time on this detail. A good method, without a lot of design work, will be found, even if its a bit slower. If I have to, I'll use a 16 port Ethernet box, or use Ethernet to serial modules on each test fixture board. -- Rick C. ++-- Get 1,000 miles of free Supercharging ++-- Tesla referral code - https://ts.la/richard11209
Reply by ●December 2, 20222022-12-02
On Fri, 2 Dec 2022 10:09:50 -0800 (PST), Ricky <gnuarm.deletethisbit@gmail.com> wrote:>On Friday, December 2, 2022 at 5:01:14 AM UTC-5, upsid...@downunder.com wrote: >> On Thu, 1 Dec 2022 23:25:03 -0800 (PST), Ricky >> <gnuarm.del...@gmail.com> wrote: >> >> >On Thursday, December 1, 2022 at 11:30:44 PM UTC-5, Jasen Betts wrote: >> >> On 2022-12-01, Ricky <gnuarm.del...@gmail.com> wrote: >> >> >> >> > >> >> > The problem is, I don't have a PCIe slot on the laptops to plug >> >> > into. They also offer a single port USB device that claims high baud >> >> > rates, but baud rate is not the issue. Data rate is the issue, or >> >> > more accurately, message rate. >> >> How fast do you want / need? >> > >> >I'd like to get ~30 message pairs per second per end point. With 128 end points, that's around 4,000 message pairs per second or 8,000 messages (4,000 in each directon). 15 chars per message is 150 bits in each direction, for around 600,000 kbps each way, but they are essentially half duplex, so the bit rate would need to be above 1.2 Mbps. >> One way to access a large number of stations with typically only a few >> bits or bytes each at very short cycle times is to use EtherCAT >> https://en.wikipedia.org/wiki/EtherCAT >> >> A single Ethernet frame is daisy chained through all station. Each >> station can extract bits from the frame and replace with their input >> data to be sent away. The propagation delay in each station is just a >> few bit times on 100 Mbit/s Ethernet. >> >> The system works just like a local train in which each person just >> travels between a few stations. > >The claims seem to support that it would be good for my application, but a quick look didn't show many vendors. I found these guys, but they sure don't put much information on their web pages. > >https://www.anybus.com/technical-support/pages/files-and-documentation---compactcom?ordercode=AB6677AnyBus is a company selling fiedbus converters from any technology through their internal protocol to an other fiedbus technology. Check the Beckhoff site for information about EtherCAT.> >They use a bunch of canned images on their support page, the kind that you get with low cost web sites. > >More importantly, I found a document for "Host Application Implementation Guide" and it looks like this would be a lot of work to come up the learning curve. I did find where they can use a serial interface. What I have not found, >is what would be needed on the PC side.On the master side you should need a standard Ethernet port to launch the "local train", which runs through the special EtherCAT "slave stations" before returning to the master port. For the slaves, special chips are needed.>On the PC it needs to be a COM port. I see no indication that this software is provided.What COM port ? Possibly for one time configuration of the slave chips ? Or are you thinking about some AnyBus converter with a serial port ?>Maybe I'll look at this later. Right now it is too much work just to get up the learning curve. But thanks for the info.The learning curve may be too steep for a one-off project. *** I still do not understand why you would like to put all slaves on a _single_ RS-485 bus. Split the large number of slaves between 8. 16 or 32 independent RS-485 buses and run each bus with an independent Windows process. You could even use multiple PCs, if driving all buses from a single PC is too much.
Reply by ●December 2, 20222022-12-02
On Thursday, December 1, 2022 at 1:20:47 AM UTC-8, Ricky wrote:> On Wednesday, November 30, 2022 at 3:48:40 PM UTC-4, whit3rd wrote: > > On Wednesday, November 30, 2022 at 6:01:04 AM UTC-8, Ricky wrote:> > > The overhead is in the adapters. I have not heard back from FTDI, but people have mentioned that the USB bus operates on polling, and full-speed polls at up to 1,000 per second while hi-speed operates at up to 8,000 per second. If there are no other delays, that could give me around 1 Mbps throughput and 16 message pairs per UUT per second, which would be marginally adequate.> > Maybe, instead of USB intermediate connect, you should have (the master) running > > an RS422 card, for expandability maybe a four-port version like this > > > > <https://fastcomproducts.com/products/fastcom-4224-pcie/> > > > > and have the slaves reply to the buffer memories in its UART > > > > <https://assets.maxlinear.com/web/documents/xr17v358.pdf>> The problem is, I don't have a PCIe slot on the laptops to plug into. They also offer a single port USB device that claims high baud rates, but baud rate is not the issue. Data rate is the issue, or more accurately, message rate. I suppose the laptops can be canned and a commercial computer used.Do the laptops offer an open m.2 socket? <https://accesio.com/product/m-2-icm422-4/> It's also possible, sometimes, that the laptop has a dock connector (but using that is perilous, they're all proprietary, thus will obsolesce rapidly).
