[ECOS] Serial buffer overrun

Scott Dattalo scott@dattalo.com
Sun Jan 12 15:43:00 GMT 2003

On Sat, 11 Jan 2003, Shannon Holland wrote:

> I'm trying to debug a serial problem I'm having with receiving data from 
> a remote system. It appears that I'm spending too much time processing 
> data on the eb40a side and hence the serial buffer is filling up and I'm 
> losing data (data comes through correctly for a while, then I start 
> getting lots of errors. If I stop the remote host, the eb40a keeps going 
> for a while before blocking).

Are you *sure* that it's an overrun and not that you're losing bytes? A 
few weeks ago you may recall that this issue was discussed. If the serial 
driver is not using the RPR register (the hardware peripheral in the 
at91r40008 that allows DMA-like streaming between the USART and RAM) then 
there's a chance that the interrupt routine will occasionally drop a byte. 
If the serial driver *does* use the RPR register, then there's a chance 
that the serial driver will loose a byte (or several...) when the receive 
pool is filled (because there's a brief instant in which the receiver has 
to be inhibited while the RPR is adjusted).

In my application, the only way to get around this byte-dropping problem 
was by implementing flow control. I chose to implement it at the software 
(i.e. protocol level) instead of hardware. (Strictly speaking, hardware 
flow control is not automatic with the at91 USART. So what I'm really 
saying for hardware flow control, is dedicate an I/O pin and call it DTR 
[or whatever] and drive it manually with the software.)

In my opinion, the at91 usart has a fundamental design flaw. If the RPR 
buffer memory was a circular buffer then this problem would go away (after 
you of course designed the software to handle circular buffers!).


More information about the Ecos-discuss mailing list