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

[Robert Hildebrand]

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.

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: Freitag, 12. November 2004 12:11
An: Ethernut User Chat (English)
Betreff: [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