Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #31284 > unrolled thread
| Started by | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| First post | 2022-11-01 22:28 -0700 |
| Last post | 2022-11-05 00:13 +0000 |
| Articles | 14 on this page of 94 — 10 participants |
Back to article view | Back to comp.arch.embedded
Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-01 22:28 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-02 10:28 +0100
Re: Shared Communications Bus - RS-422 or RS-485 pozz <pozzugno@gmail.com> - 2022-11-02 11:54 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-02 14:27 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-02 12:20 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-02 21:49 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-02 16:27 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-03 12:42 +0100
Re: Shared Communications Bus - RS-422 or RS-485 pozz <pozzugno@gmail.com> - 2022-11-03 14:00 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-03 16:26 +0100
Re: Shared Communications Bus - RS-422 or RS-485 pozz <pozzugno@gmail.com> - 2022-11-04 08:45 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-04 10:49 +0100
Re: Shared Communications Bus - RS-422 or RS-485 pozz <pozzugno@gmail.com> - 2022-11-04 15:37 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-04 17:36 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-04 10:11 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-05 11:58 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-05 09:55 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 11:00 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-07 15:46 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 08:05 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-07 19:02 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 17:15 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-08 06:54 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-08 05:50 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Clifford Heath <no_spam@please.net> - 2022-11-09 10:45 +1100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-08 16:46 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Clifford Heath <no_spam@please.net> - 2022-11-09 22:32 +1100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-09 04:53 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-09 23:45 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-09 21:42 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-04 08:40 -0700
Re: Shared Communications Bus - RS-422 or RS-485 antispam@math.uni.wroc.pl - 2022-11-04 22:53 +0000
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-04 18:07 -0700
Re: Shared Communications Bus - RS-422 or RS-485 antispam@math.uni.wroc.pl - 2022-11-05 03:46 +0000
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-05 02:09 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 10:40 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-05 12:47 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-05 10:23 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-05 19:57 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-05 13:42 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-06 11:55 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-06 05:56 -0800
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-06 21:53 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 01:58 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 11:26 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 02:39 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 12:07 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 08:25 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 17:57 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 09:50 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 21:30 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 14:27 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-08 00:07 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 16:50 -0800
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-08 09:02 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-08 06:58 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-06 18:34 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-06 15:37 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-06 19:18 -0500
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 02:07 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 02:03 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 11:55 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 08:18 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 18:20 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 10:26 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Stef <me@this.is.invalid> - 2022-11-07 22:04 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 14:54 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-07 15:14 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 16:57 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-07 07:51 -0800
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 08:29 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-03 10:36 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 12:32 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-03 13:08 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 13:40 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-03 16:50 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 21:10 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-04 11:13 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-04 08:52 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-04 20:03 -0700
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-05 17:25 +0100
Re: Shared Communications Bus - RS-422 or RS-485 David Brown <david.brown@hesbynett.no> - 2022-11-04 11:01 +0100
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-02 15:00 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-02 16:31 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-02 17:36 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-02 21:58 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-03 09:57 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 12:02 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Paul Rubin <no.email@nospam.invalid> - 2022-11-03 12:53 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 13:33 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Dave Nadler <drn@nadler.com> - 2022-11-03 15:37 -0400
Re: Shared Communications Bus - RS-422 or RS-485 Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-03 13:32 -0700
Re: Shared Communications Bus - RS-422 or RS-485 Richard Damon <Richard@Damon-Family.org> - 2022-11-04 22:47 -0400
Re: Shared Communications Bus - RS-422 or RS-485 chris <chris-nospam@tridac.net> - 2022-11-05 00:13 +0000
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-05 17:25 +0100 |
| Message-ID | <tk62pr$2hcgu$1@dont-email.me> |
| In reply to | #31342 |
On 05/11/2022 04:03, Paul Rubin wrote: > Rick C <gnuarm.deletethisbit@gmail.com> writes: >> Cablestogo has 6 inch cables for $2.99 each. I'd like to keep them >> a bit shorter, but that's probably not an issue. > > I thought there was a minimum length for ethernet cables because they > have to have certain RF characteristics at 100mhz or 1ghz frequencies. > I didn't realize they even came as short as 6 inches. Either way > though, it shouldn't be an issue for your purposes. There may be issues with minimum total length for Ethernet, but I have not heard of figures myself - usually maximum lengths are the issue. It's common to have racks with the wiring coming into patch panels, and then you need a short Ethernet cable to the switch. These cables should ideally be short - both from a cable management viewpoint, and because you always want to have as few impedance jumps as possible in the total connection between switch and end device and you want the bumps to be as close to the ends as possible. 30 cm patch cables are common, but I've also seen 10 cm cables. For the very short ones, they need to be made of very flexible material - standard cheap Ethernet cables aren't really flexible enough to be convenient to plug in and out unless you have a little more length.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-04 11:01 +0100 |
| Message-ID | <tk2nsv$1o27f$1@dont-email.me> |
| In reply to | #31323 |
On 03/11/2022 21:08, Paul Rubin wrote: > 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. > On some testbenches that we have made that are used for cards with RJ45 sockets on the card, we made posts with an RJ45 on the end, with a small spring at the base. The RJ45 connector had its tag removed, of course. The DUT slid in on rails. For high-usage testbenches, you don't want any flexible cables attached to the DUT - you want bed of nails and spring-loaded connectors as much as possible.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2022-11-02 15:00 -0700 |
| Message-ID | <871qql2ezq.fsf@nightsong.com> |
| In reply to | #31284 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-02 16:31 -0700 |
| Message-ID | <85415d13-1a8c-4f07-8bbf-46564346cf36n@googlegroups.com> |
| In reply to | #31302 |
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
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2022-11-02 17:36 -0700 |
| Message-ID | <87k04c27rt.fsf@nightsong.com> |
| In reply to | #31307 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-02 21:58 -0700 |
| Message-ID | <cbbd68d3-c4bf-4ae4-b063-a14ba488a22dn@googlegroups.com> |
| In reply to | #31308 |
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
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2022-11-03 09:57 -0700 |
| Message-ID | <87pme4c6wv.fsf@nightsong.com> |
| In reply to | #31309 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-03 12:02 -0700 |
| Message-ID | <9326ffa5-8d5b-42d7-ba8d-0dea3e5d1dc2n@googlegroups.com> |
| In reply to | #31317 |
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
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2022-11-03 12:53 -0700 |
| Message-ID | <87fsez4xxk.fsf@nightsong.com> |
| In reply to | #31319 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-03 13:33 -0700 |
| Message-ID | <6dfec8f3-0100-4fe3-8d67-3eeb456f3e48n@googlegroups.com> |
| In reply to | #31322 |
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
[toc] | [prev] | [next] | [standalone]
| From | Dave Nadler <drn@nadler.com> |
|---|---|
| Date | 2022-11-03 15:37 -0400 |
| Message-ID | <tk15a0$usu$1@gioia.aioe.org> |
| In reply to | #31284 |
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
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-03 13:32 -0700 |
| Message-ID | <34f51ec8-9265-4cfa-93ff-c65eb0050fbbn@googlegroups.com> |
| In reply to | #31321 |
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
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-04 22:47 -0400 |
| Message-ID | <L8k9L.20582$1449.2451@fx14.iad> |
| In reply to | #31324 |
On 11/3/22 4:32 PM, Rick C wrote: > 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. > RS-485 will require you to make a firm decision on protocol timing. Either you require that ALL units can get off the line fast after a message, so you don't need to add much wait time, or your allow any unit to be slow to get off, so everyone has to wait a while before talking. Perhaps if you have a single master that is fast, the replying machines can be slow, as long as the master knows that. Multi-drop RS-422, with one pair going out from the master controller to everyone, and a shared pair to answer on largely gets around this problem, as the replying units just need to be fast enough getting off the line so they are off before the controller sends enough of a message that someone else might decide to start to reply. This sounds like what you are talking about, and does work. You can even do "Multi-Master" with this topology, if you give the masters two drive chips, one to drive the master bus when they are the master, and one to drive the response bus when they are selected as a slave, and some protocol to pass mastering around and some recovery method to handle the case where the master role gets lost. One other thing to remember is that 422/485 really is designed to be a single linear bus, without significant branches, with end of bus termination. You can "cheat" on this if your speed is on the slow side.
[toc] | [prev] | [next] | [standalone]
| From | chris <chris-nospam@tridac.net> |
|---|---|
| Date | 2022-11-05 00:13 +0000 |
| Message-ID | <tk49r0$156q$1@gioia.aioe.org> |
| In reply to | #31284 |
On 11/2/22 05: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-485 would allow all this to be over a single pair of wires. But the one big issue I see people complain about is getting PC software to not clobber the slaves, or I should say, to get the master to wait long enough that it's not clobbering it's own start bit by overwriting the stop bit of the slave. I suppose someone, somewhere has dealt with this on the PC and has a solution that doesn't impact bus speed. I run the single test fixture version of this at about 100 kbps. I'm going to want as much speed as I can get for 80 FPGAs controlling 160 UUTs. Maybe I should give that some analysis, because this might not be true. > > The tests are of two types, most of them are setting up a state and reading a signal. This can go pretty fast and doesn't take too many commands. Then there are the audio tests where the FPGA sends digital data to the UUT, which does it's thing and returns digital data which is crunched by the FPGA. This takes some small number of seconds and presently the protocol is to poll the status until it is done. That's a lot of messages, but it's not necessarily a slow point. The same test can be started on every UUT in parallel, so the waiting is in parallel. So maybe the serial port won't need to be any faster. > > Still, I want to use RS-422 or RS-485 to deal with ground noise since this will be spread over multiple boards that don't have terribly solid grounds, just the power cable really. > > I'm thinking out loud here as much as anything. I intended to simply ask if anyone had experience with RS-485 that would be helpful. Running two wires rather than eight would be a help. I'll probably use a 10 pin connector just to be on the safe side, allowing the transceivers to be used either way. > I worked on highway traffic sign project some years back that used multidrop RS423. The sign driven from a roadside controller, with a supervisory controller between that and led column controllers. Supervisory controller always master, with col controllers slaves. Master always initiated comms, with col controllers talking when addressed. A simple software state machine and line turnaround for the selected column to talk. Used diff line transceivers at the tx and rx ends, which could be tristated at the output. Interesting project and with a 15 yr design life, probably hundreds still working now. RS423 multidrop works well, though don't remember what the max supported speeds are. Much cheaper than network, but you can used standard cat5 etc network cables and pcb sockets to tie it all together... Chris
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.arch.embedded
csiph-web