Shared Communications Bus - RS-422 or RS-485

[gnuarm]

I have test fixtures using RS-232 to communicate with a PC as the controller.  I'm redesigning the test fixtures to hold more units and fully automate a few features that presently require an operator. There will now be 8 UUTs on each test fixture controlled by 4 FPGAs, and I expect to have 10 to 20 test fixtures in a card rack. That's 80 to 160 UUTs total and 40 to 80 FPGAs controlled by one PC.

I'm thinking of either daisy chaining, or connecting in parallel these devices. The protocol is master-slave where the master sends a command and the slaves only 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 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 could use an RS-422 interface with a master to slaves pair and a slaves to master pair. The slaves do not speak until spoken to, so there will be no collisions.

RS-485 would allow 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'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.

I'm looking at using the FTDI RS-422 or RS-485 cables, but I've yet to find any info on how they manage the tri-state of the driver from the user software.

[jonpaul]

I would check the RS-232 , RS-422, and RS-485 standards.

Full vs half duplex, different speeds, drive, levels.

Then get the spec sheets on a few typical parts.

https://www.ti.com/interface/rs-485-rs-422/products.html

For our broadcast reference designs in 2017, We used  l ISL3259E  rated to 100 MBS.

See Belden app notes for cable length, atten, Zo and choice.

With Kind Regards,

Jon

[gnuarm]

Thanks, but the issues I'm concerned with are not the electrical aspects.  It's the protocols on the interface.  With RS-422 a master-slave arrangement like I'm using should have no trouble since the master and slave can't collide.  With RS-485 the master has to know when the slave has finished the complete transmission before sending its next command. 

I've seen this in systems, where in the master, the UART informs the CPU the last character has been received, when it is only half way through the stop bit.  The master then starts transmission of the next command before the stop bit has completed with the master and slave fighting on the bus for that half of a bit.  Some slaves may not see the master's start bit because the start bit was too short, and the transmission is corrupted. 

I suppose I could append a DEL as the starting character of any master message and discard it.  The master DEL with 7 bit times of '1' which would provide time for slaves to recover from a corrupted start or stop bit. 

Or, I suppose a transmit protocol of adding a MARK parity bit and having the receiver not include parity would have the effect of adding an extra stop bit, preventing the problem at the expense of an extra bit on each character.  I seem to recall there being a setting  for numbers of stop bits, sometimes including 1, 2 and 1.5 bits.  1.5 bits for the stop bit should fix this as well.  As I've said, the slave is an FPGA, so I have total control over that.

[coromonadalix]

I would be more afraid of the parts you will use,  we work  in rs485, rs232, can bus  ...

The biggest problems we have after that darn covid thing is the parts quality,  we received tons of fake rs485 transceivers ...  be sure to find good parts reseller with some warranty in case of ...

On some products we have, if it was possible to redesign them  it would be usb 2 or usb 3  or even lan controlled or even esp32 (wi-fi)

And yes 

You can or may have timing issues on the rs485,  send and wait .... we had to make the controller / master scan 3 times the rs485 "network" and give some delays for that "scan response"

Personally  it's good to a point  BUT  with newest technologies,  the rs485  can be replaced easily, unless you use it in industrial environements / equipments  etc ... with noises  on the communication lines

Sure it depends of the costs involved .....  we did a mesh network with zigbee modules, very good speeds, redundancy  etc ...  esp modules costs are very low  too

my 2 cents

[max_torque]

In my experience, any windows pc is tough for sub ms synchronisation. Windows is very good without custom drivers off going off for a fair old period doing "something else" and this includes things like serial ports etc, especially when they are virtual ones over USB.

I'd have one of your slave units as the "interface slave" abd this that has a seperate fast virtual com port (USB VCP at say 1Mb) up  to the pc, so you can get a fair bit of data down that completely asynchronously to the parallel data that is then sent between the slaves and master.

One trick when you have decent timing control (which is what you need the embedded interface for) is to have your system master send a sync message out, and leave gaps between those sync messages for the slaves to TX/RX, and that includes your interfaceslave.  This is basically what FLEXRAY does, ie the master has bus control and arbitration.  Say the master sends a sync header every 1ms, and that header includes an address, When the slaves address matches that sent in the header, then it has the bus for bit. Give your "interface slave" a unique address, and then it can tx on the bus in a known empty time slot

[gnuarm]

I would be more afraid of the parts you will use,  we work  in rs485, rs232, can bus  ...

The biggest problems we have after that darn covid thing is the parts quality,  we received tons of fake rs485 transceivers ...  be sure to find good parts reseller with some warranty in case of ...

On some products we have, if it was possible to redesign them  it would be usb 2 or usb 3  or even lan controlled or even esp32 (wi-fi)

And yes 

You can or may have timing issues on the rs485,  send and wait .... we had to make the controller / master scan 3 times the rs485 "network" and give some delays for that "scan response"

Personally  it's good to a point  BUT  with newest technologies,  the rs485  can be replaced easily, unless you use it in industrial environements / equipments  etc ... with noises  on the communication lines

Sure it depends of the costs involved .....  we did a mesh network with zigbee modules, very good speeds, redundancy  etc ...  esp modules costs are very low  too

my 2 cents

I'm not sure of everything you've mentioned.  This is not a widely distributed bus.  There will be some number of boards in a rack.  With no backplane, I'm not comfortable with distributing TTL levels between boards, so the RS-422 drivers/receivers will be used. 

Conversations elsewhere have given me a chance to think about it and the topology will be a multi-drop from the PC to the slaves and multi-point from the slaves to the master.  With no chance of collision between master and slaves, this should not be a problem.  A single chassis with 16 test fixture cards, will hold 128 UUTs.  The UUTs will be constantly tested.  Any that fail immediately will be replaced with units until all 128 are working.  Assuming the failure rate from overnight burn-in is very low, we should be able to ship nearly 640 a week.  That will produce the required annual quantity in 28 weeks.  My CM will be estatic!  Higher volumes and lower labor times. 

[gnuarm]

In my experience, any windows pc is tough for sub ms synchronisation. Windows is very good without custom drivers off going off for a fair old period doing "something else" and this includes things like serial ports etc, especially when they are virtual ones over USB.

I'd have one of your slave units as the "interface slave" abd this that has a seperate fast virtual com port (USB VCP at say 1Mb) up  to the pc, so you can get a fair bit of data down that completely asynchronously to the parallel data that is then sent between the slaves and master.

Sorry, I don't follow what you are describing with this.  Are you talking about having a direct USB link to one of the board in the test rack?  What does that help?  It still has to get to the FPGAs, which would be serial. 

One trick when you have decent timing control (which is what you need the embedded interface for) is to have your system master send a sync message out, and leave gaps between those sync messages for the slaves to TX/RX, and that includes your interfaceslave.  This is basically what FLEXRAY does, ie the master has bus control and arbitration.  Say the master sends a sync header every 1ms, and that header includes an address, When the slaves address matches that sent in the header, then it has the bus for bit. Give your "interface slave" a unique address, and then it can tx on the bus in a known empty time slot

I'm not trying to control timing.  Each UUT is tested separately, although likely in parallel.  The current protocol over RS-232 uses commands from the PC with replies from the target.  The target actually allows for two UUTs, so there's a selection command to select one of the UUTs or the target board itself since it returns some info.  The only addition to the protocol required is to select which FPGA is being addressed.  If the data rate on the bus is high enough, the same commands can be sent out to every FPGA at once, testing every UUT in parallel.  Not that it is needed, but that would be impressive to see all the blinking lights.  Yes... there will be blinking lights! 

[langwadt]

In my experience, any windows pc is tough for sub ms synchronisation. Windows is very good without custom drivers off going off for a fair old period doing "something else" and this includes things like serial ports etc, especially when they are virtual ones over USB.

I'd have one of your slave units as the "interface slave" abd this that has a seperate fast virtual com port (USB VCP at say 1Mb) up  to the pc, so you can get a fair bit of data down that completely asynchronously to the parallel data that is then sent between the slaves and master.

Sorry, I don't follow what you are describing with this.  Are you talking about having a direct USB link to one of the board in the test rack?  What does that help?  It still has to get to the FPGAs, which would be serial. 

USB to one of the boards, rs485 from there to the other boards you can add as many parallel strings as you like and have total control over the timing.

something like an FT232 handles rs485 timing in hardware, it enables the driver one bit before the start bit and disables it after the last stop bit

[gnuarm]

In my experience, any windows pc is tough for sub ms synchronisation. Windows is very good without custom drivers off going off for a fair old period doing "something else" and this includes things like serial ports etc, especially when they are virtual ones over USB.

I'd have one of your slave units as the "interface slave" abd this that has a seperate fast virtual com port (USB VCP at say 1Mb) up  to the pc, so you can get a fair bit of data down that completely asynchronously to the parallel data that is then sent between the slaves and master.

Sorry, I don't follow what you are describing with this.  Are you talking about having a direct USB link to one of the board in the test rack?  What does that help?  It still has to get to the FPGAs, which would be serial. 

USB to one of the boards, rs485 from there to the other boards you can add as many parallel strings as you like and have total control over the timing.

something like an FT232 handles rs485 timing in hardware, it enables the driver one bit before the start bit and disables it after the last stop bit

Ok, thanks, but I don't see how that's different from using the FTDI cable.  Why do I want to make one of the many test fixture boards different from the others?

[max_torque]

The problem with a PC/Windows based serial data exchange over a virtual serial port, ie a USB link with a driver IC that makes it look like a uart at the end, ie a FTDI device, is that USB is not optimised in anything like the same way as a native uart. USB is designed to move a reasonable amount of data, at a reasonable speed, but under conditions where the latency, delay and interbit timing of that data isn't really important.

For example, you put a usb memory stick in the usb socket, and transfer a file up to your PC, and while you do want all the file and it to be all intact ie not full of bit errors, you don't actually care, to the nearest millisecond, how or when it got there.

For an embedded system trying to avoid collisons on a serial bus of any format, then unless you data rate is incredibly slow, then you need ms level timing accuracy and critically repeatability.  A VCP on a PC does not allow this, well, certainly not with std drivers, but even, with custom RTOS it is still dificult in my experience.

So, the solution is to use a slave node as an interface and that embedded node gets data from the PC running the control software, but it acts in a way to buffer that data and hence you can now have asyncronous coms to the pc, and synchonous coms to the slave network.

If you have am RS-485 network with a master controlling the flow, then that master can issue ms or shorter timming sync messages, and your individual slaves can act on those messages and reply when you know there isn't going to be a collision.  here, your "interface slave" acts to buffer any data exchange to the pc to fit neatly into the master led timing of that slave bus.  That slave can have a descrete data link to the pc via a FTDI or similar.

[gnuarm]

The existing system, on RS-232, is a master/slave protocol.  The master sends a short message, around 10 characters, and receives a short reply.  The messages are just reading and writing registers, so they consist of an address, optionally data, and a command (read or write or select target).  The slave responds by echoing the command, with the response to a read including data.

The slaves are FPGAs, so the response time is virtually instantaneous compared to the data rate on the bus.  And control over the RS-422 driver enables is also nearly instantaneous, no worry about getting a driver off the bus quickly enough. 

I could use an RS-485 bus.  The PC will use an FTDI cable which provides proper driver control.  Or I could use RS-422 with a single driver/multiple receiver for the master talk bus, and a single receiver/multiple driver for the master listen bus.  The boards I would build will have flexibility to work with either arrangement.

Since the slaves only speak when spoken to, there will be no collisions (baring bit errors on the bus, so I might want to add a check sum) on the master listen bus.  Obviously the master can't collide with itself on the master talk bus.

Given the inherent timing control from the query/response protocol, collisions can't happen on the RS-485 bus.  But the turn around time for drivers has to be very well controlled, or delays need to be provided. 

The USB protocol at 480 Mbps seems to have an 8 kHz polling rate, so messages can't be sent faster than this, from what I'm told.  So a message pair (xmit/rcv) would be at 4 kHz.  That's not as good as I would like, but I guess it can be good enough.  Given an average of about 20 characters per message pair, that's 800 kbps, plus overhead on the USB side and 1 Mbps on the RS-485/RS-422 buses.  So I will need to run the USB virtual UART faster than 1 Mbps. 

Some people have suggested that I use Ethernet from the PC and distribute that to multiple test fixture cards which can then talk to the 8 UUTs.  I don't think I need the added speed, and it means worrying about configuration of the Ethernet protocol.  Not something I want to bother with.

[tooki]

If you have a working RS-232 interface on the PC and are worried about USB introducing uncertainties, then why not just keep the RS-232 interface and use an RS-232 to RS-485 converter to interface with the RS-485 bus?

[gnuarm]

If you have a working RS-232 interface on the PC and are worried about USB introducing uncertainties, then why not just keep the RS-232 interface and use an RS-232 to RS-485 converter to interface with the RS-485 bus?

How would that help???  I don't follow at all.  What's wrong with using an RS-422 USB cable???  The RS-232 interface is an FTDI serial cable.  I'm just swapping one cable for another.

[m98]

Why not use an interface card that already supports the protocol, instead of emulating it over a virtual COM port? Just use a USB to CAN adapter.

[gnuarm]

Why not use an interface card that already supports the protocol, instead of emulating it over a virtual COM port? Just use a USB to CAN adapter.

Perhaps I'm not familiar enough with CAN.  What does a CAN adapter do for me that an RS-422 serial port cable doesn't  do?  What would I need at the slaves?  What protocol does a CAN interface adapter implement exactly?

My protocol is very simple.  I send a message of around 10 or 12 characters.  The addressed slave replies with a message of around 10 or 15 characters.  So only one is talking at a time and the message is the handshake.  The PC master implements a timeout to detect message failures.

One wrinkle I just discovered is that the FTDI devices are not high speed, they are full speed.  People talked about the polling rate being 8 kHz, but with full speed it's only 1 kHz.  Unless I'm not understanding the protocol, this would reduce my throughput by 8x.  500 message pairs per second is only around 4 message pairs per second per UUT with 128 UUTs in the box. I had been thinking it would be more like 32 commands per second per UUT.  Not fatal, but visibly slower.  In use there might be up to 256 UUTs in two crates.  Using two serial ports is a bit of a PITA. 

[gnuarm]

I took a quick look for CAN bus modules and could not find anything equivalent to the units I'm using now.  I would want a PC USB cable that looks like a standard UART on the PC.  On the other end, I would want a module that can be mounted to the test fixture boards that looks like a TTL level serial port.  The data rate would need to be around 1 Mbps with messages around 12 characters long, one in each direction for a message exchange.  The CAN bus units don't need to be separately addressable, but I suppose that's how they work and would be a plus. 

Is it safe to assume CAN bus can have up to 32 devices on a single bus?

[max_torque]

I suggest you get some VCP hardware, and write a bit of simple PC software to send data over that link at a fixed interval. Use a scope or logic analyser to monitor that traffic and report back!

(good luck getting anywhere near a robust, repeatable 4KHz rate from windows..........       )

[langwadt]

Why not use an interface card that already supports the protocol, instead of emulating it over a virtual COM port? Just use a USB to CAN adapter.

Perhaps I'm not familiar enough with CAN.  What does a CAN adapter do for me that an RS-422 serial port cable doesn't  do?  What would I need at the slaves?  What protocol does a CAN interface adapter implement exactly?

My protocol is very simple.  I send a message of around 10 or 12 characters.  The addressed slave replies with a message of around 10 or 15 characters.  So only one is talking at a time and the message is the handshake.  The PC master implements a timeout to detect message failures.

One wrinkle I just discovered is that the FTDI devices are not high speed, they are full speed.  People talked about the polling rate being 8 kHz, but with full speed it's only 1 kHz.  Unless I'm not understanding the protocol, this would reduce my throughput by 8x.  500 message pairs per second is only around 4 message pairs per second per UUT with 128 UUTs in the box. I had been thinking it would be more like 32 commands per second per UUT.  Not fatal, but visibly slower.  In use there might be up to 256 UUTs in two crates.  Using two serial ports is a bit of a PITA.

FT2232H is highspeed dual serialport, FT4232 is highspeed quad serial port

[gnuarm]

Why not use an interface card that already supports the protocol, instead of emulating it over a virtual COM port? Just use a USB to CAN adapter.

Perhaps I'm not familiar enough with CAN.  What does a CAN adapter do for me that an RS-422 serial port cable doesn't  do?  What would I need at the slaves?  What protocol does a CAN interface adapter implement exactly?

My protocol is very simple.  I send a message of around 10 or 12 characters.  The addressed slave replies with a message of around 10 or 15 characters.  So only one is talking at a time and the message is the handshake.  The PC master implements a timeout to detect message failures.

One wrinkle I just discovered is that the FTDI devices are not high speed, they are full speed.  People talked about the polling rate being 8 kHz, but with full speed it's only 1 kHz.  Unless I'm not understanding the protocol, this would reduce my throughput by 8x.  500 message pairs per second is only around 4 message pairs per second per UUT with 128 UUTs in the box. I had been thinking it would be more like 32 commands per second per UUT.  Not fatal, but visibly slower.  In use there might be up to 256 UUTs in two crates.  Using two serial ports is a bit of a PITA.

FT2232H is highspeed dual serialport, FT4232 is highspeed quad serial port

By "devices", I meant the devices I am looking at, the cables.  But I see now, they have some high speed cables, but simply don't indicate that in the USB Speed column.  You have to look in the description.  Still, they don't have any for my purposes, RS-422/RS-485.  Interesting that they use separate dongles for the two.  It would be easy enough to use a single cable with appropriate options for connecting them in the different ways.  They seem locked into the Zywyn driver/receiver chips.  To accommodate both protocols in the same chip requires a 14 pin package, rather than the 8 pin version.

I just realized, if I want to add the RS-422 translator chip, I can use the hi-speed serial cable.  This application does not require a driver enable signal, since the buses are split.

I was looking at the schematic for the Hi-speed serial cables and I can't see how it is powered.  They have one that provides the USB 5V to the cable and one with a 3.3V LDO.  Neither schematic shows how power is supplied to the FTDI chip.  Very odd.

https://ftdichip.com/wp-content/uploads/2020/07/DS_C232HD_UART_CABLE.pdf

[langwadt]

Why not use an interface card that already supports the protocol, instead of emulating it over a virtual COM port? Just use a USB to CAN adapter.

Perhaps I'm not familiar enough with CAN.  What does a CAN adapter do for me that an RS-422 serial port cable doesn't  do?  What would I need at the slaves?  What protocol does a CAN interface adapter implement exactly?

My protocol is very simple.  I send a message of around 10 or 12 characters.  The addressed slave replies with a message of around 10 or 15 characters.  So only one is talking at a time and the message is the handshake.  The PC master implements a timeout to detect message failures.

One wrinkle I just discovered is that the FTDI devices are not high speed, they are full speed.  People talked about the polling rate being 8 kHz, but with full speed it's only 1 kHz.  Unless I'm not understanding the protocol, this would reduce my throughput by 8x.  500 message pairs per second is only around 4 message pairs per second per UUT with 128 UUTs in the box. I had been thinking it would be more like 32 commands per second per UUT.  Not fatal, but visibly slower.  In use there might be up to 256 UUTs in two crates.  Using two serial ports is a bit of a PITA.

FT2232H is highspeed dual serialport, FT4232 is highspeed quad serial port

By "devices", I meant the devices I am looking at, the cables.  But I see now, they have some high speed cables, but simply don't indicate that in the USB Speed column.  You have to look in the description.  Still, they don't have any for my purposes, RS-422/RS-485.  Interesting that they use separate dongles for the two.  It would be easy enough to use a single cable with appropriate options for connecting them in the different ways.  They seem locked into the Zywyn driver/receiver chips.  To accommodate both protocols in the same chip requires a 14 pin package, rather than the 8 pin version.

I just realized, if I want to add the RS-422 translator chip, I can use the hi-speed serial cable.  This application does not require a driver enable signal, since the buses are split.

https://ftdichip.com/products/usb-com422-plus4-2/

[gnuarm]

You continue to impress me.  I was limiting myself to cables, but I can make a module work.  In fact, the module could be at the test fixture which would eliminate 5 foot (1.8 m) of RS-422 cable.  I would use a 5 ft (1.8 m) USB cable and a very short DB9 to RJ-45 cable.  It would be nice if this module came in a case, but that can be accommodated easily I'm sure.  I'd probably go for the dual version since it is much cheaper.  I can't see ever needing four RS-422 ports for this use.  Even if I needed two ports, it would be better to use another USB port to avoid slowing the bus.

The more I think about it, the more I think there are more messages per test rather than fewer.  Since the bus is message limited moreso than character limited, or bit limited, if the speed ends up being an issue, I may need to use multiple interfaces.  Or maybe an Ethernet to RS-422 adapter.

The Ethernet interface to the test fixture boards, without RS-422, might be a way to go after all.  But the devil is in the details.  Just like I found the USB limitation of message rate, rather than bit rate, Ethernet could be full of pitfalls.  I don't have any more time to mess with this now.  I need to address other issues.

[gnuarm]

I've had more time to look at this, and I think the way to go is to use Ethernet to the PC master and a single, 4-wire, RS-485 connection to all the slaves. 

This may have been suggested before and I may have rejected it, because I couldn't find the right device.  I had gotten more uneasy about maintaining the RS-485 data rate over the USB interface, given the polling limitation. So I was looking for Ethernet devices that could provide an RS-232 or RS-422/485 connection to the slave boards.  The problem there is the limited data rate they provide on the serial port, typically no higher than 1 Mbps, which is what the USB approach would limit me to.

So then I started looking for 16 port Ethernet interfaces and found a few.  But at some point I had myself mixed up and was looking for higher data rates on the serial ports... lol  But as luck had it, I found one running up to 12 Mbps on each serial port.  So then I looked at smaller boxes in this brand, and found the 8 and 4 port units also run 12 Mbps on each port.  The 1 and 2 port versions run at 3.7 Mbps, but that's still more than I need.  So I'll probably get the 2 port as a fudge factor and to be able to run a second crate.

So I think I can use 1 port of a NetCom Plus x13 Ethernet interface and meet my speed requirements.  I've sent them an email to ask for verification.  When the messages are this short and the message rate is this high, I think it may need verification. 

[ajb]

One thing I didn't see mentioned, beware of the unit load on your transceivers with that many devices.  A typical RS485/RS422 transceiver loads the bus such that a max of 32 devices are allowed on each bus, but transceivers with 1/8 unit loads are available, allowing 256 devices per bus.