From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4770 invoked by alias); 6 Feb 2013 15:06:24 -0000 Received: (qmail 4760 invoked by uid 22791); 6 Feb 2013 15:06:22 -0000 X-SWARE-Spam-Status: No, hits=-5.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-oa0-f50.google.com (HELO mail-oa0-f50.google.com) (209.85.219.50) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Feb 2013 15:06:15 +0000 Received: by mail-oa0-f50.google.com with SMTP id l20so1580311oag.37 for ; Wed, 06 Feb 2013 07:06:14 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.30.42 with SMTP id p10mr22348902oeh.59.1360163174404; Wed, 06 Feb 2013 07:06:14 -0800 (PST) Received: by 10.76.75.42 with HTTP; Wed, 6 Feb 2013 07:06:14 -0800 (PST) In-Reply-To: References: Date: Wed, 06 Feb 2013 15:06:00 -0000 Message-ID: From: Andreas Stenius To: ecos-discuss@ecos.sourceware.org Content-Type: text/plain; charset=ISO-8859-1 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: Serial communication issues X-SW-Source: 2013-02/txt/msg00007.txt.bz2 OK, not 100% clear, but I've narrowed it down to the interrupt driven DMA receiver in at91_serial.c. I used the default values for the HW serial driver, with a receive buffer of 128 bytes, and a receive chunk size of 1 byte. After adding a bunch of CYG_TRACE calls, which didn't affect the timings too much, I captured a trace where it had dropped two bytes. Analyzing the trace and source, I suspect that the ISR/DSR handling of the DMA receiver isn't glitch free when done in the midst of incoming data. With this knowledge, I changed my receive chunk size to 6 bytes, and the issue has gone away, for this particular use case. Not yet sure if it is going to show up again later or not.. :/ Btw, there are a few rough edges in the trace handling when set to halt after filling the trace buffer. First, when printing a halted trace buffer (i.e. it is full), it will go into an endless loop. This from the fact that the loop variable i is set to 0 before the end test when it has reached the last entry. Moving the if (i == BUFFER_SIZE) test to the head of the loop instead of at the bottom solves this (so the while test is done first, then the if test). Secondly, there is no way to restart the tracing once it has been halted. I find this rather limiting, so I dropped the old_halted variable in cyg_trace_print() so that the trace is restarted after printing the contents of the trace buffer. I'll consider posting this as a patch to the bugzilla database... Cheers, Andreas -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss