Platformio

[Thomas-Busch-Waterloo]

How would this integrate with Platformio?

I have tried utilizing the framework but I consistently encounter compilation errors. While I have been able to alleviate some of these errors by reorganizing files, the issues persist.

[Lzw655]

@vicelikedust Sorry, I haven't tested it with Platformio. I will find time to take a look.

[Thomas-Busch-Waterloo]

@Lzw655 I appreciate it very much, Thank you.

[PockyBum522]

I humbly also request this -

I have a project that is fully set up for platformIO at https://github.com/PockyBum522/esp32-touchscreen-home-assistant-panel

It is fully functional on an ESP32-S3-Touch-LCD-7 v1.1 EXCEPT for vertical screen shifting during LVGL animations.

I attempted to install the ESP32 board version 3.0.2 in the Arduino IDE per the "How to use" section in the readme of branch main of this repo, (copying the 3.0.2 high_perf files and overwriting some of the files I used the Arduino IDE to download.) Unfortunately, the first errors I get are several instances of: "unrecognized command line option '-std=gnu++2b'; did you mean '-std=gnu++2a'"

When attempting to use the modified 3.0.2 files, I specified the path to the modified copy under

platform_packages =
platformio/framework-arduinoespressif32 @ symlink://D:/repos/esp32-touchscreen-home-assistant-panel/platformio-touchscreen-src/platforms/esp32/hardware/esp32/3.0.2/
platformio/framework-arduinoespressif32-libs @ symlink://D:/repos/esp32-touchscreen-home-assistant-panel/platformio-touchscreen-src/platforms/esp32/tools/esp32-arduino-libs/idf-release_v5.1-bd2b9390ef

Which worked well for specifying what packages to use.

Note that although that project will complain about not being able to connect to MQTT if you run it, it still displays the LVGL buttons I made for testing fine even with that occurring.

The vertical screen shifting happens every few presses of the buttons, during the LVGL animation phase.

[Lzw655]

Hi @PockyBum522,

If I understand correctly, you’ve successfully replaced the Arduino SDK on PlatformIO. Thank you very much for sharing!

Your current issue is that you’re still experiencing shifting problems, correct? If that’s the case, there are two areas you can optimize. You can try the following steps in order:

1. Modify the macro LVGL_PORT_TASK_CORE in the file lvgl_port_v8.h.

// Original
#define LVGL_PORT_TASK_CORE                     (-1)

// After
#include <Arduino.h>
...
#define LVGL_PORT_TASK_CORE                     (ARDUINO_RUNNING_CORE)

2. Increase LVGL_PORT_RGB_BOUNCE_BUFFER_SIZE to LVGL_PORT_DISP_WIDTH * 20 (This will use about 16KB more SRAM. If there's not enough space, an error will occur).

[PockyBum522]

EDIT: Ignore this comment, see comments further down in this thread.

Original comment:
Apologies, I believe I could have structured my comment to be more understandable.

I have indeed modified the Arduino SDK in platformio, however, my problem is that it is not building, so I cannot test whether the screen tearing is happening or not.

Here is an example of the log when I try to build a minimal version of my code (That does build fine when I'm not attempting to use the modified arduino SDK)

C:\Users\David\.platformio\penv\Scripts\pio run -t upload -e esp32-s3-devkitc-1
Processing esp32-s3-devkitc-1 (platform: espressif32; board: ESP-LCD; framework:
 arduino)
--------------------------------------------------------------------------------

Library Manager: Installing >=0.0.1 && <0.1.0
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/ESP-LCD.html
PLATFORM: Espressif 32 (6.8.1) > ESP-LCD (8M DIO Flash & OPI PSRAM)
HARDWARE: ESP32S3 240MHz, 320KB RAM, 8MB Flash
DEBUG: Current (esp-builtin) On-board (esp-builtin) External (cmsis-dap, esp-bridge, esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:
 - framework-arduinoespressif32 @ 3.0.2
 - framework-arduinoespressif32-libs @ 5.1.4+sha.bd2b9390ef
 - tool-esptoolpy @ 1.40501.0 (4.5.1)
 - tool-mkfatfs @ 2.0.1
 - tool-mklittlefs @ 1.203.210628 (2.3)
 - tool-mkspiffs @ 2.230.0 (2.30)
 - toolchain-riscv32-esp @ 8.4.0+2021r2-patch5
 - toolchain-xtensa-esp32s3 @ 8.4.0+2021r2-patch5
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 45 compatible libraries
Scanning dependencies...
Dependency Graph
|-- ESP32_Display_Panel @ 0.1.6+sha.48cd18b
|-- ESP32_IO_Expander @ 0.0.3+sha.e5378da
|-- lvgl @ 8.3.11+sha.4d96c27
Building in release mode
Compiling .pio\build\esp32-s3-devkitc-1\src\lvgl_port_v8.cpp.o
Compiling .pio\build\esp32-s3-devkitc-1\src\main.cpp.o
Building .pio\build\esp32-s3-devkitc-1\bootloader.bin
Generating partitions .pio\build\esp32-s3-devkitc-1\partitions.bin
xtensa-esp32s3-elf-g++: error: unrecognized command line option '-std=gnu++2b'; did you mean '-std=gnu++2a'?
xtensa-esp32s3-elf-g++: error: unrecognized command line option '-std=gnu++2b'; did you mean '-std=gnu++2a'?
esptool.py v4.5.1
Creating esp32s3 image...
Merged 1 ELF section
Successfully created esp32s3 image.
Compiling .pio\build\esp32-s3-devkitc-1\lib735\ESP32_IO_Expander\ESP_IOExpander.cpp.o
*** [.pio\build\esp32-s3-devkitc-1\src\lvgl_port_v8.cpp.o] Error 1
*** [.pio\build\esp32-s3-devkitc-1\src\main.cpp.o] Error 1
xtensa-esp32s3-elf-g++: error: unrecognized command line option '-std=gnu++2b'; did you mean '-std=gnu++2a'?
*** [.pio\build\esp32-s3-devkitc-1\lib735\ESP32_IO_Expander\ESP_IOExpander.cpp.o] Error 1
================================================================================================= [FAILED] Took 2.27 seconds =================================================================================================

I believe this is due to platformio using the: toolchain-xtensa-esp32s3 @ 8.4.0+2021r2-patch5 (which I believe is an old version of the toolchain.)

If you can confirm that the errors I'm getting about -std=gnu++2b arguments are likely due to using the 8.4.0 version of that toolchain, then I'll work on figuring out how to tell platformIO to use a newer version of that toolchain.

[PockyBum522]

@Lzw655 Just a heads up, I tried only your modifications in your last comment (without the modified Arduino SDK files) and the screen shifting is at least severely improved. I'm going to test more and let you know, but that might fix it entirely for me.

I didn't even change the bounce buffer yet, just the core it was running on per your instructions, and it's looking great.

I don't know if it's stock, but my bounce buffer is:

#define LVGL_PORT_RGB_BOUNCE_BUFFER_SIZE (LVGL_PORT_DISP_WIDTH * 10)

[PockyBum522]

@Lzw655 I've been sitting here for the last 10 minutes pressing the LVGL buttons on the touchscreen and watching them do their animation for about as long with no screen shifting whatsoever.

I'll let you know if I ever see an issue, but just modifying what core the LVGL loop is running on appears to fix it for me on an ESP32-S3-Touch-LCD-7 v1.1

Thank you so much!

@vicelikedust please try out this branch:
https://github.com/PockyBum522/esp32-touchscreen-home-assistant-panel/tree/minimal-lvgl-for-testing

I'm using CLion, but you should be able to just copy everything in src/ over to a new platformIO project, and then modify your platformio.ini to match the one in that project. If you're using the ESP32-S3-Touch-LCD-7 v1.1 then copy what's in boards/ also, if you're not then you'll have to integrate all the correct settings for your board. If that's the case, you may have an easier time just attempting to change your platformio.ini to match mine and doing nothing else other than changing what core the LVGL loop is on per this comment: #1 (comment)

(And you'll have to use your original board = in platformio.ini, since the one mine is set to relies on the json file in boards/)

EDIT: Ignore this, see below comments for updated info. I did end up having to change the bounce buffer to * 20
Note that my bounce buffer is set per this comment:
#1 (comment)
and I didn't need to change it from that.

Let me know how it goes.

[PockyBum522]

I went ahead and reintegrated my MQTT and OTA handlers, and it looks like when there's significant blocking processing in loop(), it still shifts the screen vertically, but when there isn't, it works. I'm going to see if I can make the mqtt handler fire less than every loop and see if that helps.

However, it still looks solid if there's little processing going on in loop. Will keep you both updated.

[PockyBum522]

Setting #define LVGL_PORT_RGB_BOUNCE_BUFFER_SIZE (LVGL_PORT_DISP_WIDTH * 20) per your instructions along with the changes I outlined above seems to work, and I'm not running out of ram.

I believe I am set for what I need this touchscreen to do! Thank you very much for your help.

@vicelikedust I updated the bounce buffer size in my minimal-lvgl-for-testing branch, so you should still be able to pull it down and just modify things to your board/environment and have it work. Start with nothing in loop() and make sure things work, then slowly add back in blocking work to loop() and you should be set assuming you're not doing an extreme amount of processing.

[Lzw655]

Hi @PockyBum522,

I’m glad I could help, and I really appreciate your feedback.

To make it easier for you to understand, I can explain the cause of screen tearing on RGB LCDs. The root cause is that the ESP's RGB peripheral is unable to send out data in real-time according to the timing sequence. The direct reasons for this usually include two points:

1. PSRAM is disabled or there is insufficient data bandwidth;
2. The bandwidth of DMA transferring data from PSRAM is insufficient.

As you mentioned, when performing OTA or MQTT operations, these operations will invoke WiFi or Flash interfaces, and the SDK with default configurations will disable the Cache. Since PSRAM needs to be accessed through the Cache, this leads to PSRAM being inaccessible (first point), resulting in screen tearing. Therefore, in this case, it is recommended to use the high-performance version of this library, which enables the 'XIP on PSRAM' feature, ensuring that the Cache is not disabled when operating Flash.

Additionally, the 'RGB Bounce Buffer' feature is used because the efficiency of DMA with SRAM is much higher than with PSRAM. By using the Bounce Buffer located in SRAM, DMA's data bandwidth can be significantly improved (second point).

[Hooba97]

i started working on a similar project 6 months ago and left it for lack of resources
i am happy to find new resources for my esp32s3 LCD (zx7d00ce01s)
last time i had mqtt, vnc and lots of other things,
fingers crossed it can handle lvgl next

i have a simple hello world code to display as soon as i added wifi screen started shifting/ flickering

@PockyBum522 can you please quickly describe to me how you added the new SDK esp32-3.0.2-h ( high_perf) to platformio
as i tested it on Arduino ide and it solved the problem

and maybe how to enable DMA ?

[env:esp32-s3-devkitm-1]
platform = espressif32
board = esp32-s3-devkitm-1
framework = arduino
lib_deps = 
	smartpanle/PanelLan@^0.0.1
	bblanchon/ArduinoJson@^7.1.0
	knolleary/PubSubClient@^2.8
	qub1750ul/SharpIR@^2.0.1
;	https://github.com/JakubAndrysek/BasicOTA-ESP32-library.git
board_build.f_cpu = 240000000L
board_build.f_flash = 80000000L
board_build.arduino.memory_type = qio_opi
board_build.flash_mode = qio
build_flags = 
  -DBOARD_HAS_PSRAM
  -mfix-esp32-psram-cache-issue
upload_speed = 921600
board_upload.flash_size = 16MB

monitor_speed = 115200

;upload_port = 192.168.100.30
;upload_protocol = espota
upload_flags = -p 3232

[PockyBum522]

@xXhoobaXx have a read through my last 4 comments in this thread.

Basically it boils down to:

1. I think platformio won't build with the high_perf modification because the toolchain platformio tries to use to build for the esp32-s3 is expecting a newer version of the Arduino SDK. I'm not 100% sure, though. Regardless, it won't build and I never got it to behave.

2. If you make the two modifications stated by Lzw655 in this comment Platformio #1 (comment) and you're not doing anything in loop() that blocks for more than a few tens of milliseconds, you'll likely fix the screen shifting/tearing issue WITHOUT having to use the high_perf modified arduino SDK

You may find my repo useful, particularly this branch:
https://github.com/PockyBum522/esp32-touchscreen-home-assistant-panel/tree/minimal-lvgl-for-testing

That branch is meant as a getting started and has the two modifications that I mention in point #2 in this comment. It may help you to get up and running with the LCD. If you're not using the 7 inch Waveshare, you'll of course still have to plug in the correct settings for your particular LCD.

I would start with very little in your loop() and slowly add things. You may find it usable in platformio without worrying about the high_perf Arduino SDK.

[Hooba97]

Thank you @PockyBum522 , I did read through everything but I might have misunderstood it

Anyway that's what I am planning to do to start from hello world and build it up bit by bit

I am not using lvgl library yet
I am using a PanelLan library which is based on LovyanGFX

And I would like to try to make it work on platform io
I'll take a look at your project It seems very interesting

Now that I wrote this I think I might not need PanelLan library after all if I am switching to lvgl
Still kinda new to all of this

I still would like to know more about DMA