Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #31422

Re: Serial Bus Speed on PCs

Show all headers | View raw

Rick C <gnuarm.deletethisbit@gmail.com> wrote:
> 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. 

I am not sure if you get that there are two issues: througput and latency.
If you wait for answer before sending next request you will be bounded
by latency.  OTOH if you fire several request without waiting, then
you will be limited by througput.  With relatively cheap convertors
on Linux to handle 10000 roundtrips for 15 bytes messages I need
the following times:

CH340 2Mb/s, waiting,               6.890s
CH340 2Mb/s, overlapped             1.058s
CP2104 2Mb/s, waiting,              2.514s
CP2104 2Mb/s, overlapped            1.214s

The other end was STM32F030, which was simply replaying back
received characters.

Note: there results are not fully comparable.  Apparently CH340
will silently drop excess characters, so for overalapped operation
I simply sent more charactes than I read.  OTOH CP2104 seem to
stall when its receive buffer overflows, so I limited overlap to
avoid stalls.  Of course real application would need some way
to ensure that receive buffers do not overflow.

So, you should be easily able to handle 10000 round trips
per second provided there is enough overlap.  For this
you need to ensure that only one device is transmitting to
PC.  If you have several FPGA-s on a single board, coordinating
them should be easy.  Of couse, you need some free pins and
extra tracks.  I would use single transceiver per board,
depending on coordination to ensure that only one FPGA
controls transceiver at given time.  Anyway, this would
allow overlapped transmisson to all devices on single
board.  With multiple boards you would need some hardware
or software protocol decide which board can transmit.
On hardware side a single pair of extra wires could
carry needed signals (that is your "priority daisy chain").

As other suggested you could use multiple convertors for
better overlap.  My convertors are "full speed" USB, that
is they are half-duplex 12 Mb/s.  USB has significant
protocol overhead, so probably two 2 Mb/s duplex serial
convertes would saturate single USB bus.  In desktops
it is normal to have several separate USB controllers
(buses), but that depends on specific motherboard.
Theoreticaly, when using "high speed" USB converters,
several could easily work from single USB port (provided
that you have enough places in hub(s)).

An extra thing: there are reasonably cheap PC compatible
boards, supposedly they are cheaper and more easy to buy
than Raspberry Pi (but I did not try buy them).  If you
need really large scale you could have a single such board
per batch of devices and run copy of your program there.  And
a single laptop connecting to satelite board via ethernet
and collecting results.

-- 
                              Waldek Hebisch

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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