Is there a good tool for generating STM32 Baremetal GUIs?

[BlueEagle]

I have a STM32 project that uses the LTDC and custom graphics drivers to draw text, images, shapes, etc.

It all works, and I've been making GUIs this way for years but it takes FOREVER to make the GUI look good. Everything has to be carefully arranged by the pixel, and text has to be manually erased and redrawn from the buffers all the time, among other issues.

I would really like to use a graphical GUI editor so I can quickly draw up screens with buttons, images, sliders, and all that. I've been trying to set up TouchGFX, but it's been like pulling teeth.

My projects are almost entirely custom baremetal code so ideally I could just generate some graphics code and copy and paste it into my project. I don't really want to add a bunch of bloat in the form of libraries if possible.

Do any of you guys have a toolchain that works well for this?

[hansd]

Have a look at LVGL.

[BlueEagle]

Have a look at LVGL.

LVGL looks perfect, but I hate that the designer is a subscription service.

[hansd]

Somewhere they have to make some money  You don't have to use the designer. You can do it by designing it on the PC with the simulator using the library and then port it to your board. All free of charge.

[westfw]

I don't really want to add a bunch of bloat in the form of libraries if possible.

GUIs are like the #1 cause of program bloat, aren't they?  Before you know it you have options to support 3D-transparent buttons with localization in at least a dozen languages and fonts.    :-(

[wek]

I was about to recommend LVGL too, but then I realized exactly this - @BlueEagle is obviously after the designing part of the whole thing. Sure, the library itself solves a ton of headaches, that's why I'm using it, too; but the pixel-counting, searching-manual-for-the-right-function-or-symbol etc. processes are too familiar to me, too, to understand what pain it can be.

There's probably no good solution. The whole bundle is too expensive to be free, you'll pay it somewhere that's 1. And should the bundle be attractive to masses in order to split the cost somehow, it inevitably imposes a "modern feel and look" upon you together with whatever convenience choices there are for the authors, which you have to accomodate to. TouchGFX is paid through the cost of the chips, which may sound "free" enough; but it suffers from 2 (C++, imposing a certain workflow and general bloat is that developer-convenience you have to suffer).

Back in the days of simpler dot-matrix displays, I concocted myself a tool, which on PC looked like the late PaintBrush, and through UART connection to target it drew on the target display. Lot of effort, but spared me even more effort with the pixel-shifting on target etc. I even simulated the font generator for targets with T6963. And I supported copy/paste through standard windows clipboard (which was a PITA of its own kind, due to microsoftoisms). Kinda similar to the "can simulate on PC" approach, except that pictures on those displays looked very differently than on PC monitor.

A couple of years ago, in ages of STM32 and LVGL and TFT, I tried to write a tool which run on the same target and allowed to visualize and manipulate the internal LVGL structures through a menu system written in the same LVGL... much like a visual designer, but on the target. I failed miserably, the thing was complex, rigid and cumbersome... So, maybe something like that could be split off to PC, a tool which would connect to target, read out the LVGL structures, visualizing them in a tree or other suitable form, and allowing to manipulate its values... it won't need to be fancy, all it takes is a way to click through a tree and enter numberic values. It does not need to visualize the result - it's visualized automagically on the target upon sending the changes and redraw. However, that's still a huge task which would require modification of LVGL itself (read: irreversibly forking from the official sources with all the consequences) and in no way would pay off as an internal project.

But, if your display system is simple enough (I presume, tile-based), this may be the way to go.

JW

[JPortici]

Have a look at LVGL.

LVGL looks perfect, but I hate that the designer is a subscription service.

I feel your pain, but at least it's only the designer. It's not *that* hard to make simple but effective layouts by hand.
Library is free, open source and very powerful, look and feel from this century, can use it on any target with enough ram, even on PC. Simulator is free and works. If you ask me that's miles ahead any other graphic library (Qt would be even better but it has very few targets and you don't want to know how much it costs)

EDIT: I see they added a perpetual free license for personal use, cool! And perpetual licenses for business. They weren't there a few months ago when i first saw they released the editor

[BlueEagle]

I tried to write a tool which run on the same target and allowed to visualize and manipulate the internal LVGL structures through a menu system written in the same LVGL... much like a visual designer, but on the target.

You know, I think you might be on to something with that. Maybe something quick and dirty, like making the positions statics and using the debugger to edit values until everything looks ok.

[ajb]

You could also go the other direction: If you've already got a set of low-level draw functions targeting an internal framebuffer, then (as long as you're not relying on ST's dedicated graphics peripherals) you could build that to run on a PC and directly display the resulting output.  From there you could similarly use a debugger to tweak and redraw, or ingest key values from a text file and update live, or go all the way and implement some sort of interactive editing. 

On the other hand, if you're spending a lot of time on pixel-by-pixel alignment of primitives, it may be worth spending more time building up more sophisticated graphic functions/objects that handle the pixel math internally.  Something like a button is pretty obvious in that regard, but list/grid layouts, or even basic templating wouldn't be too hard to create and could have a significant return on the time investment.  Yes, this is technically more overhead and could be considered 'bloat', but consider that your time is generally much more valuable than the CPU's time, so trading off some of the latter for more of the former is usually a good bargain.  All depends on what aspects are currently bogging you down.

[westfw]

Do any of the phone app builders generate high-level descriptions that could be parsed/compiled into C code using your graphics libraries?
It's been a while since I've tried to program a phone, and the churn rate is extraordinary, but I seem to recall that screen layouts and etc end up as some sort of 'resource' file rather than actual "code."

[zapta]

Have a look at LVGL.

LVGL looks perfect, but I hate that the designer is a subscription service.

You don't have to use the designer. The designer is relatively new and people used LCGL for years without a designer. 

[Scrts]

Did you see TouchGFX? It says it's free.
https://www.st.com/en/embedded-software/x-cube-touchgfx.html
https://www.st.com/en/development-tools/touchgfxdesigner.html
https://support.touchgfx.com/docs/introduction/welcome

Another to consider:
https://www.embedded-wizard.de/platforms/stmicroelectronics

[AVI-crak]

Writing your own library is surprisingly simple.
First you need primitives - point, line, curve, binary rectangle for graphics.
Then you need to write interface primitives - text area, colour area, picture.
A layer of logic is written on all this ugliness. These are simple algorithms, each one individually fits into a couple of lines.
The topmost layer is the user interface. These are those functions and structures that are visible when you connect the library to the project.

It's simple, you can write it or use someone else's.

[DavidAlfa]

AVI-crack, we all know how to use primitives, but designing a GUI manually is very tedious and slow.
He's asking for a WYSIWYG editor, were you make your design and it translates then into those primitives.

Alternatively, using existing DWIN / Nextion devices might be cost-effective.
You have the editor and the LCD module doing the heavy work, the mcu only need to tell the module "show this menu", "Show this value there", etc.

[ali_asadzadeh]

Just googling, and found this https://github.com/CURTLab/LVGLBuilder, it's a free WYSIWYG editor for LVGL

[Ario]

I use EmWin from segger, if you use a nxp chip you may use emWin for free. Alternatively if you use it for non-commercial purposes it is also free I think.

[BlueEagle]

I use EmWin from segger, if you use a nxp chip you may use emWin for free. Alternatively if you use it for non-commercial purposes it is also free I think.

Wow, 15k USD for a license. Maybe next time I'll consider using a nxp chip, but that ship has sailed on this project. Thanks for the suggestion.

[DavidAlfa]

Also free for stm32!
https://www.st.com/en/embedded-software/stemwin.html

[peter-h]

This is interesting. I started looking at this a while ago:
https://www.eevblog.com/forum/projects/small-tft-display-5x5cm-for-moving-graphics-over-spi/
and got to this: https://www.ramtex.dk/display-controller-driver/rgb/st7789.htm

That gives you fairly low level stuff like drawing polygons, text, etc, and it keeps track of object overlap which is quite tedious to do manually (it is usually not feasible to just redraw the whole display, due to the large amount of data, especially over SPI). The trick with this $500 library is matching the display controller it supports with the display(s) you want to use, otherwise you end up buying multiple $500 licenses. But I found a good match which covers displays up to almost VGA size.

There is a lot of open source code for driving specific controllers and setting a pixel or even drawing a line (Bresenham), but one needs much more than that in most cases.

What I wonder is where LVGL comes in. I can see you can construct the page, a bit like VC++ has an editor where you can drag/drop GUI objects like radio buttons onto a form. But does it support a wide range of graphics controllers directly? It states
To make your display work with LVGL all you need is a function which can copy the rendered image to the display. If you have it you can integrate LVGL in 10 minutes.
which sounds like you need to write the controller dependent code - either copy pixels or maybe a rectangle, or a polygon? So you probably want the above Ramtex library as well, or spend some days or weeks writing that code.

That ST lib mentioned above probably has a huge learning curve, looking at what else ST do. I've been up the Cube IDE + LWIP + FreeRTOS + etc curve. Be prepared for structs of structs of structs and thousands of lines of definitions and typedefs and macros of typedefs of macros

I don't think you can get way from "pixel counting" if you want a really slick looking product - unless your display is huge

[jan28]

I've been using EEZ-Studio to generate UI and most of the UI interaction (dynamically enable/disable buttons, switch pages, ...) for a project. It is LVGL compatible.
https://www.envox.eu/studio/studio-introduction/

It's open-source and the current version is pretty feature complete for touch displays. Documentation is getting there now, but it might have a learning curve because it is not juist UI element placement but also low-code with links to native code. I like this mix.
On this forum: https://www.eevblog.com/forum/testgear/eez-studio-for-accessing-your-(scpi)-instruments/ but not very active. Discord is more active.


Disclaimer: I'm an active member of the community.

[hansd]

"What I wonder is where LVGL comes in. I can see you can construct the page, a bit like VC++ has an editor where you can drag/drop GUI objects like radio buttons onto a form. But does it support a wide range of graphics controllers directly?"

LVGL is a widget library (buttons, sliders, text boxes etc) build up from primitives and sits on top of the display driver.
It needs a memory buffer for drawing and your application handles the transfer to the display. Development can be done in C or other ports like Python etc.

[BlueEagle]

I stopped trying to set up TouchGFX, and started on LVGL. Setting it up is so much easier. It only took me about a day to get some test graphics displaying. Haven't tried the WYSIWYG editor yet though.

[AVI-crak]

I agree, LVGL is simple and affordable.
All graphics libraries are exorbitantly fat, LVGL is no exception. However, LVGL can be significantly reduced in size without headaches. It is almost impossible to do the same with other libraries. The reason is the huge number of cross-links.

[JPortici]

But does it support a wide range of graphics controllers directly?

https://docs.lvgl.io/8.3/overview/renderers/index.html

There are a couple of integrated controllers there. (Even though there are not docs in the site, they are actually supported in the source code)
But if with "controller" you meen a LCD driver IC, in most cases the only thing to do is to shove pixels, and that's always up to you (parallel, spi, i2c, interrupt based, dma based, ...)

[peter-h]

From the above URL:

Renderers and GPUs
Software renderer
SDL renderer
Arm-2D GPU
How to Use
Design Considerations
Examples
NXP PXP and VGLite GPU
DMA2D GPU

I don't see any LCD controllers there, like Ramtex support:
ST7789 TFT display driver library
The ST7789, ST7789C, ST7789V, ST7789V2, ST7789V3, ST7789VI, ST7789H2, and ST7789VW display controllers are supported by the RAMTEX S6D0129 display driver library package.

The devil is in the detail. I guess some arm32 CPUs, connected to an LCD via a 16 bit or 32 bit bus, can do this fairly efficiently using built-in hardware features, but if the LCD is SPI-connected, none of these can be used, and the amount of data which needs to be transferred is critical. The ramtex library seems to be able to optimise that.

I will take a look at this when I get to that stage of the project, and will report.