Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Deliver yesterday, code today, think tomorrow.


devel / comp.arch.embedded / Re: UART connection between ATSAMD20 and ATtiny4313

SubjectAuthor
* UART connection between ATSAMD20 and ATtiny4313pozz
+* Re: UART connection between ATSAMD20 and ATtiny4313David Brown
|`* Re: UART connection between ATSAMD20 and ATtiny4313pozz
| `* Re: UART connection between ATSAMD20 and ATtiny4313Grant Edwards
|  +- Re: UART connection between ATSAMD20 and ATtiny4313Rick C
|  `- Re: UART connection between ATSAMD20 and ATtiny4313pozz
+* Re: UART connection between ATSAMD20 and ATtiny4313Rick C
|`* Re: UART connection between ATSAMD20 and ATtiny4313pozz
| `* Re: UART connection between ATSAMD20 and ATtiny4313Rick C
|  +- Re: UART connection between ATSAMD20 and ATtiny4313David Brown
|  `* Re: UART connection between ATSAMD20 and ATtiny4313pozz
|   +* Re: UART connection between ATSAMD20 and ATtiny4313Andrew Smallshaw
|   |+* Re: UART connection between ATSAMD20 and ATtiny4313Rick C
|   ||`* Re: UART connection between ATSAMD20 and ATtiny4313David Brown
|   || `- Re: UART connection between ATSAMD20 and ATtiny4313Rick C
|   |`* Re: UART connection between ATSAMD20 and ATtiny4313Tauno Voipio
|   | +* Re: UART connection between ATSAMD20 and ATtiny4313Ulf Samuelsson
|   | |`- Re: UART connection between ATSAMD20 and ATtiny4313Tauno Voipio
|   | `* Re: UART connection between ATSAMD20 and ATtiny4313Rick C
|   |  +* Re: UART connection between ATSAMD20 and ATtiny4313Tauno Voipio
|   |  |+* Re: UART connection between ATSAMD20 and ATtiny4313Ulf Samuelsson
|   |  ||`- Re: UART connection between ATSAMD20 and ATtiny4313Tauno Voipio
|   |  |`* Re: UART connection between ATSAMD20 and ATtiny4313Rick C
|   |  | `- Re: UART connection between ATSAMD20 and ATtiny4313Rick C
|   |  `* Re: UART connection between ATSAMD20 and ATtiny4313David Brown
|   |   `* Re: UART connection between ATSAMD20 and ATtiny4313Rick C
|   |    `* Re: UART connection between ATSAMD20 and ATtiny4313David Brown
|   |     `- Re: UART connection between ATSAMD20 and ATtiny4313Rick C
|   `* Re: UART connection between ATSAMD20 and ATtiny4313Rick C
|    `* Re: UART connection between ATSAMD20 and ATtiny4313David Brown
|     `* Re: UART connection between ATSAMD20 and ATtiny4313Rick C
|      `- Re: UART connection between ATSAMD20 and ATtiny4313David Brown
`* Re: UART connection between ATSAMD20 and ATtiny4313pozz
 `* Re: UART connection between ATSAMD20 and ATtiny4313Rick C
  `* Re: UART connection between ATSAMD20 and ATtiny4313pozz
   +* Re: UART connection between ATSAMD20 and ATtiny4313David Brown
   |`* Re: UART connection between ATSAMD20 and ATtiny4313pozz
   | +* Re: UART connection between ATSAMD20 and ATtiny4313David Brown
   | |`* Re: UART connection between ATSAMD20 and ATtiny4313pozz
   | | +* Re: UART connection between ATSAMD20 and ATtiny4313Dimiter_Popoff
   | | |`- Re: UART connection between ATSAMD20 and ATtiny4313pozz
   | | `* Re: UART connection between ATSAMD20 and ATtiny4313Rick C
   | |  `* Re: UART connection between ATSAMD20 and ATtiny4313pozz
   | |   `* Re: UART connection between ATSAMD20 and ATtiny4313David Brown
   | |    `- Re: UART connection between ATSAMD20 and ATtiny4313pozz
   | `* Re: UART connection between ATSAMD20 and ATtiny4313Grant Edwards
   |  `* Re: UART connection between ATSAMD20 and ATtiny4313pozz
   |   `* Re: UART connection between ATSAMD20 and ATtiny4313Rick C
   |    +* Re: UART connection between ATSAMD20 and ATtiny4313David Brown
   |    |`- Re: UART connection between ATSAMD20 and ATtiny4313Dimiter_Popoff
   |    `* Re: UART connection between ATSAMD20 and ATtiny4313pozz
   |     +* Re: UART connection between ATSAMD20 and ATtiny4313Grant Edwards
   |     |`* Re: UART connection between ATSAMD20 and ATtiny4313pozz
   |     | +* Re: UART connection between ATSAMD20 and ATtiny4313Rick C
   |     | |`* Re: UART connection between ATSAMD20 and ATtiny4313pozz
   |     | | `* Re: UART connection between ATSAMD20 and ATtiny4313Rick C
   |     | |  `- Re: UART connection between ATSAMD20 and ATtiny4313pozz
   |     | `* Re: UART connection between ATSAMD20 and ATtiny4313Grant Edwards
   |     |  `- Re: UART connection between ATSAMD20 and ATtiny4313pozz
   |     `* Re: UART connection between ATSAMD20 and ATtiny4313Rick C
   |      `* Re: UART connection between ATSAMD20 and ATtiny4313pozz
   |       `* Re: UART connection between ATSAMD20 and ATtiny4313Rick C
   |        `* Re: UART connection between ATSAMD20 and ATtiny4313pozz
   |         +- Re: UART connection between ATSAMD20 and ATtiny4313Grant Edwards
   |         `- Re: UART connection between ATSAMD20 and ATtiny4313Rick C
   `* Re: UART connection between ATSAMD20 and ATtiny4313Rick C
    `- Re: UART connection between ATSAMD20 and ATtiny4313pozz

Pages:123
UART connection between ATSAMD20 and ATtiny4313

<u2be3n$1a5nq$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: pozzu...@gmail.com (pozz)
Newsgroups: comp.arch.embedded
Subject: UART connection between ATSAMD20 and ATtiny4313
Date: Wed, 26 Apr 2023 16:56:55 +0200
Organization: A noiseless patient Spider
Lines: 14
Message-ID: <u2be3n$1a5nq$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 26 Apr 2023 14:56:55 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="9d51b577305fcad2e6dd16c693f84533";
logging-data="1382138"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+wMl9wdXYb4hDshu08EyRsqyIAYBQjBos="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.10.0
Cancel-Lock: sha1:MjHVbOhYgwD2wQ/DbEkWi+ieIsg=
 by: pozz - Wed, 26 Apr 2023 14:56 UTC

I'd like to use async UART to let these MCUs communicate.
The protocol will be request-response with the request generated by the
SAM MCU. The baudrate will be 38400bps.

I'd like to use internal oscillator of ATtiny4313, while the SAM will
use an external 32.768kHz crystal (that is multiplied by internal PLL to
reach 48MHz).

I'm not sure if this scenario can work well. My concerns are related to
the internal oscillator of ATtiny4313 that hasn't a good accuracy over
temperature and life.

The tiny MCU will be supplied by 3.3V and its temperature will be in the
range 0-80°C.

Re: UART connection between ATSAMD20 and ATtiny4313

<u2bhl1$1em9g$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
Date: Wed, 26 Apr 2023 17:57:21 +0200
Organization: A noiseless patient Spider
Lines: 23
Message-ID: <u2bhl1$1em9g$1@dont-email.me>
References: <u2be3n$1a5nq$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 26 Apr 2023 15:57:22 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="5aaf490b838c73f16b64a3a21ba3af07";
logging-data="1530160"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+pOwNHgYY/TDPvBwITlVe4ph2U7q8iQJU="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.7.1
Cancel-Lock: sha1:i/XTgyDdTZRtgkYafoT85aPdCOU=
In-Reply-To: <u2be3n$1a5nq$1@dont-email.me>
Content-Language: en-GB
 by: David Brown - Wed, 26 Apr 2023 15:57 UTC

On 26/04/2023 16:56, pozz wrote:
> I'd like to use async UART to let these MCUs communicate.
> The protocol will be request-response with the request generated by the
> SAM MCU. The baudrate will be 38400bps.
>
> I'd like to use internal oscillator of ATtiny4313, while the SAM will
> use an external 32.768kHz crystal (that is multiplied by internal PLL to
> reach 48MHz).
>
> I'm not sure if this scenario can work well. My concerns are related to
> the internal oscillator of ATtiny4313 that hasn't a good accuracy over
> temperature and life.
>
> The tiny MCU will be supplied by 3.3V and its temperature will be in the
> range 0-80°C.

The rule of thumb is a maximum of 5% total mismatch in baud rates
between the two sides. One side has a crystal and PLL, so it will be
quite close - that means you can have most of the error margin on the
other side. If the internal oscillator is within 2%, you should be
fine. If it is 5% or more, you will want to do some automatic
measurement of the rate.

Re: UART connection between ATSAMD20 and ATtiny4313

<8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:ad4:5889:0:b0:5ef:63e8:e64e with SMTP id dz9-20020ad45889000000b005ef63e8e64emr4000451qvb.7.1682526366621;
Wed, 26 Apr 2023 09:26:06 -0700 (PDT)
X-Received: by 2002:a05:620a:1088:b0:74e:4d1:8ab8 with SMTP id
g8-20020a05620a108800b0074e04d18ab8mr4564278qkk.9.1682526366327; Wed, 26 Apr
2023 09:26:06 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.embedded
Date: Wed, 26 Apr 2023 09:26:06 -0700 (PDT)
In-Reply-To: <u2be3n$1a5nq$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=73.134.219.103; posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 73.134.219.103
References: <u2be3n$1a5nq$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Wed, 26 Apr 2023 16:26:06 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Rick C - Wed, 26 Apr 2023 16:26 UTC

On Wednesday, April 26, 2023 at 10:57:01 AM UTC-4, pozz wrote:
> I'd like to use async UART to let these MCUs communicate.
> The protocol will be request-response with the request generated by the
> SAM MCU. The baudrate will be 38400bps.
>
> I'd like to use internal oscillator of ATtiny4313, while the SAM will
> use an external 32.768kHz crystal (that is multiplied by internal PLL to
> reach 48MHz).
>
> I'm not sure if this scenario can work well. My concerns are related to
> the internal oscillator of ATtiny4313 that hasn't a good accuracy over
> temperature and life.
>
> The tiny MCU will be supplied by 3.3V and its temperature will be in the
> range 0-80°C.

I don't get what your question is. You seem to understand the concepts. You don't tell us the relevant data however. What does the data sheet say about the frequency variability of the internal clock over PVT (process, voltage and temperature)? I assume you are aware that the 3.3V supply will have an accuracy and an RC clock rate can be voltage dependent. It depends on how they designed the circuit. There are techniques for removing most of the voltage dependency, if they used them.

You can always use the bit times of the SAM to adjust the bit rate on the ATtiny. That used to be part of the protocol for low data rate modems. The first characters sent were AT if I recall, which give good edges to time to measure the bit rate. At 38400 bps this might be a bit tricker, it depends on your instruction rate. A bit time is just 26 us. Will this be a software UART, or a hardware unit?

--

Rick C.

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

Re: UART connection between ATSAMD20 and ATtiny4313

<u2c27u$1hfgr$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: pozzu...@gmail.com (pozz)
Newsgroups: comp.arch.embedded
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
Date: Wed, 26 Apr 2023 22:40:29 +0200
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <u2c27u$1hfgr$1@dont-email.me>
References: <u2be3n$1a5nq$1@dont-email.me> <u2bhl1$1em9g$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 26 Apr 2023 20:40:30 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="9d51b577305fcad2e6dd16c693f84533";
logging-data="1621531"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+xutBRnHvgri11YMaO+QBJkgxVgnVwe6k="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.10.0
Cancel-Lock: sha1:62eyYuG55gbYVLWa7kMBAtKF3tg=
In-Reply-To: <u2bhl1$1em9g$1@dont-email.me>
 by: pozz - Wed, 26 Apr 2023 20:40 UTC

Il 26/04/2023 17:57, David Brown ha scritto:
> On 26/04/2023 16:56, pozz wrote:
>> I'd like to use async UART to let these MCUs communicate.
>> The protocol will be request-response with the request generated by
>> the SAM MCU. The baudrate will be 38400bps.
>>
>> I'd like to use internal oscillator of ATtiny4313, while the SAM will
>> use an external 32.768kHz crystal (that is multiplied by internal PLL
>> to reach 48MHz).
>>
>> I'm not sure if this scenario can work well. My concerns are related
>> to the internal oscillator of ATtiny4313 that hasn't a good accuracy
>> over temperature and life.
>>
>> The tiny MCU will be supplied by 3.3V and its temperature will be in
>> the range 0-80°C.
>
> The rule of thumb is a maximum of 5% total mismatch in baud rates
> between the two sides.  One side has a crystal and PLL, so it will be
> quite close - that means you can have most of the error margin on the
> other side.  If the internal oscillator is within 2%, you should be
> fine.  If it is 5% or more, you will want to do some automatic
> measurement of the rate.
>

ATtiny4313 datasheet[1] says the internal oscillator is factory
calibrated with an accuracy of +/-10% at Vcc=3V and 25°C temperature.
This accuracy can be reduced to +/-2% at a fixed voltage and a fixed
temperature with a user calibration.

I could calibrate for a fixed voltage (3.3V), but I can't fix a
temperature, because it can vary in the real application.

I tried to heat the ATtiny4313 with a heat gun and the communication
between SAM and tiny didn't stopped, but I know this isn't an exaustive
test.

[1] https://ww1.microchip.com/downloads/en/DeviceDoc/doc8246.pdf

Re: UART connection between ATSAMD20 and ATtiny4313

<u2c2eu$1hfgr$2@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: pozzu...@gmail.com (pozz)
Newsgroups: comp.arch.embedded
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
Date: Wed, 26 Apr 2023 22:44:13 +0200
Organization: A noiseless patient Spider
Lines: 35
Message-ID: <u2c2eu$1hfgr$2@dont-email.me>
References: <u2be3n$1a5nq$1@dont-email.me>
<8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 26 Apr 2023 20:44:14 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="9d51b577305fcad2e6dd16c693f84533";
logging-data="1621531"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+IcR7u2g8WZqR6M079l3+uiH4BCmLJRHw="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.10.0
Cancel-Lock: sha1:OHsnFKFceJnf1K8cHzEzb+28EPo=
In-Reply-To: <8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
 by: pozz - Wed, 26 Apr 2023 20:44 UTC

Il 26/04/2023 18:26, Rick C ha scritto:
> On Wednesday, April 26, 2023 at 10:57:01 AM UTC-4, pozz wrote:
>> I'd like to use async UART to let these MCUs communicate.
>> The protocol will be request-response with the request generated by the
>> SAM MCU. The baudrate will be 38400bps.
>>
>> I'd like to use internal oscillator of ATtiny4313, while the SAM will
>> use an external 32.768kHz crystal (that is multiplied by internal PLL to
>> reach 48MHz).
>>
>> I'm not sure if this scenario can work well. My concerns are related to
>> the internal oscillator of ATtiny4313 that hasn't a good accuracy over
>> temperature and life.
>>
>> The tiny MCU will be supplied by 3.3V and its temperature will be in the
>> range 0-80°C.
>
> I don't get what your question is. You seem to understand the concepts. You don't tell us the relevant data however. What does the data sheet say about the frequency variability of the internal clock over PVT (process, voltage and temperature)? I assume you are aware that the 3.3V supply will have an accuracy and an RC clock rate can be voltage dependent. It depends on how they designed the circuit. There are techniques for removing most of the voltage dependency, if they used them.

ATtiny4313 datasheet[1] says the internal oscillator is factory
calibrated with an accuracy of ±10% at Vcc=3V and 25°C temperature. This
accuracy can be reduced to ±2% at a fixed voltage and a fixed
temperature with a user calibration.

>
> You can always use the bit times of the SAM to adjust the bit rate on the ATtiny. That used to be part of the protocol for low data rate modems. The first characters sent were AT if I recall, which give good edges to time to measure the bit rate. At 38400 bps this might be a bit tricker, it depends on your instruction rate. A bit time is just 26 us. Will this be a software UART, or a hardware unit?
>

I will use the interal UART peripheral of ATtiny4313. I can't add too
much code, the Flash memory is almost full. I wanted to know if the
figures shown on the datasheet guarantee good communication between the
the MCUs. It seems this isn't the case.

[1] https://ww1.microchip.com/downloads/en/DeviceDoc/doc8246.pdf

Re: UART connection between ATSAMD20 and ATtiny4313

<u2c3d0$l35$1@reader2.panix.com>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!panix!.POSTED.localhost!not-for-mail
From: inva...@invalid.invalid (Grant Edwards)
Newsgroups: comp.arch.embedded
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
Date: Wed, 26 Apr 2023 21:00:16 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <u2c3d0$l35$1@reader2.panix.com>
References: <u2be3n$1a5nq$1@dont-email.me> <u2bhl1$1em9g$1@dont-email.me>
<u2c27u$1hfgr$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 26 Apr 2023 21:00:16 -0000 (UTC)
Injection-Info: reader2.panix.com; posting-host="localhost:::1";
logging-data="21605"; mail-complaints-to="abuse@panix.com"
User-Agent: slrn/1.0.3 (Linux)
 by: Grant Edwards - Wed, 26 Apr 2023 21:00 UTC

On 2023-04-26, pozz <pozzugno@gmail.com> wrote:

> ATtiny4313 datasheet[1] says the internal oscillator is factory
> calibrated with an accuracy of +/-10% at Vcc=3V and 25°C temperature.

10% total error (combination of both ends) is pretty much right at the
limit according to the usual rule of thumb for UART receivers that
sync only on the start bit. IIRC, there used to be UART receivers that
would sync on every edge within the data "word" as well, but I don't
think that was ever very common -- and to take advantage of it, you
had to make sure your data had edges. :)

Can you spare a line for a clock and go synchronous? (Or are they
really UARTs and not USARTs?).

> This accuracy can be reduced to +/-2% at a fixed voltage and a fixed
> temperature with a user calibration.

2% is no problem at all. With a crystal on the other end, you should
be able to easily tolerate +/-5%. The requirement for a fixed
temperature, OTOH, is usually a problem.

> I could calibrate for a fixed voltage (3.3V), but I can't fix a
> temperature, because it can vary in the real application.

Does the ATtiny have an on-die temp sensor? If yes, you could try
characterizing the oscillator over temperature at 3.3V and adjusting
the baud rate divisor as the temperature changes. That get's expensive
if you have to do it on every unit during production, but if the T/F
curve is consistent enough between units, then maybe...

Re: UART connection between ATSAMD20 and ATtiny4313

<3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:a05:622a:1a90:b0:3ef:4b16:3f38 with SMTP id s16-20020a05622a1a9000b003ef4b163f38mr8323075qtc.13.1682554254342;
Wed, 26 Apr 2023 17:10:54 -0700 (PDT)
X-Received: by 2002:a05:622a:4c:b0:3e3:8bbd:b367 with SMTP id
y12-20020a05622a004c00b003e38bbdb367mr8703368qtw.7.1682554254122; Wed, 26 Apr
2023 17:10:54 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!diablo1.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: Wed, 26 Apr 2023 17:10:53 -0700 (PDT)
In-Reply-To: <u2c2eu$1hfgr$2@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=63.114.57.174; posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 63.114.57.174
References: <u2be3n$1a5nq$1@dont-email.me> <8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Thu, 27 Apr 2023 00:10:54 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 5100
 by: Rick C - Thu, 27 Apr 2023 00:10 UTC

On Wednesday, April 26, 2023 at 4:44:20 PM UTC-4, pozz wrote:
> Il 26/04/2023 18:26, Rick C ha scritto:
> > On Wednesday, April 26, 2023 at 10:57:01 AM UTC-4, pozz wrote:
> >> I'd like to use async UART to let these MCUs communicate.
> >> The protocol will be request-response with the request generated by the
> >> SAM MCU. The baudrate will be 38400bps.
> >>
> >> I'd like to use internal oscillator of ATtiny4313, while the SAM will
> >> use an external 32.768kHz crystal (that is multiplied by internal PLL to
> >> reach 48MHz).
> >>
> >> I'm not sure if this scenario can work well. My concerns are related to
> >> the internal oscillator of ATtiny4313 that hasn't a good accuracy over
> >> temperature and life.
> >>
> >> The tiny MCU will be supplied by 3.3V and its temperature will be in the
> >> range 0-80°C.
> >
> > I don't get what your question is. You seem to understand the concepts. You don't tell us the relevant data however. What does the data sheet say about the frequency variability of the internal clock over PVT (process, voltage and temperature)? I assume you are aware that the 3.3V supply will have an accuracy and an RC clock rate can be voltage dependent. It depends on how they designed the circuit. There are techniques for removing most of the voltage dependency, if they used them.
> ATtiny4313 datasheet[1] says the internal oscillator is factory
> calibrated with an accuracy of ±10% at Vcc=3V and 25°C temperature. This
> accuracy can be reduced to ±2% at a fixed voltage and a fixed
> temperature with a user calibration.

Ok, that is information. Do you have a question?

> > You can always use the bit times of the SAM to adjust the bit rate on the ATtiny. That used to be part of the protocol for low data rate modems. The first characters sent were AT if I recall, which give good edges to time to measure the bit rate. At 38400 bps this might be a bit tricker, it depends on your instruction rate. A bit time is just 26 us. Will this be a software UART, or a hardware unit?
> >
> I will use the interal UART peripheral of ATtiny4313. I can't add too
> much code, the Flash memory is almost full. I wanted to know if the
> figures shown on the datasheet guarantee good communication between the
> the MCUs. It seems this isn't the case.
>
>
> [1] https://ww1.microchip.com/downloads/en/DeviceDoc/doc8246.pdf

You point me to a data sheet. I am not reading the data sheet to do your work for you. I'm happy to discuss the information and offer advice and opinion. The info you provide above with the 2% stability if temperature and voltage are maintained and the clock calibrated, is not enough to know if this will work.

When you write, "It seems this isn't the case.", what do you base this on? What is your reasoning?

I don't think the software UART is a lot of code, but you don't need that. You need to write a routine to measure a bit time on the input to calibrate your clock to the incoming bit times. That should not be a lot of code. Translating a loop count into a bit clock setting for the UART should be a simple linear relationship, although it may involve a divide. You only need to work over a small range, so a small table lookup should be pretty close to optimal solution.

I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?

--

Rick C.

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

Re: UART connection between ATSAMD20 and ATtiny4313

<8fc93140-1821-4fc4-b848-6ec9a6b559ean@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:a05:622a:289:b0:3e1:3cc8:98b0 with SMTP id z9-20020a05622a028900b003e13cc898b0mr8160204qtw.3.1682554855227;
Wed, 26 Apr 2023 17:20:55 -0700 (PDT)
X-Received: by 2002:a05:6214:aa5:b0:5ef:43ee:61fb with SMTP id
ew5-20020a0562140aa500b005ef43ee61fbmr4503800qvb.6.1682554854065; Wed, 26 Apr
2023 17:20:54 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.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: Wed, 26 Apr 2023 17:20:53 -0700 (PDT)
In-Reply-To: <u2c3d0$l35$1@reader2.panix.com>
Injection-Info: google-groups.googlegroups.com; posting-host=63.114.57.174; posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 63.114.57.174
References: <u2be3n$1a5nq$1@dont-email.me> <u2bhl1$1em9g$1@dont-email.me>
<u2c27u$1hfgr$1@dont-email.me> <u2c3d0$l35$1@reader2.panix.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8fc93140-1821-4fc4-b848-6ec9a6b559ean@googlegroups.com>
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Thu, 27 Apr 2023 00:20:55 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 3963
 by: Rick C - Thu, 27 Apr 2023 00:20 UTC

On Wednesday, April 26, 2023 at 5:00:22 PM UTC-4, Grant Edwards wrote:
> On 2023-04-26, pozz <pozz...@gmail.com> wrote:
>
> > ATtiny4313 datasheet[1] says the internal oscillator is factory
> > calibrated with an accuracy of +/-10% at Vcc=3V and 25°C temperature.
> 10% total error (combination of both ends) is pretty much right at the
> limit according to the usual rule of thumb for UART receivers that
> sync only on the start bit.

I think you are not doing the calculation right. The limit is based on the UART trying to sample in the middle of a bit. If it gets out by a half a bit time, either way, it will sample the wrong bit. With 10 bits in the character, including start and stop bits, that puts the total error limit at about 5%. This is actually closer to 5.5% (because while it is 10 bits, it's only 9 bit times between start and stop bits), but then you need to subtract a fraction of a bit for the internal Nx clock used to sample the bit stream. So round off to 5%. That's the total error allowed, including both ends. Then there's distortion in the pulse edges. With 26 us bit times, there may be issues with asymmetric edge distortion. There has been no mention of the electrical interface.

> IIRC, there used to be UART receivers that
> would sync on every edge within the data "word" as well, but I don't
> think that was ever very common -- and to take advantage of it, you
> had to make sure your data had edges. :)
>
> Can you spare a line for a clock and go synchronous? (Or are they
> really UARTs and not USARTs?).
> > This accuracy can be reduced to +/-2% at a fixed voltage and a fixed
> > temperature with a user calibration.
> 2% is no problem at all. With a crystal on the other end, you should
> be able to easily tolerate +/-5%. The requirement for a fixed
> temperature, OTOH, is usually a problem.
> > I could calibrate for a fixed voltage (3.3V), but I can't fix a
> > temperature, because it can vary in the real application.
> Does the ATtiny have an on-die temp sensor? If yes, you could try
> characterizing the oscillator over temperature at 3.3V and adjusting
> the baud rate divisor as the temperature changes. That get's expensive
> if you have to do it on every unit during production, but if the T/F
> curve is consistent enough between units, then maybe...

Calibration, in general is expensive. But yes, a calibration curve is worse, since you need to wait for temperature to adjust.

--

Rick C.

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

Re: UART connection between ATSAMD20 and ATtiny4313

<u2d7ih$1qmgf$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
Date: Thu, 27 Apr 2023 09:17:36 +0200
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <u2d7ih$1qmgf$1@dont-email.me>
References: <u2be3n$1a5nq$1@dont-email.me>
<8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me>
<3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 27 Apr 2023 07:17:37 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="313551b1103bdb8aa7c1dea9f4424667";
logging-data="1923599"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/dslC5GBc6kpbVSIwMrTeyyOR3gS/dyuo="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.9.0
Cancel-Lock: sha1:91/ALJkdGm1e5hT8qq95Ub6zsng=
Content-Language: en-GB
In-Reply-To: <3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
 by: David Brown - Thu, 27 Apr 2023 07:17 UTC

On 27/04/2023 02:10, Rick C wrote:

> I don't think the software UART is a lot of code, but you don't need
> that. You need to write a routine to measure a bit time on the input
> to calibrate your clock to the incoming bit times. That should not
> be a lot of code. Translating a loop count into a bit clock setting
> for the UART should be a simple linear relationship, although it may
> involve a divide. You only need to work over a small range, so a
> small table lookup should be pretty close to optimal solution.
>

That's definitely one way to do it, yes.

Have the master side send a couple of 0x00 bytes before the data, and
use an interrupt on the Rx pin falling edge - when that comes in, count
the time until a rising edge is seen. If that time works out to within
10% of the nominal expected time, you are calibrated and can turn off
the interrupt. Alternatively, send 0x55 bytes first and measure
multiple short periods. There will be some details to work out,
depending on the what you are sending, the type of noise you expect, how
often you need to re-calibrate, etc. You are making a software
equivalent to a PLL.

There's no need for a lookup table here (unless I've got my calculations
upside down!). The more cycles you count for the incoming trainer
characters, the bigger the UART divider value you need. That means your
divisions will be done with constant values, and the compiler will turn
those into multiplies.

An alternative is trial and error. If your clock source is ±10%, and
you need to get within ±2%, start your UART at the nominally correct
baud rate. If you don't receive error-free telegrams within a timeout,
go 2% faster. Keep adding 2%, stepping from +10% to -10%, until you hit
a baud rate that works.

You can get even fancier here by figuring out the lowest and highest
rates that work, then picking their average to get the best value.

Re: UART connection between ATSAMD20 and ATtiny4313

<u2dav8$1q74u$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: pozzu...@gmail.com (pozz)
Newsgroups: comp.arch.embedded
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
Date: Thu, 27 Apr 2023 10:15:36 +0200
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <u2dav8$1q74u$1@dont-email.me>
References: <u2be3n$1a5nq$1@dont-email.me> <u2bhl1$1em9g$1@dont-email.me>
<u2c27u$1hfgr$1@dont-email.me> <u2c3d0$l35$1@reader2.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 27 Apr 2023 08:15:36 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="ca20ec59ab6207da8f821104a0caab5e";
logging-data="1907870"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ESYEr3aeU63KQi+Ft0Us4Q84TTiQBaKg="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.10.0
Cancel-Lock: sha1:jyigUzc84w9P9mWlwm3dwMSIT+Y=
In-Reply-To: <u2c3d0$l35$1@reader2.panix.com>
 by: pozz - Thu, 27 Apr 2023 08:15 UTC

Il 26/04/2023 23:00, Grant Edwards ha scritto:
> On 2023-04-26, pozz <pozzugno@gmail.com> wrote:
>
>> ATtiny4313 datasheet[1] says the internal oscillator is factory
>> calibrated with an accuracy of +/-10% at Vcc=3V and 25°C temperature.
>
> 10% total error (combination of both ends) is pretty much right at the
> limit according to the usual rule of thumb for UART receivers that
> sync only on the start bit. IIRC, there used to be UART receivers that
> would sync on every edge within the data "word" as well, but I don't
> think that was ever very common -- and to take advantage of it, you
> had to make sure your data had edges. :)
>
> Can you spare a line for a clock and go synchronous? (Or are they
> really UARTs and not USARTs?).

No, I can't. The MCUs are not on the same board and they are really
connected through RS485 half-duplex transceivers.

>> This accuracy can be reduced to +/-2% at a fixed voltage and a fixed
>> temperature with a user calibration.
>
> 2% is no problem at all. With a crystal on the other end, you should
> be able to easily tolerate +/-5%. The requirement for a fixed
> temperature, OTOH, is usually a problem.
>
>> I could calibrate for a fixed voltage (3.3V), but I can't fix a
>> temperature, because it can vary in the real application.
>
> Does the ATtiny have an on-die temp sensor? If yes, you could try
> characterizing the oscillator over temperature at 3.3V and adjusting
> the baud rate divisor as the temperature changes. That get's expensive
> if you have to do it on every unit during production, but if the T/F
> curve is consistent enough between units, then maybe...

Thank you for this suggestion, but I can't use this trick.

Re: UART connection between ATSAMD20 and ATtiny4313

<u2dbn7$1q74v$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: pozzu...@gmail.com (pozz)
Newsgroups: comp.arch.embedded
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
Date: Thu, 27 Apr 2023 10:28:23 +0200
Organization: A noiseless patient Spider
Lines: 65
Message-ID: <u2dbn7$1q74v$1@dont-email.me>
References: <u2be3n$1a5nq$1@dont-email.me>
<8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me>
<3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 27 Apr 2023 08:28:23 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="ca20ec59ab6207da8f821104a0caab5e";
logging-data="1907871"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18kD57AAM4ZJ8J9bXFv355Z5lpUnay2sKc="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.10.0
Cancel-Lock: sha1:HlayKlooRsoyy5BGfw6bZJ3dV+M=
In-Reply-To: <3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
 by: pozz - Thu, 27 Apr 2023 08:28 UTC

Il 27/04/2023 02:10, Rick C ha scritto:
> On Wednesday, April 26, 2023 at 4:44:20 PM UTC-4, pozz wrote:
>> Il 26/04/2023 18:26, Rick C ha scritto:
>>> On Wednesday, April 26, 2023 at 10:57:01 AM UTC-4, pozz wrote:
>>>> I'd like to use async UART to let these MCUs communicate.
>>>> The protocol will be request-response with the request generated by the
>>>> SAM MCU. The baudrate will be 38400bps.
>>>>
>>>> I'd like to use internal oscillator of ATtiny4313, while the SAM will
>>>> use an external 32.768kHz crystal (that is multiplied by internal PLL to
>>>> reach 48MHz).
>>>>
>>>> I'm not sure if this scenario can work well. My concerns are related to
>>>> the internal oscillator of ATtiny4313 that hasn't a good accuracy over
>>>> temperature and life.
>>>>
>>>> The tiny MCU will be supplied by 3.3V and its temperature will be in the
>>>> range 0-80°C.
>>>
>>> I don't get what your question is. You seem to understand the concepts. You don't tell us the relevant data however. What does the data sheet say about the frequency variability of the internal clock over PVT (process, voltage and temperature)? I assume you are aware that the 3.3V supply will have an accuracy and an RC clock rate can be voltage dependent. It depends on how they designed the circuit. There are techniques for removing most of the voltage dependency, if they used them.
>> ATtiny4313 datasheet[1] says the internal oscillator is factory
>> calibrated with an accuracy of ±10% at Vcc=3V and 25°C temperature. This
>> accuracy can be reduced to ±2% at a fixed voltage and a fixed
>> temperature with a user calibration.
>
> Ok, that is information. Do you have a question?
>
>
>>> You can always use the bit times of the SAM to adjust the bit rate on the ATtiny. That used to be part of the protocol for low data rate modems. The first characters sent were AT if I recall, which give good edges to time to measure the bit rate. At 38400 bps this might be a bit tricker, it depends on your instruction rate. A bit time is just 26 us. Will this be a software UART, or a hardware unit?
>>>
>> I will use the interal UART peripheral of ATtiny4313. I can't add too
>> much code, the Flash memory is almost full. I wanted to know if the
>> figures shown on the datasheet guarantee good communication between the
>> the MCUs. It seems this isn't the case.
>>
>>
>> [1] https://ww1.microchip.com/downloads/en/DeviceDoc/doc8246.pdf
>
> You point me to a data sheet. I am not reading the data sheet to do your work for you.

And I don't want you do it if you don't want. The datasheet link is
there if someone WANTS to look at it with a single click of the mouse.

> I'm happy to discuss the information and offer advice and opinion. The info you provide above with the 2% stability if temperature and voltage are maintained and the clock calibrated, is not enough to know if this will work.
>
> When you write, "It seems this isn't the case.", what do you base this on? What is your reasoning?

Because internal oscillator has an accuracy of 10% and I read that UART
receivers are usually able to decode the input signal with an error of
2-5% order.

However I tested one sample at high temperature, but the MCUs continued
communicating well.

> I don't think the software UART is a lot of code, but you don't need that. You need to write a routine to measure a bit time on the input to calibrate your clock to the incoming bit times. That should not be a lot of code. Translating a loop count into a bit clock setting for the UART should be a simple linear relationship, although it may involve a divide. You only need to work over a small range, so a small table lookup should be pretty close to optimal solution.

Ok, thanks for suggestion.

> I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?

No, this isn't an option.

Re: UART connection between ATSAMD20 and ATtiny4313

<slrnu4ku3q.qb0.andrews@sdf.org>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: andr...@sdf.org (Andrew Smallshaw)
Newsgroups: comp.arch.embedded
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
Date: Thu, 27 Apr 2023 13:28:27 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 16
Message-ID: <slrnu4ku3q.qb0.andrews@sdf.org>
References: <u2be3n$1a5nq$1@dont-email.me>
<8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me>
<3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
<u2dbn7$1q74v$1@dont-email.me>
Injection-Date: Thu, 27 Apr 2023 13:28:27 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="f28a424883a6c654cb6d80c5d800cb1c";
logging-data="2043919"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19xUzDweJ+zsajhov3PUvCSkmZiKf4LQZY="
User-Agent: slrn/1.0.3 (Patched for libcanlock3) (NetBSD)
Cancel-Lock: sha1:HKCF/fUzpjXmT05LWntFqT96O5U=
 by: Andrew Smallshaw - Thu, 27 Apr 2023 13:28 UTC

On 2023-04-27, pozz <pozzugno@gmail.com> wrote:
> Il 27/04/2023 02:10, Rick C ha scritto:
>
>> I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?
>
> No, this isn't an option.

The other option would be to adopt a Manchester-encoded (self
clocking) signal. Wouldn't be true RS485 but would pass through
transceivers and cabling at sensible baud rates. Manchester coding
is fine provided the clocks are within 2:1 of each other. You will
need to bit-bang the interface though, the UART won't handle it.

--
Andrew Smallshaw
andrews@sdf.org

Re: UART connection between ATSAMD20 and ATtiny4313

<c34969f6-84de-456f-95ed-99eb9e8500cfn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:a05:620a:10a9:b0:74e:34b:d1b8 with SMTP id h9-20020a05620a10a900b0074e034bd1b8mr333664qkk.12.1682611362391;
Thu, 27 Apr 2023 09:02:42 -0700 (PDT)
X-Received: by 2002:ac8:7d03:0:b0:3e1:3cc8:98b0 with SMTP id
g3-20020ac87d03000000b003e13cc898b0mr761541qtb.3.1682611362096; Thu, 27 Apr
2023 09:02:42 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!diablo1.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: Thu, 27 Apr 2023 09:02:41 -0700 (PDT)
In-Reply-To: <u2dbn7$1q74v$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: <u2be3n$1a5nq$1@dont-email.me> <8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me> <3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
<u2dbn7$1q74v$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c34969f6-84de-456f-95ed-99eb9e8500cfn@googlegroups.com>
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Thu, 27 Apr 2023 16:02:42 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 7137
 by: Rick C - Thu, 27 Apr 2023 16:02 UTC

On Thursday, April 27, 2023 at 4:28:29 AM UTC-4, pozz wrote:
> Il 27/04/2023 02:10, Rick C ha scritto:
> > On Wednesday, April 26, 2023 at 4:44:20 PM UTC-4, pozz wrote:
> >> Il 26/04/2023 18:26, Rick C ha scritto:
> >>> On Wednesday, April 26, 2023 at 10:57:01 AM UTC-4, pozz wrote:
> >>>> I'd like to use async UART to let these MCUs communicate.
> >>>> The protocol will be request-response with the request generated by the
> >>>> SAM MCU. The baudrate will be 38400bps.
> >>>>
> >>>> I'd like to use internal oscillator of ATtiny4313, while the SAM will
> >>>> use an external 32.768kHz crystal (that is multiplied by internal PLL to
> >>>> reach 48MHz).
> >>>>
> >>>> I'm not sure if this scenario can work well. My concerns are related to
> >>>> the internal oscillator of ATtiny4313 that hasn't a good accuracy over
> >>>> temperature and life.
> >>>>
> >>>> The tiny MCU will be supplied by 3.3V and its temperature will be in the
> >>>> range 0-80°C.
> >>>
> >>> I don't get what your question is. You seem to understand the concepts. You don't tell us the relevant data however. What does the data sheet say about the frequency variability of the internal clock over PVT (process, voltage and temperature)? I assume you are aware that the 3.3V supply will have an accuracy and an RC clock rate can be voltage dependent. It depends on how they designed the circuit. There are techniques for removing most of the voltage dependency, if they used them.
> >> ATtiny4313 datasheet[1] says the internal oscillator is factory
> >> calibrated with an accuracy of ±10% at Vcc=3V and 25°C temperature. This
> >> accuracy can be reduced to ±2% at a fixed voltage and a fixed
> >> temperature with a user calibration.
> >
> > Ok, that is information. Do you have a question?
> >
> >
> >>> You can always use the bit times of the SAM to adjust the bit rate on the ATtiny. That used to be part of the protocol for low data rate modems. The first characters sent were AT if I recall, which give good edges to time to measure the bit rate. At 38400 bps this might be a bit tricker, it depends on your instruction rate. A bit time is just 26 us. Will this be a software UART, or a hardware unit?
> >>>
> >> I will use the interal UART peripheral of ATtiny4313. I can't add too
> >> much code, the Flash memory is almost full. I wanted to know if the
> >> figures shown on the datasheet guarantee good communication between the
> >> the MCUs. It seems this isn't the case.
> >>
> >>
> >> [1] https://ww1.microchip.com/downloads/en/DeviceDoc/doc8246.pdf
> >
> > You point me to a data sheet. I am not reading the data sheet to do your work for you.
> And I don't want you do it if you don't want.

I'm glad we are in agreement. My point is you could have pointed us to any useful info in the document, or better quoted it, if there was anything you had not already quoted. I find CPU data sheets to be rather onerous to read, as they have so much data in them these days, and they don't always put timing data in the timing section, for example.

> The datasheet link is
> there if someone WANTS to look at it with a single click of the mouse.
> > I'm happy to discuss the information and offer advice and opinion. The info you provide above with the 2% stability if temperature and voltage are maintained and the clock calibrated, is not enough to know if this will work.
> >
> > When you write, "It seems this isn't the case.", what do you base this on? What is your reasoning?
> Because internal oscillator has an accuracy of 10% and I read that UART
> receivers are usually able to decode the input signal with an error of
> 2-5% order.

The 10% was for a fixed voltage and temperature without calibration. I don't recall if you are adverse to calibration. But you do have a wide temperature range which is an issue.

> However I tested one sample at high temperature, but the MCUs continued
> communicating well.

That means pretty much nothing. While testing can prove that something doesn't work, it can't prove that it does.

Instead of simply testing pass/fail, it would have been more useful to measure the clock rate, by measuring the bit rate over temperature. Get some numbers for multiple units to see what sort of spread you get.

> > I don't think the software UART is a lot of code, but you don't need that. You need to write a routine to measure a bit time on the input to calibrate your clock to the incoming bit times. That should not be a lot of code.. Translating a loop count into a bit clock setting for the UART should be a simple linear relationship, although it may involve a divide. You only need to work over a small range, so a small table lookup should be pretty close to optimal solution.
> Ok, thanks for suggestion.
> > I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?
> No, this isn't an option.

You can't add a crystal? Then the two workable choices would appear to be calibration of each unit over temperature, or a real time calibration from the data rate of the incoming data. I can't think of any other solutions. Adding the crystal seems the simple route.

--

Rick C.

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

Re: UART connection between ATSAMD20 and ATtiny4313

<fbdc8ee3-eaa9-4042-b4ca-d86f482f9d2dn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:a05:620a:13bb:b0:74d:ff80:c492 with SMTP id m27-20020a05620a13bb00b0074dff80c492mr346406qki.13.1682612533300;
Thu, 27 Apr 2023 09:22:13 -0700 (PDT)
X-Received: by 2002:a05:622a:199d:b0:3ee:be98:9fc9 with SMTP id
u29-20020a05622a199d00b003eebe989fc9mr705033qtc.3.1682612533072; Thu, 27 Apr
2023 09:22:13 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.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: Thu, 27 Apr 2023 09:22:12 -0700 (PDT)
In-Reply-To: <slrnu4ku3q.qb0.andrews@sdf.org>
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: <u2be3n$1a5nq$1@dont-email.me> <8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me> <3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
<u2dbn7$1q74v$1@dont-email.me> <slrnu4ku3q.qb0.andrews@sdf.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <fbdc8ee3-eaa9-4042-b4ca-d86f482f9d2dn@googlegroups.com>
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Thu, 27 Apr 2023 16:22:13 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 3110
 by: Rick C - Thu, 27 Apr 2023 16:22 UTC

On Thursday, April 27, 2023 at 9:28:33 AM UTC-4, Andrew Smallshaw wrote:
> On 2023-04-27, pozz <pozz...@gmail.com> wrote:
> > Il 27/04/2023 02:10, Rick C ha scritto:
> >
> >> I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?
> >
> > No, this isn't an option.
> The other option would be to adopt a Manchester-encoded (self
> clocking) signal. Wouldn't be true RS485 but would pass through
> transceivers and cabling at sensible baud rates. Manchester coding
> is fine provided the clocks are within 2:1 of each other. You will
> need to bit-bang the interface though, the UART won't handle it.

What about Manchester encoding is not RS-485? That's just an electrical interface standard, no?

But that is a great idea... if the hardware will accommodate it. Or this can be done in the UART using a faster clock and synchronous mode. Send characters with one data bit per character, the Manchester encoded bit, x0F or xF0. It would not be terribly hard to decode the data in software.. possibly. I believe you align to the transition that is always present mid-cell, then look for the presence/absence of the other transition. The OP talked about the "small" processor being program space constrained, but again, this is not a lot of code... maybe. So maybe this will be too much. But it would solve the clocking issue. Then again, so would a crystal.

--

Rick C.

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

Re: UART connection between ATSAMD20 and ATtiny4313

<u2eaq0$20si2$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: tauno.vo...@notused.fi.invalid (Tauno Voipio)
Newsgroups: comp.arch.embedded
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
Date: Thu, 27 Apr 2023 20:18:53 +0300
Organization: A noiseless patient Spider
Lines: 31
Message-ID: <u2eaq0$20si2$1@dont-email.me>
References: <u2be3n$1a5nq$1@dont-email.me>
<8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me>
<3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
<u2dbn7$1q74v$1@dont-email.me> <slrnu4ku3q.qb0.andrews@sdf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 27 Apr 2023 17:18:56 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="9dc03874a0587cb405e215cb0fda61ac";
logging-data="2126402"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+yCevEIed/WdYVfS/iGujl3Ab1GY+/nXs="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.10.0
Cancel-Lock: sha1:3JFtjr3ozHFWCRaIwmDIx/Vrovw=
In-Reply-To: <slrnu4ku3q.qb0.andrews@sdf.org>
Content-Language: en-US
 by: Tauno Voipio - Thu, 27 Apr 2023 17:18 UTC

On 27.4.2023 16.28, Andrew Smallshaw wrote:
> On 2023-04-27, pozz <pozzugno@gmail.com> wrote:
>> Il 27/04/2023 02:10, Rick C ha scritto:
>>
>>> I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?
>>
>> No, this isn't an option.
>
> The other option would be to adopt a Manchester-encoded (self
> clocking) signal. Wouldn't be true RS485 but would pass through
> transceivers and cabling at sensible baud rates. Manchester coding
> is fine provided the clocks are within 2:1 of each other. You will
> need to bit-bang the interface though, the UART won't handle it.

I doubt that the ATTiny can handle Manchester coding at the requested
bit rate, and it may be difficult for the SAM.

In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester
coded bus at 31.25 kbit/s. The trick was to innovatively use the timer
counter units of the chip. A timer used to measure the times between
pulse edges could be used to receive and decode the incoming data, and
a timer running at half of the bit rate (15.625 kbit/s) could be used
to send the data. The receiver needed to respond to interrupts at the
incoming edge rate, and the transmitter needed to respond at the
outgoing bit rate.

--

-TV

Re: UART connection between ATSAMD20 and ATtiny4313

<u2enum$233k9$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: ulf.r.sa...@gmail.com (Ulf Samuelsson)
Newsgroups: comp.arch.embedded
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
Date: Thu, 27 Apr 2023 23:03:14 +0200
Organization: eMagii
Lines: 45
Message-ID: <u2enum$233k9$1@dont-email.me>
References: <u2be3n$1a5nq$1@dont-email.me>
<8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me>
<3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
<u2dbn7$1q74v$1@dont-email.me> <slrnu4ku3q.qb0.andrews@sdf.org>
<u2eaq0$20si2$1@dont-email.me>
Reply-To: ulf.r.samuelsson@gmail.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 27 Apr 2023 21:03:19 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="e06ed78c1495380a4807241f34669d85";
logging-data="2199177"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/9koTXhKF+kJyegQJLjCiu"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.8.0
Cancel-Lock: sha1:i+yOlV9KqkU3Yycsit+f2EIrhKY=
In-Reply-To: <u2eaq0$20si2$1@dont-email.me>
Content-Language: sv
 by: Ulf Samuelsson - Thu, 27 Apr 2023 21:03 UTC

Den 2023-04-27 kl. 19:18, skrev Tauno Voipio:
> On 27.4.2023 16.28, Andrew Smallshaw wrote:
>> On 2023-04-27, pozz <pozzugno@gmail.com> wrote:
>>> Il 27/04/2023 02:10, Rick C ha scritto:
>>>
>>>> I don't see where you have a choice, unless you want to add a
>>>> crystal to the ATtiny. Can the SAM chip send a clock?  You can use
>>>> an SPI port instead of a UART, or just send a clock to use for the
>>>> bit rate clock in the UART?
>>>
>>> No, this isn't an option.
>>
>> The other option would be to adopt a Manchester-encoded (self
>> clocking) signal.  Wouldn't be true RS485 but would pass through
>> transceivers and cabling at sensible baud rates.  Manchester coding
>> is fine provided the clocks are within 2:1 of each other.  You will
>> need to bit-bang the interface though, the UART won't handle it.
>
>
> I doubt that the ATTiny can handle Manchester coding at the requested
> bit rate, and it may be difficult for the SAM.

Atmel implemented Manchester Coding in the SAM7 USART (My proposal)
but the SAMD20 has a "SERCOM" module without Manchester Coding.
I would look into the event system.

The tiny will have to do it in S/W.
/Ulf

>
> In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester
> coded bus at 31.25 kbit/s. The trick was to innovatively use the timer
> counter units of the chip. A timer used to measure the times between
> pulse edges could be used to receive and decode the incoming data, and
> a timer running at half of the bit rate (15.625 kbit/s) could be used
> to send the data. The receiver needed to respond to interrupts at the
> incoming edge rate, and the transmitter needed to respond at the
> outgoing bit rate.
>

The SAM4E USART supports Manchester Coding in H/W.
The SAM4E UART does not.

/Ulf

Re: UART connection between ATSAMD20 and ATtiny4313

<18a1c260-3763-441c-bb3f-586ff27ce555n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:ac8:5841:0:b0:3bf:b9d9:675f with SMTP id h1-20020ac85841000000b003bfb9d9675fmr1286131qth.10.1682642709890;
Thu, 27 Apr 2023 17:45:09 -0700 (PDT)
X-Received: by 2002:a05:622a:24b:b0:3ec:8ffc:e232 with SMTP id
c11-20020a05622a024b00b003ec8ffce232mr1326078qtx.7.1682642709656; Thu, 27 Apr
2023 17:45:09 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer03.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: Thu, 27 Apr 2023 17:45:09 -0700 (PDT)
In-Reply-To: <u2eaq0$20si2$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: <u2be3n$1a5nq$1@dont-email.me> <8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me> <3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
<u2dbn7$1q74v$1@dont-email.me> <slrnu4ku3q.qb0.andrews@sdf.org> <u2eaq0$20si2$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <18a1c260-3763-441c-bb3f-586ff27ce555n@googlegroups.com>
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Fri, 28 Apr 2023 00:45:09 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 3415
 by: Rick C - Fri, 28 Apr 2023 00:45 UTC

On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote:
> On 27.4.2023 16.28, Andrew Smallshaw wrote:
> > On 2023-04-27, pozz <pozz...@gmail.com> wrote:
> >> Il 27/04/2023 02:10, Rick C ha scritto:
> >>
> >>> I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?
> >>
> >> No, this isn't an option.
> >
> > The other option would be to adopt a Manchester-encoded (self
> > clocking) signal. Wouldn't be true RS485 but would pass through
> > transceivers and cabling at sensible baud rates. Manchester coding
> > is fine provided the clocks are within 2:1 of each other. You will
> > need to bit-bang the interface though, the UART won't handle it.
> I doubt that the ATTiny can handle Manchester coding at the requested
> bit rate, and it may be difficult for the SAM.
>
> In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester
> coded bus at 31.25 kbit/s. The trick was to innovatively use the timer
> counter units of the chip. A timer used to measure the times between
> pulse edges could be used to receive and decode the incoming data, and
> a timer running at half of the bit rate (15.625 kbit/s) could be used
> to send the data. The receiver needed to respond to interrupts at the
> incoming edge rate, and the transmitter needed to respond at the
> outgoing bit rate.

That's if the entire job is handled in software, perhaps. The USART can be used to send the bits as characters at the transmitter. A USART can be used to handle the reception with software seeking edges. I don't think that would be a huge burden at 38.4 kbps. But then, I'm more used to FPGA work..

--

Rick C.

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

Re: UART connection between ATSAMD20 and ATtiny4313

<u2fqqi$2bi76$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: tauno.vo...@notused.fi.invalid (Tauno Voipio)
Newsgroups: comp.arch.embedded
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
Date: Fri, 28 Apr 2023 09:58:24 +0300
Organization: A noiseless patient Spider
Lines: 56
Message-ID: <u2fqqi$2bi76$1@dont-email.me>
References: <u2be3n$1a5nq$1@dont-email.me>
<8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me>
<3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
<u2dbn7$1q74v$1@dont-email.me> <slrnu4ku3q.qb0.andrews@sdf.org>
<u2eaq0$20si2$1@dont-email.me> <u2enum$233k9$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 28 Apr 2023 06:58:26 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="98efc64cba83babeebd20a9b19d16b12";
logging-data="2476262"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+JscEO3JBAy7ZN5Mw5uqmFp2ljuuH9fjg="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.10.0
Cancel-Lock: sha1:yd7+ULRufBXebAfNuNdZBHrPwpU=
In-Reply-To: <u2enum$233k9$1@dont-email.me>
Content-Language: en-US
 by: Tauno Voipio - Fri, 28 Apr 2023 06:58 UTC

On 28.4.2023 0.03, Ulf Samuelsson wrote:
> Den 2023-04-27 kl. 19:18, skrev Tauno Voipio:
>> On 27.4.2023 16.28, Andrew Smallshaw wrote:
>>> On 2023-04-27, pozz <pozzugno@gmail.com> wrote:
>>>> Il 27/04/2023 02:10, Rick C ha scritto:
>>>>
>>>>> I don't see where you have a choice, unless you want to add a
>>>>> crystal to the ATtiny. Can the SAM chip send a clock?  You can use
>>>>> an SPI port instead of a UART, or just send a clock to use for the
>>>>> bit rate clock in the UART?
>>>>
>>>> No, this isn't an option.
>>>
>>> The other option would be to adopt a Manchester-encoded (self
>>> clocking) signal.  Wouldn't be true RS485 but would pass through
>>> transceivers and cabling at sensible baud rates.  Manchester coding
>>> is fine provided the clocks are within 2:1 of each other.  You will
>>> need to bit-bang the interface though, the UART won't handle it.
>>
>>
>> I doubt that the ATTiny can handle Manchester coding at the requested
>> bit rate, and it may be difficult for the SAM.
>
> Atmel implemented Manchester Coding in the SAM7 USART (My proposal)
> but the SAMD20 has a "SERCOM" module without Manchester Coding.
> I would look into the event system.
>
>
> The tiny will have to do it in S/W.
> /Ulf
>
>>
>> In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester
>> coded bus at 31.25 kbit/s. The trick was to innovatively use the timer
>> counter units of the chip. A timer used to measure the times between
>> pulse edges could be used to receive and decode the incoming data, and
>> a timer running at half of the bit rate (15.625 kbit/s) could be used
>> to send the data. The receiver needed to respond to interrupts at the
>> incoming edge rate, and the transmitter needed to respond at the
>> outgoing bit rate.
>>
>
> The SAM4E USART supports Manchester Coding in H/W.
> The SAM4E UART does not.
>
> /Ulf

The problem with the USART Manchester coder was in address markers
(intentional mis-codings). It was not possible to conform with the
markers in the IEC coding.

--

-TV

Re: UART connection between ATSAMD20 and ATtiny4313

<u2ftob$2bnd0$5@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
Date: Fri, 28 Apr 2023 09:48:27 +0200
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <u2ftob$2bnd0$5@dont-email.me>
References: <u2be3n$1a5nq$1@dont-email.me>
<8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me>
<3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
<u2dbn7$1q74v$1@dont-email.me> <slrnu4ku3q.qb0.andrews@sdf.org>
<fbdc8ee3-eaa9-4042-b4ca-d86f482f9d2dn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 28 Apr 2023 07:48:27 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="3d1097169b2902b2a75ddccb5ac1bd12";
logging-data="2481568"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Ed2djlxMqyOtUoCSrGC+CuAfwEDaAoH8="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.9.0
Cancel-Lock: sha1:9Msr4uikSGWunlfoxiqPpT/90Bk=
Content-Language: en-GB
In-Reply-To: <fbdc8ee3-eaa9-4042-b4ca-d86f482f9d2dn@googlegroups.com>
 by: David Brown - Fri, 28 Apr 2023 07:48 UTC

On 27/04/2023 18:22, Rick C wrote:
> On Thursday, April 27, 2023 at 9:28:33 AM UTC-4, Andrew Smallshaw wrote:
>> On 2023-04-27, pozz <pozz...@gmail.com> wrote:
>>> Il 27/04/2023 02:10, Rick C ha scritto:
>>>
>>>> I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?
>>>
>>> No, this isn't an option.
>> The other option would be to adopt a Manchester-encoded (self
>> clocking) signal. Wouldn't be true RS485 but would pass through
>> transceivers and cabling at sensible baud rates. Manchester coding
>> is fine provided the clocks are within 2:1 of each other. You will
>> need to bit-bang the interface though, the UART won't handle it.
>
> What about Manchester encoding is not RS-485? That's just an electrical interface standard, no?
>

Technically, you are correct. In reality, the term "RS-485" is usually
used to mean "UART signalling on an RS-485 bus" - any other kind of
signalling (such as Manchester encoding) would be specified explicitly.
It's good to be technically accurate, but also good to consider less
accurate common usage of terms.

> But that is a great idea... if the hardware will accommodate it. Or
> this can be done in the UART using a faster clock and synchronous
> mode. Send characters with one data bit per character, the
> Manchester encoded bit, x0F or xF0. It would not be terribly hard to
> decode the data in software.. possibly. I believe you align to the
> transition that is always present mid-cell, then look for the
> presence/absence of the other transition. The OP talked about the
> "small" processor being program space constrained, but again, this is
> not a lot of code... maybe. So maybe this will be too much. But it
> would solve the clocking issue. Then again, so would a crystal.
>

Not all microcontroller UARTs have synchronous modes. Receiving or
sending Manchester encoded data with a UART is fiddly because of the
start and stop bits of UART, so it is often done by bit-banging.
Whether or not that suits the OP, only he can say.

Re: UART connection between ATSAMD20 and ATtiny4313

<u2g0ur$2ci2v$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: tauno.vo...@notused.fi.invalid (Tauno Voipio)
Newsgroups: comp.arch.embedded
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
Date: Fri, 28 Apr 2023 11:43:04 +0300
Organization: A noiseless patient Spider
Lines: 80
Message-ID: <u2g0ur$2ci2v$1@dont-email.me>
References: <u2be3n$1a5nq$1@dont-email.me>
<8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me>
<3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
<u2dbn7$1q74v$1@dont-email.me> <slrnu4ku3q.qb0.andrews@sdf.org>
<u2eaq0$20si2$1@dont-email.me>
<18a1c260-3763-441c-bb3f-586ff27ce555n@googlegroups.com>
<u2fqun$2bi76$2@dont-email.me>
<e8b9660b-a169-4259-b2fd-f210b9ca322bn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 28 Apr 2023 08:43:07 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="98efc64cba83babeebd20a9b19d16b12";
logging-data="2508895"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Uv5yxekFSi4YvfLWGpPelmP20wAojtSY="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
Gecko/20100101 Thunderbird/102.10.1
Cancel-Lock: sha1:qyqb2Dg74hs5Ue8rIUJTXtbHAfM=
In-Reply-To: <e8b9660b-a169-4259-b2fd-f210b9ca322bn@googlegroups.com>
Content-Language: en-US
 by: Tauno Voipio - Fri, 28 Apr 2023 08:43 UTC

On 28.4.2023 10.21, Rick C wrote:
> On Friday, April 28, 2023 at 3:00:45 AM UTC-4, Tauno Voipio wrote:
>> On 28.4.2023 3.45, Rick C wrote:
>>> On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote:
>>>> On 27.4.2023 16.28, Andrew Smallshaw wrote:
>>>>> On 2023-04-27, pozz <pozz...@gmail.com> wrote:
>>>>>> Il 27/04/2023 02:10, Rick C ha scritto:
>>>>>>
>>>>>>> I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?
>>>>>>
>>>>>> No, this isn't an option.
>>>>>
>>>>> The other option would be to adopt a Manchester-encoded (self
>>>>> clocking) signal. Wouldn't be true RS485 but would pass through
>>>>> transceivers and cabling at sensible baud rates. Manchester coding
>>>>> is fine provided the clocks are within 2:1 of each other. You will
>>>>> need to bit-bang the interface though, the UART won't handle it.
>>>> I doubt that the ATTiny can handle Manchester coding at the requested
>>>> bit rate, and it may be difficult for the SAM.
>>>>
>>>> In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester
>>>> coded bus at 31.25 kbit/s. The trick was to innovatively use the timer
>>>> counter units of the chip. A timer used to measure the times between
>>>> pulse edges could be used to receive and decode the incoming data, and
>>>> a timer running at half of the bit rate (15.625 kbit/s) could be used
>>>> to send the data. The receiver needed to respond to interrupts at the
>>>> incoming edge rate, and the transmitter needed to respond at the
>>>> outgoing bit rate.
>>>
>>> That's if the entire job is handled in software, perhaps. The USART can be used to send the bits as characters at the transmitter. A USART can be used to handle the reception with software seeking edges. I don't think that would be a huge burden at 38.4 kbps. But then, I'm more used to FPGA work.
>> Had to bit-bang. The USART cannot create or detect IEC H1 standard
>> address marker octets.
>
> I did a Google search and this didn't return anything useful. So I don't know for certain what an IEC H1 standard address marker octet is, but if I'm specifying the waveform, rather than relying on the hardware to do the Manchester encoding, I can't see a reason why I could not transmit any given waveform. Can you point me to something that describes these marker octets?

The H1 bus is an industrial fieldbus and technical information about
it has been notoriously difficult to access.

The Manchester coding in the H1 bus is sent as current variations,
which are converted into voltage variations for receiving.

I'll show the more positive voltage with a plus sign and the less
positive voltage with a minus sign.

A state pair takes one bit time (32 us) with the change at the middle.

A data bit of '1' is sent as +-
A data bit of '0' is sent as -+

There are two intentional miscodings for delimiters:

A coding N+ is sent as ++
A coding N- is sent as --

A frame starts with a preamble of alternating 0's and 1's:

1 0 1 0 1 0 1 0 1 0

After preamble a start delimiter is sent:

1 N+ N- 1 0 N- N+ 0

The packet content follows, with most significant bit first.

After last data octet an end delimiter is sent:

1 N+ N- N+ N- 1 0 1

After the packet the transmitter is switched off, so the line
will stay halfway between the + and - states.

The processor chip Manchester coders could not be twisted to
handle the start end end delimiters correctly.

--

-TV

Re: UART connection between ATSAMD20 and ATtiny4313

<e51a8a3b-1214-40de-a362-b0c708e873d9n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:a05:620a:821a:b0:74f:b866:a0c3 with SMTP id ow26-20020a05620a821a00b0074fb866a0c3mr637012qkn.1.1682672145606;
Fri, 28 Apr 2023 01:55:45 -0700 (PDT)
X-Received: by 2002:a05:6214:1929:b0:5e6:5f7b:d1a3 with SMTP id
es9-20020a056214192900b005e65f7bd1a3mr653712qvb.2.1682672145399; Fri, 28 Apr
2023 01:55:45 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch.embedded
Date: Fri, 28 Apr 2023 01:55:45 -0700 (PDT)
In-Reply-To: <u2ftob$2bnd0$5@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: <u2be3n$1a5nq$1@dont-email.me> <8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me> <3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
<u2dbn7$1q74v$1@dont-email.me> <slrnu4ku3q.qb0.andrews@sdf.org>
<fbdc8ee3-eaa9-4042-b4ca-d86f482f9d2dn@googlegroups.com> <u2ftob$2bnd0$5@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <e51a8a3b-1214-40de-a362-b0c708e873d9n@googlegroups.com>
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Fri, 28 Apr 2023 08:55:45 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Rick C - Fri, 28 Apr 2023 08:55 UTC

On Friday, April 28, 2023 at 3:48:32 AM UTC-4, David Brown wrote:
> On 27/04/2023 18:22, Rick C wrote:
> > On Thursday, April 27, 2023 at 9:28:33 AM UTC-4, Andrew Smallshaw wrote:
> >> On 2023-04-27, pozz <pozz...@gmail.com> wrote:
> >>> Il 27/04/2023 02:10, Rick C ha scritto:
> >>>
> >>>> I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?
> >>>
> >>> No, this isn't an option.
> >> The other option would be to adopt a Manchester-encoded (self
> >> clocking) signal. Wouldn't be true RS485 but would pass through
> >> transceivers and cabling at sensible baud rates. Manchester coding
> >> is fine provided the clocks are within 2:1 of each other. You will
> >> need to bit-bang the interface though, the UART won't handle it.
> >
> > What about Manchester encoding is not RS-485? That's just an electrical interface standard, no?
> >
> Technically, you are correct. In reality, the term "RS-485" is usually
> used to mean "UART signalling on an RS-485 bus" - any other kind of
> signalling (such as Manchester encoding) would be specified explicitly.
> It's good to be technically accurate, but also good to consider less
> accurate common usage of terms.

Not technically, actually. "Wouldn't be true RS485" is a very clear statement, which happens to also be wrong, no matter how hands are waved.

> > But that is a great idea... if the hardware will accommodate it. Or
> > this can be done in the UART using a faster clock and synchronous
> > mode. Send characters with one data bit per character, the
> > Manchester encoded bit, x0F or xF0. It would not be terribly hard to
> > decode the data in software.. possibly. I believe you align to the
> > transition that is always present mid-cell, then look for the
> > presence/absence of the other transition. The OP talked about the
> > "small" processor being program space constrained, but again, this is
> > not a lot of code... maybe. So maybe this will be too much. But it
> > would solve the clocking issue. Then again, so would a crystal.
> >
> Not all microcontroller UARTs have synchronous modes.

I never said anything different.

> Receiving or
> sending Manchester encoded data with a UART is fiddly because of the
> start and stop bits of UART, so it is often done by bit-banging.
> Whether or not that suits the OP, only he can say.

It is simply not practical to send Manchester encoding with a UART... but Manchester is not the only encoding scheme that embeds a clock. Or you can roll your own. The point is, clock encoding with the data is a viable method of overcoming the lack of precision in the clock rate, which does not require bit banging an I/O pin. The encoding scheme of IRIG is a real possibility. The data bits are PWM encoded, with three values; 0.2, 0.5 and 0.8 widths for 0, 1 and a sync marker. This would fit a UART very nicely. With a distinction of symbols of 0.3 bit times, it can tolerate a lot more clock error than a typical async data stream with a start and stop bit on each character. It would also be pretty easy to decode. Align to the rising edge, and count the bits in the received data to find the falling edge. 0.1, 0.2 and 0.3 are all a zero bit. 0.4, 0.5 and 0.6 are all one bits. 0.7, 0.8 and 0.9 are all sync markers. To prevent the UART from missing anything important, set it for 7 data bits and no parity on receive. Then it always stops one bit early. Then if the timing is off by 10%, you still don't lose any data. This can be better than using a USART, actually. It does the alignment in the hardware, making the decoding simpler. It also includes a sync marker.

Yeah, I think this is a much better scheme than Manchester encoding.

--

Rick C.

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

Re: UART connection between ATSAMD20 and ATtiny4313

<u2g2i9$2cdfn$6@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: ulf.r.sa...@gmail.com (Ulf Samuelsson)
Newsgroups: comp.arch.embedded
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
Date: Fri, 28 Apr 2023 11:10:29 +0200
Organization: eMagii
Lines: 97
Message-ID: <u2g2i9$2cdfn$6@dont-email.me>
References: <u2be3n$1a5nq$1@dont-email.me>
<8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me>
<3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
<u2dbn7$1q74v$1@dont-email.me> <slrnu4ku3q.qb0.andrews@sdf.org>
<u2eaq0$20si2$1@dont-email.me>
<18a1c260-3763-441c-bb3f-586ff27ce555n@googlegroups.com>
<u2fqun$2bi76$2@dont-email.me>
<e8b9660b-a169-4259-b2fd-f210b9ca322bn@googlegroups.com>
<u2g0ur$2ci2v$1@dont-email.me>
Reply-To: ulf.r.samuelsson.invalid@gmail.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 28 Apr 2023 09:10:33 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="b452f82109ea9c6d09e4f26752b75ae5";
logging-data="2504183"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX192/4sMjLl9JcivFm/HLh85"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.8.0
Cancel-Lock: sha1:4cFmDdRx86u7GV0w44/eHB0Wbpo=
In-Reply-To: <u2g0ur$2ci2v$1@dont-email.me>
Content-Language: sv
 by: Ulf Samuelsson - Fri, 28 Apr 2023 09:10 UTC

Den 2023-04-28 kl. 10:43, skrev Tauno Voipio:
> On 28.4.2023 10.21, Rick C wrote:
>> On Friday, April 28, 2023 at 3:00:45 AM UTC-4, Tauno Voipio wrote:
>>> On 28.4.2023 3.45, Rick C wrote:
>>>> On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote:
>>>>> On 27.4.2023 16.28, Andrew Smallshaw wrote:
>>>>>> On 2023-04-27, pozz <pozz...@gmail.com> wrote:
>>>>>>> Il 27/04/2023 02:10, Rick C ha scritto:
>>>>>>>
>>>>>>>> I don't see where you have a choice, unless you want to add a
>>>>>>>> crystal to the ATtiny. Can the SAM chip send a clock? You can
>>>>>>>> use an SPI port instead of a UART, or just send a clock to use
>>>>>>>> for the bit rate clock in the UART?
>>>>>>>
>>>>>>> No, this isn't an option.
>>>>>>
>>>>>> The other option would be to adopt a Manchester-encoded (self
>>>>>> clocking) signal. Wouldn't be true RS485 but would pass through
>>>>>> transceivers and cabling at sensible baud rates. Manchester coding
>>>>>> is fine provided the clocks are within 2:1 of each other. You will
>>>>>> need to bit-bang the interface though, the UART won't handle it.
>>>>> I doubt that the ATTiny can handle Manchester coding at the requested
>>>>> bit rate, and it may be difficult for the SAM.
>>>>>
>>>>> In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester
>>>>> coded bus at 31.25 kbit/s. The trick was to innovatively use the timer
>>>>> counter units of the chip. A timer used to measure the times between
>>>>> pulse edges could be used to receive and decode the incoming data, and
>>>>> a timer running at half of the bit rate (15.625 kbit/s) could be used
>>>>> to send the data. The receiver needed to respond to interrupts at the
>>>>> incoming edge rate, and the transmitter needed to respond at the
>>>>> outgoing bit rate.
>>>>
>>>> That's if the entire job is handled in software, perhaps. The USART
>>>> can be used to send the bits as characters at the transmitter. A
>>>> USART can be used to handle the reception with software seeking
>>>> edges. I don't think that would be a huge burden at 38.4 kbps. But
>>>> then, I'm more used to FPGA work.
>>> Had to bit-bang. The USART cannot create or detect IEC H1 standard
>>> address marker octets.
>>
>> I did a Google search and this didn't return anything useful.  So I
>> don't know for certain what an IEC H1 standard address marker octet
>> is, but if I'm specifying the waveform, rather than relying on the
>> hardware to do the Manchester encoding, I can't see a reason why I
>> could not transmit any given waveform.  Can you point me to something
>> that describes these marker octets?
>
> The H1 bus is an industrial fieldbus and technical information about
> it has been notoriously difficult to access.
>
> The Manchester coding in the H1 bus is sent as current variations,
> which are converted into voltage variations for receiving.
>
> I'll show the more positive voltage with a plus sign and the less
> positive voltage with a minus sign.
>
> A state pair takes one bit time (32 us) with the change at the middle.
>
> A data bit of '1' is sent as +-
> A data bit of '0' is sent as -+
>
> There are two intentional miscodings for delimiters:
>
> A coding N+ is sent as ++
> A coding N- is sent as --
>
> A frame starts with a preamble of alternating 0's and 1's:
>
> 1 0 1 0 1 0 1 0 1 0
>
> After preamble a start delimiter is sent:
>
> 1 N+ N- 1 0 N- N+ 0
>
> The packet content follows, with most significant bit first.
>
> After last data octet an end delimiter is sent:
>
> 1 N+ N- N+ N- 1 0 1
>
> After the packet the transmitter is switched off, so the line
> will stay halfway between the + and - states.
>
> The processor chip Manchester coders could not be twisted to
> handle the start end end delimiters correctly.
>

If the bus speed is known, this packet seems overkill.
It can be used to detect the BAUD rate.

The Atmel USART is designed to use a 9-bit mode for packet data, with
the 9th bit set for addresses.

/Ulf.

Re: UART connection between ATSAMD20 and ATtiny4313

<cb66c9a4-e8a5-47c5-853c-2355fa98b182n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:a05:620a:153a:b0:746:c33f:786 with SMTP id n26-20020a05620a153a00b00746c33f0786mr668533qkk.3.1682673284933;
Fri, 28 Apr 2023 02:14:44 -0700 (PDT)
X-Received: by 2002:a05:622a:1822:b0:3ef:35e2:addb with SMTP id
t34-20020a05622a182200b003ef35e2addbmr1706026qtc.3.1682673284589; Fri, 28 Apr
2023 02:14:44 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!usenet.blueworldhosting.com!diablo1.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: Fri, 28 Apr 2023 02:14:44 -0700 (PDT)
In-Reply-To: <u2g0ur$2ci2v$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=63.114.57.174; posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 63.114.57.174
References: <u2be3n$1a5nq$1@dont-email.me> <8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me> <3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
<u2dbn7$1q74v$1@dont-email.me> <slrnu4ku3q.qb0.andrews@sdf.org>
<u2eaq0$20si2$1@dont-email.me> <18a1c260-3763-441c-bb3f-586ff27ce555n@googlegroups.com>
<u2fqun$2bi76$2@dont-email.me> <e8b9660b-a169-4259-b2fd-f210b9ca322bn@googlegroups.com>
<u2g0ur$2ci2v$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <cb66c9a4-e8a5-47c5-853c-2355fa98b182n@googlegroups.com>
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Fri, 28 Apr 2023 09:14:44 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 6506
 by: Rick C - Fri, 28 Apr 2023 09:14 UTC

On Friday, April 28, 2023 at 4:43:13 AM UTC-4, Tauno Voipio wrote:
> On 28.4.2023 10.21, Rick C wrote:
> > On Friday, April 28, 2023 at 3:00:45 AM UTC-4, Tauno Voipio wrote:
> >> On 28.4.2023 3.45, Rick C wrote:
> >>> On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote:
> >>>> On 27.4.2023 16.28, Andrew Smallshaw wrote:
> >>>>> On 2023-04-27, pozz <pozz...@gmail.com> wrote:
> >>>>>> Il 27/04/2023 02:10, Rick C ha scritto:
> >>>>>>
> >>>>>>> I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?
> >>>>>>
> >>>>>> No, this isn't an option.
> >>>>>
> >>>>> The other option would be to adopt a Manchester-encoded (self
> >>>>> clocking) signal. Wouldn't be true RS485 but would pass through
> >>>>> transceivers and cabling at sensible baud rates. Manchester coding
> >>>>> is fine provided the clocks are within 2:1 of each other. You will
> >>>>> need to bit-bang the interface though, the UART won't handle it.
> >>>> I doubt that the ATTiny can handle Manchester coding at the requested
> >>>> bit rate, and it may be difficult for the SAM.
> >>>>
> >>>> In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester
> >>>> coded bus at 31.25 kbit/s. The trick was to innovatively use the timer
> >>>> counter units of the chip. A timer used to measure the times between
> >>>> pulse edges could be used to receive and decode the incoming data, and
> >>>> a timer running at half of the bit rate (15.625 kbit/s) could be used
> >>>> to send the data. The receiver needed to respond to interrupts at the
> >>>> incoming edge rate, and the transmitter needed to respond at the
> >>>> outgoing bit rate.
> >>>
> >>> That's if the entire job is handled in software, perhaps. The USART can be used to send the bits as characters at the transmitter. A USART can be used to handle the reception with software seeking edges. I don't think that would be a huge burden at 38.4 kbps. But then, I'm more used to FPGA work.
> >> Had to bit-bang. The USART cannot create or detect IEC H1 standard
> >> address marker octets.
> >
> > I did a Google search and this didn't return anything useful. So I don't know for certain what an IEC H1 standard address marker octet is, but if I'm specifying the waveform, rather than relying on the hardware to do the Manchester encoding, I can't see a reason why I could not transmit any given waveform. Can you point me to something that describes these marker octets?
> The H1 bus is an industrial fieldbus and technical information about
> it has been notoriously difficult to access.
>
> The Manchester coding in the H1 bus is sent as current variations,
> which are converted into voltage variations for receiving.
>
> I'll show the more positive voltage with a plus sign and the less
> positive voltage with a minus sign.
>
> A state pair takes one bit time (32 us) with the change at the middle.
>
> A data bit of '1' is sent as +-
> A data bit of '0' is sent as -+
>
> There are two intentional miscodings for delimiters:
>
> A coding N+ is sent as ++
> A coding N- is sent as --
>
> A frame starts with a preamble of alternating 0's and 1's:
>
> 1 0 1 0 1 0 1 0 1 0
>
> After preamble a start delimiter is sent:
>
> 1 N+ N- 1 0 N- N+ 0
>
> The packet content follows, with most significant bit first.
>
> After last data octet an end delimiter is sent:
>
> 1 N+ N- N+ N- 1 0 1
>
> After the packet the transmitter is switched off, so the line
> will stay halfway between the + and - states.
>
> The processor chip Manchester coders could not be twisted to
> handle the start end end delimiters correctly.

Yes, my point is you can run the USART at a higher rate and send data as x0F, xF0, x00 or xFF. You can use the hardware without a hardware Manchester encoder.

Actually, I think Manchester encoding is inferior to the scheme they use in the IRIG signal (also the WWVB time broadcast). I don't know if that PWM scheme has a particular name, but it is very robust and can be implemented with a UART, so no USART required. The UART aligns to the start of the bit frame, so less work in the software. It becomes a matter of recognizing which of the 7 bit patterns are received. You really only need to look at two bit positions to distinguish the three values.

--

Rick C.

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

Re: UART connection between ATSAMD20 and ATtiny4313

<69de6ec0-f424-43c4-8cba-64e28af4ce06n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
X-Received: by 2002:a37:f516:0:b0:74f:b962:c7fb with SMTP id l22-20020a37f516000000b0074fb962c7fbmr829234qkk.0.1682673558894;
Fri, 28 Apr 2023 02:19:18 -0700 (PDT)
X-Received: by 2002:a05:622a:46:b0:3d5:bb6:9240 with SMTP id
y6-20020a05622a004600b003d50bb69240mr1646131qtw.4.1682673558451; Fri, 28 Apr
2023 02:19:18 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.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: Fri, 28 Apr 2023 02:19:18 -0700 (PDT)
In-Reply-To: <cb66c9a4-e8a5-47c5-853c-2355fa98b182n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=63.114.57.174; posting-account=I-_H_woAAAA9zzro6crtEpUAyIvzd19b
NNTP-Posting-Host: 63.114.57.174
References: <u2be3n$1a5nq$1@dont-email.me> <8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me> <3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
<u2dbn7$1q74v$1@dont-email.me> <slrnu4ku3q.qb0.andrews@sdf.org>
<u2eaq0$20si2$1@dont-email.me> <18a1c260-3763-441c-bb3f-586ff27ce555n@googlegroups.com>
<u2fqun$2bi76$2@dont-email.me> <e8b9660b-a169-4259-b2fd-f210b9ca322bn@googlegroups.com>
<u2g0ur$2ci2v$1@dont-email.me> <cb66c9a4-e8a5-47c5-853c-2355fa98b182n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <69de6ec0-f424-43c4-8cba-64e28af4ce06n@googlegroups.com>
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
From: gnuarm.d...@gmail.com (Rick C)
Injection-Date: Fri, 28 Apr 2023 09:19:18 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 6957
 by: Rick C - Fri, 28 Apr 2023 09:19 UTC

On Friday, April 28, 2023 at 5:14:48 AM UTC-4, Rick C wrote:
> On Friday, April 28, 2023 at 4:43:13 AM UTC-4, Tauno Voipio wrote:
> > On 28.4.2023 10.21, Rick C wrote:
> > > On Friday, April 28, 2023 at 3:00:45 AM UTC-4, Tauno Voipio wrote:
> > >> On 28.4.2023 3.45, Rick C wrote:
> > >>> On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote:
> > >>>> On 27.4.2023 16.28, Andrew Smallshaw wrote:
> > >>>>> On 2023-04-27, pozz <pozz...@gmail.com> wrote:
> > >>>>>> Il 27/04/2023 02:10, Rick C ha scritto:
> > >>>>>>
> > >>>>>>> I don't see where you have a choice, unless you want to add a crystal to the ATtiny. Can the SAM chip send a clock? You can use an SPI port instead of a UART, or just send a clock to use for the bit rate clock in the UART?
> > >>>>>>
> > >>>>>> No, this isn't an option.
> > >>>>>
> > >>>>> The other option would be to adopt a Manchester-encoded (self
> > >>>>> clocking) signal. Wouldn't be true RS485 but would pass through
> > >>>>> transceivers and cabling at sensible baud rates. Manchester coding
> > >>>>> is fine provided the clocks are within 2:1 of each other. You will
> > >>>>> need to bit-bang the interface though, the UART won't handle it.
> > >>>> I doubt that the ATTiny can handle Manchester coding at the requested
> > >>>> bit rate, and it may be difficult for the SAM.
> > >>>>
> > >>>> In 2016, I made a processor unit using AT91SAM4E for IEC H1 Manchester
> > >>>> coded bus at 31.25 kbit/s. The trick was to innovatively use the timer
> > >>>> counter units of the chip. A timer used to measure the times between
> > >>>> pulse edges could be used to receive and decode the incoming data, and
> > >>>> a timer running at half of the bit rate (15.625 kbit/s) could be used
> > >>>> to send the data. The receiver needed to respond to interrupts at the
> > >>>> incoming edge rate, and the transmitter needed to respond at the
> > >>>> outgoing bit rate.
> > >>>
> > >>> That's if the entire job is handled in software, perhaps. The USART can be used to send the bits as characters at the transmitter. A USART can be used to handle the reception with software seeking edges. I don't think that would be a huge burden at 38.4 kbps. But then, I'm more used to FPGA work.
> > >> Had to bit-bang. The USART cannot create or detect IEC H1 standard
> > >> address marker octets.
> > >
> > > I did a Google search and this didn't return anything useful. So I don't know for certain what an IEC H1 standard address marker octet is, but if I'm specifying the waveform, rather than relying on the hardware to do the Manchester encoding, I can't see a reason why I could not transmit any given waveform. Can you point me to something that describes these marker octets?
> > The H1 bus is an industrial fieldbus and technical information about
> > it has been notoriously difficult to access.
> >
> > The Manchester coding in the H1 bus is sent as current variations,
> > which are converted into voltage variations for receiving.
> >
> > I'll show the more positive voltage with a plus sign and the less
> > positive voltage with a minus sign.
> >
> > A state pair takes one bit time (32 us) with the change at the middle.
> >
> > A data bit of '1' is sent as +-
> > A data bit of '0' is sent as -+
> >
> > There are two intentional miscodings for delimiters:
> >
> > A coding N+ is sent as ++
> > A coding N- is sent as --
> >
> > A frame starts with a preamble of alternating 0's and 1's:
> >
> > 1 0 1 0 1 0 1 0 1 0
> >
> > After preamble a start delimiter is sent:
> >
> > 1 N+ N- 1 0 N- N+ 0
> >
> > The packet content follows, with most significant bit first.
> >
> > After last data octet an end delimiter is sent:
> >
> > 1 N+ N- N+ N- 1 0 1
> >
> > After the packet the transmitter is switched off, so the line
> > will stay halfway between the + and - states.
> >
> > The processor chip Manchester coders could not be twisted to
> > handle the start end end delimiters correctly.
> Yes, my point is you can run the USART at a higher rate and send data as x0F, xF0, x00 or xFF. You can use the hardware without a hardware Manchester encoder.
>
> Actually, I think Manchester encoding is inferior to the scheme they use in the IRIG signal (also the WWVB time broadcast). I don't know if that PWM scheme has a particular name, but it is very robust and can be implemented with a UART, so no USART required. The UART aligns to the start of the bit frame, so less work in the software. It becomes a matter of recognizing which of the 7 bit patterns are received. You really only need to look at two bit positions to distinguish the three values.

Sorry, two points to distinguish the three values encoded in the eight possible received bit patterns using a 7 bit character.

--

Rick C.

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

Re: UART connection between ATSAMD20 and ATtiny4313

<u2gfgf$2ejus$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: UART connection between ATSAMD20 and ATtiny4313
Date: Fri, 28 Apr 2023 14:51:26 +0200
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <u2gfgf$2ejus$1@dont-email.me>
References: <u2be3n$1a5nq$1@dont-email.me>
<8c53b82a-f075-4b51-98bd-792221acbe60n@googlegroups.com>
<u2c2eu$1hfgr$2@dont-email.me>
<3400c428-350a-4826-adc8-df2c6105fc8bn@googlegroups.com>
<u2dbn7$1q74v$1@dont-email.me> <slrnu4ku3q.qb0.andrews@sdf.org>
<u2eaq0$20si2$1@dont-email.me>
<18a1c260-3763-441c-bb3f-586ff27ce555n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 28 Apr 2023 12:51:27 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="3d1097169b2902b2a75ddccb5ac1bd12";
logging-data="2576348"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/asOzA4gE8i52Rkvf8mf0arkDqeZk424A="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.9.0
Cancel-Lock: sha1:QUZ7oPGD4gj7Ky1xu2Q02aXJw1Y=
In-Reply-To: <18a1c260-3763-441c-bb3f-586ff27ce555n@googlegroups.com>
Content-Language: en-GB
 by: David Brown - Fri, 28 Apr 2023 12:51 UTC

On 28/04/2023 02:45, Rick C wrote:
> On Thursday, April 27, 2023 at 1:19:01 PM UTC-4, Tauno Voipio wrote:

>> In 2016, I made a processor unit using AT91SAM4E for IEC H1
>> Manchester coded bus at 31.25 kbit/s. The trick was to innovatively
>> use the timer counter units of the chip. A timer used to measure
>> the times between pulse edges could be used to receive and decode
>> the incoming data, and a timer running at half of the bit rate
>> (15.625 kbit/s) could be used to send the data. The receiver needed
>> to respond to interrupts at the incoming edge rate, and the
>> transmitter needed to respond at the outgoing bit rate.
>
> That's if the entire job is handled in software, perhaps. The USART
> can be used to send the bits as characters at the transmitter. A
> USART can be used to handle the reception with software seeking
> edges. I don't think that would be a huge burden at 38.4 kbps. But
> then, I'm more used to FPGA work.
>

You certainly /can/ do this kind of thing in software on a Tiny.
However, it might be a challenge depending on other factors. If the
device already has high-precision timing requirements for another task,
doing two of them can get complicated. If you need to deal with a lot
of noise on the lines, that too is messy.

Pages:123
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor