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.

--

Rick C.

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

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.

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

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

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

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.

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.

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.

Il 02/11/2022 10:28, David Brown ha scritto:
> On 02/11/2022 06:28, Rick C wrote:

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

However this depends on the speed of slave too, because it could be slow
to move *its* direction from TX to RX. If the master starts transmitting
after the stop bit from the slave, but *before* it changes *its*
direction from TX to RX, the first bytes could be corrupted.

Unfortunately, not all UARTs in MCUs are able to drive automatically the
DE (Drive Enable) signal, so it sometimes happens that DE is a normal GPIO.
If you are lucky, you have the TXC (transmit complete) interrupt that
fires *after* stop bit is transmitted, a safe time to move DE signal.

In this case interrupt delay is short, but you could have other active
interrupts that occasionally could delay the TXC interrupt for some time.

On 02/11/2022 11:54, pozz wrote:
> Il 02/11/2022 10:28, David Brown ha scritto:
>> On 02/11/2022 06:28, Rick C wrote:
>
>> 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.
>>
>> 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.  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.
>
> However this depends on the speed of slave too, because it could be slow
> to move *its* direction from TX to RX. If the master starts transmitting
> after the stop bit from the slave, but *before* it changes *its*
> direction from TX to RX, the first bytes could be corrupted.

True, and it that is an important point.

>
> Unfortunately, not all UARTs in MCUs are able to drive automatically the
> DE (Drive Enable) signal, so it sometimes happens that DE is a normal GPIO.
> If you are lucky, you have the TXC (transmit complete) interrupt that
> fires *after* stop bit is transmitted, a safe time to move DE signal.

I think the OP has FPGA's for the slave side of the equation, so there
should not be a delay in switching their drivers off after the last byte
is sent. Even if it is a microcontroller and has no hardware control
for the DE line, pretty much any half-decent microcontroller from this
century has a TXC interrupt and can react and turn off the driver within
a few microseconds. I am assuming he is not trying to do this project
using PIC's or 8051's !

>
> In this case interrupt delay is short, but you could have other active
> interrupts that occasionally could delay the TXC interrupt for some time.
>

If this kind of thing is a risk, then it's not hard to put a short delay
on the PC side between receiving a reply and sending out the next
telegram. But it's good that you brought it up, so that the OP can
decide if it /is/ a risk.

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

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

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

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

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

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

--

Rick C.

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

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

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> 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 make a huge shared bus, I wonder if you could move the test
controller from a PC to a small microprocessor board that controls two
FPGA's or whatever. Then use a bunch of separate boards of that type,
communicating with a PC using some method that doesn't have to be
especially fast. The microprocessor board could be something like a
Raspberry Pi Pico, which costs $4 and can run Mecrisp, if that is what
your software is written with. It is quite a powerful little board.

On Wednesday, November 2, 2022 at 4:49:16 PM UTC-4, David Brown wrote:
> 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.

Not sure of your point. Multi-drop is multiple receivers on a single transmitter. Multi-point is multiple drivers and receivers. Look at a few references. Even wikipedia says, "RS-422 provides for data transmission, using balanced, or differential, signaling, with unidirectional/non-reversible, terminated or non-terminated transmission lines, point to point, or multi-drop. In contrast to EIA-485, RS-422/V.11 does not allow multiple drivers but only multiple receivers."

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

Sure, but the point is, nothing in RS-422 precludes multiple receivers, and in fact, every reference I've found (not paying for the actual spec) shows multi-drop receivers.

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

I don't believe that is correct. If you have a copy of the spec to share, I'd love to look at it. I might have one myself, but it would be a paper copy somewhere unknown. The diagrams showing multi-drop RS-422 is so ubiquitous, I expect they are from the standard itself.

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

So, what range of speeds have you used? It is actually the UART hardware that *does* get it very wrong by working off the transmitter empty signal, which changes in the middle of the bit. The control has to be specially designed to transition at the *end* of the stop bit of the transmitted character. Knowing when it is ok to enable the driver has the same problem. The data is "received" in the middle of the stop bit. So the enable has to be a half bit time later, at the end of the stop bit.

None of this matters to me really. I'm going to use more wires, and do the multi-drop from the PC to the slaves on one pair and use RS-422 to multi-point from the slaves to the PC. Since the slaves are controlled by the master, they will never collide. The master can't collide with itself, so I can ignore any issues with this. I will use the bias resistors to assure a valid idle state. I may need to select different devices than the ones I use in the product. I think there are differences in the input load and I want to be sure I can chain up to 32 units.

> 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 don't seem to understand that there is nothing timing from the start of the bit. The timing is from the first detected low of the start bit. From there, all timing is done by an internal clock. Check the math, you don't get 50% of the stop bit, guaranteed. That's why they call it "asynchronous" serial.

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

I know the master has the most trouble with this. The slaves tend to not have a problem because they are operated by MCUs and can wait a bit time before replying, or even a character time. I suppose they don't have any magic on turning off the driver though, but early is the easy way and generally doesn't cause a problem. The master has trouble on both ends of it's message, needing to be careful to not turn on the driver too soon and not turning it off too late to clobber the reply.

On Wednesday, November 2, 2022 at 6:01:02 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> > 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 make a huge shared bus, I wonder if you could move the test
> controller from a PC to a small microprocessor board that controls two
> FPGA's or whatever. Then use a bunch of separate boards of that type,
> communicating with a PC using some method that doesn't have to be
> especially fast. The microprocessor board could be something like a
> Raspberry Pi Pico, which costs $4 and can run Mecrisp, if that is what
> your software is written with. It is quite a powerful little board.

I'm lost. How is this any better? The data collection is running on the PC, so there still has to be communications. If I want to make changes to the test program, it's one place, not 32 places, or 128 places. All they would be doing is acting as a serial port concentrator. They went out 40 years ago!

--

Rick C.

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

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> I'm lost. How is this any better? The data collection is running on
> the PC, so there still has to be communications... All they would be
> doing is acting as a serial port concentrator. They went out 40 years
> ago!

Well, I always like doing stuff in software instead of hardware. Serial
port concentrators are still around and I posted a link to one in your
other thread. It seems like a reasonable approach too. Oddly, a quick
web search doesn't find any big cheap serial to ethernet ones, but maybe
you could use USB hubs and FTDI-like cables.

The idea of using an MCU is to move almost everything speed critical
away from the PC. The MCU only has control the FPGA's and transfer
transfer digested data upwards to the PC. By having some fanout you
could potentially control 1000s of UUT instead of 80 from a single PC,
without having to build anything special. It would just mean plugging
some off the shelf boxes together, and writing some code.

You're more comfortable with hardware than I am, so maybe that approach
has less attraction for you than it does for me.

On Wednesday, November 2, 2022 at 8:37:03 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> > I'm lost. How is this any better? The data collection is running on
> > the PC, so there still has to be communications... All they would be
> > doing is acting as a serial port concentrator. They went out 40 years
> > ago!
> Well, I always like doing stuff in software instead of hardware.

What hardware can you replace with software??? You use *different* hardware and then have to add new software. That's not an improvement.

> Serial
> port concentrators are still around and I posted a link to one in your
> other thread. It seems like a reasonable approach too. Oddly, a quick
> web search doesn't find any big cheap serial to ethernet ones, but maybe
> you could use USB hubs and FTDI-like cables.

I'm getting tired of discussing this. Your added hardware solves no problems. Having 32 serial ports just makes the software more complex and saves nothing.

> The idea of using an MCU is to move almost everything speed critical
> away from the PC. The MCU only has control the FPGA's and transfer
> transfer digested data upwards to the PC. By having some fanout you
> could potentially control 1000s of UUT instead of 80 from a single PC,
> without having to build anything special. It would just mean plugging
> some off the shelf boxes together, and writing some code.
>
> You're more comfortable with hardware than I am, so maybe that approach
> has less attraction for you than it does for me.

What hardware??? It's a serial port either way. You want to add a middle man that accomplishes nothing. You talk about controlling 1000's of UUTs, but there is no need for that.

What I need at this point, is the mechanical details of how to design a board to fit into a Eurocard chassis and how to figure out all the bits that go with it.

--

Rick C.

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

On 03/11/2022 00:27, Rick C wrote:
> On Wednesday, November 2, 2022 at 4:49:16 PM UTC-4, David Brown wrote:
>> 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.
>
> Not sure of your point. Multi-drop is multiple receivers on a single transmitter. Multi-point is multiple drivers and receivers. Look at a few references. Even wikipedia says, "RS-422 provides for data transmission, using balanced, or differential, signaling, with unidirectional/non-reversible, terminated or non-terminated transmission lines, point to point, or multi-drop. In contrast to EIA-485, RS-422/V.11 does not allow multiple drivers but only multiple receivers."
>

OK. I have always associated "multidrop" with multiple receivers /and/
transmitters - I have never come across a need for multiple receivers on
a serial bus without them also needing to transmit (such as in your
case), or a distinction between "multi-drop" meaning multiple receivers
and "multi-point" meaning multiple transmitters.

The term "multi-drop" is more commonly taken to mean "multiple devices
connected directly to the same bus, transmitting and receiving". The
bus has no explicit direction on the electrical connections. Examples
include RS-485, CAN, co-ax Ethernet.

"Multi-point" is more general and can be any kind of network where there
are multiple nodes that can send and receive to all other nodes. That
would include a switched Ethernet network as well as the subclass of
"multi-drop" networks.

But whatever the terms, I think we agree on how RS-422 works.

>
>> 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.
>
> Sure, but the point is, nothing in RS-422 precludes multiple receivers, and in fact, every reference I've found (not paying for the actual spec) shows multi-drop receivers.
>

Yes, it seems that is entirely possible. The only uses I have seen for
RS-422 is as a kind of long-range alternative to RS-232. And the only
use I have seen for multiple receivers is - like for RS-232 - for
monitoring and debugging communication.

Still, multiple receivers are not going to help you in your testbench
unless they can also transmit.

>
>> 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.
>
> I don't believe that is correct. If you have a copy of the spec to share, I'd love to look at it. I might have one myself, but it would be a paper copy somewhere unknown. The diagrams showing multi-drop RS-422 is so ubiquitous, I expect they are from the standard itself.
>
>
>>>>> 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.
>
> So, what range of speeds have you used? It is actually the UART hardware that *does* get it very wrong by working off the transmitter empty signal, which changes in the middle of the bit. The control has to be specially designed to transition at the *end* of the stop bit of the transmitted character. Knowing when it is ok to enable the driver has the same problem. The data is "received" in the middle of the stop bit. So the enable has to be a half bit time later, at the end of the stop bit.

For RS-485, my usage has usually been quite slow (9600 baud is very
common). Other colleagues have used faster rates. But as I said, it is
the slow baud rates that are at higher risk.

However, without knowing exact implementation details of all UART
hardware, I think you are wrong. There are two "finished byte" signals
that are common in UART transmission hardware.

The first is "transmit buffer empty" which is set when a byte is
transferred from the buffer into the transmitter shift register - most
UARTs are at least double-buffered to improve flow. This signal comes a
whole character before the end of the transmission - it is useful for
the software, but not the hardware. If you have a transmitter that is
not double-buffered, this signal would likely come at the beginning of
the stop bit, or at the end of the stop bit (depending on how the state
machines were made).

Il 03/11/2022 12:42, David Brown ha scritto:
> On 03/11/2022 00:27, Rick C wrote:
>> On Wednesday, November 2, 2022 at 4:49:16 PM UTC-4, David Brown wrote:
>>> 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:

> You are correct that reception is in the middle of the stop bit
> (typically sub-slot 9 of 16).  The first transmitter will be disabled at
> the end of the stop bit, and the next transmitter must not enable its
> driver until after that point - it must wait at least half a bit time
> after reception before starting transmission.  (It can wait longer
> without trouble, which is why faster baud rates are less likely to
> involve any complications here.)

Do you mean that RX interrupt triggers in the middle of the stop bit and
not at the end? Interesting, but are you sure this is the case for every
UART implemented in MCUs?

I wouldn't be surprised if the implementation was different for
different manufacturers.

>> None of this matters to me really.  I'm going to use more wires, and
>> do the multi-drop from the PC to the slaves on one pair and use RS-422
>> to multi-point from the slaves to the PC.  Since the slaves are
>> controlled by the master, they will never collide.  The master can't
>> collide with itself, so I can ignore any issues with this.  I will use
>> the bias resistors to assure a valid idle state.  I may need to select
>> different devices than the ones I use in the product.  I think there
>> are differences in the input load and I want to be sure I can chain up
>> to 32 units.
>>
>
> OK.  I have no idea what such a hybrid bus should technically be called,
> but I think it should work absolutely fine for the purpose and seems
> like a solid solution.  I would not foresee any issues with 32 nodes on
> such a bus, especially if it is relatively short and you have
> terminators at each end.

In my experience, termination resistors at each end of the line could
introduce other troubles if they aren't strictly required (because of
signal integrity on long lines at high baud rates).

The receiver input impedance of all the nodes on the bus are in parallel
with the two terminators. If you have many nodes, the equivalent
impedance on the bus is much small and the partition with bias resistors
could reduce the differential voltage between A and B at idle to less
than 200mV.

If you don't use true fail-safe transceivers, a fault start bit could be
seen by these kind of receivers.

On 03/11/2022 14:00, pozz wrote:
> Il 03/11/2022 12:42, David Brown ha scritto:
>> On 03/11/2022 00:27, Rick C wrote:
>>> On Wednesday, November 2, 2022 at 4:49:16 PM UTC-4, David Brown wrote:
>>>> 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:
>
>
>> You are correct that reception is in the middle of the stop bit
>> (typically sub-slot 9 of 16).  The first transmitter will be disabled
>> at the end of the stop bit, and the next transmitter must not enable
>> its driver until after that point - it must wait at least half a bit
>> time after reception before starting transmission.  (It can wait
>> longer without trouble, which is why faster baud rates are less likely
>> to involve any complications here.)
>
> Do you mean that RX interrupt triggers in the middle of the stop bit and
> not at the end? Interesting, but are you sure this is the case for every
> UART implemented in MCUs?

Of course I'm not sure - there are a /lot/ of MCU manufacturers!

UART receivers usually work in the same way, however. They have a
sample clock running at 16 times the baud clock. The start bit is edge
triggered to give the start of the character frame. Then each bit is
sampled in the middle of its time slot - usually at subbit slots 7, 8,
and 9 with majority voting. So the stop bit is recognized by subbit
slot 9 of the tenth bit (assuming 8-bit, no parity) - the voltage on the
line after that is irrelevant. (Even when you have two stop bits,
receivers never check the second stop bit - it affects transmit timing
only.) What purpose would there be in waiting another 7 subbits before
triggering the interrupt, DMA, or whatever?

>
> I wouldn't be surprised if the implementation was different for
> different manufacturers.
>

I've seen a bit of variation, including 8 subbit clocks per baud clock,
wider sampling ranges, re-sync of the clock on edges, etc. And of
course you don't always get the details of the timings in datasheets
(and who bothers measuring them?) But the key principles are the same.

>
>>> None of this matters to me really.  I'm going to use more wires, and
>>> do the multi-drop from the PC to the slaves on one pair and use
>>> RS-422 to multi-point from the slaves to the PC.  Since the slaves
>>> are controlled by the master, they will never collide.  The master
>>> can't collide with itself, so I can ignore any issues with this.  I
>>> will use the bias resistors to assure a valid idle state.  I may need
>>> to select different devices than the ones I use in the product.  I
>>> think there are differences in the input load and I want to be sure I
>>> can chain up to 32 units.
>>>
>>
>> OK.  I have no idea what such a hybrid bus should technically be
>> called, but I think it should work absolutely fine for the purpose and
>> seems like a solid solution.  I would not foresee any issues with 32
>> nodes on such a bus, especially if it is relatively short and you have
>> terminators at each end.
>
> In my experience, termination resistors at each end of the line could
> introduce other troubles if they aren't strictly required (because of
> signal integrity on long lines at high baud rates).
>

RS-485 requires them - you want to hold the bus at a stable idle state
when nothing is driving it. You also want to have a bit of load so that
you have some current on the bus, and thereby greater noise immunity.

> The receiver input impedance of all the nodes on the bus are in parallel
> with the two terminators. If you have many nodes, the equivalent
> impedance on the bus is much small and the partition with bias resistors
> could reduce the differential voltage between A and B at idle to less
> than 200mV.
>
> If you don't use true fail-safe transceivers, a fault start bit could be
> seen by these kind of receivers.
>

Receiver load is very small on modern RS-485 drivers.

On Thursday, November 3, 2022 at 9:01:00 AM UTC-4, pozz wrote:
> Il 03/11/2022 12:42, David Brown ha scritto:
> > On 03/11/2022 00:27, Rick C wrote:
> >> On Wednesday, November 2, 2022 at 4:49:16 PM UTC-4, David Brown wrote:
> >>> 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:
>
>
> > You are correct that reception is in the middle of the stop bit
> > (typically sub-slot 9 of 16). The first transmitter will be disabled at
> > the end of the stop bit, and the next transmitter must not enable its
> > driver until after that point - it must wait at least half a bit time
> > after reception before starting transmission. (It can wait longer
> > without trouble, which is why faster baud rates are less likely to
> > involve any complications here.)
> Do you mean that RX interrupt triggers in the middle of the stop bit and
> not at the end? Interesting, but are you sure this is the case for every
> UART implemented in MCUs?

No, I have not tested every MCU UART ever made. This was the case when I tried using RS-485 many years ago and was in every UART chip available. I forget the number, but there was a particular part made by Western Digital that became the "standard". It blossomed into a family of devices with small improvements in each (typically adding a FIFO and the size of the FIFO). I never saw one of that family which changed this "feature". It's because the purpose of this signal was not to control a driver, but to signal to a CPU the buffer condition. The UART timing is to first align to the middle of the start bit, then continue marking the time for bit centers. When it times the middle of the stop bit, the receiver or transmitter is done and flags the received character is available or the transmitter register is empty. The stop bit is the default value of the line, so nothing further has to be done in the UART, other than the receiver entering the start bit hunt mode.

If a modern UART has a separate signal that flags the end of the stop bit time, that would be great, but I have no reason to think this is available in every case, or any particular case, unless it is documented, *well* documented. Have you seen any parts that specifically indicate they flag the end of the stop bit of characters received or transmitted?

I recall the 8251 USART by Intel was full of bugs and this flag was no exception.

> I wouldn't be surprised if the implementation was different for
> different manufacturers.

Of course. The trouble is knowing which ones have what!

> >> None of this matters to me really. I'm going to use more wires, and
> >> do the multi-drop from the PC to the slaves on one pair and use RS-422
> >> to multi-point from the slaves to the PC. Since the slaves are
> >> controlled by the master, they will never collide. The master can't
> >> collide with itself, so I can ignore any issues with this. I will use
> >> the bias resistors to assure a valid idle state. I may need to select
> >> different devices than the ones I use in the product. I think there
> >> are differences in the input load and I want to be sure I can chain up
> >> to 32 units.
> >>
> >
> > OK. I have no idea what such a hybrid bus should technically be called,
> > but I think it should work absolutely fine for the purpose and seems
> > like a solid solution. I would not foresee any issues with 32 nodes on
> > such a bus, especially if it is relatively short and you have
> > terminators at each end.
> In my experience, termination resistors at each end of the line could
> introduce other troubles if they aren't strictly required (because of
> signal integrity on long lines at high baud rates).
>
> The receiver input impedance of all the nodes on the bus are in parallel
> with the two terminators. If you have many nodes, the equivalent
> impedance on the bus is much small and the partition with bias resistors
> could reduce the differential voltage between A and B at idle to less
> than 200mV.

That depends on the details of the receivers and drivers. I have control over that other than the USB cable. To assure I'm using appropriate RS-422 devices, I could use a TTL cable and on the first test fixture board use a separate connector with TTL level signaling. This would then be buffered on this first board to RS-422 for the rest of the chain. I could do all this with RS232, but it doesn't provide for tristate on the outputs. Not that I recall anyway.

> If you don't use true fail-safe transceivers, a fault start bit could be
> seen by these kind of receivers.

Sorry, I don't know what you mean by "fail-safe" transceivers. Are you talking about the driver or the receiver? Do you mean the internal bias some receivers have, so with zero volts across the input pair they are in a defined state? That can be done through external resistors as well.

I'm expecting to use shorting jumpers for setting various modes on these test fixtures. Do they make any shorting jumpers that are more than just two pins? I've never seen that. I suppose I could make one using a connector and wire.

I think my biggest problem is going to be the mechanical parts of the chassis. I need the boards to be very strong to withstand many insertion removal cycles of the UUTs from these boards. We currently do burn in using production Eurocard format units. They are very stiff with a rail on the front.. I just realized, they probably get a lot of stiffening from the massive Eurocard connectors on the back and similar connectors on the front panel. I was planning to use a front panel, but maybe I need to add board stiffeners as well. In the "old" days, when DIPs roamed the earth, these were a combination of power decoupling capacitor and board stiffener. They probably don't even make them anymore. I really need the board to be solid so it doesn't suffer damage from the strain of repeated use. Maybe I just need to bolt a hunk of metal to the card.

--

Rick C.

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

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> What hardware can you replace with software??? You use *different*
> hardware and then have to add new software. That's not an
> improvement.

The idea is to avoid BUILDING hardware. Plugging cables into a box is
not building. There is no soldering iron, oscilloscope, or anything
like that in the picture. If you already avoid that, then great.

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> I think my biggest problem is going to be the mechanical parts of the
> chassis. I need the boards to be very strong to withstand many
> insertion removal cycles of the UUTs from these boards.

I wonder if you can use some kind of low-force connector or cable on the
card, instead of plugging and unplugging the card from a chassis.

E.g. something like https://www.adafruit.com/product/5468 depending on
how many conductors are needed.

On Thursday, November 3, 2022 at 12:57:41 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> > What hardware can you replace with software??? You use *different*
> > hardware and then have to add new software. That's not an
> > improvement.
> The idea is to avoid BUILDING hardware. Plugging cables into a box is
> not building. There is no soldering iron, oscilloscope, or anything
> like that in the picture. If you already avoid that, then great.

You seem to misunderstand. I AM building hardware. There's no choice in that matter. You want me to add other hardware and also software that adds nothing, improves nothing, and just creates more potential problems. This all seems to be because you can't understand the very, very simple nature of a master-slave shared bus and a polling protocol.

The bottom line is, you don't know much about the application, but think you can design it better. Why are you doing this?

The only way to "improve" this, might be to use RS-232 instead of RS-422. But that loses the noise immunity of the differential signaling and would require adding analog switches to the slave transmit outputs. It is also very unspecified, so I'd have to do more engineering to be sure it will work. So RS-422 is looking pretty good to me.

The connectors will be RJ-45 8P8C connectors. They are cheap and easy to plug/unplug. They mount securely to the board and can even be integrated into the front panel rather than hanging out the back. I still need to figure out how to distribute power. It's probably going to be plugs like they use on PC laptop supplies. This will most likely be supplied by a laptop supply, so I'll need a board that splits out the one PSU to 16 power cables. Sounds like a job for perf board and a small, plastic case. The supply on my laptop is 300W. That should do the trick easily.

--

Rick C.

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

On Thursday, November 3, 2022 at 1:36:31 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> > I think my biggest problem is going to be the mechanical parts of the
> > chassis. I need the boards to be very strong to withstand many
> > insertion removal cycles of the UUTs from these boards.
> I wonder if you can use some kind of low-force connector or cable on the
> card, instead of plugging and unplugging the card from a chassis.
>
> E.g. something like https://www.adafruit.com/product/5468 depending on
> how many conductors are needed.

How about something like this?

https://www.digikey.com/en/products/detail/amphenol-cs-commercial-products/RJHSE538B02/1979553

That's what I'm going to use. I'd run the power through it as well, but even with the low power I'll be using, 28 ga is a bit small. I'm just not a big fan of the typical barrel power connectors. I'd be happy if they had a detent so they won't fall out. The nylon shell connectors are a pain to remove.

--

Rick C.

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

On 11/2/2022 1:28 AM, 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-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.
>

Hi Rick - I have an RS-485 system on my desk using an implementation of
the old Intel BitBus. Works fine for a handful of nodes, limited
distance, and very simple cabling - but only 62.5kbaud. Good solid
technology for 1994 when I designed it...

Why would you use RS-485 instead of CAN? A million chips out there
support CAN with no fuss, works at decent speeds over twisted pair, not
hard to use.

BTW, another option for interfacing to RS-485 from USB is XR21B1411
which is what I happen to have on my desk.

Hope that helps!
Best Regards, Dave

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> The bottom line is, you don't know much about the application, but
> think you can design it better. Why are you doing this?

You asked for suggestions and I gave some.

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> How about something like this?
>
> https://www.digikey.com/en/products/detail/amphenol-cs-commercial-products/RJHSE538B02/1979553

That appears to be an RJ45 like ethernet cables use. The little locking
tabs break off all the time, and also the cable gets kinked up after
repeated flexing where it goes into the connector. Strain relief helps
but it happens anyway. You might buy some ready made ethernet cables
rather than putting those connectors on yourself. At least with cheap
crimpers, the ready made cables are often more reliable than DIY ones.

They do make those magnetic connectors with varying numbers of pins.

Here is a CAN cable, no idea if that is of interest, but it uses the
OBD connector found in cars: https://www.adafruit.com/product/4841

XLR or DIN style plugs/sockets might also be something to consider.

There is also this style, popular with the mechanical keyboard crowd:
https://www.pchcables.com/aviationplugs.html

On Thursday, November 3, 2022 at 3:37:43 PM UTC-4, Dave Nadler wrote:
> On 11/2/2022 1:28 AM, 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-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.
> >
> Hi Rick - I have an RS-485 system on my desk using an implementation of
> the old Intel BitBus. Works fine for a handful of nodes, limited
> distance, and very simple cabling - but only 62.5kbaud. Good solid
> technology for 1994 when I designed it...
>
> Why would you use RS-485 instead of CAN? A million chips out there
> support CAN with no fuss, works at decent speeds over twisted pair, not
> hard to use.
>
> BTW, another option for interfacing to RS-485 from USB is XR21B1411
> which is what I happen to have on my desk.

I'm using RS-422 because I don't need to learn how to use a "chip". It's the same serial protocol I'm using now, but instead of RS-232 voltage levels, it's RS-422 differential. The "change" is really the fact that it's not just one slave. So the bus will be split into a master send bus and a slave reply bus. The master doesn't need to manage the tri-state output because it's the only talker. The slaves only talk when spoken to and the UART is in an FPGA, (no CPU), so it can manage the tri-state control to the driver chip very easily.

CAN bus might be the greatest thing since sliced bread, but I am going to be slammed with work and I don't want to do anything I don't absolutely have to.

A lot of people don't understand that this is nearly the same as what I'm using now and will only require a very minor modification to the message protocol, to allow the slaves to be selected/addressed. It would be hard to make it any simpler and this would all still have to be done even if adding the CAN bus. The slaves still need to be selected/addressed.

Thanks for the suggestions. The part I'm worried about now are the more mechanical bits. I am thinking of using the Eurocard size so I can use the rack hardware, but I know very little about the bits and bobs. There will be no backplane, just card guides and the front panels on the cards to hold them in place. I might put the cabling on the front panel to give it easy access, but then it needs machining of the front panel. I could simplify that by cutting out one large hole to expose all the LEDs and connectors. I want to make the design work as simple as possible and mechanical drawings are not my forte.

--

Rick C.

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

On Thursday, November 3, 2022 at 3:53:32 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> > The bottom line is, you don't know much about the application, but
> > think you can design it better. Why are you doing this?
> You asked for suggestions and I gave some.

Ok, thank you for your suggestions.

--

Rick C.

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

On Thursday, November 3, 2022 at 4:08:28 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> > How about something like this?
> >
> > https://www.digikey.com/en/products/detail/amphenol-cs-commercial-products/RJHSE538B02/1979553
> That appears to be an RJ45 like ethernet cables use. The little locking
> tabs break off all the time, and also the cable gets kinked up after
> repeated flexing where it goes into the connector. Strain relief helps
> but it happens anyway. You might buy some ready made ethernet cables
> rather than putting those connectors on yourself. At least with cheap
> crimpers, the ready made cables are often more reliable than DIY ones.

The cable will be three inches long. I can make more.

> They do make those magnetic connectors with varying numbers of pins.
>
> Here is a CAN cable, no idea if that is of interest, but it uses the
> OBD connector found in cars: https://www.adafruit.com/product/4841

If you are talking about the big, black connector, it is bigger than the board. This will be a Eurocard rack with 4HP or 0.8 inch spacing. RJ-45 barely fits.

> XLR or DIN style plugs/sockets might also be something to consider.

DIN? You mean those things that are used on Eurocards with some 96 pins? What would mate with it? What's actually wrong with RJ-45?

> There is also this style, popular with the mechanical keyboard crowd:
> https://www.pchcables.com/aviationplugs.html

Way too much work. This is a jumper connector to go between boards that are 0.8 inches on centers. It simply doesn't require that much effort. They will be plugged and unplugged, on average, 1.1 times a day. I think RJ-11 will hack it. I'd rather have something that breaks and is very easy to replace, than something that breaks less often, but is much harder to repair or replace.

--

Rick C.

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