On 2008-01-27, Laurie Gellatly <[EMAIL PROTECTED]> 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
