From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23238 invoked by alias); 28 Jan 2008 15:58:35 -0000 Received: (qmail 23226 invoked by uid 22791); 28 Jan 2008 15:58:34 -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; Mon, 28 Jan 2008 15:58:11 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JJWN4-0001Wr-Oh for ecos-discuss@sources.redhat.com; Mon, 28 Jan 2008 15:58:06 +0000 Received: from c-76-17-159-23.hsd1.mn.comcast.net ([76.17.159.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Jan 2008 15:58:06 +0000 Received: from grante by c-76-17-159-23.hsd1.mn.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Jan 2008 15:58:06 +0000 To: ecos-discuss@sources.redhat.com From: Grant Edwards Date: Mon, 28 Jan 2008 15:58: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/msg00189.txt.bz2 On 2008-01-28, Laurie Gellatly wrote: > Reading the LPC manual I thought that just looping thru reading > as many chars as were available could (if a new char arrived > while looping) remove a newly arrived OE. It would. If you want to detect overrun errors, you have to check the OE bit every time the LSR is read. > The original code loops reading the LSR to check for any chars > available which also clears any OE that might have happened > after the original interrupt and while you were looping. I see. > I changed the RDA case to just read a threshold full (not > touching LSR) so that it would preserve the error till > interrupts were enabled again. I can see I misunderstood you. > I checked out a fresh copy via CVS and ser_16x5x.c is what I > started from. Sorry about the misunderstanding. > I just changed the BCFG for the RAM bank to be make accessing > RAM as slow as the flash. Running the test again did produce > just a few errors. RAM is normally 15ns and flash 70ns on my > board. > > I then slowed comms to 9600 baud and that works perfectly with > code running from flash. I'd say it's definitely an interrupt latency issue. > So, how would you approach this now? With a threshold of 8, that shuold give you almost 700us to respond to an interrupt. The first step is to find out why interrupts or DSRs are being disabled for so long. It's probably a DSR that's running longer than 700us. If that's so, you need to figure out what DSR is running longer than that and speed it up. Locating all the ISRs and DSRs in RAM appears to be one solution. It would be instructive to know which DSR is taking too long. The way I usually do that is to instrument all the DSRs so that they set a spare port pin high at entry and low at exit. Then you hook a scope or logic analyzer up to the spare port pins and see where the problem is. Once you know where the problem is, you can break the culprit up into a state machine that runs for a little while (performing part of the work), then reschedules itself (which will let other DSRs run) and exits. -- Grant Edwards grante Yow! Was my SOY LOAF left at out in th'RAIN? It tastes visi.com REAL GOOD!! -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss