Littlevgl/micropython on a non-psram ESP32?

Has anyone had success using littlevgl/micropython on a non-psram ESP32 module? e.g. 520 kB internal ram only. Littlevgl works well for me on a 4MB psram ESP32 but not on a regular ESP32 .

Everything seems to work (builds ok, runs after flashing, no exceptions running a uPy program, ESP communicates to display via SPI) except the display stays blank.

Usage:

  • ILI9341 display
  • custom build with littlevgl
  • C driver for ILI9341

Perhaps a psram ESP32 is needed to run littlevgl/micropython? If not, I’ll spend some time to find the problem in my configuration. Thanks!

I’m guessing that you may be running out of heap space. Did you enable LittlevGL logging and see if anything useful gets printed?

Hi @miketeachman,
I don’t see any special reason why psram would be required for lv_micropython.

The lvgl binding itself costs 12 bytes per lvgl object and 8 bytes per lvgl struct, which is not much and all memory is garbage collected.
If you are using the default ili9341 micropython driver (which you should, as it is the most up to date), it would print an error in case it fails allocating DMA ram. If you got no error then memory allocation went fine.

Enabling logging, as @embeddedt suggested, is a good idea.
Logging is enabled by default on lv_micropython, but you need to register a callback.
Something like this will do:

lv.log_register_print_cb(lambda level,path,line,msg: print('LOG: %s(%d): %s' % (path, line, msg)))

When I have some time I’ll try configuring my board without psram and see if it works for me.

Thanks for the logging suggestion. I’ll give that a try. I’m using the C driver for the ILI9341. Is there much performance penalty when using the Python driver?

No.
The critical parts in the Python driver are still implemented in C (when hybrid=True, which is the default), so performance penalty is negligible.
It consumes just a tiny bit more RAM, and requires a little more FLASH for the esp-idf binding, but I think it is worth it.

Currently I’m maintaining and updating only the Python driver. It implements DMA with either single or double buffer, gives more control over initialization (for example, setting portrait/landscape modes) and implements tear down (deinint) which is missing on the C driver.

My recommendation is to use it as is, or at least use it as a reference when implementing a C driver if you insist.
In fact, I removed the C driver from lv_micropython Makefile and I’m keeping the old C driver on the repo just for reference.

The same applies to xpt2046 driver as well.

Good news - I found the problem that caused the blank display. It was a hardware issue. I needed a pullup resistor on the display reset pin. Without the pullup resistor the display was being held in reset, resulting in the blank display.

Summary: Littlevgl/micropython is working on a regular ESP32 development board that has 520 KB SRAM. Yay !

1 Like