--- In David Hawkins <> wrote:
>
> Hi Yan,
>
> > I get the values I would expect when I cast
> > everything to uint32_t but uint16_t types
> > *always* start with 0x8c.
>
> It could be due to access of a 16-bit only,
> or 32-bit only register using smaller values.
That's a good point, one I haven't thought of...
The one thing that puzzles me is that 32-bit access on a 16-bit
boundary works fine.... I guess I don't understand the ARM hardware
as well as I should.
>
> Run your test on an address in SDRAM which has
> all 32-bits working, and byte-enables working,
> and see if you get identical results.
How do I enable byte-enables?
>
> Also add some variables to your code to store
> the casted values, and call them volatile,
> just to force the compiler to leave them alone
> for the purposes of this test.
>
> I had a problem once with an x86 host performing
> read-modify-write operations using an I/O register,
> when it really should have been using a
> processor register; so optimization may cause you
> to see a different result too.
>
> Look at the assembler code if its a small program,
> or you can easily isolate the code section. It'll
> show you whether 8-bit/16-bit/32-bit instructions
> are being used for a particular piece of code.
I'll have to write a small test proggie, but I gave up on assembler
back in my IBM360 days... It just doesn't agree with me... :-(
--Yan
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|