This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 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!).






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]