Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

We have a equal opportunity Calculus class -- it's fully integrated.


devel / comp.arch.embedded / Re: Shared Communications Bus - RS-422 or RS-485

SubjectAuthor
* Shared Communications Bus - RS-422 or RS-485Rick C
+* Re: Shared Communications Bus - RS-422 or RS-485David Brown
|+* Re: Shared Communications Bus - RS-422 or RS-485pozz
||`- Re: Shared Communications Bus - RS-422 or RS-485David Brown
|`* Re: Shared Communications Bus - RS-422 or RS-485Rick C
| `* Re: Shared Communications Bus - RS-422 or RS-485David Brown
|  `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|   `* Re: Shared Communications Bus - RS-422 or RS-485David Brown
|    `* Re: Shared Communications Bus - RS-422 or RS-485pozz
|     +* Re: Shared Communications Bus - RS-422 or RS-485David Brown
|     |`* Re: Shared Communications Bus - RS-422 or RS-485pozz
|     | `* Re: Shared Communications Bus - RS-422 or RS-485David Brown
|     |  +* Re: Shared Communications Bus - RS-422 or RS-485pozz
|     |  |`* Re: Shared Communications Bus - RS-422 or RS-485David Brown
|     |  | `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |  |  `* Re: Shared Communications Bus - RS-422 or RS-485David Brown
|     |  |   `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |  |    `* Re: Shared Communications Bus - RS-422 or RS-485Stef
|     |  |     +- Re: Shared Communications Bus - RS-422 or RS-485David Brown
|     |  |     `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |  |      `* Re: Shared Communications Bus - RS-422 or RS-485Richard Damon
|     |  |       `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |  |        `* Re: Shared Communications Bus - RS-422 or RS-485Richard Damon
|     |  |         `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |  |          +* Re: Shared Communications Bus - RS-422 or RS-485Clifford Heath
|     |  |          |`* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |  |          | +- Re: Shared Communications Bus - RS-422 or RS-485Clifford Heath
|     |  |          | `- Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |  |          `* Re: Shared Communications Bus - RS-422 or RS-485Richard Damon
|     |  |           `- Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |  `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |   +* Re: Shared Communications Bus - RS-422 or RS-485antispam
|     |   |`* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |   | +* Re: Shared Communications Bus - RS-422 or RS-485antispam
|     |   | |`- Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |   | `- Re: Shared Communications Bus - RS-422 or RS-485Stef
|     |   `* Re: Shared Communications Bus - RS-422 or RS-485David Brown
|     |    `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |     `* Re: Shared Communications Bus - RS-422 or RS-485David Brown
|     |      +* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |      |`* Re: Shared Communications Bus - RS-422 or RS-485David Brown
|     |      | `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |      |  +* Re: Shared Communications Bus - RS-422 or RS-485David Brown
|     |      |  |`* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |      |  | `* Re: Shared Communications Bus - RS-422 or RS-485Stef
|     |      |  |  `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |      |  |   `* Re: Shared Communications Bus - RS-422 or RS-485Stef
|     |      |  |    `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |      |  |     `* Re: Shared Communications Bus - RS-422 or RS-485Stef
|     |      |  |      `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |      |  |       +- Re: Shared Communications Bus - RS-422 or RS-485Stef
|     |      |  |       `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |      |  |        +- Re: Shared Communications Bus - RS-422 or RS-485Stef
|     |      |  |        `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |      |  |         +- Re: Shared Communications Bus - RS-422 or RS-485David Brown
|     |      |  |         `- Re: Shared Communications Bus - RS-422 or RS-485Richard Damon
|     |      |  `* Re: Shared Communications Bus - RS-422 or RS-485Richard Damon
|     |      |   +* Re: Shared Communications Bus - RS-422 or RS-485Paul Rubin
|     |      |   |`* Re: Shared Communications Bus - RS-422 or RS-485Richard Damon
|     |      |   | `- Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |      |   `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |      |    `* Re: Shared Communications Bus - RS-422 or RS-485Stef
|     |      |     `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |      |      `* Re: Shared Communications Bus - RS-422 or RS-485Stef
|     |      |       `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |      |        `* Re: Shared Communications Bus - RS-422 or RS-485Stef
|     |      |         `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |      |          `* Re: Shared Communications Bus - RS-422 or RS-485Paul Rubin
|     |      |           `- Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     |      `- Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|      `* Re: Shared Communications Bus - RS-422 or RS-485Paul Rubin
|       `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|        `* Re: Shared Communications Bus - RS-422 or RS-485Paul Rubin
|         +* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|         |`* Re: Shared Communications Bus - RS-422 or RS-485Paul Rubin
|         | `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|         |  `* Re: Shared Communications Bus - RS-422 or RS-485David Brown
|         |   `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|         |    `* Re: Shared Communications Bus - RS-422 or RS-485Paul Rubin
|         |     `- Re: Shared Communications Bus - RS-422 or RS-485David Brown
|         `- Re: Shared Communications Bus - RS-422 or RS-485David Brown
+* Re: Shared Communications Bus - RS-422 or RS-485Paul Rubin
|`* Re: Shared Communications Bus - RS-422 or RS-485Rick C
| `* Re: Shared Communications Bus - RS-422 or RS-485Paul Rubin
|  `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|   `* Re: Shared Communications Bus - RS-422 or RS-485Paul Rubin
|    `* Re: Shared Communications Bus - RS-422 or RS-485Rick C
|     `* Re: Shared Communications Bus - RS-422 or RS-485Paul Rubin
|      `- Re: Shared Communications Bus - RS-422 or RS-485Rick C
+* Re: Shared Communications Bus - RS-422 or RS-485Dave Nadler
|`* Re: Shared Communications Bus - RS-422 or RS-485Rick C
| `- Re: Shared Communications Bus - RS-422 or RS-485Richard Damon
`- Re: Shared Communications Bus - RS-422 or RS-485chris

Pages:1234
Re: Shared Communications Bus - RS-422 or RS-485

<tk83ql$32rij$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1165&group=comp.arch.embedded#1165

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: Shared Communications Bus - RS-422 or RS-485
Date: Sun, 6 Nov 2022 11:55:17 +0100
Organization: A noiseless patient Spider
Lines: 65
Message-ID: <tk83ql$32rij$1@dont-email.me>
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me>
<b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me>
<ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me>
<05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me>
<55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me>
<608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 6 Nov 2022 10:55:17 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="7f2383d589da89ae0a3de4311e480df9";
logging-data="3239507"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+YYfAEIKXtowG5zhs+9CK1PIrn9uyrV9M="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.2.2
Cancel-Lock: sha1:H0jHtyIK930PHd4P1kOpfTenlFE=
In-Reply-To: <608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
Content-Language: en-GB
 by: David Brown - Sun, 6 Nov 2022 10:55 UTC

On 05/11/2022 21:42, Rick C wrote:
> On Saturday, November 5, 2022 at 2:57:30 PM UTC-4, David Brown wrote:
>> On 05/11/2022 18:23, Rick C wrote:
>>> On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote:

>> The USB device is /not/ a processor - it is a converter between USB and
>> UART. And it is the USB device that controls the transmit enable signal
>> to the RS-485/RS-422 driver. There is no software on any processor
>> handling the transmit enable signal - the driver is enabled precisely
>> when the USB to UART device is sending data on the UART.
>
> Actually, the FTDI device is a processor. I expect it actually has no UART, rather the entire thing is done in software. I recall there being code to download for various purposes, such as JTAG, but I forget the details. I'm pretty sure the TxEn is controlled by FTDI software.
>

No, I think you are mixing things up. FTDI make a fair number of
devices, including some that /are/ processors or contain processors.
(That would their display controller devices, their USB host
controllers, amongst others.)

The code for using chips like the FT232H as a JTAG interface runs on the
host PC, not FTDI chip - it is a DLL or so file (or OpenOCD, or other
software). The chip has /hardware/ support for a few different serial
interfaces - SPI, I²C, JTAG and UART.

>> As I mentioned earlier, this thread is getting seriously mixed-up. The
>> transmit enable discussion started with /RS-485/ - long before you
>> decided to use a hybrid bus and a RS-422 cable. You were concerned
>> about how the PC controlled the transmitter enable for the RS-485
>> driver, and I have been trying to explain how this works when you use a
>> decent UART device. You only confuse yourself when you jump to
>> discussing RS-422 here, in this bit of the conversation.
>
> Ok, I'll stop talking about what I am doing.
>

We don't need to stop talking about it - we (everyone) just need to be a
bit clearer about the context. It's been fun to talk about, and its
great that you have a solution you are happy with, but it's a shame if
topic mixup leads to frustration.

>> All communications have failures. Accept that as a principle, and
>> understand how to deal with it. It's not hard to do - it is certainly
>> much easier than trying to imagine and eliminate any possible cause of
>> trouble.
>
> That's not a premise I have to deal with. I will also die. I'm not factoring that into the project either.
>
> I don't need to eliminate "any possible cause of trouble". I only have to reach an effective level of reliability. As I've said, error handling protocols are complex and subject to failure. It's much more likely I will have more trouble with the error handling protocol than I will with bit errors on the bus. So I choose the most reliable solution, no error handling. So without an error handling protocol in the software, I don't need to do anything further to deal with errors.
>

I agree that error handling procedures can be difficult - and very
often, they are poorly tested and have their own bugs (hardware or
software). Over-engineering can reduce overall reliability, rather than
increase it. (A few years back, we had a project that had to be updated
to SIL safety certification requirements. Most of the changes reduced
the overall safety and reliability in order to fulfil the documentation
and certification requirements.)

For serial protocols, ensuring a brief pause between telegrams is
extremely simple and makes recovery possible after many kinds of errors.
That's why it is found in virtually every serial protocol in wide use.
And like it or not, you have it already in your hybrid bus solution.

Re: Shared Communications Bus - RS-422 or RS-485

<0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1166&group=comp.arch.embedded#1166

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:a05:622a:19a6:b0:3a5:7005:e8a with SMTP id u38-20020a05622a19a600b003a570050e8amr8008283qtc.147.1667743014075;
Sun, 06 Nov 2022 05:56:54 -0800 (PST)
X-Received: by 2002:a25:9ac6:0:b0:6ca:d6:15e6 with SMTP id t6-20020a259ac6000000b006ca00d615e6mr42153613ybo.420.1667743013801;
Sun, 06 Nov 2022 05:56:53 -0800 (PST)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.embedded
Date: Sun, 6 Nov 2022 05:56:53 -0800 (PST)
In-Reply-To: <tk83ql$32rij$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=65.207.89.54; posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 65.207.89.54
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me> <b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me> <ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me> <05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me> <55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me> <608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
<tk83ql$32rij$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
Subject: Re: Shared Communications Bus - RS-422 or RS-485
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Sun, 06 Nov 2022 13:56:54 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 6548
 by: Rick C - Sun, 6 Nov 2022 13:56 UTC

On Sunday, November 6, 2022 at 5:55:22 AM UTC-5, David Brown wrote:
> On 05/11/2022 21:42, Rick C wrote:
> > On Saturday, November 5, 2022 at 2:57:30 PM UTC-4, David Brown wrote:
> >> On 05/11/2022 18:23, Rick C wrote:
> >>> On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote:
>
> >> The USB device is /not/ a processor - it is a converter between USB and
> >> UART. And it is the USB device that controls the transmit enable signal
> >> to the RS-485/RS-422 driver. There is no software on any processor
> >> handling the transmit enable signal - the driver is enabled precisely
> >> when the USB to UART device is sending data on the UART.
> >
> > Actually, the FTDI device is a processor. I expect it actually has no UART, rather the entire thing is done in software. I recall there being code to download for various purposes, such as JTAG, but I forget the details. I'm pretty sure the TxEn is controlled by FTDI software.
> >
> No, I think you are mixing things up. FTDI make a fair number of
> devices, including some that /are/ processors or contain processors.
> (That would their display controller devices, their USB host
> controllers, amongst others.)
>
> The code for using chips like the FT232H as a JTAG interface runs on the
> host PC, not FTDI chip - it is a DLL or so file (or OpenOCD, or other
> software). The chip has /hardware/ support for a few different serial
> interfaces - SPI, I²C, JTAG and UART.

They need code for the PC to run, but there is no reason to think they don't use a processor in the USB dongle.

> >> As I mentioned earlier, this thread is getting seriously mixed-up. The
> >> transmit enable discussion started with /RS-485/ - long before you
> >> decided to use a hybrid bus and a RS-422 cable. You were concerned
> >> about how the PC controlled the transmitter enable for the RS-485
> >> driver, and I have been trying to explain how this works when you use a
> >> decent UART device. You only confuse yourself when you jump to
> >> discussing RS-422 here, in this bit of the conversation.
> >
> > Ok, I'll stop talking about what I am doing.
> >
> We don't need to stop talking about it - we (everyone) just need to be a
> bit clearer about the context. It's been fun to talk about, and its
> great that you have a solution you are happy with, but it's a shame if
> topic mixup leads to frustration.
> >> All communications have failures. Accept that as a principle, and
> >> understand how to deal with it. It's not hard to do - it is certainly
> >> much easier than trying to imagine and eliminate any possible cause of
> >> trouble.
> >
> > That's not a premise I have to deal with. I will also die. I'm not factoring that into the project either.
> >
> > I don't need to eliminate "any possible cause of trouble". I only have to reach an effective level of reliability. As I've said, error handling protocols are complex and subject to failure. It's much more likely I will have more trouble with the error handling protocol than I will with bit errors on the bus. So I choose the most reliable solution, no error handling. So without an error handling protocol in the software, I don't need to do anything further to deal with errors.
> >
> I agree that error handling procedures can be difficult - and very
> often, they are poorly tested and have their own bugs (hardware or
> software). Over-engineering can reduce overall reliability, rather than
> increase it. (A few years back, we had a project that had to be updated
> to SIL safety certification requirements. Most of the changes reduced
> the overall safety and reliability in order to fulfil the documentation
> and certification requirements.)
>
> For serial protocols, ensuring a brief pause between telegrams is
> extremely simple and makes recovery possible after many kinds of errors.
> That's why it is found in virtually every serial protocol in wide use.
> And like it or not, you have it already in your hybrid bus solution.

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.

--

Rick C.

-+-+ Get 1,000 miles of free Supercharging
-+-+ Tesla referral code - https://ts.la/richard11209

Re: Shared Communications Bus - RS-422 or RS-485

<tk96t7$3abv7$2@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1167&group=comp.arch.embedded#1167

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: Shared Communications Bus - RS-422 or RS-485
Date: Sun, 6 Nov 2022 21:53:59 +0100
Organization: A noiseless patient Spider
Lines: 80
Message-ID: <tk96t7$3abv7$2@dont-email.me>
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me>
<b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me>
<ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me>
<05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me>
<55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me>
<608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
<tk83ql$32rij$1@dont-email.me>
<0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 6 Nov 2022 20:53:59 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="7f2383d589da89ae0a3de4311e480df9";
logging-data="3485671"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19jNkVnDco+NIFnt3Mh/vjgwULgb5Ec+1A="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.2.2
Cancel-Lock: sha1:M5WyZt+oKzl2V1Ec5O/cCPXVcEY=
Content-Language: en-GB
In-Reply-To: <0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
 by: David Brown - Sun, 6 Nov 2022 20:53 UTC

On 06/11/2022 14:56, Rick C wrote:
> On Sunday, November 6, 2022 at 5:55:22 AM UTC-5, David Brown wrote:
>> On 05/11/2022 21:42, Rick C wrote:
>>> On Saturday, November 5, 2022 at 2:57:30 PM UTC-4, David Brown wrote:
>>>> On 05/11/2022 18:23, Rick C wrote:
>>>>> On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote:
>>
>>>> The USB device is /not/ a processor - it is a converter between USB and
>>>> UART. And it is the USB device that controls the transmit enable signal
>>>> to the RS-485/RS-422 driver. There is no software on any processor
>>>> handling the transmit enable signal - the driver is enabled precisely
>>>> when the USB to UART device is sending data on the UART.
>>>
>>> Actually, the FTDI device is a processor. I expect it actually has no UART, rather the entire thing is done in software. I recall there being code to download for various purposes, such as JTAG, but I forget the details. I'm pretty sure the TxEn is controlled by FTDI software.
>>>
>> No, I think you are mixing things up. FTDI make a fair number of
>> devices, including some that /are/ processors or contain processors.
>> (That would their display controller devices, their USB host
>> controllers, amongst others.)
>>
>> The code for using chips like the FT232H as a JTAG interface runs on the
>> host PC, not FTDI chip - it is a DLL or so file (or OpenOCD, or other
>> software). The chip has /hardware/ support for a few different serial
>> interfaces - SPI, I²C, JTAG and UART.
>
> They need code for the PC to run, but there is no reason to think they don't use a processor in the USB dongle.
>

There is no reason to think that they /do/ have a processor there. I
should imagine you would have no problem making the programmable logic
needed for controlling a UART/SPI/I²C/JTAG/GPIO port, and USB slave
devices are rarely made in software (even on the XMOS they prefer
hardware blocks for USB). Why would anyone use a /processor/ for some
simple digital hardware? I am not privy to the details of the FTDI
design beyond their published documents, but it seems pretty clear to me
that there is no processor in sight.

>
>>>> As I mentioned earlier, this thread is getting seriously mixed-up. The
>>>> transmit enable discussion started with /RS-485/ - long before you
>>>> decided to use a hybrid bus and a RS-422 cable. You were concerned
>>>> about how the PC controlled the transmitter enable for the RS-485
>>>> driver, and I have been trying to explain how this works when you use a
>>>> decent UART device. You only confuse yourself when you jump to
>>>> discussing RS-422 here, in this bit of the conversation.
>>>
>>> Ok, I'll stop talking about what I am doing.
>>>
>> We don't need to stop talking about it - we (everyone) just need to be a
>> bit clearer about the context. It's been fun to talk about, and its
>> great that you have a solution you are happy with, but it's a shame if
>> topic mixup leads to frustration.
>>>> All communications have failures. Accept that as a principle, and
>>>> understand how to deal with it. It's not hard to do - it is certainly
>>>> much easier than trying to imagine and eliminate any possible cause of
>>>> trouble.
>>>
>>> That's not a premise I have to deal with. I will also die. I'm not factoring that into the project either.
>>>
>>> I don't need to eliminate "any possible cause of trouble". I only have to reach an effective level of reliability. As I've said, error handling protocols are complex and subject to failure. It's much more likely I will have more trouble with the error handling protocol than I will with bit errors on the bus. So I choose the most reliable solution, no error handling. So without an error handling protocol in the software, I don't need to do anything further to deal with errors.
>>>
>> I agree that error handling procedures can be difficult - and very
>> often, they are poorly tested and have their own bugs (hardware or
>> software). Over-engineering can reduce overall reliability, rather than
>> increase it. (A few years back, we had a project that had to be updated
>> to SIL safety certification requirements. Most of the changes reduced
>> the overall safety and reliability in order to fulfil the documentation
>> and certification requirements.)
>>
>> For serial protocols, ensuring a brief pause between telegrams is
>> extremely simple and makes recovery possible after many kinds of errors.
>> That's why it is found in virtually every serial protocol in wide use.
>> And like it or not, you have it already in your hybrid bus solution.
>
> 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.
>

That is one way to handle possible errors.

Re: Shared Communications Bus - RS-422 or RS-485

<xwX9L.33736$TUR8.17072@fx17.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1168&group=comp.arch.embedded#1168

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx17.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.4.1
Subject: Re: Shared Communications Bus - RS-422 or RS-485
Content-Language: en-US
Newsgroups: comp.arch.embedded
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me>
<b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me>
<ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me>
<05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me>
<55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me>
<608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
<tk83ql$32rij$1@dont-email.me>
<0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 20
Message-ID: <xwX9L.33736$TUR8.17072@fx17.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sun, 6 Nov 2022 18:34:55 -0500
X-Received-Bytes: 2885
 by: Richard Damon - Sun, 6 Nov 2022 23:34 UTC

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.

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.

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.

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

Re: Shared Communications Bus - RS-422 or RS-485

<87v8nr1wp6.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1169&group=comp.arch.embedded#1169

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.arch.embedded
Subject: Re: Shared Communications Bus - RS-422 or RS-485
Date: Sun, 06 Nov 2022 15:37:25 -0800
Organization: A noiseless patient Spider
Lines: 6
Message-ID: <87v8nr1wp6.fsf@nightsong.com>
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me>
<b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me>
<ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me>
<05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me>
<55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me>
<608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
<tk83ql$32rij$1@dont-email.me>
<0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
<xwX9L.33736$TUR8.17072@fx17.iad>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: reader01.eternal-september.org; posting-host="aaa6411e924e7398e6b8a0636aec8031";
logging-data="3516029"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/YyBaMn2loG15Popgbdsl4"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Cancel-Lock: sha1:x/TORsGCXTo9k445gFHSVkdfPJo=
sha1:37Beik0eaDKU5DfW1v+WeaXhvwY=
 by: Paul Rubin - Sun, 6 Nov 2022 23:37 UTC

Richard Damon <Richard@Damon-Family.org> writes:
> And such handshaking is needed if you have need to handle noise in
> packets.

Once you acknowledge that noise and errors are even possible, some kind
of checksums or FEC seem appropriate in addition to a retry protocol.

Re: Shared Communications Bus - RS-422 or RS-485

<P9Y9L.71047$2Rs3.50835@fx12.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1170&group=comp.arch.embedded#1170

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx12.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.4.1
Subject: Re: Shared Communications Bus - RS-422 or RS-485
Content-Language: en-US
Newsgroups: comp.arch.embedded
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me>
<b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me>
<ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me>
<05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me>
<55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me>
<608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
<tk83ql$32rij$1@dont-email.me>
<0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
<xwX9L.33736$TUR8.17072@fx17.iad> <87v8nr1wp6.fsf@nightsong.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <87v8nr1wp6.fsf@nightsong.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 10
Message-ID: <P9Y9L.71047$2Rs3.50835@fx12.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sun, 6 Nov 2022 19:18:57 -0500
X-Received-Bytes: 2151
 by: Richard Damon - Mon, 7 Nov 2022 00:18 UTC

On 11/6/22 6:37 PM, Paul Rubin wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>> And such handshaking is needed if you have need to handle noise in
>> packets.
>
> Once you acknowledge that noise and errors are even possible, some kind
> of checksums or FEC seem appropriate in addition to a retry protocol.

Yes, the messages should have some form of checksum in them to identify
bad packets. That should be part of the message definition.

Re: Shared Communications Bus - RS-422 or RS-485

<nnd$6a130c7b$68b29486@72e1c12e4320b3d3>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1171&group=comp.arch.embedded#1171

 copy link   Newsgroups: comp.arch.embedded
Newsgroups: comp.arch.embedded
From: me...@this.is.invalid (Stef)
Subject: Re: Shared Communications Bus - RS-422 or RS-485
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me>
<b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me>
<ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me>
<05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk4558$1i99$1@gioia.aioe.org>
<e130818b-2e12-4dbc-b8a3-ee72a6ef42b3n@googlegroups.com>
Mail-Copies-To: nobody
User-Agent: slrn/1.0.3 (Linux)
Message-ID: <nnd$6a130c7b$68b29486@72e1c12e4320b3d3>
Organization: Newsxs
Date: Mon, 07 Nov 2022 10:40:00 +0100
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!feed.abavia.com!abe005.abavia.com!abp003.abavia.com!news.newsxs.nl!not-for-mail
Lines: 27
Injection-Date: Mon, 07 Nov 2022 10:40:00 +0100
Injection-Info: news.newsxs.nl; mail-complaints-to="abuse@newsxs.nl"
X-Received-Bytes: 2685
 by: Stef - Mon, 7 Nov 2022 09:40 UTC

On 2022-11-05 Rick C wrote in comp.arch.embedded:
....
> One thing I'm a bit confused about, is the wiring of the EIA/TIA 568B or 568A cables. Both standards are used, but as far as I can tell, the only difference is the colors! The green and orange twisted pairs are reversed on both ends, making the cables electrically identical, other than the colors used for a given pair. The only difference is, the different pairs have different twist pitch, to help reduce crosstalk. But the numbers are not specified in the spec, so I don't see how this could matter.
>
> Why would the color be an issue, to the point of creating two different specs???
>
> Obviously I'm missing something. I will need to check a cable before I design the boards, lol.

Yes, only difference is the colors. There are some historical
backgrounds, see also https://en.wikipedia.org/wiki/ANSI/TIA-568.

In the early days there sometimes was a need for crossover cables. 568A
on one end, 568B on the other end. IIRC, you needed one to connect 2
PC's together directly, without a hub. Hubs also had a special uplink
port.

These days all ethernet PHY's are auto detect and there is no need
for special ports or cables anymore. So pick a standard you like or just
use what is available. Most cables I have in my drawer here seem to be
568B. Just standard cables, did not pay attention to the A/B when I
bought them. ;-)

--
Stef

The light at the end of the tunnel is the headlight of an approaching train.

Re: Shared Communications Bus - RS-422 or RS-485

<bf93b34c-ccdd-4178-b377-17589fd52bcen@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1172&group=comp.arch.embedded#1172

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:ac8:5746:0:b0:39c:deac:c69c with SMTP id 6-20020ac85746000000b0039cdeacc69cmr38485579qtx.292.1667815082944;
Mon, 07 Nov 2022 01:58:02 -0800 (PST)
X-Received: by 2002:a25:dacc:0:b0:6cb:866:6245 with SMTP id
n195-20020a25dacc000000b006cb08666245mr49690765ybf.473.1667815082703; Mon, 07
Nov 2022 01:58:02 -0800 (PST)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.embedded
Date: Mon, 7 Nov 2022 01:58:02 -0800 (PST)
In-Reply-To: <tk96t7$3abv7$2@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2605:ba00:a220:106e:458f:d6f0:844e:ea79;
posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 2605:ba00:a220:106e:458f:d6f0:844e:ea79
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me> <b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me> <ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me> <05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me> <55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me> <608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
<tk83ql$32rij$1@dont-email.me> <0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
<tk96t7$3abv7$2@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <bf93b34c-ccdd-4178-b377-17589fd52bcen@googlegroups.com>
Subject: Re: Shared Communications Bus - RS-422 or RS-485
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Mon, 07 Nov 2022 09:58:02 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 5320
 by: Rick C - Mon, 7 Nov 2022 09:58 UTC

On Sunday, November 6, 2022 at 3:54:04 PM UTC-5, David Brown wrote:
> On 06/11/2022 14:56, Rick C wrote:
> > On Sunday, November 6, 2022 at 5:55:22 AM UTC-5, David Brown wrote:
> >> On 05/11/2022 21:42, Rick C wrote:
> >>> On Saturday, November 5, 2022 at 2:57:30 PM UTC-4, David Brown wrote:
> >>>> On 05/11/2022 18:23, Rick C wrote:
> >>>>> On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote:
> >>
> >>>> The USB device is /not/ a processor - it is a converter between USB and
> >>>> UART. And it is the USB device that controls the transmit enable signal
> >>>> to the RS-485/RS-422 driver. There is no software on any processor
> >>>> handling the transmit enable signal - the driver is enabled precisely
> >>>> when the USB to UART device is sending data on the UART.
> >>>
> >>> Actually, the FTDI device is a processor. I expect it actually has no UART, rather the entire thing is done in software. I recall there being code to download for various purposes, such as JTAG, but I forget the details.. I'm pretty sure the TxEn is controlled by FTDI software.
> >>>
> >> No, I think you are mixing things up. FTDI make a fair number of
> >> devices, including some that /are/ processors or contain processors.
> >> (That would their display controller devices, their USB host
> >> controllers, amongst others.)
> >>
> >> The code for using chips like the FT232H as a JTAG interface runs on the
> >> host PC, not FTDI chip - it is a DLL or so file (or OpenOCD, or other
> >> software). The chip has /hardware/ support for a few different serial
> >> interfaces - SPI, I²C, JTAG and UART.
> >
> > They need code for the PC to run, but there is no reason to think they don't use a processor in the USB dongle.
> >
> There is no reason to think that they /do/ have a processor there. I
> should imagine you would have no problem making the programmable logic
> needed for controlling a UART/SPI/I²C/JTAG/GPIO port, and USB slave
> devices are rarely made in software (even on the XMOS they prefer
> hardware blocks for USB). Why would anyone use a /processor/ for some
> simple digital hardware? I am not privy to the details of the FTDI
> design beyond their published documents, but it seems pretty clear to me
> that there is no processor in sight.

I don't agree. These interfaces are not so simple when you consider the level of flexibility in implementing many different interfaces in one part. XMOS is nothing like this. A small processor running at high speed would easily implement any of these interfaces. The small processor can actually be a very small amount of chip area. Typical MCUs are dominated by the memory blocks. With a small memory an MCU could easily be smaller than dedicated logic. Even many of the I/O blocks, like UARTs, can be larger than an 8 bit CPU. A CPU takes advantage of the massive multiplexer in the memory, which is implemented in ways that use very little area. FPGAs use the multiplexers in tiny LUTs while an MCU uses the multiplexer in a single, much larger LUT, the program store.

--

Rick C.

-++- Get 1,000 miles of free Supercharging
-++- Tesla referral code - https://ts.la/richard11209

Re: Shared Communications Bus - RS-422 or RS-485

<nnd$6f3f0caf$4d60a848@f05e10f4dcc9e72b>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1173&group=comp.arch.embedded#1173

 copy link   Newsgroups: comp.arch.embedded
Newsgroups: comp.arch.embedded
From: me...@this.is.invalid (Stef)
Subject: Re: Shared Communications Bus - RS-422 or RS-485
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me>
<b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me>
<ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me> <tk3839$1nau3$2@dont-email.me>
<tk3f2t$1t3hc$1@dont-email.me>
<3d9e5c38-93be-4504-b891-e0087053ebc7n@googlegroups.com>
<tk5fkb$2dl2i$2@dont-email.me>
<377ca797-345a-4daf-aa84-eb0e2fb889a6n@googlegroups.com>
Mail-Copies-To: nobody
User-Agent: slrn/1.0.3 (Linux)
Message-ID: <nnd$6f3f0caf$4d60a848@f05e10f4dcc9e72b>
Organization: Newsxs
Date: Mon, 07 Nov 2022 11:00:03 +0100
Path: i2pn2.org!i2pn.org!news.swapon.de!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!feed.abavia.com!abe004.abavia.com!abp001.abavia.com!news.newsxs.nl!not-for-mail
Lines: 40
Injection-Date: Mon, 07 Nov 2022 11:00:03 +0100
Injection-Info: news.newsxs.nl; mail-complaints-to="abuse@newsxs.nl"
X-Received-Bytes: 3247
 by: Stef - Mon, 7 Nov 2022 10:00 UTC

On 2022-11-05 Rick C wrote in comp.arch.embedded:
> On Saturday, November 5, 2022 at 6:58:24 AM UTC-4, David Brown wrote:
>
>> In UART communication, this is handled at the protocol level rather than
>> the hardware (though some UART hardware may have "idle detect" signals
>> when more than 11 bits of high level are seen in a row). Some
>> UART-based protocols also use a "break" signal between frames - that is
>> a string of at least 11 bits of low level.
>>
>> If you do not have such pauses, and a receiver is out of step,
>
> You have failed to explain how a receiver would get "out of step". The receiver syncs to every character transmitted. If all characters are received, what else do you need? How does it get "out of step"?

I have seen this happen in long messages (few kB) with no pauses between
characters and transmitter and receiver set to 8,N,1. It seemed that the
receiver needed the complete stop bit and then immediately saw the low
of the next start bit. Detecting the edge when it was ready to see it,
not when it actually happened. When the receiver is slightly slower than
the transmitter, this caused the detection of the start bit (and
therefor the whole character) to shift a tiny bit. This added up over
the character stream until it eventually failed.

Lowering the baud rate did not solve the issue, but inserting pauses
after a number of chars did. What also solved it was setting the
transmitter to 2 stop bits and the receiver to one stop bit. This was a
one way stream and this may not be possible on a bi-directional stream.

I would expect a sensible UART implementation to allow for a slightly
shorter stop bit to compensate for issues like this. But apparently this
UART did not do so in the 1 stop bit setting. I have not tested if
setting both ends to 2 stop bits also solved the problem.

--
Stef

Westheimer's Discovery:
A couple of months in the laboratory can frequently save a
couple of hours in the library.

Re: Shared Communications Bus - RS-422 or RS-485

<f81aabf9-87f3-440c-b063-40461d8b0359n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1174&group=comp.arch.embedded#1174

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:a05:6214:1c85:b0:4c5:6ed:b914 with SMTP id ib5-20020a0562141c8500b004c506edb914mr8761698qvb.0.1667815389501;
Mon, 07 Nov 2022 02:03:09 -0800 (PST)
X-Received: by 2002:a25:e04b:0:b0:6d7:26dc:67a5 with SMTP id
x72-20020a25e04b000000b006d726dc67a5mr4748161ybg.71.1667815389179; Mon, 07
Nov 2022 02:03:09 -0800 (PST)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.embedded
Date: Mon, 7 Nov 2022 02:03:08 -0800 (PST)
In-Reply-To: <xwX9L.33736$TUR8.17072@fx17.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=2605:ba00:a220:106e:458f:d6f0:844e:ea79;
posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 2605:ba00:a220:106e:458f:d6f0:844e:ea79
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me> <b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me> <ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me> <05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me> <55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me> <608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
<tk83ql$32rij$1@dont-email.me> <0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
<xwX9L.33736$TUR8.17072@fx17.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f81aabf9-87f3-440c-b063-40461d8b0359n@googlegroups.com>
Subject: Re: Shared Communications Bus - RS-422 or RS-485
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Mon, 07 Nov 2022 10:03:09 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 4217
 by: Rick C - Mon, 7 Nov 2022 10:03 UTC

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

Re: Shared Communications Bus - RS-422 or RS-485

<7dfde881-da25-4408-960a-cee283481ab9n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1175&group=comp.arch.embedded#1175

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:a05:620a:c88:b0:6fa:841b:86e5 with SMTP id q8-20020a05620a0c8800b006fa841b86e5mr13562156qki.498.1667815635183;
Mon, 07 Nov 2022 02:07:15 -0800 (PST)
X-Received: by 2002:a81:57d2:0:b0:36b:cc32:a150 with SMTP id
l201-20020a8157d2000000b0036bcc32a150mr47266378ywb.420.1667815634885; Mon, 07
Nov 2022 02:07:14 -0800 (PST)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.embedded
Date: Mon, 7 Nov 2022 02:07:14 -0800 (PST)
In-Reply-To: <P9Y9L.71047$2Rs3.50835@fx12.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=2605:ba00:a220:106e:458f:d6f0:844e:ea79;
posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 2605:ba00:a220:106e:458f:d6f0:844e:ea79
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me> <b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me> <ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me> <05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me> <55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me> <608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
<tk83ql$32rij$1@dont-email.me> <0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
<xwX9L.33736$TUR8.17072@fx17.iad> <87v8nr1wp6.fsf@nightsong.com> <P9Y9L.71047$2Rs3.50835@fx12.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7dfde881-da25-4408-960a-cee283481ab9n@googlegroups.com>
Subject: Re: Shared Communications Bus - RS-422 or RS-485
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Mon, 07 Nov 2022 10:07:15 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 3202
 by: Rick C - Mon, 7 Nov 2022 10:07 UTC

On Sunday, November 6, 2022 at 7:19:00 PM UTC-5, Richard Damon wrote:
> On 11/6/22 6:37 PM, Paul Rubin wrote:
> > Richard Damon <Ric...@Damon-Family.org> writes:
> >> And such handshaking is needed if you have need to handle noise in
> >> packets.
> >
> > Once you acknowledge that noise and errors are even possible, some kind
> > of checksums or FEC seem appropriate in addition to a retry protocol.
> Yes, the messages should have some form of checksum in them to identify
> bad packets. That should be part of the message definition.

Why? Does the processor checksum every value calculated and stored in memory? Not on my computer. This is not warranted because the data failure rate is very low. Same with an RS-422 bus in an electrically quiet environment. 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.

--

Rick C.

+--- Get 1,000 miles of free Supercharging
+--- Tesla referral code - https://ts.la/richard11209

Re: Shared Communications Bus - RS-422 or RS-485

<nnd$4bad0da4$14a9e7ec@210656c28878494e>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1176&group=comp.arch.embedded#1176

 copy link   Newsgroups: comp.arch.embedded
Newsgroups: comp.arch.embedded
From: me...@this.is.invalid (Stef)
Subject: Re: Shared Communications Bus - RS-422 or RS-485
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me>
<b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me>
<ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me>
<05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me>
<55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me>
<608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
<tk83ql$32rij$1@dont-email.me>
<0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
<tk96t7$3abv7$2@dont-email.me>
<bf93b34c-ccdd-4178-b377-17589fd52bcen@googlegroups.com>
Mail-Copies-To: nobody
User-Agent: slrn/1.0.3 (Linux)
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Message-ID: <nnd$4bad0da4$14a9e7ec@210656c28878494e>
Organization: Newsxs
Date: Mon, 07 Nov 2022 11:26:01 +0100
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!feed.abavia.com!abe004.abavia.com!abp002.abavia.com!news.newsxs.nl!not-for-mail
Lines: 51
Injection-Date: Mon, 07 Nov 2022 11:26:01 +0100
Injection-Info: news.newsxs.nl; mail-complaints-to="abuse@newsxs.nl"
X-Received-Bytes: 5180
 by: Stef - Mon, 7 Nov 2022 10:26 UTC

On 2022-11-07 Rick C wrote in comp.arch.embedded:
> On Sunday, November 6, 2022 at 3:54:04 PM UTC-5, David Brown wrote:
>> On 06/11/2022 14:56, Rick C wrote:
>> > On Sunday, November 6, 2022 at 5:55:22 AM UTC-5, David Brown wrote:
>> >> On 05/11/2022 21:42, Rick C wrote:
>> >>> On Saturday, November 5, 2022 at 2:57:30 PM UTC-4, David Brown wrote:
>> >>>> On 05/11/2022 18:23, Rick C wrote:
>> >>>>> On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote:
>> >>
>> >>>> The USB device is /not/ a processor - it is a converter between USB and
>> >>>> UART. And it is the USB device that controls the transmit enable signal
>> >>>> to the RS-485/RS-422 driver. There is no software on any processor
>> >>>> handling the transmit enable signal - the driver is enabled precisely
>> >>>> when the USB to UART device is sending data on the UART.
>> >>>
>> >>> Actually, the FTDI device is a processor. I expect it actually has no UART, rather the entire thing is done in software. I recall there being code to download for various purposes, such as JTAG, but I forget the details. I'm pretty sure the TxEn is controlled by FTDI software.
>> >>>
>> >> No, I think you are mixing things up. FTDI make a fair number of
>> >> devices, including some that /are/ processors or contain processors.
>> >> (That would their display controller devices, their USB host
>> >> controllers, amongst others.)
>> >>
>> >> The code for using chips like the FT232H as a JTAG interface runs on the
>> >> host PC, not FTDI chip - it is a DLL or so file (or OpenOCD, or other
>> >> software). The chip has /hardware/ support for a few different serial
>> >> interfaces - SPI, I²C, JTAG and UART.
>> >
>> > They need code for the PC to run, but there is no reason to think they don't use a processor in the USB dongle.
>> >
>> There is no reason to think that they /do/ have a processor there. I
>> should imagine you would have no problem making the programmable logic
>> needed for controlling a UART/SPI/I²C/JTAG/GPIO port, and USB slave
>> devices are rarely made in software (even on the XMOS they prefer
>> hardware blocks for USB). Why would anyone use a /processor/ for some
>> simple digital hardware? I am not privy to the details of the FTDI
>> design beyond their published documents, but it seems pretty clear to me
>> that there is no processor in sight.
>
> I don't agree. These interfaces are not so simple when you consider the level of flexibility in implementing many different interfaces in one part. XMOS is nothing like this. A small processor running at high speed would easily implement any of these interfaces. The small processor can actually be a very small amount of chip area. Typical MCUs are dominated by the memory blocks. With a small memory an MCU could easily be smaller than dedicated logic. Even many of the I/O blocks, like UARTs, can be larger than an 8 bit CPU. A CPU takes advantage of the massive multiplexer in the memory, which is implemented in ways that use very little area. FPGAs use the multiplexers in tiny LUTs while an MCU uses the multiplexer in a single, much larger LUT, the program store.

Why are you discussing this? Out of academic curiosity? Then please
continue. But what does it matter for your system implementation? There
is just a UART/SPI/I²C/JTAG/GPIO peripheral and your software won't care
how this peripheral is implemented, as long as it behaves as expected.

--
Stef

"Microwave oven? Whaddya mean, it's a microwave oven? I've been watching
Channel 4 on the thing for two weeks."

Re: Shared Communications Bus - RS-422 or RS-485

<54c1222e-de58-4a87-ba02-40d4ec9576a3n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1177&group=comp.arch.embedded#1177

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:a05:622a:22a1:b0:3a5:4fdb:ac68 with SMTP id ay33-20020a05622a22a100b003a54fdbac68mr514657qtb.214.1667817574103;
Mon, 07 Nov 2022 02:39:34 -0800 (PST)
X-Received: by 2002:a25:8f8f:0:b0:6c1:cd87:e726 with SMTP id
u15-20020a258f8f000000b006c1cd87e726mr43991363ybl.560.1667817573837; Mon, 07
Nov 2022 02:39:33 -0800 (PST)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.embedded
Date: Mon, 7 Nov 2022 02:39:33 -0800 (PST)
In-Reply-To: <nnd$4bad0da4$14a9e7ec@210656c28878494e>
Injection-Info: google-groups.googlegroups.com; posting-host=2605:ba00:a220:106e:458f:d6f0:844e:ea79;
posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 2605:ba00:a220:106e:458f:d6f0:844e:ea79
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me> <b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me> <ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me> <05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me> <55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me> <608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
<tk83ql$32rij$1@dont-email.me> <0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
<tk96t7$3abv7$2@dont-email.me> <bf93b34c-ccdd-4178-b377-17589fd52bcen@googlegroups.com>
<nnd$4bad0da4$14a9e7ec@210656c28878494e>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <54c1222e-de58-4a87-ba02-40d4ec9576a3n@googlegroups.com>
Subject: Re: Shared Communications Bus - RS-422 or RS-485
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Mon, 07 Nov 2022 10:39:34 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 6493
 by: Rick C - Mon, 7 Nov 2022 10:39 UTC

On Monday, November 7, 2022 at 5:26:06 AM UTC-5, Stef wrote:
> On 2022-11-07 Rick C wrote in comp.arch.embedded:
> > On Sunday, November 6, 2022 at 3:54:04 PM UTC-5, David Brown wrote:
> >> On 06/11/2022 14:56, Rick C wrote:
> >> > On Sunday, November 6, 2022 at 5:55:22 AM UTC-5, David Brown wrote:
> >> >> On 05/11/2022 21:42, Rick C wrote:
> >> >>> On Saturday, November 5, 2022 at 2:57:30 PM UTC-4, David Brown wrote:
> >> >>>> On 05/11/2022 18:23, Rick C wrote:
> >> >>>>> On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote:
> >> >>
> >> >>>> The USB device is /not/ a processor - it is a converter between USB and
> >> >>>> UART. And it is the USB device that controls the transmit enable signal
> >> >>>> to the RS-485/RS-422 driver. There is no software on any processor
> >> >>>> handling the transmit enable signal - the driver is enabled precisely
> >> >>>> when the USB to UART device is sending data on the UART.
> >> >>>
> >> >>> Actually, the FTDI device is a processor. I expect it actually has no UART, rather the entire thing is done in software. I recall there being code to download for various purposes, such as JTAG, but I forget the details. I'm pretty sure the TxEn is controlled by FTDI software.
> >> >>>
> >> >> No, I think you are mixing things up. FTDI make a fair number of
> >> >> devices, including some that /are/ processors or contain processors..
> >> >> (That would their display controller devices, their USB host
> >> >> controllers, amongst others.)
> >> >>
> >> >> The code for using chips like the FT232H as a JTAG interface runs on the
> >> >> host PC, not FTDI chip - it is a DLL or so file (or OpenOCD, or other
> >> >> software). The chip has /hardware/ support for a few different serial
> >> >> interfaces - SPI, I²C, JTAG and UART.
> >> >
> >> > They need code for the PC to run, but there is no reason to think they don't use a processor in the USB dongle.
> >> >
> >> There is no reason to think that they /do/ have a processor there. I
> >> should imagine you would have no problem making the programmable logic
> >> needed for controlling a UART/SPI/I²C/JTAG/GPIO port, and USB slave
> >> devices are rarely made in software (even on the XMOS they prefer
> >> hardware blocks for USB). Why would anyone use a /processor/ for some
> >> simple digital hardware? I am not privy to the details of the FTDI
> >> design beyond their published documents, but it seems pretty clear to me
> >> that there is no processor in sight.
> >
> > I don't agree. These interfaces are not so simple when you consider the level of flexibility in implementing many different interfaces in one part.. XMOS is nothing like this. A small processor running at high speed would easily implement any of these interfaces. The small processor can actually be a very small amount of chip area. Typical MCUs are dominated by the memory blocks. With a small memory an MCU could easily be smaller than dedicated logic. Even many of the I/O blocks, like UARTs, can be larger than an 8 bit CPU. A CPU takes advantage of the massive multiplexer in the memory, which is implemented in ways that use very little area. FPGAs use the multiplexers in tiny LUTs while an MCU uses the multiplexer in a single, much larger LUT, the program store.
> Why are you discussing this? Out of academic curiosity? Then please
> continue. But what does it matter for your system implementation? There
> is just a UART/SPI/I²C/JTAG/GPIO peripheral and your software won't care
> how this peripheral is implemented, as long as it behaves as expected.

I care. Don't you?

I remember when I came to the realization of why an MCU was so cost effective compared to programmable or even dedicated logic. It's because the MCU program is a FSM, using the instructions stored in the memory. These instruction are essentially logic, which is connected through the CPU logic, creating a very low cost solution to a wide variety of problems, because of the very low cost of memory compared to dedicated or programmable logic.

--

Rick C.

+--+ Get 1,000 miles of free Supercharging
+--+ Tesla referral code - https://ts.la/richard11209

Re: Shared Communications Bus - RS-422 or RS-485

<nnd$2d9aedf3$3ff05d81@29b8ea6f16782d6d>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1178&group=comp.arch.embedded#1178

 copy link   Newsgroups: comp.arch.embedded
Newsgroups: comp.arch.embedded
From: me...@this.is.invalid (Stef)
Subject: Re: Shared Communications Bus - RS-422 or RS-485
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com> <tjtd7g$145er$1@dont-email.me> <b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com> <tjul46$18dkn$3@dont-email.me> <ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com> <tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me> <tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me> <tk2n7g$1o0ct$1@dont-email.me> <05989871-748b-4b08-b564-84a323418b45n@googlegroups.com> <tk5iha$2e64h$1@dont-email.me> <55844769-5be7-47e9-b849-396e655188abn@googlegroups.com> <tk6bmk$2k36a$3@dont-email.me> <608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com> <tk83ql$32rij$1@dont-email.me> <0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com> <xwX9L.33736$TUR8.17072@fx17.iad> <f81aabf9-87f3-440c-b063-40461d8b0359n@googlegroups.com>
Mail-Copies-To: nobody
User-Agent: slrn/1.0.3 (Linux)
Message-ID: <nnd$2d9aedf3$3ff05d81@29b8ea6f16782d6d>
Organization: Newsxs
Date: Mon, 07 Nov 2022 11:55:21 +0100
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder.usenetexpress.com!tr1.eu1.usenetexpress.com!94.232.112.244.MISMATCH!feed.abavia.com!abe004.abavia.com!abp001.abavia.com!news.newsxs.nl!not-for-mail
Lines: 64
Injection-Date: Mon, 07 Nov 2022 11:55:21 +0100
Injection-Info: news.newsxs.nl; mail-complaints-to="abuse@newsxs.nl"
 by: Stef - Mon, 7 Nov 2022 10:55 UTC

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

Re: Shared Communications Bus - RS-422 or RS-485

<nnd$365bd2e6$24582938@34ecb23b658f2b03>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1179&group=comp.arch.embedded#1179

 copy link   Newsgroups: comp.arch.embedded
Newsgroups: comp.arch.embedded
From: me...@this.is.invalid (Stef)
Subject: Re: Shared Communications Bus - RS-422 or RS-485
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com> <tjtd7g$145er$1@dont-email.me> <b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com> <tjul46$18dkn$3@dont-email.me> <ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com> <tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me> <tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me> <tk2n7g$1o0ct$1@dont-email.me> <05989871-748b-4b08-b564-84a323418b45n@googlegroups.com> <tk5iha$2e64h$1@dont-email.me> <55844769-5be7-47e9-b849-396e655188abn@googlegroups.com> <tk6bmk$2k36a$3@dont-email.me> <608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com> <tk83ql$32rij$1@dont-email.me> <0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com> <tk96t7$3abv7$2@dont-email.me> <bf93b34c-ccdd-4178-b377-17589fd52bcen@googlegroups.com> <nnd$4bad0da4$14a9e7ec@210656c28878494e> <54c1222e-de58-4a87-ba02-40d4ec9576a3n@googlegroups.com>
Mail-Copies-To: nobody
User-Agent: slrn/1.0.3 (Linux)
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Message-ID: <nnd$365bd2e6$24582938@34ecb23b658f2b03>
Organization: Newsxs
Date: Mon, 07 Nov 2022 12:07:35 +0100
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!tr1.eu1.usenetexpress.com!94.232.112.244.MISMATCH!feed.abavia.com!abe004.abavia.com!abp003.abavia.com!news.newsxs.nl!not-for-mail
Lines: 71
Injection-Date: Mon, 07 Nov 2022 12:07:35 +0100
Injection-Info: news.newsxs.nl; mail-complaints-to="abuse@newsxs.nl"
 by: Stef - Mon, 7 Nov 2022 11:07 UTC

On 2022-11-07 Rick C wrote in comp.arch.embedded:
> On Monday, November 7, 2022 at 5:26:06 AM UTC-5, Stef wrote:
>> On 2022-11-07 Rick C wrote in comp.arch.embedded:
>> > On Sunday, November 6, 2022 at 3:54:04 PM UTC-5, David Brown wrote:
>> >> On 06/11/2022 14:56, Rick C wrote:
>> >> > On Sunday, November 6, 2022 at 5:55:22 AM UTC-5, David Brown wrote:
>> >> >> On 05/11/2022 21:42, Rick C wrote:
>> >> >>> On Saturday, November 5, 2022 at 2:57:30 PM UTC-4, David Brown wrote:
>> >> >>>> On 05/11/2022 18:23, Rick C wrote:
>> >> >>>>> On Saturday, November 5, 2022 at 7:47:59 AM UTC-4, David Brown wrote:
>> >> >>
>> >> >>>> The USB device is /not/ a processor - it is a converter between USB and
>> >> >>>> UART. And it is the USB device that controls the transmit enable signal
>> >> >>>> to the RS-485/RS-422 driver. There is no software on any processor
>> >> >>>> handling the transmit enable signal - the driver is enabled precisely
>> >> >>>> when the USB to UART device is sending data on the UART.
>> >> >>>
>> >> >>> Actually, the FTDI device is a processor. I expect it actually has no UART, rather the entire thing is done in software. I recall there being code to download for various purposes, such as JTAG, but I forget the details. I'm pretty sure the TxEn is controlled by FTDI software.
>> >> >>>
>> >> >> No, I think you are mixing things up. FTDI make a fair number of
>> >> >> devices, including some that /are/ processors or contain processors.
>> >> >> (That would their display controller devices, their USB host
>> >> >> controllers, amongst others.)
>> >> >>
>> >> >> The code for using chips like the FT232H as a JTAG interface runs on the
>> >> >> host PC, not FTDI chip - it is a DLL or so file (or OpenOCD, or other
>> >> >> software). The chip has /hardware/ support for a few different serial
>> >> >> interfaces - SPI, I²C, JTAG and UART.
>> >> >
>> >> > They need code for the PC to run, but there is no reason to think they don't use a processor in the USB dongle.
>> >> >
>> >> There is no reason to think that they /do/ have a processor there. I
>> >> should imagine you would have no problem making the programmable logic
>> >> needed for controlling a UART/SPI/I²C/JTAG/GPIO port, and USB slave
>> >> devices are rarely made in software (even on the XMOS they prefer
>> >> hardware blocks for USB). Why would anyone use a /processor/ for some
>> >> simple digital hardware? I am not privy to the details of the FTDI
>> >> design beyond their published documents, but it seems pretty clear to me
>> >> that there is no processor in sight.
>> >
>> > I don't agree. These interfaces are not so simple when you consider the level of flexibility in implementing many different interfaces in one part. XMOS is nothing like this. A small processor running at high speed would easily implement any of these interfaces. The small processor can actually be a very small amount of chip area. Typical MCUs are dominated by the memory blocks. With a small memory an MCU could easily be smaller than dedicated logic. Even many of the I/O blocks, like UARTs, can be larger than an 8 bit CPU. A CPU takes advantage of the massive multiplexer in the memory, which is implemented in ways that use very little area. FPGAs use the multiplexers in tiny LUTs while an MCU uses the multiplexer in a single, much larger LUT, the program store.
>> Why are you discussing this? Out of academic curiosity? Then please
>> continue. But what does it matter for your system implementation? There
>> is just a UART/SPI/I²C/JTAG/GPIO peripheral and your software won't care
>> how this peripheral is implemented, as long as it behaves as expected.
>
> I care. Don't you?

No, I don't. We do use FTDI chips in our designs to interface a serial
port to USB. And we also use ready made FTDI cables. We use these chips
and cables based on their specifications in datasheets and user guides
etc. I have never felt the need to invesitigate how the UART/USB
functionality was actually implemented inside the chip. What would I do
with this knowledge? In a design I must rely on the behaviour as
specified in the datasheet.

> I remember when I came to the realization of why an MCU was so cost effective compared to programmable or even dedicated logic. It's because the MCU program is a FSM, using the instructions stored in the memory. These instruction are essentially logic, which is connected through the CPU logic, creating a very low cost solution to a wide variety of problems, because of the very low cost of memory compared to dedicated or programmable logic.
>

This is what I would call 'academic interest', and that is perfectly
fine. And this knowledge might help you think differently about solving
a problem in your own design. But it will make no difference in how you
will imlement this chip (or cable) in your design.

--
Stef

So many men, so many opinions; every one his own way.
-- Publius Terentius Afer (Terence)

Re: Shared Communications Bus - RS-422 or RS-485

<tkb5o6$3jsb2$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1180&group=comp.arch.embedded#1180

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!rocksolid2!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: Shared Communications Bus - RS-422 or RS-485
Date: Mon, 7 Nov 2022 15:46:29 +0100
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <tkb5o6$3jsb2$1@dont-email.me>
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me>
<b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me>
<ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me> <tk3839$1nau3$2@dont-email.me>
<tk3f2t$1t3hc$1@dont-email.me>
<3d9e5c38-93be-4504-b891-e0087053ebc7n@googlegroups.com>
<tk5fkb$2dl2i$2@dont-email.me>
<377ca797-345a-4daf-aa84-eb0e2fb889a6n@googlegroups.com>
<nnd$6f3f0caf$4d60a848@f05e10f4dcc9e72b>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 7 Nov 2022 14:46:30 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="fa4f7761f5481cc8690c1657281c1371";
logging-data="3797346"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX188BrnWOeEac9AIQ3X05iCqqPhEkD8QAzM="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Cancel-Lock: sha1:0eeE3XiBgak/yU/dnH4FfC+XQRU=
Content-Language: en-GB
In-Reply-To: <nnd$6f3f0caf$4d60a848@f05e10f4dcc9e72b>
 by: David Brown - Mon, 7 Nov 2022 14:46 UTC

On 07/11/2022 11:00, Stef wrote:
> On 2022-11-05 Rick C wrote in comp.arch.embedded:
>> On Saturday, November 5, 2022 at 6:58:24 AM UTC-4, David Brown wrote:
>>
>>> In UART communication, this is handled at the protocol level rather than
>>> the hardware (though some UART hardware may have "idle detect" signals
>>> when more than 11 bits of high level are seen in a row). Some
>>> UART-based protocols also use a "break" signal between frames - that is
>>> a string of at least 11 bits of low level.
>>>
>>> If you do not have such pauses, and a receiver is out of step,
>>
>> You have failed to explain how a receiver would get "out of step". The receiver syncs to every character transmitted. If all characters are received, what else do you need? How does it get "out of step"?
>
> I have seen this happen in long messages (few kB) with no pauses between
> characters and transmitter and receiver set to 8,N,1. It seemed that the
> receiver needed the complete stop bit and then immediately saw the low
> of the next start bit. Detecting the edge when it was ready to see it,
> not when it actually happened. When the receiver is slightly slower than
> the transmitter, this caused the detection of the start bit (and
> therefor the whole character) to shift a tiny bit. This added up over
> the character stream until it eventually failed.
>
> Lowering the baud rate did not solve the issue, but inserting pauses
> after a number of chars did. What also solved it was setting the
> transmitter to 2 stop bits and the receiver to one stop bit. This was a
> one way stream and this may not be possible on a bi-directional stream.
>

An extra stop bit will help for this particular kind of error (and is a
good idea if you get such errors often, as it will improve your
percentage timing margins). An occasional pause of at least 11 bit
times will help for all sorts of possible errors.

Basically, it is a good idea to assume that sometimes things go wrong.
There can be noise, interference, cosmic rays, power glitches - even in
a system that has bug-free software, quality hardware, and no fallible
human anywhere, there's always a risk of faults. That is why most
serial protocols have CRC's or other checksums, and at least a basic "if
there is no reply, repeat the telegram" handler.

> I would expect a sensible UART implementation to allow for a slightly
> shorter stop bit to compensate for issues like this. But apparently this
> UART did not do so in the 1 stop bit setting. I have not tested if
> setting both ends to 2 stop bits also solved the problem.
>
>

Re: Shared Communications Bus - RS-422 or RS-485

<b5f2334f-2118-4360-b1d3-3860c04fa72cn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1181&group=comp.arch.embedded#1181

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:a0c:f00f:0:b0:4bb:6167:d338 with SMTP id z15-20020a0cf00f000000b004bb6167d338mr45498890qvk.11.1667836307711;
Mon, 07 Nov 2022 07:51:47 -0800 (PST)
X-Received: by 2002:a5b:c92:0:b0:688:436c:b2b with SMTP id i18-20020a5b0c92000000b00688436c0b2bmr48973104ybq.436.1667836307453;
Mon, 07 Nov 2022 07:51:47 -0800 (PST)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.embedded
Date: Mon, 7 Nov 2022 07:51:47 -0800 (PST)
In-Reply-To: <tk6bmk$2k36a$3@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2605:ba00:a220:106e:b1bc:e4d0:6d06:9cda;
posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 2605:ba00:a220:106e:b1bc:e4d0:6d06:9cda
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me> <b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me> <ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me> <05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me> <55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b5f2334f-2118-4360-b1d3-3860c04fa72cn@googlegroups.com>
Subject: Re: Shared Communications Bus - RS-422 or RS-485
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Mon, 07 Nov 2022 15:51:47 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 2761
 by: Rick C - Mon, 7 Nov 2022 15:51 UTC

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

Re: Shared Communications Bus - RS-422 or RS-485

<eecc4db5-f637-44ac-ada8-899a8309ded7n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1182&group=comp.arch.embedded#1182

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:ae9:ee0f:0:b0:6fa:c968:7243 with SMTP id i15-20020ae9ee0f000000b006fac9687243mr5328659qkg.176.1667837115328;
Mon, 07 Nov 2022 08:05:15 -0800 (PST)
X-Received: by 2002:a81:1202:0:b0:36a:efd4:b28d with SMTP id
2-20020a811202000000b0036aefd4b28dmr48069823yws.436.1667837115063; Mon, 07
Nov 2022 08:05:15 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border-2.nntp.ord.giganews.com!border-1.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.embedded
Date: Mon, 7 Nov 2022 08:05:14 -0800 (PST)
In-Reply-To: <nnd$6f3f0caf$4d60a848@f05e10f4dcc9e72b>
Injection-Info: google-groups.googlegroups.com; posting-host=2605:ba00:a220:106e:b1bc:e4d0:6d06:9cda;
posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 2605:ba00:a220:106e:b1bc:e4d0:6d06:9cda
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me> <b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me> <ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me> <tk3839$1nau3$2@dont-email.me>
<tk3f2t$1t3hc$1@dont-email.me> <3d9e5c38-93be-4504-b891-e0087053ebc7n@googlegroups.com>
<tk5fkb$2dl2i$2@dont-email.me> <377ca797-345a-4daf-aa84-eb0e2fb889a6n@googlegroups.com>
<nnd$6f3f0caf$4d60a848@f05e10f4dcc9e72b>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <eecc4db5-f637-44ac-ada8-899a8309ded7n@googlegroups.com>
Subject: Re: Shared Communications Bus - RS-422 or RS-485
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Mon, 07 Nov 2022 16:05:15 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 72
 by: Rick C - Mon, 7 Nov 2022 16:05 UTC

On Monday, November 7, 2022 at 6:00:09 AM UTC-4, Stef wrote:
> On 2022-11-05 Rick C wrote in comp.arch.embedded:
> > On Saturday, November 5, 2022 at 6:58:24 AM UTC-4, David Brown wrote:
> >
> >> In UART communication, this is handled at the protocol level rather than
> >> the hardware (though some UART hardware may have "idle detect" signals
> >> when more than 11 bits of high level are seen in a row). Some
> >> UART-based protocols also use a "break" signal between frames - that is
> >> a string of at least 11 bits of low level.
> >>
> >> If you do not have such pauses, and a receiver is out of step,
> >
> > You have failed to explain how a receiver would get "out of step". The receiver syncs to every character transmitted. If all characters are received, what else do you need? How does it get "out of step"?
> I have seen this happen in long messages (few kB) with no pauses between
> characters and transmitter and receiver set to 8,N,1. It seemed that the
> receiver needed the complete stop bit and then immediately saw the low
> of the next start bit. Detecting the edge when it was ready to see it,
> not when it actually happened. When the receiver is slightly slower than
> the transmitter, this caused the detection of the start bit (and
> therefor the whole character) to shift a tiny bit. This added up over
> the character stream until it eventually failed.
>
> Lowering the baud rate did not solve the issue, but inserting pauses
> after a number of chars did. What also solved it was setting the
> transmitter to 2 stop bits and the receiver to one stop bit. This was a
> one way stream and this may not be possible on a bi-directional stream.
>
> I would expect a sensible UART implementation to allow for a slightly
> shorter stop bit to compensate for issues like this. But apparently this
> UART did not do so in the 1 stop bit setting. I have not tested if
> setting both ends to 2 stop bits also solved the problem.

If a UART receiver can not properly receive a message like this, it is defective. The point of the start and stop bits are to provide the synchronization. The receiver simply needs to detect the stop be state (by sampling where the receiver thinks is the middle of the bit) and then immediately start looking for the leading edge of the next start bit. The receiver will then be synchronized to the new character bit timing and it will never slip.. That gives up to ±5% combined timing error tolerance.

If the receiver waits until a later time, such as the expected end of the received stop bit, to start looking for a start bit leading edge, it will not be able to tolerate a timing error where the transmitter is faster than the receiver making the timing tolerance unipolar, i.e. 5% rather than ±5%.

That's a receiver design flaw, or the transmitter is sending short stop bits, which you can easily see on the scope with a delayed trigger control.

You should be able to diagnose which end has the problem by connecting a different type of receiver to the stream. If a different receiver UART is able to receive the messages without fault, the problem is obviously the failing receiver.

--

Rick C.

+-++ Get 1,000 miles of free Supercharging
+-++ Tesla referral code - https://ts.la/richard11209

Re: Shared Communications Bus - RS-422 or RS-485

<97420ff2-6264-47db-9d62-232f5db75a9dn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1183&group=comp.arch.embedded#1183

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:a05:620a:2844:b0:6ef:757:2be7 with SMTP id h4-20020a05620a284400b006ef07572be7mr35109977qkp.253.1667837895454;
Mon, 07 Nov 2022 08:18:15 -0800 (PST)
X-Received: by 2002:a25:c987:0:b0:6ca:621d:af06 with SMTP id
z129-20020a25c987000000b006ca621daf06mr53067415ybf.331.1667837895143; Mon, 07
Nov 2022 08:18:15 -0800 (PST)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.embedded
Date: Mon, 7 Nov 2022 08:18:14 -0800 (PST)
In-Reply-To: <nnd$2d9aedf3$3ff05d81@29b8ea6f16782d6d>
Injection-Info: google-groups.googlegroups.com; posting-host=2605:ba00:a220:106e:b1bc:e4d0:6d06:9cda;
posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 2605:ba00:a220:106e:b1bc:e4d0:6d06:9cda
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me> <b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me> <ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me> <05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me> <55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me> <608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
<tk83ql$32rij$1@dont-email.me> <0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
<xwX9L.33736$TUR8.17072@fx17.iad> <f81aabf9-87f3-440c-b063-40461d8b0359n@googlegroups.com>
<nnd$2d9aedf3$3ff05d81@29b8ea6f16782d6d>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <97420ff2-6264-47db-9d62-232f5db75a9dn@googlegroups.com>
Subject: Re: Shared Communications Bus - RS-422 or RS-485
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Mon, 07 Nov 2022 16:18:15 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 5732
 by: Rick C - Mon, 7 Nov 2022 16:18 UTC

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

Re: Shared Communications Bus - RS-422 or RS-485

<4df2d2d6-d520-439b-8504-4912f553351bn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1184&group=comp.arch.embedded#1184

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:a05:6214:21a6:b0:4bb:85b4:fd96 with SMTP id t6-20020a05621421a600b004bb85b4fd96mr44909904qvc.28.1667838350442;
Mon, 07 Nov 2022 08:25:50 -0800 (PST)
X-Received: by 2002:a25:dacc:0:b0:6cb:866:6245 with SMTP id
n195-20020a25dacc000000b006cb08666245mr51451037ybf.473.1667838350186; Mon, 07
Nov 2022 08:25:50 -0800 (PST)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.embedded
Date: Mon, 7 Nov 2022 08:25:49 -0800 (PST)
In-Reply-To: <nnd$365bd2e6$24582938@34ecb23b658f2b03>
Injection-Info: google-groups.googlegroups.com; posting-host=2605:ba00:a220:106e:b1bc:e4d0:6d06:9cda;
posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 2605:ba00:a220:106e:b1bc:e4d0:6d06:9cda
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me> <b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me> <ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me> <05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me> <55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me> <608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
<tk83ql$32rij$1@dont-email.me> <0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
<tk96t7$3abv7$2@dont-email.me> <bf93b34c-ccdd-4178-b377-17589fd52bcen@googlegroups.com>
<nnd$4bad0da4$14a9e7ec@210656c28878494e> <54c1222e-de58-4a87-ba02-40d4ec9576a3n@googlegroups.com>
<nnd$365bd2e6$24582938@34ecb23b658f2b03>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4df2d2d6-d520-439b-8504-4912f553351bn@googlegroups.com>
Subject: Re: Shared Communications Bus - RS-422 or RS-485
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Mon, 07 Nov 2022 16:25:50 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 4405
 by: Rick C - Mon, 7 Nov 2022 16:25 UTC

On Monday, November 7, 2022 at 7:07:43 AM UTC-4, Stef wrote:
> On 2022-11-07 Rick C wrote in comp.arch.embedded:
> > On Monday, November 7, 2022 at 5:26:06 AM UTC-5, Stef wrote:
> >> On 2022-11-07 Rick C wrote in comp.arch.embedded:
> >
> > I care. Don't you?
> No, I don't. We do use FTDI chips in our designs to interface a serial
> port to USB. And we also use ready made FTDI cables. We use these chips
> and cables based on their specifications in datasheets and user guides
> etc. I have never felt the need to invesitigate how the UART/USB
> functionality was actually implemented inside the chip. What would I do
> with this knowledge? In a design I must rely on the behaviour as
> specified in the datasheet.

It's hard to imagine an engineer with no curiosity.

> > I remember when I came to the realization of why an MCU was so cost effective compared to programmable or even dedicated logic. It's because the MCU program is a FSM, using the instructions stored in the memory. These instruction are essentially logic, which is connected through the CPU logic, creating a very low cost solution to a wide variety of problems, because of the very low cost of memory compared to dedicated or programmable logic.
> >
> This is what I would call 'academic interest', and that is perfectly
> fine. And this knowledge might help you think differently about solving
> a problem in your own design. But it will make no difference in how you
> will imlement this chip (or cable) in your design.

It is very much of practical interest to me, as I design FPGAs and knowing that I can use less resources by constructing a peripheral as a CPU, is important info. The FPGA design in the UUT was pushing the capacity of the chip it was in. I was on the cusp of changing the design to a CPU centric design when it was routed at 90% utilization. This time, I'm bumping the size of the FPGA significantly, about 3x. The Gowin FPGA devices are very cost effective. I'll be able to use the hard logic and the soft CPU, both. LOL

--

Rick C.

++-+ Get 1,000 miles of free Supercharging
++-+ Tesla referral code - https://ts.la/richard11209

Re: Shared Communications Bus - RS-422 or RS-485

<nnd$437d2a7f$076c08cf@1f746f18e05c17f1>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1185&group=comp.arch.embedded#1185

 copy link   Newsgroups: comp.arch.embedded
Newsgroups: comp.arch.embedded
From: me...@this.is.invalid (Stef)
Subject: Re: Shared Communications Bus - RS-422 or RS-485
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me>
<ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me>
<05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me>
<55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me>
<608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
<tk83ql$32rij$1@dont-email.me>
<0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
<tk96t7$3abv7$2@dont-email.me>
<bf93b34c-ccdd-4178-b377-17589fd52bcen@googlegroups.com>
<nnd$4bad0da4$14a9e7ec@210656c28878494e>
<54c1222e-de58-4a87-ba02-40d4ec9576a3n@googlegroups.com>
<nnd$365bd2e6$24582938@34ecb23b658f2b03>
<4df2d2d6-d520-439b-8504-4912f553351bn@googlegroups.com>
Mail-Copies-To: nobody
User-Agent: slrn/1.0.3 (Linux)
Message-ID: <nnd$437d2a7f$076c08cf@1f746f18e05c17f1>
Organization: Newsxs
Date: Mon, 07 Nov 2022 17:57:22 +0100
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!feed.abavia.com!abe004.abavia.com!abp002.abavia.com!news.newsxs.nl!not-for-mail
Lines: 29
Injection-Date: Mon, 07 Nov 2022 17:57:22 +0100
Injection-Info: news.newsxs.nl; mail-complaints-to="abuse@newsxs.nl"
X-Received-Bytes: 2814
 by: Stef - Mon, 7 Nov 2022 16:57 UTC

On 2022-11-07 Rick C wrote in comp.arch.embedded:
> On Monday, November 7, 2022 at 7:07:43 AM UTC-4, Stef wrote:
>> On 2022-11-07 Rick C wrote in comp.arch.embedded:
>> > On Monday, November 7, 2022 at 5:26:06 AM UTC-5, Stef wrote:
>> >> On 2022-11-07 Rick C wrote in comp.arch.embedded:
>> >
>> > I care. Don't you?
>> No, I don't. We do use FTDI chips in our designs to interface a serial
>> port to USB. And we also use ready made FTDI cables. We use these chips
>> and cables based on their specifications in datasheets and user guides
>> etc. I have never felt the need to invesitigate how the UART/USB
>> functionality was actually implemented inside the chip. What would I do
>> with this knowledge? In a design I must rely on the behaviour as
>> specified in the datasheet.
>
> It's hard to imagine an engineer with no curiosity.

Yes, that's hard. But imagining an engineer who does not care about the
internal structure of every single chip he uses is a lot easier (for
me). I tend to focus my curiiosity on things that matter to me, don't
you?

--
Stef

One difference between a man and a machine is that a machine is quiet
when well oiled.

Re: Shared Communications Bus - RS-422 or RS-485

<nnd$5ce85a17$52a5bfc5@d54640d88a1ab2e6>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1186&group=comp.arch.embedded#1186

 copy link   Newsgroups: comp.arch.embedded
Newsgroups: comp.arch.embedded
From: me...@this.is.invalid (Stef)
Subject: Re: Shared Communications Bus - RS-422 or RS-485
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me>
<b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me>
<ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me>
<05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me>
<55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me>
<608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
<tk83ql$32rij$1@dont-email.me>
<0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
<xwX9L.33736$TUR8.17072@fx17.iad>
<f81aabf9-87f3-440c-b063-40461d8b0359n@googlegroups.com>
<nnd$2d9aedf3$3ff05d81@29b8ea6f16782d6d>
<97420ff2-6264-47db-9d62-232f5db75a9dn@googlegroups.com>
Mail-Copies-To: nobody
User-Agent: slrn/1.0.3 (Linux)
Message-ID: <nnd$5ce85a17$52a5bfc5@d54640d88a1ab2e6>
Organization: Newsxs
Date: Mon, 07 Nov 2022 18:20:26 +0100
Path: i2pn2.org!i2pn.org!aioe.org!news.mixmin.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!feed.abavia.com!abe004.abavia.com!abp001.abavia.com!news.newsxs.nl!not-for-mail
Lines: 91
Injection-Date: Mon, 07 Nov 2022 18:20:26 +0100
Injection-Info: news.newsxs.nl; mail-complaints-to="abuse@newsxs.nl"
X-Received-Bytes: 6682
 by: Stef - Mon, 7 Nov 2022 17:20 UTC

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

Re: Shared Communications Bus - RS-422 or RS-485

<f8930684-c183-4270-ba6c-4a64adfd11a6n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1187&group=comp.arch.embedded#1187

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:a05:6214:5182:b0:4bb:a323:4ca5 with SMTP id kl2-20020a056214518200b004bba3234ca5mr45594315qvb.121.1667843423300;
Mon, 07 Nov 2022 09:50:23 -0800 (PST)
X-Received: by 2002:a81:8b46:0:b0:373:3ba2:61ba with SMTP id
e6-20020a818b46000000b003733ba261bamr33920325ywk.508.1667843423055; Mon, 07
Nov 2022 09:50:23 -0800 (PST)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.embedded
Date: Mon, 7 Nov 2022 09:50:22 -0800 (PST)
In-Reply-To: <nnd$437d2a7f$076c08cf@1f746f18e05c17f1>
Injection-Info: google-groups.googlegroups.com; posting-host=2605:ba00:a220:106e:b1bc:e4d0:6d06:9cda;
posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 2605:ba00:a220:106e:b1bc:e4d0:6d06:9cda
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com> <tjul46$18dkn$3@dont-email.me>
<ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com> <tk09ev$1f0de$1@dont-email.me>
<tk0e27$1f1rv$1@dont-email.me> <tk0mih$1g2fh$1@dont-email.me>
<tk2fuo$1nau3$1@dont-email.me> <tk2n7g$1o0ct$1@dont-email.me>
<05989871-748b-4b08-b564-84a323418b45n@googlegroups.com> <tk5iha$2e64h$1@dont-email.me>
<55844769-5be7-47e9-b849-396e655188abn@googlegroups.com> <tk6bmk$2k36a$3@dont-email.me>
<608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com> <tk83ql$32rij$1@dont-email.me>
<0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com> <tk96t7$3abv7$2@dont-email.me>
<bf93b34c-ccdd-4178-b377-17589fd52bcen@googlegroups.com> <nnd$4bad0da4$14a9e7ec@210656c28878494e>
<54c1222e-de58-4a87-ba02-40d4ec9576a3n@googlegroups.com> <nnd$365bd2e6$24582938@34ecb23b658f2b03>
<4df2d2d6-d520-439b-8504-4912f553351bn@googlegroups.com> <nnd$437d2a7f$076c08cf@1f746f18e05c17f1>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f8930684-c183-4270-ba6c-4a64adfd11a6n@googlegroups.com>
Subject: Re: Shared Communications Bus - RS-422 or RS-485
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Mon, 07 Nov 2022 17:50:23 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 4170
 by: Rick C - Mon, 7 Nov 2022 17:50 UTC

On Monday, November 7, 2022 at 12:57:27 PM UTC-4, Stef wrote:
> On 2022-11-07 Rick C wrote in comp.arch.embedded:
> > On Monday, November 7, 2022 at 7:07:43 AM UTC-4, Stef wrote:
> >> On 2022-11-07 Rick C wrote in comp.arch.embedded:
> >> > On Monday, November 7, 2022 at 5:26:06 AM UTC-5, Stef wrote:
> >> >> On 2022-11-07 Rick C wrote in comp.arch.embedded:
> >> >
> >> > I care. Don't you?
> >> No, I don't. We do use FTDI chips in our designs to interface a serial
> >> port to USB. And we also use ready made FTDI cables. We use these chips
> >> and cables based on their specifications in datasheets and user guides
> >> etc. I have never felt the need to invesitigate how the UART/USB
> >> functionality was actually implemented inside the chip. What would I do
> >> with this knowledge? In a design I must rely on the behaviour as
> >> specified in the datasheet.
> >
> > It's hard to imagine an engineer with no curiosity.
> Yes, that's hard. But imagining an engineer who does not care about the
> internal structure of every single chip he uses is a lot easier (for
> me). I tend to focus my curiiosity on things that matter to me, don't
> you?

By definition curiosity is, "an eager desire to know or learn about something". That's not limited to things I *need* to know about. In fact, I don't limit my curiosity at all. It's a desire, not an act.

The knowledge can be very useful, if it opens new ideas for how to use these devices. In fact, I found that the majority of FTDI cables are full speed, which is much more limiting that the few Hi-speed USB cables they make. The Hi-speed cables seem to handle a lot more protocols. So now I'm back to wondering if they are implemented in a CPU based design.

--

Rick C.

+++- Get 1,000 miles of free Supercharging
+++- Tesla referral code - https://ts.la/richard11209

Re: Shared Communications Bus - RS-422 or RS-485

<0ba7bfa3-595a-4920-a8e9-54d10e973071n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1188&group=comp.arch.embedded#1188

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:ac8:4651:0:b0:3a5:977e:d042 with SMTP id f17-20020ac84651000000b003a5977ed042mr2241632qto.176.1667845603915;
Mon, 07 Nov 2022 10:26:43 -0800 (PST)
X-Received: by 2002:a25:3492:0:b0:6d1:fbac:e8e4 with SMTP id
b140-20020a253492000000b006d1fbace8e4mr22815695yba.293.1667845603694; Mon, 07
Nov 2022 10:26:43 -0800 (PST)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.embedded
Date: Mon, 7 Nov 2022 10:26:43 -0800 (PST)
In-Reply-To: <nnd$5ce85a17$52a5bfc5@d54640d88a1ab2e6>
Injection-Info: google-groups.googlegroups.com; posting-host=2605:ba00:a220:106e:b1bc:e4d0:6d06:9cda;
posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 2605:ba00:a220:106e:b1bc:e4d0:6d06:9cda
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<tjtd7g$145er$1@dont-email.me> <b4a93d7d-3d6f-4b23-86b1-f1066b6b72ebn@googlegroups.com>
<tjul46$18dkn$3@dont-email.me> <ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me> <05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me> <55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me> <608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
<tk83ql$32rij$1@dont-email.me> <0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
<xwX9L.33736$TUR8.17072@fx17.iad> <f81aabf9-87f3-440c-b063-40461d8b0359n@googlegroups.com>
<nnd$2d9aedf3$3ff05d81@29b8ea6f16782d6d> <97420ff2-6264-47db-9d62-232f5db75a9dn@googlegroups.com>
<nnd$5ce85a17$52a5bfc5@d54640d88a1ab2e6>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0ba7bfa3-595a-4920-a8e9-54d10e973071n@googlegroups.com>
Subject: Re: Shared Communications Bus - RS-422 or RS-485
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Mon, 07 Nov 2022 18:26:43 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 10660
 by: Rick C - Mon, 7 Nov 2022 18:26 UTC

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

Re: Shared Communications Bus - RS-422 or RS-485

<nnd$47f3affc$02cb14ae@0b1845cd201d6465>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=1189&group=comp.arch.embedded#1189

 copy link   Newsgroups: comp.arch.embedded
Newsgroups: comp.arch.embedded
From: me...@this.is.invalid (Stef)
Subject: Re: Shared Communications Bus - RS-422 or RS-485
References: <6b8c6b92-a2ca-4849-ba68-f03060bc41fcn@googlegroups.com>
<ec91ddbe-6777-494f-8001-cf57fc15deeen@googlegroups.com>
<tk09ev$1f0de$1@dont-email.me> <tk0e27$1f1rv$1@dont-email.me>
<tk0mih$1g2fh$1@dont-email.me> <tk2fuo$1nau3$1@dont-email.me>
<tk2n7g$1o0ct$1@dont-email.me>
<05989871-748b-4b08-b564-84a323418b45n@googlegroups.com>
<tk5iha$2e64h$1@dont-email.me>
<55844769-5be7-47e9-b849-396e655188abn@googlegroups.com>
<tk6bmk$2k36a$3@dont-email.me>
<608a7c08-1447-4483-89bc-38b9a6e6d4ean@googlegroups.com>
<tk83ql$32rij$1@dont-email.me>
<0f5f3759-7ecc-4ed4-9501-60fba54a7d48n@googlegroups.com>
<tk96t7$3abv7$2@dont-email.me>
<bf93b34c-ccdd-4178-b377-17589fd52bcen@googlegroups.com>
<nnd$4bad0da4$14a9e7ec@210656c28878494e>
<54c1222e-de58-4a87-ba02-40d4ec9576a3n@googlegroups.com>
<nnd$365bd2e6$24582938@34ecb23b658f2b03>
<4df2d2d6-d520-439b-8504-4912f553351bn@googlegroups.com>
<nnd$437d2a7f$076c08cf@1f746f18e05c17f1>
<f8930684-c183-4270-ba6c-4a64adfd11a6n@googlegroups.com>
Mail-Copies-To: nobody
User-Agent: slrn/1.0.3 (Linux)
Message-ID: <nnd$47f3affc$02cb14ae@0b1845cd201d6465>
Organization: Newsxs
Date: Mon, 07 Nov 2022 21:30:29 +0100
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!feed.abavia.com!abe006.abavia.com!abp003.abavia.com!news.newsxs.nl!not-for-mail
Lines: 40
Injection-Date: Mon, 07 Nov 2022 21:30:29 +0100
Injection-Info: news.newsxs.nl; mail-complaints-to="abuse@newsxs.nl"
X-Received-Bytes: 3476
 by: Stef - Mon, 7 Nov 2022 20:30 UTC

On 2022-11-07 Rick C wrote in comp.arch.embedded:
> On Monday, November 7, 2022 at 12:57:27 PM UTC-4, Stef wrote:
>> On 2022-11-07 Rick C wrote in comp.arch.embedded:
>> > On Monday, November 7, 2022 at 7:07:43 AM UTC-4, Stef wrote:
>> >> On 2022-11-07 Rick C wrote in comp.arch.embedded:
>> >> > On Monday, November 7, 2022 at 5:26:06 AM UTC-5, Stef wrote:
>> >> >> On 2022-11-07 Rick C wrote in comp.arch.embedded:
>> >> >
>> >> > I care. Don't you?
>> >> No, I don't. We do use FTDI chips in our designs to interface a serial
>> >> port to USB. And we also use ready made FTDI cables. We use these chips
>> >> and cables based on their specifications in datasheets and user guides
>> >> etc. I have never felt the need to invesitigate how the UART/USB
>> >> functionality was actually implemented inside the chip. What would I do
>> >> with this knowledge? In a design I must rely on the behaviour as
>> >> specified in the datasheet.
>> >
>> > It's hard to imagine an engineer with no curiosity.
>> Yes, that's hard. But imagining an engineer who does not care about the
>> internal structure of every single chip he uses is a lot easier (for
>> me). I tend to focus my curiiosity on things that matter to me, don't
>> you?
>
> By definition curiosity is, "an eager desire to know or learn about something". That's not limited to things I *need* to know about. In fact, I don't limit my curiosity at all. It's a desire, not an act.
>

Learn about something != learn about everything
Matter to me != *need* to know about

My not caring abbout the innards of a particular chip seems to let you
think I don't care about anything. But we are not discussing my
interests here, but your bus.

--
Stef

Old age is the most unexpected of things that can happen to a man.
-- Trotsky

Pages:1234
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor