Closed zackees closed 1 year ago
This system is able to build and deploy to a WT32-SCO-PLUS board. I have tested the WT32-SCO (non plus) and it fails to install because it's missing #defines for one of the GPIO pins. I'm investigating fixes for this.
This is because you need to delete the build folder and again run idf.py menuconfig
to select the correct device. This is important because WT32-SC01
uses ESP32
and WT32-SC01 Plus
uses ESP32-S3
.
I have already mentioned it here https://github.com/sukesh-ak/ESP32-TUX/issues/16
And just to let you know, I have tested with all 4 supported devices listed in the README.md file.
Have started working on the Documentation Wiki. Will get it completed by weekend. https://github.com/sukesh-ak/ESP32-TUX/wiki
Appreciate your help and contributions. Have added credits on the Wiki as well.
There's a bunch of foot guns that I keep hitting trying to get this working. Things go wrong and I have trouble trying to figure out how to take corrective action, but I'm able to work through it pretty ok.
I think that what is needed is to take all the manual build steps and turn them into scripts.
My current fork I've got
For some reason, at every step of the config/build/deploy process I have to delete the components.hash
on both mac and windows. Fortunately the scripts allow me to do this painlessly and serves as a nice abstraction layer.
I find that automating the installation process truly reduces the friction of setup and install. If you allow me, I would like to merge my changes into this repo. It's obvious you are an expert on the ESP32 and have done some great work, I'm about one month into ESP32 dev so I have a more naive knowledge approach that more closely matches the experience of the target audience for this open source project. This audience isn't really that aware of how ESP32 idf.py
works that well and is more likely is trying to use VSCode. Giving them a script to configure and deploy the code to a working device very quickly would really open up this project to a much wider audience and allow it to take off. It also brings the project closer to have CI testing on each push/pull review which I think would help catch bugs like the ones I'm facing on Mac/Windows.
If you don't want these changes, this is totally fine. But I'd like to contribute back. This WT32-SCO(+) is a great little device and there is a total lack of quick solutions to get a great looking GUI up and running on it, so I think this repo really hits the sweet spot, but the barrier for entry needs to come down a little.
Also, I realize that my CL history here is a little dirty. I may just go ahead and save everything to a folder and then recreate the fork so that the entire history is submitted as one PR.
How do I run the business logic loop in this demo?
When I do the following in app_main()
while (true) {
vTaskDelay(5 / portTICK_PERIOD_MS);
}
The watch dog timer immediately halts the program. Do I need to run all my business logic via xTaskCreate?
...i figured it out
...i figured it out
How do I run the business logic loop in this demo?
When I do the following in app_main()
while (true) { vTaskDelay(5 / portTICK_PERIOD_MS); }
The watch dog timer immediately halts the program. Do I need to run all my business logic via xTaskCreate?
Please take some time to understand the code. Check how Remote screen is shown, Don't touch the code related to loops etc which will get you into trouble.
Okay some questions here on the layout of the project:
Okay some questions here on the layout of the project:
- Why so many uses of *.hpp files instead of h/cpp units?
When you are developing with cmake, sometimes its easier to use .hpp
so that it gets included by referring it in source code. Usually .h = C
and .hpp = C++
- Is there a way to reduce the size of the framebuffer to increase speed?
Reducing frame buffer won't increase speed. For now all optimizations are already included in the config file.
I tried using the menuconfig to use one byte color but the colors don't change nor the performance.
Read my previous comment.
@zackees I have added video walkthrough of Clone, Build and Flash for the project in the readme. It's pretty straight forward with just 3 commands. Nothing complicated.
Please feel free to use Discussion option of the project for questions if any. https://github.com/sukesh-ak/ESP32-TUX/discussions
All the basics of using ESP32-TUX project is explained in Wiki (will be improving it further soon) https://github.com/sukesh-ak/ESP32-TUX/wiki
Closing this PR, since there is no reason to create another script which complicate things.
Btw, idf.py
itself is a python wrapper on top of esptool
to get everything done easily.
I highly appreciate your efforts. Thank you.
Streamlines configuring and deploying the app.
This allows repeatable edit->deploy cycles on MacOS M1 Ventura - 13.0.1 (22A400).
Fixes Applied:
Installing, building, deploying the app will fail on a
compontent.hash
not being the expected value. The work around is to touch and remove the file before running commands. This method was recommend by the tools themseleves when they abort.The environment
activation.sh
puts in an include guard to ensure theidf.py
environment is activated once.This system is able to build and deploy to a WT32-SCO-PLUS board. I have tested the WT32-SCO (non plus) and it fails to install because it's missing
#define
s for one of the GPIO pins. I'm investigating fixes for this.