From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24044 invoked by alias); 27 Jan 2008 11:20:06 -0000 Received: (qmail 24032 invoked by uid 22791); 27 Jan 2008 11:20:04 -0000 X-Spam-Check-By: sourceware.org Received: from netic.com (HELO netic.com) (208.131.130.247) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 27 Jan 2008 11:19:41 +0000 Received: from piii550 (60-242-91-36.static.tpgi.com.au [60.242.91.36]) by netic.com (8.12.11.20060308/8.12.11) with SMTP id m0RBJclR014591 for ; Sun, 27 Jan 2008 04:19:39 -0700 From: "Laurie Gellatly" To: Date: Sun, 27 Jan 2008 11:20:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: RE: [ECOS] Re: Uart missing chars when in Release X-SW-Source: 2008-01/txt/msg00176.txt.bz2 Hi Grant, >> The missing chars are on the wire - I've snooped them. >So the receiver is at fault. Definitely. >>> 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. So I modified ser_16X5X.c to read FIFO threshold (1,4,8 or 14) characters worth when an RDA interrupt occurs. With it set to 8 that should give 8 times as long to service the interrupt. >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.) Hmm, unfortunately that sounds right. >Does it stop dropping bytes at lower baud rates? Try that next. >Does it stop dropping bytes if there is no Ethernet traffic? Tried that. No difference. >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. Maybe I should copy ISR or DSR to internal RAM or flash? >>> 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. Counted the errors - none were shown. Thanks again for the help. ...Laurie:{) -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss