From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29332 invoked by alias); 19 May 2005 14:20:17 -0000 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 Received: (qmail 29024 invoked from network); 19 May 2005 14:19:24 -0000 Received: from unknown (HELO mail.cipher.com) (198.107.56.73) by sourceware.org with SMTP; 19 May 2005 14:19:24 -0000 Received: from [10.0.0.100] (DAVID01 [10.0.0.100]) by mail.cipher.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id J3786MX6; Thu, 19 May 2005 07:19:23 -0700 Message-ID: <428CA063.8040005@cipher.com> Date: Thu, 19 May 2005 20:01:00 -0000 From: David Roethig Reply-To: droethig@cipher.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 MIME-Version: 1.0 To: Nick Garnett CC: ecos-discuss@sources.redhat.com References: <428BCC08.8060804@cipher.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ECOS] problem with generic serial driver? X-SW-Source: 2005-05/txt/msg00265.txt.bz2 Nick Garnett wrote: > David Roethig writes: > > >>I am using (as of recently) the generic serial driver >>package (16x5x compatible serial device drivers). >> >>The application was sending data to the port using the >>file i/o interface: >> >> /* output string to serial port */ >> err = cyg_io_write( serHandle, writeBuffer, length ); >> >>Nothing came out the serial port! That is, until, the app >>output a 'diag_printf()'. That was a head-scratcher until >>looking at the pc_serial_start_xmit() routine, I noticed >>that the trasmitter wasn't being 'kicked' with a character >>to the transmit register. >> >> // Enable the transmitter on the device >> static void >> pc_serial_start_xmit(serial_channel *chan) >> { >> pc_serial_info *ser_chan = (pc_serial_info *)chan->dev_priv; >> cyg_addrword_t base = ser_chan->base; >> cyg_uint8 _ier; >> >> HAL_READ_UINT8(base+REG_ier, _ier); >> _ier |= IER_XMT; // Enable xmit interrupt >> HAL_WRITE_UINT8(base+REG_ier, _ier); >> >> /* kick transmitter */ // **!! added !!** >> (chan->callbacks->xmt_char)(chan); // **!! added !!** >> } >> >>My questions: >> 1) is the generic serial package still being used? >> 2) is this a bug or are things configured incorrectly? > > > This driver is being used on lots of targets, any that have 16x5x > compatible serial devices will use it. However, not all devices that > claim to be 16x5x compatible actually are. Some are missing features, > some have extra features. > > Under normal circumstances the XMT interrupt occurs whenever the > transmit buffer (or FIFO) is empty. That's why we have to enable and > disable it, since we would otherwise be flooded with interrupts when > we had nothing to transmit. > > It looks like your 16x5x clone either has this wrong, or, more likely, > has a "transmit interrupt holdoff" feature in an attempt to solve the > interrupt flood problem. Another example of hardware designers trying > to be helpful but actually just making the software more complicated. > > Your fix is the correct thing to do, and is benign even for correctly > functioning 16x5xs. > > > Out of interest, what is the target you are working on? We are working on a Philips LPC2292 custom board. We started our design before the LPC2xxx port was released. Recently, the generic serial port driver package was added because we thought it would be more robust than the code we cobbled together. Thanks Dave -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss