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

[Matthias Ringwald]

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.