Serial.print(value,HEX) sometimes gives a series of FF before the actual value

Part of the code looks like this:

Wire.requestFrom(i2c_dev_address,10);
while(Wire.available()>0){
rct = Wire.read();
Serial.println(rct,HEX);}

The expected register values are : 80, 4, 53, 0, 0, 0, 9F, F6, 97, 35
But what I got is : FFFFFF80, 4, 53, 0, 0, 0, FFFFFF97, FFFFFFF6, FFFFFF97, 35

It looks like if the value's MSB is 1, it will have the FFFFFF prefix, can someone help to remove it?

wxs:
Part of the code looks like this:

Wire.requestFrom(i2c_dev_address,10);
while(Wire.available()>0){
rct = Wire.read();
Serial.println(rct,HEX);}

The expected register values are : 80, 4, 53, 0, 0, 0, 9F, F6, 97, 35
But what I got is : FFFFFF80, 4, 53, 0, 0, 0, FFFFFF97, FFFFFFF6, FFFFFF97, 35

It looks like if the value's MSB is 1, it will have the FFFFFF prefix, can someone help to remove it?

Try this:

byte n = Wire.requestFrom(i2c_dev_address,10);
for (int i=0; i<n; i++)
{
  rct[i] = Wire.read();
  Serial.print(rct[i],HEX);
  Serial.print(' ');
}

How is rtc declared ?
Presumably it should be a byte

See this thread: https://forum.arduino.cc/index.php?topic=631611.0

PieterP:
There is no "print" overload for int8_t, int:
Arduino/cores/esp8266/Print.h at e77f96c3e14c29714c072a7784614a3cae0abd47 · esp8266/Arduino · GitHub
Therefore, the compiler selects print(int, int). Since it is a signed number, it is sign extended to 32 bits, because if you have -1 as a int8_t, it's 0xFF, but as an int32_t, it's 0xFFFFFFFF, not 0x000000FF.

When printing, you can cast it to uint8_t, so it's not sign extended.

Serial.print((uint8_t)bmp_header[j], HEX);

Pieter

UKHeliBob:
How is rtc declared ?
Presumably it should be a byte

Sorry, shoulda mentioned it. it's just a char

wxs:
Sorry, shoulda mentioned it. it's just a char

When printing, you can cast it to uint8_t, so it's not sign extended.
Serial.print((uint8_t) rtc, HEX);

PieterP:
See this thread: Output not as expected (uint32_t to uint8_t) - Programming Questions - Arduino Forum

Pieter

Thanks!! This is the point. If I cast the rtc to unsigned or declare it as byte (unsigned char), the problem is gone.

If I cast the rtc to unsigned or declare it as byte (unsigned char), the problem is gone.

So why declare it as a char ?