AVR Freaks

Habit?

Because the code was copied from somewhere where it did matter?

Maybe like people put in extra brackets to be sure - even thought they not strictly required?

can you tell that I'm just guessing ?

You can also do 

my_num = 256*highbyte + lowbyte, which gives the same result, but it's easier to understand.

or   

my_24bitter = 65535*byte2 + 256*byte1 + byte0     for 24 bits

As us digital guys say....don't get bit

A union ? ;-)

not so sure about "easier to understand" ?

By writing the shift, you show explicitly that you are just taking a block of 8 bits, and putting them into the top byte.

I think a multiplication rather "hides" that.

YMMV.

This sound like "one country, 2 systems", can't remember where I heard that.

not so sure about "easier to understand" ?

Oh certainly can be, if you are good in hex

say you have a two byte number:

0x0A26   (0x0A,26)   that's  10*256 +32+6 =2598 , I did it in my head in a few seconds, while you are still getting shifty with the local bits. 

Of course this does raise the question of "endianism"

That brings up a very excellent & often overlooked point! In this post, the high & low bytes were assumed to be already known, so no problemo.   Of course, when you don't know (or overlook)--that has sunk a few ships!   It's almost as bad as some chips (such as DAC's) shift in msb first, and others lsb first....just to keep us our toes.   Things seems to "work" but the results are chaotic indeed.

Jim here is an example of using a union:

#include <stdint.h>

union
{
    struct adc_tag
    {
        uint8_t adc_low_byte;   //can swap bytes here by changing order of high/low
        uint8_t adc_high_byte;
    } adc_dat;
    uint16_t adc_val;
} adc_u;

int main(void)
{
    volatile uint16_t p;
    // Insert code

    do
    {
    /* store adc bytes into structure */
        adc_u.adc_dat.adc_low_byte = 0x55;
        adc_u.adc_dat.adc_high_byte = 0xAA;
    /* retreive adc as integer value */
        p = adc_u.adc_val; //p = 0xAA55
    }
    while(0);

    return 0;
}

Hope that helps, note by changing the order of the high/low bytes in the structure the bytes can be swapped when read as the integer value.

Jim

Jim it's really simpler than you might imagine. A union is just "two types of variable on top of one another" (and before the purists tell me "no it isn't" bear with me as that is the easiest way to imagine it). So if I simply type:

union {
    int n;
    char bytes[2];
} foo;

I am creating a "combined variable" that occupies two bytes and those two bytes can be identified as either foon to write to the full 16 bit (2 byte) item in one go:

foo.n = 12345;

but if you look at 12345 in hex it is 0x3039. So in memory there is either:

location of "foo":    0x30
location of "foo" +1: 0x39

or the compiler might have chosen to store it as:

location of "foo":    0x39
location of "foo" +1: 0x30

The first would be "big endian" and the second is "little endian" (and is what AVR compilers would use).

But in the definition of the union we said that these two locations would either be treated as one int or two chars with names bytes[0] and bytes[1]. So we could read things back out that way. If you said:

char bar = foo.bytes[0];

then bytes[0] will be located at the same byte as the lower byte of foo.n so bar will get the value 0x39. Reading foo.bytes[1] would return 0x30 - the upper byte.

Or you can work this backwards - if you want to write the bytes and read the int then:

foo.bytes[0] = 0xBC;
foo.bytes[1] = 0x47;

int result = foo.n;

So after the first two writes:

foo  : 0xBC
foo+1: 0x47

now when that is read to "result" from foo.n it will read 0x47BC which is 18,364.

There is a little complication in what I wrote (as I wanted to keep the example simple with "char" and "int") in that I used just "int" and not "unsigned int" and by implication that means I'm using "signed it". So if my later example was:

foo.bytes[0] = 0x83;
foo.bytes[1] = 0xC2;

then the combined value is 0xC283 but that is not simply 49,795 but actually -15,741 because it is signed. My original example should really have been:

union {
    uint16_t n;
    uint8_t bytes[2];
} foo;

to make the size and signage of the components more obvious.

So I can do:

Or I can do:

The first combines 2 bytes into one 16 bit int. The second splits one 16 bit int into 2 bytes.

 HighByte=temp.Bytes[1];  //Get the High Byte (255)
 LowByte=temp.Bytes[0];   //Get the Low Byte (255)

which seems like the "wrong order" to me - I'd be tempted to read [0] first and [1] second but in either case:

LowByte=temp.Bytes[0];   //Get the Low Byte (255)
HighByte=temp.Bytes[1];  //Get the High Byte (255)

that is saying "low in the first of the two bytes and high in the second" which to me sounds an awful lot like "little endian".

Endianism is perhaps more obvious still if you trade up from 2 byte to 4 byte variables but if I write:

uint32_t foo = 0xDEADBEEF;

then there are two ways this might be stored in memory:

foo  : EF
foo+1: BE
foo+2: AD
foo+3: DE

or

foo  : DE
foo+1: AD
foo+2: BE
foo+3: EF

even reading those vertically it's easier to "see" the variable in memory when it is big endian (the latter) but this is more pronounced if you read horizontally (as you might in a debugger or hex dump program) One looks like:

foo: EF BE AD DE (little endian)

and the other as:

foo: DE AD BE EF (big endian)

The AVR (and Intel PCs) would be using little endian so the lowest byte you come to is the least significant byte. So if you positioned a byte[4] array over this [0] would be EF, [1] would be BE, [2] would be AD and [3] would be DE.

as with so many things in C you have options. I personally am a HUGE fan of typedefs so while I could just use:

#include <stdio.h>
#include <stdint.h>

union {
    uint16_t n;
    uint8_t bytes[2];
} foo;

int main(void) {
    foo.n = 12345;
    etc

as I did in my examples in post #37 in reality what I personally would use is:

#include <stdio.h>
#include <stdint.h>

typedef union {
    uint16_t n;
    uint8_t bytes[2];
} joined_t;

joined_t foo;

int main(void) {
    foo.n = 12345;

That is I would start by typedef'ing a union which creates a new C type called "joined_t" so if I want to create more than one of these I could:

joined_t foo;
joined_t bar;
joined_t boo;

or, perhaps importantly if I want to pass one into a function I could use:

int processData(joined_t join) {
    if (join.bytes[0] > 0x80) {
        // something
    }
}

Oh and as for where to instantiate the variables you can go for global:

#include <stdio.h>

joined_t foo;

int main(void) {
    foo.n = 12345;
}

or you could go for local:

#include <stdio.h>

int main(void) {
    joined_t foo;

    foo.n = 12345;
}

It's up to you really. The computer science purists would say localise and limit name scope as much as possible so keep it local to the function where it is used. But maybe this thing needs to be "seen" across more of the software - in which case the choices are either global or you pass the object (or a pointer to the object?) around to anyone who needs to access it.

I think it is easier and better to just say  myresult= 256*highbyte + lowbyte.  You can easily pick up your calculator & follow along, anyone can readily check the code to verify the correct results are computed, & even the poor compiler will readily work with you.

This is certainly a very complicated undertaking!