From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25730 invoked by alias); 8 May 2008 09:49:01 -0000 Received: (qmail 25711 invoked by uid 22791); 8 May 2008 09:48:59 -0000 X-Spam-Check-By: sourceware.org Received: from cheviot1.ncl.ac.uk (HELO cheviot1.ncl.ac.uk) (128.240.234.85) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 08 May 2008 09:48:41 +0000 X-Newcastle-MailScanner-Watermark: 1210844886.49841@ImHe1AGPhePchDt769n85Q Received: from moonraker.campus.ncl.ac.uk (moonraker.ncl.ac.uk [10.8.234.171]) by cheviot1.ncl.ac.uk (8.13.1/8.13.1) with ESMTP id m489m2wP015149 for ; Thu, 8 May 2008 10:48:04 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 08 May 2008 09:49:00 -0000 Message-ID: <96F77944E1BA554D814FBC549EC5D3F00B48636C@moonraker.campus.ncl.ac.uk> In-Reply-To: <4821D94E.3050409@til.ca> From: "Steven Clugston" To: X-Newcastle-MailScanner-Information: Please contact Postmaster@newcastle.ac.uk for more information X-Newcastle-MailScanner: Found to be clean X-Newcastle-MailScanner-MCPCheck: X-Newcastle-MailScanner-From: steven.clugston@newcastle.ac.uk X-NCL-Spam-Status: No 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: MPC555 serial receive drops bytes X-SW-Source: 2008-05/txt/msg00036.txt.bz2 >This sounds like your ISR code can take more than one=20 >character time to=20 >execute. Assuming 8-N-1 data format, a 57600 baudrate works=20 >out to 173.6=20 >microseconds per character. You don't say what speed your CPU is=20 >running, but I suspect 173.6 uS works out to a *lot* of CPU=20 >instructions.=20 The board is 40MHz which for 173.6 uS corresponds to 6944 instructions assuming one instruction per clock cycle. The board is really quite modest when running just the serial_echo test, the only thing (that I can think of) that's running periodically in at the ISR/DSR level is the wallclock and serial Rx and Tx ISRs and DSRs. Thinking about this though, the Tx DSR does sit and try to clear the send buffer into the hardware register which would make it take longer than the Rx DSR. It usually only manages to transfer one or two bytes at a time before giving up and waiting for the next ready to send interrupt. If the Tx DSR was blocking the Rx DSR from running in time then I guess this would show up worst in an serial echo situation which is what I'm seeing. I think this warrants further investigation. >You should not need to sit in the ISR waiting=20 >for the line=20 >to go idle. I was thinking to do this in the DSR and not the ISR, but I think the ISR circular buffer is better. >I had the same problem with the Coldfire serial driver. The original=20 >driver simply masked out the interrupt and called the DSR. That worked=20 >great until you got some other DSR taking more than one character time=20 >to execute. The serial DSRs got posted, but they didn't run in=20 >time. The=20 >solution for my driver was to move the data in/out of the UART to a=20 >circular buffer in the ISR. > >I suspect this issue may occur on other platforms as well. > >Alex. I've had a quick look at coldfire mcf5272_serial.c in cvs which still does as you say the original driver does. Does this mean then that this is a potential problem will all of the serial drivers, particularly the ones which have only a single character buffer? I notice also that in the same file there is: #ifdef CYGOPT_IO_SERIAL_SUPPORT_LINE_STATUS // Overrun error if (usr_ucsr & MCF5272_UART_USR_OE) { stat.which =3D CYGNUM_SERIAL_STATUS_OVERRUNERR; (chan->callbacks->indicate_status)(chan, &stat); } #endif And in packages/io/serial/include/serialio.h #ifdef CYGOPT_IO_SERIAL_SUPPORT_LINE_STATUS # define CYGNUM_SERIAL_STATUS_FLOW 0 # define CYGNUM_SERIAL_STATUS_BREAK 1 # define CYGNUM_SERIAL_STATUS_FRAMEERR 2 # define CYGNUM_SERIAL_STATUS_PARITYERR 3 # define CYGNUM_SERIAL_STATUS_OVERRUNERR 4 # define CYGNUM_SERIAL_STATUS_CARRIERDETECT 5 # define CYGNUM_SERIAL_STATUS_RINGINDICATOR 6 This is the error reporting mechanism I was after. In io_serial.cdl there is the cdl option CYGOPT_IO_SERIAL_SUPPORT_LINE_STATUS : requires { CYGINT_IO_SERIAL_LINE_STATUS_HW > 0 } "This option indicates that if the serial driver supports it, serial line status and modem status information should be propagated to higher layers via callbacks." And in mcf5272_serial.cdl: implements CYGINT_IO_SERIAL_LINE_STATUS_HW So I know how to do this from the driver side, but does anybody know how this gets reported to "higher layers" and if it currently works? I can't find any API documentation for this. Ideally I would like the cyg_io_read() to return with a spcific error code or at least something that tells me I need to do a cyg_io_get_config() to find out what happened at the app level. Steven -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss