Joel Bodenmann

Hello Alex and welcome to the community! FatFS requires you to implement the disk interface. That is a set of functions known to FatFS that it will use to communicate with the actual memory device. FatFS comes with the corresponding template files named diskio.h and diskio.c. You have to copy these files to your project and implement them accordingly to your system. µGFX itself only comes with built-in diskio implementations for ChibiOS/RT.

mbed os is currently not official supported. You have to write a GOS port in order to use µGFX with it. It's actually quite straight forward and not as complicated as it might look on first glance. The forum contains many information about this. Furthermore, there are plenty of porting examples available in the /src/gos directory. Please don't hesitate to open a new forum topic if you have any questions regarding writing an mbed OS port.

Ah yes, that might very well be the problem. It appears that the code generated by the µGFX-Studio is lacking the wrappers for C++ inclusion. The fix is easy though: Open the file gui.h and wrap the function declarations in the corresponding wrapper: #ifdef __cplusplus extern "C" { #endif // Function prototypes ... #ifdef __cplusplus } #endif Don't forget to make a clean build afterwards.

Did you forget to include the gui.h file in main.c? #include "gui.h"

Those functions are part of the files gui.h and gui.c that are generated by the µGFX-Studio. It appears that the compiler/linker is not seeing these files. Please make sure that these files are part of the compilation & linking process. For the source file this means that you have to add it to the project tree in the navigation on the left side of Keil µVision. The folder that contains the header file must be added to the compiler include path.

Please don't hesitate to ask if you have any questions

Hello and welcome to the community, This issue has been reported before but unfortunately we didn't have time to investigate ourselves yet and the person that asked the question didn't bother trying to figure out what the problem is. For now, the easy solution is to call the board initialization function twice in the driver.: We'd appreciate it if you can have a look at this trying to figure out what the problem might be.

Hello @Oguzhan and welcome to the community! Keil µVision is known to work very well with µGFX. We are using it ourselves to develop certain features and projects from time to time. There's a complete step by step guide that explains how you can integrate the µGFX library into an existing Keil µVision project: https://wiki.ugfx.io/index.php/Using_Keil_µVision_5_MDK-ARM You can use the µGFX-Studio to develop your GUI and compile it with Keil µVision. The code generated by the studio is fully portable. You can simply copy/paste the files generated by the studio to your Keil project. In fact, you can automate the process by using post-generation scripts as explained here: You might also be interested in this post of our community member @king2 which explains how he's working with the µGFX-Studio in a real-world project:

Hello Andrey, I'm glad to hear that you successfully managed to write a driver for the SSD1322 display controller - great work! The reason for this is because the string is vertically centered in the box that you define with the first four parameters. In your code, you set the height of the second box to 60 instead of 30. If the height of the box is 60, the text will be drawn in a fashion that it's vertically centered and that is what you are experiencing. To fix the problem, simply use a height of 30 for the second string box as well: gdispDrawStringBox(0, 0, 250, 30, str, font2, 0x02, justifyLeft); gdispDrawStringBox(0, 30, 250, 30, str, font2, 0x02, justifyLeft); That should definitely fix your problem Basically you want the same box/rectangle for both texts, it's just that one is 30 pixels below the other one. If you clear/refresh the display the old content will be gone. The all the GDISP drawing functions directly modify the content of the framebuffer when you call them, they don't retain any state. Hence, if you clear/refresh the display the content that you wrote previously to the framebuffer will be gone. To have persistent items on the display you need a window manager. That is actually what the GWIN module provides. Theoretically you could simply use the label widget instead and the window manager will take care of redrawing the text when it needs to be redrawn. However, with your display that is way overkill. It's better if you simply write your own update() or refresh() function that redraws the stuff that needs to be redrawn. These parameters change the meaning depending on the function that receives them. Those are only used internally by the GDISP module - you must not touch them at any time. I'm sorry in case of I misunderstood any of your questions. Please feel free to complain if your questions didn't get answered properly

Pixmaps currently don't support alpha blending. However, a friend of mine implemented that feature just a few days ago. It's an actual extension for the existing pixmap. I'll ask him whether he could share his work - stay tuned.

Hello @csteaderman, gdispImageCache() will already improve the drawing speed for the very first draw. One of the nice things of gdispImageCache() is that your image will still be drawn, even if caching it failed (due to lack of memory). However, you will always be aware of this as the return value of gdispImageCache() gives you information of whether the caching was successful.

Please attach the complete compiler output log as a text file to your next forum post. Make sure that it is a clean build. I am having hard times believing that you are able to compile successfully:

Hello, That configuration file looks fine. However, I am really surprised.... are you able to compile that with Keil µVision? Because if you set GFX_CPU_CORTEX_M7_FPU it enables the architecture specific assembly code that we wrote for the baremetal port. That code is known to compile well with GCC but not with ARMCC (which is the compiler that Keil µVision uses by default). Are you 100% sure that you can compile with that configuration without any errors?

Note that having a powerful processor doesn't mean that you can use the available resources for the GUI. There are more than plenty systems out there that run µGFX on very powerful & capable hardware that benefit from the fact that µGFX uses only a very small part of those resources so the rest is available to the actual job done (the stuff other than the GUI). We are working on that. That's why @inmarket wrote that new gdispGFillDualCircle() in first place.

Judging from your screenshot you are using Keil µVision, is that correct? Given the information from your previous forum topics I assume that you have been using an RTOS before and are now switching to a baremetal solution. In that case, please double check to ensure that there is no operating system running in the background. With Keil µVision it is quite easy to have software components enabled that get initialized automatically due to the package manager. After that... Did you specify the CPU in the configuration file? As forum search will tell you the ARMCC compiler will complain about the syntax of the assembly code that gets enabled when specify any of the Cortex-M architectures. Therefore, I assume that you are using GFX_CPU_UNKNOWN - is that correct? There's a known issue with the implementation of setjmp() and longjmp() of the libc that comes with ARMCC. As far as I remember that issue never got resolved as it's really a bug in the upstream. @inmarket might have more information on this. To actually debug this: Please check whether the scheduler is up and running. You can easily do this by creating multiple thread and making sure that all of them are working. You might want to run the demo you can find in /demos/modules/gos/thread. In general: We can't really help based on "It doesn't show anything". More background information is always required. If you are encountering compilation errors and similar you can always attach the compiler output log as a text file to your forum post.

Hello Dave, If you're using the GWIN module you're already using the GTIMER module as well. Both the GWIN and the GINPUT module have the GTIMER module as dependencies. This means that you can use a GTIMER in your spinner without pulling additional dependencies in. A GTIMER uses a lot less resources than a thread, both in terms of memory and CPU power. Also, you might want to consider taking your spinner and creating a custom widget out of it. The process is very easy, especially in this case as the spinner doesn't take any user input and doesn't fire any events. It's what we call a window, not a widget (that's explained in the corresponding documentation). Having a dedicated widget (window!) for this would mean that the window manager can control the visibility, that it can become a child of a parent container and that you can have multiple instances of it. Furthermore, it would be easy to apply styles, move it around and stuff like that. Creating a custom widget is explained here.

Hello Dave, Thank you very much for sharing your code. Things like that are always appreciated. I'm sure that this will help somebody in the future. I haven't taken a look at your code yet but judging from your description you are using an actual thread for the spinner. Have you considered using a GTimer instead? I've moved this topic to the User Projects section of this forum.

Just fixed that: https://git.ugfx.io/uGFX/uGFX/commit/c91f42ec85a2c2f127663c0b0a9f11f11a6660b8

It's TIME_INFINITE

You have to set GFX_USE_OS_RAW32 to TRUE in your configuration file to enable the BareMetal (no operating system) port. You can have a look at this example which is a bare metal project for the STM32F746G-Discovery board:

Hi, We certainly can't help you without you providing your algorithm. If it's a small issue we might be able to help you or to give you certain pointers. Developing a dedicated algorithm for this is definitely the right approach as assembling the ring from other existing primitives will result in issues as you mentioned. Depending on your application / use-case you might be able to use the new gdispDrawDualCircle() function that was added 17 hours ago:

Hello Sébastien, If you can share a stripped down version of the project that runs as an x86 project so we can run it on Windows that would be great. Other than that, if you want to dive into it yourself you can simply put a breakpoint at the redrawing function and look at the backtrace to figure out what causes the 2nd redraw.

Hello Sébastien and welcome to the community! First to of all, let me thank you for your very nice post. If everybody would post their questions like this, life would be a whole lot easier for us. The background information you give along the minimized examples are really helpful. I'm on the road right now so I can't run your example - this might have to wait until tomorrow. I also don't know anything on top of my head that might help you - we're going to have a look at this and report back ASAP. Would it be possible for you to attach your simplified code as a ready-to-run projects as a ZIP archive? This would further simplify the process of tracking down & fixing the issue for us. The current version of the uGFX-Studio is pretty much dead. We're not putting any more time into it unless a company requests bug fixes or new features as part of a paid support plan. We started working on a completely new version of the uGFX-Studio which will be a lot better in almost all aspects. You can have a look at that here: Whether or not that tool will be open-sourced has not been decided yet.

Hi, The configuration file is completely independent from whether you use your ILI9341 display controller in 8-bit or in 16-bit mode. It is up to the board file to handle the 8-bit mode correctly.

Hi, There is a GOS port called Raw32 which allows running µGFX on any 32-bit architecture. You can find more about it in the corresponding documentation: https://wiki.ugfx.io/index.php/BareMetal You might want to consider setting the GFX_CPU_XXX macro in case of you're using an explicitly supported CPU to benefit from further, platform specific optimizations.