32 bit memory writted backwards????

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi all...

guys I have a little problem I am trying to understand.. Ok. I am developing
an application with a miniwebserver on an embedded board with msp430 and
working with IAR embedded workbench. I have to read variables that will be
introduced in certain memory positions that will be reserved. So My
application goes to memory position, say, 0x220 and reads 16bits then uses
them to display them on a webpage. So far so good. Since this variables will
be introduced through an assember interrupt that will get them from outside
my micro, I don't have to worry about them. BUT, to do the development I had
to crerate a simulator that writes fictious info into this memory positions
to, afterwards, read it.  All the variables in 16 bits work smoothly, but 32
bit variables have this WEIRD behaviour: they are written backwards in
chunks of 16bits.... for example, if I write  0x00201582 as a 32 bit value,
once reading the memory map of my board will be shown as: "1582" on memory
position 0x224 and "0020" on memory position 0x226.... My question is, are
my writting functions wrong and I am doing this myself, or is it some sort
of standard I should have been aware of and, thus, I have to add
calculations to invert the order of this numbers? I add some of my code to
make this more understandable:


//here I define the "reserved" memory positions for some variables


#define 1st16bitvar         ((uint16_t*)0x0220)
#define 2nd16bitvar         ((uint16_t*)0x0222)
#define 1st32bitvar         ((uint32_t*)0x0224)
#define 2nd32bitvar         ((uint32_t*)0x0228)

//here I build the functions to write info onto memory positions. I call it
"simulator"

INLINE void
wr_mem16(volatile uint16_t *p, const uint16_t v)
{
*p=v;
}

INLINE void
wr_mem32(volatile uint32_t *p, const uint32_t v)
{
*p=v;
}

//here I write info onto the memory positions


void WriteMem(void)
{

wr_mem16(1st16bitvar,0x0006);
wr_mem16(2nd16bitvar,0x0FA1);
wr_mem32(1st32bitvar,0x00201582);
wr_mem32(2nd32bitvar,0x00067A50);

}


//after all this I just read the functions and display them. However, this
other part is unimportant since what I am worried about is the memory map
and my functions to read cannot write over this. So, after what you've seen,
the memory map will look like this:

position            value
0x220                 0006   //as you can see, everything is written
properly here
0x222                 0FA1  //as well as here
0x224                 1582   // But what the hell is this doing here¿?
0x226                 0020    //and this is the end of the begining ¿?
0x228                 7A50  //again the same....
0x22a                 0006


As you can see I am a little lost about this. Any guru can throw some light
upon this?

Cheers,

Yodai



Re: 32 bit memory writted backwards????
: Hi all...
:
: to, afterwards, read it.  All the variables in 16 bits work smoothly, but 32
: bit variables have this WEIRD behaviour: they are written backwards in
: chunks of 16bits.... for example, if I write  0x00201582 as a 32 bit value,
: once reading the memory map of my board will be shown as: "1582" on memory

<snip>

Search google for "big endian" and "little endian"

This should explain what's going on.

-buddy

Re: 32 bit memory writted backwards????
Quoted text here. Click to load it

The order of the words in memory is a choice by IAR.  It is their
standard way of storing a 32-bit integer.  Compilers are free to use any
byte order, as long as they are consistent.

Thad

Re: 32 bit memory writted backwards????
Quoted text here. Click to load it

The compiler's byte order had better be in agreement with that
of the target processor.  Otherwise, there's going to be a lot
of byte-swapping code for multi-byte operations.

There's the right way and then there's the Little-Endian way...

Re: 32 bit memory writted backwards????
Quoted text here. Click to load it

What, you think it's right to write the highest order byte at the lowest
address?  ;^)

--
Ron Sharp.
Oh no, not again...




Re: 32 bit memory writted backwards????
On Tue, 28 Oct 2003 10:25:17 PST, snipped-for-privacy@iwvisp.com (Everett M.

Quoted text here. Click to load it

The "right way" may be the best format if you do mostly divisions,
however, the Little-Endian format is quite nice if you do mostly
additions, subtractions and multiplications. For logical operations
(AND, OR, XOR, NOT) the order is irrelevant.

Paul


Re: 32 bit memory writted backwards????

Quoted text here. Click to load it

I'll venture a guess you're not a big Intel fan.  You probably love Motorola.  
And you like to wear socks and your underwear inside-out.  That last part was
a joke by the way.  Couldn't resist.

LT

Re: 32 bit memory writted backwards????

Quoted text here. Click to load it


That's correct, but it's assuming the target processor *has* a defined
byte order for 32-bit integers in the first place.  A 16-bit processor
isn't particularly likely to.

E.g. for the 8051 family, about the only part of the instruction set
that cares about the byte order in memory would be the call stack,
because the instruction pointer is the only atomic 16-bit object in
the whole processor.  Which leaves the decision about multibyte
integer storage patterns completely up to the compiler designers.
--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: 32 bit memory writted backwards????
On 29 Oct 2003 11:09:44 GMT, Hans-Bernhard Broeker

[...]
Quoted text here. Click to load it

IIRC, the 8051 pushes the return address from an LCALL to the stack
little-endian, but expects the destination address in the LCALL
instruction itself to be big-endian.

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Site Timeline