On Wednesday, November 2, 2022 at 8:32:26 PM UTC-4, lang...@fonz.dk wrote:> torsdag den 3. november 2022 kl. 01.25.31 UTC+1 skrev Ricky: > > On Wednesday, November 2, 2022 at 7:56:34 PM UTC-4, lang...@fonz.dk wrote: > > > torsdag den 3. november 2022 kl. 00.34.39 UTC+1 skrev Ricky: > > > > On Wednesday, November 2, 2022 at 6:12:49 PM UTC-4, Arie de Muijnck wrote: > > > > > On 2022-11-02 20:40, Ricky wrote: > > > > > > On Wednesday, November 2, 2022 at 7:34:03 AM UTC-4, Arie de Muijnck wrote: > > > > > >> I've built test systems like that, without any PC master timing problems. > > > > > >> > > > > > >> Use a 2-pair RS485 bus, one pair for PC TX, one for PC RX. > > > > > >> Use independent RX and TX. On PC side enable TX at all times. > > > > > >> Use a 120R terminator on each end of each pair. > > > > > >> Use one 560R pull-up and 560R pull-down on the RX pair to keep the RX bus noise-free when idle. > > > > > >> > > > > > >> On the device side use separate RS485 RX and TX, enable TX only when replying (and turn off AFTER the stop bit). > > > > > >> > > > > > >> Use Hi-Z RS485 chips, they can handle multi drop up to 256 connections. > > > > > >> > > > > > >> Worked perfectly, even with up to 5V ground differences. > > > > > >> Tested in production environment, CRC error counters stayed zero. > > > > > > > > > > > > Just to be clear, if the talking and listening aren't on the same wires, that just RS-422, not RS-485. No? > > > > > > But yes, that's one very good option. What bit rates were you using? > > > > > The two-pair topology is like RS-422. The three-stating levels are RS-485. This is a hybrid system. > > > > > > > > > > I used about 400 kbps, but if you use small stubs, proper termination and not too long a cable, 1+ Mbps is possible. > > > > > A chip like https://www.ti.com/product/THVD1424 would do: 3.3/5V, full duplex, enables, 20 Mbps, 256 nodes, $1 at 1K+. > > > > > > > > > > But there are cheaper ones, a searching link including filters is: > > > > > https://www.ti.com/interface/rs-485-rs-422/products.html#p994=0;1&p993=0;1.67&p1065=Half&p1064=95;320&o4=1&sort=p1130;asc > > > > This one is plenty cheap enough, but "Out of stock", like many, many devices these days. > > > LCSC have million of transceivers in stock https://lcsc.com/products/RS-485-RS-422-ICs_578.html > > > > > > and most of the SO8 rs-485 ones are likely pin compatible > > The trouble is, I'm not using RS-485. I guess I could use two of these chips and never enable the driver on the receiver part. They have nothing in stock that's actually RS-422 with a separate driver and receiver, also, some level of ESD protection. But thanks for the pointer. I tend to not use LCSC. These days, even they don't have much in stock. > > > using two chips in a package with lots of pin compatible alternatives might be a good strategy there daysThis is a test fixture, not a deliverable. I only need to buy a few. Looking at the schematic for the FTDI cable, they use RS-422 transceivers that have no enables, so they fit in an 8 pin package. The 16-pin TSSOP on the product I'm selling has separate enables on the drivers. The two 8-pin SOICs are twice as large, so it isn't to save space. This was not designed in the last couple of years, so it's not about availability. -- Rick C. ++- Get 1,000 miles of free Supercharging ++- Tesla referral code - https://ts.la/richard11209
Shared Communications Bus - RS-422 or RS-485
Started by ●November 2, 2022
Reply by ●November 3, 20222022-11-03
Reply by ●November 3, 20222022-11-03
On 2022-11-02, Ricky <gnuarm.deletethisbit@gmail.com> wrote:> Rather than working on a way to mux 80 RS-232 interfaces, I'm > thinking it would be better to either daisy chain, or connect in > parallel all these devices. The protocol is master-slave where the > master sends a command and the slaves are idle until they reply. The > four FPGAs on a test fixture board could be connected in parallel > easily enough. But I don't think I want to run TTL level signals > between so many boards.> I could do an RS-422 interface with a master to slave pair and a > slave to master pair. The slaves do not speak until spoken to, so > there will be no collisions.> RS-485 would allow all this to be over a single pair of wires.I would have suggested the same,> But the one big issue I see people complain about is getting PC > software to not clobber the slaves, or I should say, to get the master > to wait long enough that it's not clobbering it's own start bit by > overwriting the stop bit of the slave. I suppose someone, somewhere > has dealt with this on the PC and has a solution that doesn't impact > bus speed. I run the single test fixture version of this at about 100 > kbps. I'm going to want as much speed as I can get for 80 FPGAs > controlling 160 UUTs. Maybe I should give that some analysis, because > this might not be true.RS422 seems the easy solution, you can use a resettable one-shot triggered by pusses on the tx line to set tx_enable (and rely on it to time out while the master is sending the next command on the other pair), but for RS485, all you need to do is use an RS485 capable UART in RS485 mode - that is use a UART that has a hardware output that goes high when there are bits in the send register. for the USB end FT232 will work I think, or CH340B if you're on a budget (this chip enables RS485 mode using an external resistor, meaning there's no need to set some serial port feature flags to enable 485), Choose RS485 transceivers that can have more than 80 devices on the bus (this is most of them but not all). -- Jasen.
Reply by ●November 3, 20222022-11-03
On 2022-11-02, Ricky <gnuarm.deletethisbit@gmail.com> wrote:> On Wednesday, November 2, 2022 at 6:12:19 AM UTC-4, Clive Arthur wrote: >> On 02/11/2022 05:30, Ricky wrote: >> > I have a test fixture that uses RS-232 to communicate with a PC. It actually uses the voltage levels of RS-232, even though this is from a USB cable on the PC, so it's only RS-232 for maybe four inches. lol >> > >> > I'm redesigning the test fixtures to hold more units and fully automate a few features that presently requires an operator. There will now be 8 UUTs on each test fixture and I expect to have 10 to 20 test fixtures in a card rack. That's 80 to 160 UUTs total. There will be an FPGA controlling each pair of UUTs, so 80 FPGAs in total that the PC needs to talk to. >> > >> > Rather than working on a way to mux 80 RS-232 interfaces, I'm thinking it would be better to either daisy chain, or connect in parallel all these devices. The protocol is master-slave where the master sends a command and the slaves are idle until they reply. The four FPGAs on a test fixture board could be connected in parallel easily enough. But I don't think I want to run TTL level signals between so many boards. >> <snip> >> >> I've done similar, though with many fewer nodes, simply by paralleling >> the RS232 inputs and diode oring the outputs. I imagine you might need >> to buffer your PC output and maybe not expect very high speeds. > > I believe most such transceivers are rated to drive up to 32 loads.Find transceivers that are themselves 1/4 load (or less) and you can have 128 on the bus. eg: SN75HVD3082EDR is 1/8 load -- Jasen.
Reply by ●November 3, 20222022-11-03
On 2022-11-02, Arie de Muijnck <eternal.september@ademu.com> wrote:> On 2022-11-03 00:09, Lasse Langwadt Christensen wrote: >> RS485 is simple, reliable and can run quite fast, if you really need more bandwidth you could just split the string and add more interfaces to the PC > > Ricky wants to communicate with a PC. > RS-485 does not handle the timing from the standard PC UART signals well > the disabling of the TX after the last character is a problem.16650 UART has hardware RS485 support - these days that's almost "standard PC UART", but there's no reason not to use a USB UART interface instead, and there's plenty of them that can drive RS485 too.> However, some RS-485 USB dongles have proper TX enabling control by > the UART chip inside, they turn off just after the last stop bit. That > leaves only the slave timing to be considered, and terminators plus > pull-ups / pull-downs.I don't trust anything cheaper than a dollar to do RS485 properly, I verify instead, I have some that do and some that do not :) -- Jasen.
Reply by ●November 3, 20222022-11-03
On Thursday, November 3, 2022 at 3:04:54 AM UTC-4, Jasen Betts wrote:> On 2022-11-02, Arie de Muijnck <eternal....@ademu.com> wrote: > > On 2022-11-03 00:09, Lasse Langwadt Christensen wrote: > >> RS485 is simple, reliable and can run quite fast, if you really need more bandwidth you could just split the string and add more interfaces to the PC > > > > Ricky wants to communicate with a PC. > > RS-485 does not handle the timing from the standard PC UART signals well > > the disabling of the TX after the last character is a problem. > 16650 UART has hardware RS485 support - these days that's almost > "standard PC UART", but there's no reason not to use a USB UART interface > instead, and there's plenty of them that can drive RS485 too. > > However, some RS-485 USB dongles have proper TX enabling control by > > the UART chip inside, they turn off just after the last stop bit. That > > leaves only the slave timing to be considered, and terminators plus > > pull-ups / pull-downs. > I don't trust anything cheaper than a dollar to do RS485 properly, > I verify instead, I have some that do and some that do not :)I don't know why people are pushing RS-485. At this point RS-485 offers no advantages over a split bus, full duplex solution using RS-422. I expect to use a pair of RJ-45 connectors to make cabling simple and cheap, and an FTDI RS-422 USB adapter. The FPGA UART will have perfect control over the transmitter enable using the custom UART already in the design. The FTDI transmitter will remain on all the time, so timing of the transmitter enable is of no consequence. This is about as simple and fool-proof as I can design it. I can't see how RS-485 offers any advantages, other than allowing the use of a smaller connector, RJ-11 perhaps. Actually, I can run the full duplex interface over RJ-11 connectors, it would just require four conductors rather than two (or six if you want to include grounds). -- Rick C. +++ Get 1,000 miles of free Supercharging +++ Tesla referral code - https://ts.la/richard11209
Reply by ●November 4, 20222022-11-04
On Tue, 1 Nov 2022 22:30:58 -0700 (PDT), Ricky <gnuarm.deletethisbit@gmail.com> wrote:>I could do an RS-422 interface with a master to slave pair and a slave to master pair. The slaves do not speak until spoken to, so there will be no collisions.The master can be standard RS-422, but the slaves needs to be 4-wire RS-485 i.e. the slave Tx is in tri-state until the slave is addressed. On a PC side, do NOT use standard RS-232 PC ports followed by an RS-232 to RS-422/485 external converter, there is a great risks for timing problems. Use proper RS-422/485 PCI cards (or external Ethernet to RS-422/485 converter for laptops).
Reply by ●November 4, 20222022-11-04
On Friday, November 4, 2022 at 5:17:57 AM UTC-4, upsid...@downunder.com wrote:> On Tue, 1 Nov 2022 22:30:58 -0700 (PDT), Ricky > <gnuarm.del...@gmail.com> wrote: > > >I could do an RS-422 interface with a master to slave pair and a slave to master pair. The slaves do not speak until spoken to, so there will be no collisions. > The master can be standard RS-422, but the slaves needs to be 4-wire > RS-485 i.e. the slave Tx is in tri-state until the slave is addressed. > > On a PC side, do NOT use standard RS-232 PC ports followed by an > RS-232 to RS-422/485 external converter, there is a great risks for > timing problems. Use proper RS-422/485 PCI cards (or external Ethernet > to RS-422/485 converter for laptops).PCI cards? What's wrong with USB cables? FTDI makes chips that provide serial ports from USB interfaces. I would use an RS-422 adapter as that provides separate transmit and receive interfaces. The PC does not need to tristate the RS-422 output, so it doesn't matter if there are risks of "timing problems". The chip FTDI makes is a small, very fast processor, that emulates serial ports in software. It is the same processor for all interfaces, including SPI and JTAG. As others have said, their devices just work, and there are no timing problems. I'll probably provide for the ability to use either split RS-422 buses or a single RS-485 type bus. The driver/receiver chips are the same. It's just how they are connected. Easy enough to try both. -- Rick C. ---- Get 1,000 miles of free Supercharging ---- Tesla referral code - https://ts.la/richard11209
Reply by ●November 4, 20222022-11-04
On Friday, November 4, 2022 at 10:57:09 AM UTC-4, Ricky wrote:> On Friday, November 4, 2022 at 5:17:57 AM UTC-4, upsid...@downunder.com wrote: > > On Tue, 1 Nov 2022 22:30:58 -0700 (PDT), Ricky > > <gnuarm.del...@gmail.com> wrote: > > > > >I could do an RS-422 interface with a master to slave pair and a slave to master pair. The slaves do not speak until spoken to, so there will be no collisions. > > The master can be standard RS-422, but the slaves needs to be 4-wire > > RS-485 i.e. the slave Tx is in tri-state until the slave is addressed. > > > > On a PC side, do NOT use standard RS-232 PC ports followed by an > > RS-232 to RS-422/485 external converter, there is a great risks for > > timing problems. Use proper RS-422/485 PCI cards (or external Ethernet > > to RS-422/485 converter for laptops). > PCI cards? What's wrong with USB cables? FTDI makes chips that provide serial ports from USB interfaces. I would use an RS-422 adapter as that provides separate transmit and receive interfaces. The PC does not need to tristate the RS-422 output, so it doesn't matter if there are risks of "timing problems". > > The chip FTDI makes is a small, very fast processor, that emulates serial ports in software. It is the same processor for all interfaces, including SPI and JTAG. As others have said, their devices just work, and there are no timing problems. I'll probably provide for the ability to use either split RS-422 buses or a single RS-485 type bus. The driver/receiver chips are the same. It's just how they are connected. > > Easy enough to try both. > > -- > > Rick C. > > ---- Get 1,000 miles of free Supercharging > ---- Tesla referral code - https://ts.la/richard11209I haven't quite followed the entire thread, not sure of the bandwidth requirements or the need for full duplex communication. If noise immunity is of concern, you may want to consider 4-20ma current loops. Some years ago, I designed a RS-232 to 4-20ma converter. The control computer connected to ~ 50 micros in the plant (10 micros/loop). The communication topology was basically a token ring. I also wrote the communication code on the micros. Don't know if you want to go down this road - probably looking for something out of the box. Of course there are lots of other system requirements that need to be taken into account, e.g. minimum event latency, etc. They would need to be looked at when considering the network topology.
Reply by ●November 4, 20222022-11-04
On Friday, November 4, 2022 at 5:55:32 PM UTC-4, three_jeeps wrote:> On Friday, November 4, 2022 at 10:57:09 AM UTC-4, Ricky wrote: > > On Friday, November 4, 2022 at 5:17:57 AM UTC-4, upsid...@downunder.com wrote: > > > On Tue, 1 Nov 2022 22:30:58 -0700 (PDT), Ricky > > > <gnuarm.del...@gmail.com> wrote: > > > > > > >I could do an RS-422 interface with a master to slave pair and a slave to master pair. The slaves do not speak until spoken to, so there will be no collisions. > > > The master can be standard RS-422, but the slaves needs to be 4-wire > > > RS-485 i.e. the slave Tx is in tri-state until the slave is addressed. > > > > > > On a PC side, do NOT use standard RS-232 PC ports followed by an > > > RS-232 to RS-422/485 external converter, there is a great risks for > > > timing problems. Use proper RS-422/485 PCI cards (or external Ethernet > > > to RS-422/485 converter for laptops). > > PCI cards? What's wrong with USB cables? FTDI makes chips that provide serial ports from USB interfaces. I would use an RS-422 adapter as that provides separate transmit and receive interfaces. The PC does not need to tristate the RS-422 output, so it doesn't matter if there are risks of "timing problems". > > > > The chip FTDI makes is a small, very fast processor, that emulates serial ports in software. It is the same processor for all interfaces, including SPI and JTAG. As others have said, their devices just work, and there are no timing problems. I'll probably provide for the ability to use either split RS-422 buses or a single RS-485 type bus. The driver/receiver chips are the same. It's just how they are connected. > > > > Easy enough to try both. > > > > -- > > > > Rick C. > > > > ---- Get 1,000 miles of free Supercharging > > ---- Tesla referral code - https://ts.la/richard11209 > I haven't quite followed the entire thread, not sure of the bandwidth requirements or the need for full duplex communication. If noise immunity is of concern, you may want to consider 4-20ma current loops. Some years ago, I designed a RS-232 to 4-20ma converter. The control computer connected to ~ 50 micros in the plant (10 micros/loop). The communication topology was basically a token ring. I also wrote the communication code on the micros. Don't know if you want to go down this road - probably looking for something out of the box. > Of course there are lots of other system requirements that need to be taken into account, e.g. minimum event latency, etc. They would need to be looked at when considering the network topology.Thanks for your reply. Noise immunity is why I'm using RS-422, but I could just as easily use RS-232 for the noise aspects. The problem is RS-232 is hard to use in a multiple transmitter arrangement. It's also not specified for higher bit rates, even if some chips support it. I started looking at RS-422 mostly because I'm familiar with it and an RS-422 chip is already on the UUT. I like using the same components on the test fixture as the UUT, it makes my life easier in many regards. A current loop would work fine for this app, except it would make the cabling a bit more complex. We need to be able to take cards out of the system at will. For a current loop, that would mean cabling in a way that always completes the loop. It also means an adapter board in addition to the USB cable to the PC, plus extra logic on the slave boards, even if it is very simple logic. I believe the slaves would be an opto-isolator, plus something to open the loop when transmitting, so an analog switch or FET? In other words, it's design work rather than just plopping an RS-422 chip on the board. Is there an equivalent 20 mA current loop chip I could use? The RS-422 solution lets me use a bog standard chip and all cabling is just in parallel, so very easy to implement without thinking about keeping the loop complete. I'm not saying that's tricky, but I guarantee that with this being torn down and reinstalled every day to remove the UUTs, it would result in a screw up by every member of the test team at least once. It's also one run, not multiple loops to prevent the need for a higher voltage with the greater number of nodes. -- Rick C. ---+ Get 1,000 miles of free Supercharging ---+ Tesla referral code - https://ts.la/richard11209
Reply by ●November 5, 20222022-11-05
On Friday, November 4, 2022 at 5:17:26 PM UTC-7, Ricky wrote:> The RS-422 solution lets me use a bog standard chip and all cabling is just in parallel, so very easy to implement...Each pair is a short drop from the backbone; how do you wire that 'in parallel' when it requires two terminated endpoints on a serial string? U-turn cables, and plug in a dummy short link when a slave is removed from the ensemble?
