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


I just ran some more tests where I:

- Read more bytes than are contained in the serial buffer.
- Read 512 bytes at a time and make sure they are correct (the MSP430 on the other end i just sending sequential bytes at full speed).

If I do this, I get no errors (over several hundred kb of data). If I don't preface the read test with the buffer clear I do get errors. This interests me as I make sure the app is running and waiting for data before I connect the serial cable - so the serial buffer should be completely empty before the first read of 512 bytes. However, this first read does contain errors (unless I do the pre-read).

I have ecos configured to set up the serial port correctly on boot (so I'm not having to do any configuration). This begs the question - is there some configuration I should be doing beyond opening the handle to the device and reading? The errors only tend to be in the first 6-10 bytes of the 512, the remaining are correct. Might there be some weird case where the uart is not configured properly but data is being received and pushed into the serial buffer anyway?

Thanks!

Shannon

On Wednesday, January 15, 2003, at 08:23 PM, Shannon Holland wrote:

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


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


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