From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6788 invoked by alias); 11 Jun 2005 13:49:42 -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 6780 invoked by uid 22791); 11 Jun 2005 13:49:37 -0000 Received: from norbert.ecoscentric.com (HELO smtp.ecoscentric.com) (194.153.168.165) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 11 Jun 2005 13:49:37 +0000 Received: by smtp.ecoscentric.com (Postfix, from userid 99) id 3E31E65C07D; Sat, 11 Jun 2005 14:49:35 +0100 (BST) Received: from delenn.bartv.net (localhost [127.0.0.1]) by smtp.ecoscentric.com (Postfix) with ESMTP id 7C2CA65C057; Sat, 11 Jun 2005 14:49:33 +0100 (BST) To: oyvind.harboe@zylin.com Cc: ecos-discuss@sources.redhat.com In-reply-to: <1118229873.11654.24.camel@localhost.localdomain> (message from =?ISO-8859-1?Q?=D8yvind?= Harboe on Wed, 08 Jun 2005 13:24:33 +0200) From: Bart Veer References: <1118229873.11654.24.camel@localhost.localdomain> Message-Id: <20050611134933.7C2CA65C057@smtp.ecoscentric.com> Date: Sat, 11 Jun 2005 13:49:00 -0000 Subject: Re: [ECOS] hal_delay_us() patch to at91_misc + multithreading X-SW-Source: 2005-06/txt/msg00080.txt.bz2 >>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind?= Harboe writes: Oyvind> Q: As near as I can tell, HAL_DELAY_US() is not thread Oyvind> safe in at91_misc.c. Is this correctly observed? Oyvind> I can't tell by reading the eCos documentation whether or Oyvind> not hal_delay_us or HAL_DELAY_US is supposed to be thread Oyvind> safe. Oyvind> http://sources.redhat.com/ecos/docs-2.0/ref/hal-interrupt-handling.html Oyvind> The implementation of I2C uses hal_delay_us, but since I'm Oyvind> not currently using that code(our home rolled I2C code has Oyvind> not been phased out yet), I'm not sure whether or not Oyvind> interrupts are disabled while hal_delay_us() is invoked Oyvind> inside the I2C code. The actual definition of HAL_DELAY_US() is in http://ecos.sourceware.org/docs-latest/ref/hal-clocks-and-timers.html It lists the macro as optional and does not address thread-safety. There are still some architectures where it has not been implemented including the synthetic target, sparc, sparclite and v85x. There are two main ways of implementing HAL_DELAY_US(). The first is a counting loop, typically written in inline assembler, using an outer loop for the microseconds and an inner loop that consumes approximately 1us. With a bit of experimenting it is usually straightforward to get this to within a couple of percent of the desired delay. The implementation is automatically thread-safe and does not require manipulating any hardware, disabling interrupts, or anything like that. If the thread happens to be timesliced or preempted by a higher-priority thread in the middle of the busy loop then the delay will be longer than intended, but that is always a possibility anyway. This approach assumes the cpu clock speed is known at compile-time and won't change. On the synthetic target it would probably require reading /proc/cpuinfo during initialization, extracting the bogomips rating, and using that to calibrate a busy loop. The second way is to use one of the hardware clocks, possibly the system clock. Personally I do not like this approach, it adds a dependency on the hardware and is vulnerable to other code manipulating the clock. However currently this is the more common implementation. HAL_DELAY_US() is already used in various places, not just the I2C bitbang code, for example the lan91cxx ethernet driver. It is generally useful functionality. I would like to see the macro definition upgraded to make it compulsory rather than optional, and require the macro to be thread-safe. 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. 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