Joel Bodenmann

µGFX v2.9 is not the last release. In fact, the v2.10 release is well overdue. We tend to put it off because most users & customers are just using the git `master` branch which we always keep in a working state. But yeah, we should definitely just pump out v2.10. As for the µGFX studio: After the beta, we concluded that it was not good enough as it was missing a few features we deemed "must have" back then. In retrospect, that was probably a mistake and we should have just released it and improve it along the road. Live and learn. As for µGFX v3.0: We have a working version of it. The only thing that's truly missing is blitting support which we deem essential in order to replace v2.x. The issue is ultimately that we're constantly busy with projects that consume µGFX v2.x. Furthermore, the embedded landscape changed drastically over the past couple of years. Nowdays it's almost normal to have an MCU that runs at well over 100 MHz with memory in the megabytes. As such, the very low resource consumption which is one of µGFX's USPs is no longer needed for "regular everyday projects". µGFX is still being used, but these days it's usually in applications that most people are not exposed to such as mission & safety critical systems. As such, the publicly visible µGFX activities dropped down sharply. We fully stand behind µGFX and support it where needed and we use it ourselves, but the last couple of years the landscape changed in a way that it's not necessarily of interest to most developers anymore. These days, especially hobbyists will find themselves working with embedded systems providing resources orders of magnitudes higher than what µGFX requires which allows for vibe-coding pretty much anything without ever having to worry about speed, latency or memory constrains. Personally, I am currently developing an IP core to provide 2D hardware acceleration for FPGAs and ASICs which will ship with tight µGFX integration. I am hoping to implement a full 2D GPU eventually with shader support etc. Bottom line is: If you like µGFX and it works for your use-case, don't be discouraged to continue using it. We're here to stay.

Sorry, I ended up not replying once I read that you got everything resolved. Don't hesitate to ask if you have any other questions!

Fixed - Thank you!

Hello & Welcome to the µGFX community! The µGFX library is completely platform agnostic. You should be able to get it to work on AM64x baremetal without any issues. Here's the corresponding documentation for a baremetal target: https://wiki.ugfx.io/index.php/BareMetal

Hello & Welcome to the µGFX community! Should be fixed now - Thank you for bringing this to our attention.

Hello & Welcome to the µGFX community! It's pretty much impossible for us to help without more information such as how you integrated the µGFX library and actual build error messages.

If you only work with an 18x18 image, PNG is the wrong format to choose. For such as small image, you're better of using something like BMP or even the NATIVE format. PNG does have a minimum overhead of 34k. See the "RAM usage" section in the documentation: https://wiki.ugfx.io/index.php/Images#PNG

Hi, Can you please provide more details? What do you consider to be defective?

Using the Makefile approach is very simple as the Makefile that ships with µGFX exposes variables for sources, include paths and libraries to link. See the corresponding documentation. Does your existing CubeIDE project already use Makefile? If so, follow the makefile documentation linked above. There's also an example for ChibiOS (not specific to CubeIDE but it shows how simple it is to add µGFX to an existing Makefile project). If your existing CubeIDE project uses CMake instead, the current master branch of the official µGFX repository (i.e. µGFX v2.10) supports CMake too. If you need more hands-on support, we can provide commercial support.

Awesome - Thanks! This has now been merged into the master branch: https://git.ugfx.io/uGFX/ugfx/commit/02cbcea9e5b882f35b33f079340925a511b78acb Will do a v2.10 release this week.

µGFX supports file formats like BMP, GIF and PNG out of the box. You can directly load the encoded image. No need to use an image converter. You can use the NATIVE format but then you'll indeed have to do the conversion yourself. The easiest way to get an image is to include it in your firmware image. This can be done with the file2c utility that ships with the µGFX library. You can then use ROMF to display it. Have a look at the /demos/modules/gdisp/images demo to get started. Also, here's more documentation: https://wiki.ugfx.io/index.php/Images For the future, please make a separate forum topic/thread. This makes it much easier for other people to find answers to similar questions in the future

Great that you got the new driver working so quickly - nice work! Does everything work properly then? The font looks a bit funky but maybe that's just the font. You can always test with the built-in DejaVu fonts first to confirm that it's working as intended.

So, generally the good news is that once you see something on the screen (anything, even if it's distorted), you're generally in good shape. It's usually harder to get to the point where you're no longer staring at a black screen. First of all, I would recommend that you use the current `master` branch of the official µGFX v2 git repository: https://git.ugfx.io/ugfx/ugfx One of the notable changes after the v2.9 release was a rework of the STM32 LTDC driver. You can (and should) read more about the changes here: I think it's wasted effort to debug the issue you're currently having with the old driver. I'd suggest that you get it up and running with the new driver and then we figure out what isn't working for you. Don't hesitate to ask if you have any questions. We're happy to help wherever we can.

Hello & Welcome to the µGFX community! Could you please tell us which version of the µGFX library you're using (eg. v2.9 release or the git master branch, ...) and whether you're using a development kit (such as STM32 discovery or similar) or whether you're using custom hardware?

@Sergey Kushnir I've applied your patch to the feature/gwin_redraw_fix branch (https://git.ugfx.io/uGFX/ugfx/src/branch/feature/gwin_redraw_fix) Would you be able to verify that everything is working as expected before we merge it into the master branch and make a v2.10 release?