Joel Bodenmann

Thank you for bringing this to our attention. I've modified the documentation accordingly.

Thank you for sharing your progress & files with everybody - much appreciated! µGFX can definitely do a lot better than that. µGFX does provide those kind of features as well (in a much bigger scope even). We basically call those "hardware acceleration". There are a number of functions that a GDISP driver can implement to use hardware acceleration. For rectangles that would be the `fill area` function. You can have a look at existing drivers. As you'll see it's simply a matter of turning the hardware support for a feature on in the drivers configuration file and then implementing the corresponding function. Have a look at the ST7735 driver for an example. You can see that GDISP_HARDWARE_FILLS is enabled in the drivers config file (gdisp_lld_conf.h) and that the drivers implementation file (gdisp_lld_ST7735.c) is implementing the corresponding hardware filling function named gdisp_lld_fill_area(). The actual implementation of such a function varies a lot. Some display controller have a simple command which takes X, Y, width, height and color while other drivers rely on using DMA and similar techniques to speed things up.

@David Thomas is correct. You're missing some board support package files. You will find that µGFX also supplies those as part of the board files for the STM32F746 Discovery board files. You can find them under /boards/base/STM32F746-Discovery. Just add the appropriate files that you're missing (most notably the SDRAM ones) and you should be ready to go After all, board files are completely application specific. You're not forced to use what you find in the /boards directory. If you're using another framework you can either use their board files (if they exist already) or create your own. Board files are just there to give the µGFX driver(s) access to the actual hardware. You'll find a board file template in each driver directory (eg. /drivers/gdisp/STM32LTDC in your case) which you can implement however you want using whatever you want.

Hello @cchilumbu and welcome to the µGFX community! This topic is very old and there has been a lot of improvements in all corners of µGFX. Please make sure that you're using the latest master branch from the official git repository. If you keep having problems, please don't hesitate to open a dedicated forum topic to ask your questions. We're happy to help wherever we can

You will definitely get a lot better performance when using FSMC. We strongly recommend that you do so. It's quite "common" that the FSMC can go faster than the slave (the display controller in this case). For this, the FSMC has plenty of timing registers to make sure that everything stays within the interface specs you can review in the display controller's datasheet.

Thank you for bringing this to our attention!

That what's the board field in the GDisplay struct is there for. See https://wiki.ugfx.io/index.php/Multiple_displays#Board_files So what you propose to do is fine, just use the existing g->board integer.

Did you perform a clean compilation? This should definitely work. There's not much that can go wrong.

Yes that's possible. The existing keyboard widget (virtual on-screen keyboard) has an interface that allows to load custom layouts. You can add whatever keys you want in whatever layout you want. Furthermore, you can use custom rendering functions to make it look the way you want - all without touching any of the logic!

Word wrapping is supported: https://wiki.ugfx.io/index.php/Font_rendering#Word-Wrapping The existing rendering functions for the label widget take a justification value as the param and use word wrapping internally if it's enabled in the configuration file.

Uhm... what exactly is the problem/issue you're experiencing?

Hello & Welcome to the µGFX community! You should use the private area of the GDisplay structure instead (g->priv) for these sorts of things. g->board is used to identify the board if using multiple displays at once. You need to write an intermediate wrapper. You need to call pure C functions from the driver file (which is C code). Those "pure C functions" can be implemented using C++ however. I'd recommend you to have a look at /drivers/gdisp/QImage to get an idea. We did the same there to interface Qt's QImage class in C++. We're very happy if you'd like to participate and update existing or create new documentation. An Arduino specific page would be very welcomed. I hope this helps.

Just to clarify: The driver file (eg. gdisp_lld_ILI3820.c) will only call functions like write_data() and write_cmd(). However, the implementation of those functions need to be in the board file (eg. board_ILI3820.h). In the implementation of those functions in the board file you'll access your microcontroller's peripherals to talk to the display controller. Never access pins or SPI stuff directly from the driver file!

Hello and welcome to the µGFX community! Is it possible that you forgot to assign the font on the GWIN level? You can either use gwinSetDefaultFont() to set a default font for all widgets or you can set a per-widget specific font with gwinSetFont().

Happy yo Help & Very glad to hear that :)

Regarding 1: Keep in mind that µGFX can still optionally run off one or more buffers. We have a lot of applications that use either hardware level double buffering or application level double buffering. We also have a lot of applications that use our dynamic arbitrary sized framebuffers called pixmaps.

I think you might want to give GWIN_FLAT_STYLING a try (set it to FALSE or GFXOFF). Other than that you can always just create a custom rendering routine in your application instead of modifying library code: https://wiki.ugfx.io/index.php/Creating_a_custom_rendering_routine

We're happy to answer any specific question you have but please give the documentation a shot first.

You should also set GFX_COMPILER to GFX_COMPILER_KEIL if you're using Keil.

What you did is correct. But now you need to debug: Step through your application and see whether it hangs or crashes somewhere Make sure that your board file is implemented properly. Use a logic analyzer / osmelloscope to verify that the signals are correct The ILIxxxx drivers are known to be very difficult to handle in terms of different revisions and so on. Some of the chips are even labeled wrong. Check out the initialization sequence in the driver file (/drivers/gdisp/ILI9341/gdisp_lld_ILI9341.c) and compare it to the one that your manufacturer/supplier supplied with the module you bought.

Did you try to debug the application? Most likely it's hanging or crashing somewhere during initialization.

Well did you check the configuration file reference? --> https://wiki.ugfx.io/index.php/Configuration Of course, each setting is also documented in-source code which makes it available in the API documentation: https://api.ugfx.io

Hello and welcome to the µGFX community! Did you check out the Eclipse guide in the wiki (and/or the guides for the various eclipse based IDEs)? P.S. Next time please use code boxes in your post (I've added them).

Yes, it is. Make sure that you use the latest master branch of the official repository to get all of the latest goodies.

Did you ensure that your _mouseDown() function is registered in the VMT? Can you try to put the statusbar in the middle of the display to ensure that it's not some edge-touching issue.