Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

freetype for MCU #12

Open
CalvinML opened this issue Aug 23, 2021 · 21 comments
Open

freetype for MCU #12

CalvinML opened this issue Aug 23, 2021 · 21 comments

Comments

@CalvinML
Copy link

The "freeType" library tested in LVGL emulator is normal, can "LVGL + FreeType" add support for MCU?

@kisvegabor
Copy link
Member

It'a certainly possible to build FreeType on MCUs but it requires some adjustments on FreeTypes build system.


I moved this issue to the FreeType repo.

@kisvegabor kisvegabor transferred this issue from lvgl/lvgl Aug 24, 2021
@Miguel0101
Copy link

As I understand it, this library is not compatible with MCUs, but it is compatible with simulators, right?

@embeddedt
Copy link
Member

FreeType can run on sufficiently powerful MCUs as well. I have used it on STM32 before, though not with LVGL.

@Miguel0101
Copy link

Miguel0101 commented Sep 22, 2021

FreeType can run on sufficiently powerful MCUs as well. I have used it on STM32 before, though not with LVGL.

Some MCUs do not support the C File API(fopen, etc).
EDIT: Does lv_lib_freetype supports ESP32?

@kisvegabor
Copy link
Member

I saw some implementations on ESP32, but it's unrelated to LVGL so I can't comment much on it.

@s-hadinger
Copy link

I added freetype support to lvgl in Tasmota on Esp32. It runs fine but you need to be cautious about memory and stack size. The default 8kb stack is insufficient for freetype. I suppose similar MCUs will work with the same constraints.

@kisvegabor
Copy link
Member

I added freetype support to lvgl in Tasmota on Esp32.

That's great! Can share some details about how did you port FreeType to ESP32?

@Miguel0101
Copy link

Miguel0101 commented Sep 29, 2021

I agree with @kisvegabor.
It would be great to support ESP32.

@s-hadinger
Copy link

I added freetype support to lvgl in Tasmota on Esp32.

That's great! Can share some details about how did you port FreeType to ESP32?

Sure, and sorry for the late response.

First FreeType compiles out of the box on ESP32, so it does not require specific work here. The main problem is that calling get_glyph_dsc_cb() consumes more than 16KB of stack whereas the default ESP32 stack is 8KB. This yields to a crash.

Currently I run get_glyph_dsc_cb() in a separate FreeRTOS task with 24KB of stack allocated and pass parameters through a queue. I'm not satisfied with the solution and discovered in between that esp-idf has a function to pass a temporary stack bigger than the default one.

Here is the patched code: https://github.com/arendst/Tasmota/blob/development/lib/libesp32_lvgl/lv_lib_freetype/lv_freetype.c

@kisvegabor
Copy link
Member

That's great, thank you for the explanation!

@fvanroie
Copy link

I'm also looking into adding this functionality to my ESP32 project. Thanks @s-hadinger for sharing your solution!

I discovered in between that esp-idf has a function to pass a temporary stack bigger than the default one.

Are you refering too Call function with external stack?

@s-hadinger
Copy link

Yes. That's the one. I will switch to this method which is simpler

@huming2207
Copy link

I've also made a wrapper here for someone who needs it: https://github.com/huming2207/esp-ft2

Currently:

  1. It may cause crashing due to the stack overflow issue (stack is too small)
  2. May need this patch to allow LVGL to know my wrapper's existence: cmake: Add missing "REQUIRES main" for ESP-IDF lvgl#3240

@kisvegabor
Copy link
Member

It may cause crashing due to the stack overflow issue (stack is too small)

Which stack do you mean?

@huming2207
Copy link

Which stack do you mean?

As per @s-hadinger mentioned, the task that eventually does get_glyph_dsc_cb() needs to be big enough, otherwise it will crash due to stack overflow.

@s-hadinger
Copy link

In my experience you need 24KB of CPU native stack to have Freetype run correctly. This gives 3 options:

  • Resize your main stack's to 24KB
  • Run get_glyph_dsc_cb() in a separate RTOS stack with a stack sized at 24KB
  • Use esp-idf esp_execute_shared_stack_function() to swap the stack with a 24KB memory chunk for this call

@huming2207
Copy link

In my experience you need 24KB of CPU native stack to have Freetype run correctly. This gives 3 options:

Yep. For our scenario, we can just increase the main thread's stack to be 32KB as we also have a lot of other stuff that needs the stack memory anyway.

@huming2207
Copy link

huming2207 commented Apr 5, 2022

I think the right way of doing this is probably to spin up a FreeRTOS task with 24KB stack in the init function, that wait and deal with FT2, and pass the data over a FreeRTOS queue to the real get_glyph_dsc_cb() and pass the result back to LVGL. Otherwise I don't know how to pass the arguments when using esp_execute_shared_stack_function() - unless if we use global variables (which I'd prefer avoid doing that).

@s-hadinger
Copy link

This is what I did the first time, because I couldn't increase the main stack. But it's a little more complicated to do.

@garudaonekh
Copy link

garudaonekh commented May 2, 2022

Glad to use add this(LVGL+Freetype) into my ESP32 project. But my concern is the resource constraint because my project also use so much space and cpu. Can you share some info on resources usage of this Freetype?

Currently, we are using ESp32-WROOM but I can use ESP32-Wrover if it's suitable.

Thanks;

@s-hadinger
Copy link

Everything is explained above. You need at least 24KB of stack when calling Freetype. It's really stretched if you don't have a PSRAM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants