From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13210 invoked by alias); 6 Oct 2004 13:22:23 -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 13195 invoked from network); 6 Oct 2004 13:22:21 -0000 Received: from unknown (HELO mail3.becom.net) (194.162.52.24) by sourceware.org with SMTP; 6 Oct 2004 13:22:21 -0000 Received: from [192.168.128.120] (pD9E2C510.dip.t-dialin.net [217.226.197.16]) (authenticated) by mail3.becom.net (8.11.6/8.11.6) with ESMTP id i96D5Z618172 for ; Wed, 6 Oct 2004 15:05:35 +0200 Message-ID: <4163F16F.8010501@itknet.de> Date: Wed, 06 Oct 2004 14:44:00 -0000 From: Peter Graf User-Agent: Mozilla Thunderbird 0.5 (Windows/20040502) MIME-Version: 1.0 To: eCos Discussion References: In-Reply-To: X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ECOS] Problem with getchar / gets / fgets X-SW-Source: 2004-10/txt/msg00135.txt.bz2 Nicolas Brouard wrote: >Hi, >Does somebody have a council to solve my problem? >I have a Shell application and input lost a lot of characters. On my PowerPc >MPC860 target, I have to hit each character several times to display it on >minicom. > > IIRC you reported that Redboot worked fine, so it reminded me of having a similar problem. I can only refer to eCos 2.0, but I guess this has not changed. In io/serial...serial.c, serial_read() attempts to fill a buffer of more than one character, even if the upper layer has requested only one, e.g. when the caller was getchar(). Now when your lowlevel driver supports no interrupt driven buffer fill operation (reflected here by cbuf->len==0), this will be done by calling several blocking (funs->getc)(chan), i.e. you must send several characters until the buffer is filled and serial_read() decides to return to its caller. Check if the characters properly arrive in your lowlevel driver first. If they do, it might be related to this. I resolved it by a quick hack in serial.c, never blocking for more than one character, but the proper way is an interrupt driven lowlevel driver. Peter -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss