[En-Nut-Discussion] usartavr driver problem/bug

[Jean Pierre Gauthier]

Hello,
I tested the CTS function yesterday (No RTS| CTS:PE7 | USART1 | TxBuffer:
2048 bytes | latest usart.h Revision 1.4  2004/11/08 18:14:09! | usart.c
Revision 1.4  | usart1avr.c  Revision 1.3   | usartavr.c  Revision 1.4   |
ICCAVR 6.31A |  Nut3.9.1 pre | Ethernut 1.3F )  

Only tested 2 hours.
My conclusions :
- CTS fonction works ONLY a moment. Good behavior on the scope at this step.
Flow is stopped quicky... 
- After this moment, usart sends bad data (or some data are lost in fact, I
don't know) OR is definitively locked.  (Especially true after the Tx buffer
becomes empty again, after strong CTS handshake...) 
- If  the test "if (rbf->rbf_cnt--)" is moved after "#ifdef UART_CTS_BIT ...
#endif" bloc (AvrUsartTxEmpty function / usartavr.c) similary to XON/XOFF
(see below), usart sends valid data again but it always locks ...
- Now, if an ioctl UART_SETWRITETIMEOUT is set at USART initialization, this
lock disappairs. (even without effective timeout in operation...) 
- On the scope, I see that CTS may be short "pulsed" and devalided during
only a few us... Hard constraint for software.
- Full hardware CTS handshake is more simple and reliable :-) Thanks to
ATMEGA128 :-(

Short (and perhaps stupid) conclusion but no explanation...
Jean Pierre




//   if (rbf->rbf_cnt--) { // ************************ REMOVED 

#ifdef UART_CTS_BIT
        /* 
         * If CTS has been disabled, we disable the transmit interrupts
         * and return without sending anything.
         */
        if (cts_sense && bit_is_set(UART_CTS_PIN, UART_CTS_BIT)) {
            cbi(UCSRnB, UDRIE);
            sbi(EIMSK, UART_CTS_BIT);
            return;
        }
#endif
     if (rbf->rbf_cnt--) { // ************************ INSERTED
        /*
         * The data sheet doesn't exactly tell us, if this bit is retained 
         * or cleared after the character has been sent out. So we do it
         * the save way.
         */









-----Message d'origine-----
De : en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] De la part de Harald Kipp
Envoyé : lundi 8 novembre 2004 21:46
À : Ethernut User Chat (English)
Objet : Re: [En-Nut-Discussion] usartavr driver problem/bug

Matthias,

this is indeed a serious problem, not only for your application.
Same as the RS232 interference caused by the toggling of the reset line
during programming. This can drive you crazy if a picky equipment like an
ATM (teller machine) is attached.

Leaving the transmitter enabled after making sure that all characters had
been sent should work.


>hm.. looking a bit more, I wonder if the usart functionality is ever
disabled.
>I see that it is implicitly activated by the setspeed call. But the 
>AvrUsartDisable function is never called from an higher layer. What 
>about disabling the usart on usart:close() ?

Sorry, but this makes no sense to me. Right now
AvrUsartDisable() is called from five places.

Disabling the UART on close may work now. But it is not clean really.
AvrUsartDeinit() is the right place, IMHO. But this is not used due to the
lack of NutDeregisterDevice().

Harald


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