From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Nt464-0004vy-9C for garchives@archives.gentoo.org; Sat, 20 Mar 2010 19:12:33 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DF5B1E0B4F for ; Sat, 20 Mar 2010 19:12:31 +0000 (UTC) Received: from mail.osagesoftware.com (osagesoftware.com [216.144.204.42]) by pigeon.gentoo.org (Postfix) with ESMTP id 18BF3E0A8C for ; Sat, 20 Mar 2010 19:02:38 +0000 (UTC) Received: from osage.osagesoftware.com (osage.osagesoftware.com [192.168.1.10]) by mail.osagesoftware.com (Postfix) with ESMTP id 64D967BC4D for ; Sat, 20 Mar 2010 15:02:37 -0400 (EDT) Date: Sat, 20 Mar 2010 15:02:37 -0400 From: David Relson To: gentoo-embedded@lists.gentoo.org Subject: [gentoo-embedded] SOLUTION (partial) was: High Speed Serial Problem Message-ID: <20100320150237.2ee70a4e@osage.osagesoftware.com> In-Reply-To: <91FA647A1A781F41BBB0359765C90C15F713C8@mailsvr.orion-sys.com> References: <20100314102459.20d7883b@osage.osagesoftware.com> <20100315133434.GA15613@xyzzy.org.uk> <91FA647A1A781F41BBB0359765C90C15F713C8@mailsvr.orion-sys.com> Organization: Osage Software Systems, Inc. X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-embedded@lists.gentoo.org Reply-to: gentoo-embedded@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 6f6eebce-0f6b-4150-a1d4-906360fe975c X-Archives-Hash: f65c9476279d2a34bedb22a004fbce1a On Mon, 15 Mar 2010 13:47:14 -0400 Relson, David wrote: > Hello Bob, > > VMIN and VTIME are the default values of 1 and 0, respectively. If I > understand correctly, these settings will provide data as rapidly as > possible. > > At present, I am using a 256 byte buffer for reading data. I've added > some statistics gathering. Every 1000 reads, the program logs the > total bytes read and the maximum read. The program was run for 30 > seconds to provide 6 statistics records > > With _no_ processing of data, 1000 reads got from 27,545 to 28,520 > chars. The max read was 128 chars. 3 of the 1000 read samples had > max reads of 56 or 57 and 3 had max reads of 110, 126, and 128. > > With copying of data to a buffer (which involves several function > calls, incrementing counters, etc), 1000 reads got from 27,187 to > 28,241 chars and each of the 6 sample sets had a max read of 110 to > 128 bytes. > > One would expect processing to increase the total bytes received, but > this was not the case. > > The code _is_ handling the 3 char break sequence and the > (undocumented) doubling (escaping) of 0xFF chars (to distinguish them > from break sequences). > > Regards, > > David The serial input problem has been solved! While talking with the project manager, it occurred to me to check whether all byte codes, i.e. 0x00 to 0xFF, were being received. I quickly found that 2 were missing -- 0x11 and 0x13 -- which are the usual XON and XOFF characters. Simply setting termios.c_iflag=PARMK (rather than or'ing the flag) solved the lost character input problem. Even with a dedicated thread, the program is still receiving multiple characters per read. Calculating average and maximum byte counts for each 10,000 reads, I've often seen maximums of 150 and have never seen an average under 12. These numbers occur with VMIN=1 and VTIME=0. Is there a setting so that the serial port driver will release characters sooner (rather than later)? My basic loop looks like: while (1) { char buffer[256]; select(...) count = read(fd, buffer, sizeof(buffer)) ... save characters. } Regards, David