From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27042 invoked by alias); 13 Jun 2005 18:54:55 -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 27028 invoked by uid 22791); 13 Jun 2005 18:54:51 -0000 Received: from norbert.ecoscentric.com (HELO smtp.ecoscentric.com) (194.153.168.165) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 13 Jun 2005 18:54:51 +0000 Received: by smtp.ecoscentric.com (Postfix, from userid 99) id F15E665C07E; Mon, 13 Jun 2005 19:54:48 +0100 (BST) Received: from delenn.bartv.net (localhost [127.0.0.1]) by smtp.ecoscentric.com (Postfix) with ESMTP id 1D92265C057; Mon, 13 Jun 2005 19:54:48 +0100 (BST) To: oyvind.harboe@zylin.com Cc: ecos-discuss@sources.redhat.com In-reply-to: <1118685436.31409.9.camel@localhost.localdomain> (message from =?ISO-8859-1?Q?=D8yvind?= Harboe on Mon, 13 Jun 2005 19:57:16 +0200) From: Bart Veer References: <1118229873.11654.24.camel@localhost.localdomain> <20050611134933.7C2CA65C057@smtp.ecoscentric.com> <1118685436.31409.9.camel@localhost.localdomain> Message-Id: <20050613185448.1D92265C057@smtp.ecoscentric.com> Date: Mon, 13 Jun 2005 18:54:00 -0000 Subject: Re: [ECOS] hal_delay_us() patch to at91_misc + multithreading X-SW-Source: 2005-06/txt/msg00099.txt.bz2 >>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind?= Harboe writes: >> I would like to see the macro definition upgraded to make it >> compulsory rather than optional, and require the macro to be >> thread-safe. Oyvind> Makes sense. I2C seems to be based upon these assumptions. >> I am happy to do a synthetic target implementation, but that >> still leaves other architectures where the macro would need to >> be added or fixed. Oyvind> How about calibrating a CPU counter loop implementaiton Oyvind> upon startup using the default hardware timer in the HAL? Oyvind> - a couple of ms to the startup time is a small price to pay for Oyvind> a default implementation of a HAL_DELAY_US() Oyvind> - The HAL_DELAY_US() definition should state that the the accuracy Oyvind> is not very good, but that it is guaranteed to wait at least Oyvind> n us. Doesn't work for the synthetic target. The only easy way for the synthetic target to read a clock is a gettimeofday() system call, i.e. real time rather than process elapsed time. This would be fine if there was nothing else running, but the synthetic target may get preempted at any time including during this calibration loop. Hence there is no guarantee the gettimeofday() values bear any resemblance to the loop count. You could try doing the measurements several times and picking the most sensible result, but at that level of complexity you might as well read /proc/cpuinfo. For embedded targets, often a couple of ms extra boot time is not significant. But not always. There are systems which have a hard requirement that some application code gets to run within a couple of ms or less of power-up. Instead wherever possible the HAL_DELAY_US() loop count should be determined during the porting process, not at run-time. Oyvind> Is there a fundamental reason why HAL_DELAY_US() needs to Oyvind> be very accurate(i.e. say <20-30%) It should not be less than the specified delay, give or take a couple of percent. Device drivers can have fairly strict minimum intervals between operations. Once interrupts are enabled HAL_DELAY_US() can take arbitrary amounts of time longer than the specified delay, but it is still a good idea to make it reasonably accurate. The usual implementation is a polling loop during which no other work can get done, making that loop use more cpu cycles than are absolutely necessary is wasteful. Bart -- Bart Veer eCos Configuration Architect http://www.ecoscentric.com/ The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss