[En-Nut-Discussion] Possible BUG in ARM usart driver or crt routines

[Coleman Brumley]

Harald,

> Many thanks, Coleman.

My pleasure.

I took the "16 pound sledge" approach of ignoring the errors because I had
to implement a protocol at the USART level.  

Unfortunately, I think I'm getting burned by this because it's now being
reported that the device is missing RS485 data which is likely due to buffer
overruns.  I don't have a moment to investigate this thoroughly, but hope to
get to it in the future.  

- Coleman


> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-
> bounces at egnite.de] On Behalf Of Harald Kipp
> Sent: Friday, September 04, 2009 5:11 AM
> To: Ethernut User Chat (English)
> Subject: Re: [En-Nut-Discussion] Possible BUG in ARM usart driver or
> crt routines
> 
> Coleman Brumley wrote:
> 
> > There are some issues with the AT91 USART error handling in that he
> error
> > flag doesn't get cleared correctly.
> >
> > I documented this, and a potential fix some time ago at
> > http://coleman.jandasoft.biz/?p=8
> 
> Many thanks, Coleman.
> 
> Indeed the flags never get cleared, neither in the hardware register
> nor
> in the global shadow variable.
> 
> As the AT91 channel status register keeps the errors until explicitly
> cleared by RSTSTA, we may be able to remove the register read from the
> interrupt routine to decrease the system's interrupt latency. We simply
> need to keep track of the ring buffer overflow.
> 
> My first attempt was to remove the shadow variable and skip reading the
> character from the receiver holding register, if the ring buffer is
> full. The next incoming character would automatically set the OVRE flag
> in the channel status register. Unfortunately this conflicts with
> XON/XOFF handshake. Thus, we still need the global variable to flag
> buffer overruns. :-(
> 
> Harald
> 
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion