32 bit memory writted backwards????

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

Reply to
Yodai
Loading thread data ...

Yodai wrote: : 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

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

This should explain what's going on.

-buddy

Reply to
buddy.spaminator.smith

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

Reply to
Thad Smith

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...

Reply to
Everett M. Greene

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

--
Ron Sharp.
Oh no, not again...
Reply to
Android Cat

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

Reply to
Paul Keinanen

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

Reply to
Loi Tran

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 (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker
[...]

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.
Reply to
Dave Hansen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.