TTGO T-WATCH-2020

[Angainor]

Still messing around and trying to find "good" ways to integrate with current Husky fork at least, if not the original wasp-os.

Dealing with touch driver and gestures atm.
Having lvgl touch enabled is easy. Rewiring the events of the lvgl driver to the wasp level so we can keep swipes for instance is significantly harder.

Also, dev is painful at this stage because file transfer is slow and I have to reboot the watch every time so it re-init clean.
(Freezing all core files should help once the low level is stable enough.)

End result is a few lines, but the making takes hours or days

Would you contribute and at what stage -core, apps, faces/gui?- once it's published?

Unrelated: I can't find any doc, does anyone know if the bevel button only is a button or an undocumented rotary encoder?

[Mike Teachman]

Has anyone worked on the I2S piece? The watch hardware block diagram shows an I2S DAC connected to a speaker. If someone integrates my ESP32 I2S PR it should be possible to play sound clips using WAV files. Integrating the I2S PR is simple: add one C file and edit 3 others. Then build.

An I2S how-to guide for this PR is in this repo:
https://github.com/miketeachman/micropy ... s-examples

Example #2 in the repo provides MicroPython code to play a WAV file using the I2S hardware used in the watch (MAX98357A).
https://github.com/miketeachman/micropy ... -sdcard.py

Make some noise !

[husky]

There you ttgo:

Minimal lvgl app demo with micropython on T-Watch 2020, st7789 and axp202.
https://gist.github.com/AngainorDev/63e ... 651eee1005

that's fantastic, when I have time I will integrate lvgl into my port and find a way to integrate my port into the main branch of wasp-os

[Angainor]

that's fantastic, when I have time I will integrate lvgl into my port and find a way to integrate my port into the main branch of wasp-os

Thanks for your work, helped a lot bootstrapping.

I'm new to lvgl myself, nice opportunity to learn.
I have a first dirty fork I'll post soon, lgvl wasp-os based upon your fork.

Many things changed again, like no more direct access to touch driver - handled by lvgl - and no more need for gesture recognition or the app ring, since we can use a TileView and lvgl handles a lot of things, simplifies the arch.
However, challenging to blend.

Also, this plays well with the esp32 ram, would be impossible on 32K RAM nRF MPUs.
So, likely this makes a unified thing one step harder (I may end up advocating a split, may depend on Daniel's feedback)

A - lvgl enabled - simulator like Daniel's one also is critically missing, would ease app dev a lot.

[Angainor]

Check this one, based upon Husky "develop" branch

https://github.com/AngainorDev/wasp-os/tree/lvgl
Do not take care of the whole repo, only required code is the wasp/ folder to drop on your watch once you have the proper micropython firmware.

- relies on https://github.com/OPHoperHPO/lilygo-tt ... icropython
- not clean, many commented out code, not usable yet
- Only "l" for lvgl prefixed apps do run, lclock and lvoid
- wifi temp. deactivated for ease of debug
- some logic presumably broken

Used a TileView https://docs.lvgl.io/v7/en/html/widgets/tileview.html to handle the main screen and various apps
(main clock + 3 void app)
works when asking to switch by code, but not via touch (despite other touch events working at lvgl level)
That's the main thing to solve atm.

Any help/hint from knowledgeable lvgl dev is welcome

[uraich]

Thanks, I will try to make it work on my watch and see if I understand the code. I am interested to help in the development and in documentation. We should have a single master repository though.

[Angainor]

We should have a single master repository though.

Absolutely.
My work is too crude for now to be a repo on its own. Pushed that in a hurry to demo the current state and issues.
On the other hand, PR to husky repo would break other (non lvgl) apps, so it would only make sense if husky was to target lvgl only or we find a way to blend both and have both (lvgl and non lvgl) app kinds.
May require a new indirection/abstraction layer in the core.

That's the whole question behind husky questioning about integration with original wasp-os as well.
To what point can it be the same app when so many things and logic differ?

As for myself, seing how lvgl makes sense and facilitates oo dev (but may be hardly usable on low ram watches), I'd say it could make sense to have a dedicated esp32+lvgl project.
Husky or a new one depending on how things go, no matter.
But yeah, a single one, with related micropython build and specific doc + tools.

[uraich]

Got the lvgl wasp code up and running. I wrote a simply shell script using ampy to upload all the wasp python code to the watch. However, this takes a loooooong time!
Since the micropython fork has uftpd included I will try to write a script that uploads everything using ftp. After that I will have a closer look into the code.
Thanks again to have given me access to the code. It may not do much just yet but it is very helpful nevertheless.
I don't know wasp-os, I don't know lvgl and therefore any working example helps at lot to bring me up to speed.

[Angainor]

Still trying to figure out lvgl events and things.

Got the swipe and views almost ok by getting rid of "lv_win" and using a simpler "lv_cont" - container instead.
"win" traps the swipe event and I wasn't able to tell it to forward yet.

Updated my branch, you can just upload the 3 changed files (wasp.py, apps/lvoid.py apps/lclock.py)
Do not go to the bottom right app, seems it crashes

As for the files weight: current wasp os has files that are no more needed, plus once the core is stable, all core python files should be frozen in the firmware and you would only have to upload wasp.py and the app/ you need.

Next we'll have to figure out lvgl styles and themes.
As for now, I'm more trying to get the core mechanism working than nice looking, I hope others with more advanced GUI skills will then hop
Now need to trap the correct events from lvgl to activate the app currently in view (see logs "tvevent lvgl tileview", it's event 16 I think.)
since for now the display scrolls, but the first app only gets ticks.

[husky]

wow, I also think that a lvgl way would make things much easier in terms of interface programming. But you're right that the changes are getting bigger and harder to integrate into the main branch of wasp-os.Looking at lvgl, I think an lvgl-based system would be nicer, more usable, and easier to program.
I also think that this kind of system would be tricky to run on an nRF chip.
It wasn't clear to me if branching for esp32 so different would make sense. But now that it's on the lvgl table, I think the fork should be permanent.
Taking this decision, it would be necessary to:

• Clean up the old code, without keeping some functions that only served to maintain compatibility.

• Document, to help other people develop applications and the core.

• Develop all applications using lvgl. I will start with the weather application.