[ECOS] Re: Uart missing chars when in Release

[Grant Edwards <grante@visi.com>]

On 2008-01-27, Laurie Gellatly <laurie.gellatly@netic.com> wrote:

> The missing chars are on the wire - I've snooped them.

So the receiver is at fault.

>> I'm not familiar with your platform, but on many platforms
>> running from flash can be much, much slower than running from
>> RAM -- in some cases up to maybe 8-10X slower, but 4X slower
>> is more typical.  Flash often has much slower access times
>> that RAM and is often narrower than RAM.  2X bus cycles with
>> 4X access time can add up pretty fast.
>
> The same platform also runs an Ethernet interface without
> problems. 10Mbit is quite a bit faster than 115K baud so I
> feel I can probably discount that.

At 117Kbps with no fifo, you have to service a receive
interrupt at a 11.7KHz or you lose bytes.  That means you've
got to have an interrupt latency less than 85us.

The Ethernet interface only produces an interrupt once per
frame. I'd be surprised if you're transferring more than a
hundred frames per second. The Ethernet interface probabably
also has a buffer queue.  That means that the Ethernet
interface can tolerate an interrupt latency 10-20X larger than
the serial interface can tolerate.  The Ethernet service
routine also probably produces a pretty long interrupt latency
while its DSR is running.  (It's probably the DSR latency that
matters rather than the ISR latency.)

Does it stop dropping bytes at lower baud rates?

Does it stop dropping bytes if there is no Ethernet traffic?

Running from flash is almost certainly slower, and I'd wager
that it increases the interrupt latency beyond what can be
tolerated by the serial interface's interrupt frequency.

>> Are you seeing rx overrun errors?  If the rx end is running
>> too slowly for the data rate, you would see rx overrun errors.
>
> From what I've read, the OE gets cleared on each read of RBR.
> How can I check on this? Is there a counter of OE and other
> errors kept in eCos that I can access?

You've got the source code, you tell me.  -- I don't know what
low-level driver you're using. If it doesn't have an OE
counter, you can add one: it's only a couple lines of code.

You could also add a line of code to the serial driver's DSR
that toggles a spare port pin.  Then watch that pin while it's
receiving data.  That should give a pretty good idea if
interrupt latency is the problem. 

-- 
Grant



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