Re: Shared Communications Bus - RS-422 or RS-485

From	David Brown <david.brown@hesbynett.no>
Newsgroups	comp.arch.embedded
Subject	Re: Shared Communications Bus - RS-422 or RS-485
Date	2022-11-02 21:49 +0100
Organization	A noiseless patient Spider
Message-ID	<tjul46$18dkn$3@dont-email.me> (permalink)
References	<6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com> <tjtd7g$145er$1@dont-email.me> <b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>

Show all headers | View raw

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.)

Thread

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

csiph-web