Joel Bodenmann

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.

Hello and welcome to the community! Please read the following threads for more information: https://community.ugfx.org/topic/316-ugfx-amp-chibios-stm32f746g-discovery https://community.ugfx.org/topic/311-newbie-trying-discof746-demo https://community.ugfx.org/topic/289-ugfx-ltdc-and-chibios The short version is that last time we checked (which is about half a year ago) there was compatibility issue with the ST headers used by ChibiOS/RT and our demo. Either of the two used the incorrect / outdated headers. The linked threads explain what steps are required to resolve this issue.

This looks awesome, great work! I haven't had time to look at the code yet but the video looks very promising We will review the code (which might sadly take up to two weeks) and eventually add it to the repository. In the meantime I will create a blog post to inform people. Great work, keep it up!

The GMISC module provides array/matrix operations including translation, rotation and scaling. These operations can be applied on polygon items. Hence you can draw a needle using a polygon and rotate that using the GMISC functionalities. In fact, there is a demo that shows this: /demos/modules/gdisp/polygons Let us know if you need any further help / explanations. We are happy to help wherever we can. The µGFX-Studio currently doesn't allows adding custom widgets. However, that feature is now at the very top of the ToDo list. Either the next or the over-next version of the µGFX-Studio will definitely include this feature. The next four weeks we won't have any time left to work on the Studio, however, after that we will put some serious time into it.

Note that you can use a different Cygwin / MinGW version that runs on your system. All you have to do is setting up a corresponding build configuration under Preferences -> Build.

Hello bluexp and welcome to the community! I'm sorry but we don't provide any support for Windows XP. We recommend that you simply use the µGFX-Studio on a different machine or that you run it in a VM.

We will investigate - this shouldn't happen. The GAUDIO module is supposed to automatically enable the GTIMER module and just showing a compilation warning. The file /src/gfile/gfile_fatfs_diskio_chibios.c implements a default disk interface that works with most ChibiOS/RT setups. You might need to modify it to your needs in case of you are using other card interfaces. You will still have to enable all the required stuff in ChibiOS/RT itself (halconf.h and mcuconf.h files). µGFX can't enable the MMC or SDIO interfaces and other required stuff for you in the ChibiOS/RT files. We strongly recommend getting your SD-Card up and running in a bare ChibiOS/RT project before you slap µGFX on top of it. That's way easier to debug. As soon as your SD-Card is working with ChibiOS/RT itself it will most likely just work out of the box with the GFILE module of µGFX. I hope that helps

Using flags for a partial redraw is indeed the recommended / intended way to go. You'd set a flag that either indicates that only a partial or a full redraw is required in the functions that modify the string content. In the rendering routine you'll simply read that flag and draw the stuff that needs to be drawn accordingly. I hope that helps. Please don't hesitate to ask if you have any further questions. We are happy to help where we can.

This is strange. The rules set of the GAUDIO module should automatically turn GFX_USE_GTIMER on if you enable the GAUDIO module: #if GFX_USE_GAUDIO #if GFX_USE_GEVENT && !GFX_USE_GTIMER #if GFX_DISPLAY_RULE_WARNINGS #warning "GAUDIO: GFX_USE_GTIMER is required if GFX_USE_GAUDIO and GFX_USE_GEVENT are TRUE. It has been turned on for you." #endif #undef GFX_USE_GTIMER #define GFX_USE_GTIMER TRUE #endif #endif Is there any way you can reproduce this problem?

Wow, those look great! Nice work! Would it be possible for you to share the actual widget source? We'd love to add this spinbox widget to the official repository! From the video it seems like you are always redrawing the entire string. As an optimization it would be possible to just redraw the value string without the unit string.

Hello and welcome to the community! Thank you for bringing this to our attention. We will have a look at this and fix what needs to be fixed. However, this might take a couple of days. Please excuse the inconvenience.

Thank you for sharing your port! We will have a look at it and integrate it in the repository. During the next couple of days/weeks.