From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26775 invoked by alias); 19 Jun 2006 13:07:57 -0000 Received: (qmail 26764 invoked by uid 22791); 19 Jun 2006 13:07:57 -0000 X-Spam-Check-By: sourceware.org Received: from dns1-chi.paetec.net (HELO dns1-chi.paetec.net) (64.80.249.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 19 Jun 2006 13:07:54 +0000 Received: from dtcsrvr09.dtccom.com ([66.153.88.146]) by dns1-chi.paetec.net (8.13.6/8.13.6) with ESMTP id k5JD7lUr004173 for ; Mon, 19 Jun 2006 09:07:52 -0400 (EDT) Received: by dtcsrvr09.dtccom.com with Internet Mail Service (5.5.2658.3) id ; Mon, 19 Jun 2006 09:07:27 -0400 Message-ID: From: "Chase, Tom" To: ecos-discuss@ecos.sourceware.org Date: Mon, 19 Jun 2006 13:07:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.3) Content-Type: text/plain X-IsSubscribed: yes 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 Subject: [ECOS] cyg_thread_delay vs cyg_flag_wait behavior X-SW-Source: 2006-06/txt/msg00168.txt.bz2 Hello, I am working on my fourth ecos project. Historically I have had a thread monitoring a serial port. The thread has the lowest priority and sits at a getc until some data arrives then deals with it. This has worked well for debugging and configuration allowing a PC application to talk to the device and set up frequencies or what not. On the latest project this isn't working reliably. It will work for a few bytes of data then stop responding. The change in performance appears to be related to cyg_thread_delay vs. cyg_flag_wait. For the first time, I have a higher priority thread that has no cyg_thread_delays in it. It sits at a cyg_flag_wait most of the time (servicing flags every 100 to 250 ms). If I add a cyg_thread_delay to that thread (putting it just before the flag_wait for example) then the serial behavior is as I expect. I am working on an OMAP5912 and using the interrupt driven serial. I have verified that the thread is indeed waking up from the wait as I expect (10 times a second) and not always running (I.E. there is time available for lower priority threads). I have tried using various settings (buffered, non buffered, stdin, TTY etc.) with no change in performance. I have a cyg_thread_delay that is called when the unit prepares to power down (to lock out the keyboard) and any buffered serial inputs are handled then (which is one clue to why this was happening). I can add a delay but I would like to understand the differences between these two functions while they are blocking. Conceptually I think of the delay and the wait doing the same thing and do not understand why they behave differently while they are in effect. Can anyone advise? Thanks, Tom Chase DTC Communications Software Engineering Manager -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss