Joel Bodenmann

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?

No worries, we'll do it then We mainly asked because this way author information can be incorporated into the git history which is something some contributors care about. I'll try to get this done this week but I need to setup a test case to reproduce the issue and testing your fix first.

This sounds good - thank you for having investigated this! If you are able/willing to provide a patch (such as git format-patch) we could apply your fix directly to the repository (and have you credited as the author). If possible, adding a comment or two in the source code wouldn't hurt either

Could you provide some more details? I had no problems compiling the code. Did you forget the inclusion of gwin/gwin_keyboard_layout.h or enabling the options in gfxconf.h? Please share your full build output.

Hello & Welcome to the µGFX community! µGFX accesses display hardware via the so-called "board file". Each display driver has a file named board_xxx_template.h where xxx is the driver name. In your case, that would be /drivers/gdisp/ILI9341/board_ILI9341_template.h. Simply copy that file to your project and rename it to board_ILI9341.h. In that file, you will find the various functions the driver needs to access on the hardware/peripherals to talk to the display controller - you'll have to implement those functions to work with your ecosystem (i.e. Arduino) and your hardware. So technically, that is where the pin assignments go. You can find an example under boards/addons/gdisp/board_ILI9341_spi.h While that is written to work with ChibiOS, it should still give you an idea of what you need to do (toggle GPIOs, make SPI transactions etc). As for the repository you linked - That seems to be 10 years old. I am not saying it won't work, but also from an understanding/learning perspective, it might be best if you start from scratch and import whatever you need. Please don't hesitate to ask if you have any questions - we're happy to help wherever we can.

Hello & Welcome to the µGFX community! This can be done by defining a custom keyboard layout and setting it via gwinKeyboardGetEventSource(). You can have a look at the built-in layout as a reference which you can find under src/gwin/gwin_keyboard_layout.c

Glad to hear that!

Hi! Have you tried just running the unmodified example found under /demos/modules/gwin/button ? With regards to calibration: You would typically only ever do that once (or if you build a full application, have some "settings" menu where the user can re-launch the calibration sequence). Once calibration was performed, you'd typically store the calibration data and load it on power-on. Have you had a look at the corresponding documentation? https://wiki.ugfx.io/index.php/Touchscreen_Calibration

Hello & Welcome to the µGFX community! Have you checked out the attached archive in @M3Michi 's last post?

Definitely on the ToDo list to check this out. Have to get the v2.10 release out first tho (pretty much done at this point).

Does that mean your patch changes font rendering (the actual painting) to use gdispGStreamStart(), gdispGStreamColor() and gdispGStreamStop()? And then on top of that giving gdispGStreamColor() an additional "count" parameter? Apologies if I'm way off here - totally buried at the moment.

We had a short internal discussion about this. We'll gladly have a look at your patch but we'll need a bit more time as we're quite busy at the moment. In general, we're quite keen on this additional/improvement if it is not restrictive to a particular type of driver.

Woah - that is awesome - good work! Is this the default dashboard for all BELAZ trucks or is this a retrofit that you're offering? If you like you can "showcase" your project in the "User Projects" section of this forum. That is always appreciated: https://community.ugfx.io/forum/6-user-projects/

You seem to have been patient with me.... thank you In your initial post you mentioned that the problem you're encountering happens when changing pages. Is this by any chance related to this?

Don't hesitate to ask if you have any other questions

Hello & welcome to the µGFX community! This is a common issue with graphics rendering not only specific to font rendering. Common solutions include: Render the entire element before pushing it to the framebuffer. In µGFX terms that would mean rendering into a pixmap and then blitting to the real display. Using global double buffering: You render to an off-screen buffer and once your rendering operation(s) are complete you swap the display's framebuffer. I'll need some time to get back to this as it has been a while since I was last digging in the internals of font rendering. One thing that comes to mind is that fillarea() tends to be a fast operation as this is an operation commonly supported by hardware acceleration. If you can propose a patch that handles the kerning issue I'd be more than happy to look into it.

Hello & Welcome to the µGFX community! The µGFX library can be integrated into an existing project through four different mechanisms: CMake Makefile Single-File-Include Manually adding all files the old fashioned way See https://wiki.ugfx.io/index.php/Getting_Started for more information STM32 CubeMX allows to generate projects using either Makefile or CMake - the latter being a very recent addition. I'd recommend that you get a basic project up and running without including µGFX to make sure that your environment & tooling are working as expected. Once you have a working project, you can include the µGFX library using any of the available mechanisms. In your case that will most likely be via Makefiles. Don't hesitate to ask if you have any questions. We're happy to help wherever we can.

Have a look at the command(s) passed to the compiler to verify that STM32LTDC_USE_DMA2D=GFXON is being passed as expected. This should definitely work (both based one existing customer projects as well as a quick test on our end).

Just had a quick look and the STM32LTDC_USE_DMA2D define/setting seems to work as intended. Firstly, make sure that you define STM32LTDC_USE_DMA2D as GFXON (i.e. not just defining it, but also assigning the value to it). Secondly, have you tried setting STM32LTDC_USE_DMA2D to GFXON in your build system (makefile, cmake, ...) instead of gfxconf.h?

Happy to hear that you have the STM32LTDC driver up and running The hardware accelerated area filling is handled by the DMA2D peripheral. From the µGFX side of things, the only thing you have to do is setting `STM32LTDC_USE_DMA2D` define to `GFXON`. More information regarding the STM32LTDC driver can be found in the corresponding driver readme: https://git.ugfx.io/uGFX/ugfx/src/branch/master/drivers/gdisp/STM32LTDC/readme.md Note: We strongly recommend that you use the latest master branch of the official µGFX v2.x git repository if you're using the LTDC driver. It has been reworked/improved substantially since the last official release.