adding support for the ST7796 + creating a new variant of the T-beam

[Nasimovy]

modified the existing library for the ST7789 to support the ST7796
created a new variant of the T-beam that supports the ST7796 shield

edit:
the touchscreen is not working yet, the address has been added to the scani2c, should i separate it?

🤝 Attestations

• I have tested that my proposed changes behave as described.
• I have tested that my proposed changes do not cause any obvious regressions on the following devices:
  • LilyGo T-Beam

[Nasimovy]

converted it to draft because i seem to get SPI related errors

[caveman99]

Looking good overall, though i'd prefer if you got the touchscreen working as well

[Nasimovy]

im trying lower SPI speeds for both the LORA module and the display because it looks like the tbeam is very EMI susceptible, or the ST7796 pumps out loads of EMI.

yesterday i had a SPI related error every ~20 minutes, also next to zero Bluetooth reception

i first want to resolve that issue before i start implementing the touchscreen

edit: resolved, Bluetooth reception is resolved with higher pinheaders

[Nasimovy]

hello, could somebody that has a device with a CST328 test if the detection is working properly?, the else case is the CST328, it detects the CST226SE

[mverch67]

The T-Deck Pro has a CST328.

Actually the scan result does not matter as the touch controller is hard-coded for the device variant.

[Nasimovy]

Hey, @mverch67 , @caveman99 , @thebentern , @vidplace7 , sorry for the ping in the first place.

I know it has been a long road for me to get it working properly as in no code duplication etc...

But i think the final version is good/proper, could you guys take a look at it and hopefully merge it?

kind regards, Wout
i don't want to sound pushy but i get or know that it for some would look like that.

[mverch67]

But i think the final version is good/proper, could you guys take a look at it and hopefully merge it?

PR7613 also integrates the ST7796 but via TFTDisplay as most other TFT displays do. It would be more homogeneous to also adopt this way for the tbeam display otherwise the code gets more and more confusing (e.g. ST7796_CS vs. USE_ST7796)...

[Nasimovy]

integrates the ST7796 but via TFTDisplay as most other TFT displays do ST7796_CS vs. USE_ST7796

i understand that code readability is important, but USE_ST7789 is also used with the same driver type as my use case of the USE_ST7796, the mui or the lovyangfx driver is to large to use on the esp32 i know that @Szetya got it working with lovyangfx but he had to exclude default included features.
So i don't really know the way forward.
An if T-beam case perhaps or a other way

thanks mverch67 for your input

[Szetya]

integrates the ST7796 but via TFTDisplay as most other TFT displays do ST7796_CS vs. USE_ST7796

i understand that code readability is important, but USE_ST7789 is also used with the same driver type as my use case of the USE_ST7796, the mui or the lovyangfx driver is to large to use on the esp32 i know that @Szetya got it working with lovyangfx but he had to exclude default included features. So i don't really know the way forward. An if T-beam case perhaps or a other way

thanks mverch67 for your input

USE_DISPLAYTYPE has its own driver.
And for DISPLAYTYPE_CS, lovyangfx.
This is exactly why the USE_DISPLAYTYPE macro was introduced.

[Copilot]

Pull Request Overview

This PR adds support for the ST7796 display controller to create a new T-beam variant with the ST7796 display shield. The changes enable a new hardware configuration with touchscreen support using the CST226SE touch controller.

• Modified existing ST7789 library integration to support ST7796 displays
• Created new T-beam variant with display shield configuration
• Added touchscreen support using CST226SE controller with I2C scanning improvements

Reviewed Changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
variants/esp32/tbeam/variant.h	Adds ST7796 display and CST226SE touchscreen pin definitions
variants/esp32/tbeam/platformio.ini	Creates new tbeam-displayshield build environment with ST7796 support
src/platform/extra_variants/tbeam_displayshield/variant.cpp	Implements CST226SE touchscreen initialization and touch reading logic
src/mesh/NodeDB.cpp	Adds USE_ST7796 to display detection conditional
src/main.cpp	Includes USE_ST7796 in screen setup conditionals
src/graphics/images.h	Extends high-resolution image support to ST7796
src/graphics/draw/UIRenderer.cpp	Includes ST7796 in high-resolution display conditionals
src/graphics/draw/DebugRenderer.cpp	Adds ST7796 support to debug rendering conditionals
src/graphics/ScreenFonts.h	Includes ST7796 in large font conditional
src/graphics/Screen.h	Adds ST7796Spi header include
src/graphics/Screen.cpp	Implements ST7796 display initialization and control logic
src/detect/ScanI2CTwoWire.cpp	Enhances I2C scanning to differentiate CST226SE from other devices
src/detect/ScanI2C.h	Adds CST226SE device type to enum
src/configuration.h	Defines CST226SE I2C addresses

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The magic number 0xAB should be defined as a named constant to improve code readability and maintainability.

Suggested change

	if (registerValue == 0xAB) {
	if (registerValue == CST226SE_DEVICE_ID) {

[Nasimovy]

does this increase readability or should i add a comment on how or what the hex code means?

[Copilot]

[nitpick] The conditional logic is becoming complex with multiple negations. Consider refactoring to use positive conditions or extracting this logic into a helper function for better readability.

Suggested change

	#elif HAS_TOUCHSCREEN && !defined(USE_EINK) && !HAS_CST226SE
	#elif HAS_USABLE_TOUCHSCREEN

[Nasimovy]

requires multiple changes, should this be done, in a other way that's more convenient / readable?