Re: [ECOS] Serial buffer overrun

[Shannon Holland <holland at loser dot net>]

So I've been looking at this more and it appears that I'm both dropping 
bytes and getting an overrun. If I run at full speed things might work 
for a while, but I will get dropped bytes. This generally brings out 
some debug code which does some printfs and gets me in an overrun case. 
I also was getting into this because of my lame lcd code - I improved 
this tonight so it should no longer be a problem.

So, at this point I'm not terribly concerned about the overrun. It's 
generally caused by debug code which will go away. In the future it will 
be solved by flow control. However, the byte dropping is a concern.

I've been looking at the at91 serial code and don't see that it uses the 
RPR/DMA mechanism - is there a version that implements this? Is this the 
driver implemented by Paulk Sheer?

I also notice that the low level ISR immediately schedules a DSR - how 
long is the delay from the exit from the ISR until the DSR routine is 
called? It seems to be a likely candidate for dropped bytes if there's 
any kind of delay here.

I also noticed that in the DSR it pulls in a single byte and then calls 
out to the channel callback, then gets the next byte, etc. Just for 
grins I modified this code to pull in a number of bytes at a time before 
calling the channel callback. I'm not sure this will buy me anything 
(doesn't change behavior) - I need to read up on the uart docs!

I also have another question as to how the debugger printf's interact 
with program flow: I notice I drop a whole ton of bytes if I call printf 
(anywhere from 20-60 bytes!). Are interrupts disabled when using the 
monitor printf?

Thanks!

Shannon


On Sunday, January 12, 2003, at 07:42  AM, Scott Dattalo wrote:

> 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!).
>
>
> Scott

--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss