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 | 20 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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-07 02:03 -0800 |
| Message-ID | <f81aabf9-87f3-440c-b063-40461d8b0359n@googlegroups.com> |
| In reply to | #31356 |
On Sunday, November 6, 2022 at 6:34:59 PM UTC-5, Richard Damon wrote: > On 11/6/22 8:56 AM, Rick C wrote: > > There's no point to inter-message delays. If there is an error that causes a loss of framing, the devices will see that and ignore the message. As I've said, the real issue is that the message will not be responded to, and the software will fail. At that point the user will exit the software on the PC and start over. That gives a nice long delay for resyncing. > If the only way to handle a missed message is to abort the whole > software system, that seems to be a pretty bad system. You would certainly think that if your error rate was more than once a hundred years. I expect to be long dead before an RS-422 bus only 10 feet long burps a bit error. > Note, if the master sends out a message, and waits for a response, with > a retry if the message is not replied to, that naturally puts a pause in > the communication bus for inter-message synchronization. The pause is already there by virtue of the protocol. Commands and replies are on different busses. > Based on your description, I can't imagine the master starting a message > for another slave until after the first one answers, or you will > interfere with the arbitration control of the reply bus. Exactly! Now you are starting to catch on. > In a dedicated link, after the link is established, it might be possible > that one side just starts streaming data continously to the other side, Except that there is no data to stream. Maybe you haven't been around for the full conversation. The protocol is command/reply for reading and writing registers and selecting which unit the registers are being accessed. The "stream" is an 8 bit value. > but most protocals will have some sort of at least occational > handshaking back, so a loss of sync can stop the flow to re-establish > the syncronization. And such handshaking is needed if you have need to > handle noise in packets. ??? Every command has a reply. How is that not a handshake??? -- Rick C. -+++ Get 1,000 miles of free Supercharging -+++ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Stef <me@this.is.invalid> |
|---|---|
| Date | 2022-11-07 11:55 +0100 |
| Message-ID | <nnd$2d9aedf3$3ff05d81@29b8ea6f16782d6d> |
| In reply to | #31362 |
On 2022-11-07 Rick C wrote in comp.arch.embedded: > On Sunday, November 6, 2022 at 6:34:59 PM UTC-5, Richard Damon wrote: >> On 11/6/22 8:56 AM, Rick C wrote: >> > There's no point to inter-message delays. If there is an error that causes a loss of framing, the devices will see that and ignore the message. As I've said, the real issue is that the message will not be responded to, and the software will fail. At that point the user will exit the software on the PC and start over. That gives a nice long delay for resyncing. >> If the only way to handle a missed message is to abort the whole >> software system, that seems to be a pretty bad system. > > You would certainly think that if your error rate was more than once a hundred years. I expect to be long dead before an RS-422 bus only 10 feet long burps a bit error. I would not dare to implement a serial protocol without any form of error checking, on any length of cable. You mention ESD somewhere. This can be a serious disturbance that can easily corrupt a few bits. Reminds me of a product where we got windows blue screens during ESD testing on a device connected via an FTDI USB to serial adapter. Cable length less than 6 feet. > >> Note, if the master sends out a message, and waits for a response, with >> a retry if the message is not replied to, that naturally puts a pause in >> the communication bus for inter-message synchronization. > > The pause is already there by virtue of the protocol. Commands and replies are on different busses. > > >> Based on your description, I can't imagine the master starting a message >> for another slave until after the first one answers, or you will >> interfere with the arbitration control of the reply bus. > > Exactly! Now you are starting to catch on. So you do wait for a reply, and a reply is only expected on a valid message? What if there is no reply, do you retry? If so, you already have implemented some basic error checking. For more robustness you could (I would) add some kind of CRC. In the following, I think Richard is just considering a situation where this problem might occur. Not your situation because he has already 'caught on', as you mention. But I should probably not speak for Richard ... >> In a dedicated link, after the link is established, it might be possible >> that one side just starts streaming data continously to the other side, > > Except that there is no data to stream. Maybe you haven't been around for the full conversation. The protocol is command/reply for reading and writing registers and selecting which unit the registers are being accessed. The "stream" is an 8 bit value. > > >> but most protocals will have some sort of at least occational >> handshaking back, so a loss of sync can stop the flow to re-establish >> the syncronization. And such handshaking is needed if you have need to >> handle noise in packets. > > ??? Every command has a reply. How is that not a handshake??? > -- Stef I don't care for the Sugar Smacks commercial. I don't like the idea of a frog jumping on my Breakfast. -- Lowell, Chicago Reader 10/15/82
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-07 08:18 -0800 |
| Message-ID | <97420ff2-6264-47db-9d62-232f5db75a9dn@googlegroups.com> |
| In reply to | #31366 |
On Monday, November 7, 2022 at 6:55:27 AM UTC-4, Stef wrote: > On 2022-11-07 Rick C wrote in comp.arch.embedded: > > On Sunday, November 6, 2022 at 6:34:59 PM UTC-5, Richard Damon wrote: > >> On 11/6/22 8:56 AM, Rick C wrote: > >> > There's no point to inter-message delays. If there is an error that causes a loss of framing, the devices will see that and ignore the message. As I've said, the real issue is that the message will not be responded to, and the software will fail. At that point the user will exit the software on the PC and start over. That gives a nice long delay for resyncing. > >> If the only way to handle a missed message is to abort the whole > >> software system, that seems to be a pretty bad system. > > > > You would certainly think that if your error rate was more than once a hundred years. I expect to be long dead before an RS-422 bus only 10 feet long burps a bit error. > I would not dare to implement a serial protocol without any form of > error checking, on any length of cable. > > You mention ESD somewhere. This can be a serious disturbance that can > easily corrupt a few bits. Yes, I mentioned ESD somewhere. This is testing newly constructed circuit boards, so is used in an ESD controlled environment. > Reminds me of a product where we got windows blue screens during ESD > testing on a device connected via an FTDI USB to serial adapter. Cable > length less than 6 feet. I assume you mean some other device was being ESD tested? This is not being used in an ESD testing lab. Was the FTDI serial cable RS-232 by any chance? Being single ended, that is much less tolerant of noise. > >> Note, if the master sends out a message, and waits for a response, with > >> a retry if the message is not replied to, that naturally puts a pause in > >> the communication bus for inter-message synchronization. > > > > The pause is already there by virtue of the protocol. Commands and replies are on different busses. > > > > > >> Based on your description, I can't imagine the master starting a message > >> for another slave until after the first one answers, or you will > >> interfere with the arbitration control of the reply bus. > > > > Exactly! Now you are starting to catch on. > So you do wait for a reply, and a reply is only expected on a valid > message? What if there is no reply, do you retry? If so, you already have > implemented some basic error checking. For more robustness you could (I > would) add some kind of CRC. There should not be any messages other than "valid" messages. I don't recall specifically what the slave does on messages with bit errors, but I'm pretty sure it simply doesn't know they have bit errors. The message has no checksum or other bit error control. The format has one character to indicate the "command" type. If that character is corrupted, the command is not used, unless it is changed to another valid character (3 of 256 chance). Again, there's no reason to "detect" errors since I've implemented no error protocol. That is many times more complex than simply ignoring the errors, which works because errors don't happen often enough to have an impact on testing. On the Apollo moon missions, they took no precautions against damage from micrometeoroids, because the effort required was not commensurate with the likelihood of the event. -- Rick C. ++-- Get 1,000 miles of free Supercharging ++-- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Stef <me@this.is.invalid> |
|---|---|
| Date | 2022-11-07 18:20 +0100 |
| Message-ID | <nnd$5ce85a17$52a5bfc5@d54640d88a1ab2e6> |
| In reply to | #31371 |
On 2022-11-07 Rick C wrote in comp.arch.embedded:
> On Monday, November 7, 2022 at 6:55:27 AM UTC-4, Stef wrote:
>> On 2022-11-07 Rick C wrote in comp.arch.embedded:
>> > On Sunday, November 6, 2022 at 6:34:59 PM UTC-5, Richard Damon wrote:
>> >> On 11/6/22 8:56 AM, Rick C wrote:
>> >> > There's no point to inter-message delays. If there is an error that causes a loss of framing, the devices will see that and ignore the message. As I've said, the real issue is that the message will not be responded to, and the software will fail. At that point the user will exit the software on the PC and start over. That gives a nice long delay for resyncing.
>> >> If the only way to handle a missed message is to abort the whole
>> >> software system, that seems to be a pretty bad system.
>> >
>> > You would certainly think that if your error rate was more than once a hundred years. I expect to be long dead before an RS-422 bus only 10 feet long burps a bit error.
>> I would not dare to implement a serial protocol without any form of
>> error checking, on any length of cable.
>>
>> You mention ESD somewhere. This can be a serious disturbance that can
>> easily corrupt a few bits.
>
> Yes, I mentioned ESD somewhere. This is testing newly constructed circuit boards, so is used in an ESD controlled environment.
>
You wrote:
"I could probably get away with TTL level signals, but I'd like to have
the ESD protection these RS-422 chips give. That additional noise
immunity means there is an extremely small chance of bit errors. If we
have problems, the error handling can be added."
This led me to believe you were expecting actual ESD discharges that
could disturb your messages.
ESD protection is just that: protection against device damage
I do not believe ESD protection does anything to improve noise immunity.
It just increases the ESD level at which the device will be damaged.
And if you have an ESD controlled environment, that is not actually
needed.
>> Reminds me of a product where we got windows blue screens during ESD
>> testing on a device connected via an FTDI USB to serial adapter. Cable
>> length less than 6 feet.
>
> I assume you mean some other device was being ESD tested? This is not being used in an ESD testing lab. Was the FTDI serial cable RS-232 by any chance? Being single ended, that is much less tolerant of noise.
No a device with an FTDI chip on it was tested. USB cable was <= 6 feet
and serial ports were only a few centimeters of TTL level PCB traces.
This was reproducable with an evaluation kit with only USB connected.
>
>> >> Note, if the master sends out a message, and waits for a response, with
>> >> a retry if the message is not replied to, that naturally puts a pause in
>> >> the communication bus for inter-message synchronization.
>> >
>> > The pause is already there by virtue of the protocol. Commands and replies are on different busses.
>> >
>> >
>> >> Based on your description, I can't imagine the master starting a message
>> >> for another slave until after the first one answers, or you will
>> >> interfere with the arbitration control of the reply bus.
>> >
>> > Exactly! Now you are starting to catch on.
>> So you do wait for a reply, and a reply is only expected on a valid
>> message? What if there is no reply, do you retry? If so, you already have
>> implemented some basic error checking. For more robustness you could (I
>> would) add some kind of CRC.
>
> There should not be any messages other than "valid" messages. I don't recall specifically what the slave does on messages with bit errors, but I'm pretty sure it simply doesn't know they have bit errors. The message has no checksum or other bit error control. The format has one character to indicate the "command" type. If that character is corrupted, the command is not used, unless it is changed to another valid character (3 of 256 chance).
Okay, the slaves are already implemented? Missed that.
So there is some very basic error detection: the command must be valid.
And if it is not and the slave does not reply, what does the master do?
> Again, there's no reason to "detect" errors since I've implemented no error protocol. That is many times more complex than simply ignoring the errors, which works because errors don't happen often enough to have an impact on testing.
A test rig that ignores errors. I don't know the requirements of this
test and how bad it would be to have an invalid pass/fail result.
> On the Apollo moon missions, they took no precautions against damage from micrometeoroids, because the effort required was not commensurate with the likelihood of the event.
I am not sure what they could have done, but adding effective shields
would probably have prohibitive weight consequences, if at all possible.
But if you can believe the movie Apollo 13, thre is a real danger from
micrometeorites.
--
Stef
<KnaraKat> Bite me.
* TheOne gets some salt, then proceeds to nibble on KnaraKat a little
bit....
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-07 10:26 -0800 |
| Message-ID | <0ba7bfa3-595a-4920-a8e9-54d10e973071n@googlegroups.com> |
| In reply to | #31374 |
On Monday, November 7, 2022 at 1:20:33 PM UTC-4, Stef wrote: > On 2022-11-07 Rick C wrote in comp.arch.embedded: > > On Monday, November 7, 2022 at 6:55:27 AM UTC-4, Stef wrote: > >> On 2022-11-07 Rick C wrote in comp.arch.embedded: > >> > On Sunday, November 6, 2022 at 6:34:59 PM UTC-5, Richard Damon wrote: > >> >> On 11/6/22 8:56 AM, Rick C wrote: > >> >> > There's no point to inter-message delays. If there is an error that causes a loss of framing, the devices will see that and ignore the message. As I've said, the real issue is that the message will not be responded to, and the software will fail. At that point the user will exit the software on the PC and start over. That gives a nice long delay for resyncing. > >> >> If the only way to handle a missed message is to abort the whole > >> >> software system, that seems to be a pretty bad system. > >> > > >> > You would certainly think that if your error rate was more than once a hundred years. I expect to be long dead before an RS-422 bus only 10 feet long burps a bit error. > >> I would not dare to implement a serial protocol without any form of > >> error checking, on any length of cable. > >> > >> You mention ESD somewhere. This can be a serious disturbance that can > >> easily corrupt a few bits. > > > > Yes, I mentioned ESD somewhere. This is testing newly constructed circuit boards, so is used in an ESD controlled environment. > > > You wrote: > "I could probably get away with TTL level signals, but I'd like to have > the ESD protection these RS-422 chips give. That additional noise > immunity means there is an extremely small chance of bit errors. If we > have problems, the error handling can be added." > This led me to believe you were expecting actual ESD discharges that > could disturb your messages. > > ESD protection is just that: protection against device damage > > I do not believe ESD protection does anything to improve noise immunity. > It just increases the ESD level at which the device will be damaged. Yes, you are right. My language there is poor. I should have said I prefer the noise immunity the RS-422 devices have compared to TTL devices *in addition to* the ESD immunity. > And if you have an ESD controlled environment, that is not actually > needed. In theory, but I can't control how these will be used in the future. ESD immunity is something I want designed into any application that is connected by a cable. > >> Reminds me of a product where we got windows blue screens during ESD > >> testing on a device connected via an FTDI USB to serial adapter. Cable > >> length less than 6 feet. > > > > I assume you mean some other device was being ESD tested? This is not being used in an ESD testing lab. Was the FTDI serial cable RS-232 by any chance? Being single ended, that is much less tolerant of noise. > No a device with an FTDI chip on it was tested. USB cable was <= 6 feet > and serial ports were only a few centimeters of TTL level PCB traces. > This was reproducable with an evaluation kit with only USB connected. So you were shooting high voltages into a device and were surprised the PC it was connected to crashed? I'm not following this at all. I'm pretty sure the FTDI cable is not rated to provide isolation. That has nothing to do with ESD protection. As you say, ESD protection is about damage, not operation. > >> >> Note, if the master sends out a message, and waits for a response, with > >> >> a retry if the message is not replied to, that naturally puts a pause in > >> >> the communication bus for inter-message synchronization. > >> > > >> > The pause is already there by virtue of the protocol. Commands and replies are on different busses. > >> > > >> > > >> >> Based on your description, I can't imagine the master starting a message > >> >> for another slave until after the first one answers, or you will > >> >> interfere with the arbitration control of the reply bus. > >> > > >> > Exactly! Now you are starting to catch on. > >> So you do wait for a reply, and a reply is only expected on a valid > >> message? What if there is no reply, do you retry? If so, you already have > >> implemented some basic error checking. For more robustness you could (I > >> would) add some kind of CRC. > > > > There should not be any messages other than "valid" messages. I don't recall specifically what the slave does on messages with bit errors, but I'm pretty sure it simply doesn't know they have bit errors. The message has no checksum or other bit error control. The format has one character to indicate the "command" type. If that character is corrupted, the command is not used, unless it is changed to another valid character (3 of 256 chance). > Okay, the slaves are already implemented? Missed that. A test fixture is in use, with software on the PC. There's no reason to change the protocol in the new test fixture and software unless there is a need, a new requirement. > So there is some very basic error detection: the command must be valid. > And if it is not and the slave does not reply, what does the master do? The command being valid is based on as single character. The command is something like, "01 23 X<cr><lf>". I suppose the CR LF might also be required, but I don't recall. It might require one and ignore the other. The whole CR LF thing is such a PITA. The only character that is required for sure, is the "X", which at the moment can be one of three from the possible characters (don't recall if they are 8 bit or 7). I also don't recall if parity checking is used. I do know that I had a flaw in the initial setup that gave intermittent errors. I had the hardest time finding the problem because of using bias in where to look. I tried adding re-transmission, which helped, but it borked up the code pretty well. I guess my software skills are not so good. In the end, it was an Ariane problem where the UART in the FPGA was existing code that was reused. Thinking it was a previously validated module, it was not suspected... at all. Eventually I realized it did not include the input FF synchronization to absolve race conditions. That was left for the system designer to add, since there may be more than one device on the same input. Since that was solved, we've tested thousands of UUTs with no interface bit errors. So I have no worries about this. > > Again, there's no reason to "detect" errors since I've implemented no error protocol. That is many times more complex than simply ignoring the errors, which works because errors don't happen often enough to have an impact on testing. > A test rig that ignores errors. I don't know the requirements of this > test and how bad it would be to have an invalid pass/fail result. Since the test will be run, over night, every few seconds, with all UUT errors logged, the chances of the same bit error happening the same way, causing the same miss of a UUT failure some thousands of time (about 7,000), is on the order as a proton decaying. Well, maybe a bit more likely. > > On the Apollo moon missions, they took no precautions against damage from micrometeoroids, because the effort required was not commensurate with the likelihood of the event. > I am not sure what they could have done, but adding effective shields > would probably have prohibitive weight consequences, if at all possible. > But if you can believe the movie Apollo 13, thre is a real danger from > micrometeorites. Real, even if very small danger. That's the point. In this case, the impact is small, the likelihood is small, and the work to mitigate the problem is far more effort than justifiable, no matter how emotional people may get about "Errors! OMG, there may be ERRORS!" Maybe I need a heavy duty cabinet to protect against the very real possibility of meteors? https://abc7chicago.com/meteor-california-destroys-home-shower/12425011/ -- Rick C. ++++ Get 1,000 miles of free Supercharging ++++ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Stef <me@this.is.invalid> |
|---|---|
| Date | 2022-11-07 22:04 +0100 |
| Message-ID | <nnd$5ca4aa81$093b4535@bcd51477899e35fd> |
| In reply to | #31376 |
On 2022-11-07 Rick C wrote in comp.arch.embedded: > On Monday, November 7, 2022 at 1:20:33 PM UTC-4, Stef wrote: >> On 2022-11-07 Rick C wrote in comp.arch.embedded: >> > On Monday, November 7, 2022 at 6:55:27 AM UTC-4, Stef wrote: >> >> On 2022-11-07 Rick C wrote in comp.arch.embedded: >> >> > On Sunday, November 6, 2022 at 6:34:59 PM UTC-5, Richard Damon wrote: >> >> >> On 11/6/22 8:56 AM, Rick C wrote: >> >> >> > There's no point to inter-message delays. If there is an error that causes a loss of framing, the devices will see that and ignore the message. As I've said, the real issue is that the message will not be responded to, and the software will fail. At that point the user will exit the software on the PC and start over. That gives a nice long delay for resyncing. >> >> >> If the only way to handle a missed message is to abort the whole >> >> >> software system, that seems to be a pretty bad system. >> >> > >> >> > You would certainly think that if your error rate was more than once a hundred years. I expect to be long dead before an RS-422 bus only 10 feet long burps a bit error. >> >> I would not dare to implement a serial protocol without any form of >> >> error checking, on any length of cable. >> >> >> >> You mention ESD somewhere. This can be a serious disturbance that can >> >> easily corrupt a few bits. >> > >> > Yes, I mentioned ESD somewhere. This is testing newly constructed circuit boards, so is used in an ESD controlled environment. >> > >> You wrote: >> "I could probably get away with TTL level signals, but I'd like to have >> the ESD protection these RS-422 chips give. That additional noise >> immunity means there is an extremely small chance of bit errors. If we >> have problems, the error handling can be added." >> This led me to believe you were expecting actual ESD discharges that >> could disturb your messages. >> >> ESD protection is just that: protection against device damage >> >> I do not believe ESD protection does anything to improve noise immunity. >> It just increases the ESD level at which the device will be damaged. > > Yes, you are right. My language there is poor. I should have said I prefer the noise immunity the RS-422 devices have compared to TTL devices *in addition to* the ESD immunity. > > >> And if you have an ESD controlled environment, that is not actually >> needed. > > In theory, but I can't control how these will be used in the future. ESD immunity is something I want designed into any application that is connected by a cable. > Yes, alway protect accessible parts. > >> >> Reminds me of a product where we got windows blue screens during ESD >> >> testing on a device connected via an FTDI USB to serial adapter. Cable >> >> length less than 6 feet. >> > >> > I assume you mean some other device was being ESD tested? This is not being used in an ESD testing lab. Was the FTDI serial cable RS-232 by any chance? Being single ended, that is much less tolerant of noise. >> No a device with an FTDI chip on it was tested. USB cable was <= 6 feet >> and serial ports were only a few centimeters of TTL level PCB traces. >> This was reproducable with an evaluation kit with only USB connected. > > So you were shooting high voltages into a device and were surprised the PC it was connected to crashed? I'm not following this at all. I'm pretty sure the FTDI cable is not rated to provide isolation. That has nothing to do with ESD protection. As you say, ESD protection is about damage, not operation. Ofcourse not into a device. But all over the enclosure, as is required to pass EMC testing. These discharges cause current spikes that can induce currents in parts of your circuits. Part of ESD testing also uses coupling planes, where you fire on a metal plate 'near' the device. That can also give a lot of noise. All these things may not cause device damage like direct ESD discharges, but they can disturb the device operation. Depending on the expected performance level, this may cause a fail. For medical devices you usually cannot get away with worse than "temporary loss of function and recovery without operator intervention". ESD protection is indeed about damage prevention. But passing an ESD test usually requires more than just preventing damage. How would you rate a phone that resets every time you pick it up when you have not properly discharged yourself from static electricity? It may just reboot and work fine after that, but it would still be a crappy phone. >> >> >> Note, if the master sends out a message, and waits for a response, with >> >> >> a retry if the message is not replied to, that naturally puts a pause in >> >> >> the communication bus for inter-message synchronization. >> >> > >> >> > The pause is already there by virtue of the protocol. Commands and replies are on different busses. >> >> > >> >> > >> >> >> Based on your description, I can't imagine the master starting a message >> >> >> for another slave until after the first one answers, or you will >> >> >> interfere with the arbitration control of the reply bus. >> >> > >> >> > Exactly! Now you are starting to catch on. >> >> So you do wait for a reply, and a reply is only expected on a valid >> >> message? What if there is no reply, do you retry? If so, you already have >> >> implemented some basic error checking. For more robustness you could (I >> >> would) add some kind of CRC. >> > >> > There should not be any messages other than "valid" messages. I don't recall specifically what the slave does on messages with bit errors, but I'm pretty sure it simply doesn't know they have bit errors. The message has no checksum or other bit error control. The format has one character to indicate the "command" type. If that character is corrupted, the command is not used, unless it is changed to another valid character (3 of 256 chance). >> Okay, the slaves are already implemented? Missed that. > > A test fixture is in use, with software on the PC. There's no reason to change the protocol in the new test fixture and software unless there is a need, a new requirement. Ah, existing stuff. >> So there is some very basic error detection: the command must be valid. >> And if it is not and the slave does not reply, what does the master do? > > The command being valid is based on as single character. The command is something like, "01 23 X<cr><lf>". I suppose the CR LF might also be required, but I don't recall. It might require one and ignore the other. The whole CR LF thing is such a PITA. The only character that is required for sure, is the "X", which at the moment can be one of three from the possible characters (don't recall if they are 8 bit or 7). I also don't recall if parity checking is used. Okay, more restrictions on valid messages, yet more error detection present already. ;-) > I do know that I had a flaw in the initial setup that gave intermittent errors. I had the hardest time finding the problem because of using bias in where to look. I tried adding re-transmission, which helped, but it borked up the code pretty well. I guess my software skills are not so good. In the end, it was an Ariane problem where the UART in the FPGA was existing code that was reused. Thinking it was a previously validated module, it was not suspected... at all. Eventually I realized it did not include the input FF synchronization to absolve race conditions. That was left for the system designer to add, since there may be more than one device on the same input. > > Since that was solved, we've tested thousands of UUTs with no interface bit errors. So I have no worries about this. > > >> > Again, there's no reason to "detect" errors since I've implemented no error protocol. That is many times more complex than simply ignoring the errors, which works because errors don't happen often enough to have an impact on testing. >> A test rig that ignores errors. I don't know the requirements of this >> test and how bad it would be to have an invalid pass/fail result. > > Since the test will be run, over night, every few seconds, with all UUT errors logged, the chances of the same bit error happening the same way, causing the same miss of a UUT failure some thousands of time (about 7,000), is on the order as a proton decaying. Well, maybe a bit more likely. > Another layer of error detection. ;-) > >> > On the Apollo moon missions, they took no precautions against damage from micrometeoroids, because the effort required was not commensurate with the likelihood of the event. >> I am not sure what they could have done, but adding effective shields >> would probably have prohibitive weight consequences, if at all possible. >> But if you can believe the movie Apollo 13, thre is a real danger from >> micrometeorites. > > Real, even if very small danger. That's the point. In this case, the impact is small, the likelihood is small, and the work to mitigate the problem is far more effort than justifiable, no matter how emotional people may get about "Errors! OMG, there may be ERRORS!" > > Maybe I need a heavy duty cabinet to protect against the very real possibility of meteors? > > https://abc7chicago.com/meteor-california-destroys-home-shower/12425011/ > -- Stef The only winner in the War of 1812 was Tchaikovsky. -- David Gerrold
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-07 14:54 -0800 |
| Message-ID | <fdc0a4b8-db36-498c-a5c6-a9fdc44f7dcan@googlegroups.com> |
| In reply to | #31378 |
On Monday, November 7, 2022 at 5:04:29 PM UTC-4, Stef wrote: > On 2022-11-07 Rick C wrote in comp.arch.embedded: > > On Monday, November 7, 2022 at 1:20:33 PM UTC-4, Stef wrote: > >> On 2022-11-07 Rick C wrote in comp.arch.embedded: > >> > On Monday, November 7, 2022 at 6:55:27 AM UTC-4, Stef wrote: > >> >> On 2022-11-07 Rick C wrote in comp.arch.embedded: > >> >> > On Sunday, November 6, 2022 at 6:34:59 PM UTC-5, Richard Damon wrote: > >> >> >> On 11/6/22 8:56 AM, Rick C wrote: > >> >> >> > There's no point to inter-message delays. If there is an error that causes a loss of framing, the devices will see that and ignore the message. As I've said, the real issue is that the message will not be responded to, and the software will fail. At that point the user will exit the software on the PC and start over. That gives a nice long delay for resyncing. > >> >> >> If the only way to handle a missed message is to abort the whole > >> >> >> software system, that seems to be a pretty bad system. > >> >> > > >> >> > You would certainly think that if your error rate was more than once a hundred years. I expect to be long dead before an RS-422 bus only 10 feet long burps a bit error. > >> >> I would not dare to implement a serial protocol without any form of > >> >> error checking, on any length of cable. > >> >> > >> >> You mention ESD somewhere. This can be a serious disturbance that can > >> >> easily corrupt a few bits. > >> > > >> > Yes, I mentioned ESD somewhere. This is testing newly constructed circuit boards, so is used in an ESD controlled environment. > >> > > >> You wrote: > >> "I could probably get away with TTL level signals, but I'd like to have > >> the ESD protection these RS-422 chips give. That additional noise > >> immunity means there is an extremely small chance of bit errors. If we > >> have problems, the error handling can be added." > >> This led me to believe you were expecting actual ESD discharges that > >> could disturb your messages. > >> > >> ESD protection is just that: protection against device damage > >> > >> I do not believe ESD protection does anything to improve noise immunity. > >> It just increases the ESD level at which the device will be damaged. > > > > Yes, you are right. My language there is poor. I should have said I prefer the noise immunity the RS-422 devices have compared to TTL devices *in addition to* the ESD immunity. > > > > > >> And if you have an ESD controlled environment, that is not actually > >> needed. > > > > In theory, but I can't control how these will be used in the future. ESD immunity is something I want designed into any application that is connected by a cable. > > > Yes, alway protect accessible parts. > > > >> >> Reminds me of a product where we got windows blue screens during ESD > >> >> testing on a device connected via an FTDI USB to serial adapter. Cable > >> >> length less than 6 feet. > >> > > >> > I assume you mean some other device was being ESD tested? This is not being used in an ESD testing lab. Was the FTDI serial cable RS-232 by any chance? Being single ended, that is much less tolerant of noise. > >> No a device with an FTDI chip on it was tested. USB cable was <= 6 feet > >> and serial ports were only a few centimeters of TTL level PCB traces. > >> This was reproducable with an evaluation kit with only USB connected. > > > > So you were shooting high voltages into a device and were surprised the PC it was connected to crashed? I'm not following this at all. I'm pretty sure the FTDI cable is not rated to provide isolation. That has nothing to do with ESD protection. As you say, ESD protection is about damage, not operation. > Ofcourse not into a device. But all over the enclosure, as is required > to pass EMC testing. These discharges cause current spikes that can > induce currents in parts of your circuits. Part of ESD testing also uses > coupling planes, where you fire on a metal plate 'near' the device. That > can also give a lot of noise. All these things may not cause device > damage like direct ESD discharges, but they can disturb the device > operation. Depending on the expected performance level, this may cause a > fail. For medical devices you usually cannot get away with worse than > "temporary loss of function and recovery without operator intervention". > > ESD protection is indeed about damage prevention. But passing an ESD > test usually requires more than just preventing damage. > > How would you rate a phone that resets every time you pick it up when > you have not properly discharged yourself from static electricity? It > may just reboot and work fine after that, but it would still be a crappy > phone. Lol! I probably would barely notice! Cell phones are among the most unreliable devices we use with any regularity. I recall a Dave Barry article that was talking about cell phones which he mocked by describing typical conversations as, "What? WHAT?" Now, it's more like, "Hello...? Hello...? <click>" > >> >> >> Note, if the master sends out a message, and waits for a response, with > >> >> >> a retry if the message is not replied to, that naturally puts a pause in > >> >> >> the communication bus for inter-message synchronization. > >> >> > > >> >> > The pause is already there by virtue of the protocol. Commands and replies are on different busses. > >> >> > > >> >> > > >> >> >> Based on your description, I can't imagine the master starting a message > >> >> >> for another slave until after the first one answers, or you will > >> >> >> interfere with the arbitration control of the reply bus. > >> >> > > >> >> > Exactly! Now you are starting to catch on. > >> >> So you do wait for a reply, and a reply is only expected on a valid > >> >> message? What if there is no reply, do you retry? If so, you already have > >> >> implemented some basic error checking. For more robustness you could (I > >> >> would) add some kind of CRC. > >> > > >> > There should not be any messages other than "valid" messages. I don't recall specifically what the slave does on messages with bit errors, but I'm pretty sure it simply doesn't know they have bit errors. The message has no checksum or other bit error control. The format has one character to indicate the "command" type. If that character is corrupted, the command is not used, unless it is changed to another valid character (3 of 256 chance). > >> Okay, the slaves are already implemented? Missed that. > > > > A test fixture is in use, with software on the PC. There's no reason to change the protocol in the new test fixture and software unless there is a need, a new requirement. > Ah, existing stuff. Yes, the very first sentence of the very first post was, "I have a test fixture that uses RS-232 to communicate with a PC." > >> So there is some very basic error detection: the command must be valid. > >> And if it is not and the slave does not reply, what does the master do? > > > > The command being valid is based on as single character. The command is something like, "01 23 X<cr><lf>". I suppose the CR LF might also be required, but I don't recall. It might require one and ignore the other. The whole CR LF thing is such a PITA. The only character that is required for sure, is the "X", which at the moment can be one of three from the possible characters (don't recall if they are 8 bit or 7). I also don't recall if parity checking is used. > Okay, more restrictions on valid messages, yet more error detection > present already. ;-) No real detection since there's no awareness of the error. It's like saying your transmission has "error detection" because it can stop working because a gear tooth broke off and jammed the whole transmission breaking more gears. > > I do know that I had a flaw in the initial setup that gave intermittent errors. I had the hardest time finding the problem because of using bias in where to look. I tried adding re-transmission, which helped, but it borked up the code pretty well. I guess my software skills are not so good. In the end, it was an Ariane problem where the UART in the FPGA was existing code that was reused. Thinking it was a previously validated module, it was not suspected... at all. Eventually I realized it did not include the input FF synchronization to absolve race conditions. That was left for the system designer to add, since there may be more than one device on the same input. > > > > Since that was solved, we've tested thousands of UUTs with no interface bit errors. So I have no worries about this. > > > > > >> > Again, there's no reason to "detect" errors since I've implemented no error protocol. That is many times more complex than simply ignoring the errors, which works because errors don't happen often enough to have an impact on testing. > >> A test rig that ignores errors. I don't know the requirements of this > >> test and how bad it would be to have an invalid pass/fail result. > > > > Since the test will be run, over night, every few seconds, with all UUT errors logged, the chances of the same bit error happening the same way, causing the same miss of a UUT failure some thousands of time (about 7,000), is on the order as a proton decaying. Well, maybe a bit more likely. > > > Another layer of error detection. ;-) Errors in the UUT. If there is an error in the comms link, we likely would not even know about it. This will be an interesting test for both the UUTs and the comms link. I'm not certain how many messages it currently takes to implement any given test, but it should be possible to run the tests in parallel minimizing wait times for the PC software. I would estimate the total test time for a chassis to be between 10 and 60 seconds, so between 1,200 and 7,200 tests in the 20 hour soak time. As I learn more about the FTDI device, I am more pessimistic about the throughput. I could shove the details of tests into the FPGAs, so the commands are more like, run test 1 on channel number 2. That would cut the number of tests significantly, but require much more work in updating the FPGA software. I think I'll start with a direct transfer of the existing protocol. -- 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-07 15:14 -0800 |
| Message-ID | <87cz9yl5lg.fsf@nightsong.com> |
| In reply to | #31380 |
Rick C <gnuarm.deletethisbit@gmail.com> writes: > I could shove the details of tests into the FPGAs, so the commands are > more like, run test 1 on channel number 2. That would cut the number > of tests significantly, but require much more work in updating the > FPGA software. Are we circling back to the idea putting a microprocessor on the test board? Ivan Sutherland famously called this a wheel of reincarnation: http://www.cap-lore.com/Hardware/Wheel.html
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-07 16:57 -0800 |
| Message-ID | <b3bccfa7-a872-4b73-96f7-acbb744fc993n@googlegroups.com> |
| In reply to | #31382 |
On Monday, November 7, 2022 at 7:14:56 PM UTC-4, Paul Rubin wrote: > Rick C <gnuarm.del...@gmail.com> writes: > > I could shove the details of tests into the FPGAs, so the commands are > > more like, run test 1 on channel number 2. That would cut the number > > of tests significantly, but require much more work in updating the > > FPGA software. That should have been, "cut back the number of commands". > Are we circling back to the idea putting a microprocessor on the test > board? Ivan Sutherland famously called this a wheel of reincarnation: > > http://www.cap-lore.com/Hardware/Wheel.html Zero need for a processor in the FPGA at this point. At least the need for a conventional processor. The commands are things like, assert pin X, read pin Y. A test of some basic functionality that could be debugged separately from other tests would be a few of these instructions. Very easy to do in an FPGA by using memory blocks and stepping through the commands. But I'm open to a processor. It would be one of my own design, however. -- Rick C. ---++ Get 1,000 miles of free Supercharging ---++ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-07 07:51 -0800 |
| Message-ID | <b5f2334f-2118-4360-b1d3-3860c04fa72cn@googlegroups.com> |
| In reply to | #31350 |
On Saturday, November 5, 2022 at 2:57:30 PM UTC-4, David Brown wrote: > > In more sophisticated tristate drivers, you would off (disconnect) the > local terminator whenever the driver is enabled. This is done in some > multi-lane systems as it can significantly reduce power and make slope > control and pulse shaping easier. (It's not something you'd be likely > to see on RS-485 buses.) I'm not sure what bus arrangement you are referring to. The RS-485 bus is intended to be linear. The terminators are at the ends, to prevent reflections. There's no point in removing either of them no matter which driver is enabled. All drivers see two loads. A terminal driver sees the bus and the terminator. A driver along the bus sees two buses which are driven in parallel. So everyone sees the same impedance, half the characteristic impedance of the bus. -- Rick C. +-+- Get 1,000 miles of free Supercharging +-+- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-03 08:29 -0700 |
| Message-ID | <d6523819-5f08-4dad-9032-aa3ada86f989n@googlegroups.com> |
| In reply to | #31314 |
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
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2022-11-03 10:36 -0700 |
| Message-ID | <87zgd83pph.fsf@nightsong.com> |
| In reply to | #31316 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-03 12:32 -0700 |
| Message-ID | <ebce990e-0ff7-4bb4-baa9-ede4df631fc4n@googlegroups.com> |
| In reply to | #31318 |
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
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2022-11-03 13:08 -0700 |
| Message-ID | <87bkpn4x8p.fsf@nightsong.com> |
| In reply to | #31320 |
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
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-03 13:40 -0700 |
| Message-ID | <cc65d39e-a1d3-4198-8485-64297d9b889an@googlegroups.com> |
| In reply to | #31323 |
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
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2022-11-03 16:50 -0700 |
| Message-ID | <8735az4mz4.fsf@nightsong.com> |
| In reply to | #31326 |
Rick C <gnuarm.deletethisbit@gmail.com> writes: > DIN? You mean those things that are used on Eurocards with some 96 > pins? No I meant the circular connectors like you see on old PC keyboards, similar to the aviation style one that I linked. > What would mate with it? What's actually wrong with RJ-45? 1) the plugs break and the cables get munged up, but as you can say you can replace them when they do. 2) the sockets also break, maybe not as often, but replacing them might be harder, depending If both of those are ok with you, then maybe it a good choice.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-03 21:10 -0700 |
| Message-ID | <69459438-670f-4f45-9e3b-767c368605a3n@googlegroups.com> |
| In reply to | #31327 |
On Thursday, November 3, 2022 at 7:50:13 PM UTC-4, Paul Rubin wrote: > Rick C <gnuarm.del...@gmail.com> writes: > > DIN? You mean those things that are used on Eurocards with some 96 > > pins? > No I meant the circular connectors like you see on old PC keyboards, > similar to the aviation style one that I linked. > > What would mate with it? What's actually wrong with RJ-45? > 1) the plugs break and the cables get munged up, but as you can say you > can replace them when they do. I suppose the plugs can break, but I've never seen a broken RJ-45, other than the catch breaking. That's nearly always a result of pulling on a cable through a tangle rather than freeing it gently. On the other hand, I have seen broken DIN mouse connectors. The way they protrude, they get bumped and one or the other is damaged. I think the metal on the chassis mounted connector is optional or something, that can make it more fragile. Anything can break, but I need to be concerned with significant problems. I think RJ-45 will be very adequate. > 2) the sockets also break, maybe not as often, but replacing them > might be harder, depending I've never seen an RJ-45 plug broken. They are used widely in the telecom industry as RS-232 connectors for consoles. > If both of those are ok with you, then maybe it a good choice. Yeah, I'm fine with a cable I can make to any length I want in 5 minutes, with most of that spent finding where I put the parts and tool. Oh, and costs less than $1. If there was an easier way to make a DIN connector, I'd be ok with that. Anything crimp or solder pin is going to be a PITA. Heck, I'd be ok with a ribbon cable actually, but it would be larger than an RJ-45 since the smallest I'm likely to find is 10 positions. That's a half inch, plus the extra width of the female part. It's easy to bend those pins and it's not easy to extract the things without the extraction levers which make it even larger. As long as I put it in the back of the card, that's not a big deal, but I'm thinking of putting the connectors on the front to make access easier when pulling a card out of the cage. If power is in the front, it's totally easy. Of course, using an actual back plane is even easier, but that's a lot more work to get all the specs to make that happen. I wish I had one of the card cages in front of me to look at and see how they are constructed. I have a similar card with a front panel. That is pretty straight forward with 8.5 inches clear space on the front panel. Not sure where to get these particular parts though. I wish the cards were a bit larger in each direction. I can get 8 UUTs on one 6U, size B card, but it will be tight with the other stuff (FPGA, buffers, power supplies). We've always had trouble ejecting the daughter cards as the two friction fit, 20 pin connectors are tough to get apart. It's easy to damage the connectors removing them. I have some ideas, but nothing that's rock solid. It will be important for the test fixture card to be well supported when removing the daughter cards. Having some extra room around the UUTs would help. The next standard size up from the size B (233 x 160 mm) is 367 x 220 mm. That's a large card! Turns out it's not so much money if made at JLCPCB. 20 of them for $352! That's pretty amazing! -- Rick C. +-- Get 1,000 miles of free Supercharging +-- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-11-04 11:13 +0100 |
| Message-ID | <tk2okc$1o3pb$1@dont-email.me> |
| In reply to | #31328 |
On 04/11/2022 05:10, Rick C wrote: > Yeah, I'm fine with a cable I can make to any length I want in 5 minutes, with most of that spent finding where I put the parts and tool. Oh, and costs less than $1. > A cable you can make in 5 minutes doesn't cost $1, unless you earn less than a hamburger flipper and the parts are free. The cost of a poor connection when making the cable could be huge in downtime of the testbench. It should not be hard to get a bag of pre-made short Ethernet cables for a couple of dollars per cable - it's probably cheaper to buy an effectively unlimited supply than to buy a good quality crimping tool.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2022-11-04 08:52 -0700 |
| Message-ID | <f89bca6b-8b07-4217-a050-77a91920b280n@googlegroups.com> |
| In reply to | #31332 |
On Friday, November 4, 2022 at 6:13:37 AM UTC-4, David Brown wrote: > On 04/11/2022 05:10, Rick C wrote: > > > Yeah, I'm fine with a cable I can make to any length I want in 5 minutes, with most of that spent finding where I put the parts and tool. Oh, and costs less than $1. > > > A cable you can make in 5 minutes doesn't cost $1, unless you earn less > than a hamburger flipper and the parts are free. The cost of a poor > connection when making the cable could be huge in downtime of the > testbench. It should not be hard to get a bag of pre-made short > Ethernet cables for a couple of dollars per cable - it's probably > cheaper to buy an effectively unlimited supply than to buy a good > quality crimping tool. You are not only right, but absolutely correct. 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. Under quantity, they even list "unlimited supply". -- 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-04 20:03 -0700 |
| Message-ID | <87cza22jd3.fsf@nightsong.com> |
| In reply to | #31335 |
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.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web