Microcontrollers are wonderfully useful things, but programming them can be a little daunting if you’re used to the simplicity of compiling for regular PCs. Over time though, this has become easier. Communities have strayed away from assembly code and created higher-level languages such as Micropython, to allow these devices to be programmed in a more accessible manner. Unfortunately, Micropython has historically lacked a decent high-level GUI library. Thankfully, that’s no longer the case, with [amirgon] porting LittlevGL to the platform.
Putting a GUI into a project with a screen seems simple, until one actually gets down to brass tacks. A simple button can consist of a background color, text, and a symbol – and that’s not even considering the use of shading or other visual effects. Having a library to handle the grunt work can massively cut down development time.
LittlevGL is the work of [kisvegabor], and is programmed in C, but this effort has made it possible to integrate it with Micropython code. It’s all object-oriented, and thus works well in the broader Python framework. [amirgon] notes that it’s particularly good for quick development, due to Python’s ability to run code without a slow compiling step.
There are other approaches to this problem, too – with MyOpenLab being a particularly versatile example.
I’m glad to see LittlevGL gain a bit more popularity. I stumbled across it at work but I’ve used it (and even contributed a few small things) in a private project and really like it. It’s fairly easy to include, just have to provide a bit of hardware interface code and it works. It looks nice, has a ton of features and doesn’t take up a huge amount of space.
For a GUI article I feel it lacks of illustrations :p So does the official website… But hopefully you’ll find what it looks like on the Gihtub page: https://github.com/littlevgl/lvgl
“Python’s ability to run code without a slow compiling step.”
Yeah. Much better to take that hit thousands of times rather than once…
I’ll bite ;)
If the code runs fast (maybe 10’s of milliseconds), either option is fine. But interactively coding in python is probably 10x faster to develop than using C/C++. And it’s much faster again if you don’t have to compile and flash the microcontroller with each iteration!
Yeah, because your super fast brain certainly notices the slow interpreter going through the code, and it makes testing modifications you did on the code grueling because of that, right?
So, you’re both arguing that the users should suffer for the laziness and lack of forethought (thinking avoids iteration) of the coder. Sadly, that view is far too common nowadays. And yes, I’m grouchy about it having spent the last week cleaning up after just such a view rendered our code vulnerable to exploitation…
No, they are arguing that in SOME CASES, using python (or other interpreted language) saves a lot of time with negligible effect on end result.
In other cases using python may save negligible time with negligible effects on the end result, in which case it doesn’t really matter what language you use.
In yet other other cases using python may save time at the result of significant slower end product. In these cases using something compiled would be beneficial.
In yet other other other cases, not having the option of doing something in Python may cause the individual creating the product to simply not do it, in which case a slower product may be better than no product. Someone can later notice the product is useful and recreate in a compiled language to make it faster.
Gray – the world is full of shades of gray.
Modify, Compile, Run, Repeat sucks. I know, I do it all day long for a living.
Previously I worked in an interpreted environment. I prefer to be where I am now for reasons that have nothing to do with the technology. Tech wise the interpreted environment was MUCH MUCH better.
You should read up on “critical sections”. Most code really doesn’t need to be all that efficient, especially on modern hardware. For most of that code the user will never even notice the difference between compiled and interpreted. It’s only the stuff in really long loops that repeat a billion times or complex math like calculating 3d textures for the latest game or simulating star formation for an astrophysicist and stuff like that which really needs to be as efficient as possible.
For everything else the only differences the end user will notice is fewer bugs and faster release of new and improved versions when the developer is working in higher level, maybe even interpreted languages.
Just a note. Compiled code means a task is done faster and your microcontroller can sleep the rest of time. So saving power.
You can compile the Python code, or translate it to C/C++ or ASM or … However, development is faster and easier with interpreted languages.
I am a big fan of LittlevGL, I always prefer to use the esp32 using esp-idf. I am not a micropython/Arduino fan but I would like to try those for some basic prototyping and all but not for products. To use the true power and potential of the esp32, I prefer to develop code in C along with esp-idf so that we can get a lot of juice out of it.
John, you don’t have to choose one over the other. You can write some code in micropython (for example building and managing the GUI staff) and keep all the critical stuff in C. Micropython on ESP32 is built on esp-idf so you will feel pretty much at home there.
btw, this is what I do – write the critical parts in C with esp-idf and freertos, and all the rest with micropython.
I haven’t tried it yet. But sounds good. Will try mixing up both.
would I be able to have the main code in micropython, and then access the bluetooth on the ESP32 with some C code via esp-idf?
Yes, of course.
In order to call a C function from micropython code you would need to write a micropython extension, as described here: https://micropython-dev-docs.readthedocs.io/en/latest/adding-module.html.
In fact, the bindings between micropython and LittlevGL is actually one huge auto-generated extension module like this.
The new version of LVGL (v7) is released and there a lot of news too (new website, establishing LVGL LLC, providing services and so on).
Check it out here: https://blog.lvgl.io/2020-06-01/announcement