Support for Python3

Re lv_binding_micropython Github issue #13: Support for regular python

I’m interested in an lvgl Python3 module for use with the Onion Omega2. It has a Linux OS and supports framebuffers as well as full Python3.

Is it feasible to modify the existing lv_binding_micropython generator to produce Python3 bindings? How different would the Python3 bindings be?

I’ve taken a look at but it looks like there’s been no development since May.

@amirgon would you be interested in collaborating?

Hi @Lazar_Demin!

Under the hoods, Python and Micropython have several significant differences.
The mechanism for adding a native C modules is very different.
The memory management is different. Python relies on reference counting while Micropython uses Garbage Collection.
So, while the front end (python syntax) is very similar, the backend is very different.

My point is - I don’t think you can “convert” the Micropython binding to Python binding without re-designing and re-writing significant parts of it.

My focus is Micropython and it aligns well with LittlevGL, both were designed to work well on resource constrained devices such as microcontrollers.

As far as I know, @rreilink’s work is the most advanced attempt to create Python binding for LittlevGL. His bakcend is different but there was a time when he and I tried to collaborate and create a unified front-end. Unfortunately, it looks like @rreilink is busy with other things and didn’t make much progress with the Python binding for many months.
There are several open questions regarding the python binding, for example, how to manage memory and how to handle access to structs and fields. While on Micropython these are implemented and are working well, I’m not sure what is the best way to implement those for Python.

Did you consider using Micropython?

The Omega2 is a powerful device, but still constrained by RAM and Flash.
You could try the unix (Linux) port of Micropython on the Omega2, it could probably be an interesting project with a lot of potential!

Oh, and one last thing I forgot to mention, if you are worried about Micropython API to other modules with C API (other than LittlevGL) - you can also use the micropython bindings to interact with any other C library! (under certain assumptions).

More details here:

Thanks for the detailed response! I’ve tried out the linux micropython port on the Omega2, it looks like it’s stable and very usable. Especially with the micropython-lib package that adds a whole suite of standard libraries.

Based on the work you’ve done, how much additional work would be involved in creating a standalone micropython littlev module? Would you be interested in working on this with the Onion team?

Btw, we have hardware prototypes ready for testing. We can send you a beta unit if you’re interested.

Yes… but take into account that many of these libraries have limited functionality and some of them are even just placeholders to prevent an error when you try to import them (but not when you try to use them).
It doesn’t get close to the “real” Python standard library.

Don’t expect a random python script which has some standard Python imports to “just run” on Micropython.

If I understand correctly, you already successfully ran both lvgl and micropython on Omega2. Is that correct?

If that’s the case, it should be pretty simple to create a micropython littlevgl module.
Did you try building lv_micropython? (try branch dev-6.1, that’s the closest to micropython’s upstream)
Did you have any problem building/running lv_micropython?

How “open” are your hardware and software? What license do you use?
When I contribute on my own free time, I limit myself to open projects such as lvgl (which has “MIT” license)

If your long term policy is all-embracing open hardware and software - I’ll be happy to help and collaborate!

That’s right, we’ve been able to run C lvgl and micropython on the Omega2.

From my understanding it looks like lv_micropython builds a full micropython runtime that has an lvgl module built-in.

Our preference would be to stick with the already available micropython package for OpenWRT and load lvgl as an external module. That’s where we could use your help since we’re new to micropython.

The intention of this project is to provide a reference design for display applications with the Omega2. So the schematics and layout of the hardware will be open source, as will any work done with drivers and application software.

Generally, we use GPLv3 but are open to other licenses.

I don’t think you could load lvgl binding as an external module without rebuilding micropython.
I had to do some small but important changes in micropython itself.

For example, lvgl uses micropython’s Garbage Collector for memory management, so I had to add lvgl gc-root pointers to micropython (see MICROPY_PORT_ROOT_POINTERS).
External modules don’t support Micropython gc.

Another example is a change I tried to push to micropython but unfortunately didn’t succeed yet, so I had to do it on my micropython fork.

btw, in micropython External C Modules feature don’t mean you can load the module on runtime like you load a shared library. What it means is that you can add your C files at some location and build micropython without manually writing the Makefile. So you would have to build your OpenWRT micropython project anyway if you want to add anything.

Remember that micropython was primarily designed for embedded platforms where you usually don’t load code dynamically, like you do in Linux.

What you can do, is build a fork of your OpenWRT micropython package with lvgl binding included.

What about other projects? What about the entire Onion policy?
I took a look at your website and couldn’t find any information about hardware/software licensing, or about what is supposed to be open and what is not.
I found, however, a few troubling posts on the forum.

I think that what’s missing is clarity.
What is the company’s policy and intentions regarding licensing? What parts are GPL? What parts are MIT? What parts are proprietary?