From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19256 invoked by alias); 13 Jun 2005 17:57:02 -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 19229 invoked by uid 22791); 13 Jun 2005 17:56:57 -0000 Received: from asav1.lyse.net (HELO asav1.lyse.net) (213.167.96.68) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 13 Jun 2005 17:56:57 +0000 Received: from asav1.lyse.net (asav1.lyse.net [127.0.0.1]) by localhost.lyse.net (Postfix) with ESMTP id 2709790124; Mon, 13 Jun 2005 19:52:06 +0200 (CEST) Received: from mail1.lyse.net (unknown [192.168.42.2])by asav1.lyse.net (Postfix) with ESMTPid 11F7690093; Mon, 13 Jun 2005 19:52:06 +0200 (CEST) Received: from [84.234.138.230] (helo=[192.168.0.193])by mail1.lyse.net with smtp (Exim 4.34)id 1DhtA6-0001Yd-52; Mon, 13 Jun 2005 19:55:50 +0200 From: =?ISO-8859-1?Q?=D8yvind?= Harboe To: Bart Veer Cc: ecos-discuss@sources.redhat.com In-Reply-To: <20050611134933.7C2CA65C057@smtp.ecoscentric.com> References: <1118229873.11654.24.camel@localhost.localdomain> <20050611134933.7C2CA65C057@smtp.ecoscentric.com> Content-Type: text/plain Date: Mon, 13 Jun 2005 17:57:00 -0000 Message-Id: <1118685436.31409.9.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-imss-version: 2.025 X-imss-result: Passed X-imss-scores: Clean:91.11750 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.1500 0.1500) Subject: Re: [ECOS] hal_delay_us() patch to at91_misc + multithreading X-SW-Source: 2005-06/txt/msg00098.txt.bz2 > I would like to see the macro > definition upgraded to make it compulsory rather than optional, and > require the macro to be thread-safe. 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. How about calibrating a CPU counter loop implementaiton upon startup using the default hardware timer in the HAL? - a couple of ms to the startup time is a small price to pay for a default implementation of a HAL_DELAY_US() - The HAL_DELAY_US() definition should state that the the accuracy is not very good, but that it is guaranteed to wait at least n us. Is there a fundamental reason why HAL_DELAY_US() needs to be very accurate(i.e. say <20-30%) > > Bart > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss