This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Serial buffer overrun
- From: Shannon Holland <holland at loser dot net>
- To: eCos Discussion <ecos-discuss at sources dot redhat dot com>
- Date: Sun, 12 Jan 2003 11:04:59 -0800
- Subject: Re: [ECOS] Serial buffer overrun
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!).