From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22533 invoked by alias); 21 Nov 2008 16:42:08 -0000 Received: (qmail 22214 invoked by uid 22791); 21 Nov 2008 16:42:06 -0000 X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from lon1-post-3.mail.demon.net (HELO lon1-post-3.mail.demon.net) (195.173.77.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 21 Nov 2008 16:41:13 +0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by lon1-post-3.mail.demon.net with esmtp (Exim 4.69) id 1L3Z4A-0001WP-eB; Fri, 21 Nov 2008 16:41:10 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id BE066138703; Fri, 21 Nov 2008 16:41:08 +0000 (GMT) To: =?utf-8?b?SsO8cmdlbiBMYW1icmVjaA==?= =?utf-8?b?dA==?= Cc: "ecos-devel@ecos.sourceware.org" Subject: Re: hal/arm/at91/../var_io.h: HAL_ARM_AT91_GPIO_GET References: <4926D675.4080702@televic.com> <4926E071.70706@televic.com> From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Fri, 21 Nov 2008 16:42:00 -0000 In-Reply-To: <4926E071.70706@televic.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2008-11/txt/msg00048.txt.bz2 J=C3=BCrgen Lambrecht writes: > Nick Garnett wrote: > > J=C3=BCrgen Lambrecht writes: > > > > > >> Hello, > >> > >> The current implementation of HAL_ARM_AT91_GPIO_GET in > >> hal/arm/at91/../var_io.h uses the AT91_PIO_PDSR register. > >> But, "Reading the I/O line levels requires the clock of the PIO > >> Controller to be enabled". So if you forget to enable the related PIO > >> clock, this HAL_ARM_AT91_GPIO_GET always fails! > >> Therefore, I propose to use the AT91_PIO_ODSR register. > >> Anyhow, the added value of PDSR over ODSR is small I think: > >> -with ODSR you read the value you want this pin to be > >> -with PDSR you read the actual (physical) value of this pin > >> They are only different if there is a hardware problem.. > >> > > > > Without reading the documentaion: the ODSR give you the contents of > > the output latch, while PDSR reads the line value. ODSR and PDSR > > should agree for output pins, but for inputs the ODSR may differ from > > the line level, since it is no longer connected to the pin and pin is > > being driven to its current level by some external device. > > > Indeed. So in general, my proposition is wrong. > I then propose to make an "OUT" version of that macro. > > Also, surely if you are using a GPIO port you should be enabling its > > clock. I would consider not doing that a programming error. > > > No, only for an input you must enable the PIO clock: the PIO clock is > then used to sample the input signal. > For an output, you just write the output register from your > application, using the application clock. OK. In that case a macro that reads back the value set in the output register might make sense. Of course one can make the argument that since your code must have set this value initially, it shouldn't have to read it back to know what it is. However, I appreciate that code is not always structured to allow you to do that. --=20 Nick Garnett eCos Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No: 4422071