Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #31350
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Shared Communications Bus - RS-422 or RS-485 |
| Date | 2022-11-05 19:57 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <tk6bmk$2k36a$3@dont-email.me> (permalink) |
| References | (8 earlier) <tk2fuo$1nau3$1@dont-email.me> <tk2n7g$1o0ct$1@dont-email.me> <05989871-748b-4b08-b564-84a323418b45n@googlegroups.com> <tk5iha$2e64h$1@dont-email.me> <55844769-5be7-47e9-b849-396e655188abn@googlegroups.com> |
On 05/11/2022 18:23, Rick C wrote: > On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote: >> On 04/11/2022 16:40, Rick C wrote: >>> On Friday, November 4, 2022 at 5:49:42 AM UTC-4, David Brown wrote: >>>> 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. >>> >>> You are making an assumption of implementation. There is a processor in the USB cable that is implementing the UART. The driver enable control is most likely is implemented there. It would be pointless and very subject to failure, to require the main CPU to handle this timing. There's no reason to expect the driver disable to take more than a fraction of a bit time, so the "UART" needs a timing signal to indicate when the stop bit has been completed. >>> >> I'm making the assumption that you are using appropriate hardware. No >> processor, just a USB device that has a "transmitter enable" signal on >> its UART. > > How can there not be a processor? I'm using a split bus, with the PC master driving all the slave receivers and all the slave transmitters sharing the PC receive bus. > > Is the PC not a processor? Sure, the PC is a processor. It sends a command to the USB device, saying "send these N bytes of data out on the UART ...". The USB device is /not/ a processor - it is a converter between USB and UART. And it is the USB device that controls the transmit enable signal to the RS-485/RS-422 driver. There is no software on any processor handling the transmit enable signal - the driver is enabled precisely when the USB to UART device is sending data on the UART. > > The slaves have no USB. > > >> I'm getting the impression that you have never heard of such a UART >> (either in a USB-to-UART device, or as a UART peripheral elsewhere), and >> assume software has to be involved in enabling and disabling the >> transmitter. Please believe me when I say such UARTs /do/ exist - and >> the FTDI examples I keep giving are a case in point. > > You are not being clear. I don't know and don't care what is inside the FTDI device. That's just magic to me, or it's like something inside the black hole, unknowable. More importantly, there is no transmitter enable on the RS-422 driver in the FTDI device, because it's not tristateable. > As I mentioned earlier, this thread is getting seriously mixed-up. The transmit enable discussion started with /RS-485/ - long before you decided to use a hybrid bus and a RS-422 cable. You were concerned about how the PC controlled the transmitter enable for the RS-485 driver, and I have been trying to explain how this works when you use a decent UART device. You only confuse yourself when you jump to discussing RS-422 here, in this bit of the conversation. The FTDI USB to UART chip (or chips - they have several) provides a "transmitter enable" signal that is active with exactly the right timing for RS-485. This is provided automatically, in hardware - no software involved. If you connect one of these chips to an RS-485 driver, you immediately have a "perfect" RS-485 interface with automatic direction control. If you connect one of these chips to an RS-422 driver, you don't need direction control as RS-422 has two fixed-direction pairs. If you buy a pre-built cable from FTDI, it will have one of these driver chips connected appropriately. > >>> The timing issue is not about loading another character into the transmit FIFO. It's about controlling the driver enable. >>> >> Yes, and it is a /solved/ issue if you pick the right hardware. >>> >>>> 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. >>> >>> Your numbers are only relevant to Modbus. The only requirement is that no two drivers are on the bus at the same time, which requires zero delay from the end of the previous stop bit and the beginning of the next start bit. This is why the timing indication from the UART needs to be the end of the stop bit, not the middle. >>> >> A single transmitter, while sending a multi-character message, does not >> need any delay between sending the full stop bit and starting the next >> start bit. That is obvious. And that is why a "transmission complete" >> signal comes at the end of the start bit sent on the transmitter side. > > ??? Are you talking about the buffer management signals for the software? > No. > >> On the receiver side, the "byte received" signal comes in the /middle/ >> of the stop bit, as seen by the receiver, because that could be at the >> /end/ of the stop bit as seen by the transmitter due to clock >> differences. (It could also be at the /start/ of the stop bit as seen >> by the transmitter.) The receiver has to prepare for the next incoming >> start bit as soon as it identifies the stop bit. > > Again, this depends entirely on what this signal is used for. For entering the state of detecting the next start bit, yes, that is the perceived middle of the stop bit. > Yes. > >> But you want an extra delay of at least 11 bits (a character frame plus >> a buffer for clock speed differences) between messages - whether they >> are from the same transmitter or a different transmitter - to allow >> resynchronisation if something has gone wrong. > > Again, you seem to not understand the use case. Yes, I understand your new use case, as well as the original discussions and the side discussions. I don't think /you/ understand that there had been a change, because you seem to imagine everything in the thread is in reference to your current solution. > The split bus never has messages back to back on the same pair. It gets confusing because so many people have tried to talk up RS-485 using a single pair. In that case, everything is totally different. Slaves need to wait until the driver has stopped driving the bus, which means an additional bit time to account for timing errors. But RS-485 is not being used. Each bus is simplex, implementing a half-duplex protocol on the two buses. > I agree. I know how your solution works, and have said many times that I think it sounds quite a good idea for the task in hand. > >> I've explained in other posts why inter-message pauses are needed for >> reliable UART communication protocols. They don't /need/ to be as long >> as 35 bit times as Modbus specifies - 11 bit times is the minimum. If >> you don't understand this by now, then we should drop this point. > > You are assuming a need for error tolerance. But a munged message is the problem, not resyncing. A protocol to detect an error and retransmit is very messy. I've tried that before and it messes up the protocol badly. > All communications have failures. Accept that as a principle, and understand how to deal with it. It's not hard to do - it is certainly much easier than trying to imagine and eliminate any possible cause of trouble. > >>>> So put in a delay. An /appropriate/ delay. >>> >>> You are thinking software, like most people do. >> It doesn't matter whether things are software, hardware, or something in >> between. > > Of course it does. Since the slaves are all logic, there is no need for delays, at all. The slave driver can be enabled at any time the message has been received and the reply is ready to go. > I'm sorry you don't understand, and I can't see how to explain it better than to say timing and delays are fundamental to the communication, not the implementation. > >>> The slaves will be in logic, so the UART will have timing information relevant to the end of bits. I don't care how the master does it. The FTDI cable is alleged to "just work". Nonetheless, I will be providing for separate send and receive buses (or call it master/slave buses). Only one slave will be addressed at a time, so no collisions there, and the master can't collide with itself. >>> >> Yes, with the bus you have described, and the command/response protocol >> you have described, there should be no problems with multiple >> transmitters on the bus, and you have plenty of inter-message idle periods. >> >> However, this Usenet thread has been mixing posts from different people, >> and discussions of different kinds of buses and protocols - not just the >> solution you picked (which, as I have said before, should work fine). I >> think this mixing means that people are sometimes talking at cross-purposes. > > Yes, it gets confusing. > There has, I think, been some interesting discussion despite the confusion. I hope you have got something out of it too - and I am glad that you have a bus solution that looks like it will work well for the purpose. > >>>> 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. >>> >>> How long is a piece of string? By keeping the interconnecting cables short, 4" or so, and a 5 foot cable from the PC, I don't expect problems with reflections. But it is prudent to allow for them anyway. The FTDI RS-422 cable seems to have a terminator on the receiver, but not the driver and no provision to add a terminator to the driver. >>> >> There is no point in having a terminator at a driver (unless you are >> talking about very high speed signals with serial resistors for slope >> control). You will want to add a terminator at the far end of both >> buses. This will give you a single terminator on the PC-to-slave bus, >> which is fine as it is fixed direction, and two terminators on the >> slave-to-PC bus, which is appropriate as it has no fixed direction. > > It does if you are using it in a shared bus with multiple drivers. The line should still be organized as linear with minimal stubs and a terminator on each end. This is not my plan, so maybe I should stop discussing it. > Ideally, a bus should be (as you say) linear with minimal stubs and a terminator at each end - /except/ if one end is always driven. There is no point in having a terminator at a driver. Think about it in terms of impedance - the driver is either driving a line high, or it is driving it low. At any given time, one of the differential pair lines will have almost 0 ohm resistance to 0V, and the other will have nearly 0 ohm resistance to 5V. When the signal changes, these swap. Connecting a 100 ohm resistor across the lines at that point will make no difference whatsoever. The terminator is completely useless - it's just a waste of power. At the other end of the cable it's a different matter - there's a cable full of resistance, capacitance and inductance between the terminator and the near 0 ohm driver, so the terminator resistor /does/ make a difference. In more sophisticated tristate drivers, you would off (disconnect) the local terminator whenever the driver is enabled. This is done in some multi-lane systems as it can significantly reduce power and make slope control and pulse shaping easier. (It's not something you'd be likely to see on RS-485 buses.) > >> (I agree that your piece of string is of a size that should work fine >> without reflections being a concern.) >>> Oddly enough, the RS-485 cable has a terminator that can be connected by the user, but that would be running through the cable separately from the transceiver signals, so essentially stubbed! I guess at 1 Mbps, 5 feet is less than the rise time, so not an issue. Since the interconnections between cards will be about five feet as well, it's unlikely to be an issue. The entire network will look like a lumped load, with the propagation time on the order of the rise/fall time. Even adding in a second chassis, makes the round trip twice the typical rise/fall time and unlikely to create any issues. >>> >>> They sell cables that have 5 m of cable, with a round trip of 30 ns or so. I think that would still not be significant in this application. The driver rise/fall times are 15 ns typ, 25 ns max. >>> >> The speed of a signal in a copper cable is typically about 70% of the >> speed of light, giving a minimum round-trip time closer to 45 ns than 30 >> ns. Not that it makes any difference here. > > The problem I have now is finding parts to use for this. These devices seem to be in a catagory that are hit hard by the shortage. My product uses the SN65C1168EPW, which is very hard to find in quantity. My customer has mentioned 18,000 units next year. I may need to get with the factory and see if they can supply me directly. > Unfortunately, sourcing components these days is a much harder problem than designing the systems.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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