Parsing Byte Array using a struct

Projects Programming
1

Hi, im using a display that has a GT911 touch controller. I downloaded the library from here (https://github.com/nik-sharky/arduino-goodix/blob/master/GT911_touch.ino).
The issue is when it outputs the touch positions its wrong. The main thing im trying to understand is how this process works in this library (so i can understand why its not working correctly)

Basically he has an array defined like this

uint8_t points[GOODIX_MAX_CONTACTS*GOODIX_CONTACT_SIZE]; //points buffer

And he has a struct defined like this which lines up with the order of the data output in the order of data in the chips registers

struct GTPoint {
  // 0x814F-0x8156, ... 0x8176 (5 points) 
  uint8_t trackId;
  uint16_t x;
  uint16_t y;
  uint16_t area;
  uint8_t reserved;
};

He then does the following when the method onIRQ is fired is calls readInput passing the points array reference and reads the data into the array.

void Goodix::onIRQ() {
  //uint8_t buf[1 + GOODIX_CONTACT_SIZE * GOODIX_MAX_CONTACTS];
  int8_t contacts;

  contacts = readInput(points);
  if (contacts < 0)
    return;

  if (contacts > 0) {
    touchHandler(contacts, (GTPoint *)points);

}


int16_t Goodix::readInput(uint8_t *data) {
     ....
     .....
      error = read(GOODIX_READ_COORD_ADDR+1, data, GOODIX_CONTACT_SIZE * (touch_num));
}

finally he returns the data to the main code via touchHandler and loops through the data

void handleTouch(int8_t contacts, GTPoint *points) {
   Serial.println("Contacts" + String(contacts) );
  for (uint8_t i = 0; i < contacts; i++) {
      Serial.print("TP" + String(i) + ":");
      Serial.print(points[i].trackId);
      Serial.print(" X:");
      Serial.print(points[i].x);
      Serial.print(" Y:");
      Serial.print(points[i].y);      
      Serial.print(" Area:");
      Serial.println(points[i].area);      
  }
}

The problem is its reading the touch position wrong and returning

Contacts1
TP0:0 X:24578 Y:4609 Area:0

So to check the data in the array is ok i added the following after the read command

	Serial.print("Id ");
	Serial.print((uint)(data[0]));
	Serial.print(" x ");
	Serial.print((uint)(data[2] )<<8 | (uint)data[1]);
	Serial.print(" y ");
	Serial.print((uint)(data[4] )<<8 | (uint)data[3]);
	Serial.print(" area ");
	Serial.println((uint)(data[6] )<<8 | (uint)data[5]);

i get which is correct

Id 0 x 610 y 366 area 18

So what im asking is how come when the data is parsed using the struct i seems to return odd values?
I would just like to understand why his way isnt working so i can fix it and also use it myself going forward

2

I'll guess that it is a packing issue. You will need to force that struct to be byte aligned.

3

I did read about that and I tried this

struct GTPoint {
  // 0x814F-0x8156, ... 0x8176 (5 points)
  uint8_t trackId:8;
  uint16_t x:16;
  uint16_t y:16;
  uint16_t area:16;
  uint8_t reserved:8;
};

But it didn't work ie the output was the same. Did I do the right change?

Thanks

4

gotty101:
I did read about that and I tried this

struct GTPoint {

// 0x814F-0x8156, ... 0x8176 (5 points)
  uint8_t trackId:8;
  uint16_t x:16;
  uint16_t y:16;
  uint16_t area:16;
  uint8_t reserved:8;
};




But it didn't work ie the output was the same. Did I do the right change?

Thanks

That code is identical to your original code. You need to use the packed attribute

struct __attribute__ ((packed)) GTPoint {
  // 0x814F-0x8156, ... 0x8176 (5 points)
  uint8_t trackId:8;
  uint16_t x:16;
  uint16_t y:16;
  uint16_t area:16;
  uint8_t reserved:8;
};
5

Thanks blh64

I did have a feeling it was the same, I got the idea from

I've not come across attribute ((packed)) but I just read it removes padding.
https://forum.arduino.cc/index.php?topic=215468.0

I didn't realise there was padding between variables, i thought at the end of the one started the next declared variable.

I'll give it a try tonight.

Thanks again

6

Just a quick update. Ive done the packing change and it worked perfectly. Ive since looked through the original library's git hub and it makes reference to esp32, so I wonder if that was why if that handles packaging slightly different.

Thanks again