Is there a good tool for generating STM32 Baremetal GUIs?

[JPortici]

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.

Yeah, that happens AFTER the screen render (which is either the software rendered, or accelerated by the GPU). Talking to the TFT controllers, that is the "shoving pixel out of the MCU" part, because almost all TFT controllers are pretty dumb in the end, or it doesn't make sense to render some parts in software and some in the controller, software would get too complicated too quickly. IIRC you can setup LVGL to only udpate the pixels that will change, instead of redrawing the entire buffer. I think there is also a mode in which you don't use the internal memory, but write the pixel as soon as it's calculated. Combine the two and you should have what the ramtex library does

[peter-h]

OK.

However any one pixel at a time drawing will be painfully slow, even at the max SPI clock of most LCDs (I can run at 21MHz but most displays can't). This is largely due to the address etc bytes.

Yes using SPI is really desirable otherwise the LCD eats up most of your GPIO

I think, ideally, one would transfer a rectangle using SPI, or some sequence of adjacent pixels.

[m98]

I found this tool from NXP:
https://www.nxp.com/design/software/development-software/gui-guider:GUI-GUIDER
Which looks a lot better than Squareline Studio for LVGL, as it includes all LVGL widgets and also supports Lottie animations. Only thing I haven't tried yet is exporting the code, but LVGL gui code is not hardware or RTOS specific, so it should work with non-NXP microcontrollers just fine.

[dietert1]

Recently i spent two days to work out font generation for a MSP3520 TFT display connected to a STM32L476 via SPI.
I printed the set of characters i wanted to use in Paintshop Pro with Verdana 24 in one line of text in black and white and saved the file. Then i used a small tool named "ImageConverter565.exe" supplied by a chinese trader of those displays. It converts the graphics into a C header file. Then i wrote my own tool to analyze that data block in order to convert the graphics from 16 bit color to 1 bit per pixel and find the horizontal locations of the characters. Also i added a constant C string that serves as index to pick the right character from the image. The result gets dumped into a new header file ready to include into the MCU project. Then there is a small procedure to print one character using kind of bitblt and procedures to print text using , and . separators as tabs.
I also wrote some procedures to draw rectangles. Need to enhance that for rounded rectangles. I mean it is pretty easy to arrive at some basic GUI elements.
Another problem i solved before is running the TFT controller and the touch controller on the same SPI bus. As far as i remember there was a problem with three-stating the ILI4988 output. And the touch controller uses its 3.3 V supply as voltage reference and there was a pretty weak LDO common to the display and the touch controller.

Regards, Dieter

[uer166]

FIY Gimp can output C headers natively. It's what I use for my graphics projects as direct drop-ins for bitmaps.

[SiliconWizard]

I use LCD Image Converter, which is a great tool. Very flexible, can generate all kinds of pixel formats (and customizable too), converts bitmaps as well as fonts.
https://lcd-image-converter.riuson.com

[Nominal Animal]

I use NetPBM formats for custom image processing almost every day.

The P1 (ASCII bitmap), P2 (ASCII grayscale), and P3 (ASCII rgb) formats are plain text, so in a pinch one can use those.
I prefer P4, P5, and P6 formats, where the header is plain text, but the pixel data is in binary.
The PF (using a 32-bit Binary32 float for each RGB component per pixel) can be useful for very-HDR stuff.

GIMP can load and save in these formats (.pbm, .pgm, .ppm, .pfm file extensions, respectively), and of course, the NetPBM tools themselves can convert these to GIF, PNG, JPEG, BMP, AutoCAD (database or slide), XPM, and a number of other formats.  The NetPBM tools include utilities like pnmcat, which can concatenate a number of NetPBM images into a single image, and pnmflip, that can mirror and transpose the images into other orientations.

From C, parsing the header correctly for the binary versions is slightly funny, and most people do it "wrong".  You're actually supposed to read the two first chars of the file, that tell the file format.  Then, you should use a function (like a getnni() I wrote a decade ago), that reads a non-negative integer, skipping leading whitespace and comments, for each of the header fields.  After the last header field, there will be exactly one ASCII whitespace char (\t, \n, \v, \f, \r, or space).  The binary data will follow.  For PGM and PPM formats, if the component maxval is between 255 and 65535, inclusive, the component uses two bytes; otherwise one byte only.  (The maxval can be any positive value up to 65535, and corresponds to 100% of that component.)
In Python, it is extremely simple to process in a similar manner, although again, most people do it "wrong", assuming the header is a fixed number of "lines".

For widgets, one can consider using 2D vector primitives, using an existing rasterizer or creating their own, and test it in practice on a fully-hosted system by creating canvases for the widgets (or the entire display), and saving the display images as PPM for viewing.  No need to futz with GUI toolkits, very quick to do in plain C; I can do it in Linux even in freestanding C (without the standard library, using only one inline assembly helper for write() syscalls to standard output for generating the image; it is arch-specific, though).

For widgets you use your own compression algorithms, say 16-color palettes (32/48 bytes of palette per widget or widget set, then two pixels per byte; doubling the palette size in RAM allows you extremely rapid RGB/YCbCr/YUV/whatever lookup).  The pnmquant isn't the best color quantizer (for picking the palette from a PNM image or multiple images pnmcat'd together), and I've intended to create a replacement that uses the relatively new OKLab color model for computing the color differences (ΔE) used for grouping, assuming RGB data uses the sRGB color space (as used on the web, for example).  The colormap format is just a PPM image with one pixel per color to be used, so trivial too.

One could even create a simple web page (no network connection needed, everything in a single HTML file) using JavaScript and Canvas to render fonts into a display buffer (see HTML Canvas DOM object), and generate per-glyph bitmap definitions in C for one to copy-paste to a text file, and even demonstrate how a sequence of the bitmap glyphs would look like.  Such HTML pages cannot really read or write local files; that's their only major limitation.

I cry for those who believe BMP is the easiest image format to manipulate from your own scripts/programs.

[wek]

> From C, parsing the header correctly for the binary versions is slightly funny,

As long as single-use single-purpose homebrew tools to convert bitmaps into whatever my target needs are concerned, I never could care enough to do it *properly*: it's simpler to learn how to coax the "big" drawing programs to output consistently files where the binary which matters is always at the same place and in the same format. Even if it means to use always the same size canvas, and crop it in my tool.

Some "big" programs can output bare binaries (which is IMO better than C sources/headers/whatever).

JW

[Nominal Animal]

Some "big" programs can output bare binaries (which is IMO better than C sources/headers/whatever).

That's exactly what P5 (PGM), P6 (PPM), and PF and Pf (PFM) format NetPBM files are, if you look at the file after the header.
Even Adobe Photoshop supports these, and that's as "big" as you can get for professional image editing.

In Augmented Backus–Naur format, I do believe the binary formats' headers (with binary data immediately following) can be correctly described as
    PBM = "P" "4" sep WIDTH sep HEIGHT wschar
    PGM = "P" "5" sep WIDTH sep HEIGHT sep MAXVAL wschar
    PPM = "P" "6" sep WIDTH sep HEIGHT sep MAXVAL wschar
    PFM = "P" "F" sep WIDTH sep HEIGHT sep RANGE LF
    PfM = "P" "f" sep WIDTH sep HEIGHT sep RANGE LF
    PFM4 = "P" "F" "4" sep WIDTH sep HEIGHT sep RANGE LF
    WIDTH = nonzero *digit ; ASCII positive decimal number
    HEIGHT = nonzero *digit ; ASCII positive decimal number
    MAXVAL = nonzero *digit ; ASCII positive decimal number between 1 and 65535, inclusive
    RANGE = 1*( "-" / "+" ) ( 1*digit / 1*digit "." *digit / *digit "." 1*digit )
    nonzero = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
    digit = "0" / nonzero
    wschar = HTAB / LF / VTAB / FF / CR / " "
    sep = 1*(1*wschar / comment)
    comment = "#" *(anything except CR or LF)
As you can see, it is easy to do it right by reading positive (nonzero) decimal numbers skipping the initial whitespace-and-comments (sep).

PBM files have one bit per pixel, 0=white, 1=black.  Rows are specified from top to bottom: top left pixel is the first, followed by the pixel to its right.  If WIDTH is not a multiple of 8, each row is padded to a multiple of 8, so each row consists of Ceil(WIDTH/8) bytes.  Each byte specifies eight pixels, with the most significant bit leftmost, and least significant bit rightmost.

PGM files have one (MAXVAL < 256) or two (MAXVAL >= 256) bytes per pixel.  Standard byte order is big-endian, but some do use little-endian.  A value of 0 corresponds to black, and MAXVAL corresponding to white.  Top left pixel is the first, followed by the pixel to its right.

PPM files have three (MAXVAL < 256) or six (MAXVAL >= 256) bytes per pixel.  This is like in PGM, except in triplets, first one corresponding to red, second to green, and third to blue.  0 is 0%, and MAXVAL is 100% of that component. Top left pixel is the first, followed by the pixel to its right.

PFM files consist of three IEEE 754 Binary32 floats per pixel, for red, green, and blue triplets.  If RANGE is negative, the byte order is little-endian, and 0% corresponds to 0.0f and 100% corresponds to -RANGE.  If RANGE is positive, the byte order is big-endian, and 0% corresponds to 0.0f and 100% to RANGE.  Bottom left pixel is the first, followed by the pixel to its right.

PfM files consist of one IEEE 754 Binary32 floats per pixel, corresponding to grayscale, 0 corresponding to black.  If RANGE is negative, the byte order is little-endian, and -RANGE corresponds to white.  If RANGE is positive, the byte order is big-endian, and RANGE corresponds to white.  Bottom left pixel is the first, followed by the pixel to its right.

PFM4 files consist of four IEEE 754 Binary32 floats per pixel, for red, green, blue, and alpha/opacity.  If RANGE is negative, the byte order is little-endian, and 0% corresponds to 0.0f and 100% corresponds to -RANGE.  If RANGE is positive, the byte order is big-endian, and 0% corresponds to 0.0f and 100% to RANGE.  Bottom left pixel is the first, followed by the pixel to its right.  This is not a widely supported format.

There is also a P7 aka PAM format, but it is not widely supported.

I tend to generate 8-bit PPM files using the sRGB colorspace, and they tend to open in all image editors from GIMP to Photoshop, but usually I use a chain of command-line tools to compress and optimize them into small PNG files (using a 16-256 color palette for minimal size).

For vector stuff, I use SVG (typically SVG 1.1).  It is ridiculously simple to generate, but not fun to rasterize.  You simply emit
    <?xml version="1.0" encoding="UTF-8" standalone="no"?>
    <svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 width height">
    <path d="path-data" fill="fill" stroke="stroke" stroke-width="thickness" />
    ...
    </svg>
where path-data consists of single-letter commands followed by numeric parameters (typically coordinates), width and height define the visible range of the maximum x and y coordinates, fill and stroke are either none or an RGB color (using hexadecimal notation, #RGB, #RRGGBB).  There are more options, of course, but this is usually sufficient for a lot of stuff.
The ... indicates other elements drawn on top.  Mostly I use paths, rects (to fill background; it defaults to transparent), and circle elements (for dots and such).

As long as single-use single-purpose homebrew tools to convert bitmaps into whatever my target needs are concerned, I never could care enough to do it *properly*

I have a header file somewhere that uses <stdlib.h> and <stdio.h> and defines accessor functions to load and save 32 bit canvases (R8:G8:B8, R8:G8:B8:A8 with a separate PGM alpha channel, or R10:G10:B10) where each pixel corresponds to an uint32_t, and the fast getpixel()/setpixel() have bounds checking.  I've also got fast 64-bit (for x86-64) RGB blending routines, although the quality of the result is nowhere near as nice if one used e.g. OKLab for the representation.

Point is, it is a perfect format to use in ELF-based toolchains to import pixmap data in customized formats.  You can use C, Python, or whatever your favourite language is on the host to convert the image format to whatever happens to be the optimal format for a specific use case on a microcontroller or embedded device.  No added library dependencies.  If you do decide to depend on the netpbm tools, you can then convert basically from and to any image format.  If your compression/optimization code on the host also emits the final versions as PPM, they can be converted to PNG losslessly and included in the generated documentation, for visual verification.