From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16875 invoked by alias); 27 Jan 2008 15:55:26 -0000 Received: (qmail 16864 invoked by uid 22791); 27 Jan 2008 15:55:26 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 27 Jan 2008 15:55:01 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JJ9qP-00032l-AE for ecos-discuss@sources.redhat.com; Sun, 27 Jan 2008 15:54:53 +0000 Received: from grante.dsl.visi.com ([208.42.141.248]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Jan 2008 15:54:53 +0000 Received: from grante by grante.dsl.visi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Jan 2008 15:54:53 +0000 To: ecos-discuss@sources.redhat.com From: Grant Edwards Date: Sun, 27 Jan 2008 15:55:00 -0000 Message-ID: References: User-Agent: slrn/0.9.8.1 (Linux) 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: [ECOS] Re: Uart missing chars when in Release X-SW-Source: 2008-01/txt/msg00177.txt.bz2 On 2008-01-27, Laurie Gellatly wrote: >>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. What was it doing? The correct thing to do is to read all the available characters each time an rx interrupt occurs. > With it set to 8 that should give 8 times as long to service > the interrupt. Correct. If you're using a 16 byte fifo, you should have up to (16-threshold) byte times to respond to an interrupt. >>Does it stop dropping bytes at lower baud rates? > > Try that next. If the problem goes a way an lower baud rates, that would be an important clue. >>Does it stop dropping bytes if there is no Ethernet traffic? > > Tried that. No difference. What other interrupt sources are active? I wouldn't think the timer tick would be an issue... >>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? If it's a latency problem, you'd probably need to copy all ISRs and DSRs to RAM (as well as any long-running functions called by either of those). >>> 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. If there aren't any receive overrun errors, then interrupt latency isn't the problem. There weren't any rx errors of any sort (parity, framing, etc.)? -- Grant Edwards grante Yow! Where's th' DAFFY at DUCK EXHIBIT?? visi.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss