R
Ricky
Guest
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
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
