Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"The Street finds its own uses for technology." -- William Gibson


devel / comp.arch.embedded / Re: USART interrupt on transmission

SubjectAuthor
* USART interrupt on transmissionpozz
`* Re: USART interrupt on transmissionantispam
 `* Re: USART interrupt on transmissionpozz
  `* Re: USART interrupt on transmissionantispam
   `- Re: USART interrupt on transmissionAndrew Smallshaw

1
USART interrupt on transmission

<t1mh64$rc2$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: pozzu...@gmail.com (pozz)
Newsgroups: comp.arch.embedded
Subject: USART interrupt on transmission
Date: Sat, 26 Mar 2022 09:00:03 +0100
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <t1mh64$rc2$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 26 Mar 2022 08:00:04 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="be49934e38a3e92bedd4fe6ffa0f0dbb";
logging-data="28034"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+8iKYgKJpqf/zcvaVNfB/JslOI4p+sJ4U="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Cancel-Lock: sha1:912ELvNQPICilw4phhnlfKQZHq8=
 by: pozz - Sat, 26 Mar 2022 08:00 UTC

The UART/USART peripheral usually available in many microcontrollers
triggers a few interrupts. Two of them are DRE (data register empty, as
named in AVR documentation) and TXC (transmitter complete).

The first can be used to feed the TX FIFO even during shifting out the
last pushed data.

Documentation usually lacks details on these interrupts, for example
exactly WHEN they are triggered.
I made some tests on SAMD20 (from Atmel/Microchip) and LPC54628 (from
NXP) and found a difference.

When the UART isn't transmitting, the DRE flag is set because it is
possible to push some data on TX FIFO that is empty. When you enable DRE
interrupt, the relevant ISR is triggered immediately because the flag is
already set.
In the ISR you usually push the first data to write and return.
The first data is immediately moved to the shift register so the TX FIFO
is again empty in a very short time, so the DRE interrupt is triggered
again.

There's a subtle difference between the two MCUs above.

On SAMD21 the second DRE interrupt is triggered immediately after the
first ISR returns.

On LPC54628 the second DRE interrupt is triggered AFTER a start bit
delay. It seems the first outgoing data stays in the TX FIFO during
transmission of the start bit and moved out only after that period.
LPC54628 USART has an hardware TX FIFO, but I'm not using it because I
configured the peripheral to trigger DRE interrupt when TX FIFO is empty.

The behaviour of LPC54628 is interesting. It can be used to enable an
external transceiver after a few dummy bytes to have a short delay in
replying on the bus, allowing the sender (that could be slower) to
change its direction.
If dummy bytes are 0xFF (that appears on the wire as a start bit only),
I can enable the driver in DRE ISR when I'm ready to push the first
useful data. In this way, all the dummy bytes will not appear really on
the wire.

On SAMD20 devices this can't be done, because you would enable the
driver before the start bit of the last dummy byte, so really
transmitting it on the wire.
You need to disable DRE interrupt in the DRE ISR of the last dummy byte,
wait for TXC interrupt to enable the driver and enable again DRE
interrupt. Push all useful data in DRE ISR and, at the last, disable
again DRE and wait for TXC ISR to change again the direction of the
transceiver.

Re: USART interrupt on transmission

<t1side$feh$1@gioia.aioe.org>

  copy mid

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

  copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!aioe.org!NZ87pNe1TKxNDknVl4tZhw.user.46.165.242.91.POSTED!not-for-mail
From: antis...@math.uni.wroc.pl
Newsgroups: comp.arch.embedded
Subject: Re: USART interrupt on transmission
Date: Mon, 28 Mar 2022 14:57:50 -0000 (UTC)
Organization: Aioe.org NNTP Server
Message-ID: <t1side$feh$1@gioia.aioe.org>
References: <t1mh64$rc2$1@dont-email.me>
Injection-Info: gioia.aioe.org; logging-data="15825"; posting-host="NZ87pNe1TKxNDknVl4tZhw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: tin/2.4.5-20201224 ("Glen Albyn") (Linux/5.10.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.2
Cancel-Lock: sha1:OdoyJcT0yWgZw6EkQNOniXVJBZo=
 by: antis...@math.uni.wroc.pl - Mon, 28 Mar 2022 14:57 UTC

pozz <pozzugno@gmail.com> wrote:
> The UART/USART peripheral usually available in many microcontrollers
> triggers a few interrupts. Two of them are DRE (data register empty, as
> named in AVR documentation) and TXC (transmitter complete).
>
> The first can be used to feed the TX FIFO even during shifting out the
> last pushed data.
>
> Documentation usually lacks details on these interrupts, for example
> exactly WHEN they are triggered.
> I made some tests on SAMD20 (from Atmel/Microchip) and LPC54628 (from
> NXP) and found a difference.
>
> When the UART isn't transmitting, the DRE flag is set because it is
> possible to push some data on TX FIFO that is empty. When you enable DRE
> interrupt, the relevant ISR is triggered immediately because the flag is
> already set.
> In the ISR you usually push the first data to write and return.
> The first data is immediately moved to the shift register so the TX FIFO
> is again empty in a very short time, so the DRE interrupt is triggered
> again.
>
> There's a subtle difference between the two MCUs above.
>
> On SAMD21 the second DRE interrupt is triggered immediately after the
> first ISR returns.
>
> On LPC54628 the second DRE interrupt is triggered AFTER a start bit
> delay. It seems the first outgoing data stays in the TX FIFO during
> transmission of the start bit and moved out only after that period.
> LPC54628 USART has an hardware TX FIFO, but I'm not using it because I
> configured the peripheral to trigger DRE interrupt when TX FIFO is empty.
>
> The behaviour of LPC54628 is interesting. It can be used to enable an
> external transceiver after a few dummy bytes to have a short delay in
> replying on the bus, allowing the sender (that could be slower) to
> change its direction.
> If dummy bytes are 0xFF (that appears on the wire as a start bit only),
> I can enable the driver in DRE ISR when I'm ready to push the first
> useful data. In this way, all the dummy bytes will not appear really on
> the wire.
>
> On SAMD20 devices this can't be done, because you would enable the
> driver before the start bit of the last dummy byte, so really
> transmitting it on the wire.
> You need to disable DRE interrupt in the DRE ISR of the last dummy byte,
> wait for TXC interrupt to enable the driver and enable again DRE
> interrupt. Push all useful data in DRE ISR and, at the last, disable
> again DRE and wait for TXC ISR to change again the direction of the
> transceiver.

Thanks for interesting info. However, it is not clear why do
you want to sent dummy bytes? AFACS all you need is a little
delay and for delay I would use timer.

--
Waldek Hebisch

Re: USART interrupt on transmission

<t1sln4$qdn$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: pozzu...@gmail.com (pozz)
Newsgroups: comp.arch.embedded
Subject: Re: USART interrupt on transmission
Date: Mon, 28 Mar 2022 17:54:14 +0200
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <t1sln4$qdn$1@dont-email.me>
References: <t1mh64$rc2$1@dont-email.me> <t1side$feh$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 28 Mar 2022 15:54:12 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="bfe2124f16b85ac566f45d60de829169";
logging-data="27063"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18895qY6AqI4rdFBpozc474jgpMWpp8rcg="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Cancel-Lock: sha1:LhJEvFQpjAUpaykVr4mArmLp2OI=
In-Reply-To: <t1side$feh$1@gioia.aioe.org>
 by: pozz - Mon, 28 Mar 2022 15:54 UTC

Il 28/03/2022 16:57, antispam@math.uni.wroc.pl ha scritto:
> pozz <pozzugno@gmail.com> wrote:
>> The UART/USART peripheral usually available in many microcontrollers
>> triggers a few interrupts. Two of them are DRE (data register empty, as
>> named in AVR documentation) and TXC (transmitter complete).
>>
>> The first can be used to feed the TX FIFO even during shifting out the
>> last pushed data.
>>
>> Documentation usually lacks details on these interrupts, for example
>> exactly WHEN they are triggered.
>> I made some tests on SAMD20 (from Atmel/Microchip) and LPC54628 (from
>> NXP) and found a difference.
>>
>> When the UART isn't transmitting, the DRE flag is set because it is
>> possible to push some data on TX FIFO that is empty. When you enable DRE
>> interrupt, the relevant ISR is triggered immediately because the flag is
>> already set.
>> In the ISR you usually push the first data to write and return.
>> The first data is immediately moved to the shift register so the TX FIFO
>> is again empty in a very short time, so the DRE interrupt is triggered
>> again.
>>
>> There's a subtle difference between the two MCUs above.
>>
>> On SAMD21 the second DRE interrupt is triggered immediately after the
>> first ISR returns.
>>
>> On LPC54628 the second DRE interrupt is triggered AFTER a start bit
>> delay. It seems the first outgoing data stays in the TX FIFO during
>> transmission of the start bit and moved out only after that period.
>> LPC54628 USART has an hardware TX FIFO, but I'm not using it because I
>> configured the peripheral to trigger DRE interrupt when TX FIFO is empty.
>>
>> The behaviour of LPC54628 is interesting. It can be used to enable an
>> external transceiver after a few dummy bytes to have a short delay in
>> replying on the bus, allowing the sender (that could be slower) to
>> change its direction.
>> If dummy bytes are 0xFF (that appears on the wire as a start bit only),
>> I can enable the driver in DRE ISR when I'm ready to push the first
>> useful data. In this way, all the dummy bytes will not appear really on
>> the wire.
>>
>> On SAMD20 devices this can't be done, because you would enable the
>> driver before the start bit of the last dummy byte, so really
>> transmitting it on the wire.
>> You need to disable DRE interrupt in the DRE ISR of the last dummy byte,
>> wait for TXC interrupt to enable the driver and enable again DRE
>> interrupt. Push all useful data in DRE ISR and, at the last, disable
>> again DRE and wait for TXC ISR to change again the direction of the
>> transceiver.
>
> Thanks for interesting info. However, it is not clear why do
> you want to sent dummy bytes? AFACS all you need is a little
> delay and for delay I would use timer.

Some years ago, I read the idea to use the same UART peripheral as a
"timer" to have a short delay in the reply. It is sufficient to send
some dummy bytes, but not really.

The delay must be short (otherwise bus throughput would decrease too
much), so you need a timer peripheral. Why you want to waste a timer for
this if we can use the UART?

Re: USART interrupt on transmission

<t1ta71$2dm$1@gioia.aioe.org>

  copy mid

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

  copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!aioe.org!NZ87pNe1TKxNDknVl4tZhw.user.46.165.242.91.POSTED!not-for-mail
From: antis...@math.uni.wroc.pl
Newsgroups: comp.arch.embedded
Subject: Re: USART interrupt on transmission
Date: Mon, 28 Mar 2022 21:44:01 -0000 (UTC)
Organization: Aioe.org NNTP Server
Message-ID: <t1ta71$2dm$1@gioia.aioe.org>
References: <t1mh64$rc2$1@dont-email.me> <t1side$feh$1@gioia.aioe.org> <t1sln4$qdn$1@dont-email.me>
Injection-Info: gioia.aioe.org; logging-data="2486"; posting-host="NZ87pNe1TKxNDknVl4tZhw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: tin/2.4.5-20201224 ("Glen Albyn") (Linux/5.10.0-9-amd64 (x86_64))
Cancel-Lock: sha1:Bq/GVgmI3d9j9CUGyYwtSLIoBVA=
X-Notice: Filtered by postfilter v. 0.9.2
 by: antis...@math.uni.wroc.pl - Mon, 28 Mar 2022 21:44 UTC

pozz <pozzugno@gmail.com> wrote:
> Il 28/03/2022 16:57, antispam@math.uni.wroc.pl ha scritto:
> > pozz <pozzugno@gmail.com> wrote:
> >> The UART/USART peripheral usually available in many microcontrollers
> >> triggers a few interrupts. Two of them are DRE (data register empty, as
> >> named in AVR documentation) and TXC (transmitter complete).
> >>
> >> The first can be used to feed the TX FIFO even during shifting out the
> >> last pushed data.
> >>
> >> Documentation usually lacks details on these interrupts, for example
> >> exactly WHEN they are triggered.
> >> I made some tests on SAMD20 (from Atmel/Microchip) and LPC54628 (from
> >> NXP) and found a difference.
> >>
> >> When the UART isn't transmitting, the DRE flag is set because it is
> >> possible to push some data on TX FIFO that is empty. When you enable DRE
> >> interrupt, the relevant ISR is triggered immediately because the flag is
> >> already set.
> >> In the ISR you usually push the first data to write and return.
> >> The first data is immediately moved to the shift register so the TX FIFO
> >> is again empty in a very short time, so the DRE interrupt is triggered
> >> again.
> >>
> >> There's a subtle difference between the two MCUs above.
> >>
> >> On SAMD21 the second DRE interrupt is triggered immediately after the
> >> first ISR returns.
> >>
> >> On LPC54628 the second DRE interrupt is triggered AFTER a start bit
> >> delay. It seems the first outgoing data stays in the TX FIFO during
> >> transmission of the start bit and moved out only after that period.
> >> LPC54628 USART has an hardware TX FIFO, but I'm not using it because I
> >> configured the peripheral to trigger DRE interrupt when TX FIFO is empty.
> >>
> >> The behaviour of LPC54628 is interesting. It can be used to enable an
> >> external transceiver after a few dummy bytes to have a short delay in
> >> replying on the bus, allowing the sender (that could be slower) to
> >> change its direction.
> >> If dummy bytes are 0xFF (that appears on the wire as a start bit only),
> >> I can enable the driver in DRE ISR when I'm ready to push the first
> >> useful data. In this way, all the dummy bytes will not appear really on
> >> the wire.
> >>
> >> On SAMD20 devices this can't be done, because you would enable the
> >> driver before the start bit of the last dummy byte, so really
> >> transmitting it on the wire.
> >> You need to disable DRE interrupt in the DRE ISR of the last dummy byte,
> >> wait for TXC interrupt to enable the driver and enable again DRE
> >> interrupt. Push all useful data in DRE ISR and, at the last, disable
> >> again DRE and wait for TXC ISR to change again the direction of the
> >> transceiver.
> >
> > Thanks for interesting info. However, it is not clear why do
> > you want to sent dummy bytes? AFACS all you need is a little
> > delay and for delay I would use timer.
>
> Some years ago, I read the idea to use the same UART peripheral as a
> "timer" to have a short delay in the reply. It is sufficient to send
> some dummy bytes, but not really.
>
> The delay must be short (otherwise bus throughput would decrease too
> much), so you need a timer peripheral. Why you want to waste a timer for
> this if we can use the UART?

Well, if there is availible hardware timer, than arguably _not_
using it is a waste. If there is shortage of timers, then
multi-purposing single timer looks like better solution.

AFAICS main disadvantage of using UART is lack of portablity
and flexibility. You are tied to specific behaviour of UART,
changing to different mode (like enabling FIFO) can break
your code. And you only get multiple of character transmit
time as delay.

--
Waldek Hebisch

Re: USART interrupt on transmission

<slrnt65ol1.4uf.andrews@otaku.sdf.org>

  copy mid

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

  copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: andr...@sdf.org (Andrew Smallshaw)
Newsgroups: comp.arch.embedded
Subject: Re: USART interrupt on transmission
Date: Fri, 22 Apr 2022 17:15:13 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 44
Message-ID: <slrnt65ol1.4uf.andrews@otaku.sdf.org>
References: <t1mh64$rc2$1@dont-email.me> <t1side$feh$1@gioia.aioe.org>
<t1sln4$qdn$1@dont-email.me> <t1ta71$2dm$1@gioia.aioe.org>
Injection-Date: Fri, 22 Apr 2022 17:15:13 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="ac58651708841a5c14d920c4ff9a8199";
logging-data="23717"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18XZKlfn+8SbS7QEmzOqOCf8uTaoZa56Go="
User-Agent: slrn/1.0.3 (Patched for libcanlock3) (NetBSD)
Cancel-Lock: sha1:lnppZmyRn4W/UkKBFWxtCy6HLok=
 by: Andrew Smallshaw - Fri, 22 Apr 2022 17:15 UTC

On 2022-03-28, antispam@math.uni.wroc.pl <antispam@math.uni.wroc.pl> wrote:
> pozz <pozzugno@gmail.com> wrote:
>>
>> Some years ago, I read the idea to use the same UART peripheral as a
>> "timer" to have a short delay in the reply. It is sufficient to send
>> some dummy bytes, but not really.
>
> Well, if there is availible hardware timer, than arguably _not_
> using it is a waste. If there is shortage of timers, then
> multi-purposing single timer looks like better solution.
>
> AFAICS main disadvantage of using UART is lack of portablity
> and flexibility. You are tied to specific behaviour of UART,
> changing to different mode (like enabling FIFO) can break
> your code. And you only get multiple of character transmit
> time as delay.

I'm a bit late into this discussion but this was a standard trick
in the days of serial terminals - the first glass terminals used
either discrete logic or very primitive CPUs and thus operations
such as scrolling or even cursor movement would take longer to
execute than would be implied by the baud rate. Look up terminal
padding - where NULL bytes were inserted after certain control
codes to allow the terminal to process what it had just been sent.

Portability was in fact on the main advantages - the code knew the
bauda rate and how long processing took on a given terminal so
could compute the padding the add without external dependencies.
Important at the ttime since UNIX (in particular) didn't provide
convenient sub-second delays at first. It also benefitted from
the fact it a NULL byte had known behaviour on most terminals -
i.e. a no-op.

On an embedded device you'd have to weigh up those benefits against
the closer to the hardware nature of firmware - i.e. you have less
intervening software in the way isolating you from the hardware.
Personally I wouldn't like to say what's best except in relation
to the circumstances - like any delay you might be looking at a
timer and interrupt, a delay loop or even a couple of no-ops (or
shuffling of tasks) to enforce however long is needed.

--
Andrew Smallshaw
andrews@sdf.org

1
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor