In this article, you’ll learn to cross-compile and integrate LVGL with MicroPython and deploy the UF2 firmware to the Pico board. Additionally, we present a sample Python code that demonstrates how to initialize a GUI and enable resistive functionality using the XPT2046 touch controller, commonly paired with SPI display drivers such as ILI9341
1 Like
Thank for you for this topic! It is very useful for the beginners like me. I did everything as described on the webpage but finally I got the following:
MicroPython v1.20.0-2492.g48ea6e4cf on 2025-09-28; Raspberry Pi Pico W with RP2040
Type "help()" for more information.
>>> help('modules')
__main__ asyncio/__init__ hashlib requests/__init__
_asyncio asyncio/core heapq rp2
_boot asyncio/event io select
_boot_fat asyncio/funcs json socket
_onewire asyncio/lock lvgl ssl
_rp2 asyncio/stream lwip struct
_thread binascii machine sys
_webrepl bluetooth math time
aioble/__init__ builtins micropython tls
aioble/central cmath mip/__init__ uasyncio
aioble/client collections neopixel uctypes
aioble/core cryptolib network urequests
aioble/device deflate ntptime vfs
aioble/l2cap dht onewire webrepl
aioble/peripheral ds18x20 os webrepl_setup
aioble/security errno platform websocket
aioble/server framebuf random
array gc re
Plus any modules on the filesystem
Unfortunately is not the same as mentioned in the article: “LVGL version 9.1 with MicroPython 1.24.1”
The example from the article shows: Running LVGL 9.1
Anyway thank you!
Weird, I think there is an issue with the github link, because what should be fetched is version 1.24
can you run the code?
Yes, I ran the example from your article (website)
I got message in TonnyIDE : “Running LVGL 9.1” (unfortunatelly I dont have ILI9341 with SPI - My LCD just has the 18bits parallel interface - Im designing the “SPI-parallel” convertor by using FPGA-CPLD for using with LVGL - I saw that the last revision LVGL supports the parallel interface as well )
That means simple code works without display and touch screen XPT2046.
Can we troubleshoot somehow that issue with “wrong” revision of uPython?
I have saved the log message during cloning and compiling LVGL and uPython just for refernce.
So that’s good, then LVGL-9.1 is correct.
it’s very unlikely using version 1.20 instead of 1.24 affects something, by the way my suggestion is using ILI9341 displays with SPI interface because for such a display SPI speed is fine to get a good refresh rate
I have connected to SPI ILI9341 Display and didn’t see any widgets on the screen.
The example stock on the step:
disp = ili9xxx.Ili9341(spi=spi, dc=9, cs=13, rst=15, rot=0)
For testing purpose I used ili9xxx-test.py which used Ili9341_hw class and that test works properly.
I used also LVGL ver 8.3 (some member of forum shared it here) - it works also perfect! I have tested many widgets and bmp pictures to display on the screen.
I dont understand what is wrong with compiled LVGL 9.1.
Unfortunatelly it does not provide any errors.
Did you test with my code and Python files?
yes, I used your example from website.
Weird, My TFT LCD is ILI9341 with XPT2046 Resistive Touch. Good that I’ve put the proof.
it must work if the controller is identical, Make sure your LCD module is SPI with no conversion between the Pico and LCD.
I suggest you Nuke Flash the Pico to erase everything, then flash it with your compiled LVGL-9.1 and then run my example. do not mix with your python files, you must be able to replicate the results
I ordered exactly the same for that reason (to try LVGL) : 3.2inch SPI Module Touch Screen Shield Display Module SPI Serial ILI9341 320X240 5V 3.3V with Touch Pen
It is exactly what I did by following sequence of steps from you webpage. I have used attached archives with example and all files of support for ILI9346 with XPT2046. There is no any mix with my files.
I have tested LCD ILI9346 with XPT2046 by using class “_hardware”.
LCD ILI9346 and XPT2046 operate properly.
If you used an ESP32 you are able to connect a much larger assortment of displays instead of being limited to single lane SPI. You would use this binding instead of the official one…
It has a plethora of built in display drivers and input drivers, built in touch calibration, built in IO expander drivers. supports double buffering with DMA transfers. Display connection types that are supported are single, dual quad and octal SPI connections as well as 8 lane and 16 lane I8080 and RGB connections. I2C connections are also supported. MIPI DSI connections are coming pretty soon. It currently only supports the ESP32 line of MCU’s. If you decide to give it a go I suggest getting an ESP32-S3 with 8mb or 16mb of RAM and 16 or 32 MB of flash. If you get one of those MCU’s make sure it has octal flash. the 16mb variant comes in either quad or octal flash.
My suggestion is to use either an 8 lane or a 16 lane I8080 display as these are going to be the fastest that is currently able to be connected. When DSI becomes available that will be a better choice for a display but it will also require getting an ESP32-P4 and not the S3.
I have displays based on SSD1963 and ILI9486 with 16bits bus, also RGB24bits display but unfortunately I dont have any plans to use ESP32 in the future.
All of them work well with FPGA and CPLD and PR2040.
It sad to know that LVGL currently only supports the ESP32 line of MCU’s.
I have LVGL rev 8.3 from this forum witch works well with Raspberry Pi pico (unfortunately without support PicoW). I have tested my display with that (rev 8.3)- it works properly.
no no no LVGL supports many many different types of MCU’s. Micropython however does not and the MCU’s it does support it doesn’t have a complete set of IO drivers written for those MCU’s.
I don’t know enough about other MCU’s to write the drivers needed for MicroPython other wise that link I gave you would offer more support for other MCU’s. I have not has anyone willing and knowledgeable that was willing to help out with it which is the reason why there isn’t more offerings for connections and MCU’s beyond the ESP32.
Yeah I have seen that link and many years I try to make the friendship between my Raspberry Pi Pico W and LVGL but I never had a success with compilation of source file LVGL with embedded uPython.
I had to use the compiled by someone from this forum the old version without support of PicoW.
That link is not what you think it is. That link is to my version of the binding. It is much easier to use that the official binding. I can get my binding to work with most of the MCU’s that are supported by MicroPython but they will be limited to single lane SPI only and only using a single framebuffer. No DMA support either.
Building using the binding I wrote is really simple. You would need to have only a few requirements installed, things like Python, build-essentials and possibly cmake. other than that it’s a single command to compile the library. You don’t need to install/setup any SDK’s. This is all done internally in the build system I wrote. 2 simple commands is all that is needed… It would look something along the lines of…
apt-get install build-essential cmake ninja-build python gcc-arm-none-eabi libnewlib-arm-none-eabi
python3 make.py rp2 BOARD=RPI_PICO_W DISPLAY=ili9341 INDEV=xpt2046
Then you would need to enter the command to flash the compiled binary to the MCU.
That handles baking the driver you want to use into the firmware. Display and touch drivers are a runtime choice meaning they don’t have to be chosen at compile time. The drivers are written in python so you can upload the python source files to the MCU after you have flashed the firmware, there is no requirement to bake them into the firmware. This allows you to upload several different display drivers and to pick which one to use when the MCU boots, no need to compile and flash firmware if you change the display or the touch you are using.
In the future I am going to add the ability to collect IC information from a connected display and the user will be able to use that information to select the correct display driver when the MCU boots.
I really want to offer all of the available connection types for other MCU’s. I simply do not have the time to invest to learn how to do that for other MCU’s. All of the drivers I have seen available for other MCU’s need to be chosen at compile time and not runtime so they are of no help.