[ECOS] Serial buffer overrun

Shannon Holland holland@loser.net
Sun Jan 12 19:08:00 GMT 2003


Hmmm, interesting. I apparently missed the discussion a few weeks back, 
I'll go looking.

The data point I was using regarding overrun was that if I unplug the 
serial cable while everything is running, the at91 keeps plugging away 
with new data for a while until it finally empties the buffer. Making 
the serial buffer larger or smaller changes this time appropriately.

It seems like using the DMA/RPR mechanism is probably more reliable - is 
this true? I'm presently only running the serial line at 19,200 baud. 
I'd like to go higher, but 38.4 or 57.6 is probably as high as I need to 
go. I presume I'm more likely to hit these bugs at higher baud rates?

Flow control is definitely a solution. I also need to implement a 
reliable transport protocol (rather than just detecting and dropping bad 
packets as I'm doing now). Are there existing protocols for lightweight 
reliable transport on a multidrop serial bus? (Rather not invent 
something if I can help it!). I basically plan to use the at91 as a 
master and then have multiple data collection endpoints sharing a RS-485 
serial line.

Ahh, just searched through my email - a big serial discussion happened 
while I was away on vacation - that will teach me not to catch up on 
email!

Thanks!

Shannon

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

> 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