Go Down

Topic: lowByte and highByte are not really byte functions (Read 2695 times) previous topic - next topic


May 30, 2009, 09:29 pm Last Edit: May 30, 2009, 09:32 pm by lefstin Reason: 1
The reference page states that lowByte and highByte return a byte.  This appears not to be the case.

I discovered this when making a call like:
Code: [Select]

if i2cdata is type int, this works fine.  If i2cdata is type word, a compiler error is generated.

I am not sure exactly why but I suspect it has to do with the way lowByte and highByte are implemented in Wiring.h:
Code: [Select]
#define lowByte(w) ((w) & 0xff)
#define highByte(w) ((w) >> 8)

so what type you get from highByte and lowByte depends on what you feed them.

You can easily fix this by using (byte)lowByte(xxxx) but it is cetainly counter-intuitive.


May 30, 2009, 10:38 pm Last Edit: May 30, 2009, 10:41 pm by lefstin Reason: 1
To show this more clearly:
Code: [Select]

void setup() {
int d, c, a = 0xffff;
byte b;


b = lowByte(a);
c = sizeof(b);

d = sizeof(lowByte(a));

Serial.print(" ");


void loop(){}

produces the output:
Code: [Select]
1 2
showing that with an int argument lowByte returns an int value.


C essentially specifies that all intermediate values in calculations are of at least type 'int', which occasionally causes assorted problems with attempts at optimization.  But I'm not sure why "Wire.send(lowByte(i2cdata));" would cause a compiler error (what's a "word"?); aren't arguments automagically truncated to correct size?

Go Up