[En-Nut-Discussion] usartavr.c rx complete irq improvement suggestion

[Matthias Ringwald]

hi

I'm still trying to improve the usaravr.c driver.
one thing I was wondering is the way the FIFO buffer of the hw usart is 
working.
After reading the atmel datasheet, I figured out, that the uart can 
buffer up to 2 chars or even 3.

Question now: how do I know how many bytes are in there?

Its actually quite simple, the rx complete bit just stays on, as long 
as there are bytes in the
queue, and gets cleared after the last byte is read.

With this 'knowledge' I was wondering, what's going on in nut's rx 
complete handler.
There, if the IRQ is triggered, one byte is read from the uart queue 
handled and then
the IRQ handler is quit.

So, if we had some longer critical sections, and there are now 2-3 
bytes ready, the
IRQ is entered, one byte is taken then the IRQ is left. After that, the 
very same
IRQ is triggered again, reads the byte, leaves the IRQ, ....
I assume this leaving and interrupting takes some time.

So, I'd like to propose to add a do while loop around the current 
handler like this:

do {
    IRQ handler
  } while ( rx complete flag set);

this does cost one bit test & jump, but can/should save time especially 
if we are late.

I tried this code and had 2 BTnodes exchange 300 MB data over the 
Bluetooth module
at 57600 baud (at 7.28 MHz clock) without errors, so I feel confident 
that this is
working and it is an improvement.

Some comments on that ?

Matthias

P.S. I'm now really adding the "blocking uart read" next, read older 
posts about it..