Would it be possible to export my GUI from Squareline Studio to Micropython and upload to Raspberry Pi through Thonny to run?
What have you tried so far?
I am new to the world of embedded system and GUI programming.
I have tried very hard to find a tutorial about this workflow but all I can see are for C or C++
Would highly appreciate any help or lead to this endeavor.
Thank you!
The MicroPython board-template (in desktop categories) can export MicroPython code. Itâs not full Python, but MicroPython has only a subset of Python. But the LV-MicroPython code compiled to Raspberry Pi can run those LVGL-oriented MicroPython scripts. (See instructions/scripts in the exported board-template to build it successfully, the target you want is âunixâ. Pre-built variants are only made for Intel processor, not for ARM which RaspBerry needs.)
Yes, the board-template (if you have a recent version of the board-template starting with v1.0.2 for LVGL-8.3, or v2.0.0 for LVGL-9.1 available already in SLS) has the build-instructions and scripts along with the precompiled âmicropythonâ executables. These include cloning the exact revision of lv_micropython, lv_bindings and lvgl with submodules. If you have the board-template in zipped form, you donât even need to export anything from SquareLine studio. The is essentially the same as original lv_micropython repository, but with many additions to build for Linux and even for Windows (which lv_micropython didnât support but I found out the ways to build it.)
âBuildingâ is kindof synonym for âcompilingâ, though building is a broader term including build-scripts & makefiles, compiling, linking, etc.
if I build the lv_micropython correctly and it runs on my raspberry pi, what will happen if I execute the main.py?
Assuming my app is 480 x 800 but I am using a monitor thatâs 1920 x 1080, would it cause any issue?
Iâm a bit confused by your comments now, if itâs a Raspberry Pi or a Rasbperry Pi Pico actually.
If the target is âPicoâ, not the normal Raspberry Pi, the display handling entirely depends on the connected display-controller. So the unix/windows+SDL2 targets in the MicroPython board-template canât be used directly but can serve as working examples. (Also, Iâm not sure if MicroPython will be that fast if MicroPython is used on it, as it already kindof sluggish even with results compiled from C code.) Itâs worth a try, because the display-driver and LVGL code is actually coming from C code even with MicroPython, itâs only the code put into the interpreter which is Python after all. For Pico, youâll need to scale to bigger resolution by software, which is slow, but if itâs a monitor somehow, it can do the scaling by itself.
If itâs a normal RaspBerry Pi, it will depend on the OS and SDL2: if you use the desktop environment SDL2 is there, for Raspberry OS Lite you can find our pre-compiled SDL2 in the Raspberry Pi board-template. SDL2 can scale the 480x800 resolution to be full-screen with the proper API-calls and display-drivers/backends (e.g. KMSDRM), and the scaling can even be hardware-acceleratedâŚ
Hi Hermit, thanks for the clarifications! I do apologize if I didnât make it clear earlier.
I started out trying to make it work on a Pico but decided to switch to a Raspberry Pi 5 to not worry about the firmware.
I am using a normal Raspberry Pi 5 (I will refer to it as RPi5).
I just figured out how to make the UI appear in LVGL Simulator. Itâs the first time since I started this forum thread.
The UI is currently exactly the âThermostatâ example in the SLS, exported from my Macbook and copied to RPi5.
A few follow-up questions -
In my LVGL Simulator on RPi5, I am unable to pull the sliders on Temperature & Fan Speed control like I could in the SLS play mode. Is it because my ui_events.py is currently empty?
If thatâs the case, what would be a good placeholder code in ui_events.py to enable me test the action of slider in LVGL simulator?
My end goal is to create a GUI based on this Thermostat example to control some motors connected to RPi5âs GPIO.
Good to see your progressâŚ
If I deduce correctly from your tiny screenshot you donât call lv.task_handler() / lv.timer_handler() in your while loop, so LVGL canât do its input-handling and refreshment tasks, probably thatâs why you cantâ move the slider & arc.
Thanks Hermit,
With a few fixes: A. adding lv.timer.handler() in while loop B. type cast with lv.slider.__cast__for event_struct.get_target() C. a python module name correction. I am able to move the slider and arc. But I would love to ask a few more -
in the example in SLS, there number inside the arc that show the current temperature. I am still unable to make the number appear. It appears although itâs not showing the value of arc, it should at least give me 23. Do you know what might be wrong?
2. I am testing the other sample included in SLS. The interactions are working but It appears all the bitmap textures are not(orange, distorted and not displaying correctly). Any idea what might be the cause?
For the thermostat temperature value, I suspect your exported python code has problem with loading/using the special âNumberâ font. If itâs so, you probably have a warning dropped by LVGL in the console. (LVGL-9.1 doesnât handle 8bpp fonts. If theyâre 8bpp, converting to 4bpp might help.)
The colour problem might come from the fact that the color-depth in project-settings is set to 16bit and the colours somehow get swapped. Maybe itâs just the image-colours that get swapped. The â16bitâ vs â16bit swapâ in project settings might do the trick. But as LVGL-9.1 handles it differently (and there 16bit swap is done by the flush-callback, and not in advance by the image-conversion) you might have proper results by simply changing between LVGL-version 8 and 9.
I am able to resolve the color-depth issue by increasing it to 32bit and re-export.
However the font is still an issue. The fonts are confirmed to be 4bpp. I have the following 2 lines in my ui.py and the print gives me âNoneâ. what are other potential issues?
Your python-code seem to use incorrect path. At least, when exporting custom font with the MicroPython board-template, this line looks something like: font_Font1 = lv.binfont_create("A:ui_font_Font1.bin")
It uses the âA:â drive instead of direct â./â. Drive âA:â is pre-configured for STDIO filesystem-driver to point to folder ââ (aka â./â) in the lv_conf.h that the MicroPython executable is built with.
It works with the code exported from MicroPython board-template on Debian Linux which I use. I think it should work in pretty the same way for you on the Raspberry Pi, which is also Debian essentially, just an ARM one. So I think you have some difference in your lv_conf.h or other thing before compilation into ARM âmicropythonâ executable. Maybe try to find the cause by creating a very simple example-project in SquareLine Studio with only a single label on the screen having a custom font. Check if it works for you by exporting it with the MicroPython board-template. If it works on your PC, then this same exported folder should work on the Raspberry Pi the same way if you compiled the ARM micropython-executable correctly⌠if the simple label with custom font works, then thereâs some other problem with the more complex Thermostat project export⌠if not, the issue is really the font-handling, all font-related settings should be double-checked in lv_conf.h, and, and should be check if every font-related build-phases were fine during the compilation of the ARM micropython executable.
yes! I will try the simple export on a Debian Linux on x86 platform. At the meantime, would you mind sharing your lv_conf.h so I can cross check my settings against yours? thanks a lot and happy new year!
I tested with the same lv_conf.h that is present in the available board-template in âcorrections/lib/lv_bindingâ (but attached anyway), nothing special, no modification. lv_conf.h (33.4 KB)
Happy New Year to all of you tooâŚ
thanks, there are 8 files total in the correction folder in exported board-template. do I replace all folders in my lv_micropython source files and rebuild my lv_micropython?
I have been using the one I got from lv_micropython github and maybe thatâs one of the reasons why it does not work.
Itâs always a good ide to start a fresh build. Yes, all the corrections are needed (build.sh copies all by overwriting these files in the lv_micropython). Itâs crucial that the exact lv_micropython version is used (even revision/subversion counts), thatâs why the clone.sh gets it with the exact hash-numbers, not just by some name-based matching.