esp-brookesia memory and thread used issue

[yihua-wang]

@Lzw655 I suggest that when designing the esp-brookesia-related components, issues regarding memory resources and thread resources should be taken into consideration.

Since the ESP32 is a microcontroller chip with limited memory resources and CPU scheduling capabilities, we cannot develop esp-brookesia in exactly the same way as we would for an Android application.

This could easily consume a large amount of memory and thread resources. An ESP32-S3 chip, under no-load conditions, has approximately 300 KB of available memory.

Using Wi-Fi, HTTP, JPEG, LVGL buffers, and other components will further increase memory consumption. If esp-brookesia uses excessive memory, it will reduce the SRAM available for users, thereby diminishing developers' enthusiasm for working with esp-brookesia.
Therefore, I recommend taking memory and thread resource constraints into consideration when developing components related to esp-brookesia.

Could you address my concerns?

[Lzw655]

Hi @yihua-wang,

Thank you very much for your consideration and suggestions regarding memory! We also had similar concerns during the early design phase, but after discussion and research, we ultimately decided to proceed with the new framework design for Release V0.7. Below are our key considerations:

1. First, ESP-Brookesia is currently positioned mainly for AI-related application scenarios. It is not just a UI framework (its core still uses LVGL), but a true system-level framework. Therefore, the chips capable of supporting such applications are primarily those with large-capacity PSRAM, such as the ESP32-S3 and ESP32-P4 (and possibly the ESP32-C5).

2. Second, regarding your concern about “a large amount of memory and thread resources,” the new ESP-Brookesia framework is actually designed specifically to address this issue. Here are a few reasons:

   • Since we assume that the target chips include large PSRAM, and since most of ESP-Brookesia’s memory usage is created via C++ new, we can allocate all such memory directly from PSRAM (by setting CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL=0 or by overloading new). This keeps SRAM usage very low.
   • Regarding thread resources, brookesia_lib_utils provides a tool called task_scheduler. It allows users to post/dispatch target tasks (or specific functions) into the scheduler to run using one or multiple threads. When designing various ESP-Brookesia components, we reuse the same task_scheduler as much as possible to minimize thread consumption. Moreover, the stack of most threads can be allocated in PSRAM.

3. In fact, during the development of the EchoEar speaker, we discovered that complex AI applications require advanced language features and tooling. These may introduce additional resource overhead, but compared to the complex coupling between modules and the hidden bugs that easily arise, we believe the new framework design is justified.

4. Finally, Espressif will continue releasing more powerful chips, and the design of ESP-Brookesia should not be constrained by older, low-performance chips.

Once again, thank you for your concern and suggestions! If you have more thoughts or feedback from your usage, we would be very happy to hear them!

[yihua-wang]

Thanks for your explanation.
@Lzw655
How should I overload the New and Delete functions to be used in the PSRAM?
Could you provide me with a demo?

[Lzw655]

You are welcome.
Here is a demo: https://github.com/esp-arduino-libs/esp-lib-utils/blob/master/src/memory/esp_utils_mem_cxx_global.cpp. You can use heap_caps_malloc/heap_caps_free instead of MALLOC/FREE to apply to PSRAM memory.