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

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

[Nasimovy]

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

[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]

touchscreen is recognized and responds to touches, swipe is also recognized. ~observer is not working though.~

edit: how should i add the ST7796 to the org? edit 2: touchscreen works properly

[Nasimovy]

the addition of a fixed baudrate for the GPS solved the GPS issue, i dont know and cant test if other T-beams with another variant of the Ublox module has the same baudrate

i had to update the NIMBLE because of stack smashing protect failure, i will try the latest alfa and report back if the problem exists there also.

[caveman99]

Thanks for the great work so far. the GPS Speed issue and the NimBLE update should be untangled from this PR. The former can be looked into later and the latter is subject of a different PR we're debugging right now. Please only submit the ST7796 support and the touchscreen stuff.

For the move of the drive repo, i will simply fork your repo back into the org. This is more straight forward than moving it.

[Nasimovy]

I wanted to revert the NIMBLE, but i ran into unrelated issues with VScode, i will split it up when i get access to my desktop.

The GPS is not getting detected on startup so i thought i should include it here, the T-beam works fine without the display code though.

[Nasimovy]

code works again with NIMble reverted, only issue now is that gps does not get detected on startup

the fixed baud rate change helps with that

[caveman99]

standard baud rate on the t-beam is 9600. I am curious what your 115200 comes from. can you run a GPS factory reset sketch on your t-beam and try again?

[Nasimovy]

i tried (all) the factory reset scripts sketches i could find, the baudrate stays on 115200, i forced set it to 9600, on the non tft shield firmware it finds it on the first search...... , on the tft firmware it says INFO | ??:??:?? 11 [GPS] UBlox Frame Errors (baudrate 9600) im inside so im still waiting on gps lock with that tiny tic tac antenna

[Nasimovy]

the gps works!, it does not get identified on startup but it puts out data and meshtastic picks that up

[Nasimovy]

I think using lovyanGFX (TFTDisplay) would have saved some work as it natively supports the ST7796 display

lovyangfx makes the program to large to fit on the t-beam (iram overflow ~2700)

edit: maybe i'm stupid but i got the display working in the arduino ide with lovyangfx but i couldn't fit it in the meshtastic code.

[mverch67]

lovyangfx makes the program to large to fit on the t-beam (iram overflow ~2700)

The current tbeam size in master is:

RAM:   [=         ]   7.4% (used 96820 bytes from 1310720 bytes)
Flash: [========= ]  89.3% (used 2165385 bytes from 2424832 bytes)

I wouldn't expect lovyanGFX being that large (260kB)?!

[Nasimovy]

lovyangfx makes the program to large to fit on the t-beam (iram overflow ~2700)

The current tbeam size in master is:

RAM:   [=         ]   7.4% (used 96820 bytes from 1310720 bytes)
Flash: [========= ]  89.3% (used 2165385 bytes from 2424832 bytes)

I wouldn't expect lovyanGFX being that large (260kB)?!

the IRAM is insufficient by 2736 bytes

/root/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: .pio/build/tbeam-displayshield/firmware.elf section `.iram0.text' will not fit in region `iram0_0_seg'
/root/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: IRAM0 segment data does not fit.
/root/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: region `iram0_0_seg' overflowed by 2736 bytes

edit: if i compile the exact same code with 1 modification it fits on a esp 32S3

[Nasimovy]

is there still something i need to improve change or test?

[mverch67]

is there still something i need to improve change or test?

Yes, I would say so. Look, the original design of the touch screen impl class is completely generic and there's no need to duplicate this entire class and add a little bit, that's not the way object-oriented C++ is intended to be handled.

Have a look at how I implemented the new touch driver for the T-Deck Plus E-Ink screen: https://github.com/meshtastic/firmware/pull/6936/files#diff-35aefebed15b5365cae9167c43827cf77fc61afab35cc089a3a46b26af67c3b0

You'll see that here I make fully use of the generic TouchScreenImpl1 class and it's interface. That's the way how it's supposed to be used for registering touch drivers.

[Nasimovy]

it works now with the new oled ui and with the default touchscreen implementation

[Nasimovy]

@mverch67 it seams that i am blind, github says there is still a requested change but i cant find it

[mverch67]

@mverch67 it seams that i am blind, github says there is still a requested change but i cant find it

maybe use from terminal:

git diff
git restore <file>
git checkout T-beam-display-no-touch -- .vscode/settings.json

[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.

[Nasimovy]

code is still working on my t-beam

[Xaositek]

Testing in the develop branch, this has broken all aspects of the TFT_MESH color being applied and is reverting all screens back to the default Green.

[Nasimovy]

I will look into it and report what I can find Thanks for letting me know

[Xaositek]

I will look into it and report what I can find Thanks for letting me know

I have fixed it in develop already - https://github.com/meshtastic/firmware/pull/8796