Open scottbez1 opened 2 years ago
LVGL is something I have been trying out whilst I wait for some motors I’ve ordered to arrive. The above is running on a modified version of the handheld branch. It creates a new task called UI_Task, to contain all of the lvgl requests. Under the hood lvgl uses TFT_eSPI. There is not much there yet as I am still playing with the configuration
LVGL is something I have been trying out whilst I wait for some motors I’ve ordered to arrive. The above is running on a modified version of the handheld branch. It creates a new task called UI_Task, to contain all of the lvgl requests. Under the hood lvgl uses TFT_eSPI. There is not much there yet as I am still playing with the configuration
Good progress.
@scottbez1 Hi Scott. I found esp32 we use has 8MB flash and 2MB PSRAM. But the log shows incorrectly.
PLATFORM: Espressif 32 (3.4.0) > DOIT ESP32 DEVKIT V1 HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
@zinwalin Sorry to be off-topic. What board are you using with that small display? I would also like to tinker before I can get motors.
@jtsfour That's a Lilygo T-Display - it's a great ESP32 board, and there's even a pio env set up to use it for prototyping the smartknob as well! (though since I haven't done much prototyping with it recently, it's possible that T-Display env hasn't quite kept up to date, but it should at least compile)
It also happens to be the board I recommend using for my splitflap project
@zinwalin Sorry to be off-topic. What board are you using with that small display? I would also like to tinker before I can get motors.
I mean T-Micro32 Plus has 8MB flash and 2MB PSRAM.
When I initially set up the project, the stable Arduino core yet didn't have support for using the PSRAM on the ESP32-PICO-V3-02, so that is not expected to show up as available. More info here: https://community.platformio.org/t/support-for-eps32-pico-v3/26967
It looks like it's still not landed, but I'm hopeful that there will be an official release soon. Otherwise I guess we can switch to the Jason2866 platform to get PSRAM support sooner.
You could try the following code to check if you have 8Mb Flash (I don't have this board ESP32-PICO-V3) :
#include <esp_chip_info.h>
void GetChipAndMemoryDetails (void)
{
// This function display the details of the integrated chip (memory, core, bluetooth)
// It also give external memory size
/* Print chip information */
Serial.println();
esp_chip_info_t chip_info;
esp_chip_info(&chip_info);
Serial.printf("This is ESP32 chip with %d CPU cores, WiFi%s%s, ",
chip_info.cores,
(chip_info.features & CHIP_FEATURE_BT) ? "/BT" : "",
(chip_info.features & CHIP_FEATURE_BLE) ? "/BLE" : "");
Serial.println();
Serial.printf("silicon revision %d, ", chip_info.revision);
Serial.println();
Serial.printf("%dMB %s flash\n", spi_flash_get_chip_size() / (1024 * 1024),
(chip_info.features & CHIP_FEATURE_EMB_FLASH) ? "embedded" : "external");
}
I believe there is no PSRAM (external component) on this board (ESP32-PICO-V3) and it is not supported by the MCU used by espressif on this specific board (PIN 16 and 17 dedicated in Wroover modules version to support PSRAM).
The Arduino Core for ESP32 simply uses the esp-idf/FreeRTOS under the hood. Using it directly opens up a lot of optimizations for reducing RAM usage by the FreeRTOS itself and also the Wifi stack (e.g. how large the buffers should be and the maximum amount of connections). This would obviously require some refactoring but large parts of the code already use functions from FreeRTOS so added complexity is rather small. Some other tweaks could be made by reducing the stack size for tasks and maybe using static allocation where possible. Oh and obviously it would support PSRAM though that might be too slow for the framebuffer itself.
Not sure if it was mentioned anywhere but you can reduce color depth to 8 bit from 16 bit and reduce memory usage for sprite by half - according to the documentation for createSprite
method in TFT_eSprite
, 8 bit color requires 1 byte per pixel compared to 2 bytes for 16 bit color. Unless you absolutely need 16 bit color depth, this seems to be a nice trade off for now.
I changed color depth value in display_task.cpp
with spr_.setColorDepth(8);
and was able to initialize wifi, connect to mqtt and send out test message just fine, no memory issues.
wifi
how tu get your modified project, can you share your code
maybe the device can use two core. auther maybe use one core
Currently there is not enough memory available to initialize wifi (and I assume the same is likely true of bluetooth though I haven't tested yet).
A big culprit is the full 240x240x16b framebuffer in the display task which is used to avoid flickering when rendering. Two ideas of avoiding this memory issue:
There are some other memory issues, like the default arduino loop task allocates a (fixed) moderately sized stack but is essentially completely unused and gets deleted immediately after starting other tasks, but I think those issues are smaller scale compared to the framebuffer issue.