Handling non-standard I2C read response lengths with Wire library

Question

I'm trying to read from a Sam&Wing XW12A 12 channel touch sensor IC using I2C. The IC responds to an address read packet with 16 uninterrupted bits representing its state.

XW12A I2C signal per datasheet

However, since I2C usually uses 8 bit bytes separated with an ACK signal, the 9th bit is lost when the controller sends an ACK bit for the first 8 bits.

The controller is sending an ACK after the first 8 bytes

My current code, using the Wire library, is below:

Wire.beginTransmission(devAddr);
Wire.requestFrom((uint8_t)devAddr, 2);
uint16_t buf;
Wire.readBytes((uint8_t *)&buf, 2);

This will return a 16 bit value, with bits 0-7 correct, then bits 9-15 shifted along with bit 8 missing.

Is there a way to prevent the controller from sending ACK bits and read the continuous 16 bits using the Wire library? And if not, is there any other better approach than just bitbanging the signal manually?

---

Edit: I've translated the I2C section of the datasheet below.

I2C section of the XW12A datasheet translated

---

Edit 2: To prove that there's an issue, I've captured oscilloscope traces while bitbanging the address read header to the IC (but not sending ACKs). I've included a capture for each pad being pressed (and none pressed), you can see that pad 8 occurs on the first clock pulse after pad 7. If the IC was implementing I2C correctly, I would expect a gap of one clock pulse at this point while the IC waits for an ACK from the controller.

Oscilloscope traces for each pad being pressed when bitbanging the header.

• timemage: I think the documentation is just somewhat bad in that it doesn't show the an ACK where they almost certainly are. Not having one there would make this not I2C and not compatible with things that are I2C for no particularly good reason. Did you confirm that is this actually a problem? Or are you just noticing the lack of an ACK in the documentation?
• timemage: Don't know what to tell you. Section 4.6.3, when machine translated to English, seems to describe standard I2C behaviour for ACK/NAK at each 9th bit. You even received the four padding '1' bits on the end that they described to make the actual data bits, to be padded to 16. Anyway, if you want to do something like I2C but not have the ACK/NAK where it is required by the I2C standard, then yes you'd need to bit-bang. But, I don't see putting that as answer because I don't think it has anything to do with the actual problem. So far as I can tell, your diagram is just a better diagram.
• chrisl: Can you please explain in more detail why you think that the bit for Pad8 is missing? In the question I don't see much supporting your theory that the ack should not be used (besides the last image in the datasheet snippet. And I don't really trust that image)
• Jim: I've edited my question to add oscilloscope captures for each pad being pressed while bitbanging the header. If the IC was implementing I²C correctly, I'd expect to see a gap of one clock pulse between pad 7 and pad 8 as the IC waits for the ACK signal from the controller, but you can see that pulse for pad 8 follows directly on from pad 7.
• timemage: Ultimately, if this question is properly answerable by anyone, it's probably going to be by you. In which case, you could rewrite it as more of a "How do I use the Sam&Wing XW12A 12 channel touch sensor IC with Arduino", maybe make reference how a conventional I2C reading code fails, and then present what you've learned above cleaned up in an answer. Just so they're not reading the saga. If you go that route it may make more sense to delete this question and present the your own Q&A in one go under a new question.