From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10039 invoked by alias); 16 Jan 2006 10:36:59 -0000 Received: (qmail 9976 invoked by uid 22791); 16 Jan 2006 10:36:58 -0000 X-Spam-Check-By: sourceware.org Received: from anchor-post-33.mail.demon.net (HELO anchor-post-33.mail.demon.net) (194.217.242.91) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 16 Jan 2006 10:36:56 +0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by anchor-post-33.mail.demon.net with esmtp (Exim 4.42) id 1EyRjJ-00013b-A7; Mon, 16 Jan 2006 10:36:53 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id 8BA5527FE2; Mon, 16 Jan 2006 10:36:52 +0000 (GMT) To: daniel.neri@sigicom.se (=?utf-8?b?RGFuaWVsIE7DqXJp?=) Cc: ecos-discuss@sources.redhat.com References: <87vewklg60.fsf@ebbot.hq.sigicom.net> From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Mon, 16 Jan 2006 10:36:00 -0000 In-Reply-To: <87vewklg60.fsf@ebbot.hq.sigicom.net> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Re: DSR Scheduling Problem X-SW-Source: 2006-01/txt/msg00120.txt.bz2 daniel.neri@sigicom.se (Daniel N=C3=A9ri) writes: > Grant Edwards writes: >=20 > > On 2006-01-14, Paul D. DeRocco wrote: > > > >> If the transmitter has a hardware FIFO, and the software > >> transmits one byte per interrupt, > > > > Then the sofware is completely and utterly broken. It doesn't > > deserve to work. > > > >> then presenting a block of data to it after an idle period > >> will invoke the ISR/DSR a slew of times until the FIFO is > >> full. > > > > That's insane. Nobody with a clue would write software like that. >=20 > Actually, the generic 16x5x serial driver in eCos works exactly like > that. Actually, it doesn't. >=20 > > When you get a TX interrupt you write data to the tx FIFO until it's > > full. >=20 > Yep. I've made a somewhat quick-and-dirty fix that is attached below. This already happens. pc_serial_putc() returns true or false, depending on whether it transmitted the byte. In the 16550 this means that it will only return false when the FIFO fills up. The generic serial code calls the putc() driver routine in a loop to transmit bytes until it returns false. --=20 Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss