From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17639 invoked by alias); 10 Nov 2003 22:00:01 -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 17584 invoked from network); 10 Nov 2003 21:59:58 -0000 Received: from unknown (HELO mailgate.bolloxnet.com) (80.196.130.32) by sources.redhat.com with SMTP; 10 Nov 2003 21:59:58 -0000 Received: from bollox ([192.168.5.2]) (authenticated user ecos@soeberg.net) by mailgate.bolloxnet.com for ecos-discuss@sources.redhat.com; Mon, 10 Nov 2003 22:56:40 +0100 From: "Philip Soeberg" To: Date: Mon, 10 Nov 2003 22:00:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <1068496486.9906.71.camel@hermes> Subject: [ECOS] Deciphering ISO C (Chap 6.3.2.3 - Pointers) X-SW-Source: 2003-11/txt/msg00136.txt.bz2 Message-ID: <20031110220000.FMWe8s0Ze789DY2W9egH1y4fyLAGac8Otgl88fQStt8@z> Hi, I'm having weird difficulties with the flash_am29xxxxx.inl file, whereas I have created this cut-down version of what appears to be my problem: ------------- The code-example further down was created from analyzing line 216-217 in file flash_am29xxxxx.inl: ROM =3D (flash_data_t*) CYGNUM_FLASH_BASE; f_s1 =3D FLASH_P2V(ROM+FLASH_Setup_Addr1); Resulting output after preprocessing is: ROM =3D (flash_data_t*) (0x00000000u); f_s1 =3D ((volatile flash_data_t *) \ ((CYG_ADDRWORD)((CYG_ADDRESS)ROM+(0x555)))); The value in f_s1 must be 0x555 for the AMD chip to work in word mode (as far as I have read) ... but "diag_printf("%x", f_s1)" yields 0xAAA :( ------------- I can't seem to find the logic in why this example doesn=92t work: cyg_uint16* res_16; cyg_uint16* p_16; cyg_uint16 u_16; p_16 =3D 0x0u; u_16 =3D 0x0u; res_16 =3D (p_16 + 0x555u); The above code yields res_16 =3D=3D 0xaaa I was sort of hoping for 0x555 instead... Altering the addition line to this: res_16 =3D (cyg_uint16*)(u_16 + 0x555); corrects the problem...=20 why? The platform is a 32bit. Trying to decipher the first addition, I get: 32bit_u =3D (32bit_u + 32bit_u) assuming that the pointer =93cyg_uint16 *=94 is 32bit... ------------- I hope one of you can shed some light to this problem of mine :) Regards, -=3D[ Philip Soeberg ]=3D- -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss