next topic »

[on:]

Hi all,

A simple question. Does the C/C++ implementation on ATMega chips follow the little endian or big endian format?  That is, for a pointer to an integer, does the pointer give the address of the least significant byte or the most significant byte?  I want to write an integer value to EEPROM and the question is if I should increment or decrement the pointer value.

Thanks.

Ed

[Reply #1 on:]

Little. You can go to the main page www.arduino.cc and use the search box at the top of it, it gives better results than trying to use the forum search box = )

[Reply #2 on:]

John_Ryan is correct: the processor is little endian.  However, if you are using this information to decide whether to "increment or decrement the pointer" to the integer you may be surprised at the result.  Incrementing an integer pointer will not generate a pointer to the high-order byte, but to the next integer instead.  (You may know all this already for all I know.)  It might be a good idea to just use this technique, which will work with any "endianness":

Code:

//writes myint to EEPROM at offset 0/1
EEPROM.write(myint % 256, 0);
EEPROM.write(myint / 256, 1);

Mikal

[Reply #3 on:]

Thanks MikalHart and John_Ryan. I hadn't realized the issue about incrementation pointing to the next integer; I thought that only occurred in arrays. That is very useful.

I had thought about MikalHart's option using a shift operator. The only caveat is that the first argument of EEPROM.write() would need to be typecast to type byte.

Again, thanks.

Ed

[Reply #4 on:]

I had thought about MikalHart's option using a shift operator.

Yes, that would be even better!

Code:

EEPROM.write((byte)myint, 0); // write low order byte
EEPROM.write((byte)(myint >> 8), 1); // write high order byte

Mikal

[Reply #5 on:]

Ever since the 80s, C compilers generally recognize "take an int and divide it by a constant power of two" and then if the target processor prefers it, to replace it with a "shift to the right" operation automatically.

You're welcome to put (x >> 3) in your code, but if you feel like making the code more readable, and you prefer to think of it as dividing by eight, then don't feel like it's bad to put (x / in your C source code.

Source code is more for the humans than for the machines.  Be expressive.  Simple things like this generally get optimized to the best equivalent code for the platform, within reason.

[Reply #6 on:]

Be expressive.

Quite right.  And I tell my students this.  But in this case, the operation I am trying to express is not a division but a shift.  When I write "myint >> 8", I am not trying to give the compiler a hint on a clever way to divide by 256; I am telling it that I want a shift so that I can access the high bits.  I don't "feel that it's bad" to write "myint / 256" -- I even proposed that earlier in the thread -- but it less directly expresses the operation I want and therefore is less readable.

Mikal

[Reply #7 on:]

Totally agree.