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

Jean Pierre Gauthier jp.gauthier at wanadoo.fr
Fri Nov 12 19:13:30 CET 2004


 
Yes, interesting (and classical in fact in telecom devices:  "data burst" in
interrupts is the best way to achieve performances). 
My application looses some chars at 57Kb/s and none at 38Kb/s.
I am very interested to test your improvement. 
Jean Pierre

-----Message d'origine-----
De : en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] De la part de Matthias Ringwald
Envoyé : vendredi 12 novembre 2004 12:11
À : Ethernut User Chat (English)
Objet : [En-Nut-Discussion] usartavr.c rx complete irq improvementsuggestion

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..

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




More information about the En-Nut-Discussion mailing list