[En-Nut-Discussion] detecting UART parity errors

[Harald Kipp]

Trevor,

At 14:42 17.12.2003 +0000, you wrote:

>The problem is that the parity error bit is cleared once the byte is read by
>the OS from the UART buffer register.

Because of the added receive buffer, this error handling
behaviour changed from ATmega103 -> 128. The old UART
drivers, initially written for the 103, fail to get
the error. Parity error detection is a new 128er feature
anyway.

In the new usart driver I added error checking...but I
don't throw away the character on parity errors. It's
still added to the receive buffer.
http://cvs.sourceforge.net/viewcvs.py/*checkout*/ethernut/nut/dev/usartavr.c?rev=1.1


>What I  observe is that the parity error bit is NOT set for the first byte I
>send that has a parity error but is set for the following bytes with parity
>error including the first byte that does not have a parity error. Put
>another way, the parity error bit is always one byte behind.
>Looks like I'm really reading the parity bit for the previous byte and not
>the byte has just been read.

No idea on this one. Following the datasheet, you need to read
the error first, then the data.


>Any ideas what's going on and how I can get round this ?
>Is there a way I can stop the NUT OS from reading the UART and just setup my
>own UART interrupt which would allow be to read the parity bit before
>reading the received byte ?

This one is easy. For UART0 and the old uartavr.c:

NutEnterCritical();
NutRegisterIrqHandler(&sig_UART0_RECV, MyRxComplete, dev);
NutExitCritical();

However, I'd prefer to fix parity error handling in the new driver.

No question, I'd welcome if you add (and test) the required
modifications, send it to me and I'll commit it. :-)

Regards,
Harald