unsigned Long Bug? I think so.

I read in three bytes, High, Mid and low.
Using: unsigned long tot = 0x00010000 * High + 0x0000100 * Mid + low

A B C D E F 10 11 12 13 14 15 16 17 18 19 1A
FFA FFB FFC FFD FFE FFF 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 100A
FFFA FFFB FFFC FFFD FFFE FFFF 0 1 2 3 4 5 6 7 8 9 A
1FFFA 1FFFB 1FFFC 1FFFD 1FFFE 1FFFF 20000 20001 20002 20003 20004 20005 20006 20007 20008 20009 2000A
1FFFFFA 1FFFFFB 1FFFFFC 1FFFFFD 1FFFFFE 1FFFFFF 2000000 2000001 2000002 2000003 2000004 2000005 2000006 2000007 2000008 2000009 200000A

unsigned long uLong;
void setup()
{
Serial.begin(115200);
Serial.println();
for( byte i = 0; i <= 16; i++)
{
uLong = 0xa + i;
Serial.print(uLong,HEX);
Serial.print(' ');
}

Serial.println();
for( byte i = 0; i <= 16; i++)
{
uLong = 0xffa + i;
Serial.print(uLong,HEX);
Serial.print(' ');
}

Serial.println();
for( byte i = 0; i <= 16; i++)
{
uLong = 0x0fffa + i;
Serial.print(uLong,HEX);
Serial.print(' ');
}

Serial.println();
for( byte i = 0; i <= 16; i++)
{
uLong = 0x1fffa + i;
Serial.print(uLong,HEX);
Serial.print(' ');
}

Serial.println();
for( byte i = 0; i <= 16; i++)
{
uLong = 0x1fffffa + i;
Serial.print(uLong,HEX);
Serial.print(' ');
}
}

void loop()
{
}

uLongBug.ino (794 Bytes)

Sorry for my first post. Don't know why it posted, I wasn't ready.

Anyway, I wasn't getting the results I expected. Then I discovered when the two highest bytes are zeroes (0X00001234) all math operations treat it as a 16 bit number. If the original assigned value contains any non zero bits in the two MSBs (0x00010000) then some math operations kind of work.

My test program shows the problem in the third line below.
I'm simply adding one and when the operation is 0x0000FFFF + 1 you get ZERO!! I expect 0x00010000
If you add 0x0001FFFF + 1 it equals 0x00020000 as expected.

I did a search on the forum and it appears that a lot of people are having strange results with ulongs!

If I'm not thinking correctly, let me know.
TIA, john

A B C D E F 10 11 12 13 14 15 16 17 18 19 1A
FFA FFB FFC FFD FFE FFF 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 100A
FFFA FFFB FFFC FFFD FFFE FFFF 0 1 2 3 4 5 6 7 8 9 A <<<<<<<<============ BAD DATA
1FFFA 1FFFB 1FFFC 1FFFD 1FFFE 1FFFF 20000 20001 20002 20003 20004 20005 20006 20007 20008 20009 2000A
1FFFFFA 1FFFFFB 1FFFFFC 1FFFFFD 1FFFFFE 1FFFFFF 2000000 2000001 2000002 2000003 2000004 2000005 2000006 2000007 2000008M

"Sorry for my first post. Don't know why it posted, I wasn't ready."
You can select Modify & update a post if needed.

Try putting UL while setting up the variables:

uLong = 0xffaUL + i;

uLong = 0x0fffaUL + i;

uLong = 0x1fffaUL + i;

uLong = 0x1fffffaUL + i;

You are using integer constants in hexadecimal form.

From "The C Programming Language" (K&R), second edition, Section A2.5.1, "Integer Constants":

... The type of an integer constant depends on its form, value and suffix...

... If it is unsuffixed octal or hexadecimal, it has the first possible of these types: int, unsigned int, long int, unsigned long int...

Note the use of "first possible", this means that without the "L" suffix to force it into a long type, it will be assigned to an int (16 bits on Arduino) if its value is within the range of ints (which it is in this case). Leading zeros are not the mechanism by which long integer constants are created, you need to explicitly suffix them.

Dang software - performing shortcuts that aren't wanted!

In fact you need to be cautious about leading zeroes, what do you suppose this prints?

void setup ()
  {
  Serial.begin (115200);
  Serial.println (0001232);
  } 

void loop () { }

Warning, the result may disturb some people. :wink:

Nick, you are ]:slight_smile:

:wink:

tks Brittain and others.

You fixed it. I get caught by this about once every four yrs. To bad I can't stick with one language. :frowning:

Best Regards