Joel Bodenmann

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.

Hello Jagdish, I'm having troubles finding the link that you're talking about. Can you tell me exactly where I can find that dead "Demos" link?

Excellent work! That pull request has just been merged into the official repository. @Aivars Plume Can you confirm that this fixes the issue that you have been reporting?

Hello @Jagdish Bisawa and welcome to the community! Thank you very much for bringing this to our attention. We took a look at it and fixed several links. Please don't hesitate to let us know if you can find other remaining dead links.

Hello Alex, Thank you very much for sharing your experience. The proper way of handling this is creating separate board files for ChibiOS 2.x and ChibiOS 3.x. If you can share your working board files with us we'd be happy to include them as part of the repository. I hope that your students will enjoy working with µGFX

It would be nice if you could share your finished rendering function. I'm sure that that could be helpful for many people. Maybe it can even be included in the official µGFX library. That might be the case on your computer using the SDL back-end. Running this on real hardware (eg. a Cortex-M4) based system will yield way worse results. The type of interface used between the CPU and the actual display will also have a huge impact.

The gwinXxxCreate() function doesn't exist in that literal form. The "Xxx" are place holders for the name of the widget. You will find functions like gwinButtonCreate(), gwinSliderCreate() and similar. The term gwinXxxCreate() refers to all of these.

Hello Folks, The past couple of weeks we have been busy working on a new website. This time we have been working together with a talented photographer & designer. The result are many great images which give the new website a very polished & professional look. The new website can be found at the usual place: http://ugfx.io The old website will stay available for a few weeks: http://old.ugfx.io Please leave all your comments, feedback, criticism and ideas below. We'd love to hear your opinion!

Hello and welcome to the community! When you say that you can't show them at the same time, what do you have to do to make the others visible? Can you please check that the gwinXxxCreate() functions return valid handles? If the create functions return null pointers that usually indicates that you don't have enough memory left (heap!) to create additional widgets. In that case you want to increase the heap size that you can configure in the configuration file. Alternatively, you can always create all your objects statically and pass the corresponding object pointer as the first parameter to the create function. Are you able to successfully open the font using gdispOpenFont() and draw with the opened font using gdispDrawString()?

Hello and welcome to the community! The way you are using the TOGGLE support of the GINPUT module appears to be correct. The problem you are facing is that the list widget currently simply doesn't support a toggle role to select an entry. Looking at the list widget code we see that right now only two roles to move the selection up and down are defined. To implement the behavior you're looking for, you have to add a 3rd role to the switch() that processes the toggle roles. In that role, you have to programatically select the current list item. I hope that helps. Please don't hesitate to ask if you have any further questions.

Hello David, We'd definitely love to see your gradient code!

Adding a driver for the SSD1322 display controller is currently not on our ToDo list. However, adding such a driver is very easy and doesn't take a lot of time. The reason we don't have it is because we simply never got our hands on an SSD1322 display controller. We can encourage you writing that driver yourself. It is very easy and the existing examples such as the SSD1306 should help you a lot. Please don't hesitate to ask if you have any questions. We are happy to help where ever we can.