From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13313 invoked by alias); 26 Jun 2005 14:26: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 13297 invoked by uid 22791); 26 Jun 2005 14:26:51 -0000 Received: from norbert.ecoscentric.com (HELO smtp.ecoscentric.com) (194.153.168.165) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 26 Jun 2005 14:26:51 +0000 Received: by smtp.ecoscentric.com (Postfix, from userid 99) id 6D02A65C0BA; Sun, 26 Jun 2005 15:26:49 +0100 (BST) Received: from delenn.bartv.net (localhost [127.0.0.1]) by smtp.ecoscentric.com (Postfix) with ESMTP id 175E565C0A4; Sun, 26 Jun 2005 15:26:47 +0100 (BST) To: oyvind.harboe@zylin.com Cc: ecos-discuss@sources.redhat.com In-reply-to: <1119425206.20805.21.camel@localhost.localdomain> (message from =?ISO-8859-1?Q?=D8yvind?= Harboe on Wed, 22 Jun 2005 09:26:46 +0200) From: Bart Veer References: <1119425206.20805.21.camel@localhost.localdomain> Message-Id: <20050626142647.175E565C0A4@smtp.ecoscentric.com> Date: Sun, 26 Jun 2005 14:26:00 -0000 Subject: Re: [ECOS] HAL_DELAY_US() default implementation X-SW-Source: 2005-06/txt/msg00259.txt.bz2 >>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind?= Harboe writes: Oyvind> Ref Oyvind> http://ecos.sourceware.org/ml/ecos-patches/2005-06/msg00033.html Oyvind> Looks good. Oyvind> Thoughts on a default implementation: Oyvind> - Add calibration by default on startup. There are so many Oyvind> things affecting the performance: type of ram/flash, Oyvind> caches, off-frequency crystals(e.g. 64MHz instead of 66 Oyvind> MHz crystal), etc. I'm not entirely convinced that the Oyvind> calibration number can be put in the source and committed Oyvind> to CVS. E.g. for the AT91 there are 5 HALs X 3 types of Oyvind> code memory(internal, external & flash) 15 calibration Oyvind> numbers. The number of combinations for all the eCos HAL's Oyvind> could easy reach thousands. Oyvind> - Calibration can be disabled by specifying the number in Oyvind> a CDL option. This number is extracted by running the app Oyvind> in the debugger and setting a breakpoint at the end of the Oyvind> calibration loop. Oyvind> - The calibration algorithm must have some sort of way to Oyvind> estimating the accuracy to determine when the calibration Oyvind> should terminate. Integer math. For most platforms I do not think this level of complexity is necessary. Usually the memory speed will be irrelevant because the busy loop will run entirely out of icache. Off-frequency crystals are a possibility, but the difference between 64MHz and 66MHz is just three percent. For the purposes of HAL_DELAY_US() i.e. interacting with hardware, as long as the code assumes the faster speed the difference may not be worth worrying about. If complicated calibration really is needed then this can be done by individual HALs. I would much prefer not to see an expensive calibration loop in any generic code. When porting eCos it is far too easy to just quickly use some existing suboptimal code instead of doing the job properly, leading to problems down the road. 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