From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16941 invoked by alias); 30 May 2008 07:47:24 -0000 Received: (qmail 16910 invoked by uid 22791); 30 May 2008 07:47:19 -0000 X-Spam-Check-By: sourceware.org Received: from elasmtp-masked.atl.sa.earthlink.net (HELO elasmtp-masked.atl.sa.earthlink.net) (209.86.89.68) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 30 May 2008 07:46:51 +0000 Received: from [75.82.39.242] (helo=PAULD) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1K1zK4-0005Sw-M4; Fri, 30 May 2008 03:46:49 -0400 From: "Paul D. DeRocco" To: "ariga masahiro" , "eCos Discuss" Date: Fri, 30 May 2008 07:47:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <000d01c8c226$6fa92140$1c0110ac@ariga> X-ELNK-Trace: bd7d5d4e6f8f652c74cfc7ce3b1ad11381c87f5e51960688672962936c755128c1e7f5d08105611b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes 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: RE: [ECOS] Re: In trouble of timer operations X-SW-Source: 2008-05/txt/msg00119.txt.bz2 > From: ariga masahiro > > OK,I re_state what I want.I like to hold delay as close as multiple of > 10ms. It might be helpful if we had an idea of what you actually need this delay for. Let's say you need the software to turn on some hardware device at one point in time, then turn it off some known amount of time later. If 10ms granularity is sufficient, and it's acceptable to have both the turn-on and turn-off occur on ticks of the existing system clock, then you could do a one-tick delay to synchronize your thread to the clock, turn the device on, delay some additional ticks, and then turn it off. cyg_thread_delay(1); control_something(TRUE); cyg_thread_delay(n); control_something(FALSE); You'd get a pretty accurate n-tick delay between the two calls to control_something(). But that assumes that no other thread of the same or higher priority is running. But if that's all you need, it's easier just to use an alarm object attached to the system clock, and do whatever you need to do in the alarm handler. It will run in DSR context, so can't do certain things like file I/O, but it won't be pre-empted by anything else other than other ISRs and DSRs. A thread could still control things either by setting static variables that the alarm handler reads, or by explicitly enabling and disabling the alarm as needed. -- Ciao, Paul D. DeRocco Paul mailto:pderocco@ix.netcom.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss