Shared Communications Bus - RS-422 or RS-485...

On Wednesday, November 2, 2022 at 7:34:03 AM UTC-4, Arie de Muijnck wrote:
On 2022-11-02 06:30, Ricky 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-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.

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.

I\'ve built test systems like that, without any PC master timing problems.

Use a 2-pair RS485 bus, one pair for PC TX, one for PC RX.
Use independent RX and TX. On PC side enable TX at all times.
Use a 120R terminator on each end of each pair.
Use one 560R pull-up and 560R pull-down on the RX pair to keep the RX bus noise-free when idle.

On the device side use separate RS485 RX and TX, enable TX only when replying (and turn off AFTER the stop bit).

Use Hi-Z RS485 chips, they can handle multi drop up to 256 connections.

Worked perfectly, even with up to 5V ground differences.
Tested in production environment, CRC error counters stayed zero.
Click to expand...

Just to be clear, if the talking and listening aren\'t on the same wires, that just RS-422, not RS-485. No?

But yes, that\'s one very good option. What bit rates were you using?

--

Rick C.

-+- Get 1,000 miles of free Supercharging
-+- Tesla referral code - https://ts.la/richard11209
 
On Wednesday, November 2, 2022 at 8:54:17 AM UTC-4, Arie de Muijnck wrote:
On 2022-11-02 13:05, Lasse Langwadt Christensen wrote:

onsdag den 2. november 2022 kl. 12.34.03 UTC+1 skrev Arie de Muijnck:>> I\'ve built test systems like that, without any PC master timing problems.>>>> Use a 2-pair RS485 bus, one pair for PC TX, one for PC RX.>> Use independent RX and TX. On PC side enable TX at all times.>> Use a 120R terminator on each end of each pair.>> Use one 560R pull-up and 560R pull-down on the RX pair to keep the RX bus noise-free when idle.> > which is basically RS-442
If you meant RS-422: no, that has no three-state so cannot be used for multi-drop.
The two-pair topology is indeed like RS-422 but made multi-slave with RS-485 drivers.
Click to expand...

This is not important, but all the RS-422 devices I\'ve used have driver enables. There\'s one on the UUT, that has become unobtainium, and is a PITA, because it\'s a 5V device and has to connect to 3.3V logic. They can be used for RS-485 simply by connecting a driver and receiver to the same pair of lines. RS-485 devices typically wire the driver and receive to the same pins, so they fit in an 8 pin package.

--

Rick C.

-++ Get 1,000 miles of free Supercharging
-++ Tesla referral code - https://ts.la/richard11209
 
On 2022-11-02 20:40, Ricky wrote:
On Wednesday, November 2, 2022 at 7:34:03 AM UTC-4, Arie de Muijnck wrote:
I\'ve built test systems like that, without any PC master timing problems.

Use a 2-pair RS485 bus, one pair for PC TX, one for PC RX.
Use independent RX and TX. On PC side enable TX at all times.
Use a 120R terminator on each end of each pair.
Use one 560R pull-up and 560R pull-down on the RX pair to keep the RX bus noise-free when idle.

On the device side use separate RS485 RX and TX, enable TX only when replying (and turn off AFTER the stop bit).

Use Hi-Z RS485 chips, they can handle multi drop up to 256 connections.

Worked perfectly, even with up to 5V ground differences.
Tested in production environment, CRC error counters stayed zero.

Just to be clear, if the talking and listening aren\'t on the same wires, that just RS-422, not RS-485. No?
But yes, that\'s one very good option. What bit rates were you using?
Click to expand...

The two-pair topology is like RS-422. The three-stating levels are RS-485. This is a hybrid system.

I used about 400 kbps, but if you use small stubs, proper termination and not too long a cable, 1+ Mbps is possible.
A chip like https://www.ti.com/product/THVD1424 would do: 3.3/5V, full duplex, enables, 20 Mbps, 256 nodes, $1 at 1K+.

But there are cheaper ones, a searching link including filters is:
https://www.ti.com/interface/rs-485-rs-422/products.html#p994=0;1&p993=0;1.67&p1065=Half&p1064=95;320&o4=1&sort=p1130;asc

Arie
 
RS485 is simple, reliable and can run quite fast, if you really need more bandwidth you could just split the string and add more interfaces to the PC
 
On 2022-11-03 00:09, Lasse Langwadt Christensen wrote:
> RS485 is simple, reliable and can run quite fast, if you really need more bandwidth you could just split the string and add more interfaces to the PC

Ricky wants to communicate with a PC.
RS-485 does not handle the timing from the standard PC UART signals well, the disabling of the TX after the last character is a problem. Black-box did that with retriggerable one-shots from the TX signal, they had to be set for the proper baudrate. Even then, the slave cannot answer directly but has to provide some dead time before answering.

However, some RS-485 USB dongles have proper TX enabling control by the UART chip inside, they turn off just after the last stop bit. That leaves only the slave timing to be considered, and terminators plus pull-ups / pull-downs.

Arie
 
On Wednesday, November 2, 2022 at 6:12:49 PM UTC-4, Arie de Muijnck wrote:
On 2022-11-02 20:40, Ricky wrote:
On Wednesday, November 2, 2022 at 7:34:03 AM UTC-4, Arie de Muijnck wrote:
I\'ve built test systems like that, without any PC master timing problems.

Use a 2-pair RS485 bus, one pair for PC TX, one for PC RX.
Use independent RX and TX. On PC side enable TX at all times.
Use a 120R terminator on each end of each pair.
Use one 560R pull-up and 560R pull-down on the RX pair to keep the RX bus noise-free when idle.

On the device side use separate RS485 RX and TX, enable TX only when replying (and turn off AFTER the stop bit).

Use Hi-Z RS485 chips, they can handle multi drop up to 256 connections.

Worked perfectly, even with up to 5V ground differences.
Tested in production environment, CRC error counters stayed zero.

Just to be clear, if the talking and listening aren\'t on the same wires, that just RS-422, not RS-485. No?
But yes, that\'s one very good option. What bit rates were you using?
The two-pair topology is like RS-422. The three-stating levels are RS-485. This is a hybrid system.

I used about 400 kbps, but if you use small stubs, proper termination and not too long a cable, 1+ Mbps is possible.
A chip like https://www.ti.com/product/THVD1424 would do: 3.3/5V, full duplex, enables, 20 Mbps, 256 nodes, $1 at 1K+.

But there are cheaper ones, a searching link including filters is:
https://www.ti.com/interface/rs-485-rs-422/products.html#p994=0;1&p993=0;1.67&p1065=Half&p1064=95;320&o4=1&sort=p1130;asc
Click to expand...

This one is plenty cheap enough, but \"Out of stock\", like many, many devices these days.

--

Rick C.

+-- Get 1,000 miles of free Supercharging
+-- Tesla referral code - https://ts.la/richard11209
 
torsdag den 3. november 2022 kl. 00.21.30 UTC+1 skrev Arie de Muijnck:
On 2022-11-03 00:09, Lasse Langwadt Christensen wrote:
RS485 is simple, reliable and can run quite fast, if you really need more bandwidth you could just split the string and add more interfaces to the PC
Ricky wants to communicate with a PC.
RS-485 does not handle the timing from the standard PC UART signals well, the disabling of the TX after the last character is a problem. Black-box did that with retriggerable one-shots from the TX signal, they had to be set for the proper baudrate. Even then, the slave cannot answer directly but has to provide some dead time before answering.

However, some RS-485 USB dongles have proper TX enabling control by the UART chip inside, they turn off just after the last stop bit. That leaves only the slave timing to be considered, and terminators plus pull-ups / pull-downs.
Click to expand...

just get something like an FTDI USB to RS485 serial interface cable, it does the correct timing and has pull up/down and optional termination

actual PC UARTs are something you find in a technical museum
 
torsdag den 3. november 2022 kl. 00.34.39 UTC+1 skrev Ricky:
On Wednesday, November 2, 2022 at 6:12:49 PM UTC-4, Arie de Muijnck wrote:
On 2022-11-02 20:40, Ricky wrote:
On Wednesday, November 2, 2022 at 7:34:03 AM UTC-4, Arie de Muijnck wrote:
I\'ve built test systems like that, without any PC master timing problems.

Use a 2-pair RS485 bus, one pair for PC TX, one for PC RX.
Use independent RX and TX. On PC side enable TX at all times.
Use a 120R terminator on each end of each pair.
Use one 560R pull-up and 560R pull-down on the RX pair to keep the RX bus noise-free when idle.

On the device side use separate RS485 RX and TX, enable TX only when replying (and turn off AFTER the stop bit).

Use Hi-Z RS485 chips, they can handle multi drop up to 256 connections.

Worked perfectly, even with up to 5V ground differences.
Tested in production environment, CRC error counters stayed zero.

Just to be clear, if the talking and listening aren\'t on the same wires, that just RS-422, not RS-485. No?
But yes, that\'s one very good option. What bit rates were you using?
The two-pair topology is like RS-422. The three-stating levels are RS-485. This is a hybrid system.

I used about 400 kbps, but if you use small stubs, proper termination and not too long a cable, 1+ Mbps is possible.
A chip like https://www.ti.com/product/THVD1424 would do: 3.3/5V, full duplex, enables, 20 Mbps, 256 nodes, $1 at 1K+.

But there are cheaper ones, a searching link including filters is:
https://www.ti.com/interface/rs-485-rs-422/products.html#p994=0;1&p993=0;1.67&p1065=Half&p1064=95;320&o4=1&sort=p1130;asc
This one is plenty cheap enough, but \"Out of stock\", like many, many devices these days.
Click to expand...

LCSC have million of transceivers in stock https://lcsc.com/products/RS-485-RS-422-ICs_578.html

and most of the SO8 rs-485 ones are likely pin compatible
 
On Wednesday, November 2, 2022 at 7:56:34 PM UTC-4, lang...@fonz.dk wrote:
torsdag den 3. november 2022 kl. 00.34.39 UTC+1 skrev Ricky:
On Wednesday, November 2, 2022 at 6:12:49 PM UTC-4, Arie de Muijnck wrote:
On 2022-11-02 20:40, Ricky wrote:
On Wednesday, November 2, 2022 at 7:34:03 AM UTC-4, Arie de Muijnck wrote:
I\'ve built test systems like that, without any PC master timing problems.

Use a 2-pair RS485 bus, one pair for PC TX, one for PC RX.
Use independent RX and TX. On PC side enable TX at all times.
Use a 120R terminator on each end of each pair.
Use one 560R pull-up and 560R pull-down on the RX pair to keep the RX bus noise-free when idle.

On the device side use separate RS485 RX and TX, enable TX only when replying (and turn off AFTER the stop bit).

Use Hi-Z RS485 chips, they can handle multi drop up to 256 connections.

Worked perfectly, even with up to 5V ground differences.
Tested in production environment, CRC error counters stayed zero.

Just to be clear, if the talking and listening aren\'t on the same wires, that just RS-422, not RS-485. No?
But yes, that\'s one very good option. What bit rates were you using?
The two-pair topology is like RS-422. The three-stating levels are RS-485. This is a hybrid system.

I used about 400 kbps, but if you use small stubs, proper termination and not too long a cable, 1+ Mbps is possible.
A chip like https://www.ti.com/product/THVD1424 would do: 3.3/5V, full duplex, enables, 20 Mbps, 256 nodes, $1 at 1K+.

But there are cheaper ones, a searching link including filters is:
https://www.ti.com/interface/rs-485-rs-422/products.html#p994=0;1&p993=0;1.67&p1065=Half&p1064=95;320&o4=1&sort=p1130;asc
This one is plenty cheap enough, but \"Out of stock\", like many, many devices these days.
LCSC have million of transceivers in stock https://lcsc.com/products/RS-485-RS-422-ICs_578.html

and most of the SO8 rs-485 ones are likely pin compatible
Click to expand...

The trouble is, I\'m not using RS-485. I guess I could use two of these chips and never enable the driver on the receiver part. They have nothing in stock that\'s actually RS-422 with a separate driver and receiver, also, some level of ESD protection. But thanks for the pointer. I tend to not use LCSC. These days, even they don\'t have much in stock.

--

Rick C.

+-+ Get 1,000 miles of free Supercharging
+-+ Tesla referral code - https://ts.la/richard11209
 
torsdag den 3. november 2022 kl. 01.25.31 UTC+1 skrev Ricky:
On Wednesday, November 2, 2022 at 7:56:34 PM UTC-4, lang...@fonz.dk wrote:
torsdag den 3. november 2022 kl. 00.34.39 UTC+1 skrev Ricky:
On Wednesday, November 2, 2022 at 6:12:49 PM UTC-4, Arie de Muijnck wrote:
On 2022-11-02 20:40, Ricky wrote:
On Wednesday, November 2, 2022 at 7:34:03 AM UTC-4, Arie de Muijnck wrote:
I\'ve built test systems like that, without any PC master timing problems.

Use a 2-pair RS485 bus, one pair for PC TX, one for PC RX.
Use independent RX and TX. On PC side enable TX at all times.
Use a 120R terminator on each end of each pair.
Use one 560R pull-up and 560R pull-down on the RX pair to keep the RX bus noise-free when idle.

On the device side use separate RS485 RX and TX, enable TX only when replying (and turn off AFTER the stop bit).

Use Hi-Z RS485 chips, they can handle multi drop up to 256 connections.

Worked perfectly, even with up to 5V ground differences.
Tested in production environment, CRC error counters stayed zero..

Just to be clear, if the talking and listening aren\'t on the same wires, that just RS-422, not RS-485. No?
But yes, that\'s one very good option. What bit rates were you using?
The two-pair topology is like RS-422. The three-stating levels are RS-485. This is a hybrid system.

I used about 400 kbps, but if you use small stubs, proper termination and not too long a cable, 1+ Mbps is possible.
A chip like https://www.ti.com/product/THVD1424 would do: 3.3/5V, full duplex, enables, 20 Mbps, 256 nodes, $1 at 1K+.

But there are cheaper ones, a searching link including filters is:
https://www.ti.com/interface/rs-485-rs-422/products.html#p994=0;1&p993=0;1.67&p1065=Half&p1064=95;320&o4=1&sort=p1130;asc
This one is plenty cheap enough, but \"Out of stock\", like many, many devices these days.
LCSC have million of transceivers in stock https://lcsc.com/products/RS-485-RS-422-ICs_578.html

and most of the SO8 rs-485 ones are likely pin compatible
The trouble is, I\'m not using RS-485. I guess I could use two of these chips and never enable the driver on the receiver part. They have nothing in stock that\'s actually RS-422 with a separate driver and receiver, also, some level of ESD protection. But thanks for the pointer. I tend to not use LCSC. These days, even they don\'t have much in stock.
Click to expand...

using two chips in a package with lots of pin compatible alternatives might be a good strategy there days
 
On Wednesday, November 2, 2022 at 8:32:26 PM UTC-4, lang...@fonz.dk wrote:
torsdag den 3. november 2022 kl. 01.25.31 UTC+1 skrev Ricky:
On Wednesday, November 2, 2022 at 7:56:34 PM UTC-4, lang...@fonz.dk wrote:
torsdag den 3. november 2022 kl. 00.34.39 UTC+1 skrev Ricky:
On Wednesday, November 2, 2022 at 6:12:49 PM UTC-4, Arie de Muijnck wrote:
On 2022-11-02 20:40, Ricky wrote:
On Wednesday, November 2, 2022 at 7:34:03 AM UTC-4, Arie de Muijnck wrote:
I\'ve built test systems like that, without any PC master timing problems.

Use a 2-pair RS485 bus, one pair for PC TX, one for PC RX.
Use independent RX and TX. On PC side enable TX at all times.
Use a 120R terminator on each end of each pair.
Use one 560R pull-up and 560R pull-down on the RX pair to keep the RX bus noise-free when idle.

On the device side use separate RS485 RX and TX, enable TX only when replying (and turn off AFTER the stop bit).

Use Hi-Z RS485 chips, they can handle multi drop up to 256 connections.

Worked perfectly, even with up to 5V ground differences.
Tested in production environment, CRC error counters stayed zero.

Just to be clear, if the talking and listening aren\'t on the same wires, that just RS-422, not RS-485. No?
But yes, that\'s one very good option. What bit rates were you using?
The two-pair topology is like RS-422. The three-stating levels are RS-485. This is a hybrid system.

I used about 400 kbps, but if you use small stubs, proper termination and not too long a cable, 1+ Mbps is possible.
A chip like https://www.ti.com/product/THVD1424 would do: 3.3/5V, full duplex, enables, 20 Mbps, 256 nodes, $1 at 1K+.

But there are cheaper ones, a searching link including filters is:
https://www.ti.com/interface/rs-485-rs-422/products.html#p994=0;1&p993=0;1.67&p1065=Half&p1064=95;320&o4=1&sort=p1130;asc
This one is plenty cheap enough, but \"Out of stock\", like many, many devices these days.
LCSC have million of transceivers in stock https://lcsc.com/products/RS-485-RS-422-ICs_578.html

and most of the SO8 rs-485 ones are likely pin compatible
The trouble is, I\'m not using RS-485. I guess I could use two of these chips and never enable the driver on the receiver part. They have nothing in stock that\'s actually RS-422 with a separate driver and receiver, also, some level of ESD protection. But thanks for the pointer. I tend to not use LCSC. These days, even they don\'t have much in stock.

using two chips in a package with lots of pin compatible alternatives might be a good strategy there days
Click to expand...

This is a test fixture, not a deliverable. I only need to buy a few.

Looking at the schematic for the FTDI cable, they use RS-422 transceivers that have no enables, so they fit in an 8 pin package. The 16-pin TSSOP on the product I\'m selling has separate enables on the drivers. The two 8-pin SOICs are twice as large, so it isn\'t to save space. This was not designed in the last couple of years, so it\'s not about availability.

--

Rick C.

++- Get 1,000 miles of free Supercharging
++- Tesla referral code - https://ts.la/richard11209
 
On 2022-11-02, Ricky <gnuarm.deletethisbit@gmail.com> wrote:

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-485 would allow all this to be over a single pair of wires.
Click to expand...

I would have suggested the same,

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.
Click to expand...

RS422 seems the easy solution, you can use a resettable one-shot
triggered by pusses on the tx line to set tx_enable (and rely on it to
time out while the master is sending the next command on the other
pair), but for RS485, all you need to do is use an RS485 capable UART
in RS485 mode - that is use a UART that has a hardware output that goes
high when there are bits in the send register. for the USB end FT232
will work I think, or CH340B if you\'re on a budget (this chip enables
RS485 mode using an external resistor, meaning there\'s no need to set
some serial port feature flags to enable 485),

Choose RS485 transceivers that can have more than 80 devices on the
bus (this is most of them but not all).

--
Jasen.
 
On 2022-11-02, Ricky <gnuarm.deletethisbit@gmail.com> wrote:
On Wednesday, November 2, 2022 at 6:12:19 AM UTC-4, Clive Arthur wrote:
On 02/11/2022 05:30, Ricky 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.
snip

I\'ve done similar, though with many fewer nodes, simply by paralleling
the RS232 inputs and diode oring the outputs. I imagine you might need
to buffer your PC output and maybe not expect very high speeds.

I believe most such transceivers are rated to drive up to 32 loads.
Click to expand...

Find transceivers that are themselves 1/4 load (or less) and you can have 128 on the bus.

eg: SN75HVD3082EDR is 1/8 load

--
Jasen.
 
On 2022-11-02, Arie de Muijnck <eternal.september@ademu.com> wrote:
On 2022-11-03 00:09, Lasse Langwadt Christensen wrote:
RS485 is simple, reliable and can run quite fast, if you really need more bandwidth you could just split the string and add more interfaces to the PC

Ricky wants to communicate with a PC.
RS-485 does not handle the timing from the standard PC UART signals well
the disabling of the TX after the last character is a problem.
Click to expand...

16650 UART has hardware RS485 support - these days that\'s almost
\"standard PC UART\", but there\'s no reason not to use a USB UART interface
instead, and there\'s plenty of them that can drive RS485 too.

However, some RS-485 USB dongles have proper TX enabling control by
the UART chip inside, they turn off just after the last stop bit. That
leaves only the slave timing to be considered, and terminators plus
pull-ups / pull-downs.
Click to expand...

I don\'t trust anything cheaper than a dollar to do RS485 properly,
I verify instead, I have some that do and some that do not :)

--
Jasen.
 
On Thursday, November 3, 2022 at 3:04:54 AM UTC-4, Jasen Betts wrote:
On 2022-11-02, Arie de Muijnck <eternal....@ademu.com> wrote:
On 2022-11-03 00:09, Lasse Langwadt Christensen wrote:
RS485 is simple, reliable and can run quite fast, if you really need more bandwidth you could just split the string and add more interfaces to the PC

Ricky wants to communicate with a PC.
RS-485 does not handle the timing from the standard PC UART signals well
the disabling of the TX after the last character is a problem.
16650 UART has hardware RS485 support - these days that\'s almost
\"standard PC UART\", but there\'s no reason not to use a USB UART interface
instead, and there\'s plenty of them that can drive RS485 too.
However, some RS-485 USB dongles have proper TX enabling control by
the UART chip inside, they turn off just after the last stop bit. That
leaves only the slave timing to be considered, and terminators plus
pull-ups / pull-downs.
I don\'t trust anything cheaper than a dollar to do RS485 properly,
I verify instead, I have some that do and some that do not :)
Click to expand...

I don\'t know why people are pushing RS-485. At this point RS-485 offers no advantages over a split bus, full duplex solution using RS-422. I expect to use a pair of RJ-45 connectors to make cabling simple and cheap, and an FTDI RS-422 USB adapter. The FPGA UART will have perfect control over the transmitter enable using the custom UART already in the design. The FTDI transmitter will remain on all the time, so timing of the transmitter enable is of no consequence.

This is about as simple and fool-proof as I can design it. I can\'t see how RS-485 offers any advantages, other than allowing the use of a smaller connector, RJ-11 perhaps. Actually, I can run the full duplex interface over RJ-11 connectors, it would just require four conductors rather than two (or six if you want to include grounds).

--

Rick C.

+++ Get 1,000 miles of free Supercharging
+++ Tesla referral code - https://ts.la/richard11209
 
On Tue, 1 Nov 2022 22:30:58 -0700 (PDT), Ricky
<gnuarm.deletethisbit@gmail.com> wrote:

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

The master can be standard RS-422, but the slaves needs to be 4-wire
RS-485 i.e. the slave Tx is in tri-state until the slave is addressed.

On a PC side, do NOT use standard RS-232 PC ports followed by an
RS-232 to RS-422/485 external converter, there is a great risks for
timing problems. Use proper RS-422/485 PCI cards (or external Ethernet
to RS-422/485 converter for laptops).
 
On Friday, November 4, 2022 at 5:17:57 AM UTC-4, upsid...@downunder.com wrote:
On Tue, 1 Nov 2022 22:30:58 -0700 (PDT), Ricky
gnuarm.del...@gmail.com> wrote:

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.
The master can be standard RS-422, but the slaves needs to be 4-wire
RS-485 i.e. the slave Tx is in tri-state until the slave is addressed.

On a PC side, do NOT use standard RS-232 PC ports followed by an
RS-232 to RS-422/485 external converter, there is a great risks for
timing problems. Use proper RS-422/485 PCI cards (or external Ethernet
to RS-422/485 converter for laptops).
Click to expand...

PCI cards? What\'s wrong with USB cables? FTDI makes chips that provide serial ports from USB interfaces. I would use an RS-422 adapter as that provides separate transmit and receive interfaces. The PC does not need to tristate the RS-422 output, so it doesn\'t matter if there are risks of \"timing problems\".

The chip FTDI makes is a small, very fast processor, that emulates serial ports in software. It is the same processor for all interfaces, including SPI and JTAG. As others have said, their devices just work, and there are no timing problems. I\'ll probably provide for the ability to use either split RS-422 buses or a single RS-485 type bus. The driver/receiver chips are the same. It\'s just how they are connected.

Easy enough to try both.

--

Rick C.

---- Get 1,000 miles of free Supercharging
---- Tesla referral code - https://ts.la/richard11209
 
On Friday, November 4, 2022 at 10:57:09 AM UTC-4, Ricky wrote:
On Friday, November 4, 2022 at 5:17:57 AM UTC-4, upsid...@downunder.com wrote:
On Tue, 1 Nov 2022 22:30:58 -0700 (PDT), Ricky
gnuarm.del...@gmail.com> wrote:

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.
The master can be standard RS-422, but the slaves needs to be 4-wire
RS-485 i.e. the slave Tx is in tri-state until the slave is addressed.

On a PC side, do NOT use standard RS-232 PC ports followed by an
RS-232 to RS-422/485 external converter, there is a great risks for
timing problems. Use proper RS-422/485 PCI cards (or external Ethernet
to RS-422/485 converter for laptops).
PCI cards? What\'s wrong with USB cables? FTDI makes chips that provide serial ports from USB interfaces. I would use an RS-422 adapter as that provides separate transmit and receive interfaces. The PC does not need to tristate the RS-422 output, so it doesn\'t matter if there are risks of \"timing problems\".

The chip FTDI makes is a small, very fast processor, that emulates serial ports in software. It is the same processor for all interfaces, including SPI and JTAG. As others have said, their devices just work, and there are no timing problems. I\'ll probably provide for the ability to use either split RS-422 buses or a single RS-485 type bus. The driver/receiver chips are the same. It\'s just how they are connected.

Easy enough to try both.

--

Rick C.

---- Get 1,000 miles of free Supercharging
---- Tesla referral code - https://ts.la/richard11209
Click to expand...

I haven\'t quite followed the entire thread, not sure of the bandwidth requirements or the need for full duplex communication. If noise immunity is of concern, you may want to consider 4-20ma current loops. Some years ago, I designed a RS-232 to 4-20ma converter. The control computer connected to ~ 50 micros in the plant (10 micros/loop). The communication topology was basically a token ring. I also wrote the communication code on the micros. Don\'t know if you want to go down this road - probably looking for something out of the box.
Of course there are lots of other system requirements that need to be taken into account, e.g. minimum event latency, etc. They would need to be looked at when considering the network topology.
 
On Friday, November 4, 2022 at 5:55:32 PM UTC-4, three_jeeps wrote:
On Friday, November 4, 2022 at 10:57:09 AM UTC-4, Ricky wrote:
On Friday, November 4, 2022 at 5:17:57 AM UTC-4, upsid...@downunder.com wrote:
On Tue, 1 Nov 2022 22:30:58 -0700 (PDT), Ricky
gnuarm.del...@gmail.com> wrote:

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.
The master can be standard RS-422, but the slaves needs to be 4-wire
RS-485 i.e. the slave Tx is in tri-state until the slave is addressed..

On a PC side, do NOT use standard RS-232 PC ports followed by an
RS-232 to RS-422/485 external converter, there is a great risks for
timing problems. Use proper RS-422/485 PCI cards (or external Ethernet
to RS-422/485 converter for laptops).
PCI cards? What\'s wrong with USB cables? FTDI makes chips that provide serial ports from USB interfaces. I would use an RS-422 adapter as that provides separate transmit and receive interfaces. The PC does not need to tristate the RS-422 output, so it doesn\'t matter if there are risks of \"timing problems\".

The chip FTDI makes is a small, very fast processor, that emulates serial ports in software. It is the same processor for all interfaces, including SPI and JTAG. As others have said, their devices just work, and there are no timing problems. I\'ll probably provide for the ability to use either split RS-422 buses or a single RS-485 type bus. The driver/receiver chips are the same. It\'s just how they are connected.

Easy enough to try both.

--

Rick C.

---- Get 1,000 miles of free Supercharging
---- Tesla referral code - https://ts.la/richard11209
I haven\'t quite followed the entire thread, not sure of the bandwidth requirements or the need for full duplex communication. If noise immunity is of concern, you may want to consider 4-20ma current loops. Some years ago, I designed a RS-232 to 4-20ma converter. The control computer connected to ~ 50 micros in the plant (10 micros/loop). The communication topology was basically a token ring. I also wrote the communication code on the micros. Don\'t know if you want to go down this road - probably looking for something out of the box.
Of course there are lots of other system requirements that need to be taken into account, e.g. minimum event latency, etc. They would need to be looked at when considering the network topology.
Click to expand...

Thanks for your reply. Noise immunity is why I\'m using RS-422, but I could just as easily use RS-232 for the noise aspects. The problem is RS-232 is hard to use in a multiple transmitter arrangement. It\'s also not specified for higher bit rates, even if some chips support it.

I started looking at RS-422 mostly because I\'m familiar with it and an RS-422 chip is already on the UUT. I like using the same components on the test fixture as the UUT, it makes my life easier in many regards.

A current loop would work fine for this app, except it would make the cabling a bit more complex. We need to be able to take cards out of the system at will. For a current loop, that would mean cabling in a way that always completes the loop. It also means an adapter board in addition to the USB cable to the PC, plus extra logic on the slave boards, even if it is very simple logic. I believe the slaves would be an opto-isolator, plus something to open the loop when transmitting, so an analog switch or FET? In other words, it\'s design work rather than just plopping an RS-422 chip on the board. Is there an equivalent 20 mA current loop chip I could use?

The RS-422 solution lets me use a bog standard chip and all cabling is just in parallel, so very easy to implement without thinking about keeping the loop complete. I\'m not saying that\'s tricky, but I guarantee that with this being torn down and reinstalled every day to remove the UUTs, it would result in a screw up by every member of the test team at least once. It\'s also one run, not multiple loops to prevent the need for a higher voltage with the greater number of nodes.

--

Rick C.

---+ Get 1,000 miles of free Supercharging
---+ Tesla referral code - https://ts.la/richard11209
 
On Friday, November 4, 2022 at 5:17:26 PM UTC-7, Ricky wrote:

> The RS-422 solution lets me use a bog standard chip and all cabling is just in parallel, so very easy to implement...

Each pair is a short drop from the backbone; how do you wire that \'in parallel\' when it requires two terminated
endpoints on a serial string? U-turn cables, and plug in a dummy short link when a slave is
removed from the ensemble?
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top