Problem compiling lvgl with custom micropython

I suspect there is something wrong with portnativeglue on tve fork.
It defines some types that should be defined by system libraries. For example:

typedef int size_t;
typedef int int32_t;
typedef unsigned int uint32_t;

When integrating lvgl into Micropython, we add an include in mpconfigport.h to lv_gc.h. This is needed in order to integrate lvgl gc-roots into micropython’s MICROPY_PORT_ROOT_POINTERS.
However, it also means that mpconfigport.h now includes some headers that come from lvgl, such as lv_gc.h, lv_mem.h etc.
These headers assume the existence and uses standard types such as int16_t, size_t etc.
However, it looks like portnativeglue on tve fork both includes mpconfigport.h and re-defines these types and this is what causes the errors you see.

To solve this, either remove #include "mpconfigport.h" or include standard C library headers instead of these redefinitions in portnativeglue of tve fork.
Did you try writing to @tve about this?

I’m planning at some point to align lv_micropython to upstream Micropython.
If tve’s changes are integrated into Micropython upstream by the time I do that, or if you can already use an up to date Micropython instead of tve’s port, that could solve your problem.

1 Like

@Tiago_Almeida to pull in LVGL on top of my fork you need two things:

I created a tve-lvgl fork that compiles and boots, but I haven’t tested LVGL specifically, I need to wire-up a display first…

This is awesome!! Thank you so much @tve ! I will try it and will give feedback. I really really appreciate you taking the time for helping!
@amirgon Thank you so much too! I really appreciate your tips and calling out for tve !
Hands to work now!

So I cloned https://github.com/tve/micropython/tree/tve-lvgl, as the lv_bindings submodule was not downloaded ( I guess the link used in the .gitmodules is deprecated.) I added it myself (used https://github.com/tve/lv_binding_micropython).

This time a got a lot less errors but still got this:
errors.txt (4.3 KB)

Any idea of what to change to fix it?

I am using esp-idf v4.0.1 (see the exact hash in the ports/esp32/Makefile) and xtensa-esp32-elf-8.2.0
I believe it also works with esp-idf v3.2.3 and xtensa-esp32-elf-5.2.0/

1 Like

Heads-up that there is a problem still in keeping lv “running”. The timer in lvesp32 that schedules lv_task_handler isn’t working, and if it were it would run every millisecond, which I don’t think is practical. I’m looking into it: What calls touch.read() for xpt2046?

Thank you @tve ! It worked.
It compiled but with this micropython version and lv_bindings I get
File “ili9341.py”, line 125, in init
RuntimeError: Not enough DMA-able memory to allocate display buffer

I had this problem before, I changed factor to 8 and it worked. My code was running fine. Now I have already tried a factor of 8 and 16 and I am still getting the error.

I guess this new version of lvgl is using more DMA_RAM ? I was still using version 6. Any clue @amirgon ?

It worked with fct=16 for me…

If you’re using this without SPIRAM we have to do a bit of work to reduce the amount of memory that MP allocates to itself so there’s something left in the esp-idf heap for LVGL and the networking stack… Probably use a 0.8 factor in the esp32 main.c…

1 Like

Yup, until now I was using the version without SPIRAM. I had this problem before Not enough DMA-able memory to allocate display buffer. But changing factor worked. Now it’s not working, even if I don’t use wifi etc.
Last case scenario I will use the M5stack fire (esp32 with SPIRAM) that I ordered for the case I got this problem again, but I would like to use the normal version if possible.
But since I don’t even have the mqboard yet I don’t how feasible it would be in the future to use everything just with the normal esp32.

About the problem with the lv_task_handler I haven’t got to that point yet and don’t really know the lvgl internals. But I am sure that somebody can help us. Maybe @amirgon or @kisvegabor if they have the time.

This is what I run (you would have to adjust the SPI pins):

import lvgl as lv

class Driver:
    def __init__(self):
        pass

    def init_esp32(self):
        import lvesp32

        # Import ILI9341 driver and initialized it
        from ili9341 import ili9341

        self.disp = ili9341(spihost=2, miso=19, mosi=23, clk=18, cs=12, dc=14,
                rst=13, power=-1, backlight=-1, mhz=10, factor=16, hybrid=True)

    def init(self):
        self.init_esp32()
        return self

def main():
    drv = Driver().init()

    lv.init()
    scr = lv.obj()
    btn = lv.btn(scr)
    btn.align(lv.scr_act(), lv.ALIGN.CENTER, 0, 0)
    label = lv.label(btn)
    label.set_text("Button")
    lv.scr_load(scr)

if __name__ == "__main__":
    main()

I was setting the factor wrong :man_facepalming: nvm. With factor 16 your example runs fine. But when I try to add the network stack I get this… I haven’t change anything else yet.

W (2739) wifi: malloc buffer fail
E (2739) wifi: Expected to init 10 rx buffer, actual is 6
Traceback (most recent call last):
File “main.py”, line 56, in
File “main.py”, line 52, in main
RuntimeError: Wifi Unknown Error 0x0101

Btw when you say setting a 0.8 factor in the esp32 main.c do you mean setting
mp_task_heap = malloc(mp_task_heap_size); to mp_task_heap ==malloc(0.8*mp_task_heap_size); ? For future reference if needed.

Yup, except that’s all integer stuff, so no literal 0.8… You could also subtract 16KB or thereabouts.

1 Like

Tried, got the same wifi malloc buffer fail error.
Will try the SPIRAM version now.

@tve have you successfully flashed a version with PSRAM? On my m5stack fire (16mb flash + 520kbRAM + 4MB PSRAM) I am getting:
E (830) esp_image: Image length 2108848 doesn’t fit in partition length 2097152
E (830) boot: Factory app partition is not bootable
E (832) boot: No bootable app partitions in the partition table
Is this normal? I’ll try to compile using espidf v3 instead of v4. Anything else I can do?
Sorry for all the trouble!

Ouch. That says that the flash partition for the app is too small. So you need to modify partitions.csv to give it more space. That’s a pain.

Oh god. Why can’t one just be happy and have everything working at the first try! :roll_eyes:

Wohooo! I manage to shrink my .bin file by getting rid of some of the lvgl features that I predict I am not going to use (Disable them in lv_conf.h). Seems to be working now… let’s see.
My program also works fine just as I was using the normal micropython version.
Now let’s test https://github.com/tve/mqboard !
Thank you very much for the help provided. On to the next problems :sweat_smile:

It’s not a big deal to change the partitions size. I’ve already done it for lv_micropython, see https://github.com/lvgl/lv_micropython/commit/218e4311bba4f2cd2df61b53febb08b4ade48c04

1 Like

Thank you! In case I need I’ll know where to look