Touch panel driver AR1021: I2C and SCL streching

[lpcware]

Content originally posted in LPCWare by giusloq on Wed Jun 24 08:35:07 MST 2015
I'd like to use AR1021 touch panel controller with LPC1788 in I2C mode.

I read in AR1021 datasheet that the clock can be stretched (keeped low) by the slave after each byte. The master (LPC MCU) should monitor the clock line after the nineth pulse and should wait until it goes high again, before continuing with the first clock pulse of the next byte.

I was studying LPC datasheet, but I couldn't understand if the "clock streching" as used by AR1021 is compatible with syncronization logic performed by LPC:

---

Quote:
The synchronization logic will synchronize the serial clock generator with the clock pulses on the SCL line from another device. If two or more master devices generate clock pulses, the “mark” duration is determined by the device that generates the shortest “marks,” and the “space” duration is determined by the device that generates the longest “spaces”. Figure 117 shows the synchronization procedure.
A slave may stretch the space duration to slow down the bus master. The space duration may also be stretched for handshaking purposes. This can be done after each bit or after a complete byte transfer. the I2C block will stretch the SCL space duration after a byte has been transmitted or received and the acknowledge bit has been transferred. The serial interrupt flag (SI) is set, and the stretching continues until the serial interrupt flag is cleared.

---

If the two mechanism are compatible, is this automatic?

[lpcware]

Content originally posted in LPCWare by giusloq on Mon Jun 29 05:46:11 MST 2015
I found the point where to add the delay before the Stop Bit. It's in the handleMasterXferState() function.

int handleMasterXferState(LPC_I2C_T *pI2C, I2C_XFER_T  *xfer)
{
uint32_t cclr = I2C_CON_FLAGS;

switch (getCurState(pI2C)) {
case 0x08:/* Start condition on bus */
case 0x10:/* Repeated start condition */
pI2C->DAT = (xfer->slaveAddr << 1) | (xfer->txSz == 0);
break;

/* Tx handling */
case 0x18:/* SLA+W sent and ACK received */
case 0x28:/* DATA sent and ACK received */
if (!xfer->txSz) {
volatile int del = 5000;
while(del--);
cclr &= ~(xfer->rxSz ? I2C_CON_STA : I2C_CON_STO);
}
else {
pI2C->DAT = *xfer->txBuff++;
xfer->txSz--;
}
break;

Actually I add the short delay with a loop on a decrementing volatile variable. I don't know the exact delay I introduced. I can measure and calibrate the starting value, but it depends on working frequency, compiler optimization and so on.

I think there is a better approach.

[lpcware]

Content originally posted in LPCWare by giusloq on Thu Jun 25 02:26:20 MST 2015

---

Quote:
The I2C master of the LPC1788 does support clock stretching. It is automatic, no need to do something special.

---

That's good. Indeed it seems to work when I read touch data from the controller. I'm using Chip_I2C_MasterRead() in polling mode.

But I found another problem. AR1021 is capable to receive several commands for some operations (GET VERSION, CALIBRATE and so on). On the datasheet is written:

---

Quote:
A 50us delay is needed before the Stop bit, when clocking a command to the AR1020.

---

Is possible to introduce this delay with LPC I2C peripheral?

[lpcware]

Content originally posted in LPCWare by wmues on Wed Jun 24 13:54:28 MST 2015
The I2C master of the LPC1788 does support clock stretching. It is automatic, no need to do something special.