AW: AW: [En-Nut-Discussion] usartavr.c rx complete irqimprovementsuggestion

[Robert Hildebrand]

Hi Matthias,

after one weekend brain processing time there seems to be a special
situation, where your improvemnet makes a lot of sense to me. My main
objection about your solution is that we talk about an interrupt, which was
blocked for at least 10 bittimes. This I would avoid on any case.
But than I detected, that I wrote similar programs by myself, when I used a
polling loop for cheking the interrupt flag to avoid interrupt service
routines. In this case the "interrupt latency" can be higher, but there is
less overhead for the service routine and the "overall performance" is
slightly increased. I had this kind of application framework in combintaion
to improve the interrupt latency of the remaining interrupt.
I don't know exactly, how to combine this solution with the Nut/OS drivers.

If I sound to confused, maybe you contact me in german

Kind regards,

Robert


--
Dipl.-Ing. Robert Hildebrand

Fraunhofer-IMS
Abteilung System- und Anwendungstechnik
Finkenstr. 61
47057 Duisburg

Tel.: +49 203 / 3783 - 237
Fax:  +49 203 / 3783 - 277


Email: robert.hildebrand at ims.fhg.de


-----Ursprungliche Nachricht-----
Von: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Matthias
Ringwald
Gesendet: Samstag, 13. November 2004 14:52
An: Ethernut User Chat (English)
Betreff: Re: AW: [En-Nut-Discussion] usartavr.c rx complete
irqimprovementsuggestion


Hi Robert

thanks for your comments.

I'd like to clarify some things.
As I wrote, there can be up to 3 bytes in the uart rx buffer
not only one. And because of this, you'll loose a byte
only if you're way to late. So in theory, if we could
assure that an IRQ is triggered on time,  one IRQ is
enough for 2 bytes, similar to the Tx..

My problem right now, is that I can't figure out,
why I'm getting an buffer overrun although I added this
extra while loop too catch up fast.

The reason for no interrupts has to be either other interrupts
or the parts in the OS where IRQs are disabled. I'm assumeing
the thread switch part is definitely the longest of such events.
Also we have the thread's stack in external memory which slows
memory access quite a bit. I'll probably have to get the oszi
to see how long the thread switch does take.

As for other interrupts, your tip on optimizing the tx part is sounds
very good. I'll see, if this helps here, and if yes, will look to
see if this can be a runtime / compile time option for the usart
driver (which doesn't slow down the average case... :)

in my very specific case, I do transmit at the same time,
but because of some other reasons, I just can comment out
the send operation without other hassles.

Besten Gruss,
  Matthias


On 12.11.2004, at 14:10, Robert Hildebrand wrote:

> Hi Matthias,
>
> I don't like your improvement, because it is a (minor) change for the
> worse
> in most cases and an improvement in a special case, which I would try
> to
> avoid in my application.
>
> Case 1: the received character is processed "fast" and copied to the
> Nut/OS
> receive buffer. In this case, there is only one character in the
> buffer and
> your improvement meens an extra processing during interrupt.

>
> Case 2: There was no time to process the receive interrupt for at
> least 10
> bittimes (!), so you received one character while the recieve
> interrupt was
> pending. In this case your improvement is really an improvement as you
> described, but from application view I would be very afraid to miss a
> character.
>
> Sorry if I missed some advantage of your solution.
>
> During transmission of chracters it is more secure to work with pairs
> of
> characters. You can easily use the TXC-Flag to determine, that the
> UART-Transmitter is ready an write 2 Bytes into the buffer, becaus the
> first
> byte is immediately copied to the transmit shift register. Then you
> can wait
> for the next TXC intterupt. This method may lead to small gaps after
> every
> second character, but you have only one transmit interrupt for every
> two
> characters.

_______________________________________________
En-Nut-Discussion mailing list
En-Nut-Discussion at egnite.de
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion