From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4587 invoked by alias); 11 Jul 2002 06:52:11 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 4580 invoked from network); 11 Jul 2002 06:52:10 -0000 Received: from unknown (HELO executor.cambridge.redhat.com) (195.224.55.237) by sources.redhat.com with SMTP; 11 Jul 2002 06:52:10 -0000 Received: from zoftcorp.dk (dell-paw-2.cambridge.redhat.com [195.224.55.226]) by executor.cambridge.redhat.com (Postfix) with ESMTP id CF1CFABB01 for ; Thu, 11 Jul 2002 07:52:09 +0100 (BST) Received: by zoftcorp.dk (Postfix, from userid 500) id 5AF4819C1A0; Thu, 11 Jul 2002 08:52:08 +0200 (CEST) From: Jesper Skov Cc: eCos Discussion In-Reply-To: <20020710171857.A6837@visi.com> References: <1026337830.15020.5750.camel@hermes.chez-thomas.org> <20020710171857.A6837@visi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 10 Jul 2002 23:52:00 -0000 Message-Id: <1026370328.8108.25.camel@amber.zoftcorp.dk> Mime-Version: 1.0 Subject: Re: [ECOS] Big endian ARM HAL_WRITE_UINT8 problem (ecos 1.3.1) X-SW-Source: 2002-07/txt/msg00138.txt.bz2 On Thu, 2002-07-11 at 00:18, Grant Edwards wrote: > > Instead of using 0x0400c71f, try using the address as it would be in > > little endian form 0x0400c71c. > > If you want to write to address 0x71f, you specify address > 0x71c? Doesn't anybody else thing that sounds a bit wierd? I > guess I understand what's going on, but it seems a bit silly to > make users of big-endian hardware munge up their register > addresses. > > If I need to write to the byte at address 0x71f, then I want to > write 0x71f in my source code: that's why I don't use those > macros -- they don't work with pre-existing include files > containing my register definitions. You are using register definitions that are munged for big-endian hardware and clearly expected to be used by non-portable (big/little endian) software. If you want to use them with eCos macros, it will clearly fail since the eCos macros are endian safe. How's that? Well, the device you are writing to is activated (chip select) by matching of address lines A31-A2. I.e. addresses 0x71c, 0x71d, 0x71e and 0x71f all match and enable your device for access. It doesn't care about anything else. So when the chip select is right, you need to get the data bits right. Depending on the endianess of the CPU, you need to put the data in either D0-7 or D24-D31 for 8bit access. You do that by changing A1-A0. So A1-A0 should be depending on the CPU endian mode, and *nothing else*. If you don't care about portability, and want to use definitions that are not suitable for porting, by all means don't use the eCos macros. But don't blame the macros for bothing it when fed bad definitions. The macros do exactly what they were designed to; making the software portable. Changing one endian definition flag is easier than changing umpteen register definitions. Jesper -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss