Makerfabs TFT 7" board with gt911 doesn't reset properly

[RetiredWizard]

When attempting to use the Makerfabs TFT 7" display board with this library the board won't initialize, complaining that the touch screen can't be found at either the primary or secondary I2C address. The makerfabs board pulls the int line high which I believe causes the display to initialize but somewhat randomly selects the primary/secondary I2C address (since the INT pin is tied high and can't be used as intended, I've been omitting or passing None for the INT pin on library calls - the pin is actually not even made available on the board I'm using :grin:).

I'm not all that good at reading datasheets so I don't really understand the reset code. I did attempt to lift the reset logic from various arduino gt911 examples and was able to get the makerfabs board to initalize properly and when I compare my reset logic to the logic used in this library there are a few differences.

I went ahead and ported my reset logic into this library (leaving the original code in as comments) which made this library work with the makerfabs/gt911 board.

After staring at my new version for a bit, I realized most of the differences came down to some differences in the sleep times so I made a version of the reset that only changed some of the timing and that also works with the makerfabs board. I don't have any other gt911 displays to test with and I suspect simply using my version of the reset won't work in the general case, but I'm hoping that someone that understands the reset process closer might be able to generalize the two versions to work more generally.

    def _reset(self) -> None:
        """If the reset pin is defined, the device can be reset. If the interrupt pin is also
        defined, device can be reset into a specific I2C address configuration.
        """
        if not self.rst_pin:
            raise RuntimeError("RESET pin must be configured to reset device.")

        time.sleep(.0001)
        self.rst_pin.switch_to_output(True)  # Switch pin to output, high
        if self.int_pin:
            self.rst_pin.switch_to_output(False)  # Switch pin to output, low
        time.sleep(.005)

        self.rst_pin.value = False  # Stop the device
        time.sleep(.001)

        # Interrupt pin modifies I2C addressing (High: 0x14 | Low: 0x5D)
        if self.int_pin:
            # Set interrupt pin value in Open Drain mode.
            self.int_pin.switch_to_output(
                self.int_high, drive_mode=digitalio.DriveMode.OPEN_DRAIN
            )
            time.sleep(0.0001)  # Wait >10μs

        time.sleep(.001)

        self.rst_pin.value = True
        if self.int_pin:
            time.sleep(0.005)  # Wait >5ms
            self.int_pin.switch_to_input()  # Listen for interrupts
        time.sleep(.12)

[rgrizzell]

The makerfabs board pulls the int line high which I believe causes the display to initialize but somewhat randomly selects the primary/secondary I2C address

The LILYGO T-Deck also pulls the INT line high and exhibits the same behavior. It's confusing to troubleshoot since it really only triggers on device hard-reset vs soft-reset.

I'm not all that good at reading datasheets so I don't really understand the reset code. I did attempt to lift the reset logic from various arduino gt911 examples and was able to get the makerfabs board to initalize properly and when I compare my reset logic to the logic used in this library there are a few differences.

I can relate. This library was my first experience interpreting datasheets and writing a driver. I used a lot of Arduino and MicroPython examples to piece it together. I appreciate your help sorting out the reset logic because it's the one area of the code I wasn't able to fully test without control over the INT pin.

I realized most of the differences came down to some differences in the sleep times so I made a version of the reset that only changed some of the timing and that also works with the makerfabs board

This makes a lot of sense. I'll give your changes a test on the T-Deck and see if it fixes the addressing flipping I was seeing before.