Shared Communications Bus - RS-422 or RS-485

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.

Reply to
Ricky
Loading thread data ...

Most PCs these days have an ethernet port

Reply to
Jan Panteltje

Really? Who makes Ethernet to TTL converters? I guess I'd half to use a bunch of them, like 20! Anything that you treat like a component without a bunch of programming? I've already got the test code to drive the serial port.

Reply to
Ricky

Apple's old (1980's) LocalTalk scheme does this, using RS-422 style transceivers and transformer coupling. You can get Keyspan balanced-pair USB/serial ports and (used to be) PhoneNet transformer boxes off-the-shelf to use telco-style twisted pair wiring. For short spans, not even twisted.

But, to get speed, you need an MSI serial port as smart as the Z8530 was to do the encoding/decoding for the transformer coupling to work. With simple paired wire (no transformers) your protocol would still need a high-impedance state for the transceivers.

That's why open-collector and I2C and its brethren are usually used.

Reply to
whit3rd

On a sunny day (Tue, 1 Nov 2022 23:01:48 -0700 (PDT)) it happened Ricky snipped-for-privacy@gmail.com wrote in snipped-for-privacy@googlegroups.com:

Any Micochip PIC (24$50 cents plus interface chip, an other 2$50 cents used in in several projects, for example:

formatting link
formatting link
RS232 to UDP Ethernet adaptor:
formatting link
thoo use my own UDP stack, if needed Microchip had a free TCP stack last time I looked. color pic has been working now for many years 24/7 for room lighting here.

Not even an i2c chip can be used wihout some code

Would not surpeize me a bit if ebay had a complete RS232 to ethernet module, google?

Reply to
Jan Panteltje

I2C is slow. Isn't the fast version only 400 kbps? Besides, that's not generally used off board. The whole reason for worrying about this is because the boards are in a rack, but not with a "proper" back plane and the PC controlling it is a few feet of cable away.

Better to use the RS-422, but transformer coupling is overkill. That would be useful when the devices are plugged into different outlets in different rooms, perhaps, to deal with more pronounced ground issues.

Reply to
Ricky

Why would I want to fuss with all that programming? I've got enough on my plate as it is.

Good reason to not use an I2C chip. I'm using a serial port and that code is already written and working. Didn't I mention that?

That's just what I need, buggy eBay crap devices.

I tried using a number of no name serial cables, but they may work... mostly, but crap out periodically and have to be rebooted. So now I only use FTDI and I might use Prolific if I can find a cable I know is using *their* chips. I can buy a cable directly from FTDI and I know it will work.

The Ethernet is also a PITA as I don't want to run TTL levels between the boards. So it would have to be a minmum of 20 of these Ethernet modules. They would all need to be set up, etc., etc. With the RS-422, the protocol can address the boards based on their address set via a few jumpers or some switch blocks. Maybe I could find some nice hex dial wheels? One hex dial would get me 16 boards in a rack. Better than jumpers because there are no parts to lose when they aren't in place. Instead of putting them on one pin, people take them off and they get lost.

Hmmm, two racks of 16 boards each, testing 8 UUTs per board, would be 256 a day or 1280 a week. Wow! That's a year's production in 14 weeks. I think one rack will do the job just fine! Just 9 test fixture boards will suffice for the projected volume.

I don't actually know much about the mechanical aspects of Euroboard racks. The ones I'm working with now have very nice injector / ejector latches, and front panels that provide board support. That's another issue to deal with. The UUTs are a PITA to remove from the test fixtures, a pair of 20 pin headers have a lot of resistance and the daughter cards are very narrow. Very easy to let twist in your fingers, bending pins on the test fixture. The test fixtures need a lot of support.

The connectors are likely going to be cabled, not rack mounted. Only need a 6 pin cable for the comms and a single power voltage. Probably use a laptop supply, and daisy chain that along the cards.

By the time I'm done, this test fixture may be more work than the respin of the daughter card.

Reply to
Ricky

On a sunny day (Wed, 2 Nov 2022 01:00:43 -0700 (PDT)) it happened Ricky snipped-for-privacy@gmail.com wrote in snipped-for-privacy@googlegroups.com:

mmm

Well I have many, all work. I did have not working chips from ebay on occasion, got a refund. Bad connectors too.

I have used euro card racks, big projects, no problems.

Have fun :-)

Reply to
Jan Panteltje

The automotive market seems to be moving towards single pair ethernet, but CAN will undoubtedly be around for a very long time.

John

Reply to
John Walliker

The LocalTalk transmitters (AM26LS31) were RS-422 compliant, with high-Z enables on each (four drivers per chip). They'll drive a twisted-pair backbone, with 110 ohm terminations on each end. If you're sure rack boards only talk to the host, and listen to the host, then... yeah, you can chain all slaves to listen on pair 1, and talk on pair 2, but the master to talk on pair 1 and listen on pair 2. But, the wiring has to be in series (master and two terminators, slave 1, slave 2, ... slave N, and two terminators) . Heck, Cat5 has four pairs, you could U-turn at the end and put all the terminators at the master.

Reply to
whit3rd

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

Reply to
Clive Arthur

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.

Arie

Reply to
Arie de Muijnck

which is basically RS-442

Reply to
Lasse Langwadt Christensen

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.

Arie

Reply to
Arie de Muijnck

Where would the CAN enabled MCU go??? There are no MCUs in this design and I'm looking for lowest effort here. I'm not adding anything more than was is required. I think an RS-422 chip is a lot simpler than CAN bus.

Reply to
Ricky

I'm only using Eurocard for the size and mechanical details. I wish I knew more about the details. There seems to be a lot of hardware to support it, but I'm not sure which bits I need and which I don't or even what bits are out there.

Reply to
Ricky

Hmmm... Cat5 cable is just what I want. I've been thinking about various connectors, but that's the ticket!

Unfortunately, the master is a sealed cable. But that's ok, Cat5 cable is definitely the way to go.

Reply to
Ricky

I believe most such transceivers are rated to drive up to 32 loads. I guess that's more of a DC level thing. The cards can be connected to buffer the signals, to reduce the capacitive loading. This would accumulate propagation delays. I'd need to check that out a bit.

Reply to
Ricky

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?

Reply to
Ricky

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.

Reply to
Ricky

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.