fancy T-Deck / SenseCAP Indicator / unPhone / PICOmputer-S3 TFT screen

[mverch67]

nothing to see here, yet. Work in progress

[CLAassistant]

All committers have signed the CLA.

[bobricius]

Is possible to test on PICOmputer S3 ? I can send sample hardware.

[mverch67]

Is possible to test on PICOmputer S3 ? I can send sample hardware.

To Germany? Good. I can support it when I have the actual hardware available.
Currently (as of right now) it won't function as there is no cardKB-like keyboard input driver implemented which would be the precondition for any interaction, as the PICOmputer does not have a touch screen (or does the display have a GT911 or other touch controller??).

[bobricius]

Is possible to test on PICOmputer S3 ? I can send sample hardware.

To Germany? Good. I can support it when I have the actual hardware available. Currently (as of right now) it won't function as there is no cardKB-like keyboard input driver implemented which would be the precondition for any interaction, as the PICOmputer does not have a touch screen.

worldwide, Germany is almost a neighbor, I'm from Slovakia. Picomputer use direct gpio matrix keyboard implemented by @caveman99 cpu is bpi-PicoW-S3 + RFM95 send my your postage address to [email protected]

[caveman99]

I am on the road right now but iirc the picomputer does only have 4MB flash. May be a tight fit. The TFT tracksenger may be a better fit. 8 MB is the min for an integrated device I would think.

@mverch I have a picomputer prototype I can send you. Assuming @bobricius doesn't have a newer revision :-)

[bobricius]

I ma not sure but on product page is:
ESP32-S3R2
2MB Quad SPI PSRAM
8MB Quad SPI Flash
Also I have Picomputer based on Wroom module which is more flexible with flash/psram options

[mverch67]

I ma not sure but on product page is: ESP32-S3R2 2MB Quad SPI PSRAM 8MB Quad SPI Flash Also I have Picomputer based on Wroom module which is more flexible with flash/psram options

That's also what I read on the ALI-Express page for the Banana-Pi. Should be fine.

https://github.com/meshtastic/firmware/blob/tft-gui-work/boards/bpi_picow_esp32_s3.json#L28

[mverch67]

[Kangie]

This is looking great. I've been running it on hardware on and off for a few weeks and even in the current state I'd say it's made the T-Deck far more usable (as a standalone device) than it was before. I'm very impressed with the progress so far and look forward to seeing the improvements.

Willing volunteer if you need anything tested or want specific feedback.

[martinbogo]

Downloaded and installed latest CI artifacts. Will report back with any issues/bugs I find.

[mariotti]

[as usual latest commit]

Sorry I was a bit absent. But:

I flashed this PR to t-deck and t-echo and all fine.
(only with current device-ui master: i.e. I checked out master from the submodule)

What I tested (basic):

• it flashes with no errors
• it receives messages
• I can send messages (*)

The procedure for both:

• flash the latest alpha release from web, to check it works with latest master (tests above)
• flash with this PR (no -tft), same above tests

Procedure for t-deck:

• flash with env t-deck-tft and same tests above.
• little playing with the UI, i.e. verify only the main menus information. DID NOT change settings from the UI.

[I tested previous commits a bit more about the UI, so I kept this short]

My opinion (but see also questions below):

We should merge asap.

This PR is a firmware support for the device-ui lib, and currently it seems more like checking master.
To reduce work, I would push to master and allow others to test different hardwares.
This will also open to others some nice API. This also needs to be tested on master for devices
and use cases.

From the pure technical point we solved the issue with RadioLibs. Not Tested, indeed.

There is the comment from @fifieldt on main.cpp which we might need to resolve,
I am not sure if the t-echo with e-paper solves the issue. :)

My questions:

If we merge this, how do we handle dev "tft" device-ui lib dependencies?

The UI is going to get out resources: for example Bluetooth, or anyway something else.
How are we going to handle it? Two versions of firmware for each device?
But most important: 2 UIs? t-deck and t-deck-tft?

I will be happy with one version. I do not get a device with TFT if I am not able to pay the costs.

I really hope we can merge this asap.

[mariotti]

Fantastic!

[mariotti]

Sorry the (*) above.
For sending messages, which is indeed important.
t-deck tested only with the TFT and UI.
t-echo tested only via bluetooth from a phone

[mariotti]

@ChrDel @j6k4m8 What do you think? I'd push to master asap, otherwise it is not possible to support every device. Or better this PR might diverge or go in parallel to master, wasting time of good coders.

[j6k4m8]

Don't know how much my opinion matters here — I've only done a little work here and have only flashed/run on a T-Deck! But I'm definitely very supportive of merging to master to help coordinate dev efforts, I imagine that we can all be more helpful to @mverch67 who is doing some extraordinary work here!

[mariotti]

@j6k4m8 but you can approve the PR to show some love ;)

[j6k4m8]

can't argue with that :)

[mariotti]

@fifieldt I can test some other devices but at this point I'd like to do it from master.

This PR did not break any of my devices. All lilygo based, but apparently @mverch67
was developing on some more basic processors.

[fifieldt]

Thanks @mariotti , @j6k4m8 . I've been trying to keep master up to date by cherry-picking anything from this branch that can go into master cleanly. Where I think we're at is device-ui (or at least parts of it, like the PacketAPI) need to go in before we'd be able to merge this. I'm not sure what the plan is for that, to be honest!

[mariotti]

@mverch67 you are invited to push the button and merge!

I think everybody will thank you for this work!

But do not get sad, you will see me in the UI repo :)

[mariotti]

Hoi @fifieldt the only issue I really have is how to handle the versions with UI or without.

But I think this cannot be decided in this PR anyway. This is a requirement so that we can ask the right question ;)

[caveman99]

@mariotti please stop spamming the comment section of this PR. The core devs pretty much know how and when to merge this. Everytime you post here or 'approve this' all devs get an email.