[ECOS] Serial buffer overrun
Thu Jan 16 05:50:00 GMT 2003
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?
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?
> 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
>>> 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
>>> 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
>>> 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
>> driver is not using the RPR register (the hardware peripheral in the
>> at91r40008 that allows DMA-like streaming between the USART and RAM)
>> there's a chance that the interrupt routine will occasionally drop a
>> 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
>> pool is filled (because there's a brief instant in which the receiver
>> to be inhibited while the RPR is adjusted).
>> In my application, the only way to get around this byte-dropping
>> was by implementing flow control. I chose to implement it at the
>> (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
>> [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
>> you of course designed the software to handle circular buffers!).
> -- Before posting, please read the FAQ:
> 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
More information about the Ecos-discuss