Joel Bodenmann

The reason that there is no documentation about the framebuffer format is because there is no framebuffer in µGFX. One of the strong suits of µGFX compared to similar libraries is that it can work without a framebuffer. I assume that as you are talking about the RAM() macro you are taking the existing ST7565 driver as a template? Upon closer inspection you will see that the framebuffer is entirely handled inside of that driver. µGFX itself doesn't know about it at all. The first line in the gdisp_lld_init() function allocates a framebuffer. Note again that the framebuffer pointer is stored in the driver's private area. There is no call that submits/registers the framebuffer to µGFX itself. All that µGFX will do is calling the gdisp_lld_draw_pixel() function. In that function, the driver stores the pixel information in the framebuffer that he himself is managing. Therefore, it can use any kind of format. All you have to do is storing the pixel information in a way inside the gdisp_lld_draw_pixel() function (and similar) that you can retrieve them once it's time to send that information to the display controller. Note: I haven't checked the datasheet of the ST7586 display controller. However, note that may display controllers provide a frame buffer themselves. In that case, you might want to use a different display driver model. More information can be found here: http://wiki.ugfx.org/index.php/Display_Driver_Model I hope that helps. Please don't hesitate to ask if there's anything unclear

Well, that shouldn't happen... Are you sure that the font is opened correctly? Can you manually draw a text using gdispGDrawString() using that font? Can you supply us with a minimal test case example that allows us reproducing the problem?

Caling gwinSetFont() won't issue a redraw of the widget. You will have to manually issue a redraw using gwinRedraw().

That will be a lot of #ifdefs. But I guess as almost all of them are located inside the specific Windows port we might give it a go...

The file(s) is/are located at /ugfx/boards\base/STM32F746-Discovery/ and are included in the board.mk file that can be found in the same directory. In the main Makefile which is part of the project directory that you downloaded, that board.mk file is included by this line: GFXBOARD = STM32F746-Discovery That GFXBOARD variable is extended in the background to the path stated above. All that makefile magic happens in the /tools/gmake_scripts/compiler_gcc.mk Makefile. Simply remove the main.c file from the SRC variable in the main Makefile (the one in the project directory) and use the GFXDEMO variable (eg. GFXDEMO = modules/gwin/frame). It might be possible that you have to remove/rename the gfxconf.h file in the project directory to avoid file inclusion collision. Please feel free to create a new forum topic for this I hope that helps.

That question can't really be answered. It depends on so many different things: The underlying system that you're using Whenever possible uGFX uses infrastructures from the underlying system Which features you are using (configuration file!) Each module can be enabled/disabled individually Each module has sub-features that can be enabled/disabled individually Each of those configurations pulls a different set of dependencies Images Each image format comes with different memory requirements Fonts You can enable and disable sub-features like kerning, anti-aliasing and unicode. Each of those has an impact on the binary size. Fonts are usually stored in the linked binary. Therefore each font will have an impact on the binary size. Fonts can be filtered, this way unused characters don't end up consuming any memory Styles & Renderings Each widget style and custom rendering routine will have an individual impact on the binary size ... The list could go on and on - The point is that it not only depends on the platform you're working with but also which features you have enabled, what kind of resources you're using and so on. In general you definitely want to disable anything in the configuration file that is not explicitly needed/used. Never the less it's worth while to note that µGFX has been designed to be as small as possible. This is also one of the reasons why the source of µGFX is completely open: Many other competitive products only provide pre-compiled libraries. This is not only a pain in the butt but also means that unused features become part of the linked binary. When you don't enable something in the µGFX configuration file, the linker will never ever see the code as it gets removed by the pre-processor even before compilation. You're not We're happy to answer any question we can.

I guess this has to wait a couple of weeks then, sorry! In the meantime we at least updated the STM32F7-Discovery board files to be compatible with the latest STM32CubeF7 HAL (or what ever the right terminology is...). We will definitely take a look at it. It's on the short-term ToDo list.

Hello Ettore and welcome to the community! Sorry for the late reply. We appreciate this a lot. It's nice that you list everything in such a level of detail, nice work! As you mentioned, these changes are very Visual Studio specific. Sadly we don't see a way (yet) to integrate them in an easy way without breaking support for other compilers or introducing a very ugly #ifdef mess. For the time being, we added a note to the documentation that points to this forum topic: http://wiki.ugfx.org/index.php/Win32 Keep up the good work!

µGFX already has a virtual on-screen keyboard widget that is known to work very well. It's highly customizable as it supports custom layouts (eg. you can arrange the buttons however you like). API-Reference: http://api.ugfx.org/group___virtual_keyboard.html Demo 1: /demos/modules/gwin/keyboard Demo 2: /demos/modules/gwin/textedit_virtual_keyboard

We updated the HAL files that the STM32F746G-Discovery board files are using. Everything is now compatible to the latest version of the STM32F7CubeHAL and CMSIS that is available from the ST website itself. If you are still not able to use the new board files with ChibiOS/RT then it's very likely that ChibiOS/RT is using an older version of the ST files. Check the file headers for versioning information. We uploaded a complete, running out-of-the-box minimal project using RAW32 and makefile. I'm afraid we won't have time to create a similar example for ChibiOS/RT in the following weeks. In case of you're going to try that example, please don't forget to rate it if it's working the way it should

What do you mean? ST provides at least a dozen different examples ready-to-run for the STM32F429i-Discovery board. You can run µGFX on it the same way you are doing with the STM32F746G-Discovery board The reason to do this is to check whether it's an issue in the µGFX STM32LTDC driver itself because both platforms would use the same driver.

Can you confirm that the issue is the same on an STM32F429i-Discovery board? We will have a look at the STM32LTDC driver. There has already been an issue in the past where the LTDC wasn't configured with the proper values which resulted in shimmering effects: https://community.ugfx.org/topic/152-improvement-stm32f429i-discovery-display-shimmering/ Sadly this will have to wait for a couple of weeks. If you want to investigate: Compare the configuration values of the µGFX LTDC driver & board file(s) to the one used in the ST demos.

@inmarket he's not using the LTDC driver for his F4 as he's using an SSD1289 display module/controller. However, what was said still applies: This is most likely a display panel property. The display panels you get with the discovery boards are generally of a very poor quality. The ones form the large eval boards are a lot better. As mentioned, ST takes a lot of care to use images and colors in their examples that hide these "problems". Also note that the SSD1289 display module that you're using has most likely a higher pixel density than the display on the STM32F7 Discovery. Higher display density will increase the "smoothness" of what is being displayed.

Hello Josh and welcome to the community! We can confirm that µGFX currently doesn't provide any cursor support. However, that feature is planned for µGFX 3.0 which we started working on a couple of weeks ago. So right now you have to implement it yourself.

@inmarket is correct. The code in the HAL "includes" the APBPrescTable by using the extern keyword. Hence it just must be somewhere in a file that is available at link time. In all of ST's examples the table is declared in the system_stm32f7xx.c file which is supposed to be part of your project. As a general rule: Do never every modify something like the HAL files that are provided by ST. Those libraries have been designed to integrate with your own code in a certain way. It's your responsibility to make sure that you make sure that your code honors these integration interfaces. Documentation and examples will tell you what's required to use the library. As soon as you start modifying other people's library code you open Pandora's box. You'll run into many issues (short-, mid- and long-term) that might not even be obvious at the beginning. Modifying library code is a big no-no unless you know what you're doing and the code finds it's way into the upstream. Just take one of the simple examples from ST, verify that it works and then add µGFX to that. It seems that the HAL change too much to just hot-fix the required modifications.

This might be an issue with the inclusion order. µGFX only defines TRUE and FALSE if they haven't been defined so far. Snipped from gfx.h: /** * @brief Generic 'false' boolean constant. */ #if !defined(FALSE) || defined(__DOXYGEN__) #define FALSE 0 #endif /** * @brief Generic 'true' boolean constant. */ #if !defined(TRUE) || defined(__DOXYGEN__) #define TRUE -1 #endif You might/should include the "base system" before the uGFX stuff in your build tree. Issues like this won't happen in the future anymore. µGFX 3.0 will use prefixes for all types and definitions to avoid collisions like this.

These are not bugs. It's simply a matter of incompatibility between different HAL versions. But yes, I agree. It's a bit pain in the butt that they change their HAL stuff after releasing a product. Please note that the errors you are getting are not µGFX related. Looking at the latest STM32F7CubeHAL and judging from your screenshot I assume that you forgot to include system_stm32f7xx.c somewhere because that is where they define their APBPrescTable in all of the examples that come with the STM32F7CubeHAL package.

A friend of mine just showed me this link - Just in case of somebody would like to go and extend the existing µGFX driver. Update: The FT6x06 driver has been included in the official µGFX library:

We added the driver to the repository. Can you please give it a try and let us know whether there are any problems? While reviewing your code we came across this: #include "../ugfx_2.5/src/ginput/ginput_driver_mouse.h" What's the matter with that? The line should be this instead: #include "../../../../src/ginput/ginput_driver_mouse.h"

Our community member @Fleck tried this fix yesterday on his brand new STM32F7-Discovery and he can confirm that the fix that @inmarket pushed to the repository works well.

Our community member @Fleck tried this fix yesterday on his brand new STM32F7-Discovery and he can confirm that the fix that @inmarket pushed to the repository works well.

To clarify what @inmarket said: The solution in the current version of uGFX is to create a custom widget. More information can be found here: http://wiki.ugfx.org/index.php/Creating_a_widget As it's basically 1:1 the existing pushbutton widget you simply copy the pushbutton widget files (/src/gwin/gwin_button.[ch]) to your project and modify it as per inmarket's explanation.

We're going to add this driver to the repository in the next few days. Is there any update or is the driver attached to your post still the latest greatest?

Just as a follow-up: If you're not obligated to use ChibiOS/RT you can either use µGFX baremetal (without any operating system) or another operating system such as FreeRTOS, Keil RTX or many others. The issue here is really just that ChibiOS comes with its own HAL. You can find a demo project using the STM32F7 discovery with Keil RTX in the download section.