Capacitive Touch and I2C

Hello,

is it possible, to use the Capacitive Multi Touch Display and the I2C1 in parallel? Is it possible to use I2C2 for the Touch Display?
Would it work with Capacitive Touch Display - 7 inch?
For me it seems as if i initialise I2C (Old Library) the Touch Driver stops working.
Is this solved with the newer Library?

Best regards,
Stefan

There’s a global mutex which prevents parallel access of multiple processes to the i2c bus.
Between the calls of GetI2CLock()and ReleaseI2CLock() in your application, the i2c bus is blocked for all other processes, and the touch driver cannot communicate with the touch screen.

This is the same in the new libraries.

@andy.tx: Thank you for your Reply.

I used it like this:

Public Shared Function SendData(ByVal data As Byte(), ByVal id As Byte, ByVal Offset As Byte) As Boolean

        Dim result As Boolean

        I2C.I2CInit()
        I2C.I2CSetSpeed(I2C.Speed.I2C_400KBPS)

        If (I2C.GetI2CLock(500)) Then
            result = I2C.I2CBurstWrite(id, data, Offset, data.GetLength(0)) // Library Function

        Else

            result = False
        End If
        ReleaseI2CLock()
        I2C.I2CDeInit()

        Return result

    End Function

My original Question targeted if the parallel touch display could use another I2C than I2C1.
Or if i could use another I2C than the Display. Or if i could share the I2C with a Display.

Best regards, Stefan

Details depend on the exact driver you are using. If you go with the Unified Multi Touch Driver, you can (and have to) adjust everything in your adaptation layer, so you can use any I2C channel to communicate with the touch display.

All our finished drivers assume that the capacitive touch is connected to I2C1.

For your own application you can use any I2C instance, including the one which is used for the touch controller. However, be aware that the bus load on the I2C channel can be quite high if somebody moves his finger over the touch panel. Significant delays for the other application on the same I2C bus might be the consequence.

On the old library API, you need to provide a base address to use any other channel than I2C1. I recommend using the new API, but wait for the next release V2.1. In the current release V2.0 there is a bug regarding Mutexes.